‘테스트 시나리오’와 ‘테스트 케이스’는 같은 의미인 것처럼 사용되곤 합니다. 하지만 그렇지 않습니다. 이 둘을 혼동하면 테스트 계획이 너무 모호해서 실행할 수 없거나, 너무 자세해서 읽기 어려워질 수 있습니다. 하나는 무엇을 테스트할지 설명하고, 다른 하나는 정확히 어떻게 테스트할지 설명합니다. 이 관계를 올바르게 이해하면 테스트 커버리지를 감사하고 실행 가능하게 만들 수 있습니다.
이 가이드는 각 용어를 정의하고, 차이점을 나란히 비교하며, Apidog를 사용한 실제 API 테스트 워크플로에서 이 둘이 어떻게 함께 작동하는지 보여줍니다.
테스트 시나리오란 무엇인가요?
테스트 시나리오는 테스트할 가치가 있는 것에 대한 고수준의 설명입니다. 정확한 단계, 입력 또는 예상 값을 지정하지 않고 동작이나 조건을 명시합니다.
제목이라고 생각해보세요. 예를 들어, 전자상거래 결제의 경우 시나리오는 다음과 같을 수 있습니다:
- 저장된 카드를 사용하는 등록된 사용자의 결제 확인
- 게스트 사용자(비회원)의 결제 확인
- 구매 도중 품절된 상품에 대한 결제 확인
- 결제 거부 시 결제 확인
각 항목은 무엇을 검증해야 하는지, 그리고 왜 비즈니스에 중요한지를 알려줍니다. 그 어느 것도 호출할 엔드포인트나 보낼 페이로드를 알려주지 않습니다. 시나리오는 사용자 또는 요구사항 관점에서 작성되므로 제품 관리자와 엔지니어 모두에게 읽기 쉽습니다.
시나리오는 한 가지 질문에 답합니다: 우리는 작동해야 할 모든 것을 고려했는가? 이것들은 커버리지 맵입니다. 시나리오가 누락되면 아무리 상세한 테스트 케이스라도 그 공백을 채울 수 없습니다.
테스트 케이스란 무엇인가요?
테스트 케이스는 시나리오 아래에 위치하는 구체적이고 실행 가능한 점검 항목입니다. 정확한 입력, 사전 조건, 동작 및 예상 결과를 충분한 정밀도로 지정하여 두 사람이 실행해도 동일한 결과를 얻을 수 있도록 합니다.
“게스트 사용자의 결제 확인” 시나리오를 예로 들어봅시다. 이는 다음과 같은 케이스로 나눌 수 있습니다:
POST /orders에 유효한 게스트 페이로드로 호출 시201및order_id반환- 배송 주소 없이
POST /orders호출 시400및validation_error반환 - 품절된 SKU로
POST /orders호출 시409및error: out_of_stock반환
각 케이스는 엔드포인트, 본문, 예상 상태 및 예상 응답 필드를 명시합니다. 이는 자동화하기에 충분히 구체적입니다. 케이스의 필드별 전체 구조를 원하시면 API 테스트 케이스 작성 방법에서 템플릿을 자세히 다루고 있으며, 테스트 케이스 대 테스트 스크립트에서는 실행 가능한 코드가 어디에 적합한지 명확히 설명합니다.
테스트 케이스의 결정적인 특징은 정밀도입니다. “결제가 작동한다”는 기껏해야 시나리오의 일부입니다. “유효한 게스트 주문을 POST하고, 비어 있지 않은 order_id와 함께 201을 예상한다”는 테스트 케이스입니다.
주요 차이점
두 개념은 여러 면에서 다릅니다. 다음 표는 요약본입니다.
| 차원 | 테스트 시나리오 | 테스트 케이스 |
|---|---|---|
| 수준 | 고수준, 무엇을 테스트할지 | 저수준, 어떻게 테스트할지 |
| 세부사항 | 간략함, 한 줄 | 데이터를 포함한 단계별 지침 |
| 초점 | 비즈니스 또는 기능 목표 | 기술적 실행 |
| 입력 | 지정되지 않음 | 정확한 페이로드 및 매개변수 |
| 예상 결과 | 암시적 | 정확하게 명시됨 (상태, 본문, 시간) |
| 대상 | 제품, QA, 엔지니어링 | 테스터 및 자동화 도구 |
| 개수 | 기능당 소수 | 시나리오당 다수 |
| 생성 시점 | 테스트 계획 중 | 시나리오 합의 후 |
이 관계는 계층적입니다. 하나의 시나리오는 여러 케이스를 생성합니다. 시나리오는 커버리지의 폭을 제어하고, 케이스는 깊이와 엄격함을 제어합니다. 흔히 발생하는 실패 방식은 시나리오 맵 없이 수십 개의 상세 케이스를 작성하는 것인데, 이는 해당 기능이 완전히 커버되었는지 아니면 특정 부분만 집중적으로 테스트되었는지 알 수 없게 만듭니다.
다른 관점에서 보면, 시나리오는 “커버됨” 또는 “커버되지 않음”으로 표시될 수 있습니다. 테스트 케이스는 오직 “통과” 또는 “실패”로만 표시될 수 있습니다. 품질을 관리하려면 두 가지 상태 모두 필요합니다.
시나리오와 케이스가 함께 작동하는 방법
실용적인 워크플로는 다섯 단계로 광범위한 것에서 구체적인 것으로 진행됩니다.
- 1. 요구사항에서 시나리오 식별. 사양 또는 API 문서를 읽고, 예상치 못한 경로를 포함하여 검증할 가치가 있는 모든 동작을 나열합니다. 이 단계에서 누락된 커버리지가 발견되므로, 충분한 시간을 할애해야 합니다.
- 2. 각 시나리오의 목표 정의. "완료"의 의미를 명시합니다. "게스트 결제 확인"의 목표는 게스트가 주문을 하고 확인을 받는 동시에, 유효하지 않은 주문은 깔끔하게 거부되는 것입니다.
- 3. 각 시나리오 아래에 테스트 케이스 작성. 각 시나리오를 입력과 예상 결과를 포함하는 구체적인 케이스로 확장합니다. 성공 경로, 모든 유효성 검사 실패 및 관련 경계 조건을 다룹니다.
- 4. 완전성 검토. 트리를 다시 살펴보세요. 모든 시나리오에 최소한 하나의 성공 경로 케이스와 하나의 부정 케이스가 있습니까? 문서화된 모든 상태 코드가 예상 결과에 나타납니까? 여기서 발견되는 공백은 저렴하지만, 프로덕션에서 발견되는 공백은 그렇지 않습니다.
- 5. 결과 실행 및 추적. 케이스를 실행하고, 케이스별 통과 및 실패를 기록하며, 결과를 시나리오 수준으로 집계하여 이해관계자들이 단순히 초록색 체크 표시의 개수가 아닌 커버리지를 볼 수 있도록 합니다.
행동 기반 팀의 경우, 시나리오는 Gherkin의 Given-When-Then 형식에 자연스럽게 매핑됩니다. BDD API 테스트를 위한 Gherkin 가이드는 이러한 구조가 시나리오를 실행 가능하게 유지하면서도 가독성을 높이는 방법을 보여줍니다.
예제: 시나리오에서 케이스로
메모 앱의 API를 예로 들어보겠습니다. 테스트할 가치가 있는 단일 동작은 사용자가 메모를 생성할 수 있다는 것입니다. 이것이 시나리오입니다.
시나리오: 사용자는 메모를 생성할 수 있다. 한 줄입니다. 테스트 계획에 속하며 누구든지 읽을 수 있습니다. 엔드포인트, 페이로드 또는 상태 코드를 언급하지 않으며, 그래서도 안 됩니다.
이제 이를 케이스로 확장해 봅시다. 각 케이스는 정확한 입력과 정확한 예상 결과를 가진 하나의 실행 가능한 점검 항목입니다.
- 케이스 1, 성공 경로.
{"title": "Groceries", "body": "milk, eggs"}페이로드와 유효한 토큰으로POST /notes를 호출합니다. 예상 결과:201, 비어 있지 않은id,title이Groceries와 같고created_at타임스탬프를 포함하는 응답 본문. 응답 시간은 600ms 미만. - 케이스 2, 필수 필드 누락.
{"body": "milk, eggs"}페이로드와 유효한 토큰으로POST /notes를 호출합니다. 예상 결과:400,error가validation_error와 같고,title필드를 명시하는details. - 케이스 3, 인증되지 않음. 유효한 본문과 토큰 없이
POST /notes를 호출합니다. 예상 결과:401, 응답에id없음. - 케이스 4, 과도한 페이로드. 2MB 크기의
body로POST /notes를 호출합니다. 예상 결과:413및 명확한 오류 메시지.
하나의 시나리오, 네 개의 케이스. 시나리오는 무엇을 알려주었고, 케이스는 어떤 테스터나 자동화된 실행기라도 동일한 결과를 산출할 수 있을 만큼 충분한 정밀도로 어떻게 알려주었습니다. 나중에 “사용자가 메모에 파일을 첨부할 수 있다”는 기능을 추가하면, 이는 새로운 시나리오가 되며 자체적인 케이스 세트를 생성합니다. 계획은 평평한 검사 더미가 되는 대신 구조화되고 감사 가능한 방식으로 성장합니다.
Apidog에서 시나리오와 케이스 구축
Apidog는 이 계층 구조를 직접 모델링하므로, 테스트 계획의 구조가 도구의 구조와 일치합니다.
Apidog의 **테스트 시나리오**는 자체 어설션을 가진 API 요청의 정렬된 시퀀스입니다. 시각적으로 구축합니다: 동작에 관련된 엔드포인트를 추가하고, 한 요청의 출력이 다음 요청으로 전달되도록 연결하며(로그인은 토큰을 반환하고, 다음 요청은 이를 사용합니다), 각 단계에 어설션을 설정합니다.
각 요청과 어설션 블록은 실질적으로 **테스트 케이스**입니다. 스크립트를 작성할 필요 없이 클릭만으로 상태 코드, 응답 본문 필드, 스키마 준수 및 응답 시간을 어설션할 수 있습니다. 데이터 기반 테스트는 하나의 케이스를 CSV 또는 JSON 파일의 여러 입력 행에 대해 실행할 수 있게 하여, 단일 부정 케이스가 모든 유효하지 않은 조합을 다룰 수 있도록 합니다.
시나리오는 전체 API에 걸쳐 조직적이고 반복 가능한 실행을 위해 테스트 스위트로 그룹화됩니다. 스위트는 로컬에서, 스케줄에 따라, 또는 CI 내에서 실행할 수 있으며, Apidog는 케이스 수준과 시나리오 수준 모두에서 결과를 보여주는 보고서를 생성합니다. 이러한 이중 보기는 보상입니다: 엔지니어는 어떤 케이스가 실패했는지 확인하고, 리더는 어떤 시나리오가 현재 위험에 처해 있는지 확인합니다.
첫 번째 시나리오를 구축하고 케이스-시나리오 집계를 실제로 확인하려면 Apidog를 다운로드하세요.
둘 다 필요한 이유 (하나만 필요한 것이 아님)
팀은 때때로 한 레이어를 건너뛰려고 합니다. 시나리오를 건너뛰고 케이스만 작성하면 커버리지 맵이 없는 길고 평평한 목록이 생성됩니다. 모든 케이스를 다시 읽지 않고서는 “게스트 결제를 완전히 테스트했습니까?”라고 답할 수 없습니다. 케이스를 건너뛰고 시나리오만 유지하면 누구도 일관되게 실행할 수 없는 계획이 생성됩니다. 왜냐하면 “결제 확인”은 각 테스터에게 다르게 해석될 수 있기 때문입니다.
두 레이어는 또한 다른 독자에게 봉사합니다. 제품 관리자는 올바른 것이 테스트되고 있는지 확인하기 위해 시나리오를 읽습니다. 자동화 엔지니어는 실행기를 구축하기 위해 케이스를 읽습니다. 통과된 케이스만 보여주는 테스트 보고서는 리더십에게 커버리지에 대해 아무것도 알려주지 않습니다. 케이스를 시나리오로 집계한 보고서는 어떤 기능이 출시해도 안전한지 정확히 알려줍니다.
시나리오는 안정적으로 유지하고 케이스는 최신 상태로 유지하세요. 시나리오는 기능의 의도가 변경될 때만 변경됩니다. 케이스는 API 계약이 변경될 때마다 변경됩니다. 이들을 별도의 수명 주기를 가진 별도의 아티팩트로 취급할 때, 테스트 계획은 정확하고 유지 관리가 용이해집니다.
자주 묻는 질문
테스트 시나리오는 테스트 스위트와 같은가요? 아닙니다. 시나리오는 테스트할 동작을 설명합니다. 스위트는 실행을 위해 그룹화된 실행 가능한 테스트 모음입니다. 스위트는 여러 시나리오의 케이스를 포함할 수 있습니다. 테스트 스위트 대 테스트 케이스를 참조하세요.
하나의 시나리오에는 몇 개의 테스트 케이스가 있어야 하나요? 성공 경로와 시나리오가 암시하는 모든 실패 모드를 커버하기에 충분해야 합니다. 간단한 시나리오는 서너 개의 케이스가 필요할 수 있으며, 복잡한 시나리오는 더 많은 케이스가 필요합니다.
시나리오와 케이스는 누가 작성하나요? 시나리오는 의도를 담고 있으므로 종종 제품 팀과 QA가 함께 초안을 작성합니다. 케이스는 기술적 세부 사항을 담고 있으므로 주로 QA 또는 개발자가 작성합니다. 테스트 케이스 명세 형식은 케이스 작성을 일관성 있게 유지하는 데 도움이 됩니다.
테스트가 자동화되어 있다면 시나리오가 필요한가요? 네. 자동화는 케이스를 실행하지만, 시나리오는 올바른 케이스가 존재하는지 여전히 답합니다. 커버리지 맵 없는 자동화는 그저 더 빨리 실패할 뿐입니다.