개념
세 축은 서로 독립이다
CSTS 가이드는 테스트를 세 개의 독립된 축 으로 분류한다.
| 축 | 값 |
|---|---|
| 테스트 레벨 | 컴포넌트(단위) · 통합 · 시스템 · 인수 |
| 테스트 유형 | 기능 / 비기능(성능·신뢰성·보안 …) |
| 테스트 설계 기법 | 정적(리뷰·정적 분석) / 동적(명세 기반·구조 기반·경험 기반) |
독립이라는 말은 어떤 조합도 가능하다 는 뜻이다. "통합 레벨에서 성능 유형을 명세 기반 기법으로" 테스트할 수 있다. 그래서 "구조 기반 테스트는 시스템·인수 테스트 단계에서만 수행한다" 같은 문장은 틀렸다 — 구조 기반은 주로 컴포넌트 레벨에서 쓰지만 어느 레벨에서도 쓸 수 있다(예: 통합 레벨의 호출 커버리지, 시스템 레벨의 메뉴 커버리지).
레벨 — 무엇을 기준으로 테스트하는가 (V 모델)
| 레벨 | 대상 | 기준 문서 |
|---|---|---|
| 컴포넌트(단위) | 함수·클래스·컴포넌트를 독립적으로 | 상세 설계 |
| 통합 | 컴포넌트 사이의 인터페이스·상호작용 | 구조(아키텍처) 설계 |
| 시스템 | 전체 시스템 | 요구사항 명세 |
| 인수 | 전체 시스템을 고객·사용자 관점 에서 | 고객·사용자의 필요와 기대 |
진행 순서는 컴포넌트 → 통합 → 시스템 → 인수 다. 시스템 테스트와 인수 테스트는 둘 다 전체 시스템이 대상이지만 관점 이 다르다. 함정 보기: "단위 테스트는 모듈을 통합할 때 쓰는 인터페이스를 대상으로 한다"(X — 그것은 통합 테스트).
통합 방식 — 빅뱅과 점진적 통합
컴포넌트를 한 번에 붙이는 빅뱅(Big-bang) 은 준비가 간단하지만, 장애가 나면 어느 컴포넌트가 원인인지 찾기 어렵다. 그래서 몇 개씩 차례로 붙이는 점진적(Incremental) 통합을 쓴다. 원인 찾기는 쉬워지는 대신 스텁과 드라이버를 여러 번 만들어야 한다.
| 방식 | 순서 | 필요한 것 | 장점 | 단점 |
|---|---|---|---|---|
| 상향식(Bottom-up) | 하위 → 상위 | 드라이버 (상위 호출자를 대신) | 하위 컴포넌트를 충분히 테스트, 스텁 불필요 | 시스템 전체 모습이 늦게 보임 |
| 하향식(Top-down) | 상위 → 하위 | 스텁 (하위 피호출자를 대신) | 주요 제어 흐름·골격을 일찍 확인 | 스텁이 많이 필요, 하위 테스트가 늦음 |
| 샌드위치 | 상·하 동시 | 둘 다 | 병행 진행 | 관리 복잡 |
외우는 법: 드라이버는 위에서 "운전해(호출해)" 주고, 스텁은 아래에서 "받아 주는" 가짜 다. 하향식은 아직 없는 아래를 스텁으로, 상향식은 아직 없는 위를 드라이버로 채운다. 하향식은 다시 깊이 우선·너비 우선으로 나뉜다.
테스트 더블 — 컴포넌트를 고립시키는 다섯 가지 가짜
컴포넌트 테스트는 독립적으로 해야 하므로 협력 객체를 가짜로 바꾼다. 가이드가 쓰는 구분은 다음과 같다(모의 객체는 절차 지향의 스텁을 객체 지향으로 옮긴 것이다).
| 이름 | 하는 일 | 한 줄 판별 |
|---|---|---|
| 더미(Dummy) | 자리만 채움. 기능 불필요, 호출되면 예외 | "인자로 넘기기만 한다" |
| 스텁(Stub) | 정해진 값을 돌려줌 | "잔액 조회하면 850을 준다" |
| 스파이(Spy) | 대상이 협력 객체로 보낸 출력 을 기록해 검증 | "몇 번, 무엇으로 호출됐나 기록" |
| 목(Mock) | 기대 호출을 미리 정하고 상호작용 을 검증 | verify(acct, times(1)).withdraw(500) |
| 페이크(Fake) | 실제 기능을 단순하게 동작하는 구현으로 대체 | 메모리 DB, 가짜 파일 시스템 |
Mockito 예시로 보면 when(acctMock.balance()).thenReturn(850) 이 스텁 역할,
verify(acctMock, times(1)).withdraw(500) 이 목의 상호작용 검증이다.
FIRST 원칙 — 좋은 컴포넌트 테스트의 다섯 성질
| 글자 | 원칙 | 위반 예 |
|---|---|---|
| F | Fast — 빨라야 한다 | 실제 DB·네트워크를 호출해 전체 실행에 수 분 |
| I | Isolated — 다른 테스트에 의존하지 않는다 | 테스트 A가 만든 데이터를 테스트 B가 읽음 → 순서 바꾸면 실패 |
| R | Repeatable — 몇 번 실행해도 같은 결과 | 현재 시각·난수에 의존 |
| S | Self-Validating — 사람 개입 없이 통과/실패 판정 | 로그를 사람이 눈으로 확인 |
| T | Timely — 제때(대상 코드 작성 직전·직후) 작성 | 릴리스 직전에 몰아서 작성 |
Isolated가 깨지면 실행 순서에 따라 결과가 달라진다. 단독 실행은 통과하는데 전체 실행에서만 실패하는 테스트가 전형적 증상이다.
유형 — ISO/IEC 25010:2011 8개 주특성과 부특성
| 주특성 | 부특성 | 대표 테스트 |
|---|---|---|
| 기능 적합성 | 기능 완전성·정확성·적절성 | 기능 테스트 |
| 성능 효율성 | 시간 반응성·자원 효율성·용량 | 부하·스트레스·용량 테스트 |
| 호환성 | 공존성·상호 운용성 | 상호 연동, 크로스 브라우징 |
| 사용성 | 적절성 인식·학습성·운용성·사용자 오류 방지·UI 미학·접근성 | 사용성 테스트, 접근성 진단 |
| 신뢰성 | 성숙성·가용성·결함 허용성(장애 허용성)·회복 가능성 | 장애 주입, 복구 테스트 |
| 보안성 | 기밀성·무결성·부인 방지·책임성·진정성 | 취약점 점검, 침투 테스트 |
| 유지보수성 | 모듈성·재사용성·분석성·수정성·시험성 | 정적 분석, 복잡도 측정 |
| 이식성 | 적응성·설치성·대체성 | 설치·이전 테스트 |
단답형은 "부특성 넷(성숙성·가용성·장애 허용성·회복 가능성)을 주고 주특성을 묻는" 형태가 많다 (답: 신뢰성). 가이드는 호환성 테스트 예로 Selenium Grid(허브-노드 구조로 여러 OS·브라우저 조합에서 병렬 실행)를 들고, 자동화만으로는 사람 눈으로 확인할 부분이 남으므로 수동 테스트를 병행 하라고 쓴다. 기능 테스트를 뺀 나머지가 비기능 테스트 이고, 품질 특성별로 수행하는 테스트를 묶어 유형 테스트 라 부른다.
테스팅 방법 ① 리그레션 테스트
변경(결함 수정·기능 추가·성능 개선·환경 적응·유지보수성 개선) 뒤에 의도치 않은 결함이 생기지 않았는지, 기존 요구를 여전히 충족하는지 확인한다. 전략 네 가지를 이름으로 외운다.
| 전략 | 뜻 |
|---|---|
| Retest-all | 기존 TC를 전부 다시 실행. 안전하지만 비싸다 |
| 선택적 리그레션 | 변경 영향을 받는 TC만 골라 실행 |
| 테스트 최소화 | 커버리지를 유지하면서 중복 TC를 줄인 집합 실행 |
| 테스트 우선순위화 | 결함을 빨리 찾을 가능성이 높은 순서로 실행 |
변경이 생기면 컴포넌트 → 통합 → 시스템 레벨 순서로 각 레벨마다 리그레션을 수행한다. 리그레션은 반복성이 높아 자동화 1순위 다.
테스팅 방법 ② 생명 주기 모델별 테스트 시점
| 모델 | 테스트가 시작되는 때 | 특징 |
|---|---|---|
| Code-and-Fix | 따로 없음(디버깅의 일부) | 소규모·일회성에만 타당 |
| 폭포수 | 구현 완료 후 한 번 | 모든 산출물이 갖춰진 상태에서 시작하지만 결함 해결 비용이 크다 |
| V 모델 | 개발 시작과 함께 | 요구분석 단계에서 시스템 테스트 계획·설계, 구조 설계 단계에서 통합 테스트 계획. 산출물 리뷰·정적 분석 병행 |
| 진화적(반복·점진) | 이터레이션마다 | 이터레이션마다 테스트 계획을 세움 |
| 나선형 | 주기마다 | 주기마다 위험 분석 후 테스트 조정 |
| 프로토타이핑 | 시제품마다 | 점진적 완성, 안에 작은 V 모델이 들어 있다 |
| 애자일 | 스프린트 안에서 지속 | TDD(테스트 먼저 → 통과하는 코드), 지속적 통합(CI) |
TDD의 순서는 "실패하는 테스트 작성 → 통과할 최소 코드 → 리팩터링"이다. CI는 개발자가 저장소에 반영할 때마다 통합·빌드·테스트가 돈다는 뜻이고, 하루에도 여러 번 일어날 수 있다.
테스팅 방법 ③ 위험 기반·모델 기반
- 위험 기반 테스트 — 피처별 위험 분석 결과로 테스트 계획·설계·실행을 정한다. 테스트하지 않았을 때 위험이 낮은 것은 제외할 수 있지만 높은 것은 반드시 포함 한다. 고위험 피처에는 이른 레벨부터, 더 강한 기법, 더 엄격한 완료 기준을 적용한다(레슨 7의 L × I)
- 모델 기반 테스트 — TC·절차·입력·예상 결과를 자동으로 뽑을 수 있을 만큼 정형적이고 상세한 모델 에서 생성한다. 모델 구축 비용이 추가되지만 이후 자동화로 효율이 높고, 모델 자체의 결함을 일찍 찾는다. 자동차·의료 같은 안전 필수 분야에서 쓴다(s1-m03-l11, s4-m54 모듈)
실무에서 왜 필요한가
통합 방식은 일정과 직결된다. 하위 모듈(결제 게이트웨이 연동 등)이 먼저 끝나는 프로젝트에서 하향식을 고집하면 스텁만 쌓이고, 반대로 화면 골격을 먼저 고객에게 보여야 하는 프로젝트에서 상향식을 고르면 시연이 늦어진다. "어느 쪽이 먼저 준비되는가"로 방식을 정하고, 그에 맞춰 스텁· 드라이버 작업을 계획에 넣는다.
테스트 더블 용어는 개발자와의 대화에서 곧바로 쓰인다. "여기는 목으로 호출 횟수를 검증해야 하나요, 스텁이면 충분한가요?"라는 질문을 할 수 있으면 단위 테스트 리뷰에서 QA의 발언권이 생긴다. FIRST의 Isolated·Repeatable 위반은 CI에서 플래키 테스트 로 나타난다(s2-m07-l03).