补充异常与回归测试清单

这个场景能帮你做什么

正常流程通过后，边界、故障与共享模块的旧功能仍可能出问题。WorkBuddy 可以结合本次改动和历史缺陷补候选场景，帮助测试人员选择回归范围。

开始前需要准备什么

准备变更差异、受影响模块及调用、现有用例、历史故障和异常规则。说明哪些业务后果必须单独验证，例如数据损失、越权、重复操作或金额状态不一致。

具体怎么做

第一步：沿变更影响展开

从改动函数、接口、配置与规则追到调用方和下游状态。共享逻辑不能只测一个入口，未知依赖单列。

第二步：补异常和边界组合

检查空值、极值、重复、乱序、取消、超时、部分成功及无权限等适用条件。只列与本次任务有关的场景，不机械堆满所有异常名词。

第三步：加入历史失效

把已确认缺陷和修复要求对应到用例，检查本次改动是否可能破坏历史防护。区分必须回归与可选探索，说明依据。

第四步：明确结果与执行条件

每条列故障注入或输入、预期状态、检查证据及环境。执行结果另行填写，不能把设计出的用例写成已经验证。

可以直接交给 WorkBuddy 的完整要求

基于变更、调用关系、现有用例和历史缺陷补异常/回归清单。
每条写触发条件、输入或故障、预期、证据和对应风险，区分必须回归/建议探索。
检查共享调用、状态一致、重复执行与权限；未知规则标补问，不补造预期。
输出覆盖缺口与环境要求，不以用例数量或代码覆盖率单独宣布质量达标。

完成后会得到什么

一份与变更和历史风险对应的测试清单，以及执行所需环境与数据。

结果应该怎么检查

逐个高影响变更查回归，核对旧问题能否被新用例发现。检查“部分成功”是否被当成全失败，重复提交是否有实际状态验证。

遇到这些情况怎么处理

环境无法模拟某故障时列未验证风险。历史记录只有症状时先核实。时间有限时按业务风险排序，由测试负责人决定，不自动删难例。

哪些必须人工决定

测试与研发确定回归策略，负责人接受剩余风险。AI 补场景，不代替执行或发布判断。