diff --git a/docs/references/ai-testing/README.md b/docs/references/ai-testing/README.md new file mode 100644 index 0000000..111fab4 --- /dev/null +++ b/docs/references/ai-testing/README.md @@ -0,0 +1,12 @@ +# 레퍼런스: AI 기반 테스트 정책 (참고용) + +이 폴더의 문서는 참고용 레퍼런스입니다. 이 폴더에 있는 파일은 실개발(프로덕션) 환경에 자동으로 반영되거나 메인 브랜치에 병합되어 적용되지 않습니다. + +사용 안내: +- 본 문서들은 초안 또는 정책 검토용 참고 자료입니다. +- 실제 정책으로 채택하려면 검토(정책팀/보안팀), 승인(Human-in-the-loop) 및 관련 테스트 파이프라인 통합 절차를 반드시 완료해야 합니다. +- 임시 파일이나 실험적 스크립트가 포함될 수 있으며, 자동화 파이프라인에 포함하지 마십시오. + +경로: `docs/references/ai-testing/` + +작성일: 2026-07-02 diff --git a/docs/references/ai-testing/ai_testing_policy_draft.md b/docs/references/ai-testing/ai_testing_policy_draft.md new file mode 100644 index 0000000..0eeda78 --- /dev/null +++ b/docs/references/ai-testing/ai_testing_policy_draft.md @@ -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. 기술형 레드팀
(Jailbreaker)** | 시스템 프롬프트 우회 및 가드레일 무력화 | 가상화 레이어 명령 주입, Base64/입력 인코딩 우회, DAN(무제한 모드) 페르소나 주입 공격 | 우회 불가능한 시스템 역할 가드레일(System Role Guardrail) 작동 여부 | +| **2. 심리형 레드팀
(Social Engineer)** | 문맥 조작 및 감정적 우회 | 동정심 유발 시나리오(예: 할머니 동화책 이야기), 소설/역할극 빙자 유해 질문, 인지적 착시 유도 | 의미론적 경계 필터(Semantic Boundary Filters) 작동 및 윤리 정렬 점수 검증 | +| **3. 악성 데이터형 레드팀
(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) 파이프라인 트리거를 요청한다. diff --git a/docs/references/ai-testing/tdc114plus_test_strategy.md b/docs/references/ai-testing/tdc114plus_test_strategy.md new file mode 100644 index 0000000..040c610 --- /dev/null +++ b/docs/references/ai-testing/tdc114plus_test_strategy.md @@ -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/`에만 보관되며, 사용 전 최종 검토를 요청한다. diff --git a/docs/tdc114plus-script-automation-plan-2026-07-02.md b/docs/tdc114plus-script-automation-plan-2026-07-02.md new file mode 100644 index 0000000..3bcaf62 --- /dev/null +++ b/docs/tdc114plus-script-automation-plan-2026-07-02.md @@ -0,0 +1,93 @@ +# tdc114plus 테스트 자동화 스크립트 계획 + +작성일: 2026-07-02 +상태: v1.0 초기 스크립트 기준 + +목적: `docs/tdc114plus-testing-policy-2026-07-02.md`에 정의한 테스트 정책을 실제 `scripts/` 파일과 연결하고, 즉시 사용 가능한 스크립트와 향후 구현이 필요한 scaffold 스크립트를 구분한다. + +## 1. 즉시 사용 가능한 스크립트 + +| 스크립트 | 목적 | 실행 예 | +| --- | --- | --- | +| `scripts/format-dart.sh` | Docker Flutter 이미지에서 `dart format lib test` 실행 | `./scripts/format-dart.sh` | +| `scripts/quality-gate.sh` | `flutter analyze`, `flutter test` 순차 실행 | `./scripts/quality-gate.sh` | +| `scripts/generate-release-report.sh` | git 상태와 릴리스 체크리스트 report 생성 | `./scripts/generate-release-report.sh` | +| `scripts/perf_smoke.sh` | 현재 앱/테스트 파일 수와 기본 상태 출력 | `./scripts/perf_smoke.sh` | + +## 2. Scaffold 상태의 스크립트 + +아래 스크립트는 파일은 존재하지만, 기반 기능이 아직 없으므로 실행 시 scaffold 안내와 함께 종료한다. + +| 스크립트 | 현재 상태 | 완성 조건 | +| --- | --- | --- | +| `scripts/mock-server.sh` | `status`, `stop`은 가능. `start`는 미구현 안내 | API 계약 기반 mock server 구현 | +| `scripts/save-snapshots.sh` | snapshot source가 있으면 report 경로로 복사 | widget/integration screenshot 또는 snapshot 생성 체계 | +| `scripts/integration_tests.sh` | `TDC114_API_BASE`와 `integration_test/` 필요 | staging API 또는 mock server 기반 integration test | +| `scripts/redteam/run_all.sh` | 현재 AI 기능 없음 안내 | LLM/프롬프트 기반 기능이 실제 추가될 때 | + +## 3. Phase별 사용 기준 + +### Phase 3: Mock 기반 1차 UI + +필수: + +```bash +./scripts/format-dart.sh +./scripts/quality-gate.sh +``` + +선택: + +```bash +./scripts/save-snapshots.sh +``` + +단, snapshot 산출물이 생긴 뒤 사용한다. + +### Phase 4: 실제 API 연동 + +필수 후보: + +```bash +TDC114_API_BASE=https://staging.example.com ./scripts/integration_tests.sh +``` + +완성 조건: + +- `app/integration_test/` 테스트 추가 +- staging 또는 local mock API endpoint 확정 +- 민감정보 없는 test fixture 사용 + +### Phase 5: 핵심 액션 + +필수 후보: + +```bash +./scripts/quality-gate.sh +./scripts/perf_smoke.sh +``` + +추가 예정: + +- 전화걸기/문자보내기 URL 생성 테스트 +- 즐겨찾기 로컬 저장소 테스트 + +### Phase 6: 빌드/배포 준비 + +필수 후보: + +```bash +./scripts/generate-release-report.sh +``` + +추가 예정: + +- Android debug APK build wrapper +- 수동 검증 체크리스트 자동 생성 + +## 4. 운영 원칙 + +- 문서에 명령을 추가할 때는 실제 `scripts/` 파일도 함께 추가하거나 scaffold 상태를 명시한다. +- scaffold 스크립트는 조용히 성공하지 않고, 미구현이면 non-zero exit code로 종료한다. +- 실제 CI gate에 연결할 수 있는 스크립트는 `quality-gate.sh`부터 시작한다. +- AI/LLM redteam 자동화는 현재 앱 범위 밖이므로 `redteam/run_all.sh`는 보류 상태로 유지한다. diff --git a/docs/tdc114plus-testing-policy-2026-07-02.md b/docs/tdc114plus-testing-policy-2026-07-02.md index 2461680..2c377c0 100644 --- a/docs/tdc114plus-testing-policy-2026-07-02.md +++ b/docs/tdc114plus-testing-policy-2026-07-02.md @@ -39,15 +39,15 @@ Flutter 앱 코드를 변경한 모든 작업은 아래 검증을 통과해야 추가로 Dart 파일을 많이 수정했거나 새 파일을 추가한 경우 formatter를 적용한다. ```bash -docker run --rm -u 0:0 \ - -v /home/ubuntu/workspace/tdc114plus:/workspace \ - -w /workspace/app \ - ghcr.io/cirruslabs/flutter:stable \ - sh -lc "flutter pub get && dart format lib test && chown -R 1000:1000 /workspace/app" +./scripts/format-dart.sh ``` 검증 실패 상태의 코드는 `main` 브랜치에 반영하지 않는다. +자동화 스크립트의 구현 상태와 향후 보강 계획은 아래 문서를 따른다. + +- `docs/tdc114plus-script-automation-plan-2026-07-02.md` + ## 3. 테스트 강도 기준 ### 3.1 강한 테스트가 필요한 영역 @@ -245,6 +245,7 @@ Mock 데이터가 API 계약과 달라지는 경우 API 계약 문서를 먼저 - `docs/references/ai-testing/ai_testing_policy_draft.md` - `docs/references/ai-testing/tdc114plus_test_strategy.md` +- `docs/tdc114plus-script-automation-plan-2026-07-02.md` 본 문서는 위 참고문서보다 `tdc114plus` 개발에 우선 적용한다. diff --git a/docs/tdc114plus-work-progress-timetable-2026-07-02.md b/docs/tdc114plus-work-progress-timetable-2026-07-02.md index 4edef6e..de38457 100644 --- a/docs/tdc114plus-work-progress-timetable-2026-07-02.md +++ b/docs/tdc114plus-work-progress-timetable-2026-07-02.md @@ -47,12 +47,13 @@ | 13 | API 계약 검토 및 확정 | 완료 | API 계약 초안의 추가 확인사항 검토 후 1차 구현 기준 확정 | `docs/tdc114plus-api-contract-2026-07-02.md` | | 14 | 데이터 모델 설계 | 완료 | 직원, 조직, 가족사, 즐겨찾기 모델 정의 | Dart model 및 model test | | 15 | 테스트 정책 정식화 | 완료 | AI testing 참고 초안을 tdc114plus Flutter 앱/API/보안 중심 테스트 정책으로 재해석 | `docs/tdc114plus-testing-policy-2026-07-02.md` | -| 16 | Mock 데이터 기반 화면 확장 | 다음 작업 | 직원목록, 검색, 가족사 필터, 조직도 화면을 mock 데이터로 우선 구현 | 동작 가능한 UI | -| 17 | Baron SSO 로그인 연동 | 대기 | 전화번호 입력 후 SSO 등록 인원 여부 확인 연동 | 로그인 client/repository | -| 18 | orgFront 데이터 연동 | 대기 | 직원/조직 데이터 API 연동 | directory/organization client | -| 19 | 전화/문자 액션 구현 | 대기 | `url_launcher` 기반 전화걸기/문자보내기 구현 | 연락 액션 | -| 20 | 즐겨찾기 구현 | 대기 | 1차 로컬 저장 기반 즐겨찾기 구현 | favorites feature | -| 21 | Android APK 빌드 확인 | 대기 | debug APK 빌드 및 실행 확인 | APK 산출물 | +| 16 | 테스트 자동화 스크립트 초기 구성 | 완료 | 테스트 정책 기반 scripts 추가 및 scaffold 상태 문서화 | `scripts/*.sh`, `docs/tdc114plus-script-automation-plan-2026-07-02.md` | +| 17 | Mock 데이터 기반 화면 확장 | 다음 작업 | 직원목록, 검색, 가족사 필터, 조직도 화면을 mock 데이터로 우선 구현 | 동작 가능한 UI | +| 18 | Baron SSO 로그인 연동 | 대기 | 전화번호 입력 후 SSO 등록 인원 여부 확인 연동 | 로그인 client/repository | +| 19 | orgFront 데이터 연동 | 대기 | 직원/조직 데이터 API 연동 | directory/organization client | +| 20 | 전화/문자 액션 구현 | 대기 | `url_launcher` 기반 전화걸기/문자보내기 구현 | 연락 액션 | +| 21 | 즐겨찾기 구현 | 대기 | 1차 로컬 저장 기반 즐겨찾기 구현 | favorites feature | +| 22 | Android APK 빌드 확인 | 대기 | debug APK 빌드 및 실행 확인 | APK 산출물 | ## 3. 단계별 타임테이블 @@ -65,6 +66,7 @@ | Phase 2-2 | 완료 | API 계약 검토 및 확정 | token 종류, 전화번호 로그인 보안 수준, 개인정보 마스킹 범위, 즐겨찾기 동기화 여부 확인 | API 계약 확정본 | | Phase 2-3 | 완료 | Dart 데이터 모델 설계 | 확정된 API 계약 기준으로 직원, 조직, 로그인, 즐겨찾기 model 정의 | analyze/test 통과 | | Phase 2-4 | 완료 | 테스트 정책 정식화 | AI testing 참고 초안을 tdc114plus 적용 기준으로 정리 | `docs/tdc114plus-testing-policy-2026-07-02.md` | +| Phase 2-5 | 완료 | 테스트 자동화 스크립트 초기 구성 | 즉시 실행 가능한 quality/format/report 스크립트와 scaffold 스크립트 추가 | `docs/tdc114plus-script-automation-plan-2026-07-02.md` | | Phase 3 | 다음 | Mock 기반 1차 UI 완성 | 직원목록, 검색, 가족사 필터, 조직도, 상세 화면 구성 | API 없이 화면 흐름 확인 가능 | | Phase 4 | 이후 | 실제 API 연동 | SSO 로그인, orgFront 직원/조직 데이터 연동 | 등록 사용자 로그인 및 직원목록 조회 | | Phase 5 | 이후 | 핵심 액션 완성 | 전화걸기, 문자보내기, 즐겨찾기 저장 | 1차 기본 기능 수동 검증 | diff --git a/scripts/format-dart.sh b/scripts/format-dart.sh new file mode 100755 index 0000000..94a7a4e --- /dev/null +++ b/scripts/format-dart.sh @@ -0,0 +1,12 @@ +#!/usr/bin/env bash +set -euo pipefail + +ROOT_DIR="$(cd "$(dirname "$0")/.." && pwd)" +IMAGE="${FLUTTER_DOCKER_IMAGE:-ghcr.io/cirruslabs/flutter:stable}" + +docker run --rm \ + -u 0:0 \ + -v "$ROOT_DIR:/workspace" \ + -w /workspace/app \ + "$IMAGE" \ + sh -lc "flutter pub get && dart format lib test && chown -R 1000:1000 /workspace/app" diff --git a/scripts/generate-release-report.sh b/scripts/generate-release-report.sh new file mode 100755 index 0000000..4fcffd7 --- /dev/null +++ b/scripts/generate-release-report.sh @@ -0,0 +1,33 @@ +#!/usr/bin/env bash +set -euo pipefail + +ROOT_DIR="$(cd "$(dirname "$0")/.." && pwd)" +REPORT_DIR="${1:-$ROOT_DIR/reports/tdc114plus/$(date +%Y%m%d-%H%M%S)}" +REPORT_FILE="$REPORT_DIR/release-report.md" + +mkdir -p "$REPORT_DIR" + +{ + echo "# tdc114plus release report" + echo + echo "Generated at: $(date -u +%Y-%m-%dT%H:%M:%SZ)" + echo + echo "## Git" + echo + echo '```text' + git -C "$ROOT_DIR" status --short --branch + echo + git -C "$ROOT_DIR" log --oneline -n 10 + echo '```' + echo + echo "## Verification Checklist" + echo + echo "- [ ] ./scripts/format-dart.sh" + echo "- [ ] ./scripts/quality-gate.sh" + echo "- [ ] Android debug APK build" + echo "- [ ] Login/search/detail/favorites smoke test" + echo "- [ ] Token storage review" + echo "- [ ] Personal data exposure review" +} >"$REPORT_FILE" + +echo "generated release report: $REPORT_FILE" diff --git a/scripts/integration_tests.sh b/scripts/integration_tests.sh new file mode 100755 index 0000000..76f7829 --- /dev/null +++ b/scripts/integration_tests.sh @@ -0,0 +1,19 @@ +#!/usr/bin/env bash +set -euo pipefail + +ROOT_DIR="$(cd "$(dirname "$0")/.." && pwd)" +APP_DIR="$ROOT_DIR/app" + +if [ -z "${TDC114_API_BASE:-}" ]; then + echo "TDC114_API_BASE is required for integration tests." >&2 + echo "Example: TDC114_API_BASE=https://staging.example.com $0" >&2 + exit 64 +fi + +if [ ! -d "$APP_DIR/integration_test" ]; then + echo "integration test scaffold: $APP_DIR/integration_test does not exist yet." >&2 + echo "Add Flutter integration tests before enabling this script in CI." >&2 + exit 2 +fi + +"$ROOT_DIR/scripts/flutter-docker.sh" test integration_test diff --git a/scripts/mock-server.sh b/scripts/mock-server.sh new file mode 100755 index 0000000..64ce8ef --- /dev/null +++ b/scripts/mock-server.sh @@ -0,0 +1,32 @@ +#!/usr/bin/env bash +set -euo pipefail + +ROOT_DIR="$(cd "$(dirname "$0")/.." && pwd)" +PID_FILE="$ROOT_DIR/.tdc114plus-mock-server.pid" + +case "${1:-}" in + start) + echo "mock-server scaffold: no mock API server has been implemented yet." >&2 + echo "Expected future command: start a local API-compatible mock server." >&2 + exit 2 + ;; + stop) + if [ -f "$PID_FILE" ]; then + echo "mock-server scaffold: removing stale pid file $PID_FILE" + rm -f "$PID_FILE" + else + echo "mock-server scaffold: no running mock server pid file found." + fi + ;; + status) + if [ -f "$PID_FILE" ]; then + echo "mock-server scaffold: pid file exists at $PID_FILE" + else + echo "mock-server scaffold: not running." + fi + ;; + *) + echo "Usage: $0 {start|stop|status}" >&2 + exit 64 + ;; +esac diff --git a/scripts/perf_smoke.sh b/scripts/perf_smoke.sh new file mode 100755 index 0000000..ff4c75f --- /dev/null +++ b/scripts/perf_smoke.sh @@ -0,0 +1,16 @@ +#!/usr/bin/env bash +set -euo pipefail + +ROOT_DIR="$(cd "$(dirname "$0")/.." && pwd)" +APP_DIR="$ROOT_DIR/app" + +if [ ! -d "$APP_DIR" ]; then + echo "app directory does not exist: $APP_DIR" >&2 + exit 1 +fi + +echo "perf smoke scaffold" +echo "- app directory: $APP_DIR" +echo "- dart files: $(find "$APP_DIR/lib" -name '*.dart' | wc -l)" +echo "- test files: $(find "$APP_DIR/test" -name '*.dart' | wc -l)" +echo "No runtime performance probe is implemented yet." diff --git a/scripts/quality-gate.sh b/scripts/quality-gate.sh new file mode 100755 index 0000000..402c3b7 --- /dev/null +++ b/scripts/quality-gate.sh @@ -0,0 +1,7 @@ +#!/usr/bin/env bash +set -euo pipefail + +ROOT_DIR="$(cd "$(dirname "$0")/.." && pwd)" + +"$ROOT_DIR/scripts/flutter-docker.sh" analyze +"$ROOT_DIR/scripts/flutter-docker.sh" test diff --git a/scripts/redteam/run_all.sh b/scripts/redteam/run_all.sh new file mode 100755 index 0000000..0a0a7a7 --- /dev/null +++ b/scripts/redteam/run_all.sh @@ -0,0 +1,22 @@ +#!/usr/bin/env bash +set -euo pipefail + +PROFILE="all" + +for arg in "$@"; do + case "$arg" in + --profile=*) + PROFILE="${arg#--profile=}" + ;; + *) + echo "Unknown argument: $arg" >&2 + echo "Usage: $0 [--profile=jailbreaker|social_engineer|poisoner|all]" >&2 + exit 64 + ;; + esac +done + +echo "redteam scaffold: profile=$PROFILE" +echo "tdc114plus does not include LLM/AI inference in the current scope." +echo "This script is reserved for future AI features or prompt-based workflows." +exit 2 diff --git a/scripts/save-snapshots.sh b/scripts/save-snapshots.sh new file mode 100755 index 0000000..4f698da --- /dev/null +++ b/scripts/save-snapshots.sh @@ -0,0 +1,16 @@ +#!/usr/bin/env bash +set -euo pipefail + +ROOT_DIR="$(cd "$(dirname "$0")/.." && pwd)" +SOURCE_DIR="${1:-$ROOT_DIR/app/test/snapshots}" +TARGET_DIR="${2:-$ROOT_DIR/reports/snapshots/$(date +%Y%m%d-%H%M%S)}" + +if [ ! -d "$SOURCE_DIR" ]; then + echo "snapshot source directory does not exist: $SOURCE_DIR" >&2 + echo "Create widget/integration snapshot output first, then rerun this script." >&2 + exit 2 +fi + +mkdir -p "$TARGET_DIR" +cp -R "$SOURCE_DIR"/. "$TARGET_DIR"/ +echo "saved snapshots to $TARGET_DIR"