2024年Q2我带着测试团队做了一件在很多人看来有点“自毁长城”的事把整整50%的自动化脚本从回归体系里删掉了。焦头烂额地维护了三个月之后版本的交付速度反而提升了接近30%。这不是段子也不是标题党是我在软件测试这行摸爬滚打快十年踩过最深的一个坑之后换来的教训。我见过太多团队把“自动化覆盖率”当成KPI脚本数量越堆越多全量回归从2小时拖到8小时每天光修脚本就要耗掉半天。然后所有人都在感叹自动化怎么越做越累交付怎么越来越慢这篇东西我想把自己做“减法”的完整思路、删脚本的评分标准、以及删完之后靠什么兜底质量的经验一次性说清楚。不管你是刚入行的测试新人还是正在带团队的测试负责人这篇文章应该都能帮你避开一些我踩过的坑。1. 先复盘当初那些脚本到底是怎么堆起来的1.1 录制回放“起步”时的爽感最后都成了债说到脚本增长就绕不开很多团队的自动化第一步——录制回放。我记得2017年刚在上一家公司带自动化项目时团队里没人写过代码我用Selenium IDE对着Web端点了一遍注册登录流程一个完整的脚本就出来了。老板看得很兴奋当场拍板“以后每个核心流程都录一套。”那段时间确实爽一个上午能产出一二十条用例覆盖率报表做得漂漂亮亮。但很快问题就来了。录出来的脚本里全是绝对路径的xpath/html/body/div[2]/div[3]/form/input[1]这种前端只要加一层div脚本就崩。当时最崩溃的一次前端同学只是把登录框的id从username改成了user_name直接一条链路带崩了十几个脚本。我后来经常跟人说录制回放适合做demo、做探索但绝对不适合当核心回归资产来长期扛。这些用录制方式堆起来的脚本本质上是在借高利贷快手快脚赚来的覆盖率后面要用十倍的时间去还维护债。1.2 “覆盖率越高越好”是职场上最温柔的陷阱另一个把脚本数量推上去的推手是覆盖率指标。公司要数据测试团队就要把“核心业务自动化覆盖率”从60%做到80%、90%。为了达标大家什么场景都要补脚本一个月才跑一次的报表导出两年没改过的历史数据查询页面甚至还有一个“验证密码框回车不提交表单”的边界用例也被塞进了日常回归集。这里就出现了一个很微妙的心理脚本数量越多团队就越觉得有安全感。我那时候也有这种错觉总觉得只要回归集够大漏测的黑锅就追不上我。可实际上这跟“用1000个闹钟叫自己起床”是一个道理——闹钟越多你越会依赖“总有下一个会响”反而放松了对最重要那个闹钟的核对。回归集越臃肿真正的核心链路反而被淹没在大量低价值用例里出了问题你要花很长时间才能从几十个红灯里找到真正致命的那一个。1.3 所有人都在假装不知道的维护成本账真正的炸点是维护成本。我做一个粗算大家感受一下假设你有400个UI自动化脚本按经验数据每次业务迭代大约有10%到20%的脚本会因为页面改动、文案调整、元素重构而出现失败。哪怕只有10%一次迭代下来就是40条脚本要排查。每条脚本从看日志、复现问题、更新定位符、回归验证平均需要20到30分钟。算下来一个迭代光维护这些脚本就要花掉16到20个人时。更隐蔽的是执行耗时。脚本从2小时跑完变成4小时再到8小时。CI流水线被自动化任务堵得死死的开发合一次代码要排队等结果。反馈越慢问题暴露得越晚修复成本越高。我后来才意识到当时我们根本不是在做质量保障而是天天在给一堆脚本当保姆。喂食、洗澡、铲屎忙得团团转狗粮钱花了不少真正看家的时刻却没几次。2. 为什么脚本删掉一半交付速度反而上来了2.1 自动化覆盖率不是越高越好是“越准越好”先理清一个底层认知自动化的价值不在于“跑得多”而在于“跑得准”。一个测试用例值不值得自动化核心看两件事第一它是不是在守护核心业务逻辑第二它是不是足够稳定可以反复验证同一件事。我删掉的脚本里有相当一部分属于“伪核心”——当初为了凑覆盖率硬塞进来的边缘场景。比如某个管理后台的“用户列表导出Excel”功能看起来在跑但它依赖的是一份测试环境里几年都没变过的历史数据导出结果也没人校验断言只写了个“页面出现下载按钮”。这种用例跑了等于没跑一旦环境和数据变化它还会报错花人力去查最后发现是环境问题。它不产生任何质量价值却持续制造维护噪音。2.2 脚本维护的“脏活累活”正在悄悄吃掉你的交付人力我算过一笔真实的人效账删脚本之前我们团队每周有整整一天半是耗在“修回归脚本”上的。不是在写新功能测试不是在做探索性测试而是在跟ElementNotVisibleException、TimeoutException做斗争。这些时间的本质是把“测试人力”花在了“维持自动化系统勉强能跑”这个零产出目标上。删除50%的脚本之后最明显的变化是我们的修脚本时间从一天半降到了两个小时。省下来的时间我们重新投入到了手工探索测试和接口测试里。结果是版本发布前的缺陷密度反而下降了。这件事让我彻底想明白了一个道理测试团队的第一交付物是“质量信息”不是“脚本数量”。当你花在维护工具上的时间挤占了你获取质量信息的时间自动化不仅无益反而有害。2.3 测试金字塔倒置是慢的根源翻车最多的团队基本都是同一个姿势摔的测试金字塔完全倒过来——上面UI层堆了一堆脚本下面单元测试和接口测试几乎为零。这是个结构性问题。UI层脚本本身就有三个天然短板慢、脆、远。跑一个UI用例要启动浏览器、加载页面、等待网络动辄30秒到1分钟一个前端小改动就能让它“裂开”出了问题你要从前端一路排查到接口再到数据库链路很长。而接口测试呢一个用例跑完只要几秒钟依赖少稳定。我曾经把同一个业务场景分别写成UI脚本和接口脚本UI版平均耗时45秒接口版只需要2秒。同样的业务覆盖效率差了二十倍。2.4 反馈循环变短才是交付速度提升的真相删除脚本之后我们的CI流水线从“全量UI回归1小时40分钟”降到了“提交阶段10分钟冒烟合并阶段15分钟核心链路”。这个变化反映到开发侧是极其致命的以前开发提完一个MR可能要刷半小时甚至更久才能看到结果现在他们只需要等一杯咖啡的时间就能知道自己的改动有没有搞挂核心流程。反馈循环变短开发同学就愿意更频繁地提交代码集成冲突自然变少。代码review和联调的节奏也明显变快。所以说到底交付速度不是被“测试工作量”卡住的而是被“反馈等待时间”卡住的。我们用更少的脚本换来了更短的反馈周期这买卖怎么算都划算。3. 删脚本实战到底怎么判定谁该留、谁该扔3.1 第一步先给自动化资产做一次全面“体检”别一上来就拍脑袋删先盘家底。我当时做了一个Excel拉出了所有自动化用例的明细清单字段包括用例名、所属模块、关联需求/业务场景、最近30天执行次数、最近30天失败率、平均执行时长、最后维护时间、维护人、维护原因备注、是否核心链路、是否POM规范。你会惊讶地发现很多脚本在清单里一躺就是半年压根没人知道它是干嘛的。这份清单逼着我们回答一个尖锐的问题每条脚本到底是“资产”还是“负债”我给自己定了一个简单的判断规则如果一条脚本过去30天从未在关键决策中提供过有效信息并且每次失败都要花人力去排查那它大概率是“负债型脚本”。负债型脚本留着没有任何意义它唯一的贡献是让自动化报表看起里去更丰满。3.2 第二步用四个维度给每条脚本打分体检完原始数据我建了一个傻瓜式评分表。四个维度每个维度1到5分总分20分维度打分标准业务价值核心交易链路5分高频功能4分低频但合规3分低频低风险2分纯演示场景1分稳定性过去30天零失败5分失败率低于5%记4分低于15%记3分高于30%记1分维护成本完全POM且定位清晰5分基本POM但有硬编码4分混合定位隐式等待3分录制脚本未重构2分超长脚本无人能看懂1分执行效率30秒以内5分1分钟以内4分3分钟以内3分5分钟以上1分怎么用这个表总分低于10分的直接进淘汰名单10到14分的降级为“按需执行”从日常回归集挪到夜间巡检或里程碑回归15分以上的重点保留并继续优化。我当时筛完600多条UI脚本里有接近280条总分不到10分另外还有四五十条在“降级”区间。这个结果说实话把老板吓了一跳但也成功说服了他——数据摆在那里比任何口号都有力。3.3 第三步分三轮执行而不是一次砍光真正动手删的时候我没有选择“一刀切”。一次性删掉300条脚本万一出问题责任谁都扛不住而且团队士气也会崩。我设计了三轮递进方案。第一轮删的是“录制回放未重构”的脚本大概有七八十条。这些脚本当初就是赶工期的产物定位符丑、代码路径乱、几乎没有任何逻辑封装纯纯的毒资产。第二轮删的是“重复覆盖”的脚本比如三个不同页面用了同一套登录逻辑脚本、五条用例在断言同一个页面标题的情况这类也是七八十条。第三轮也就是真正硬核的是删掉那批“业务价值低维护成本高”的脚本再砍掉一百二三十条。每轮删完之后当时被标记为“待定观察”的脚本先禁用在流水线里跑两个迭代。如果两个迭代的生产事故、漏测数据和反馈都没有证明它不可替代那就可以心安理得地从代码库里删掉。采用这种渐进式方案最直接的好处是团队有足够时间观察风险同时也能在心理上接受“删脚本≠不测”。3.4 第四步怎么顶住“删了自动化质量谁来保证”的灵魂拷问任何砍脚本的行为都会迎来这句话“脚本删了回归谁做出问题谁负责”我的应对思路是不要让别人觉得你在“砍质量保障”要让别人看到你在“优化质量保障结构”。我给管理层展示了两张图第一张是“自动化资产健康度分布”说明哪些脚本在有效运转、哪些在空转第二张是“风险覆盖矩阵”把核心业务路径、重要非核心路径、低风险路径三个层级分别用自动化、半自动化和手工回归的方式做了明确定位。比如支付链路、登录鉴权、库存扣减这些核心路径自动化覆盖不仅没减还加强了而那些低频、低风险的路径则改成了双月手工回归。沟通的关键词不是“省钱”而是“聚焦”。让老板理解我们不是不测了是把有限的资源从无效的脚本维护挪到了真正能发现Bug的地方。4. 删完之后我们靠什么兜住质量不塌方4.1 把测试重心从UI层坚决地搬到接口层删脚本的同时我把团队的主要自动化投入方向转向了接口测试。技术栈用的是Python Requests pytest这套经典组合对大多数团队来说足够成熟、足够稳。接口测试天然比UI测试快、稳、便宜一个核心交易链路的接口用例跑起来两三秒就出结果断言清楚定位快速。这里要特别说明一点接口测试不是说把基础的增删改查跑一遍就完事了而是要覆盖业务状态流转和异常分支。比如“下单→支付→回调→发货”这条链路接口层能把中途任何一步的状态异常抓出来。这个层面稳定之后UI层只守护最关键的端到端路径数量不多但是精准。真要我给一个配比建议的话我倾向于核心项目自动化用例中接口用例占60%到70%UI用例只占20%到30%剩下留给契约和冒烟场景。这个比例远比“全是UI脚本”健康得多。4.2 留下来的UI脚本全部按POM模式重构一遍删完脚本并不是终点留下来的“精英脚本”也需要提高质量否则时间一长老问题会卷土重来。我给留下的脚本做了统一规范核心就是Page Object ModelPOM模式。页面层用Page Object封装元素定位和交互动作业务层写操作用例测试数据单独抽出来放在配置文件或Excel里。这样页面上一个按钮改了只需要去对应Page Object里改一处而不是满项目搜xpath。同时我用显式等待替代了到处乱写的time.sleep(3)。显式等待是“等到某个元素出现再继续”sleep是“闭眼睡3秒”两者的效率和对环境的适应能力天差地别。重构后同样的核心链路脚本执行时间平均缩短了30%到40%稳定性也有了质的变化。这里有个关键心得自动化脚本的代码质量直接影响它的维护成本。哪怕是删到只剩300条如果不重构半年后又会重新变成300条“债务”。4.3 测试数据的隔离是稳定性最大的隐形杀手脚本跑得不稳定的原因很多时候根本不是代码问题而是测试数据互相打架。我们之前试过A用例下单后生成了订单B用例查询“本月订单列表”时把A的订单也查出来了断言数量一多就挂。这种跨用例的数据耦合是UI脚本不稳定的大头来源。删减之后我们做了两件整改第一所有UI用例跑完后用API做数据清理或者通过数据库事务回滚尽量保证用例之间不共享可变业务数据第二用例需要依赖前置数据时优先通过接口调用造数而不是用UI流程一步一步点。比如“待支付订单列表”这个页面要测试我们就走接口批量造10个待支付订单直接进页面校验展示逻辑而不是在UI前面跑10遍下单流程。这一改动下来回归效率和稳定率又上了一个台阶。4.4 CI流水线里自动化的定位从“全量挡板”变成“分级滤网”删脚本过程中我们还重构了CI流水线里的自动化策略。之前是“所有脚本一次跑完、结果一把梭”现在是分三级来跑。提交阶段只跑冒烟测试和静态代码检查控制在10分钟以内让开发拿到快速反馈合并阶段跑接口全量测试加UI核心链路也就20分钟左右完整的UI回归集放到每晚定时任务去跑。这样既保留了深层回归能力又不拖慢日间开发迭代的节奏。我用一个比喻来跟团队解释这个设计以前安检口只有一条队伍所有人都要排一两个小时现在分成“无行李快速通道”和“全量安检通道”大部分人能快速通过少量重点人员才走全量检查。测试资源本来就有限好钢要用在刀刃上。5. 常见问题与排查技巧实录5.1 脚本“今天绿、明天红”怎么锁定问题这种flaky用例是最磨人的。修复它的第一步不是改代码而是收集信息。我要求所有用例失败时必须自动保存三个东西失败时的全屏截图、浏览器Console报错日志、还有当时的页面HTML快照。有了这三样80%的问题都能快速定位。从原因分类上看UI脚本不稳定的前三名通常都是元素定位方式不健壮、页面加载太快导致等待不足、以及数据问题。元素定位我这里有一个很实用的习惯能用id就用id没有id优先用>
2024年Q2我带着测试团队做了一件在很多人看来有点“自毁长城”的事把整整50%的自动化脚本从回归体系里删掉了。焦头烂额地维护了三个月之后版本的交付速度反而提升了接近30%。这不是段子也不是标题党是我在软件测试这行摸爬滚打快十年踩过最深的一个坑之后换来的教训。我见过太多团队把“自动化覆盖率”当成KPI脚本数量越堆越多全量回归从2小时拖到8小时每天光修脚本就要耗掉半天。然后所有人都在感叹自动化怎么越做越累交付怎么越来越慢这篇东西我想把自己做“减法”的完整思路、删脚本的评分标准、以及删完之后靠什么兜底质量的经验一次性说清楚。不管你是刚入行的测试新人还是正在带团队的测试负责人这篇文章应该都能帮你避开一些我踩过的坑。1. 先复盘当初那些脚本到底是怎么堆起来的1.1 录制回放“起步”时的爽感最后都成了债说到脚本增长就绕不开很多团队的自动化第一步——录制回放。我记得2017年刚在上一家公司带自动化项目时团队里没人写过代码我用Selenium IDE对着Web端点了一遍注册登录流程一个完整的脚本就出来了。老板看得很兴奋当场拍板“以后每个核心流程都录一套。”那段时间确实爽一个上午能产出一二十条用例覆盖率报表做得漂漂亮亮。但很快问题就来了。录出来的脚本里全是绝对路径的xpath/html/body/div[2]/div[3]/form/input[1]这种前端只要加一层div脚本就崩。当时最崩溃的一次前端同学只是把登录框的id从username改成了user_name直接一条链路带崩了十几个脚本。我后来经常跟人说录制回放适合做demo、做探索但绝对不适合当核心回归资产来长期扛。这些用录制方式堆起来的脚本本质上是在借高利贷快手快脚赚来的覆盖率后面要用十倍的时间去还维护债。1.2 “覆盖率越高越好”是职场上最温柔的陷阱另一个把脚本数量推上去的推手是覆盖率指标。公司要数据测试团队就要把“核心业务自动化覆盖率”从60%做到80%、90%。为了达标大家什么场景都要补脚本一个月才跑一次的报表导出两年没改过的历史数据查询页面甚至还有一个“验证密码框回车不提交表单”的边界用例也被塞进了日常回归集。这里就出现了一个很微妙的心理脚本数量越多团队就越觉得有安全感。我那时候也有这种错觉总觉得只要回归集够大漏测的黑锅就追不上我。可实际上这跟“用1000个闹钟叫自己起床”是一个道理——闹钟越多你越会依赖“总有下一个会响”反而放松了对最重要那个闹钟的核对。回归集越臃肿真正的核心链路反而被淹没在大量低价值用例里出了问题你要花很长时间才能从几十个红灯里找到真正致命的那一个。1.3 所有人都在假装不知道的维护成本账真正的炸点是维护成本。我做一个粗算大家感受一下假设你有400个UI自动化脚本按经验数据每次业务迭代大约有10%到20%的脚本会因为页面改动、文案调整、元素重构而出现失败。哪怕只有10%一次迭代下来就是40条脚本要排查。每条脚本从看日志、复现问题、更新定位符、回归验证平均需要20到30分钟。算下来一个迭代光维护这些脚本就要花掉16到20个人时。更隐蔽的是执行耗时。脚本从2小时跑完变成4小时再到8小时。CI流水线被自动化任务堵得死死的开发合一次代码要排队等结果。反馈越慢问题暴露得越晚修复成本越高。我后来才意识到当时我们根本不是在做质量保障而是天天在给一堆脚本当保姆。喂食、洗澡、铲屎忙得团团转狗粮钱花了不少真正看家的时刻却没几次。2. 为什么脚本删掉一半交付速度反而上来了2.1 自动化覆盖率不是越高越好是“越准越好”先理清一个底层认知自动化的价值不在于“跑得多”而在于“跑得准”。一个测试用例值不值得自动化核心看两件事第一它是不是在守护核心业务逻辑第二它是不是足够稳定可以反复验证同一件事。我删掉的脚本里有相当一部分属于“伪核心”——当初为了凑覆盖率硬塞进来的边缘场景。比如某个管理后台的“用户列表导出Excel”功能看起来在跑但它依赖的是一份测试环境里几年都没变过的历史数据导出结果也没人校验断言只写了个“页面出现下载按钮”。这种用例跑了等于没跑一旦环境和数据变化它还会报错花人力去查最后发现是环境问题。它不产生任何质量价值却持续制造维护噪音。2.2 脚本维护的“脏活累活”正在悄悄吃掉你的交付人力我算过一笔真实的人效账删脚本之前我们团队每周有整整一天半是耗在“修回归脚本”上的。不是在写新功能测试不是在做探索性测试而是在跟ElementNotVisibleException、TimeoutException做斗争。这些时间的本质是把“测试人力”花在了“维持自动化系统勉强能跑”这个零产出目标上。删除50%的脚本之后最明显的变化是我们的修脚本时间从一天半降到了两个小时。省下来的时间我们重新投入到了手工探索测试和接口测试里。结果是版本发布前的缺陷密度反而下降了。这件事让我彻底想明白了一个道理测试团队的第一交付物是“质量信息”不是“脚本数量”。当你花在维护工具上的时间挤占了你获取质量信息的时间自动化不仅无益反而有害。2.3 测试金字塔倒置是慢的根源翻车最多的团队基本都是同一个姿势摔的测试金字塔完全倒过来——上面UI层堆了一堆脚本下面单元测试和接口测试几乎为零。这是个结构性问题。UI层脚本本身就有三个天然短板慢、脆、远。跑一个UI用例要启动浏览器、加载页面、等待网络动辄30秒到1分钟一个前端小改动就能让它“裂开”出了问题你要从前端一路排查到接口再到数据库链路很长。而接口测试呢一个用例跑完只要几秒钟依赖少稳定。我曾经把同一个业务场景分别写成UI脚本和接口脚本UI版平均耗时45秒接口版只需要2秒。同样的业务覆盖效率差了二十倍。2.4 反馈循环变短才是交付速度提升的真相删除脚本之后我们的CI流水线从“全量UI回归1小时40分钟”降到了“提交阶段10分钟冒烟合并阶段15分钟核心链路”。这个变化反映到开发侧是极其致命的以前开发提完一个MR可能要刷半小时甚至更久才能看到结果现在他们只需要等一杯咖啡的时间就能知道自己的改动有没有搞挂核心流程。反馈循环变短开发同学就愿意更频繁地提交代码集成冲突自然变少。代码review和联调的节奏也明显变快。所以说到底交付速度不是被“测试工作量”卡住的而是被“反馈等待时间”卡住的。我们用更少的脚本换来了更短的反馈周期这买卖怎么算都划算。3. 删脚本实战到底怎么判定谁该留、谁该扔3.1 第一步先给自动化资产做一次全面“体检”别一上来就拍脑袋删先盘家底。我当时做了一个Excel拉出了所有自动化用例的明细清单字段包括用例名、所属模块、关联需求/业务场景、最近30天执行次数、最近30天失败率、平均执行时长、最后维护时间、维护人、维护原因备注、是否核心链路、是否POM规范。你会惊讶地发现很多脚本在清单里一躺就是半年压根没人知道它是干嘛的。这份清单逼着我们回答一个尖锐的问题每条脚本到底是“资产”还是“负债”我给自己定了一个简单的判断规则如果一条脚本过去30天从未在关键决策中提供过有效信息并且每次失败都要花人力去排查那它大概率是“负债型脚本”。负债型脚本留着没有任何意义它唯一的贡献是让自动化报表看起里去更丰满。3.2 第二步用四个维度给每条脚本打分体检完原始数据我建了一个傻瓜式评分表。四个维度每个维度1到5分总分20分维度打分标准业务价值核心交易链路5分高频功能4分低频但合规3分低频低风险2分纯演示场景1分稳定性过去30天零失败5分失败率低于5%记4分低于15%记3分高于30%记1分维护成本完全POM且定位清晰5分基本POM但有硬编码4分混合定位隐式等待3分录制脚本未重构2分超长脚本无人能看懂1分执行效率30秒以内5分1分钟以内4分3分钟以内3分5分钟以上1分怎么用这个表总分低于10分的直接进淘汰名单10到14分的降级为“按需执行”从日常回归集挪到夜间巡检或里程碑回归15分以上的重点保留并继续优化。我当时筛完600多条UI脚本里有接近280条总分不到10分另外还有四五十条在“降级”区间。这个结果说实话把老板吓了一跳但也成功说服了他——数据摆在那里比任何口号都有力。3.3 第三步分三轮执行而不是一次砍光真正动手删的时候我没有选择“一刀切”。一次性删掉300条脚本万一出问题责任谁都扛不住而且团队士气也会崩。我设计了三轮递进方案。第一轮删的是“录制回放未重构”的脚本大概有七八十条。这些脚本当初就是赶工期的产物定位符丑、代码路径乱、几乎没有任何逻辑封装纯纯的毒资产。第二轮删的是“重复覆盖”的脚本比如三个不同页面用了同一套登录逻辑脚本、五条用例在断言同一个页面标题的情况这类也是七八十条。第三轮也就是真正硬核的是删掉那批“业务价值低维护成本高”的脚本再砍掉一百二三十条。每轮删完之后当时被标记为“待定观察”的脚本先禁用在流水线里跑两个迭代。如果两个迭代的生产事故、漏测数据和反馈都没有证明它不可替代那就可以心安理得地从代码库里删掉。采用这种渐进式方案最直接的好处是团队有足够时间观察风险同时也能在心理上接受“删脚本≠不测”。3.4 第四步怎么顶住“删了自动化质量谁来保证”的灵魂拷问任何砍脚本的行为都会迎来这句话“脚本删了回归谁做出问题谁负责”我的应对思路是不要让别人觉得你在“砍质量保障”要让别人看到你在“优化质量保障结构”。我给管理层展示了两张图第一张是“自动化资产健康度分布”说明哪些脚本在有效运转、哪些在空转第二张是“风险覆盖矩阵”把核心业务路径、重要非核心路径、低风险路径三个层级分别用自动化、半自动化和手工回归的方式做了明确定位。比如支付链路、登录鉴权、库存扣减这些核心路径自动化覆盖不仅没减还加强了而那些低频、低风险的路径则改成了双月手工回归。沟通的关键词不是“省钱”而是“聚焦”。让老板理解我们不是不测了是把有限的资源从无效的脚本维护挪到了真正能发现Bug的地方。4. 删完之后我们靠什么兜住质量不塌方4.1 把测试重心从UI层坚决地搬到接口层删脚本的同时我把团队的主要自动化投入方向转向了接口测试。技术栈用的是Python Requests pytest这套经典组合对大多数团队来说足够成熟、足够稳。接口测试天然比UI测试快、稳、便宜一个核心交易链路的接口用例跑起来两三秒就出结果断言清楚定位快速。这里要特别说明一点接口测试不是说把基础的增删改查跑一遍就完事了而是要覆盖业务状态流转和异常分支。比如“下单→支付→回调→发货”这条链路接口层能把中途任何一步的状态异常抓出来。这个层面稳定之后UI层只守护最关键的端到端路径数量不多但是精准。真要我给一个配比建议的话我倾向于核心项目自动化用例中接口用例占60%到70%UI用例只占20%到30%剩下留给契约和冒烟场景。这个比例远比“全是UI脚本”健康得多。4.2 留下来的UI脚本全部按POM模式重构一遍删完脚本并不是终点留下来的“精英脚本”也需要提高质量否则时间一长老问题会卷土重来。我给留下的脚本做了统一规范核心就是Page Object ModelPOM模式。页面层用Page Object封装元素定位和交互动作业务层写操作用例测试数据单独抽出来放在配置文件或Excel里。这样页面上一个按钮改了只需要去对应Page Object里改一处而不是满项目搜xpath。同时我用显式等待替代了到处乱写的time.sleep(3)。显式等待是“等到某个元素出现再继续”sleep是“闭眼睡3秒”两者的效率和对环境的适应能力天差地别。重构后同样的核心链路脚本执行时间平均缩短了30%到40%稳定性也有了质的变化。这里有个关键心得自动化脚本的代码质量直接影响它的维护成本。哪怕是删到只剩300条如果不重构半年后又会重新变成300条“债务”。4.3 测试数据的隔离是稳定性最大的隐形杀手脚本跑得不稳定的原因很多时候根本不是代码问题而是测试数据互相打架。我们之前试过A用例下单后生成了订单B用例查询“本月订单列表”时把A的订单也查出来了断言数量一多就挂。这种跨用例的数据耦合是UI脚本不稳定的大头来源。删减之后我们做了两件整改第一所有UI用例跑完后用API做数据清理或者通过数据库事务回滚尽量保证用例之间不共享可变业务数据第二用例需要依赖前置数据时优先通过接口调用造数而不是用UI流程一步一步点。比如“待支付订单列表”这个页面要测试我们就走接口批量造10个待支付订单直接进页面校验展示逻辑而不是在UI前面跑10遍下单流程。这一改动下来回归效率和稳定率又上了一个台阶。4.4 CI流水线里自动化的定位从“全量挡板”变成“分级滤网”删脚本过程中我们还重构了CI流水线里的自动化策略。之前是“所有脚本一次跑完、结果一把梭”现在是分三级来跑。提交阶段只跑冒烟测试和静态代码检查控制在10分钟以内让开发拿到快速反馈合并阶段跑接口全量测试加UI核心链路也就20分钟左右完整的UI回归集放到每晚定时任务去跑。这样既保留了深层回归能力又不拖慢日间开发迭代的节奏。我用一个比喻来跟团队解释这个设计以前安检口只有一条队伍所有人都要排一两个小时现在分成“无行李快速通道”和“全量安检通道”大部分人能快速通过少量重点人员才走全量检查。测试资源本来就有限好钢要用在刀刃上。5. 常见问题与排查技巧实录5.1 脚本“今天绿、明天红”怎么锁定问题这种flaky用例是最磨人的。修复它的第一步不是改代码而是收集信息。我要求所有用例失败时必须自动保存三个东西失败时的全屏截图、浏览器Console报错日志、还有当时的页面HTML快照。有了这三样80%的问题都能快速定位。从原因分类上看UI脚本不稳定的前三名通常都是元素定位方式不健壮、页面加载太快导致等待不足、以及数据问题。元素定位我这里有一个很实用的习惯能用id就用id没有id优先用>
