自动化测试失败，头号原因是维护费

每个兴冲冲上自动化测试的团队，两年后大概率面对同一片废墟：几千个脚本，红的没人看，绿的没人信，维护的人跑光了。《自动化测试最佳实践》（Dorothy Graham & Mark Fewster 编）拿 29 个真实案例复盘这件事，结论扎心：公司放弃测试工具的第一原因不是工具差，是脚本维护费用太高。

automation-testing-best-practices-skill 把这 29 个案例蒸馏成 6 个可发现的技能，核心直指维护费。

维护费怎么省：两层抽象

testware-architecture（测试件架构）是答案的核心：把工具调用隔离在底层（工具换了只改一层），业务测试写在领域测试层（DSTL）——用业务语言写测试，工程师读得懂，界面改版不至于全军覆没。两层之间的「厚度权衡」是艺术：抽象太薄没有隔离效果，太厚则自己成了维护负担。

ROI 三模型让这笔账算得清：多周期工作量模型（有实测案例四个周期回本）、执行频率账（每次手工执行省多少分钟 × 频率）、缺陷成本公式。上自动化之前先算账，是这本书的纪律。

比失败更可怕的：僵尸测试

results-verification-defense 是整个技能包最狠的一张卡：自动化最容易死成的样子不是报错，是永远绿色——期望结果没人维护，断言早已失效，脚本跑过只说明「它跑过了」。防御三件套：期望结果负责制（谁写谁维护）、静态分析扫空断言、测试件生命周期状态机（过期即退役）。

「回归自动化的价值在信心与速度，不在发现 bug」——这句话配合僵尸测试防御一起读，才算读懂。

flowchart TD
    A["29 个真实案例<br/>Graham & Fewster"] --> B["automation-decision-checklist<br/>10 判据：哪些该自动化"]
    B --> C["testware-architecture<br/>两层抽象隔离维护成本"]
    C --> D["roi-evaluation<br/>四周期回本的账"]
    D --> E["zombie 防御<br/>期望负责制+生命周期状态机"]

边界与判断

适用：筹备或重建测试自动化的团队、想给 Agent 配「自动化军师」的测试负责人。不适用：指望模板直接套——29 个案例的价值在思路多样性，不是标准答案。

书里还有个反常识的提醒值得单独拎出来：自动化成功的两大要素，管理层支持排第一，工具架构排第二——技术问题背后全是组织问题。

我的判断：如果只装一个测试类技能，我会选这个——别的技能教你怎么测，这个教你怎么不半途而废。

你们团队的自动化脚本，现在还有多少是「活」的？评论区报个数，我猜中位数不忍看。

仓库：https://github.com/Fen9pi-Max/automation-testing-best-practices-skill（含 24 个反模式体检清单）