测试面试：脚本自愈怎么避免掩盖真 bug？先划清「修定位」和「改预期」的边界

《核心观点》

1. 简历上写「失败重试、脚本自愈、自动修复」，面试官几乎一定会追问：你怎么知道修的是脚本，而不是把产品的错误结果改成了通过？这道题考的是你有没有把「自愈」的边界想清楚。
2. 判断标准只有一条：改动有没有动到业务预期。修正元素定位、加等待、调超时属于工程层面的修复；修改断言、放宽校验、删除失败步骤等于改判卷标准，不能叫自愈。
3. 典型的越界场景：普通员工本来没有审批权限，接口错误地允许他完成审批——脚本应该保留失败，绝不能因为实际返回了成功就把预期改成成功，或者删掉权限断言。
4. 失败时先保存原始证据（当前页面、请求与响应、日志、测试数据、失败断言），再区分原因：环境不可用、数据残留、定位失效、脚本错误，还是产品行为不符合预期。原因没确认之前，重试成功也不能写成根因已解决。
5. 允许自动处理的情况要有明确边界，例如在指定次数内等待一个已确认会异步更新的页面；涉及断言、业务状态、权限标准、删除失败步骤的修改，应输出修改建议和依据，人工核对后再更新，不能靠「全绿」当验收。
6. 重试前必须看操作有没有副作用。审批、提交这类动作可能已经执行成功、只是响应没回来，盲目重跑会造出第二条记录——先核对当前业务状态，再按接口约定决定能不能继续。
7. 面试里最加分的是拿一次真实排查串起来讲：最初失败是什么、确认了哪些证据、最终改动在哪一层、哪些断言保持不变、修正后又验证了哪些关联场景。
8. 项目实际只做了有限重试就如实说有限重试，AI 只给修复建议就说明人工怎么审核——把已完成的范围写准确，比「全自动自愈」几个字更经得起追问。

《参考解析》

「自愈」这个词本身就是面试官布下的钩子。 它听起来像能力，实际上是一个需要被限定的概念：自动化脚本能自我修复的只有「怎么操作」这一层，不能自我修复「什么算对」这一层。答这道题时先把这条线摆出来，后面所有例子都是它的推论，面试官会觉得你想过边界，而不是只会堆功能词。

权限、金额、状态这三类断言是绝对红线。 它们对应的是业务规则，不是脚本实现细节。审批权限、退款金额、订单状态流转一旦被脚本「修好」成通过，等于用自动化把一个真实缺陷洗白了——这比脚本失败严重得多。可以补一句：这类断言的值应该来自需求或接口文档，而不是来自被测系统这一次的返回值，否则就是拿结果当标准答案。

定位失效与预期失效要能分开报。 页面按钮换位置、接口字段改名属于定位失效，改完继续跑原有断言即可；如果改定位之后断言开始失败，说明被测行为真的变了，这时应该报缺陷而不是继续修脚本。把这两种情况在报告里分列，才能让「自愈了多少条」这个数字有意义。

证据留存是自愈能力的前提，不是可选项。 没有原始现场，重试成功只能说明「这次过了」，说明不了原因；一旦后面又挂，没有任何线索可查。可落地的做法是每次失败自动落一份快照（页面 DOM 或截图、失败请求与响应、使用的测试数据、命中的断言和实际值），并给这份证据打上用例 ID 与运行批次，方便事后回放。

「靠全绿作验收」是这类团队最常见的退化路径。 断言被一条条放宽之后，通过率好看了，缺陷却流到了线上。所以工程上要有两道防线：一是断言修改必须走代码评审并在提交信息里写明依据，二是定期用已知的错误场景做反向验证——故意把预期改错，确认脚本真的会失败。第二条能有效揪出没被执行到的断言、被吞掉的异常，以及只做操作不检查结果的「空脚本」。

副作用问题常被忽略但很致命。 提交类操作天然不幂等，超时重试可能产生两笔订单。稳妥的顺序是：查当前业务状态（这条记录到底成没成）→ 按接口约定判断能否重放 → 必要时用幂等键让服务端去重。面试时可以直说「我不会给所有失败套一个统一的重跑按钮」，这句话比任何技术细节都更能说明你有生产意识。

最后要落回「如实描述项目范围」。 面试官问这个问题，往往是因为太多候选人把「重试 + 截图」包装成「AI 自愈」。你可以主动拆分三个层次：只是失败重试，是自动修正定位，还是模型给出修复建议、人工审核后生效——说清自己在哪一层，反而更容易拿到下一轮提问的机会。