3.5 KiB
3.5 KiB
10. 테스트 계획
1. 원칙
- "될 것 같다"가 아니라 테스트 결과로 완료를 판단한다.
- 큰 테스트(부하, 장애 주입, E2E)를 돌리기 전에는 먼저 Gitea 저장소에 커밋·푸시하고 진행한다(사용자 요구사항). 결과는 커밋 해시와 함께 기록.
- 모든 PR/커밋 전:
bun run typecheck && bun run lint && bun test.
2. 테스트 종류
| 종류 | 도구 | 대상 | 언제 |
|---|---|---|---|
| 규칙 단위 | bun test |
packages/games/* |
매 커밋 |
| 무작위 대국/불변식 | bun test + engine/testing.ts |
모든 게임(시드 1,000개, CI에서는 200개) | 매 커밋 |
| 정보 유출 | 같은 도구 | 숨김 정보 게임 | 매 커밋 |
| 서버 통합 | bun test + 실제 WS 클라이언트 |
인증, 방 만들기/입장, 행동, 재접속, 강퇴, 한 판 더 | 매 커밋 |
| 복구 | 통합 테스트 | 서버 인스턴스 종료 → 같은 DB로 재시작 → 상태 동일 | 매 커밋 |
| E2E | Playwright(크로미움, PC 1440×900 기준 + 모바일 뷰포트 1개) | 게스트 시작 → 방 만들기 → 링크로 두 번째 사용자 입장 → 오목 한 판 끝까지 | 마일스톤마다 |
| 접근성 | axe-core(Playwright) | 주요 화면 | 마일스톤마다 |
| 성능 | Lighthouse(데스크톱 + 모바일) | 홈, 방 | 마일스톤마다, 예산 위반 시 실패 |
| 부하 | 자체 Bun 스크립트(가짜 클라이언트) | 동시 2,000 연결, 방 500개, 각 방 2초마다 행동 | 마일스톤 M2, M5, 출시 전 |
| 장애 주입 | 스크립트 | 게임 중 서버 강제 종료(SIGKILL), 네트워크 끊김, 느린 클라이언트 | 마일스톤 M2, 출시 전 |
3. 핵심 통합 시나리오 (M1에서 반드시 통과)
- 게스트 A가 방 생성 → 코드 6자리 수신 → B가 코드로 입장 → 자동 착석 → A 시작 → 오목 끝까지 → 결과 저장 확인.
- B가 링크로 입장(로그인 안 됨) → 닉네임 입력 → 자동 착석.
- 게임 중 B의 WS를 강제로 끊음 → A 화면에 "연결 끊김" → B 재연결 → 같은 상태·같은 차례 수신.
- 게임 중 서버 프로세스 SIGKILL → 재시작 → A, B 자동 재연결 → 수 이어서 두기 가능, 이전 수 모두 보존.
- B가 자기 차례가 아닐 때
act전송 →reject, 상태 변화 없음. - 같은
cs로 두 번 전송 → 한 번만 처리. - B가 다른 탭으로 접속 → 옛 탭
bye: replaced. - 턴 시간 초과 →
onTimeout행동 적용. - 방장이 나감 → 방장 자동 이전.
- 초당 100개 메시지 전송 → 제한 동작, 서버 정상.
- 잘못된 JSON / 스키마 위반 / 16KB 초과 메시지 → 오류 응답 또는 연결 종료, 서버 정상.
- 디스코드 로그인 콜백 state 불일치 → 거절.
4. 부하 테스트 합격 기준
- 동시 연결 2,000, 진행 중 방 500개, 초당 행동 250개에서:
- 행동 → 상대 수신 p95 < 50ms(같은 머신 기준), p99 < 100ms
- 서버 CPU < 70%(4코어 기준), 메모리 < 1GB
- 오류 0, 연결 끊김 0
- 결과는
docs/reports/load-YYYYMMDD.md에 커밋 해시와 함께 기록.
5. 수동 점검표 (마일스톤마다)
- 실제 휴대폰(안드로이드 Chrome, 아이폰 Safari)에서 링크로 들어와 한 판
- 글자 "아주 크게" 설정에서 모든 화면이 깨지지 않음
- 다크 모드
- 와이파이 → LTE 전환 중 게임 이어짐
- 화면 끄고 1분 뒤 켰을 때 자동 복귀
- 카카오톡으로 링크 공유 시 미리보기 표시