1. 先说结论我亲手砍掉了团队一半的自动化脚本今年年初我做了一个在测试组内部引起不小争议的决定——把维护了大半年的自动化脚本删掉了将近一半。不是重构不是优化是真的从代码库里移除。当时有同事当面问我“咱们加班加点写的脚本你说删就删”我当时的回答是“正因为是自己写的才更清楚哪些该留、哪些该埋。”这事还得从头说起。我们团队负责的是一个面向B端客户的业务系统Web端为主App端为辅功能模块多、版本迭代快。测试组高峰期维护着600多条自动化用例覆盖了核心业务链路、模块级回归、UI冒烟甚至一些边角料场景。听起来很完整对吧但实际上团队每个人心里都清楚这套自动化体系正在把交付速度拖慢。先说数据。我删脚本之前做了统计过去三个迭代周期里全量自动化回归的平均执行时间接近4个小时但有效发现缺陷的比例只有不到2%。更扎心的是这个“有效缺陷”里还有一半是靠新增的用例发现的老脚本几乎颗粒无收。与此同时每次版本发布前团队为了等那4个小时的执行结果经常把提测和发布节点往后推。这不是我们一家的问题。很多测试团队都会陷入一个“自动化越多越好”的思维惯性里觉得用例数量代表了质量保障的力度。但真实情况是自动化测试存在一个非常明显的边际效益递减曲线——当用例数量超过某个阈值后新增脚本带来的质量收益会急剧下降而维护成本、执行耗时、结果分析的负担却在持续增长。这个阈值取决于业务稳定性、用例质量、框架选型和团队维护能力不是一个固定值。我当时做的最重要的一步就是把这个“效率悖论”摆到台面上来我们到底是为了自动化而自动化还是为了让交付更快、质量更稳想清楚这个问题砍脚本这件事就只是时间问题了。2. 自动化脚本的隐性成本为什么用得越多反而越慢2.1 维护成本脚本不是写完就完事很多刚入行的测试工程师会忽略一个事实自动化用例的编写时间可能只占整个生命周期成本的20%~30%剩下的全是维护成本。业务在变页面DOM结构在变接口参数在变权限逻辑在变。前端工程师一个看似无关紧要的class命名调整就可能让十几个UI脚本集体飘红。后端接口加了一个必填字段接口自动化用例全部报参数错误。这些都不是脚本写得“好”就能避免的因为业务本身就在持续演进。我做过一次统计我们团队在迭代最密集的时候平均每个自动化用例每个月要被修改1.2次。600条用例意味着每个迭代周期光花在修脚本上的时间就接近40人/天。这些时间本可以用来做探索性测试、做性能测试、做测试平台的二次开发结果全被脚本维护吞掉了。2.2 执行时间全量回归变成了一种负担第二个被忽略的成本是执行时间。很多人觉得自动化跑起来不用人管挂在Jenkins上就好了。但实际的痛点是执行耗时长会直接影响发布节奏。我们当时的全量回归是串行跑的UI端4个小时、接口端1.5个小时、App端还要再挂2个小时的真机集群。三个平台加起来接近8个小时。这意味着什么如果上午10点提测测试人员需要等到晚上才能看到完整的回归结果。发布前如果要做全量回归就必须提前一天把所有代码冻结。为了缩短执行时间我们试过并行执行、分布式执行、按标签筛选执行等等方案确实有效果但只是把执行时间压到了3个小时左右并没有解决核心矛盾——大量脚本本身就是在重复验证那些已经稳定了很久的功能。2.3 稳定性问题Flaky用例是团队的信任杀手这里要单独拎出来说的是Flaky用例不稳定用例。一个用例这次能过、下次不能过没有任何代码改动纯粹因为等待时间不够、元素定位偶发失败、环境抖动等原因。这类用例对交付速度的拖累远超想象。Flaky用例的最大危害不是“多花了几分钟重跑”而是它摧毁了整个团队对自动化结果的信任。当“红了”不再意味着“真的有缺陷”时测试人员就会养成“看到失败先怀疑脚本”的习惯这会带来两个后果一是真正的缺陷可能被当成误报忽略掉二是每轮回归后的结果分析时间被大幅拉长。我当时手动标记了近三个月的所有失败用例逐一分析失败原因发现稳定复现的脚本缺陷只占38%环境因素占22%剩下的40%全是Flaky——等待超时、元素偶发找不到、数据冲突。也就是说近一半的脚本失败信息是噪音需要人工去过滤。2.4 认知负担结果分析也是成本很多人算自动化ROI的时候只算执行时间、脚本编写时间完全忽略了结果分析时间。600条用例的执行会产生多少条失败记录全量回归下来少则十几条多则几十条。每条失败记录都需要人肉判断是脚本问题还是产品缺陷是环境问题还是数据污染这个判断过程需要登录系统、复现步骤、查看日志单条的平均处理时间可能在15~30分钟。我曾经让团队记录过一周的时间消耗结果分析占了测试组35%的工作时长。这是个非常恐怖的数字——自动化本意是替人省时间结果省下来的时间又被它的副产物失败记录吃掉了大半。3. 效率悖论的底层逻辑自动化收益递减的那些临界点3.1 收益递减曲线数量和质量不是线性关系自动化测试的收益曲线有一个典型特征在用例数量从0增长到某个拐点时每一单位投入带来的质量保障效果是递增或持平的但一旦越过拐点新增用例的边际收益开始快速下降而成本却继续线性或超线性增长。这个拐点在哪取决于几个因素业务迭代速度迭代越快脚本失效越快拐点来得越早系统的UI稳定性前端频繁改样式的系统UI脚本的拐点会非常早用例间的耦合度共享数据、共享状态的用例越多维护成本越高团队的自动化经验对框架熟悉度高、能熟练处理定位问题的团队可以推迟拐点以我们团队为例业务高峰期每周一个迭代版本前端几乎每两个版本就会有一次DOM结构调整。这种节奏下UI层的用例拐点来得非常早——大约在200条左右就开始感觉到明显的收益下滑。接口层的拐点会晚一些因为接口协议相对稳定。我砍脚本的决策依据不是拍脑袋而是先给每条用例做了收益评估再画出整个用例库的“收益-成本分布图”。不画不知道一画吓一跳——底部30%的用例贡献了70%的维护成本而顶部20%的用例贡献了80%的缺陷发现量。这是典型的二八法则但比二八法则更极端。3.2 自动化与手工的定位差异很多场景根本不适合自动化另一个层面是“适合自动化”和“不适合自动化”的边界问题。这是很多测试团队会在初期忽视、后期又不好意思承认的。适合自动化的场景有一个共同特征结果可预期、重复性高、数据稳定。比如登录、注册流程、订单状态流转、权限控制这类核心主链路每次跑的结果应该是一样的脚本的价值在于用机器替代人工做重复验证。不适合自动化的场景也很有规律探索式验证需要测试人员实时分析、随机应变的场景视觉/交互体验主观性强的UI反馈数据强依赖场景前置数据链路过长、难以稳定构造的复杂业务低频高复杂度场景一年只回归几次的冷门功能我们团队之前最典型的错误就是试图把探索性测试的活强行自动化。用脚本去执行一些需要人为判断“这个页面表现是否合理”的用例结果就是脚本只能验证“按钮存在”验证不了“按钮放这里是否合理”。这类用例既占维护额度又给不了有效反馈。3.3 快与稳的正确理解自动化是手段不是目的再往深一层说这个悖论的本质是对“快”的定义产生了偏差。团队早期想得很简单自动化能跑得比人快所以自动化就能让交付变快。但实际交付链路里自动化只是质量反馈的一个环节它真正的价值在于提供快速、稳定、可重复的回归验证而不是替代所有测试行为。删掉一半脚本后我们做了什么回归时长从4小时降到了1.5小时结果分析时间从2小时降到了40分钟维护成本直接对半砍。省下来的时间被投回到探索性测试和核心链路的深度验证上两个迭代期后线上缺陷率不但没有上升反而因为测试人员更专注了下降了将近30%。这就是效率悖论最反直觉的地方你以为删掉保障措施会降低质量实际上是把资源从低效的重复劳动中解放出来重新投入到能真正发现问题的地方去了。4. 我评估脚本存废的四个维度到底该砍哪些脚本4.1 缺陷发现率看历史战绩说话我删脚本思维里最重要的一条原则是没有历史战绩的用例不配占用维护资源。具体做法是拉取过去半年的CI执行记录逐条统计每条用例的执行次数、失败次数、失败原因分类以及最重要的——是否因为这条用例的失败而发现了产品缺陷。凡是半年内从未发现过缺陷、且不属于核心链路冒烟范围的用例全部列入候选删除名单。这里要特别说明一下缺陷发现率为什么必须和“核心链路”放在一起看。有些用例虽然半年没抓到过缺陷但它覆盖的是登录、支付这种核心主链路不能因为没出过错就删——正因为它在盯着缺陷才没能上线。这类用例要保留但需要把执行频率降下来不需要每个迭代全量回归可以只在发布前跑。真正该砍的是那种“覆盖了一个冷门分支、三个月没执行过、当时是为了凑覆盖率而写”的用例。它们的存在对质量没有任何实质贡献却每个月都要花时间维护。4.2 执行稳定性Flaky比例高到一定程度就该淘汰这个维度的判断标准很直接如果一条用例在过去10次执行中失败了5次以上但最后定位下来都是脚本本身的问题而不是产品缺陷这条用例就应该被处理。处理方式不是直接删而是先尝试修复。如果修复后稳定性在可接受范围内我会看修复后的连续20次执行通过率低于90%就放弃就保留修不好或者修复成本高于重新写一条用例的成本就删掉重写或直接砍掉。我总是和团队强调一个观点一条不稳定的用例还不如没有这条用例。因为它除了消耗排查时间还会造成两个方向的误报——漏报真实缺陷或者让团队对失败信息麻木。4.3 与核心链路的关联度保留主干砍掉枝叶关联度评估是用例存废中主观性最强的一个维度但也是最能体现测试设计能力的地方。我当时的做法是把业务架构图铺开标出核心用户路径注册→登录→创建订单→支付→订单查询然后检查每条用例和这个主干路径的关系。直接覆盖主干路径的流程冒烟、主链路回归保留间接覆盖主干路径的模块级测试、关键子流程测试按业务重要性分级与主干路径没有清晰关联的长尾功能、低频业务、一次性场景基本都是删除候选。这里有一个容易踩的坑有些用例覆盖的功能现在已经不活跃了但业务方说“以后可能还会用”。遇到这种情况我的处理原则是未来可能用到的功能等它真的重做的时候再写自动化现在写就是纯消耗。低频功能的价值在“能跑通”不需要天天跑。4.4 维护成本与收益的量化对比ROI说了算最后一个维度是把前面的因素全部量化算ROI。我用的简化公式是单条用例的月均收益 该用例单次执行发现缺陷的概率 × 缺陷修复的平均成本 单条用例的月均成本 月均维护耗时 月均失败分析耗时 单次执行耗时 × 月执行次数虽然缺陷发现概率很难精确计算但用历史数据可以估一个近似值。比如某条用例过去半年执行了120次发现过2个缺陷那么它单次执行发现缺陷的概率大约是1.7%。缺陷平均修复成本我按2人/天估算。那么月均收益大概就是20次执行 × 1.7% × 2人天 ≈ 0.68人天。另一边这条用例一个月要维护1次0.5小时、失败分析0.5次0.5小时、执行耗时20分钟×20次6.7小时合计约7.7小时接近1人天。收益0.68人天成本1人天这笔账是亏的。但如果是核心链路用例缺陷发现概率可能到5%~10%而且缺陷的严重级别更高、修复成本可能翻倍那它的ROI就完全不同了。我把这个表格拉出来给团队看大家就心服口服了——不是靠行政命令砍脚本而是数据帮我们做了决定。5. 删掉之后怎么补位回归策略的重构与测试层次再设计5.1 分层的回归策略全量回归该退出历史舞台了删了脚本之后一个最直接的问题是回归覆盖变薄了怎么保证不引入线上问题我的答案是放弃“每次发布都全量回归”的思路改成按变更影响范围动态调整的分层回归策略。具体来说我们把回归测试分成三层第一层是核心链路冒烟覆盖登录、主流程、支付等关键链路约30~40条用例每个迭代执行执行时间控制在20~30分钟。这层用例要精、要稳、要最快给出反馈。第二层是变更影响面回归根据本次版本涉及的模块和接口变动动态选择相应的模块级用例和关联功能用例执行。这一层不追求全量追求精准用例数控制在100条左右。第三层是全量回归保留在发布候选版本前执行但频率从每个迭代一次降低为每个发布版本一次我们一般是每两到三个迭代出一个发布版本。这个策略最核心的价值是让自动化回归的执行频率和投入成本跟着实际风险走而不是机械地“每次都要跑完”。5.2 把省下来的时间投到探索性测试上砍脚本的另一个重要动作是把释放出来的人力重新导向探索性测试。探索性测试一直被很多团队低估。它不需要预先写脚本测试人员在理解业务的基础上自由地操作系统、设计场景、观察异常。这种测试方式在发现“设计层面的问题”“边界条件下的奇怪行为”“业务逻辑漏洞”方面的效率远超那些按部就班的自动化用例。我们团队过去把太多精力放在“如何让脚本不挂”上反而没多少时间去认真“玩”系统。删脚本释放出大约每周15人/天的工时后我重新排了测试计划每个迭代预留出固定时间做半小时到一个半小时的探索性测试覆盖当次版本的新功能和变更频繁的模块。两个迭代之后探索性测试发现的缺陷数量已经超过了自动化回归。这个数字不是暗示自动化没用而是说明我们之前把资源放错了位置。5.3 测试数据与测试环境的治理比脚本数量更重要的底层建设删除脚本后我们还做了一件之前一直被自动化脚本数量淹没的事测试数据和环境治理。很多脚本不稳定、失败率高根子不在脚本本身而在测试数据。用例A在跑“创建订单”之前需要数据库里有指定状态的用户、商品、优惠券但数据被用例B消费掉了于是A在同样的代码版本下一次失败一次成功反复横跳。过去团队解决这类问题的方式是修改脚本在用例里增加数据构造的步骤、增加重试机制、增加清理逻辑——这些措施加重了脚本复杂度进一步提高了维护成本但治标不治本。我们这次做了几个基础动作搭建独立的测试数据工厂提供统一的数据准备和清理接口梳理公共数据的使用规则不允许用例直接依赖共享数据把环境配置和版本发布流程规范化避免环境差异导致的不稳定。效果是立竿见影的不仅是删除后剩余用例的稳定性提升了连之前怎么修都修不好的Flaky问题也少了约一半。5.4 代码审查与CI流水线的联动把质量门禁前置最后一个“补位”思路是把质量保障的重心从“回归测试”往前移到“变更提交”阶段。我们做的最立竿见影的一步是在CI流水线里接入代码静态分析和单元测试覆盖率门禁。开发提交代码时自动触发质量不达标直接拦截合并请求等开发改完再重新跑。这样很多基础性问题空指针、资源未释放、明显的逻辑错误在提交阶段就被拦下了根本走不到系统测试这一层。做这个调整的真实感触是质量保障不是测试组单打独斗的事。自动化回归删减之后我们更清楚地认识到一个高效的质量体系应该把更多的验证责任放到离变更最近的环节让问题在最短的反馈循环内被解决而不是等到集成测试或者回归测试阶段才暴露。6. 踩过的坑和实战中的决策要点如果你想做同样的优化6.1 坑一盲目追求覆盖率指标删脚本过程中最大的阻力不是来自开发或产品而是来自团队自己人。质量部门有同事担心“用例数减半覆盖率掉了上面问起来怎么交代”我的回应是覆盖率只是一个过程指标不是质量结果。一个系统如果只是在用脚本反复验证那些已经被验证了无数次的功能覆盖率再高也说明不了任何问题。真正应该关注的是——缺陷逃逸率线上漏测率、发布后一周内的缺陷密度、以及单次回归的平均耗时。这里建议所有想动手做优化的团队先花一到两周时间把指标体系的定义和采集方案做好把“数量类指标”换成“效率质量类指标”后面的一切决策才有依据。6.2 坑二把“删除”做成“永久性”动作另一个值得提醒的点是删除脚本不是终点而是一个持续调优的过程。我当时并没有把所有判定为低价值的脚本直接物理删除而是先归档到一个单独的branch里标记为“deprecated”。这样做的原因是万一某个低频场景突然变成了核心场景比如业务方向调整、某功能被重新激活可以从归档区快速恢复。归档区脚本不参与CI执行不产生维护成本但保留了资产。三个月后确认这些场景确实不会在短期内回归才真正从代码库中移除。6.3 坑三忽略了团队的能力配置与情绪最后也最关键的一点是人的因素。大张旗鼓地“砍掉一半自动化”很容易给人造成一个错误印象自动化不重要了。有同事私下跟我说“是不是公司觉得写脚本没价值所以让咱们别写了”这种误解如果不及时疏导会造成团队士气波动甚至让后续的自动化建设工作更不受重视。我在这个过程中花了大量时间做三件事把每个删掉的脚本都在评审会上过一遍让所有人理解删除理由而不是看着某个人拍脑袋决定反复强调“删除是为了让剩下的自动化跑得更好”不是否定自动化的价值鼓励团队把省下来的时间用于学习接口自动化、性能测试、测试平台开发等更高杠杆的方向最终的效果也验证了这一点删除50%的脚本后剩下的脚本稳定性从78%提升到了96%回归时长降低了60%测试团队的整体交付能力反而上了一个台阶。团队的自动化能力和意识比600条臃肿的用例值钱得多。根据个人经验这类优化最适合在业务版本相对稳定、自动化体系已经明显出现“维护疲倦”的团队里做。如果你们的自动化建设还在早期、脚本数量远不足以覆盖核心业务那现在还远没到该考虑删脚本的时候。但只要你发现“维护脚本的时间和跑脚本的时间已经不成比例”或者“测试人员一听到全量回归就头疼”也许就是该重新审视整个自动化策略的信号了。