테스트케이스 설계로 결함을 재현하고 품질을 관리하는 방법

결함을 재현 가능한 검증으로 바꾸는 테스트케이스

테스트케이스는 소프트웨어 결함을 찾기 위해 입력 데이터, 실행 전제, 기대 결과를 정리한 검증 단위다. 요구사항 충족 여부를 확인하고, 회귀 테스트 자동화의 기반을 만들며, 결함을 같은 조건에서 재현하고 추적하도록 돕는다.

적용 범위는 단위 테스트에 한정되지 않는다. 통합, 시스템, 인수 테스트에서도 같은 방식으로 검증 조건과 결과를 명확히 남길 수 있다.

테스트케이스에는 보통 다음 정보가 포함된다.

식별자와 테스트 대상 기능 또는 요구사항
입력 데이터, 사전조건, 기대 결과
OS, 브라우저, 버전, 데이터 상태 같은 실행 환경
외부 API와 DB 시드 등 의존성
실행 단계, 권한이나 데이터 고정화 같은 특수 절차, 예외 상황의 기대 결과

이 정보가 빠지면 테스트 결과는 남아도 다른 사람이 같은 조건으로 실행하기 어려워진다. 요구사항과 테스트케이스를 연결해 두면 변경이 발생했을 때 영향 범위를 추적하는 데도 유리하다.

입력과 규칙에서 출발하는 블랙박스 설계

블랙박스 테스트는 내부 구현보다 외부에서 보이는 입력, 출력, 규칙을 기준으로 케이스를 만든다.

Syntax 테스트는 입력 형식, 스키마, 프로토콜 준수 여부를 확인한다. 파서, 유효성 검증기, 정규식 규칙을 대상으로 입력 포맷을 정하고 유효·무효 표본을 만든 뒤 오류 코드와 메시지를 확인한다.

동등 분할은 같은 동작을 보일 것으로 예상되는 입력을 하나의 클래스로 묶고, 각 클래스의 대표값을 선택하는 방법이다. 유효·무효 클래스를 나눈 뒤 대표값과 기대 결과를 연결해 테스트 수를 줄인다.

경계값 분석은 최소값과 최대값, 그리고 그 직전·직후 값에 집중한다. 수치, 길이, 범위처럼 경계에서 오류가 생기기 쉬운 입력을 검증할 때 적합하다. 입력 범위를 도출한 다음 경계점±1을 선택하고, 각 값의 기대 결과를 정한다.

의사결정 테이블은 여러 조건과 행동의 조합을 매트릭스로 정리하는 방식이다. 규칙 기반 시스템, 요금, 권한처럼 조건 조합이 많아지는 영역에서 불가능하거나 중복되는 조합을 제거하고 규칙별 결과를 명세할 수 있다.

코드 구조를 따라 확인하는 화이트박스 설계

화이트박스 테스트는 코드의 구조와 실행 경로를 기준으로 빈 검증 영역을 찾는다.

구조 기반 시험에서는 코드 라인, 분기, 조건의 커버리지 목표를 세운다. 커버리지 기준을 정하고 경로를 설계한 뒤, 리포트에서 확인된 미커버 경로를 보완한다.

제어 구조 시험은 경로, 결정, 조건의 조합을 검증한다. CFG를 작성하고 독립 경로를 선정한 다음 각 경로를 통과할 입력 데이터를 구성한다. 복잡도(Cyclomatic Complexity)는 우선순위를 정하는 기준으로 활용할 수 있다.

루프 시험은 0회, 1회, 다회 실행과 경계 횟수, 중첩 루프를 대상으로 한다. 루프 유형을 식별한 뒤 0/1/k/k-1/k+1 회수를 설계하고, 조기 종료와 예외 경로까지 포함한다. 이는 성능 문제, 무한 루프, 오버플로를 예방하기 위한 검증과 연결된다.

요구사항에서 회귀 세트까지 이어지는 흐름

⤢✕

테스트는 실행으로 끝나지 않는다. 실패한 결과는 결함 등록과 재현 절차 기록으로 이어지고, 수정된 빌드는 재테스트와 회귀 테스트를 거쳐야 한다. 통과한 케이스도 커버리지 검토를 거쳐 회귀 세트에 반영된다.

운영 관점에서 보완하는 특성

지표	블랙박스 테스트	화이트박스 테스트
성능(실행 효율)	테스트 수 적정화로 실행 효율 양호, 대용량 데이터 I/O 시 비용 증가 가능	단위 수준 빠름, 고커버리지 달성 시 케이스 수 증가로 실행 시간 증가
확장성(스위트 규모)	요구사항 추가에 따라 케이스 선형 확장, 데이터 중심 병렬화 용이	코드 변경에 민감, 구조 복잡도 증가 시 케이스 기하급수적 증가
일관성(재현성)	환경/데이터 고정화 필요, 외부 의존성에 취약	모듈 격리·목킹으로 재현성 높음
안정성(플레이키 저항)	E2E·통합 구간에서 플레이키 위험 높음	단위 격리로 안정성 높음, 타이밍 이슈 낮음
운영 편의(자동화)	데이터 팩토리·피처 플래그 필요, 특정 도구 의존	커버리지·정적 분석 연동 용이, CI에 표준화 쉬움

두 방식은 대체 관계라기보다 서로 다른 공백을 메운다. 외부 요구사항과 사용자 흐름은 블랙박스로, 구현 내부의 분기와 경로는 화이트박스로 확인할 수 있다.

규칙과 경로를 검증하는 적용 장면

API 입력 검증에서는 경계값 기반 JSON 스키마 검증과 오류 코드·메시지 표준화가 필요하다. 권한과 상태의 조합은 의사결정 테이블로 정리해 80% 이상 시나리오를 커버할 수 있다.

결제 엔진에서는 국가, 통화, 카드 BIN, 금액대가 조건이 되고 수수료율과 승인 정책이 행동이 된다. 불가능한 조합을 제거하면 케이스를 60% 줄이면서 결함 재현성을 높일 수 있다.

데이터 파이프라인은 배치 루프의 0/1/N 회수와 역치 초과 시 롤백·재시도 경로를 함께 검증한다. 브랜치 커버리지 85% 달성과 처리 실패율 30% 감소를 목표로 둘 수 있다.

명세와 실행 코드 예시

서비스 버전 v1.4, 스테이징 DB 시드 완료를 전제로 한 테스트케이스 템플릿이다.

id: TC-AGE-BOUNDARY-001
item: 사용자_연령_검증_API
precondition:
  - "스테이징 사용자 존재"
  - "인증 토큰 유효"
input:
  endpoint: "/v1/users/validate-age"
  method: "POST"
  body: {"age": 18}
expected:
  status: 200
  body.contains: "valid": true
env:
  os: "Ubuntu 22.04"
  runtime: "Python 3.11"
dependencies:
  - "Auth Service v2.3"
  - "User DB seed v2024-10"
special_procedure:
  - "레이트리밋 우회 토큰 사용"

아래 코드는 Python 3.11과 pytest>=7.4를 전제로 경계값과 의사결정 테이블을 테스트한다.

# file: test_age.py
def is_valid_age(age: int) -> bool:
    return 18 <= age <= 65

import pytest

@pytest.mark.parametrize("age,expected", [
    (17, False), (18, True), (65, True), (66, False)  # 경계값±1 포함
])
def test_age_boundary(age, expected):
    assert is_valid_age(age) is expected

# 의사결정 테이블: (is_admin, is_active) -> can_access
@pytest.mark.parametrize("is_admin,is_active,expected", [
    (True, True, True),
    (True, False, True),
    (False, True, True),
    (False, False, False),
])
def test_access_decision(is_admin, is_active, expected):
    can_access = is_admin or is_active
    assert can_access is expected

실행: pytest -q

품질 지표와 자동화가 만드는 변화

요구사항 기반 테스트와 코드 경로 기반 테스트를 함께 적용하면 결함 발견률을 20~40%p 개선할 수 있다. 다만 결과는 도메인과 품질 성숙도에 따라 달라진다.

자동화 스위트를 구축하면 릴리스당 수동 테스트 시간을 30~60% 절감할 수 있다. 브랜치 커버리지 80% 이상과 중요 시나리오(E2E) 통과율 95% 이상을 목표로 삼고 지속적으로 추적하는 방식도 가능하다.

테스트케이스는 결함 제거를 위한 최소 단위이면서, 반복 가능한 검증의 기록이다. 입력과 규칙을 다루는 블랙박스 테스트, 구조와 경로를 다루는 화이트박스 테스트를 함께 운영하고, 경계값·의사결정·루프 설계를 표준화하면 커버리지와 실행 효율을 함께 관리할 수 있다.