缺陷验证
铁律:缺陷 verified 只证明三阶段复测;来源验收缺口必须经过新的验收计算才能关闭。
读取 retest.md 与 共享执行契约。局部 Bug 可直接开始,无需完整 TestSpec;正式回归使用已评审的范围。
- 明确 defect ID、原始预期、目标失败特征、关键初始条件、旧版/修复版身份及回归范围。
- 每阶段建立独立冻结 scope,使用 app-test 或 api-test-automation 执行并登记所有尝试。
- RED 必须证实目标失败特征;配置、DNS、安装、账号故障是阻塞,不是成功复现。
- GREEN 在相同关键条件下通过原断言;条件或 oracle 改变须说明并重新确认可比性。
- REGRESSION 覆盖相关路径、边界、角色和历史风险,按选择依据冻结范围。
- 用 scripts/verify_defect.py 核验各阶段证据引用,输出 defect-result.json;报告 verified/incomplete/failed,以及未复现或未验证的部分。
来自既有执行/验收失败时,按 retest.md 的 lineage 字段绑定来源 run/check 和 scope 摘要;尚未再验收时保留 not-run。存在再验收记录时传 --current-targets,由工具另算 reacceptance_status 和 closed_check_ids,不能手填结果或把 GREEN 重用为再验收。
交付前检查:来源检查确实失败、目标与 oracle 可比、三个阶段证据完整;分别报告缺陷状态和再验收状态。只整理已有报告时不执行或改写记录;没有外部 Bug 编号时使用本地稳定 ID,不编造外部工单。
缺失旧版可继续修复版检查,保留 missing baseline,最终不得标完整 verified。版本可用包摘要、构建号或可核实部署标识,不强制 Git。根因分析可调用诊断能力,但不是复测通过的替代证据。