xst
acdb441507
系统修复: - fleet_runner.py: Windows UTF-8 编码兼容（reconfigure stdout/stderr） - fleet_runner.py: run 命令自动生成合并清单供导出使用 - fleet_manifest.py: 新增 save_merged_manifest() 保存统一清单 - fleet_config.yml: 修复 YAML keywords 格式（block sequence → flow sequence） - 恢复被误删的知识库文件(payment_flow_cases, marketing_activity_cases) QE Fleet 产物 (安徽运八需求): - 153个测试点 + 53条可执行测试用例 - 需求分析/风险评估/测试策略/质量裁决（PASS） - Excel 导出 + 版本快照 v2 - 确认结论文件已归档
5.6 KiB
5.6 KiB
测试用例完成定义
面向当前仓库的固定流水线，一个测试任务被视为“完成”，不是只看是否产出了文档，而是看产出的测试点和测试用例是否已经达到可评审、可执行、可追溯、可导出的质量门槛。
1. 覆盖范围达标
至少覆盖以下维度，不得只覆盖主流程：
- 主流程：核心业务 Happy Path 必须覆盖。
- 异常流程：参数非法、前置条件不满足、状态不允许、库存不足、余额不足、权限不足、重复操作、超限操作等必须覆盖。
- 边界条件：最小值、最大值、临界值、空值、默认值、长度边界、数量边界、时间边界、金额边界必须按需求实际场景覆盖。
- 状态流转：创建、提交、生效、失效、取消、关闭、撤回、恢复等关键状态变化必须覆盖。
- 规则组合：多条件叠加、互斥、优先级、覆盖关系、兜底规则必须覆盖。
- 数据校验：展示数据、落库数据、统计口径、列表汇总、详情字段、外部回传字段必须覆盖。
- 中后台页面：如果需求包含列表、新建、编辑、查看、失效、删除、筛选、选择弹窗等管理能力，除失败态外，正向成功链路和交互细项也必须覆盖。
- 历史风险：
common_missed_scenes.md、historical_defects.md中与当前需求相关的高风险场景必须映射到测试点或测试用例。 - 跨需求影响：
关联与冲突.md中识别出的关联规则、潜在冲突、修订建议，必须至少落一条可验证测试点或用例。 - 项目差异化：
project_profile.md中的业务边界、禁用能力、特殊限制、风控要求必须体现。
2. 风险覆盖达标
对于高风险模块，测试用例必须体现风险导向，而不是平均用力。
- P0/P1 业务规则必须覆盖正向、逆向、边界、互斥、并发或幂等中的关键场景。
- 资金、库存、优惠、权益、运单状态等资损类风险，必须覆盖结果一致性校验。
- 涉及角色隔离、数据隔离、组织隔离的需求，必须覆盖权限与越权场景。
- 涉及外部系统、回调、异步任务、延迟生效、重试补偿的需求，必须覆盖时序异常与重复触发场景。
3. 用例设计质量达标
每条用例必须满足以下要求：
- 原子性：一条用例只验证一个主验证点，避免多个核心断言混在一条用例里。
- 可执行：前置条件、步骤、测试数据明确，执行人无需猜测。
- 可验证：预期结果必须同时覆盖 UI/接口反馈和数据状态变化。
- 可定位：失败后能大致判断是前端展示、后端规则、数据落库、异步处理还是外部依赖问题。
- 可复现：步骤中要包含关键账号、角色、商品、金额、券、积分、库存、时间或状态等必要数据。
- 类型准确：
类型字段必须使用标准枚举，且与用例真实目的匹配。 - 术语一致：术语表达必须与生效术语文件一致，不混用平台券、商家券、店铺券等概念。
- 模块清晰：
模块字段应使用层级路径表达，例如平台端-营销管理-商家优惠券。
4. 测试点到用例的映射达标
- 每个高价值测试点都应被至少一条用例承接。
- 历史缺陷防御点、漏测清单项、冲突修订项不得只停留在测试点层，必须在用例层落地。
- 如果某类测试点因为当前范围不做用例，必须明确写出原因，不能静默遗漏。
5. 待确认项处理达标
- 需求存在缺失、冲突、口径不明时，必须显式写出：
> ⚠️ 待确认：问题、影响范围、建议确认方向
- 待确认项影响主流程、金额、库存、权限、状态流转、优惠规则时，不得擅自臆造高风险业务规则。
- 对待确认项，至少要补一条“确认后需重点回归”的提醒性测试点或备注。
6. 非功能与稳健性覆盖达标
以下场景按风险选择，不要求机械凑数量，但高风险需求不能缺失：
- 幂等：重复提交、重复支付、重复领券、重复核销、重复回调。
- 并发：多人抢占、库存竞争、优惠领取竞争、重复操作竞争。
- 弱网与超时：请求超时、接口重试、页面重复点击、异步结果延迟返回。
- 兼容与稳定性：分页、排序、筛选、导入导出、大数据量、长名称、特殊字符。
- 权限与审计：无权限、低权限、跨组织、跨门店、跨商家操作及日志留痕。
- 展示状态：若多个业务状态会影响 C 端资格、弹窗或按钮展示，需拆分到可定位的独立用例，不得用一条模糊负向用例笼统代替。
7. 评审与产物达标
output/analysis/{BASE_NAME}_分析.md、output/test_points/{BASE_NAME}_测试点.md、output/test_cases/{BASE_NAME}_测试用例.md必须完整存在。- 测试用例表头必须严格符合
test_case_template.md的唯一规范。 - 测试用例文件必须可通过
verify校验，并可成功export为 Excel。 - 评审阶段必须对照本 DoD、历史缺陷、关联冲突报告、项目画像进行检查；未达标时应直接修正原文件，不另起草稿。
8. 默认判定原则
如果产物满足以下任一情况，则不能视为完成：
- 只有主流程，没有异常、边界、状态流转或冲突防御场景。
- 用例步骤泛化，没有可执行的数据。
- 预期结果只有“提示成功/失败”，没有数据状态校验。
- 历史缺陷、漏测清单、项目差异化约束未落入测试点或用例。
- 明显存在待确认问题，但未显式标记。
- Markdown 表格不规范，导致后续
verify或export无法通过。