xst
e34a3c64ce
知识库更新: - historical_defects.md: +4条数据上报领域真实缺陷模式 (阶段依赖链断裂/重试幂等/跨模块数据不一致/省份代码硬编码) - common_missed_scenes.md: +11条数据上报专项易漏场景 (多阶段依赖/第三方核验逐项/重试并发/跨模块一致性/省份隔离等) - data_reporting_cases.md: 新增数据上报类需求优秀用例范式 (8大覆盖框架+5条示例用例+7项关键风险点) - terminology.md: +14条数据上报领域术语 系统修复: - case_pipeline.py: 注册 data_reporting_cases.md + order_manage_cases.md - governance_audit.py: 更新 case_generate/AGENTS 关键词期望(旧→新架构) - AGENTS.md/README.md/.claude: 补全缺失关键词，治理审计通过 - .claude/skills/case_generate/: 创建向后兼容别名 skill
151 lines
5.6 KiB
Markdown
151 lines
5.6 KiB
Markdown
# Agentic QE Fleet
|
||
|
||
当用户在 Codex CLI 中输入以下任一意图时，必须按一条端到端流水线自动执行，不要把中间命令再抛给用户手动运行：
|
||
|
||
- `/qe-fleet run <需求文档>`
|
||
- `/qe-fleet prepare <需求文档>`
|
||
- `/qe-fleet analyze <需求文档>`
|
||
- `/qe-fleet design <需求文档>`
|
||
- `/qe-fleet review <需求文档>`
|
||
- `/qe-fleet export <需求文档>`
|
||
- `/qe-fleet monitor <需求文档> --results <测试结果>`
|
||
- `/qe-fleet status <需求文档>`
|
||
- `/case_generate <需求文档>`（向后兼容别名）
|
||
- "基于某个需求文档生成测试分析、测试点、测试用例"
|
||
- "导出测试用例 Excel"
|
||
|
||
## /qe-fleet run 自动执行规则
|
||
|
||
当用户输入 `/qe-fleet run <需求文档>` 时，必须立即完成以下动作：
|
||
|
||
1. 解析目标需求文档路径，提取 `BASE_NAME`
|
||
2. 自动执行：
|
||
|
||
```bash
|
||
python3 scripts/fleet_runner.py run --requirement <需求文档路径>
|
||
```
|
||
|
||
3. fleet_runner.py 自动按战区顺序编排 17 个专业 Agent：
|
||
|
||
**PREPARE 战区 (2 Agent):**
|
||
- document-parser: 文档解析标准化
|
||
- knowledge-activator: 知识激活
|
||
|
||
**ANALYZE 战区 (3 Agent):**
|
||
- requirement-analyzer: 需求分析
|
||
- conflict-detector: 冲突检测
|
||
- risk-assessor: 风险评估
|
||
|
||
**DESIGN 战区 (4 Agent):**
|
||
- test-strategist: 测试策略
|
||
- testpoint-designer: 测试点设计
|
||
- case-designer: 用例设计
|
||
- data-builder: 测试数据构造
|
||
|
||
**EXECUTE 战区 (3 Agent):**
|
||
- web-executor: PC Web Playwright 自动化执行 + 截图
|
||
- mobile-executor: 移动端 Appium 自动化执行 + 截图
|
||
- result-reporter: AI 视觉对比 + 测试结论报告
|
||
|
||
**REVIEW 战区 (3 Agent):**
|
||
- case-reviewer: 用例评审
|
||
- coverage-auditor: 覆盖率审计
|
||
- quality-gatekeeper: 质量门禁裁决
|
||
|
||
**MONITOR 战区 (2 Agent):**
|
||
- execution-analyst: 执行结果分析
|
||
- knowledge-curator: 知识沉淀
|
||
|
||
4. 若 manifest 中 `confirmation_gate.required=true` 且 `decision_status` 不是 `confirmed`：
|
||
- 不要继续执行后续战区
|
||
- 直接告诉用户当前卡在"人工确认"阶段
|
||
- 告知关联与冲突文件路径与 `suggested_decision_file`
|
||
- 明确说明：确认单需要写出 `确认状态：已确认` 后才能继续
|
||
|
||
5. 若确认门禁已通过，继续执行后续战区
|
||
|
||
6. 质量裁决通过 (PASS/PASS_WITH_FIX) 后自动执行 Excel 导出
|
||
|
||
7. 最终回复时直接告诉用户：
|
||
- 各战区状态（✅ 完成 / ⏳ 进行中 / ⬜ 待执行）
|
||
- 分析、测试点、测试用例、Excel、风险报告、评审报告、覆盖率审计、质量裁决的实际路径
|
||
- 质量裁决结果
|
||
- 若失败，失败在哪一步
|
||
|
||
## 子命令自动执行
|
||
|
||
### /qe-fleet prepare
|
||
```bash
|
||
python3 scripts/fleet_runner.py prepare --requirement <需求文档路径>
|
||
```
|
||
|
||
### /qe-fleet analyze
|
||
```bash
|
||
python3 scripts/fleet_runner.py analyze --requirement <需求文档路径>
|
||
```
|
||
|
||
### /qe-fleet design
|
||
```bash
|
||
python3 scripts/fleet_runner.py design --requirement <需求文档路径>
|
||
```
|
||
|
||
### /qe-fleet review
|
||
```bash
|
||
python3 scripts/fleet_runner.py review --requirement <需求文档路径>
|
||
```
|
||
|
||
### /qe-fleet export
|
||
```bash
|
||
python3 scripts/fleet_runner.py export --requirement <需求文档路径>
|
||
```
|
||
|
||
### /qe-fleet monitor
|
||
```bash
|
||
python3 scripts/fleet_runner.py monitor --requirement <需求文档路径> --results <测试结果文件>
|
||
```
|
||
|
||
### /qe-fleet status
|
||
```bash
|
||
python3 scripts/fleet_runner.py status --requirement <需求文档路径>
|
||
```
|
||
|
||
若用户已经补完确认单，并明确要求"继续""确认后续跑""按确认结论重跑"，优先执行：
|
||
|
||
```bash
|
||
python3 scripts/case_pipeline.py apply-confirmation --requirement <需求文档路径>
|
||
```
|
||
|
||
## 约束
|
||
|
||
- 除非脚本执行失败，否则不要要求用户再手动执行命令
|
||
- 若本次改动涉及以下任一范围，必须在结束前执行 `python3 scripts/governance_audit.py auto`，并根据结果同步修正 `AGENTS.md`、`.claude/`、`README.md`、`docs/` 的滞后内容：
|
||
- `scripts/`
|
||
- `.claude/`
|
||
- `agents/`
|
||
- `knowledge_base/01_standards/`
|
||
- `AGENTS.md`
|
||
- `README.md`
|
||
- `fleet_config.yml`
|
||
- 若只是 `requirements/`、`knowledge_base/02_history/`、`knowledge_base/03_best_practices/`、`output/` 下的普通内容更新，不要触发这项治理审计
|
||
- 所有测试用例必须使用 `knowledge_base/01_standards/test_case_template.md` 中定义的唯一表头
|
||
- 不允许同时维护 `draft_cases.md`、`final_cases.md`
|
||
- 最终结果始终覆盖写回 `output/test_cases/{BASE_NAME}_测试用例.md`
|
||
- 分析阶段必须识别关联需求并给出冲突修订建议
|
||
- 冲突建议不得停留在抽象描述，必须写清问题、影响范围、建议修订方向
|
||
- 测试点/测试用例必须体现 `knowledge_base/00_project/project_profile.md` 的项目差异化约束
|
||
- 若主输入是 `.docx/.doc/.pdf`，必须使用 prepare 产出的标准化 Markdown 文件，即 `normalized_requirement_file`
|
||
- 各战区产物清单汇总至 `output/manifests/{BASE_NAME}.json` 统一清单文件
|
||
- 若存在同主题技术方案，必须结合标准化技术方案文件补充测试约束
|
||
- 测试用例生成前必须先按 `knowledge_base/01_standards/review_checklist.md` 自检
|
||
- 需求有歧义时，必须显式写：
|
||
|
||
```md
|
||
> ⚠️ 待确认：问题、影响范围、建议确认方向
|
||
```
|
||
|
||
- 不得臆造高风险业务规则
|
||
- 历史遗漏场景和历史缺陷必须显式体现在测试点或测试用例中
|
||
- 预期结果必须同时覆盖 UI 反馈和数据状态变化
|
||
- 若 `confirmation_gate` 仍未解除，不得伪装成"已完成最终导出"
|
||
- 质量裁决 BLOCKED 时，不得导出 Excel
|