7.1 失败分类与重试机制

7.1 失败分类与重试机制

本节摘要：红屏不等于缺陷——失败先定性，再处置：环境类失败修环境、数据类失败修数据、时序类失败加固隔离、缺陷类失败提单跟踪。重试是时序类失败的最后缓冲，但重试不治本，滥用重试反而会掩盖真缺陷。本节给出四象限分类法、各类失败的处置路径与重试的纪律边界，它是第 7 章信任体系的入口——真假分不清，后面的一切都是空谈。

红屏的四种颜色

打开一份数百条用例的回归报告，五十条红。新手看到的是五十个"失败"；老手看到的是四种不同的问题。环境类：节点浏览器版本漂移、网络抖动、依赖服务不可用——脚本和页面都没错，是舞台塌了。数据类：账号被顶、缓存未失效、前置数据被人改了——脚本的输入脏了。时序类：等待条件没加固到位的偶发竞态——3.3 讲过机制，这里关心处置。缺陷类：被测系统真的坏了——回归的最终猎物。

四类失败的处置路径完全不同，混在一起处理的结果是两类大错：把环境失败当缺陷提单（浪费开发与测试的互相信任），把缺陷当抖动重跑放过（漏测上线）。所以失败管理的第一能力是快速定性，而定性的抓手是失败签名：报错类型、失败步骤、截图现场、执行环境指纹。四样凑齐，多数失败一眼可归类。

图7-1 失败四象限与处置路径

重试：最后一道缓冲，不是第一反应

重试的正当用途很窄：对已知偶发、已定性为时序类的失败，做有限次数的缓冲。它的价值是吸收残余抖动——等待体系再完善，网络仍有毫秒级波动，个别边界场景仍有验证盲区，重试一两次能把这些尾巴扫掉。运行器层面通常有现成开关（失败自动重跑指定次数），也可以在夹具层自定义"仅对标记的用例重试"的精细策略。

但重试有三条红线。红线一：不许重试替代治理。 某条用例每周随机红三次、重试后都过——正确动作是加固它的等待与隔离，把随机性消灭；错误动作是把重试次数加到三。后者的结局是套件越跑越慢，且真正的退化被"重试都过"的表象遮住。红线二：重试必须留痕。 每次重试要记录首次失败的原因与现场，报告里单列"重试后通过"计数——这个数字应该被当作技术债的仪表盘，只许降不许涨。红线三：缺陷类失败禁止重试。 断言失败、页面真实的异常状态，重跑一百次也是红；对它们重试纯粹浪费时长，还稀释了"重试"这个信号的纯度。

这张决策图建议直接落进团队的失败处置规范。注意"已加固仍偶发"这个分支的门槛——它把重试定位成治理之后的残余缓冲，而不是逃避治理的借口。

失败隔离：让失败不扩散

比处置单个失败更重要的，是不让一个失败污染一批结果。三个隔离动作值得成为默认纪律：会话隔离——失败后立即销毁会话重建，带病会话会让后续用例在脏状态上继续跑，连环红就是这么来的；数据隔离——失败用例留下的脏数据要标记清理，否则明天它变成别人的"数据类失败"；报告隔离——失败用例的取证包独立归档，与通过用例的轻量记录分开存。隔离的成本几乎为零，收益是失败半径恒定为一条用例，而不是一片用例。

一次失败定性晨会的完整还原

把四象限法用活的样子，是一场十五分钟的晨会。回归夜跑后三十条红，会议开始。第一轮，按失败签名粗分：十二条报错相同（同一个接口超时），归一组；八条集中在同一个新功能模块，归二组；六条是会话类异常，归三组；四条各自孤立，归四组。

第二轮，逐组定性。一组对着指纹表看环境维度——失败全部集中在两个节点，而这两个节点昨夜做过网络割接：环境类，责任到运维，下午复跑验证。二组翻取证包的页面快照，列表列头变了但接口返回正常——真缺陷，前端改了字段名没同步排序逻辑，当场提单。三组的截图显示登录页弹出了维护公告弹窗挡住登录按钮——数据类与环境类的交界，归因为公告弹窗的清理动作缺失，补一条"清场"前置步骤。四组三条是时序偶发（重试后通过），一条是断言失败但复跑通过——这条被标记为"待观察"，列入次日重点复核。

十五分钟，三十条红各有归属、各有负责人、各有下一步。散会前主持人做了一件事：把今天的分类结果记入趋势表。三个月后回看，环境类占比从四成降到半成——因为每一类失败都被持续地推向它的根因侧。定性的复利就在这里：单次晨会解决今天，趋势表改造下个季度。

定性体系的建设顺序

给刚起步的团队一个务实的建设顺序。第一周：只做一件事——给失败报告补齐"失败签名"四要素（报错类型、失败步骤、截图、环境指纹），形式可以土：一张表格、一行模板化的日志输出都行。定性没有数据支撑就是空谈，这一步是全部的地基。第二周：把四象限的处置路径写成团队规范，重点不是分类学本身，而是每类的"下一步归谁"——环境类找谁、缺陷类走什么流程，责任链清晰了分类才会被认真执行。第三周起：重试策略上线，同步在报告里开出重试计数；每月看一次四类占比的趋势，让治理资源流向占比最大的一类。

三周建成的是最小可用体系，它的特征是"每个失败都有去处"。至于自动化的定性（按报错类型自动打标签）、趋势看板这些进阶形态，等最小体系跑顺了再逐步加码——顺序反了，工具会先于流程落地，然后双双荒废。

一个定性演练

体系建成后的第一次实战，建议用一场演练校准团队口径：取历史报告里的十条失败（隐去结论），让每个人独立归类，再对答案。归类不一致的地方就是口径的模糊带——通常集中在"环境类与数据类的边界""时序类与缺陷类的边界"。把模糊带的判定规则补进规范（比如"复跑后通过且换环境仍失败，倾向环境类；复跑后通过且换环境也通过，倾向时序类"），分类学就从个人经验变成了团队资产。演练四十分钟，换来的是此后每一次晨会都省下的争论时间。

收工清单

• 四象限定性：环境、数据、时序、缺陷，四类失败四条处置路径，混处理必然两头出错。
• 定性靠签名：报错类型、失败步骤、截图现场、环境指纹，四样凑齐一眼归类。
• 重试三红线：不替代治理、必须留痕计数、缺陷类禁止重试。
• 失败隔离三动作：重建会话、清理数据、独立归档，失败半径恒定为单条。
• 与 7.2 的接口：定性依赖失败签名，签名从哪来——下一节的取证体系。

定性需要证据，证据需要体系。下一节把截图、日志、上下文数据与录屏这四件套装进工程，让每条红屏自带答案。