Mission 2 API 테스트 시나리오 생성 실습 가이드
📥 실습 입력 (Input)
- •
day4_api_contract.md(DB 물리 스키마 정의서)
💾 실습 출력 (Output)
- •
edge-case-analysis.md(예외 시나리오 리포트)
1. 스토리 및 실습 배경
스타트업이 MVP 제품을 성공적으로 론칭한 첫날 밤, 예상치 못한 서버 알람이 울립니다. 똑같은 예약 시간대에 두 명의 사용자가 동시에 결제 버튼을 눌렀고, 결제는 둘 다 성공했는데 데이터베이스에는 마지막 결제자만 덮어쓰기되어 첫 번째 결제자의 예약 데이터가 날아가 버린 것입니다. (동시성 제어 예외 상황)
실전 서비스에서는 사용자의 비정상적인 입력, 잘못된 형식 전송, 필수 키 누락, 권한 없는 비인가 요청 등 수많은 예외 상황(Edge Cases)이 발생합니다. 이에 대응하는 API 테스트 시나리오를 미리 꼼꼼히 마련해두고 빌드하지 않으면 릴리즈 이후 실시간 모니터링 창에 적색 알람이 가득 차게 됩니다.
이번 미션에서는 완성된 API 스펙 계약서를 기반으로 정상 흐름은 물론 예외적인 조건과 경계값까지 모두 검증하는 API 테스트 시나리오를 자동 작성하여, 오류 없는 안정적인 서비스를 방어하는 능력을 키웁니다.
2. 학습 목표
- 정의된 테이블 스키마와 외래키 참조 구조에서 논리적 설계 결함을 감지할 수 있다.
- 동시성 쓰기, TC-API-RES-002 / 필수 필드 누락 붕괴, 트랜잭션 롤백 실패 등 Edge Case 시나리오를 도출할 수 있다.
- Hard Delete 탈퇴를 방어하는 Soft Delete(논리 삭제) 등 대처 방안을 마련할 수 있다.
🛠️ 실제 따라 하기 실습 가이드
- 실습용 파일 생성: 아래 다운로드 버튼을 눌러
day4_api_contract.md파일을 다운로드하여automation/폴더 내에 저장합니다. - Codex 검증 위임: Codex Client 프롬프트 입력창에 아래 **Codex 요청 프롬프트**를 전송하여 빌드합니다.
- 대처 설계 확인: 도출된 리포트에서 중복 예약 방지책(분산 락/Unique 제약) 및 Soft Delete 논리식별값 설계 등 구체적인 DB 개선책이 수립되었는지 검토합니다.
실습 자료 다운로드
Codex 요청 프롬프트
Mission 02 Prompt
현재 정의된 예약 및 결제 API 명세를 기반으로, 정상 등록 흐름(Happy Path)과 필수 파라미터 누락, 날짜 형식 오류, 한도 초과 및 권한 만료 등의 예외 케이스를 모두 포함하는 API 테스트 시나리오 및 검증 체크리스트를 작성해 주세요.
4. 결과물 예시
Codex는 스키마 논리를 화이트박스로 해부하여 아래와 같은 치명적 예외 시나리오를 도출합니다.
| 시나리오 ID / 항목 | 전제 조건 및 테스트 절차 (Edge Case) | 시스템 영향도 | 기대 동작 (Expected) |
|---|---|---|---|
| TC-API-RES-001 / 예약 생성 정상 | 동일 상담 시간대에 두 사용자가 동시에 예약 결제를 진행해 둘 다 성공 판정이 나서 중복 매핑되는 현상 | 치명적 | DB 예약 테이블에 복합 UNIQUE 제약조건 생성 또는 Redis 분산 락 적용 |
| TC-API-RES-002 / 필수 필드 누락 | 결제 이력이 있는 User 레코드를 Hard Delete 처리해 외래키 관계가 끊겨 일일 매출 정산 통계 쿼리가 깨지는 현상 | 치명적 | is_deleted 컬럼 및 탈퇴 시간을 기록하는 Soft Delete(논리 삭제) 테이블 설계 변경 |
| TC-API-RES-003 / 날짜 형식 오류 | 외부 PG 결제 승인은 성공했으나 우리 DB 인서트 단계에서 네트워크 장애로 롤백되어 결제 기록이 공중 분해되는 현상 | 보통 | 결제 트랜잭션을 분산 트랜잭션(Saga Pattern)으로 묶고, 결제 미확정 건 배치 검증 스크립트 가동 |