baron-sso/docs/test-plan.md

테스트 계획 및 원칙 (Baron SSO)

1) 목적

• 인증/인가 핵심 플로우의 안정성과 회귀 방지
• 멀티 서비스(Backend/Ory Stack/Front) 연동 품질 확보
• 릴리즈 기준과 장애 분석 기준의 표준화

2) 범위

포함

• Backend (Go Fiber)
• UserFront (Flutter Web/App)
• AdminFront / DevFront (React)
• Ory Stack (Kratos/Hydra/Keto/Oathkeeper)
• Gateway/네트워크 구성 (baron_net, ory-net, public_net)
• DB (PostgreSQL, ClickHouse, Redis)

제외(별도 계획)

• 외부 IDP 벤더의 장애 대응 (Descope 등)
• 프로덕션 데이터 복구 시나리오(백업/DR)

3) 원칙

• Shift-left: 개발 단계에서 최대한 조기 검증
• 단계적 신뢰: Unit → Integration → E2E 순으로 신뢰도 상승
• 환경 분리: 로컬/스테이징/프로덕션 구성 차이를 문서로 명시
• 결정적 테스트: 시간/랜덤/외부 의존성 최소화
• Idempotent: 반복 실행 시 동일 결과 보장
• 보안 우선: 민감정보(PII/Token)는 테스트 로그에 노출 금지
• 실패 우선 기록: 실패 로그/재현 절차를 우선 확보

4) 테스트 레이어 및 목표

4.1 Unit Test

• Backend: 비즈니스 로직, 유효성 검증, Mapper/Adapter
• Frontend: 유틸/상태관리/컴포넌트 로직
• 목표: 빠른 피드백(수초~수분)

4.2 Integration Test

• Backend + DB(Postgres/ClickHouse/Redis)
• Backend + Ory Admin API (Kratos/Hydra/Keto)
• 목표: 네트워크/스토리지 연동 검증

4.3 Contract Test

• Backend ↔ Frontend API 스키마/응답 계약 검증
• OIDC/OpenID Connect 표준 응답 형식 검증

4.4 E2E Test (Happy/Edge Path)

• 로그인 플로우(Password / Magic Link / SMS / QR)
• Consent 플로우 (Hydra login/consent)
• 토큰 발급/재발급/로그아웃/세션 만료
• 목표: 핵심 사용자 여정의 회귀 방지

4.5 Smoke Test

• 배포 직후 필수 엔드포인트 헬스체크
• GET /health, Ory readiness, UserFront 정적 리소스

4.6 Regression / Non-functional

• 성능: 로그인/토큰 발급 지연, 대량 감사 로그 적재
• 보안: 인증 우회, 권한 상승, 세션 고정 공격
• 관측성: 핵심 로그/메트릭 누락 여부

5) 환경 전략

• 로컬: make up-all 또는 docker compose -f compose.infra.yaml -f compose.ory.yaml -f docker-compose.yaml up -d
• 스테이징: 프로덕션과 동일한 네트워크/도메인 구성
• 프로덕션: 최소한의 smoke/관측성 점검

6) 테스트 데이터 정책

• 표준 시드 사용자/테넌트/클라이언트 세트 정의
• PII 마스킹 규칙(이메일/전화번호/토큰)
• 재현용 고정 데이터와 랜덤 데이터 분리
• 테스트 종료 후 클린업 규칙 정의

7) 자동화 및 CI/CD 기준 (현행)

• 현재 상태: 레포에 CI/CD 워크플로우 정의가 없음. 테스트는 로컬/수동 실행 기준으로 운영.
• CI 변수 활용: AdminFront/DevFront Playwright 설정은 CI 환경 변수에 따라 재시도/워커 수를 조정함.
• 수동 실행 기준:
  • Backend: go test ./... (위치: backend/)
  • UserFront: flutter test (위치: userfront/)
  • AdminFront: npm test (Playwright, 위치: adminfront/, baseURL http://localhost:5173)
  • DevFront: npm test (Playwright, 위치: devfront/, baseURL http://localhost:5174)

7.1 수동 게이트 제안(현행 기준)

• PR/머지 전 최소 기준: Backend Unit + 해당 Front 테스트(변경 범위)
• 배포 전 최소 기준: Smoke + 핵심 E2E(로그인/Consent)

8) 핵심 플로우 테스트 시나리오

인증/세션

• Password 로그인 성공/실패/락/재시도
• Magic Link 발송/검증/만료
• SMS 코드 발송/검증/재시도 제한
• QR 승인/거절/타임아웃
• 로그아웃 시 세션/쿠키/토큰 무효화

원격 링크 로그인(verify-only)

• Desktop에서 링크 요청 → Mobile에서 링크 클릭(verifyOnly) → Desktop Poll로 세션 발급
• Mobile 단말에 세션 생성/로그인이 발생하지 않는지 확인
• Audit/로그인 이력에 Desktop 세션 ID만 기록되는지 확인
• 인증수단 표기(SMS/Email)가 요청 수단과 일치하는지 확인
• 코드/링크 만료 시 승인 실패 및 재요청 안내

OIDC/Hydra

• Login Challenge 처리
• Consent 승인/거절
• Token/Refresh Token 발급
• Redirect URI 검증

권한/정책(Keto)

• 권한 부여/회수 시 접근 제어 확인
• 관리자/일반 사용자 분리

네트워크/프록시

• baron_net와 ory-net 경계 준수
• Frontend에서 Ory 내부 Admin 포트 접근 불가

9) 관측성/장애 대응 테스트

• 에러 로그 구조(필수 필드 포함) 확인
• Audit Log 누락/중복 체크
• 실패 시 재시도 정책 검증

10) 책임 및 운영 프로세스

• 각 영역별 오너 지정(Backend/Front/Ory)
• 실패 시 triage 기준: 재현 가능 여부 → 영향도 → 우선순위
• 테스트 케이스/기대 결과는 이슈/PR에 링크

11) 유지보수 원칙

• 신규 기능은 반드시 관련 테스트 추가
• 회귀 버그 발생 시 재현 테스트를 우선 추가
• 불안정 테스트는 원인 분석 후 격리 또는 개선

12) 체크리스트 (릴리즈 전)

• Smoke 통과
• 핵심 E2E 통과
• 보안 관련 회귀 없음
• 장애/모니터링 대시보드 정상