테스트 설계 기법이란 테스트 케이스를 효율적으로 설계하기 위한 체계적인 방법입니다. 모든 입력값이나 조건을 테스트하는 것은 현실적이지 않기 때문에 버그를 발견하기 쉬운 대표적인 패턴을 선별하여 테스트합니다.
대표적인 기법에는 다음이 있습니다.
- 동등 분할
- 경계값 분석
- 디시전 테이블 테스트
- 상태 전이 테스트
테스트의 목적과 대상 시스템의 특성에 따라 적절히 사용 구분하는 것이 중요합니다.
📌 이런 분께 추천합니다
- 테스트 설계 기법의 전체상을 파악하고 싶은 QA 엔지니어·개발자
- 어떤 기법을 어떤 장면에서 사용하면 좋은지 정리하고 싶은 분
- ISTQB·테스트 자격증 학습에 활용하고 싶은 분
- 자동 테스트의 테스트 케이스 설계를 더 체계적으로 하고 싶은 분
✅ 이 글을 읽으면 얻을 수 있는 것
- 7가지 테스트 설계 기법의 특징·용도·사용 구분을 알 수 있다
- 장면에 따라 최적의 기법을 선택할 수 있게 된다
- 각 기법의 상세 해설 글 링크로 깊이 있게 공부할 수 있다
👤 이 글을 쓴 사람
QA 엔지니어·테스트 자동화 엔지니어로서 15년 이상의 실무 경험을 가진 Yoshi가 집필. 테스트 설계 기법은 실제 프로젝트에서 매일 사용하는 지식입니다. 구현 코드는 GitHub에 공개 중입니다: github.com/YOSHITSUGU728/automated-testing-portfolio
「테스트 케이스가 너무 많아 관리할 수 없다」「어디까지 테스트하면 충분한지 모르겠다」——이런 고민을 해결하는 것이 테스트 설계 기법입니다. 이 글에서는 QA 엔지니어가 실무에서 사용하는 7가지 주요 기법을 비교 일람표·각 기법의 상세·사용 구분의 기준까지 한 번에 해설합니다.
📌 결론
- 테스트 설계 기법은 「무엇을 테스트하는가」가 아니라 「어떻게 효율적으로 버그를 찾는가」의 접근법
- 7가지 기법은 각각 잘하는 장면이 다르며 조합해서 사용하는 것이 실무의 기본
- 먼저 동등 분할·경계값 분석을 습득하고 시스템 특성에 따라 다른 기법을 더해가는 것이 최단 루트
- 테스트 설계 기법 7선 비교 일람표
- ① 동등 분할（Equivalence Partitioning）이란
- ② 경계값 분석（Boundary Value Analysis）이란
- ③ 디시전 테이블 테스트（Decision Table Testing）란
- ④ 상태 전이 테스트（State Transition Testing）란
- ⑤ 유스케이스 테스트（Use Case Testing）란
- ⑥ 페어와이즈 테스트（Pairwise Testing）란
- ⑦ 에러 추측（Error Guessing）이란
- 기법의 도입 순서와 사용 구분
- FAQ：테스트 설계 기법에 대한 자주 묻는 질문
- 📋 이 글의 정리
테스트 설계 기법 7선 비교 일람표
| 기법명 | 잘하는 장면 | 난이도 | 자동화와의 궁합 | 자주 사용하는 장면 |
|---|---|---|---|---|
| ① 동등 분할 | 입력값 범위·종류 검증 | ⭐ 초급 | ◎ parametrize | 입력 유효성 검증 |
| ② 경계값 분석 | 범위의 끝·Off-by-one 에러 | ⭐ 초급 | ◎ parametrize | 숫자 범위 체크 |
| ③ 디시전 테이블 | 복수 조건의 조합 | ⭐⭐ 중급 | ○ parametrize | 권한 관리·업무 로직 |
| ④ 상태 전이 테스트 | 상태를 가진 시스템·플로우 | ⭐⭐ 중급 | ◎ E2E 테스트 | 로그인 / EC 카트 |
| ⑤ 유스케이스 테스트 | 사용자 조작 플로우 전체 | ⭐⭐ 중급 | ◎ E2E 테스트 | 구매 플로우·회원 가입 |
| ⑥ 페어와이즈 테스트 | 다수 조합의 효율화 | ⭐⭐⭐ 상급 | ○ parametrize | OS / 브라우저 조합 |
| ⑦ 에러 추측 | 경험칙·버그 패턴 활용 | ⭐⭐⭐ 상급 | △ 경험 의존 | NULL / 특수 문자 / 경계 보완 |
① 동등 분할（Equivalence Partitioning）이란
목적
- 같은 동작을 하는 입력값을 그룹화하여 테스트 수를 줄인다
- 유효·무효 양쪽 클래스를 망라한다
- 「대표값 1개로 충분하다」는 사고방식으로 테스트를 효율화한다
입력값을 「같은 동작을 하는 그룹（동등 클래스）」으로 분할하고 각 그룹에서 대표값을 1개만 선택하여 테스트하는 기법입니다. 나이·문자 수·숫자 범위 등 「범위 조건」이 있는 필드에 특히 유효합니다.
✅ 적합한 케이스
| ⚠️ 적합하지 않은 케이스
|
② 경계값 분석（Boundary Value Analysis）이란
목적
- 각 동등 클래스의 경계（끝）의 값을 중점적으로 테스트한다
- Off-by-one 에러（
>=와>의 혼동 등）를 발견한다 - 동등 분할과 조합하여 버그 검출률을 높인다
버그는 경계 부근에서 가장 많이 발생한다는 것이 통계적으로 밝혀져 있습니다. 기본 접근법은 3점법：각 클래스 경계에 대해 경계값 자체·경계값 -1·경계값 +1을 테스트합니다.
✅ 적합한 케이스
| ⚠️ 적합하지 않은 케이스
|
parametrize를 사용하면 경계값 테이블을 그대로 코드로 변환할 수 있습니다.③ 디시전 테이블 테스트（Decision Table Testing）란
목적
- 복수 조건의 모든 조합을 빠짐없이 정리한다
- 조합 폭발（조건 2개×값 2개=4패턴 등）을 시각적으로 관리한다
- 업무 규칙·권한 관리 등 복잡한 로직의 검증에 사용한다
복수의 조건이 얽힌 시스템에서는 조건의 조합이 빠짐없이 테스트되고 있는지 확인하기 어렵습니다. 디시전 테이블은 「조건」과 「액션（기대 결과）」을 표 형식으로 정리하여 조합의 망라성을 담보합니다.
디시전 테이블 예시（로그인 처리）
| 조건 / 액션 | 케이스1 | 케이스2 | 케이스3 | 케이스4 |
|---|---|---|---|---|
| ID가 올바른가 | ✅ Yes | ✅ Yes | ❌ No | ❌ No |
| 비밀번호가 올바른가 | ✅ Yes | ❌ No | ✅ Yes | ❌ No |
| → 로그인 성공 | ✅ | ❌ | ❌ | ❌ |
✅ 적합한 케이스
| ⚠️ 적합하지 않은 케이스
|
④ 상태 전이 테스트（State Transition Testing）란
목적
- 시스템의 「상태」와 「전이 조건」을 정리하여 테스트 케이스를 설계한다
- 상태 전이가 올바르게 이루어지는지·무효 전이가 올바르게 거부되는지를 확인한다
- EC 카트·로그인 플로우·주문 상태 등 상태를 가진 시스템에 유효
시스템은 「로그아웃 중」→「로그인 중」→「카트 추가 완료」처럼 상태를 가집니다. 상태 전이 테스트는 이 상태의 흐름을 도표나 표로 정리하여 「모든 정상 전이」와 「무효 전이」 양쪽을 테스트합니다.
상태 전이 예시（EC 사이트 주문 상태）
| 현재 상태 | 이벤트（조작） | 다음 상태 | 확인 포인트 |
|---|---|---|---|
| 카트 미추가 | 상품 추가 | 카트 추가 완료 | 카트 배지가 표시되는가 |
| 카트 추가 완료 | 구매 확정 | 주문 확정 | 확인 메일이 전송되는가 |
| 주문 확정 | 취소 신청 | 취소 완료 | 재고가 복구되는가 |
| 취소 완료 | 재취소（무효） | 취소 완료（변화 없음） | 에러 또는 무시되는가 |
✅ 적합한 케이스
| ⚠️ 적합하지 않은 케이스
|
⑤ 유스케이스 테스트（Use Case Testing）란
목적
- 사용자의 일련의 조작 플로우（유스케이스）를 테스트 시나리오로 변환한다
- 기본 플로우（정상계）와 대체 플로우（이상계·예외계）를 망라한다
- E2E 테스트의 시나리오 설계에 직결되는 기법
유스케이스 테스트는 「사용자가 목표를 달성하기까지의 조작 흐름」을 테스트 케이스로 설계합니다. 「상품을 구매한다」는 유스케이스라면 로그인→상품 선택→카트 추가→결제→완료 확인이라는 일련의 플로우를 테스트합니다.
✅ 적합한 케이스
| ⚠️ 적합하지 않은 케이스
|
⑥ 페어와이즈 테스트（Pairwise Testing）란
목적
- 다수의 파라미터 조합을 최소 테스트 수로 망라한다
- 「임의의 2개 파라미터 조합이 최소 1번은 테스트된다」는 것을 보증한다
- 전체 조합 테스트에 비해 테스트 수를 대폭 줄일 수 있다
파라미터가 3개×3값=27가지，4개×3값=81가지로 폭발하는 조합 테스트를 페어와이즈 기법을 사용하면 9〜12건 정도로 줄일 수 있습니다. 대부분의 버그는 2개 파라미터의 상호 작용에서 발생한다는 연구에 기반한 기법입니다.
✅ 적합한 케이스
| ⚠️ 적합하지 않은 케이스
|
allpairspy（Python）등의 도구로 자동 생성할 수 있습니다. 생성한 파라미터 세트를 pytest의 parametrize에 전달하면 그대로 자동 테스트가 됩니다.⑦ 에러 추측（Error Guessing）이란
목적
- 과거 경험·버그 패턴을 바탕으로 「버그가 나올 것 같은 값」을 직관적으로 테스트한다
- 다른 기법으로는 찾기 어려운 「경험적으로 위험한」케이스를 보완한다
- QA 엔지니어의 직감과 지식을 체계적으로 활용한다
에러 추측은 테스트 기법 중 유일하게 「경험과 직감」에 기반한 기법입니다. 「0이나 음수는 위험하다」「NULL·빈 문자열은 함정이다」「SQL 인젝션 문자열」「매우 긴 문자열」등 과거 경험에서 「버그가 발생하기 쉬운 값」을 적극적으로 테스트합니다.
자주 사용되는 에러 추측 값
| 카테고리 | 구체적인 값의 예 |
|---|---|
| 숫자계 | 0，-1，최대값+1，소수，정수 오버플로우 값 |
| 문자열계 | 빈 문자열，공백만，매우 긴 문자열（1000자 이상），전각·반각 혼재 |
| 특수 문자계 | 싱글 쿼트，세미콜론（SQL 인젝션），<script>（XSS） |
| NULL·미입력계 | NULL 값，undefined，빈 배열，미선택 상태 |
✅ 적합한 케이스
| ⚠️ 적합하지 않은 케이스
|
기법의 도입 순서와 사용 구분
7가지 기법을 어떤 순서로 배우고 어떻게 사용 구분할지를 정리합니다.
| 스텝 | 기법 | 사용하는 장면 |
|---|---|---|
| STEP 1 | 동등 분할 → 경계값 분석 | 입력값 검증·폼 유효성 검증（가장 먼저 습득） |
| STEP 2 | 디시전 테이블 | 업무 로직·권한 관리의 조건 조합 |
| STEP 3 | 상태 전이 테스트 → 유스케이스 테스트 | E2E 테스트·플로우 전체 검증 |
| STEP 4 | 페어와이즈 테스트 | 다수 파라미터 조합 최적화 |
| 항상 병용 | 에러 추측 | 다른 기법을 보완하는 경험적 테스트 추가 |
📖 관련 글
FAQ：테스트 설계 기법에 대한 자주 묻는 질문
Q. 테스트 설계 기법은 모두 외워야 하나요？
아니오. 먼저 동등 분할과 경계값 분석을 이해하는 것만으로 실무의 많은 케이스에 대응할 수 있습니다. 이 두 가지를 마스터한 후 테스트 대상의 복잡성에 따라 디시전 테이블·상태 전이 테스트를 더해가는 것이 현실적인 습득 순서입니다.
Q. 자동 테스트에도 테스트 설계 기법이 필요한가요？
필요합니다. 오히려 자동 테스트와 궁합이 좋은 기법이 많습니다. pytest의 @pytest.mark.parametrize는 동등 분할·경계값 분석과 매우 궁합이 좋아 설계한 표를 그대로 코드로 변환할 수 있습니다. 테스트 설계 없이 자동 테스트만 늘려도 중요한 부분을 놓친 채 「테스트가 있다」는 안심감만 생겨버립니다.
Q. ISTQB에서 중요한 기법은 무엇인가요？
ISTQB（Foundation Level）에서는 동등 분할·경계값 분석·디시전 테이블·상태 전이 테스트가 특히 중요합니다. 이 4가지는 시험의 빈출 주제이며 실무에서도 가장 사용 빈도가 높은 기법입니다. 먼저 이 4가지를 우선적으로 학습하는 것을 추천합니다.
Q. 복수의 기법을 조합하여 사용해도 되나요？
오히려 조합하는 것이 실무의 표준입니다. 예를 들어 「동등 분할로 그룹을 정의 → 경계값 분석으로 경계를 테스트 → 에러 추측으로 경험적으로 위험한 값을 추가」라는 흐름이 전형적입니다. 1가지 기법만으로 완결시키려 하면 누락이 생깁니다. 목적에 따라 복수를 조합하는 편이 망라성과 효율의 균형이 잡힙니다.
📋 이 글의 정리
- 동등 분할·경계값 분석：입력값 검증의 기본. 가장 먼저 습득해야 할 2가지 기법
- 디시전 테이블：복수 조건의 조합을 빠짐없이 정리하는 기법
- 상태 전이 테스트：상태를 가진 시스템의 플로우 검증에 최적
- 유스케이스 테스트：E2E 테스트 시나리오 설계에 직결되는 기법
- 페어와이즈 테스트：다수 파라미터의 조합 폭발을 효율적으로 해소
- 에러 추측：경험칙으로 다른 기법을 보완하는 마무리
테스트 설계 기법은 「모두 항상 사용하는」것이 아니라 「테스트 대상의 특성에 따라 최적의 기법을 선택하는」것입니다. 먼저 동등 분할·경계값 분석을 마스터하고 시스템의 복잡성에 따라 디시전 테이블·상태 전이 테스트를 더해가는 것이 실무에서의 최단 루트입니다.
