요약
- 테스트는 결함 발견을 목적으로 하며,
- **블랙박스(기능 중심)**와 화이트박스(구조 중심) 두 축으로 접근하고,
- 단위 → 통합 → 시스템 → 인수의 단계로 진행된다.
0. 테스트 개요
- 테스트의 목적
- 사용자 요구기능을 소프트웨어가 만족하는지 확인하기 위해 결함을 발견하는 활동
- 테스트 케이스를 실행시켜 시스템 동작이 예상대로 실행되는지 확인
테스트로 결함의 존재는 증명할 수 있지만, 부재는 증명할 수 없다. (다익스트라)
-
결함을 낮추는 방법
- 사전 방지: 인스펙션, 정적 분석
- 사후 제거: 테스트, 디버깅
-
테스팅 방식
- 블랙박스 테스트: 구현을 고려하지 않고 기능 테스트
- 화이트박스 테스트: 기능과 구현 방식까지 분석
0.1. 검증 vs. 확인
-
검증 (Verification)
- “제품을 올바르게 구축하고 있는가?”
- → 명세 준수 여부 점검, 문서 대상
- (리뷰, 인스펙션, 워크스루)
-
확인 (Validation)
- “올바른 제품을 만들고 있는가?”
- → 사용자 충족 여부, 최종 제품 대상
- (단위/통합/시스템/인수 테스트)
1. 블랙박스 테스트
1.1. 주요 기법
-
동등 분할 (Equivalence Partitioning)
- 같은 동작이 예상되는 입력 그룹으로 분류 후 대푯값 선정
- 유효 동등 클래스: 정상 입력 범위
- 무효 동등 클래스: 비정상 입력 범위
- 예: 나이 입력 → Invalid(≤17), Valid(18~60), Invalid(≥61)
-
경곗값 분석 (Boundary Coverage)
- 동등 클래스의 경계값에 집중
- 입력 조건 min ≤ X ≤ max일 때: min-1, min, min+1, max-1, max, max+1
-
원인과 결과 그래프 (Cause-Effect)
- 입력 조건의 조합을 체계적으로 분석
- 노드(원인/결과)와 기호(∧, ∨, ~)로 그래프 구성
-
결정 테이블 (Decision Table)
- 원인-결과 그래프에서 테스트 케이스 도출
- 결과별 조건 조합을 표로 나열 (X는 don’t care)
2. 화이트박스 테스트
-
화이트박스 테스트 (White-Box Test)
- 내부 소스 코드를 직접 확인하며 논리적 실행 경로 검증 (구조적 테스트)
- 주로 단위 테스트에서 활용
-
테스트 과정
- 코드 분석(논리 흐름도) → 검증 기준 결정 → 테스트 데이터 준비/실행
-
논리 흐름도 기본 요소
- 선형, if-then-else, switch, while/for, until 블록
2.1. 3가지 검증 기준 (Test Coverage)
| 커버리지 | 설명 |
|---|---|
| 문장 커버리지 | 각 문장이 최소 한 번 실행 (오류 부재를 보장하지 않음) |
| 분기 커버리지 | 모든 분기(True/False)가 최소 한 번 실행 |
| 경로 커버리지 | 모든 실행 경로 검증 (분기 2개면 4가지 케이스) |
2.2. 기본 경로 테스트 - 순환 복잡도(CC, Cyclomatic Complexity)
- 매케이브가 정의한 메트릭으로, 세 가지 공식:
- CC = R(영역)의 수 + 1
- CC = E(간선) − N(노드) + 2
- CC = P(분기 노드) + 1
2.3. 루프 테스트 (4가지 반복 구조)
- 단순 반복: 0회 / 1회 / 임의 / 최대-1회 / 최대회 반복
- 중첩 반복: 내부부터 단순 반복 테스트 적용
- 연속 반복: 독립적이면 단순 반복, 의존적이면 중첩 반복 방식
- 비구조화 반복: 구조적 반복으로 변환 후 테스트
3. 통합 테스트
3.1. 4가지 통합 방식
| 방식 | 특징 | 장점 | 단점 |
|---|---|---|---|
| 빅뱅 | 모든 모듈 한 번에 통합 | 일정 관리 편함, 스텁 불필요 | 오류 위치 파악 어려움, 융통성 부족 |
| 하향식 | 위 → 아래 (스텁 필요) | 상위 인터페이스 조기 검증, 사용자에 일찍 시현 | 하위 모듈 테스트 부족 |
| 상향식 | 아래 → 위 (드라이버 필요) | 하위 모듈 충분히 테스트 | 상위 인터페이스 늦게 확인, 초기 시스템 모습 없음 |
| 연쇄식 | 기능 단위(thread)별 통합 | 골격 빠르게 확인, 분산 개발 용이 | 드라이버/스텁 작성 오류 가능 |
4. 시스템 및 인수 테스트
4.1. 성능 테스트 측정 지표
- 성능 테스트 방법
- 스트레스 테스트: 처리능력의 몇 배 부하 견딜 수 있는지 측정
- 시뮬레이션: 난수 생성기로 작업 부하 생성
4.2. 보안 테스트
- 보안 취약점 탐색, 정적 테스트 도구로 취약 패턴 검출, 랜덤 테스트 사용
4.3. UI 테스트
- 인간 공학적 결함 발견 목적
- 결함 종류
- UI 외형, 입출력 디스플레이, 액터-시스템 동작, 오류 처리, 문서/도움말
4.4. 인수 테스트
- 의뢰자/대리인이 사용자 환경에서 수행
- 알파 테스트: 선택된 사용자가 개발 환경에서 시험
- 베타 테스트: 선택된 사용자가 고객 사용 환경에서 시험 (필드 테스트)