테스트 레벨과 V모델
테스트 레벨
소프트웨어 개발 과정에서 테스트가 수행되는 단계.
단위 테스트- 통합 테스트 - 시스템 테스트 - 인수 테스트 순으로 진행.
V 모델
폭포수 모델을 확장한 개발 모델로 개발의 각 단계에 대응하는 테스트 단계를 정의.
| 테스트 단계 | 주체 | 개발 단계 (역순) | 테스트 대상 | 툴 / 유형 |
|---|---|---|---|---|
| 단위 테스트 | 개발자 | 모듈 설계 | 개별 모듈 / 컴포넌트 | 드라이버, 스텁 |
| 통합 테스트 | 개발자 / 팀 | 시스템 설계 | 모듈 간 인터페이스 | 상향식, 하향식, 빅뱅, 샌드위치 |
| 시스템 테스트 | 팀 | 시스템 요구 명세서 | 전체 시스템 | 기능, 성능, 보안, 복구 |
| 인수 테스트 | 사용자 | 사용자 요구 명세서 | 사용자 요구사항 | 알파 / 베타 테스트 |
인수 테스트의 대표적인 유형
테스트 7원칙
ISTQB(국제 소프트웨어 테스팅 자격위원회)에서 정의한 테스트의 7가지 기본 원칙.
| 원칙 | 핵심 키워드 |
|---|---|
| 결함 존재 증명 | 테스트는 결함의 존재를 보일 뿐, 결함이 없음을 증명하지 못함. |
| 완벽한 테스트 불가능 | 모든 입력, 조합을 테스트하는 것은 비현실적 |
| 초기 테스트 | 결함은 일찍 발견할수록 비용 절감 |
| 결함 집중 (파레토 법칙) | 적은 수의 모듈에 대부분의 결함이 집중됨(결함의 80%는 모듈의 20%에서 발생) |
| 살충제 패러독스 | 동일한 테스트 케이스 반복 시 새로운 결함을 발견하기 어려움 - 주기적 테스트 검토 및 갱신 필요 |
| 정황 의존성 | 테스트 활동은 소프트웨어 종류와 환경에 따라 달라짐 |
| 오류 - 부재의 궤변 | 결함이 없어도 사용자 요구를 충족하지 못하면 품질이 좋다 볼 수 없음 |
살충제 패러독스 (Pesticlde Paradox)
같은 살충제에 해충이 내성을 가지듯, 같은 테스트 케이스를 반복하면 새로운 결함 발견 확률이 감소한다.
성능 측정 지표
시스템 테스트의 성능 테스트에서 사용하는 4가지 지표.
| 지표 | 정의 | 키워드 |
|---|---|---|
| 처리량 | 단위 시간당 처리할 수 있는 트랜잭션 수 | 단위 시간 당 처리량 |
| 응답시간 | 사용자 입력 후 응답 출력까지의 시간 | 응답 시작 순간 |
| 경과시간 | 사용자 요구 입력 시점부터 결과 출력까지의 시간 | 응답 끝나는 순간 |
| 자원 사용률 | CPU, 메모리, 네트워크 사용량 | 자원 소비량 |
회귀 테스트
결함을 수정하거나 기능을 변경한 뒤, 새로운 결함이 발생하는 지 반복 시험.
| 테스트 | 정의 |
|---|---|
| 확인 테스트 | 결함 수정되었는지 단독 확인 |
| 재테스트 | 동일한 입력으로 재시도 |
| 회귀 테스트 | 변경사항이 새로운 결함을 만드는지 반복 시험 |
테스트 커버리지
테스트가 소스 코드를 충분히 검증했는지 확인하는 지표.
명령문, 결정문, 조건식
| 용어 | 정의 | 예시 |
|---|---|---|
| 명령문 | 실행 가능한 코드 한 줄 (실행문) | System.out.println("Hello");, x = 5; |
| 결정문 | 참/거짓을 판단하는 조건부 문장의 전체 조건 | if (x > 0 && y < 10), while (a < b) |
| 조건식 | 결정문 내부의 개별 비교 연산 | 위 결정문 예시에서 x > 0, y < 10, a < b 이부분만 조건식 |
구문(문장) 커버리지 (Statement Coverage)
소스 코드의 모든 실행 가능한 문장(명령문)이 적어도 한 번 이상 실행되었는지
public void example(int x) {
if (x > 0) { // 결정문
System.out.println("Positive"); // 문장 1 (명령문1)
}
System.out.println("End"); // 문장 2 (명령문2)
}
x = 5if문의 참(true) 경로만 테스트하지만, 문장 1과 문장 2를 모두 실행하므로 구문 커버리지 100%를 만족합니다.만약 x가 0 이하(예를 들어 x=-1)이라면 if문의 참(true) 경로(System.out.println("Positive");)를 테스트하지 않습니다. 그러므로 구문 커버리지는 100%를 만족하지 않습니다.
결정/조건 커버리지 (Condition/Decision Coverage)
각 결정문의 결과가 참(True)과 거짓(False)을 각각 한 번 이상 가지는지
public void example(int x, int y) {
if (x > 0 && y > 0) { // 결정문
System.out.println("Both Positive");
}
}
x = 5, y = 5 (결정문 결과: 참)x = -1, y = 5 (결정문 결과: 거짓)조건 커버리지 (Condition Coverage)
결정문 내에 있는 각각의 개별 조건식이 참과 거짓을 한 번씩 가지는지?
조건/결정 커버리지 (Condition/Decision Coverage)
각 결정문의 결과가 참/거짓을 각각 한 번 이상 가지면서, 동시에 모든 개별 조건식의 결과도 참/거짓을 각각 한 번 이상 가지는지
변경 조건/결정 커버리지 (MC/DC, Modified Condition/Decision Coverage)
조건/결정 커버리지를 모두 만족시키면서 각 개별 조건식이 다른 조건식의 값과 관계없이 전체 결정문의 결과에 독립적으로 영향을 미치는지
블랙박스 테스트
블랙박스 테스트란?
블랙박스 테스트는 소프트웨어의 내부 구조나 소스 코드를 보지 않고, 오직 요구사항 명세를 보면서 기능이 올바르게 동작하는지를 검사하는 테스트 방법입니다. 사용자의 관점에서 테스트하는 것과 같으며, 명세 기반 테스트 또는 기능 테스트라고도 불립니다.
블랙박스 테스트 유형
| 테스트 유형 | 핵심 개념 |
|---|---|
| 동등 분할 테스트 | 입력 조건을 유효/무효 클래스로 나누어 테스트 |
| 경곗값 분석 테스트 | 분할된 클래스의 경계값을 집중적으로 테스트 |
| 결정 테이블 테스트 | 복잡한 논리적 조건과 그에 따른 행동을 표로 정리 |
| 원인-결과 그래프 테스트 | 입력(원인)과 출력(결과)의 논리적 관계를 그래프로 표현 |
| 상태 전이 테스트 | 시스템의 상태 변화를 기반으로 테스트 케이스 설계 |
| 오류 예측 테스트 | 테스터의 경험과 직관으로 오류가 발생할 만한 부분을 예측 |
| 비교 테스트 | 동일한 기능의 여러 버전 또는 제품을 비교하여 테스트 |
| 페어와이즈 테스트 | 모든 가능한 입력 값 조합 대신, 입력 값들의 모든 쌍(pair)을 테스트 |
| 분류 트리 테스트 | 테스트 관련 요소를 트리 구조로 분석하고 테스트 케이스 도출 |
| 유스케이스 테스트 | 사용자의 시나리오(유스케이스)를 기반으로 테스트 |
블랙박스 테스트 상세 유형
동등 분할 테스트 (Equivalence Partitioning)
경곗값 분석 테스트 (Boundary Value Analysis)
결정 테이블 테스트 (Decision Table Testing)
| 규칙 | 1 | 2 | 3 |
|---|---|---|---|
| 조건 | |||
| VIP 회원 | T | F | F |
| 10만원 이상 구매 | T | T | F |
| 쿠폰 사용 | T | F | F |
| 행동 | |||
| 20% 할인 | X | ||
| 5% 할인 | X | ||
| 할인 없음 | X |
원인-결과 그래프 테스트 (Cause-Effect Graphing)
입력 데이터 간의 관계나 출력에 영향을 미치는 상황을 체계적으로 분석하여, 효용성 높은 테스트 케이스를 선정하는 기법입니다. 입력(원인)과 출력(결과) 사이의 논리적 관계를 그래프로 표현합니다.
| 규칙 | 1 | 2 | 3 | 4 |
|---|---|---|---|---|
| 원인 | ||||
| C1: 1열='A' | T | F | F | F |
| C2: 1열='B' | F | T | F | F |
| C3: 2열='T' | T | T | F | T |
| 결과 | ||||
| E1: 업데이트 | O | O | X | X |
상태 전이 테스트 (State Transition Testing)
시스템의 상태가 특정 이벤트에 의해 어떻게 변하는지를 분석하고 테스트하는 기법입니다. 상태 전이도(State Transition Diagram)를 작성하여 테스트 케이스를 설계합니다.
아래는 ATM 기기의 상태 변화를 나타낸 상태 전이도입니다.
stateDiagram-v2 [*] --> 대기 대기 --> 카드삽입: 카드 삽입 카드삽입 --> PIN입력: PIN 입력 PIN입력 --> 거래중: PIN 일치 PIN입력 --> 카드반환: PIN 불일치 (3회) 거래중 --> 카드반환: 거래 종료 카드반환 --> 대기: 카드 회수
오류 예측 테스트 (Error Guessing)
테스터의 경험과 직관을 바탕으로 시스템에 어떤 오류가 있을지 예측하고, 그 오류를 검증하는 테스트 케이스를 설계하는 기법입니다. 정형화된 규칙은 없지만, 다른 기법들이 놓칠 수 있는 오류를 찾는 데 효과적입니다.
비교 테스트 (Comparison Testing)
동일한 테스트 자료를 가지고 여러 버전의 프로그램이나 경쟁사 제품과 비교하며 테스트하는 기법입니다.
페어와이즈 테스트 (Pairwise Testing)
모든 가능한 입력 파라미터의 조합을 테스트하는 대신, 최소한의 테스트 케이스로 모든 파라미터 값들의 쌍(pair)을 한 번씩은 테스트하도록 조합을 만드는 기법입니다. 파라미터가 많아질수록 조합의 수가 기하급수적으로 늘어나는 '조합 폭발' 문제를 해결하는 데 매우 효과적입니다.
분류 트리 테스트 (Classification Tree Method)
테스트 대상의 입력과 조건을 트리 구조로 표현하여 체계적으로 테스트 케이스를 도출하는 방법입니다. 복잡한 입력 값의 조합을 시각적으로 명확하게 분석하고, 논리적인 테스트 케이스를 설계하는 데 도움을 줍니다.
graph TD Root(파일 업로드) subgraph "분류 (Classification)" Root --> C1(파일 종류) Root --> C2(파일 크기) end subgraph "클래스 (Classes)" C1 --> T1[이미지] C1 --> T2[문서] C2 --> S1[10MB 미만] C2 --> S2[10MB 이상] end subgraph "테스트 케이스 (Test Cases)" TC1("TC1: 이미지, 10MB 미만") TC2("TC2: 이미지, 10MB 이상") TC3("TC3: 문서, 10MB 미만") TC4("TC4: 문서, 10MB 이상") end T1 --> TC1 T1 --> TC2 T2 --> TC3 T2 --> TC4 S1 --> TC1 S1 --> TC3 S2 --> TC2 S2 --> TC4
유스케이스 테스트 (Use Case Testing)
사용자 관점에서 시스템이 제공하는 기능의 시나리오를 정의한 유스케이스를 기반으로 테스트 케이스를 설계하는 기법입니다. 시스템이 실제 사용자의 목표를 달성시키는 과정에서 발생하는 상호작용 흐름을 검증하는 데 중점을 둡니다.