forked from baron/baron-sso
133 lines
5.3 KiB
Markdown
133 lines
5.3 KiB
Markdown
# 테스트 계획 및 원칙 (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 통과
|
|
- 보안 관련 회귀 없음
|
|
- 장애/모니터링 대시보드 정상
|