개념
레슨 3의 표를 "실행 가능한 모델"로
레슨 3에서 주문 상태 전이표를 손으로 그렸다. 상태가 몇 개 안 될 때는 사람이 표를 보고 어떤 전이를 테스트할지 직접 고르면 된다. 그런데 상태가 10개, 20개로 늘어나고 이벤트도 다양해지면, 사람이 "이 조합은 테스트했나?"를 손으로 추적하기 어려워진다.
**모델 기반 테스트(MBT)**는 이 상태 전이 다이어그램을 사람이 읽는 그림이 아니라, 도구가 읽고 순회할 수 있는 모델로 만든다. 도구가 모델 위의 모든 상태와 전이를 그래프처럼 훑으면서, 그 경로를 실행하는 테스트 케이스를 스스로 생성한다.
손으로 하는 것과 무엇이 다른가
| 레슨 3(수동 상태 전이 테스트) | 모델 기반 테스트 | |
|---|---|---|
| 모델을 그리는 사람 | 사람 | 사람 (여기까지는 같다) |
| 어떤 경로를 테스트할지 고르는 것 | 사람이 표를 보고 판단 | 도구가 모델을 순회하며 자동 생성 |
| 상태가 늘어났을 때 | 사람이 놓치는 조합이 생기기 쉬움 | 도구가 빠짐없이 순회(커버리지 전략에 따라) |
| 요구사항이 바뀌었을 때 | 테스트 케이스를 하나하나 다시 검토 | 모델만 고치면 테스트 케이스가 다시 생성됨 |
모델을 그리는 것까지는 사람의 일이다. MBT가 자동화하는 건 "그 모델에서 테스트 케이스를 뽑아내는" 그다음 단계다. 이 점에서 레슨 3이 이 기법의 전제 조건이다 — 상태 전이를 표로 그릴 줄 모르면 모델도 못 만든다.
커버리지 전략 — 얼마나 순회할 것인가
레슨 3에서 언급했던 0-switch(모든 상태를 한 번씩), 1-switch(모든 전이를 한 번씩)가 바로 모델을 순회하는 전략이다. 상태가 많아지면 가능한 경로의 수가 기하급수적으로 늘어나므로(모듈 1 레슨 5에서 배운 조합 폭발과 같은 문제), 모든 경로를 다 도는 대신 "모든 전이는 최소 한 번씩" 같은 현실적인 기준을 정한다.
상태 4개, 전이 6개짜리 모델이라면:
- 0-switch 전략: 상태 4개를 방문하는 최소 경로만 → 케이스 적음
- 1-switch 전략: 전이 6개를 각각 한 번씩 실행 → 케이스 더 많음,
더 촘촘한 커버리지어디에 강한가
MBT는 특히 상태가 명확하고, 전이 규칙이 자주 바뀌는 시스템에서 효과가 크다. 예를 들어 결제 상태 머신, 워크플로 승인 시스템, 게임의 캐릭터 상태 같은 경우다. 요구사항이 "취소 가능한 상태를 하나 추가"처럼 바뀌면, 모델 하나만 고치면 관련된 테스트 케이스가 다시 생성된다 — 사람이 관련된 테스트 케이스를 전부 찾아 하나하나 고치는 것보다 훨씬 안전하다.
한계 — 모델이 틀리면 테스트도 틀린다
MBT의 약점은 명확하다. 모델 자체가 실제 시스템과 다르면, 아무리 꼼꼼히 순회해도 잘못된 걸 테스트하게 된다. 이건 레슨 4~6(m18a)에서 배운 "AI가 생성한 테스트 케이스를 검증 없이 믿으면 안 된다"는 원칙과 근본적으로 같은 구조다 — 모델(또는 AI)이 만든 산출물은 그 입력이 되는 사람의 이해가 정확해야 결과도 정확하다. 모델을 최신 상태로 유지하는 것 자체가 별도의 유지보수 비용이라는 점도 기억해야 한다.
실무에서 왜 필요한가
상태가 많고 복잡한 시스템(결제, 예약, 승인 워크플로 등)에서는 "이 상태 조합, 테스트했었나?"를 사람이 스프레드시트로 추적하다가 빠뜨리는 일이 실무에서 흔하다. 모델 기반 테스트는 이 추적을 도구에 맡겨, 모델이 명확한 한 빠짐없는 커버리지를 보장한다. 다만 모든 곳에 쓸 도구는 아니다 — 상태가 단순하거나 자주 안 바뀌는 기능이라면, 레슨 3의 수동 방식이 도구를 도입하는 비용보다 오히려 더 실용적일 수 있다. QA는 "이 정도 규모의 상태 복잡도라면 모델링 비용을 들일 가치가 있는가"를 판단해야 한다.