1. 소프트웨어 테스트의 7대 원리 (가)
소프트웨어 테스트는 결함을 완벽히 제거하는 과정이 아닌, 위험을 최소화하는 품질 보증 활동이다. 이를 위해 ISTQB(국제 소프트웨어 테스트 자격위원회)에서 정의한 7가지 근본 원리가 존재한다.
테스트는 결함이 없음을 증명할 수 없다 (Testing shows presence of defects): 테스트는 결함이 존재함을 보여줄 수는 있지만, 결함이 전혀 없음을 증명할 수는 없음.
완벽한 테스팅은 불가능하다 (Exhaustive testing is impossible): 모든 입력과 조건의 조합을 전수 테스트하는 것은 시공간적 한계로 불가능하므로, 리스크 분석과 우선순위에 따른 타겟 테스팅이 필요함.
조기 테스팅 (Early testing): 개발 수명주기(SDLC) 초기 단계(요구사항 분석, 설계)부터 테스트를 시작해야 요구사항 결함이 코딩으로 전파되는 비용을 막을 수 있음 (Defect Amplification 방지).
결함 집중 (Defect clustering): 파레토 법칙($80:20$ 규칙)과 같이, 대다수의 소프트웨어 결함은 특정 소수의 핵심 모듈에 집중되어 발생함.
살충제 패러독스 (Pesticide paradox): 동일한 테스트 케이스를 반복적으로 수행하면 더 이상 새로운 결함을 발견할 수 없으므로, 테스트 케이스를 주기적으로 리뷰하고 업데이트해야 함.
테스팅은 정황(Context)에 의존한다 (Testing is context dependent): 비즈니스 도메인에 따라 테스트 방식은 달라짐. 안전 중심의 자율주행 소프트웨어 테스트와 일반 이커머스 웹사이트의 테스트는 접근 제어와 강도가 달라야 함.
오류-부재의 궤변 (Absence-of-errors fallacy): 개발된 시스템이 사용자의 요구사항과 기대치를 만족하지 못한다면, 단순히 결함을 모두 찾아내고 수정했다 하더라도 품질이 높다고 말할 수 없음.
2. 화이트박스 테스트와 블랙박스 테스트의 개념 및 기법 비교 (나)
가. 두 테스트 기법의 개념 정의
화이트박스 테스트 (White-box Test): 개발자가 작성한 소스 코드의 내부 논리적 가시성(Structure)을 기반으로 제어 흐름, 루프, 분기점 등의 경로를 검증하는 내부 구조 중심 테스트 기법.
블랙박스 테스트 (Black-box Test): 시스템의 내부 코드를 보지 않고, 명세서(Specification)에 정의된 기능적 요구사항(Input/Output)을 기반으로 입력값에 따른 올바른 출력값이 나오는지 검증하는 외부 기능 중심 테스트 기법.
나. 상세 비교 매트릭스
| 비교 항목 | 화이트박스 테스트 (White-box Testing) | 블랙박스 테스트 (Black-box Testing) |
| 관점 및 대상 | 개발자 관점 (구조 중심, 내부 소스 코드) | 사용자/분석가 관점 (기능 중심, 요구사항 명세) |
| 수행 단계 | 단위 테스트 (Unit Test) 단계 위주 | 통합, 시스템, 인수 테스트 단계 위주 |
| 주요 장점 | 소스 코드 내 불필요한 데드 코드(Dead Code)나 논리적 오류를 정밀하게 식별 가능 | 코드를 몰라도 테스트가 가능하며, 비즈니스 시나리오 중심의 직관적 검증 가능 |
| 핵심 측정 지표 | 구문, 분기, 조건 커버리지 및 맥케이브 순환복잡도 | 요구사항 추적성 매트릭스(RTM), 기능 커버리지 |
| 대표 기법 | * 제어 흐름 테스트, 데이터 흐름 테스트 * 구문/분기/조건/변경조건-결정(MC/DC) 커버리지 | * 동등 분할, 경계값 분석, 결정 테이블 테스트 * 상태 전이 테스트, 유스케이스 테스트 |
3. [명세] 기반 동등 분할 및 경계값 분석 테스트 케이스 설계 (다)
가. 기법 적용을 위한 입력 데이터 영역 모델링
명세 조건(점수 $0 \sim 100$, 정수형) 및 출력 규칙에 맞추어 유효(Valid) 구간과 무효(Invalid) 구간을 도출한다.
나. 테스트 케이스(Test Case) 작성 테이블
정확한 검증을 위해 동등 분할(EP)은 각 클래스의 대표값을 선정하고, 경계값 분석(BVA)은 경계의 내부점, 온점, 외부점($n-1, n, n+1$) 원리를 적용하여 테스트 케이스를 명세화한다.
| TC ID | 적용 기법 | 테스트 입력값 (Score) | 등급 판별 기대 결과 (Output) | 케이스 성격 (Valid/Invalid) |
| TC-01 | 경계값 분석 | -1 | "ERROR" | 무효 (Invalid) |
| TC-02 | 경계값 분석 | 0 | "F" | 유효 (Valid) |
| TC-03 | 동등 분할 | 30 | "F" | 유효 (Valid) |
| TC-04 | 경계값 분석 | 59 | "F" | 유효 (Valid) |
| TC-05 | 경계값 분석 | 60 | "D" | 유효 (Valid) |
| TC-06 | 동등 분할 | 65 | "D" | 유효 (Valid) |
| TC-07 | 경계값 분석 | 69 | "D" | 유효 (Valid) |
| TC-08 | 경계값 분석 | 70 | "C" | 유효 (Valid) |
| TC-09 | 동등 분할 | 75 | "C" | 유효 (Valid) |
| TC-10 | 경계값 분석 | 79 | "C" | 유효 (Valid) |
| TC-11 | 경계값 분석 | 80 | "B" | 유효 (Valid) |
| TC-12 | 동등 분할 | 85 | "B" | 유효 (Valid) |
| TC-13 | 경계값 분석 | 89 | "B" | 유효 (Valid) |
| TC-14 | 경계값 분석 | 90 | "A" | 유효 (Valid) |
| TC-15 | 동등 분할 | 95 | "A" | 유효 (Valid) |
| TC-16 | 경계값 분석 | 100 | "A" | 유효 (Valid) |
| TC-17 | 경계값 분석 | 101 | "ERROR" | 무효 (Invalid) |
4. 기술사적 제언: 블랙박스 테스트 설계의 한계 극복 및 자동화 방안
명세 누락 및 오염 방지를 위한 결합 기법 활용: 동등 분할과 경계값 분석은 단일 변수의 독립적 도메인을 테스트하는 데 효과적이지만, 다중 조건 간의 상관관계(예: 점수가 90점 이상이면서 출석률이 80% 미만일 때의 처리 등)를 검증하기는 어렵다. 이를 극복하기 위해 실무에서는 여러 조건의 조합을 매트릭스로 구조화하는 결정 테이블(Decision Table) 테스팅이나 페어와이즈(Pairwise) 기법을 상호 보완적으로 연계 결합하여 테스트 커버리지를 보장해야 한다.
CI/CD 파이프라인과의 LLM 기반 테스트 자동화 통합: 매번 수작업으로 입력구간을 도출하는 방식은 비효율적이다. 현대적 소프트웨어 공학 환경에서는 요구사항 명세서(Swagger, Jira User Story 등)가 작성되면 대형언어모델(LLM) 기반의 테스트 에이전트가 동등 분할 및 경계값을 자동 계산하여 QA 스크립트(예: Playwright, JUnit)를 자동 생성하고, 이를 빌드 파이프라인에 통합 가동하는 무인화(No-human) 테스트 가드레일 체계로 진화해야 한다.
댓글 없음:
댓글 쓰기