테스트 분류 체계로 설계하는 품질 전략
화이트박스·블랙박스, 정적·동적 테스트, Verification·Validation과 목적별 분류를 조합해 테스트 전략을 설계하는 기준
2026-08-14 · 최초 발행 2025-12-14
테스트 전략은 분류 기준을 조합하는 일이다
품질 목표가 같더라도 요구사항의 성격과 리스크에 따라 필요한 테스트는 달라진다. 테스트 분류는 정보획득 대상, 프로그램 실행 여부, 수행 시각, 목적을 기준으로 활동을 체계화하는 방법이다.
이 기준을 활용하면 중복 테스트를 줄이고, 커버리지와 리스크에 맞는 조합을 설계할 수 있다. 요구사항 검토부터 릴리스 승인까지 전 생명주기에 적용하며 비용·일정·품질 사이의 균형을 맞추는 데 쓴다.
내부 구조를 볼 것인가, 외부 행위를 볼 것인가
화이트박스 테스트는 내부 구조와 제어 흐름을 기반으로 한다. 문장·분기·조건·경로 커버리지를 정량화할 수 있어 코드 수준의 보완에 적합하다.
블랙박스 테스트는 명세와 입출력 행위에 집중한다. 동등분할, 경계값, 의사결정 테이블, 상태전이 모델을 적용해 구현 세부사항보다 기대 행위를 검증한다.
그레이박스는 인터페이스나 데이터 흐름 일부를 볼 수 있는 상황에서 활용한다. 통합 테스트와 계약 테스트에서 실무적인 보완 수단이 된다.
실행 전 결함 제거와 실행 기반 검증
동적 테스트는 프로그램을 실제로 실행해 확인한다. 설계 기법은 다음처럼 나눌 수 있다.
- 명세 기반: 요구사항·유스케이스·계약 기반 시나리오
- 구조 기반: 커버리지 향상 목적의 경로·조건 조합
- 경험 기반: 탐색적 테스트, 에러 추정, 체크리스트 기반 테스트
정적 테스트는 프로그램을 실행하지 않고 산출물을 검토하거나 분석한다. 비공식적 리뷰, 워크쓰루, 기술적 리뷰, 코드 인스펙션이 여기에 포함된다. 정적 분석 도구는 결함 패턴, 코딩 표준 위반, 보안 취약점을 검출하는 데 사용한다.
Verification과 Validation이 확인하는 대상
Verification은 올바르게 만들고 있는지를 확인한다. 산출물의 일관성과 완전성을 평가하며, 요구사항과 설계의 추적성, 코드 표준 준수, 인터페이스 계약 확인 등이 대상이다.
Validation은 올바른 것을 만들었는지 확인한다. 사용자 가치와 업무 적합성을 검토하며, 시스템·인수 테스트나 사용 시나리오를 통한 수용 기준 검증이 이에 해당한다.
리스크에 따라 달라지는 테스트 목적
회복 테스트는 장애나 오류 뒤의 복구 시간(RTO), 데이터 복구(RPO), 재시도와 롤백을 검증한다. 강도 테스트는 한계 부하, 리소스 고갈, 스파이크 상황에서 실패 모드와 저하 곡선을 평가한다.
성능 테스트는 처리량, 지연, 자원 사용량, 확장성을 측정하고 SLA/SLO 준수 여부를 확인한다. 안전 테스트는 위해 발생 위험을 낮추기 위해 페일세이프, 인터록, 허용오류영역을 검증하며 임베디드·의료·산업 영역에서 특히 중요하다.
구조 테스트는 모듈의 결합도와 응집도, 레이어링과 경계 규칙, 테스트 용이성을 평가한다. 보안 테스트는 인증·인가, 입력 검증, 데이터 보호, OWASP Top 10 등의 취약점을 다룬다. 병행 테스트는 데이터 레이스, 데드락·라이브락, 메모리 가시성, 트랜잭션 격리 위반을 확인한다.
리스크에서 종료 기준까지 이어지는 설계
테스트 전략은 먼저 자산·위협·안전·가용성 요구를 파악하고, 임팩트×발생확률로 리스크를 명세화하면서 시작한다. 이후 상위 리스크를 회복·강도·성능·안전·구조·보안·병행 목적에 매핑한다.
초기에는 정적 테스트로 결함을 조기에 제거하고, 이어서 동적 테스트로 행위를 검증하는 파이프라인을 구성할 수 있다. 명세 신뢰도가 높다면 블랙박스 테스트를 우선하고, 화이트박스 테스트로 커버리지를 보완한다.
구간별로는 리뷰·정적 분석을 위한 Verification 게이트와 실행 기반의 Validation 게이트를 나눠 둔다. 명세·구조·경험 기반 기법의 매트릭스와 커버리지 목표를 설정하고, 병행·성능 목적에 맞게 데이터 볼륨, 동시성, 격리 수준을 구성한다. 마지막으로 결함밀도, 성능 SLO, 보안 취약점 임계치와 출구 기준을 정한다. 커버리지 목표에는 분기 80% 등이 포함될 수 있다.
오류와 예외를 다룰 때는 입력부터 처리와 출력까지의 경로에 경계값, 비정상 입력, 타임아웃, 재시도, 서킷브레이커를 포함한다. 트랜잭션과 락에서는 격리수준, 락 순서·타임아웃을 통한 데드락 회피, 보상 트랜잭션을 정의한다. 네트워크 단절, 장애 전파, 부분 장애 복구도 실패 주입 시나리오에 포함한다.
분류 기준이 테스트 전략으로 모이는 흐름
정적 테스트와 동적 테스트의 운영상 차이
| 지표 | 정적 테스트 | 동적 테스트 |
|---|---|---|
| 성능(피드백 속도) | 빠름, 대규모 코드 기반 병렬 리뷰·분석 용이 | 느림~보통, 환경 구동·데이터 준비 비용 발생 |
| 확장성(조직/코드 규모) | 높음, 규칙·자동 분석 룰로 확장 쉬움 | 중간, 테스트 데이터·시나리오 유지 비용 증가 |
| 일관성(재현성/변동성) | 높음, 결정적 결과(도구/체크리스트) | 중간, 환경·시간·동시성에 따른 변동 가능 |
| 안정성(플레이크 리스크) | 높음, 비실행 기반으로 플래키 없음 | 중간~낮음, 비결정적 요소(타이밍/리소스) 존재 |
| 운영 편의 | 높음, CI 초기 단계 게이트 적합 | 중간, 컨테이너·시뮬레이터·테스트데이터 관리 필요 |
도메인별 조합 방식
금융 API 플랫폼
보안·성능·병행을 중심에 둔다. 시크릿 린트·SAST와 계약 리뷰 같은 정적 테스트 뒤에 부하·스파이크·동시성 테스트를 수행한다. 계약 준수는 블랙박스로, 임계 경로 커버리지는 화이트박스로 보완한다.
지표로는 p95 지연, TPS, 고루틴·스레드 안전성, 취약점 제로 크리티컬을 둔다.
의료기기 펌웨어
안전과 회복이 중심이다. HAZOP 기반 Validation 시나리오를 구성하고, 센서 오류와 전원 단절을 실패 주입해 페일세이프와 워치독을 검증한다.
안전기능 커버리지, 복구 시간, 위험 저감 수준(ALARP)을 지표로 삼는다.
커머스 프런트와 백오피스
구조·유지보수성·성능의 균형이 필요하다. 아키텍처 경계 룰과 Cyclic Dependency 차단에는 정적 테스트를, UI 회귀와 A/B 성능에는 동적 테스트를 적용한다. 경험 기반 탐색도 함께 사용한다.
번들 크기, TTI, 코드 스멜 감소, 결함 재발률을 지표로 관리한다.
분류 체계가 만드는 운영 효과
정적 테스트로 결함을 선제적으로 제거하고 동적 테스트로 실사용 시나리오를 검증하면 결함 탐지율을 높일 수 있다. 초기 게이트에서 저비용 결함을 제거하고 고비용 시나리오에 집중함으로써 비용과 일정을 최적화한다.
보안·안전·회복·병행처럼 위험이 높은 영역에는 표준화된 커버리지를 적용할 수 있다. Verification과 Validation 게이트를 운영하면 릴리스 결정을 뒷받침하는 근거도 명확해진다.