7.3 防脆弱设计与反模式清单

7.3 防脆弱设计与反模式清单

本节摘要：脆弱性不是运气问题，是设计问题的累计结果——每一个"先跑起来再说"的妥协，都会在套件规模变大后连本带利讨回来。本节做一次系统性清点：四条防脆弱设计原则筑底，八类高频反模式列名单，并给出每类的纠正方向。它是第 7 章的减法章节——7.1 与 7.2 教你应对失败，本节教你少制造失败。

脆弱性不是运气问题，是设计问题

接手一套"时红时绿"的存量套件，最常见的误判是把它归因于"UI 自动化天生不稳定"。逐条审查之后，真相几乎总是同一批设计缺陷在反复作案：写死的等待、裸奔的定位器、互相依赖的用例顺序、把整套流程压进一条用例。这些缺陷在十条用例时无伤大雅，一百条时开始偶发，五百条时把套件变成抽签机。

所以防脆弱的打法不是"找到那条不稳定的用例修掉"，而是清点设计缺陷的类型，按类型批量纠正。类型化的好处是治理动作可复制：识别一类、清除一类、再以规范防止复发。本节先立四条设计原则，再给反模式名单——原则是"该怎么做"，名单是"别怎么做"，两面夹击。

四条防脆弱设计原则

原则一：锚点即契约。 页面对象里的每个定位器都是与前端的一份契约，契约要显式、要评审、要稳定——最理想的载体是测试专用属性。契约的另一面是沟通机制：前端改结构要提前通知，改了测试属性要视为破坏性变更。脆弱套件的团队复盘里，十有八九缺的不是技术方案，是这份契约意识。

原则二：同步即声明。 页面就绪与否必须是显式声明的等待条件（3.3 的体系），任何"睡一会儿再试"的写法都视为技术债。同步纪律的验收方法很朴素：全仓搜索固定延时调用，主干代码里命中数应当为零。

原则三：用例即孤岛。 每条用例独立成立——自己准备数据、自己走到场景起点、自己断言、自己清理。用例之间的执行顺序、共享状态、"上一条用例留下的登录态"，全部是脆弱性存款，并行化（6.2）时连本带利爆仓。

原则四：断言即业务。 断言对象是用户可感知的业务结果（文案、状态、跳转），不是实现细节（某个内部样式、某个恰好相同的数字）。断言离业务越近，改版存活率越高，失败时指向也越准。

八类高频反模式名单

名单里两条值得展开。"界面登录开场"是性能与稳定性的双重黑洞：登录页一次三十秒，两百条用例就是一百分钟的纯开场白，还把登录页的任何抖动传染给全量用例。正确做法是把登录态准备降级为前置条件——通过接口构造会话或注入凭据，让每条用例直接从业务场景出发，登录页本身只留给专门测登录的用例。"失败即重跑"则是流程反模式：它把 7.1 建立的定性体系短路掉，红屏重新变成抽签——重试可以有，但必须留痕、必须计数、必须有人对重试率负责。

治理存量：一次有组织的清偿

给存量套件做反模式清偿，建议按"统计、排序、批量、防复发"四步走。统计：用静态扫描把各类反模式在全仓的命中数拉出来（固定延时数、裸定位器数、超长用例数），得到一张技术债地图。排序：按"引发失败的概率乘修复的收益"排优先级——固定延时与裸定位器通常是前两名。批量：同类问题批量纠正（比如一次性把全部固定延时替换成条件等待），而不是随手零敲碎打。防复发：把纠正动作沉淀成代码评审清单与静态扫描门禁，新代码不新增负债。这套流程走完一轮，套件的"偶发红率"通常会有肉眼可见的下降——而这正是下一节与 7.5 度量要追踪的核心指标。

一轮存量治理的完整账目

把治理四步法套到一个真实工程上，看账怎么算。统计：静态扫描结果——固定延时调用八十七处、疑似绝对路径定位二十三处、超过二十步的巨型用例十一条、用例间共享登录态的依赖十九对。技术债地图一页纸，首次让"套件不稳"从体感变成数字。排序：按失败概率乘修复收益，固定延时与裸定位器排前两名，巨型用例第三，顺序依赖第四。批量：固定延时的替换分三个批次完成（先冒烟集、再高频回归、后长尾），每批替换后全量回归验证；绝对路径定位按页面对象逐个重写为测试属性锚点，期间与前端约定的属性规范同步落地。防复发：把"禁用固定延时""锚点选型清单"写进代码评审模板，静态扫描挂入流水线，新增命中即阻断合并。

六周的账目结算：偶发红率从每周约二十条降到两条以内，全量回归时长缩短三成（固定延时消失的直接红利），而最大的隐性收益是评审会上不再有"这个 sleep 能不能删"的争论——规范替团队回答了。治理的难点从来不是技术，是把一次性运动变成可持续的机制，四步法的价值全在第四步。

反模式清单的使用方法

一张名单的价值取决于用法，给三条建议。用法一：当评审清单用。 代码评审时对照八条过一遍，尤其盯"固定延时"与"裸定位器"——它们是新代码里最高频的两类新债，评审拦住的成本远低于事后治理。用法二：当巡检脚本用。 每月跑一次静态扫描，把八类反模式的命中数画成趋势——数字连续下降说明治理在起效，反弹说明规范松动了。用法三：当沟通语言用。 团队讨论套件质量时，用"反模式七的命中数降了六成"替代"最近稳定多了"，模糊的体感变成可讨论的事实。

最后提醒一个反面：清单不是用来指责人的。反模式多数诞生于善意的妥协——赶工期、缺规范、不知道有更好的写法。治理的氛围应当是"还技术债"而不是"抓违规"，这一点决定了清单是被使用还是被绕开。

收工清单

• 脆弱性可类型化：时红时绿的根子是有限几类设计缺陷，按类型批量治理，不逐条碰运气。
• 四原则：锚点即契约、同步即声明、用例即孤岛、断言即业务。
• 八反模式：录制依赖、固定延时、裸定位器、顺序耦合、巨型用例、无头断言、失败重跑、界面登录开场。
• 登录态前置化：会话准备走接口，UI 用例只测 UI——稳定与性能双收。
• 治理四步：统计、排序、批量、防复发，技术债地图是治理的起点。

失败能定性、现场有证据、设计在减负，还差最后一公里：把这套体系嵌进交付流水线，让回归结果变成发布决策的一部分。下一节讲流水线集成与门禁设计。