计划要求的缺陷也要报告

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

计划要求订单测试只断言paymentMock被调用，实际目标却是确认支付拒绝后订单仍待支付。实现遵循计划，但状态变错时该断言仍可能通过。

具体做法

分别核对实现是否满足计划与验证是否捕捉所需行为。引用计划、测试及具体漏检场景，把来源冲突标plan-mandated；建议增加可见状态断言并说明需要调整的计划范围。交负责角色裁决并记录，再按授权修复。不能把规范符合自动当质量通过，也不能静默改计划。

反例

计划就是这样写的，mock被调用所以测试质量通过；忽略错误订单状态。

改进写法

报告两轴：已满足只检查mock调用的规格；但支付拒绝后错误标已支付也能通过，存在行为覆盖缺口。引用两处依据，标plan-mandated，提出经裁决增加状态断言，并保留规格冲突记录。

为什么这样改

计划作者也可能遗漏重要行为。分开报告符合度与缺陷，可同时承认实现准确和指出现实风险，避免计划自我证明质量。

如何验证

教学变异把拒绝后状态改为已支付，原mock断言仍通过，新增查询状态断言应失败。裁决记录应说明是否修订测试要求；未执行变异时只记录检查设计，不声称实测。

适用边界

负责人决定规范冲突，评审不自行扩大批准范围。不是所有mock断言都无用，需证明它遗漏了具体要求。风险级别按影响而非来源标签决定。