自动化测试中的环境治理 藏在通过率背后的暗账

上周去南京找个做测试的老同事撸串，他灌了半瓶冰啤酒之后，骂了快四十分钟。 说他们组搭了半年的自动化测试框架，一开始跑起来通过率92%，领导在季度会上点名表扬，说他们把测试效率提了一大截。结果上周三早上跑定时任务，通过率直接掉到41%。 全组人查了一天。 最后发现是运维同事把测试库的连接串改了，没打招呼。 这事儿说出来都好笑，但每个搞过自动化测试的人，大概率都遇到过。很多人把这归为“环境不稳定”，没当回事，其实这就是最典型的自动化测试中的环境治理缺位——没人盯，没规矩，出了问题才临时抱佛脚。

通过率波动的锅 从来不是脚本写得烂

很多团队搞自动化测试，从一开始就跑偏了。 把所有精力都砸在用例覆盖度、断言逻辑、CI流水线集成上，连测试环境的服务器配置文档都没人愿意整理一份，更别说做版本对齐了。跑起来之后每周报一次通过率，数字好看就万事大吉，没人去抠背后的波动原因。 真的，我见过太多团队为了把通过率凑到95%以上，直接把环境不稳定导致的失败用例标成“非产品问题”，统计的时候直接剔除。 这不是解决问题，是自欺欺人。 你以为通过率稳了，其实只是把问题藏起来了。今天是连接串改了，明天可能是mock服务的返回值被别的测试组改了，后天可能是测试环境的网关证书过期了。这些问题没有一个是你脚本写得烂导致的，但最后所有的锅，都会扣到自动化测试的头上。

有次我看一个团队的失败用例统计，连续三周有十几个用例因为“网络超时”失败，没人去查为什么超时，就直接归为环境问题。后来才发现是测试环境的带宽被别的团队传大文件占满了，只要把这些大文件的传输限速，超时问题直接消失。 你看，根本不需要搞什么复杂的技术方案，只要有人盯着这些细节就行。

别上来就搞全链路环境隔离 先算清楚账

一提到环境治理，很多人的第一反应就是搞K8s，搞一键部署，搞每个测试用例都有独立的专属环境。 这话没错，但要看你团队的规模。 这事没那么玄。 小团队总共就5个测试，3个开发，大家天天凑在同一个测试环境里写代码调接口，你上来就搞全链路环境隔离，光维护那套环境平台的时间，够你把所有用例跑三遍了。纯纯的浪费。 麻烦在于，环境治理的核心从来不是技术有多先进，是能不能匹配你现在的团队阶段，解决最痛的那个具体问题。 之前接触过一个十几人的小团队，之前最大的痛点是每次跑接口自动化之前，都要手动清一遍测试库的缓存，每次要花20分钟，还经常有人忘了清，导致用例失败。他们没搞什么复杂的环境平台，就写了个10行的shell脚本，每次用例启动前自动调一下清缓存的接口，十分钟就搞定，直接把通过率稳了15个点。

当然，要是你是百来人的研发团队，几十个测试环境互相串数据，不同项目的测试版本混在一起跑，那确实得搞标准化的环境模板。每个环境的配置、版本、依赖都打个统一的包，谁要申请环境直接拉起来，不用每次找运维手动配。但这也是解决你们这个阶段的痛点，不是说全链路隔离就是唯一正确的答案。 很多人容易陷入一个误区，觉得环境治理就得搞个大平台，把所有东西都管起来。其实不是，你只要把最影响通过率的那个问题解决了，就已经赢过大多数团队了。

最容易被忽略的成本 是测试数据的生命周期

很多人搞环境治理，只盯着服务版本、网络配置、依赖组件，忘了测试数据才是最大的不稳定来源。 比如你写了个用例，要测用户下单的流程，需要一个状态是“已支付”的订单。那这个订单是谁造的？别的用例跑的时候会不会把它改成“已退款”？数据库里的脏数据会不会导致你的断言失败？ 之前有个团队，跑支付链路的用例，每次通过率都在60%晃，查了一周才发现，是别的测营销活动的用例，每次跑的时候会给测试用户发满减券，而支付用例的断言是“订单实付金额等于商品原价”，多了券当然不对。 说白了，测试数据的治理，不是要你搞个什么高大上的数据中台，是你得给每个用例需要的数据划个“专属领地”。比如这个用例用的用户ID是10001-10010，别的用例不许碰这些ID，用例跑完之后自动把这些数据清掉，下次跑的时候重新造。 就这么简单的事，很多团队就是没人做。 还有个容易被忽略的点，很多人觉得环境治理是运维的事，是测试平台组的事。其实不对。每个写自动化用例的人，都得对自己用例依赖的环境负责。你不能写完用例扔在CI上，跑挂了就喊别人来查。 上次撸串的那个老同事，后来他们组没搞什么大的环境平台，就是定了三个很朴素的规矩： 第一，谁改测试环境的配置，必须在群里同步一声； 第二，每个用例跑完自动清理自己造的测试数据； 第三，每周花半小时，把所有通过率波动的原因列出来，能当场改的就当场改。 就这么点事。 现在他们的自动化测试通过率稳在94%，再也不用天天熬夜查莫名其妙的问题了。