xst
b2a035c4f9
- 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
5.2 KiB
5.2 KiB
测试用例评审清单
这份清单服务于当前仓库的测试用例生成与自审流程，用于把 definition_of_done.md 中的原则拆成可逐项检查的执行项。
使用原则：
testcase-designer在写入最终用例前，必须先按本清单自检并直接修正。testcase-reviewer在评审阶段，必须按本清单逐类检查并直接修正阻断项。- 发现问题时，优先修正源用例，不输出额外草稿文件。
1. 阻断项
以下任一项不满足，都不能视为通过：
- 表头不是标准唯一表头。
- Markdown 表格格式错误，可能导致
verify或export失败。 - 只有主流程，没有异常、边界、状态流转或冲突防御场景。
预期结果只写页面提示，没有数据状态校验。测试步骤、测试数据过于抽象，执行人无法直接操作。- 需求存在明显待确认项，但未显式标注
> ⚠️ 待确认：...。 - 历史缺陷、漏测场景、项目差异化约束、关联冲突修订没有落到测试点或用例。
2. 结构与格式检查
- 是否严格使用唯一表头顺序：
用例编号模块用例标题优先级类型前置条件测试步骤测试数据预期结果备注
类型是否使用允许枚举：功能测试、性能测试、兼容性测试、易用性测试、安全性测试、冒烟测试、回归测试、其他。模块是否采用层级路径写法，例如平台端-营销管理-商家优惠券。用例编号是否稳定、可读、与模块归属一致。备注是否只承载待确认项、来源说明、AI 修正原因等必要信息，而不是堆重复内容。
3. 覆盖性检查
逐个模块检查以下维度是否都有体现；若不适用，需能说明原因：
- 主流程
- 异常流程
- 边界条件
- 状态流转
- 规则组合、互斥、优先级
- 幂等与并发
- 权限与越权
- 弱网、超时、异步或回调异常
- 历史缺陷防御
- 跨需求冲突防御
- 项目差异化高风险约束
- 如果需求包含中后台 CRUD/配置页，是否覆盖了列表字段、查询/重置、查看只读、新建/编辑/删除/失效、操作栏权限与状态映射、端间数据隔离。
- 如果需求包含中后台 CRUD/配置页，除失败态和限制态外，是否显式覆盖了新建成功、编辑成功等正向主链路。
- 如果需求包含“选择商品/优惠券/奖品/门店”等弹窗或选择器，是否覆盖了刷新、搜索、字段展示、分页、排序、单选/多选反馈和归属范围差异。
- 如果需求包含“未开始/进行中/已结束/已失效”等状态对 C 端展示或资格判断有影响，是否按状态拆成独立可定位用例，而不是笼统合并。
4. 单条用例质量检查
每条用例至少检查以下问题：
- 是否只验证一个主验证点，避免多个关键断言混杂。
- 前置条件是否完整，是否缺账号、角色、商品、库存、金额、券、积分、订单状态等必要上下文。
- 测试步骤是否按执行顺序书写，是否存在“正常操作”“提交并校验”等笼统描述。
- 测试数据是否具体，而不是“输入合法金额”“选择一张优惠券”这类泛化表达。
- 预期结果是否同时包含 UI/接口反馈和数据状态变化。
- 失败后是否能大致定位到前端、后端、规则、数据、异步链路或外部依赖。
5. 风险场景检查
以下高风险场景应按需求实际风险决定是否覆盖，涉及则不应缺失：
- 金额计算、优惠分摊、退款分摊、实付金额一致性
- 库存扣减、回滚、超卖、重复扣减
- 优惠叠加、互斥、门槛校验、适用范围校验
- 权益发放、核销、回退、重复使用
- 外部回调、重复通知、延迟通知、补偿重试
- 角色越权、数据越权、跨门店/跨商家/跨组织访问
6. 追溯与来源检查
- 关键测试点是否能追溯到需求、历史缺陷、漏测清单、营销规则、项目画像或冲突修订。
- 对历史缺陷补充的用例，
备注是否标注了合理来源，例如[AI修正: 补充历史缺陷防御]。 - 对冲突修订补充的用例，
备注是否标注了修正原因，例如[AI修正: 冲突修订]。
7. 待确认项检查
- 是否存在需求缺失、规则冲突、口径不明但被直接当成事实写进用例的情况。
- 对资金、库存、权限、状态流转、营销规则相关的不确定规则，是否避免了臆造。
- 待确认项是否写清楚问题、影响范围和建议确认方向。
8. 优先级检查
- P0 是否真正对应核心主流程、核心资损风险或关键状态流转。
- P1 是否覆盖主要功能、关键异常、重要边界。
- P2 是否承载次要异常、兼容性、补充性验证，而不是把高风险场景错误下沉到 P2。
9. 评审结论规则
- 若存在阻断项，必须直接修正原文件后再结束。
- 若存在覆盖盲区但当前需求范围确实不支持，应显式写出原因，不得静默遗漏。
- 若修正了已有用例或新增了防御用例，应在
备注中保留必要的AI修正说明。