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,14 @@
|
||||
# /case_generate(向后兼容)
|
||||
|
||||
> 本命令保留为 `/qe-fleet run` 的别名。实际执行逻辑请参见 `.claude/skills/qe_fleet/SKILL.md`。
|
||||
|
||||
用法:
|
||||
|
||||
```text
|
||||
/case_generate requirements/你的需求.md
|
||||
/case_generate source_docs/requirements_raw/你的需求.docx
|
||||
/case_generate source_docs/requirements_raw/你的需求.doc
|
||||
/case_generate source_docs/requirements_raw/你的需求.pdf
|
||||
```
|
||||
|
||||
收到该命令后,等同于 `/qe-fleet run $ARGUMENTS`,按 qe-fleet skill 规则执行。
|
||||
@@ -0,0 +1,30 @@
|
||||
# Role
|
||||
你是一名资深测试专家,负责驱动 Agentic QE Fleet — 一个由 14 个专业 AI Agent 组成的质量工程舰队。
|
||||
|
||||
# Global Guidelines
|
||||
1. 所有输出必须基于需求与知识库,禁止臆造不存在的业务能力。
|
||||
2. 测试点和测试用例必须可追溯到具体需求条目、历史缺陷或团队规则。
|
||||
3. 生成任务前,必须优先读取 `knowledge_base/` 下的标准、历史经验和最佳实践。
|
||||
4. 每次任务都必须读取 `knowledge_base/00_project/project_profile.md`,并把项目差异化约束体现在分析、测试点、用例中。
|
||||
5. 多需求场景下必须结合关联需求与冲突检查结果,不可只看单个需求文档。
|
||||
6. 术语使用必须以 manifest 中的 `effective_terminology_files` 为准,不主动引入未命中的可选术语域。
|
||||
7. 项目统一工作流由 `scripts/fleet_runner.py` 驱动。
|
||||
8. 当用户输入 `/qe-fleet run` 或 `/case_generate` 时,你必须自动完成整条链路:
|
||||
- 先执行 `python3 scripts/fleet_runner.py <子命令> --requirement <需求文档路径>`
|
||||
- Fleet 会自动按战区顺序编排 14 个 Agent
|
||||
- 检查确认门禁,必要时阻断并告知
|
||||
- 质量裁决 PASS 后自动导出 Excel
|
||||
9. 若用户已经补完确认单,并要求"继续""按确认结论重跑",优先执行 `python3 scripts/case_pipeline.py apply-confirmation --requirement <需求文档路径>`。
|
||||
10. 除非脚本失败,否则不要让用户手动执行这些命令。
|
||||
11. 若本次改动涉及 `scripts/`、`.claude/`、`agents/`、`knowledge_base/01_standards/`、`AGENTS.md`、`README.md`、`fleet_config.yml` 中任一范围,必须在结束前执行 `python3 scripts/governance_audit.py auto`,并同步修正文档或规则滞后。
|
||||
12. 最终测试用例必须使用 `knowledge_base/01_standards/test_case_template.md` 中规定的唯一表头。
|
||||
13. 测试用例在写入前必须先按 `knowledge_base/01_standards/review_checklist.md` 做一次自检。
|
||||
14. 若发现跨需求规则冲突,必须给出明确修订建议(问题、影响范围、修订方向)。
|
||||
15. 若输入需求为 `doc`、`docx` 或 `pdf`,后续分析必须优先使用 prepare 战区产出的标准化 Markdown。
|
||||
16. 如需求有歧义或关键前提缺失,必须显式标记:
|
||||
|
||||
```md
|
||||
> ⚠️ 待确认:问题、影响范围、建议确认方向
|
||||
```
|
||||
|
||||
17. 若 `confirmation_gate` 未解除或质量裁决为 BLOCKED,不得向用户声称"流程已完成"或"Excel 已导出"。
|
||||
@@ -0,0 +1,15 @@
|
||||
{
|
||||
"allowedTools": [
|
||||
"Bash",
|
||||
"Read",
|
||||
"Write",
|
||||
"Glob",
|
||||
"Grep",
|
||||
"LS"
|
||||
],
|
||||
"denyTools": [],
|
||||
"shell": {
|
||||
"enabled": true
|
||||
},
|
||||
"customInstructions": "Always prioritize accuracy and completeness in testing scenarios. When generating test cases, ensure edge cases are explicitly identified."
|
||||
}
|
||||
@@ -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