有个团队给我看过他们的流水线截图。四百多条 UI 用例，跑一次四十七分钟，红色一片。值班的人点开报告，第一件事不是看哪条挂了，是先点重试。
重试两次，绿了。这也算通过。
这不算个例。做技术编辑这些年，我进过几十个研发团队的测试间，聊到自动化测试，几乎没有人的痛点是「我不会写」。全是「我写太多了」。脚本能跑，报告能出，就是没人认真看。或者看了也白看。
首付是写脚本 月供是修脚本
一条 UI 用例的一辈子，写它大概花两成时间。剩下八成花在哪？等前端改类名，等接口字段改名，等测试环境半夜重启，等一个谁也没通知就上线的弹窗横在页面中间。
我翻过一个仓库，page object 里光选择器就两千多行，注释比代码还旧。问负责人为什么不用 data-testid，他说早就提过，前端排期排不上。
所以问题的形状很清楚：自动化测试的成本大头落在维护，不落在编写。招人时考的是怎么写，上岗后天天干的是怎么修。两件事的能力模型压根不一样。
录制回放最典型。演示的时候惊艳，点几下鼠标生成二十条用例，领导鼓掌。三天后前端调了组件结构，全红。改吧，改起来比手写还慢，因为生成出来的定位器根本没有语义，你连它在指哪个元素都得猜。
这事没那么玄。脚本是代码，代码就会腐化。区别只在于你有没有给它留维护预算。
不稳定用例不能靠重试糊过去
flaky 这个词现在有点被滥用了，什么都往里装。拆开看其实就几类。
等待写死的 sleep。共享账号或者共享数据，两条用例抢同一个订单。依赖第三方沙箱，对方半夜限流。并发跑的时候时区不对。还有动画没结束就去点按钮。
这些都还能修。麻烦的是另一类——测试代码自己耦合了实现细节。比如断言写的是某个 div 的 class 名，业务逻辑没错，样式改了就红。
重试是个止痛药，不是治疗。一条用例需要重试三次才通过，它给出的信号就是假的。因为它绿了不代表系统健康，只代表这次运气好。真出缺陷那天，它会混在一堆噪音里一起被忽略。
我个人经验里，flaky 率超过两三个百分点，整个报告的可信度就开始崩。开发会说「那个我知道，一直红」，测试会说「反正重试能过」，最后没人信任何人。
治理的办法不复杂，就是费人。把最近两百次失败拉出来归类，环境问题归环境，数据问题归数据，测试自身问题归测试自身。然后按归因结果分配修复人，而不是一律甩给测试组。这一步做不做，决定后面三年是良性还是内耗。
分层不是背金字塔 是算账
测试金字塔现在讲得太多，讲成了一句话口号。真到项目里，得算具体一笔账：这条用例的编写成本、执行时长、一年能拦下几次真缺陷。
接口层的性价比通常是最高的一档。快，稳，断言能直接对着业务字段来，不受前端改样式影响。一个订单状态流转的边界，用接口测可能两秒跑完，用 UI 测要四十秒，还得等页面渲染。
UI 层呢，我倾向于只留关键链路。登录、支付、下单主流程，各来一两条。剩下的交给前端自己的组件测试，和接口层兜底。
还有个容易漏的东西叫契约测试。前后端联调期的大量假失败，其实源于双方对字段的理解不一致，而不是代码写错。让消费者端把期望的请求响应结构写成契约，提供方每次构建都验一遍，联调期的无谓争吵能少一半。
执行节奏也得分开。冒烟集挂在合并前，压在三分钟以内，红灯就拦。全量回归扔到 nightly，第二天早上看结果。把所有东西都塞进 PR 门禁，结局一定是开发者排队等流水线，然后找关系插队。
测试数据才是隐形的大坑
脚本写得好，环境数据一乱，照样全红。
造数脚本往往是最先烂掉的东西。业务字段每加一个非空约束，造数就挂一批。有人在测试库里手工改数据，第二天另一个人的用例就找不到那条记录。
比较靠谱的做法是让用例自带数据生命周期。跑之前用自己的租户或者前缀建一套，跑完自己清掉。容器化数据库快照是个便宜方案，起一个干净的实例，几十秒的事。
脱敏别拖到上线前才做。生产数据捞进测试环境，这事一旦养成习惯，后面就是合规部门来找你，而不是测试同学来找你。
说白了，环境不稳定比代码有 bug 更耗人。因为它消耗的是信任，不是工时。
指标挑错了 方向就全歪了
见过太多团队用「用例总数」「通过率」当考核项。这两个数怎么来的？用例总数可以靠批量生成灌上去，通过率可以靠关掉失败的用例涨起来。都是能被优化出来的假指标。
我更愿意看四个数。回归总时长，从提交到出结论用了多久。失败归因耗时，红了一条，判断它是不是真问题要花多少分钟。逃逸缺陷，线上发现而测试没拦住的有几个。还有平均修复时长。
前两个数是效率，后两个数是质量。四个数一起看，谁也糊弄不了谁。
AI 帮忙写用例 现在到哪一步
模型生成接口用例骨架，确实能用了。给它一个 OpenAPI 描述，边界值、必填校验、类型不匹配，它能铺得比人快，也比人全。
但断言的业务含义给不了。订单取消后退款状态该是什么，优惠券分摊到哪个商品上，这些得有人告诉它。生成的用例没人读、没人认领，就是新增的技术负债，只不过负债的利息更隐蔽。
所以现在的合理用法是：让人写断言和场景，让模型写重复的样板和参数组合。反过来用，短期看产量暴涨，半年后维护崩盘。
回到最开始那个问题。我现在的判断标准就一句：这条用例一年会跑多少次，能拦下几次真缺陷，答不上来就别写。
自动化测试不是覆盖率比赛。它更像一组你愿意长期养着的资产，养不起的，不如趁早删掉。