소프트웨어 테스트 설계 기법과 테스트 케이스 도출 방법

제한된 테스트 자원에서 케이스를 고르는 일

모든 입력과 실행 경로를 전부 시험하는 일은 현실적으로 어렵다. 테스트 설계 기법은 시간, 인력, 비용이 제한된 조건에서 결함을 발견할 가능성이 큰 테스트 케이스를 체계적으로 고르는 방법이다.

접근 방식은 요구사항과 명세를 출발점으로 삼는 명세 기반 기법, 프로그램 내부 구조를 살피는 구조 기반 기법, 테스터의 경험과 직관을 활용하는 경험 기반 기법으로 나뉜다.

⤢✕

요구사항에서 테스트 조건을 찾는 방법

명세 기반 테스트는 내부 구현을 보지 않고 요구사항과 외부 동작을 기준으로 케이스를 만든다. 사용자 입력, 업무 규칙, 상태 변화, 사용자 시나리오가 주요 재료가 된다.

동등 분할로 대표 입력을 고르기

동등 분할은 같은 방식으로 처리될 것으로 보는 입력 값을 유효 그룹과 무효 그룹으로 나누고, 각 그룹의 대표값을 선택하는 방법이다. 같은 그룹의 값은 유사한 결함을 찾을 가능성이 높다는 전제를 둔다.

예를 들어 1100 사이의 정수를 받는 시스템이라면 유효 분할은 1100이고 대표값은 50이 될 수 있다. 무효 분할은 0 이하와 101 이상이며, 각각 0, -10, 101, 1000 같은 값을 선택할 수 있다.

경계 주변을 우선 확인하기

경계값 분석은 동등 분할의 경계 근처에서 오류가 나기 쉽다는 경험을 활용한다. 1~100 사이의 정수 입력을 검증한다면 0, 1, 2, 99, 100, 101을 테스트 값으로 둔다.

입력 범위 자체가 중요한 기능에서 특히 유용하다. 금액 한도나 이체 횟수처럼 허용 범위의 시작과 끝이 명확한 경우에 적용할 수 있다.

조건 조합이 많은 규칙은 표로 드러낸다

결정 테이블 테스트는 여러 조건과 그 결과의 조합을 표로 정리해 테스트 케이스를 만드는 기법이다. 복잡한 비즈니스 규칙이나 조건별 행동이 달라지는 기능에 맞는다.

대출 승인 시스템은 다음처럼 정리할 수 있다.

| 조건/결과 | 케이스1 | 케이스2 | 케이스3 | 케이스4 |
|----------|---------|---------|---------|---------|
| 신용점수 > 700 | T | T | F | F |
| 부채비율 < 30% | T | F | T | F |
|----------|---------|---------|---------|---------|
| 대출 승인 | T | F | F | F |
| 이자율 인하 | T | F | F | F |

상태가 바뀌는 시스템을 검증하는 관점

상태 전이 테스트는 입력이나 이벤트에 따라 시스템 상태가 이동하는 경우에 사용한다. 상태 기계로 모델링할 수 있는 시스템에서 모든 전이가 의도대로 수행되는지를 확인하는 것이 목적이다.

⤢✕

사용자 흐름을 따라가는 유스케이스 테스트

유스케이스 테스트는 사용자와 시스템의 상호작용 시나리오에서 케이스를 도출한다. 사용자 관점에서 중요한 기능을 검증할 수 있다는 점이 특징이다.

기본 흐름뿐 아니라 대안 흐름과 예외 흐름도 함께 다뤄야 한다. 의료 시스템이라면 의사, 간호사, 환자의 시나리오가 이 기법의 입력이 될 수 있다.

내부 실행 경로를 기준으로 설계하는 테스트

구조 기반 테스트는 소프트웨어 내부 구조를 기준으로 한다. 코드가 실행되는 범위와 분기 결과, 조건 조합을 확인하는 데 초점을 맞춘다.

문장 실행 범위를 보는 구문 커버리지

구문 커버리지는 프로그램의 모든 문장이 적어도 한 번 실행되도록 케이스를 설계한다. 측정 방법은 (실행된 문장 수 / 전체 문장 수) × 100%다.

다만 모든 문장을 실행했다고 해서 모든 제어 흐름이 검증되는 것은 아니다.

분기의 결과를 확인하는 결정 커버리지

결정 커버리지는 if, switch 같은 모든 분기문에서 가능한 결과가 적어도 한 번씩 실행되도록 설계한다. 측정 방법은 (실행된 결정 결과 수 / 전체 결정 결과 수) × 100%다.

if(a && b)라면 true와 false 결과가 모두 나오도록 테스트한다.

조건 자체를 나눠 보는 조건 커버리지

조건 커버리지는 결정 지점에 포함된 각 조건이 true와 false 값을 모두 갖도록 확인한다. if(a && b)에서는 a와 b 각각의 true/false 조합을 테스트한다.

개별 조건을 확인할 수 있지만, 가능한 조합 전체를 커버하지는 못한다.

가능한 조합 전체를 다루는 다중 조건 커버리지

다중 조건 커버리지는 하나의 결정에 있는 조건들의 가능한 조합을 모두 테스트한다. if(a && b)라면 (T,T), (T,F), (F,T), (F,F)를 모두 다룬다.

가장 철저한 검증을 제공하지만 조건 수가 늘어나면 테스트 케이스도 기하급수적으로 증가한다.

경험을 테스트 탐색에 쓰는 방식

명세와 코드만으로 찾기 어려운 결함도 있다. 경험 기반 테스트는 테스터가 과거의 사례와 도메인 지식을 활용해 테스트 대상을 찾는다.

탐색적 테스트는 사전에 고정된 테스트 케이스 없이, 학습과 설계, 실행을 동시에 수행한다. 요구사항이 부족하거나 시간 제약이 있을 때 효과적이다.

오류 추정은 결함이 생기기 쉬운 부분을 경험으로 짚어 테스트하는 방법이다. 0 입력, 매우 큰 값, 특수문자 포함, 동시 사용자 접속 등이 일반적인 오류 후보가 될 수 있다.

체크리스트 기반 테스트는 프로젝트 경험이나 도메인 지식으로 점검 목록을 만들어 수행한다. 반복 테스트와 회귀 테스트에서 중요한 항목의 누락을 막는 데 쓸 수 있다.

시스템 특성과 테스트 레벨에 맞춰 조합하기

리스크가 높은 영역에는 다중 조건 커버리지나 결정 테이블처럼 더 엄격한 기법을 적용할 수 있다. 리스크가 낮은 영역은 동등 분할이나 구문 커버리지 같은 기본 기법으로 다룰 수 있다.

상태 기반 시스템에는 상태 전이 테스트가, 복잡한 비즈니스 로직에는 결정 테이블 테스트가, 입력 값 범위가 핵심인 기능에는 경계값 분석이 어울린다.

테스트 레벨도 선택 기준이다. 단위 테스트에서는 구조 기반 기법이 효과적이고, 통합 테스트에서는 인터페이스에 초점을 둔 명세 기반 기법을 활용할 수 있다. 시스템 테스트는 명세 기반 기법과 경험 기반 기법을 조합하며, 인수 테스트에는 유스케이스 테스트와 탐색적 테스트를 적용한다.

금융과 의료 시스템에서의 적용 관점

금융 시스템에서는 다양한 금융 규칙 조합을 결정 테이블로 검증할 수 있다. 금액 한도와 이체 횟수 제한에는 경계값 분석을 적용하며, 무작위 입력과 SQL 인젝션 시도 등 보안 테스트도 필요하다.

⤢✕

의료 시스템에서는 환자 생체 데이터 입력 범위에 동등 분할과 경계값 분석을 적용할 수 있다. 진단 알고리즘과 약물 상호작용 규칙은 결정 테이블로, 의사·간호사·환자의 업무 흐름은 유스케이스 테스트로 다룰 수 있다.

설계 기법을 운영에 연결할 때

테스트를 시작하기 전에 무엇을 검증할지 분명히 정해야 한다. 단위, 통합, 시스템, 인수 테스트의 수준에 맞는 기법을 선택하고, 단일 기법에 의존하기보다 여러 방법을 조합한다.

어떤 기법이 많은 결함을 발견했는지 데이터를 수집하고 분석해 다음 테스트 설계에 반영할 필요도 있다. 반복 테스트에는 자동화 방안을 함께 검토한다.