自动化测试中的环境治理 脚本跑挂的隐形元凶

上周跟个在互联网公司做测试的朋友喝咖啡，他对着手机皱着眉骂。团队攒了三个多月的300条自动化接口用例，本地跑全绿，一推到CI流水线就挂一半。

查了整整三天。

最后发现是其他组的人前一天在测试环境跑全链路压测，留了一堆没清的脏缓存。

太常见了。

很多人聊起自动化测试，张口就是脚本设计、断言逻辑、框架选型，好像只要把代码写好，测试就能顺顺当当跑起来。真到一线踩坑才知道，80%的自动化用例非预期失败，根因都不在代码本身。

先搞懂环境到底是怎么把测试搞崩的

你肯定碰到过这种场景。昨天还能跑通的用例，今天点一下直接报500。你以为是版本发炸了，冲去开发群反馈，人家拍着胸脯说本地测的好好的。折腾俩小时查日志，发现是测试环境的数据库，被运维临时切到了上个月的旧实例上。

说白了，大家默认测试环境是个“所有人都能进的公共大水池”。你倒点压测的脏数据，我改个配置参数，他拉个未合并的分支上去部署个半成品功能，没人主动记录这些改动。等自动化用例跑起来，根本不知道当前的环境状态是什么样的。

很多团队一开始图省事，就搭一套覆盖所有业务线的公共测试环境，所有人不管是做功能验证、压测还是临时调试，都往同一个实例上部署代码、改配置，省了初期搭环境的人力成本，代价就是每次自动化执行的时候，不可控的变量多到数不清。

你花在写脚本、调框架上的精力，最后可能抵不过别人随手改的一行超时配置。

别上来就搞什么全链路环境隔离

一提到环境治理，总有人跳出来说要做全链路隔离，要给每个自动化用例配一套独立的临时环境，跑完直接销毁，做到绝对干净。

听着特别美好对吧？

真算笔账就知道有多离谱。之前见过个团队，上来就搭了基于K8s的临时环境平台，每个用例启动前自动拉起一套完整的微服务集群。一套全量服务拉起来要12分钟，300条用例哪怕并行跑，也要占掉大半的服务器资源。CI队列排到三天后，钱花了不少，自动化的整体执行效率还不如之前。

真的，别被那些高大上的概念忽悠瘸了。

环境治理的核心从来不是追求绝对的干净，是把不可控的变量降到可预期的范围。

你根本不需要把所有服务都隔离开。只要把自动化用例依赖的几个核心组件，每次跑之前重置到固定的已知状态就行。比如跑之前清掉对应的Redis键，拉取昨天生成的数据库全量快照，把网关的超时参数、第三方接口的mock配置恢复到默认值。剩下的非依赖服务，其他组的人爱怎么折腾怎么折腾，根本不影响用例执行。

这里有个很容易被忽略的细节：环境的状态必须是可追溯的。很多团队的测试环境，连个固定的版本记录都没有。今天部署的是哪个分支的代码，哪个时间点拉的数据库快照，配置文件改了哪几行，没人记。等用例跑挂了，你想回溯当时的环境状态，根本无从下手。上次碰到个团队，查了半天才发现，运维昨天为了排生产的一个超时问题，把测试环境的网关超时时间从5秒改成了100毫秒，所有依赖外部接口的用例全超时了。这哪是用例写得不好，这是环境的信息完全不透明。

别把环境治理当成测试团队自己的事

很多团队一提环境治理，就把所有活全扔给测试组。几个测试工程师天天追着开发要部署权限，追着运维要配置修改的记录，追着其他测试组不要往公共环境倒压测数据，累到死也管不过来。

麻烦在于，测试环境是全团队共用的，凭什么让测试组单扛所有的治理责任？

其实根本不需要什么复杂的流程。比如定个最朴素的规则：谁往测试环境部署非生产验证的代码，必须在固定的群里发个通知，标注清楚动了哪个服务、改了哪部分配置。跑自动化的人看到通知，就可以临时跳过对应的用例，等部署稳定了再恢复执行。再比如每次自动化执行完生成报告的时候，自动拉取最近24小时内这个环境的所有变更记录，附在报告开头。如果用例失败的时间点刚好和某个变更对得上，直接把排查的方向指过去，不用测试工程师当背锅侠。

之前总觉得环境治理是个很重的工程，要搭专门的平台，要写一堆自动化工具，要招个专门的SRE来管。真落地了才发现，很多时候根本不需要那么复杂。你只要做到三点：跑用例之前把依赖的状态重置到已知版本，所有的环境变更有迹可循，失败的原因能快速定位是不是环境导致的，就已经能把非预期失败的概率压到极低的水平。

上周跟那个之前CI通过率只有40%的朋友聊，他们现在没搞什么复杂的隔离方案，就是在自动化启动脚本里加了几行简单的命令：清掉自动化专用的Redis缓存空间，拉取昨天凌晨生成的数据库快照，重置网关的基础配置。现在CI的通过率稳在92%上下。省下来的排查时间，他们终于不用天天对着日志找环境问题，能好好写几个真正有业务价值的用例了。