先用会失败的测试重现缺陷，再以最小改动修复

## 改代码前，先判断缺陷属于系统的哪个部分 从可观察到的影响入手，而不是从症状出现的文件入手。有效的初步研判结果应告诉下一位调查者：什么失败了、谁或什么受到了影响，以及哪个组件负责该行为。 ### 行动前先分类 - 将缺陷归类为核心行为问题、系统或集成行为问题，或者宿主环境行为问题。 - 区分展示症状的组件与控制失败行为的组件。 - 当证据表明原因位于当前组件之外时，将工作转交给真正负责该行为的边界。 ### 界定证据范围 记录触发输入、初始状态、用户的准确操作、预期结果、实际结果以及相关环境。将事实与假设分开列出。初步研判期间不要编辑实现代码；下一阶段必须先建立可重复重现的失败。 该分类只是暂定结论。如果后续证据与之矛盾，应返回此处，修订责任边界，并将测试移到真正负责该行为的层级。 ## 用会失败的测试重现用户看到的问题 将问题报告转化为仍然符合用户体验的最短可重复场景。保留有意义的输入、状态、顺序和可见结果；去掉不会影响失败的附带准备工作。 ### 选择最接近且可靠的测试层级 - 对独立逻辑使用范围明确的单元测试或组件测试。 - 当持久化、渲染、传输或多个组件参与时，使用集成测试或系统测试。 - 当失败依赖真实交互、焦点、时序、导航或视觉状态时，使用浏览器测试或端到端测试。 在更改源代码之前编写回归测试。运行测试，并确认它是因为报告中的原因而失败，而不是因为准备工作损坏、资源过期、数据缺失或无关断言。一个从未亲眼确认其失败的测试，不能作为缺陷存在的证据。 如果该行为无法自动化，应记录原因，并保留最有力且可重复的替代证据，例如确定性的手动步骤、连续截图、跟踪记录或测量结果。在失败证据足够可信之前，保持实现代码不变。 ## 找到行为最先偏离预期的地方，查明根本原因 只有在失败重现稳定后才开始调查。提出多个合理假设，并通过有针对性的观察逐一验证，而不是一次更改多个位置。 ### 追踪第一个偏离点 沿着状态变化、边界和控制流追踪失败输入。比较成功案例与失败案例，找出实际行为最早偏离预期行为的位置。只有当重现结果表明它们相关时，才检查生成产物、持久化值、集成响应或时序。 对于每个假设，预先判断哪些证据能够证实或否定它，执行能够区分假设的最小检查，并记录结果。将根本原因与后续损害，以及仅仅让缺陷更容易被观察到的条件区分开来。 隔离原因期间不要修改生产逻辑。如果所有假设都被否定，应返回重现阶段，核对其前提，修订分类，并提出新的、有证据支持的假设。 ## 以最小改动修复，并保留测试防止回归 隔离根本原因后，只更改恢复预期行为所需的最小范围。保留公共契约和无关行为，避免进行失败案例并不需要的清理、重新设计或重构。 首先运行原本会失败的测试。它现在必须因为根本原因已被消除而通过，不能因为断言被弱化、场景被跳过，或测试数据不再触发缺陷而通过。将该测试保留为永久的回归防护。 然后运行直接受影响的测试组，以及相关的静态检查、代码规范检查或类型检查。只有当更改跨越共享边界，或较小范围的证据表明存在更广泛风险时，才扩大到更广的测试套件。把每个新失败都视为证据：如果是真正的回归就修复；如果拟议修正并不完整，就返回根本原因隔离阶段。 检查最终差异中是否存在意外编辑、重复逻辑、被削弱的验证或遗漏的边界情况。只有目标行为及其直接受影响的相邻行为全部通过检查，才能在此阶段认定修复完成。 ## 在真实环境中重复用户的操作，确认已经修好 自动化测试必不可少，但不能代替对真实用户路径的确认。在具有代表性的运行环境中，使用暴露该缺陷时相同的关键输入和状态，重复原始的用户操作流程。 在用户可见的边界比较修复前后的结果。适用时，还要确认用户最终依赖的持久化结果、渲染结果、已发出的事件、集成交接或重新构建的产物。记录环境、步骤和观察结果，使其他人能够验证该结论。 如果手动操作仍然失败、与自动化结果不一致，或需要未记录的变通方法，不得宣布缺陷已经解决。返回分类或重现阶段，更新测试以覆盖遗漏条件，并重复根因分析、修复、回归检查和实际验证循环。 最后提交一份简洁的证据报告：缺陷分类、已确认的重现、根本原因、最小更改、回归覆盖范围、直接受影响的检查，以及实际流程的验证结果。只有当缺陷暴露出一个会反复产生问题的架构类型时，才添加可复用的预防规则；一次性细节应留在测试和更改记录中。