feat: Agentic QE Fleet v2.0.0 - 14-agent quality engineering platform
- 14 specialized AI agents across 5 battle zones (Prepare/Analyze/Design/Review/Monitor) - New: risk-assessor, test-strategist, data-builder, coverage-auditor, quality-gatekeeper, execution-analyst, knowledge-curator - New: fleet_runner.py orchestrator with multi-zone manifest pipeline - New: fleet_config.yml for centralized configuration - New: knowledge activation system (keyword + semantic matching) - New: semantic conflict detection with severity grading (P0-P3) - New: three-tier quality gate (PASS/PASS_WITH_FIX/BLOCKED) - New: monitor zone for test execution analysis and auto knowledge curation - Backward compatible: /case_generate alias, case_pipeline.py preserved - Comprehensive docs: USER_GUIDE.md + MAINTENANCE_GUIDE.md
This commit is contained in:
@@ -0,0 +1,108 @@
|
||||
---
|
||||
name: qe-fleet
|
||||
description: Agentic QE Fleet — 14 个专业 AI Agent 组成的自治质量工程舰队。当用户输入 /qe-fleet 或 /case_generate 时使用本 skill。
|
||||
metadata:
|
||||
short-description: 多 Agent QE Fleet:从需求到测试用例的全流程自动化 + 质量门禁 + 知识沉淀
|
||||
---
|
||||
|
||||
# Agentic QE Fleet
|
||||
|
||||
当用户输入以下任一意图时使用本 skill:
|
||||
|
||||
- `/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 <需求文档>`(向后兼容别名)
|
||||
|
||||
## 自动执行要求
|
||||
|
||||
收到 `/qe-fleet` 命令后,不要停在说明阶段,必须自动完成以下步骤:
|
||||
|
||||
### /qe-fleet run
|
||||
|
||||
1. 执行:
|
||||
```bash
|
||||
python3 scripts/fleet_runner.py run --requirement <需求文档路径>
|
||||
```
|
||||
|
||||
2. fleet_runner.py 会自动按战区顺序执行:
|
||||
- **PREPARE**: document-parser(文档解析) → knowledge-activator(知识激活)
|
||||
- **ANALYZE**: requirement-analyzer(需求分析) + conflict-detector(冲突检测) → risk-assessor(风险评估)
|
||||
- **DESIGN**: test-strategist(测试策略) → testpoint-designer(测试点) + data-builder(测试数据) → case-designer(用例设计)
|
||||
- **REVIEW**: case-reviewer(用例评审) + coverage-auditor(覆盖率审计) → quality-gatekeeper(质量裁决)
|
||||
- **MONITOR**: execution-analyst(执行分析) → knowledge-curator(知识沉淀)
|
||||
- **EXPORT**: 质量裁决 PASS 后自动导出 Excel
|
||||
|
||||
3. 检查确认门禁:
|
||||
- 若 analyze 战区 `confirmation_gate.required=true` 且 `decision_status` 不是 `confirmed`,阻断并告知
|
||||
- 提供确认单路径和阻断原因
|
||||
|
||||
4. 检查质量裁决:
|
||||
- 若 review 战区 quality_verdict 为 `BLOCKED`,告知阻断原因
|
||||
- 若为 `PASS` 或 `PASS_WITH_FIX`,自动导出
|
||||
|
||||
5. 最终反馈:
|
||||
- 各战区状态(✅ 完成 / ⏳ 进行中 / ⬜ 待执行)
|
||||
- 产物文件路径
|
||||
- 质量裁决结果
|
||||
- 若失败,失败在哪一步
|
||||
|
||||
### /qe-fleet status
|
||||
|
||||
```bash
|
||||
python3 scripts/fleet_runner.py status --requirement <需求文档路径>
|
||||
```
|
||||
|
||||
### /qe-fleet monitor
|
||||
|
||||
```bash
|
||||
python3 scripts/fleet_runner.py monitor --requirement <需求文档路径> --results <测试结果文件>
|
||||
```
|
||||
|
||||
## 战区详细流程
|
||||
|
||||
### Prepare 战区
|
||||
- **document-parser**: 解析 docx/pdf/doc → 标准化 Markdown;自动识别同主题技术方案;标注解析置信度
|
||||
- **knowledge-activator**: 按需求内容关键词+语义匹配激活术语/规则/历史缺陷/最佳实践;检测知识缺口
|
||||
|
||||
### Analyze 战区
|
||||
- **requirement-analyzer**: 结构化需求模型(背景/目标/角色/规则/流程/异常);项目画像差异化;歧义标注
|
||||
- **conflict-detector**: 语义级历史需求冲突检测(方向/数值/状态机/权限);严重度分级(P0-P3)
|
||||
- **risk-assessor**: 多维度风险矩阵(资损/可用性/数据/合规/兼容性);可能性 × 影响度 = 风险等级
|
||||
|
||||
### Design 战区
|
||||
- **test-strategist**: 测试金字塔分配;优先级覆盖规则;P0 必测清单
|
||||
- **testpoint-designer**: 全面测试点矩阵;来源标注(需求/历史缺陷/风险矩阵/冲突修订/项目画像)
|
||||
- **case-designer**: 可执行用例;原子性;双验证预期结果(UI + 数据)
|
||||
- **data-builder**: 自动提取+人工补充测试数据(账号/金额/ID/枚举/边界值)
|
||||
|
||||
### Review 战区
|
||||
- **case-reviewer**: 按 review_checklist 逐项评审;错误分级(阻断/建议/优化)
|
||||
- **coverage-auditor**: 需求→测试点→用例三级追溯;覆盖缺口识别;过度覆盖识别
|
||||
- **quality-gatekeeper**: 三级裁决(PASS / PASS_WITH_FIX / BLOCKED);裁决依据引用具体评审条目
|
||||
|
||||
### Monitor 战区
|
||||
- **execution-analyst**: 失败归类(ENV/DATA/CASE/REAL_BUG);失败模式识别;根因推测
|
||||
- **knowledge-curator**: 自动回写知识库;去重保护;P0 自动生效 / P1-P3 人工确认
|
||||
|
||||
## 约束
|
||||
|
||||
- 除非脚本执行失败,不要要求用户手动执行中间命令
|
||||
- 确认门禁未解除时,必须阻断并告知原因和解决路径
|
||||
- 质量裁决 BLOCKED 时,不得导出 Excel
|
||||
- 若主输入是 .docx/.doc/.pdf,必须基于 prepare 产出的标准化 Markdown
|
||||
- 若 manifest 中有技术方案文件,必须纳入分析
|
||||
- 需求有歧义时必须显式标注 `> ⚠️ 待确认:问题、影响范围、建议确认方向`
|
||||
- 基于项目画像差异化,避免通用化输出
|
||||
- 历史缺陷和易漏场景必须显式体现在测试点或用例中
|
||||
- 预期结果必须同时覆盖 UI 反馈和数据状态变化
|
||||
- 若改动涉及 scripts/、.claude/、agents/、AGENTS.md、README.md,必须执行 governance_audit.py auto
|
||||
|
||||
## 兼容性
|
||||
|
||||
`/case_generate` 保留为 `/qe-fleet run` 的别名,行为完全一致。
|
||||
Reference in New Issue
Block a user