Add test automation script scaffolds
This commit is contained in:
Codex
@@ -0,0 +1,12 @@
|
||||
# 레퍼런스: AI 기반 테스트 정책 (참고용)
|
||||
|
||||
이 폴더의 문서는 참고용 레퍼런스입니다. 이 폴더에 있는 파일은 실개발(프로덕션) 환경에 자동으로 반영되거나 메인 브랜치에 병합되어 적용되지 않습니다.
|
||||
|
||||
사용 안내:
|
||||
- 본 문서들은 초안 또는 정책 검토용 참고 자료입니다.
|
||||
- 실제 정책으로 채택하려면 검토(정책팀/보안팀), 승인(Human-in-the-loop) 및 관련 테스트 파이프라인 통합 절차를 반드시 완료해야 합니다.
|
||||
- 임시 파일이나 실험적 스크립트가 포함될 수 있으며, 자동화 파이프라인에 포함하지 마십시오.
|
||||
|
||||
경로: `docs/references/ai-testing/`
|
||||
|
||||
작성일: 2026-07-02
|
||||
@@ -0,0 +1,93 @@
|
||||
# [POLICY] AI 기반 시스템 개발 및 테스트 자동화 통합 규약 (Comprehensive AI Testing Policy)
|
||||
|
||||
* **문서 유형:** 개발 정책 및 CLI 참조 규약 (System Policy & Convention)
|
||||
* **적용 대상:** AI 파이프라인 소스코드, 모델 추론 레이어, LLM 기반 에이전트 워크플로우
|
||||
* **참조 경로:** `docs/references/ai-testing/ai_testing_policy_draft.md`
|
||||
* **최종 수정:** 2026. 07. 02
|
||||
|
||||
---
|
||||
|
||||
## 1. 목적 및 기본 준수 사항 (General Principles)
|
||||
|
||||
1. **확률적 출력 관리:** AI 모델의 출력은 결정론적이지 않고 확률에 기반하므로, 모든 테스트 스크립트는 단순 문자열 매칭을 지양하고 구조적 스키마 검증 및 AI 기반 자가 평가 방식을 채택한다.
|
||||
2. **CLI 강제성:** 본 문서에 정의된 정책 수치(커버리지, 성능 메트릭 등)를 만족하지 못하는 코드는 빌드(Build) 및 Main 브랜치로의 병합(Merge)을 전면 차단한다.
|
||||
3. **통합 검증 체계:** 기존 소프트웨어의 베이스라인 테스트, AI 특화 기능 테스트, 엔진 교차 검증, 3대 레드팀 적대적 공격 테스트를 하나의 파이프라인 안에서 유기적으로 수행한다.
|
||||
|
||||
---
|
||||
|
||||
## 2. 소스코드 및 베이스라인 규약 (Code & Baseline Convention)
|
||||
|
||||
### 2.1 정적 분석 및 코드 체크
|
||||
* 모든 PR(Pull Request) 및 커밋 시점에 CLI 기반의 정적 분석(Linting) 및 타입 검사(Type Checking)를 의무적으로 통과해야 한다.
|
||||
* AI 학습 파이프라인이나 데이터 전처리 스크립트 내의 문법 오류로 인한 자원 낭비를 방지하기 위해 빌드 프로세스 최우선 단계에서 정적 분석을 수행한다.
|
||||
|
||||
### 2.2 유닛 테스트 강도 정책 (Unit Test Intensity)
|
||||
AI 시스템의 컴포넌트는 성격에 따라 유닛 테스트의 합격 기준 및 강도를 이원화하여 적용한다.
|
||||
|
||||
* **결정론적 로직 영역 (High Intensity - 강도 높음):**
|
||||
* **대상:** 데이터 전처리, 전처리 가드레일 필터, API 라우팅, 데이터 변환 래퍼
|
||||
* **기준:** 테스트 통과율(Pass-rate) **100% 필수**이며 엄격하게 검증한다.
|
||||
* **확률론적 로직 영역 (Structural Validation - 구조적 검증):**
|
||||
* **대상:** AI 모델 추론(Inference) 함수 결과값, 프롬프트 템플릿 컴포저 출력
|
||||
* **기준:** 텍스트의 완전 일치 대신 다음 구조적 조건을 만족해야 함.
|
||||
* 출력 데이터의 JSON 스키마/키값 유효성 검증
|
||||
* 임베딩 벡터 차원(Shape)의 일치 여부 검증
|
||||
* 모델 출력 확률 값의 범위 검증 ($0 \\le p \\le 1$)
|
||||
|
||||
### 2.3 커버리지 테스트 기준 (Test Coverage)
|
||||
* **소스코드 라인 커버리지:** 일반 비즈니스 로직 및 데이터 전처리 코드는 최소 **80% 이상**의 라인 커버리지를 유지한다.
|
||||
* **시나리오 커버리지 (데이터셋 커버리지):** 단순히 코드 라인이 실행되었는가를 넘어, 사전에 준비된 사용자 의도(Intent) 데이터셋 및 극단적 엣지 케이스 시나리오 리스트의 최소 **90% 이상**을 테스트 스위트가 직접 경험하고 통과해야 한다.
|
||||
|
||||
---
|
||||
|
||||
## 3. 기능(Functional) 및 자율형 E2E 스냅샷 평가 규약 (E2E Snapshot Loop)
|
||||
|
||||
### 3.1 기능 테스트 (Functional Testing)
|
||||
* AI 시스템이 기획한 대로 제 기능을 수행하는지 비즈니스 요구사항 부합 여부를 검증한다. (예: 인사를 하면 인사를 받는지, 이미지 분류기가 카테고리를 올바르게 반환하는지 등)
|
||||
|
||||
### 3.2 스냅샷 저장 및 자율형 교정 루프 (Autonomous Correction Loop)
|
||||
생성형 AI 워크플로우의 엔드투엔드(E2E) 테스트 시, CLI는 사용자가 화면에서 요청하는 순간부터 AI를 거쳐 최종 화면이 뜰 때까지의 전체 과정을 통째로 테스트하되, 평가용 상위 AI(Evaluator LLM)를 활용한 자동 재시도 루프 정책을 적용한다.
|
||||
|
||||
1. **스냅샷 생성:** 타겟 AI 엔진이 출력한 최종 결과(텍스트, 이미지 등)를 `tests/snapshots/` 디렉토리에 버전별 스냅샷으로 저장한다.
|
||||
2. **평가용 AI 검증:** 별도의 검증용 AI(또는 상위 모델)가 사전에 정의된 평가 루브릭을 기준으로 스냅샷의 답변이 올바른지 자가 검증한다.
|
||||
3. **FAIL 처리 및 반복(Loop):** 평가 기준 미달 시, CLI는 프롬프트나 파라미터를 수정하여 올바른 결과가 나올 때까지 **최대 $N$회(기본값: 3회)** 자동으로 반복 수행한다.
|
||||
4. **최종 판정:** 최대 반복 후에도 FAIL인 경우, 해당 빌드는 실패로 처리되며 인간 개발자의 검토(Human-in-the-loop) 단계로 이관된다.
|
||||
|
||||
---
|
||||
|
||||
## 4. 멀티 AI 엔진 교차 검증 정책 (Multi-Engine Switch Policy)
|
||||
|
||||
특정 AI 파트너사의 모델에 대한 독점적 종속성(Lock-in)을 방지하고 시스템 마비 시 대체 가능성을 확보하기 위해, 모든 비즈니스 추론 기능은 다음 3가지 범주의 AI 엔진 종류별로 매트릭스 교차 테스트를 수행한다.
|
||||
|
||||
1. **상용 폐쇄형 엔진 (Commercial Closed-Source):** (예: GPT-4o, Claude 3.5 Sonnet) 최고 수준의 추론 성능 및 기본적인 방어 가드레일 한계선을 측정하는 기준으로 삼는다.
|
||||
2. **오픈소스형 엔진 (Open-Source Local/Self-Hosted):** (예: Llama 3, Mistral) 데이터 보안 준수 환경 및 비용 최적화 라우팅 환경 하에서 가드레일이 무너지지 않는지 검증한다.
|
||||
3. **도메인 특화 미세조정 엔진 (Internal Fine-Tuned):** 사내 자체 데이터로 학습된 전용 모델을 테스트하여 특정 도메인 내에서의 성능을 점검하고 환각 지표(Hallucination Index)를 모니터링한다.
|
||||
|
||||
---
|
||||
|
||||
## 5. 3대 프로필 레드팀 공격 규약 (Red Teaming Matrix Policy)
|
||||
|
||||
CLI 자동화 적대적 테스트셋은 AI 엔진의 보안 및 안정성을 허물기 위해 서로 다른 성향을 가진 다음 세 가지 공격 프로필을 무조건 포함하여 교차 검증을 실행해야 한다.
|
||||
|
||||
| 공격 프로필 분류 | 집중 검증 영역 | 공격 벡터 예시 | 방어 및 검증 체크포인트 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **1. 기술형 레드팀<br>(Jailbreaker)** | 시스템 프롬프트 우회 및 가드레일 무력화 | 가상화 레이어 명령 주입, Base64/입력 인코딩 우회, DAN(무제한 모드) 페르소나 주입 공격 | 우회 불가능한 시스템 역할 가드레일(System Role Guardrail) 작동 여부 |
|
||||
| **2. 심리형 레드팀<br>(Social Engineer)** | 문맥 조작 및 감정적 우회 | 동정심 유발 시나리오(예: 할머니 동화책 이야기), 소설/역할극 빙자 유해 질문, 인지적 착시 유도 | 의미론적 경계 필터(Semantic Boundary Filters) 작동 및 윤리 정렬 점수 검증 |
|
||||
| **3. 악성 데이터형 레드팀<br>(Poisoner)** | 시스템 견고성 및 오작동 유도 | 버퍼 오버플로우 유도용 초장문 텍스트 입력, 노이즈가 섞인 적대적(Adversarial) 데이터 주입 | 입력값 정제 레이어(Sanitization) 가동 및 안전한 에러 핸들링(Fallback) 여부 |
|
||||
|
||||
---
|
||||
|
||||
## 6. 품질 점수 및 데이터 모니터링 메트릭 (Metrics & Monitoring)
|
||||
|
||||
최종 배포 승인을 획득하기 위해 CLI는 테스트 완료 시점마다 아래 메트릭 계산식을 기반으로 한 결과 리포트를 의무적으로 생성해야 한다.
|
||||
|
||||
### 6.1 모델 수학적 성능 메트릭
|
||||
새로운 변경 사항이나 프롬프트가 적용된 AI 엔진은 검증 데이터셋에서 다음 메트릭의 최소 기준치(Baseline: 예: 0.85)를 초과해야 한다.
|
||||
|
||||
$$\text{Precision (정밀도)} = \frac{\text{True Positives}}{\text{True Positives} + \text{False Positives}}$$
|
||||
|
||||
$$\text{Recall (재현율)} = \frac{\text{True Positives}}{\text{True Positives} + \text{False Negatives}}$$
|
||||
|
||||
### 6.2 데이터 드리프트 감지 (Data Drift Monitoring)
|
||||
* 세상이 변하거나 트렌드가 바뀌어 발생하는 오작동을 막기 위해, CLI는 실제 운영 환경에서 수집된 입력 데이터와 모델 학습 데이터 간의 구조적 분포 차이를 **인구통계학적 안정도 지표(PSI, Population Stability Index)**를 통해 정기적으로 계산한다.
|
||||
* $\text{PSI} \ge 0.2$ 이상 검출 시, CLI는 '데이터 드리프트 경고(Warning)'를 발생시키고 AI 모델의 재학습(Retraining) 파이프라인 트리거를 요청한다.
|
||||
@@ -0,0 +1,256 @@
|
||||
# tdc114plus 테스트 단계별 전략 (참고용 초안)
|
||||
|
||||
* **문서 유형:** 테스트 전략 초안 (참고용)
|
||||
* **저장 경로:** `docs/references/ai-testing/tdc114plus_test_strategy.md`
|
||||
* **상태:** 참조 폴더 내 초안 — 사용 전 검토/승인 필요
|
||||
* **작성일:** 2026-07-02
|
||||
|
||||
---
|
||||
|
||||
## 목적
|
||||
|
||||
`tdc114plus` 개발 중에 적용할 테스트 단계, 진입/종료 조건, 실행 방법, 검증 포인트를 정의한다. 이 문서는 참조용 초안이며, 최종 확정 시 사용자 승인을 받아 참조 폴더 밖(프로덕션 정책 위치)으로 이동한다.
|
||||
|
||||
## 범위
|
||||
|
||||
- Flutter 앱 클라이언트: UI, 화면 흐름, 비즈니스 로직
|
||||
- AI/ML 관련 컴포넌트: 추론 함수, 프롬프트 템플릿, 결과 검증 루틴
|
||||
- 백엔드 연동: Baron SSO 로그인, orgFront 직원/조직 데이터 조회
|
||||
|
||||
---
|
||||
|
||||
## 개발 단계별 테스트 전략
|
||||
|
||||
`tdc114plus` 개발 진행은 다음 세 시기로 구분한다.
|
||||
|
||||
1. 초반(Initial phase)
|
||||
2. 중반(Mid phase)
|
||||
3. 후반(Late phase)
|
||||
|
||||
각 시기에 따라 테스트 우선순위와 적용 대상이 달라진다.
|
||||
|
||||
### 초반(Initial phase)
|
||||
|
||||
- 목표: 화면 흐름, 기본 기능, 코드 품질을 빠르게 검증하여 개발 기반을 마련한다.
|
||||
- 주요 활동:
|
||||
- Flutter 프로젝트 골격 확립
|
||||
- 로그인/직원검색/조직도 기본 화면 구성
|
||||
- Mock 데이터 기반 화면 흐름 검증
|
||||
- 적용 테스트:
|
||||
1. Static & CI Gate
|
||||
- `flutter analyze`, `dart format`, `flutter test --coverage`
|
||||
- 코드 스타일, 정적 분석, 기본 단위 테스트
|
||||
2. Unit & Component Tests
|
||||
- 화면 라우팅, 상태 전이, 데이터 변환
|
||||
- Mock 기반 ViewModel/Controller 동작 검증
|
||||
3. Mock-driven UI E2E
|
||||
- Mock API로 로그인→검색→조직도 시나리오 검증
|
||||
- 스냅샷 저장 및 회귀 검증
|
||||
- 개선 포인트:
|
||||
- 코드 품질 이슈 조기 발견
|
||||
- 초기 화면 플로우의 불일치 축소
|
||||
- Mock 데이터와 실제 API 계약 간 차이를 명확히 정의
|
||||
- 예시 명령:
|
||||
|
||||
```bash
|
||||
./scripts/flutter-docker.sh analyze
|
||||
flutter test --coverage
|
||||
genhtml coverage/lcov.info -o coverage/html
|
||||
```
|
||||
|
||||
### 중반(Mid phase)
|
||||
|
||||
- 목표: 외부 API 연동을 통합하고, 인증/권한/데이터 일관성 등을 검증한다.
|
||||
- 주요 활동:
|
||||
- Baron SSO 로그인 연동
|
||||
- orgFront 직원/조직 조회 로직 구현
|
||||
- 권한/마스킹/가족사 필터 검증
|
||||
- 적용 테스트:
|
||||
1. Integration Tests
|
||||
- Staging 또는 계약된 환경에서 API 연동
|
||||
- 로그인 세션, 직원 목록, 조직도 탐색 검증
|
||||
2. Unit & Component Tests
|
||||
- API 파싱, 재시도, 오류 처리, 보안 예외 로직
|
||||
3. Snapshot Loop 유지
|
||||
- Mock 데이터를 실 연동 API 형태로 업데이트
|
||||
- UI 회귀 스냅샷 재검증
|
||||
- 개선 포인트:
|
||||
- API 변경 영향 조기 검증
|
||||
- 인증/권한 경계 문제 발견
|
||||
- 데이터 포맷 불일치 최소화
|
||||
- 예시 명령:
|
||||
|
||||
```bash
|
||||
export TDC114_API_BASE=https://staging-api.example.com
|
||||
export TDC114_API_KEY=staging-key
|
||||
./scripts/integration_tests.sh
|
||||
```
|
||||
|
||||
### 후반(Late phase)
|
||||
|
||||
- 목표: 릴리스 준비 상태에서 성능, 보안, 적대적 대응, 회귀 검증을 완료한다.
|
||||
- 주요 활동:
|
||||
- 릴리스 후보 빌드
|
||||
- 레드팀/적대적 테스트
|
||||
- 성능 및 데이터 드리프트 점검
|
||||
- 적용 테스트:
|
||||
1. Adversarial / Red-team Automated Runs
|
||||
- Jailbreaker, Social Engineer, Poisoner 시나리오
|
||||
- 시스템 역할, 의미론적 필터, 차단/대체 동작 검증
|
||||
2. Release Gate & Performance Checks
|
||||
- APK 빌드, 메모리/CPU 스모크, 보안 스캔
|
||||
- PSI 기반 데이터 드리프트 감지
|
||||
3. Regression Snapshot Validation
|
||||
- 주요 화면 및 시나리오에 대한 스냅샷 재검증
|
||||
- 개선 포인트:
|
||||
- 릴리스 이전 회귀 위험 제거
|
||||
- 보안/안정성 취약점 보강
|
||||
- 실제 운영 수준 성능 파악
|
||||
- 예시 명령:
|
||||
|
||||
```bash
|
||||
flutter build apk --debug
|
||||
./scripts/perf_smoke.sh
|
||||
./scripts/redteam/run_all.sh --profile=jailbreaker
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 각 단계별 테스트 분류
|
||||
|
||||
| 테스트 유형 | 초반 | 중반 | 후반 |
|
||||
| --- | --- | --- | --- |
|
||||
| Static & CI Gate | 필수 | 필수 | 필수 |
|
||||
| Unit & Component Tests | 주력 | 유지 | 유지 |
|
||||
| Mock-driven UI E2E | 핵심 | 일부 유지 | 회귀 검증 |
|
||||
| Integration Tests | 준비 | 주력 | 유지/확장 |
|
||||
| Adversarial / Red-team Runs | 준비 | 준비 | 핵심 |
|
||||
| Release/Performance Checks | 없음 | 예비 | 주력 |
|
||||
|
||||
### 단계별 핵심 검증 포인트
|
||||
|
||||
- 초반: 화면 흐름, Mock 데이터 기반 상태 전환, 초기 코드 품질
|
||||
- 중반: 실제 API 연동, 인증 및 권한, 외부 오류 처리
|
||||
- 후반: 보안/레드팀 검증, 성능 안정성, 릴리스 체크리스트
|
||||
|
||||
### 초반 단계 상세 시나리오
|
||||
|
||||
- 로그인 화면 진입 및 입력 필드 유효성 검증
|
||||
- 입력된 전화번호가 형식에 맞지 않을 때 경고 메시지 표시
|
||||
- Mock 사용자 존재/미존재에 따른 로그인 성공/실패 플로우
|
||||
- 직원 검색 화면 진입 후 단어 검색, 결과 없음/결과 있음 케이스
|
||||
- 조직도 화면에서 노드 확장·축소, 팝업/상세 정보 표시
|
||||
- 즐겨찾기 토글 및 로컬 상태 저장 확인
|
||||
|
||||
### 중반 단계 상세 시나리오
|
||||
|
||||
- 실제 SSO 인증 실패 시 재시도 및 오류 메시지 표시
|
||||
- orgFront 직원 목록 중 특정 가족사 검색 시 필터 동작 확인
|
||||
- 조직도 건너뛰기 및 자회사/모회사 표시 일관성 검증
|
||||
- API 응답 구조 변경에 대한 파싱 예외 처리 확인
|
||||
- 네트워크 타임아웃/401/500 등 실패 케이스 대응 검증
|
||||
|
||||
### 후반 단계 상세 시나리오
|
||||
|
||||
- 릴리스 후보 APK 설치 후 주요 화면 진입 안정성 검증
|
||||
- Auth 세션 만료 후 재로그인 흐름 확인
|
||||
- 레드팀 공격 시나리오로 프롬프트 우회/입력 조작 시 방어 검증
|
||||
- 성능 기준에서 검색 응답 시간 및 UI 스크롤 부하 확인
|
||||
- 데이터 드리프트 지표(PSI) 계산에 필요한 로그 수집 경로 확인
|
||||
|
||||
### 자동화 스크립트 템플릿
|
||||
|
||||
아래 예시는 실제 스크립트 작성 시 템플릿으로 활용할 수 있는 구조이다.
|
||||
|
||||
#### 1. Static & CI Gate 스크립트
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
set -e
|
||||
|
||||
echo "[STATIC] Format check"
|
||||
./scripts/flutter-docker.sh format
|
||||
|
||||
echo "[STATIC] Analyze"
|
||||
./scripts/flutter-docker.sh analyze
|
||||
|
||||
echo "[STATIC] Unit tests with coverage"
|
||||
./scripts/flutter-docker.sh test --coverage
|
||||
|
||||
echo "[STATIC] Completed"
|
||||
```
|
||||
|
||||
#### 2. Mock-driven UI E2E 스크립트
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
set -e
|
||||
|
||||
echo "[MOCK E2E] Start mock server"
|
||||
./scripts/mock-server.sh start
|
||||
|
||||
echo "[MOCK E2E] Run UI automation"
|
||||
flutter drive --target=test_driver/app.dart
|
||||
|
||||
echo "[MOCK E2E] Save snapshot results"
|
||||
# snapshot 저장 스크립트 예시
|
||||
./scripts/save-snapshots.sh tests/snapshots/tdc114plus
|
||||
```
|
||||
|
||||
#### 3. Integration 테스트 실행 스크립트
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
set -e
|
||||
|
||||
export TDC114_API_BASE=${TDC114_API_BASE:-https://staging-api.example.com}
|
||||
export TDC114_API_KEY=${TDC114_API_KEY:?"TDC114_API_KEY required"}
|
||||
|
||||
echo "[INTEGRATION] Start integration tests"
|
||||
./scripts/integration_tests.sh
|
||||
```
|
||||
|
||||
#### 4. 레드팀 자동화 실행 스크립트
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
set -e
|
||||
|
||||
for profile in jailbreaker social_engineer poisoner; do
|
||||
echo "[REDTEAM] Running profile: $profile"
|
||||
./scripts/redteam/run_all.sh --profile="$profile"
|
||||
done
|
||||
```
|
||||
|
||||
#### 5. 릴리스 준비 스크립트
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
set -e
|
||||
|
||||
echo "[RELEASE] Build debug APK"
|
||||
flutter build apk --debug
|
||||
|
||||
echo "[RELEASE] Run performance smoke tests"
|
||||
./scripts/perf_smoke.sh
|
||||
|
||||
echo "[RELEASE] Generate release report"
|
||||
./scripts/generate-release-report.sh reports/tdc114plus/$(date +%Y%m%d)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 리포트 및 기록
|
||||
|
||||
- 자동화 실행 결과는 `reports/tdc114plus/YYYYMMDD/` 경로에 저장한다.
|
||||
- 저장 항목:
|
||||
- 테스트 커버리지 보고서
|
||||
- 실패 케이스 및 재현 정보
|
||||
- 레드팀 시나리오 결과
|
||||
- PSI/데이터 드리프트 계산 결과
|
||||
- 실패 이력은 Jira 또는 이슈 트래커로 자동 이관을 권장한다.
|
||||
|
||||
## 거버넌스
|
||||
|
||||
- 이 문서는 참조용 초안이며, 프로젝트 정책으로 채택하려면 정책팀/제품/보안 담당자의 승인 절차를 거쳐야 한다.
|
||||
- 승인 전까지 이 파일은 `docs/references/ai-testing/`에만 보관되며, 사용 전 최종 검토를 요청한다.
|
||||
Reference in New Issue
Block a user