개념
테스트의 목적 세 가지
CSTS 가이드는 테스트 목적을 세 가지로 정리한다. 보기 문장이 이 셋 중 무엇을 말하는지 구분할 수 있어야 한다.
| 목적 | 뜻 | 예시 문장 |
|---|---|---|
| 결함 검출과 품질 개선 | 결함을 찾아 제거해 품질을 높인다 | "로그인 실패 결함 12건을 찾아 수정했다" |
| 품질 평가와 의사 결정 지원 | 성능·신뢰성·보안 등 충족 수준을 평가해 출시 판단을 돕는다 | "응답 시간 기준 충족률 98%로 출시 가능" |
| 개발 프로세스 개선 지원 | 어느 단계에서 결함이 생기고 왜 못 잡았는지 분석한다 | "요구사항 결함이 40%라 요구 리뷰를 강화" |
"테스트는 결함이 없음을 보이기 위해 수행한다"는 틀린 보기 의 단골이다.
오류 → 결함 → 장애
세 용어는 인과 사슬 이다.
오류(Error) 결함(Defect) 장애(Failure)
사람의 행위 → 산출물 안의 문제 → 실행 결과와 요구의 관찰 가능한 차이
요구 오해·오타 코드·설계·명세 속 "USB를 꽂았는데 재생이 안 된다"
시험이 노리는 경계는 네 가지다.
- 결함이 있다고 반드시 장애가 나지는 않는다. 결함이 있는 코드가 실행되지 않거나, 실행되어도 특정 입력에서만 드러나면 장애로 관찰되지 않는다
- 결함은 코드에만 있지 않다. 요구사항 명세·설계서·테스트 문서 등 모든 개발 산출물에 있을 수 있다. 코드에서 발견된 결함의 원인이 설계의 잘못된 알고리즘이면 설계 결함이다
- 장애는 "관찰 가능한 차이"다. 실행 결과와 요구사항에 명시된 결과의 차이다
- 오류는 사람의 실수다. "결함(Fault)·버그와 같은 뜻"이라는 보기는 틀렸다
결함 3유형 — 누락·부정확·비관련
요구 명세와 구현을 두 개의 원으로 그리면 결함은 세 영역에 놓인다.
| 유형 | 위치 | 뜻 | 특징 |
|---|---|---|---|
| 누락(Omission) | 명세에만 있음 | 명세된 요구가 구현되지 않음 | 기능뿐 아니라 성능·보안 요구의 누락도 포함 |
| 부정확(Incorrect) | 겹치는 영역 | 명세된 요구가 틀리게 구현됨 | "A를 출력해야 하는데 B를 출력" |
| 비관련(Extraneous) | 구현에만 있음 | 명세와 무관한 구현 | 당장 장애를 유발하지 않을 수 있으나 분석·테스트·관리 노력을 낭비시키고 다른 결함의 원인이 된다 |
이차 방정식 해를 구하는 함수로 예를 들면 다음과 같다.
void quadratic(int a, int b, int c, float* x1, float* x2) {
D = b*b - 4*a*b; // 부정확: 판별식은 b*b - 4*a*c
if (D > 0) {
*x1 = (-b + sqrt(D)) / (2*a); // 부정확: a == 0 이면 0으로 나눔
...
} else if (D == 0) { ... }
// D < 0 (허근) 처리 없음 // 누락
int file = open(...); // 비관련: 해를 구하는 요구와 무관
}시험 보기는 그림의 A·B·C 영역에 유형을 맞히게 하거나, "당장 장애를 유발하지 않을 수도 있는" 유형을 묻는다(답: 비관련).
결함은 어디서 생기고, 늦게 잡으면 얼마나 비싼가
가이드가 인용하는 두 수치는 그대로 외워 둔다.
결함 발생 단계 비율 (Software Tech News, 2010)
| 단계 | 비율 |
|---|---|
| 코딩 | 35% |
| 설계 | 25% |
| 요구분석 | 20% |
| 문서화 | 12% |
| 결함 해결 오류(고치다 생긴 결함) | 8% |
단계별 결함 해결 상대 비용 (Davis, 1993)
| 단계 | 상대 비용 |
|---|---|
| 요구분석 | 0.1 ~ 0.2 |
| 설계 | 0.5 |
| 코딩 | 1 |
| 단위 테스팅 | 2 |
| 인수 테스팅 | 5 |
| 유지보수 | 20 |
결론은 하나다 — 각 단계 산출물을 그 단계에서 테스트(리뷰)해 빨리 제거해야 한다. 코딩 단계 기준으로 유지보수에서 고치면 20배다. 8장(정적 테스트)은 개발 완료 후 제거가 요구·설계 단계보다 "100배 이상"이라는 표현도 쓰고, Tom Gilb은 리뷰로 결함 제거 평균 비용을 60~80% 줄일 수 있다고 했다. 숫자가 장마다 다르게 인용되니 출처와 함께 기억한다.
테스팅·디버깅·재테스팅
| 활동 | 누가 주로 | 무엇을 | 결과물 |
|---|---|---|---|
| 테스팅 | 테스터 | 결함 존재 여부를 모르는 상태에서 실행해 장애를 관찰, 결함 존재를 간접 판단 | 결함을 검출한 TC와 환경 |
| 디버깅 | 개발자 | 결함의 위치와 원인 을 찾아 제거 | 수정된 코드 |
| 재테스팅 | 테스터 | 결함을 검출한 같은 TC 로 다시 실행해 제거 확인 | 확인 결과 |
함정 보기: "테스팅은 결함 위치를 찾아 수정까지 한다"(X), "디버깅은 알려지지 않은 결함을 찾는다"(X — 디버깅은 이미 존재가 알려진 결함을 다룬다). 재테스팅(확인 테스트)과 리그레션 테스트(변경이 다른 곳을 깨뜨리지 않았는지)도 구분한다.
완벽한 테스트는 불가능하다
입력값 무한, 경로 무한, 조합 폭발 때문이다. a·b·c를 2바이트 정수로 제한해도 2^16 × 2^16 × 2^16 가지다. 가이드는 낚시 비유를 쓴다 — 미끼(테스트 데이터)를 다 써도 물고기(결함)가 안 잡혔다고 저수지에 물고기가 없다고 단정할 수 없다. 다익스트라의 문장으로 요약된다.
프로그램 테스트는 결함이 있음을 보일 수는 있지만, 결함이 없음을 보일 수는 없다.
그래서 동등 분할·경곗값·조합 같은 설계 기법 과 위험 기반 테스트 가 필요하다. "테스터 수가 적어서", "일정이 부족해서"는 완벽한 테스트가 불가능한 근본 이유가 아니다.
테스트 진화 5단계 — 겔퍼린과 헤첼(1988)
| 레벨 | 이름 | 시기 | 핵심 |
|---|---|---|---|
| 1 | Debugging-oriented | ~1956 | 테스트와 디버깅 구분 없음, 우연히 발견한 결함 수정 |
| 2 | Demonstration-oriented | 1957~1978 | 프로그램이 올바로 동작함을 증명 |
| 3 | Destruction-oriented | 1979~1982 | 결함이 있음을 보이려고 테스트, 결함을 찾는 TC가 더 가치 있다 |
| 4 | Evaluation-oriented | 1983~1987 | 개발 전 단계 산출물을 리뷰 등으로 평가 |
| 5 | Prevention-oriented | 1988~ | 결함 예방, 테스트 용이한 설계, 테스트를 먼저 설계(TDD) |
같은 흐름을 비저(Beizer)는 Phase 0~4로 설명한다(0 디버깅과 구분 없음 → 1 동작함을 보임 → 2 동작하지 않음을 보임 → 3 위험 감소 → 4 테스트 용이성을 위한 사고방식). 문제에 "Beizer"가 나와도 마지막 단계 = 처음부터 테스트가 쉽도록 설계 라는 핵심은 같다.
마이어스의 테스트 원칙
『The Art of Software Testing』에서 가이드가 고른 원칙은 다섯이다.
- 독립성 — 개발한 프로그래머·팀과 무관한 그룹이 테스트한다(자기 코드에 방어적이고, 요구를 잘못 해석했다면 같은 오해로 테스트한다)
- 결함이 있다고 가정 하고 계획한다(레벨 3의 정신)
- 타당하지 않고 예상치 못한 입력도 테스트한다
- 파레토 — 결함이 남아 있을 확률은 이미 발견된 결함 수에 비례한다. 결함의 80%는 20%의 모듈에서 나온다 → 결함이 많이 나온 곳에 노력을 집중한다
- TC를 체계적으로 관리 (재사용)하고 각 결과를 철저히 점검 한다
"개발자가 프로그램을 가장 잘 알므로 직접 테스트하는 것이 효과적이다"는 틀린 보기다.
품질 보증 ⊃ V&V ⊃ 테스트
┌─────────────── 품질 보증 (QA) ───────────────┐
│ 제품 품질 + 프로세스 품질 │
│ ┌──────────── V&V ────────────┐ │
│ │ 정형 방법 · 테스팅 · V&V 분석 │ │
│ │ ┌──── 테스트 ────┐ │ │
│ │ │ 동적 · 정적 │ │ │
│ │ └────────────────┘ │ │
│ └──────────────────────────────┘ │
└─────────────────────────────────────────────────┘
- V&V — 29119-1 부록 분류로는 정형 방법(모델 체킹·정확성 증명), 테스팅(동적·정적), V&V 분석(시뮬레이션·평가)이다. 그래서 테스트보다 넓다
- 검증(Verification) 은 개발 활동 의 적합성 — 요구 명세가 설계에 제대로 반영됐는지 추적성 확인. 확인(Validation) 은 결과물 의 적합성 — 동작하는 소프트웨어가 요구를 충족하는지. "제대로 만들고 있나" vs "제대로 된 것을 만들었나"
- 품질 보증 은 ISO/IEC 12207 정의상 제품과 프로세스 의 적합성에 확신을 주는 활동이라 V&V보다 넓다(IEEE 730)
정답 형태는 테스트 < V&V < 품질 보증 이다.
ISO/IEC 25010 품질 특성 — 시험은 2011판
가이드는 ISO/IEC 25010:2011의 8개 주특성 을 쓴다. 기능 적합성·성능 효율성·호환성·사용성· 신뢰성·보안성·유지보수성·이식성. 2023년 개정판은 사용성을 상호작용 능력, 이식성을 유연성 으로 바꾸고 안전성 을 더해 9개가 되었다. 시험 답은 가이드 기준(8개)으로 쓰되, 실무 문서에는 어느 판을 따르는지 명시한다. 주특성별 부특성은 레슨 3에서 다룬다.
테스트 기본 용어의 관계
시험의 용어 문항은 이 관계도에서 나온다.
| 용어 | 정의 | 관계 |
|---|---|---|
| 테스트 대상(Test item) | 결함을 검출하려는 소프트웨어(전체 또는 일부) | 대상에 따라 컴포넌트·통합·시스템 테스트 = 레벨 테스트 |
| 피처(Feature) | 대상 특성 중 테스트하려는 측면·관점 | 한 대상에 여러 피처. 기능 피처·비기능 피처. 피처에 초점 = 유형 테스트 |
| 테스트 설계 기법 | 피처를 테스트하는 방법 | 정적(리뷰·정적 분석), 동적(명세·구조·경험 기반) |
| 테스트 케이스 | 입력 + 사전 조건 → 예상 결과(+ 사후 조건) | 예상 결과를 미리 정의 하는 것이 필수 |
| 테스트 절차 | TC를 특정 환경에서 수행하도록 순서를 정한 것 | 한 절차에 여러 TC, 한 TC가 여러 절차에 쓰일 수 있음 |
| 테스트 환경 | HW·SW·외부 연동 시스템·도구 | 절차가 실행되는 곳 |
함정: "요구사항에 명시되지 않은 입력은 TC가 될 수 없다"(X — 비정상 입력도 TC다). "테스트 스크립트는 TC를 적은 문서다"(X — 스크립트는 실행 절차, 특히 자동화 코드를 말한다).
실무에서 왜 필요한가
오류·결함·장애를 구분해 쓰면 결함 리포트가 정확해진다. "장애: 결제 완료 화면이 뜨지 않음 / 추정 결함: 승인 응답 파싱 / 추정 오류: API 명세 v2 필드명 오해"처럼 쓰면 디버깅 시간이 줄고, "오류" 칸이 쌓이면 프로세스 개선(세 번째 목적)의 데이터가 된다. 결함 3유형도 실무 분류로 쓸모가 있다 — 리뷰에서 누락이 많으면 요구 추적성 문제, 비관련이 많으면 범위 통제 문제다.
결함 비용 표는 리뷰 시간을 확보하는 협상 근거 다. "요구 리뷰 2시간을 쓰면 인수 단계 결함 한 건 비용의 수십 분의 일로 막을 수 있다"는 말은 숫자가 있을 때 설득력이 생긴다. 다만 이 수치는 1990년대 연구에서 나온 상대값이므로, 팀의 실제 결함 데이터로 바꿔 말하는 편이 더 강하다 (s2-m06-l05).