先说结论：1200条UI自动化，我删了1000条
2021年我在一家做跨境独立站的公司，测试组7个人，我是唯一挂着「自动化」这个title的。那年Q3 leader给了个目标：核心链路UI自动化覆盖率做到80%。我做到了，年底Allure报告里躺着1200条用例，绿油油一片，周会上被点名表扬了两次。
2022年3月，我把其中1000条删了。
不是什么幡然醒悟的故事，是维护成本真的扛不住了。当时每加一个新功能，平均要连带改12条老用例；每次发版前这1200条跑完要47分钟，失败率32%，组里两个人每周大概要花11个小时去修那些「不是bug的失败」。
我拉了2022年1月的执行数据：那个月机器上跑了31次全量，累计失败用例11904条次。我抽了500条失败记录人工归类，结果是这样的——
- 环境/数据问题：约41%（测试账号被风控锁了、优惠券过期、第三方支付沙箱挂了）
- 元素定位失效：约27%（前端把
btn-primary改成btn--primary--v2，就这一处，炸了40多条用例） - 等待/时序问题：约18%（loading动画没结束就去点，或者接口比预期慢了两秒）
- 真正是产品bug：约12%，而且这12%里九成是「文案错别字」「金额小数位显示」「多语言漏翻译」这种冒烟测试顺手就能抓到的
翻译一下：1200条用例，一个月真正抓到的新问题不到60条次。剩下的，基本是在给我的Jenkins发噪音。
「测试左移」，我用了一年之后开始怀疑它
现在行业里张口就是测试左移、质量内建、测试即服务。我不反对，但我在两个项目里实际推过之后，有个不太一样的感受：左移的前提是需求可测、设计可测，可现实是很多需求文档连异常分支都没写清楚。
你左移过去，不是去发现问题，是去帮产品经理补文档。我做过一次需求评审，一个「优惠券叠加」的功能，文档写了3页，商品券和店铺券能不能一起用、过期券是在下单时校验还是支付时校验，全是问号。这种情况下测试提前介入，能做的只有跟着一起猜，然后把猜的结果写进用例，最后猜错了再改用例。这不叫左移，这叫把返工提前了。
我后来想明白一件事：真正该左移的不是「测试人员的位置」，是「可测性」这个属性本身。
我们那个支付模块，之前每次测退款都要真去调第三方沙箱，沙箱还经常抽风。我花了三天推动开发加了个 header，测试环境传 mock_pay_result: success / fail / timeout，三个分支随便造。就这么一件小事，省下来的时间比多写300条UI用例都多。可测性设计这东西，投入产出比高得离谱，但它不出现在任何一份测试覆盖率报告里。
所以我现在的观点有点反主流：一个测试工程师的价值，不体现在他写了多少用例，而体现在他能让多少东西变得「容易验」。
我是怎么从1200砍到180的
具体做法，四步，没什么技术含量，难的是下决心。
第一步，拉三个月执行数据，算「有效失败率」。
公式很简单：有效失败数 / 总执行次数。有效失败指的是最终确认为产品缺陷的那次失败。低于2%的用例，先进观察名单，不直接删。我们那1200条里有大约640条，三个月有效失败率是0——一次真bug都没抓到过。
第二步，按业务价值分级。
支付、下单、登录注册、购物车这四条链路，一条不删，全留。后台配置页、帮助中心、多语言切换、地址簿管理、埋点校验，这些直接砍。有人说埋点不重要吗？重要，但埋点用接口层或者日志比对去验，比UI点一遍靠谱一百倍，也快一百倍。
第三步，合并参数化。
同一个断言点的多组数据，比如登录的8种异常情况（密码错、账号不存在、账号锁定、验证码过期……），UI层留1条走通，剩下7种下沉到接口层参数化，1条代码顶8条。
第四步，能下沉的全下沉。
这是砍得最狠的一刀。下单主流程，UI只留1条端到端走通，剩下15个分支（各种优惠组合、库存不足、地址超区、发票类型）全部在接口层跑。接口层跑完15个分支大概40秒，UI层跑完要9分钟。
砍完之后的数字对比：
| 指标 | 砍之前 | 砍之后 |
|---|---|---|
| 用例数 | 1200 | 180 |
| 单次全量执行 | 47分钟 | 8分20秒 |
| 失败率 | 32% | 4.7% |
| 失败中真实bug占比 | 12% | 61% |
| 每周维护工时 | 约11小时 | 约1.5小时 |
最关键的变化其实不在表里：失败率降到4.7%之后，开发开始认真看我的报告了。之前32%失败率的时候，我在群里发报告，大家的反应是「哦，又是自动化挂了」。现在4.7%，一红就是真问题，开发会主动来问。
这个信任感，比覆盖率从80%涨到95%值钱得多。
什么情况下不该砍
得说清楚，我这套逻辑不是万能的，有两种情况我不建议动手。
一种是团队只有1到2个测试，且完全没有接口测试能力。这种情况下UI自动化是你唯一能挡住回归的手段，哪怕维护成本高也得先扛着，优先要做的不是砍用例，是先补接口测试的基础设施。
另一种是产品形态本身就是重UI交互，比如在线设计工具、编辑器、图形类应用，很多bug只在渲染层和交互层出现，接口层根本验不出来。这类项目UI自动化的密度该高还是得高，但可以换个思路，用视觉回归（比如 Playwright 的截图对比）替代大量的DOM断言，成本低很多。
还有个坑我踩过：砍用例之前一定要先跑一遍全量，把当前能过的用例打上tag存起来。我当时砍完第二周，线上出了个地址簿的bug，是P2级别，结果发现我把验证它的那条用例删了。后来复盘，那条用例三个月有效失败率是0，按我的标准就该删，但业务上它确实是个风险点。所以纯数据驱动决策是有盲区的，最好拉上产品一起过一遍删除清单。
最后说点别的
我们团队的KPI改过一次。之前考核「缺陷数」，结果测试和开发天天吵「这算不算bug」，一个文案问题能来回扯三轮。后来换成「线上逃逸缺陷数」和「缺陷平均修复时长」，吵架少了一大半。指标这东西，你怎么定，大家就怎么演。
至于自动化覆盖率，我现在看到这个词会有点条件反射。覆盖率是个过程指标，它很容易被刷，而且刷高了对质量没什么实际帮助。真要看，我更愿意看另一个数：你的自动化报告里，红色的时候有多少次是开发真的改代码了。如果十次红有八次开发不理你，那这套自动化，说实话就是白跑的。