上周跟一个做了6年测试的朋友吃夜宵，他刚从公司爬起来赶线上bug，手里攥着半串凉掉的烤筋。问他最近忙啥，他翻个白眼：自动化跑着跑着全红了，查了俩小时，是测试环境的数据库被别的团队删了半张表。
我一点都不意外。
太多团队的自动化测试，从搭起来的第一天起，就带着天生的残疾。
没人提前说清的环境债
大家搭自动化的时候，注意力全在框架好不好用，用例写得够不够优雅，能不能支持多线程跑。没人愿意花心思在环境上。
毕竟写用例是写在简历上能吹的成果，环境治理是擦屁股的活。
你想想，跑100条用例，80条报红，你挨个查，不是接口超时，就是数据不对，再不然就是依赖的第三方服务返回了随机的错误码。折腾半天，根源根本不是用例的问题——是dev环境被开发塞了自己的调试代码，是测试环境的缓存没清，是隔壁团队拿你的环境做压测把CPU打满了。你说可笑不可笑？
我当初第一次遇到这种情况的时候，还以为是自己写的用例逻辑错了，翻了俩小时代码，最后发现是隔壁后端团队拿测试环境跑批量任务，把数据库连接池占满了。
这种事多了，大家慢慢就不信自动化了。红就红吧，反正不是用例错了就是环境错了，没人愿意花时间逐个核对，自动化慢慢就成了摆给领导看的摆设。
没人愿意背这个锅。环境出问题的时候，没人会记得你之前花了多久搭的框架，只会指着你的鼻子问：你管的自动化，怎么又跑挂了？
把环境当产品做的取舍
我去年跑访谈遇到的一个中后台团队，之前也是这套烂摊子。用例通过率常年在40%上下晃，每天测试团队要花近一半的时间排查环境问题，剩下的时间才是真的写用例。
后来他们没搞什么花里胡哨的平台，就咬着牙做了几件事。
先是跟运维磨了两周，给自动化测试单独划了一套物理隔离的专属环境，跟dev、预发、甚至普通测试环境完全隔开，除了负责环境的同学，其他人连SSH权限都没有。
紧接着把之前零散的脚本凑了凑，每次跑用例之前，自动把数据库的快照回滚到上一个干净版本，所有依赖的第三方接口全部用mock服务封死——哪怕第三方真的全挂了，用例也能正常跑。这就是用例执行前自动回滚数据库快照的核心逻辑，没有什么玄乎的技术，就是每次发版之后自动打个新的快照而已。真的，没有什么技术门槛。
最后定了个简单到粗暴的私自篡改环境配置的追责机制，谁要是敢私自登自动化环境改东西，直接在团队群里@，扣当月的绩效。
很多人说他们这是浪费资源。一套环境的服务器成本，顶之前三套通用环境的开销。
但你算过账没有？之前每天花在排查环境问题上的人力，一个月的成本够买多少服务器？现在他们的用例通过率稳定在97%，每次跑完自动化，直接看报告里那几个真的失败的用例就行，不用再花时间挨个排查环境问题。之前天天喊着自动化浪费人力的开发负责人，现在每天早上第一件事就是看自动化报告，再也不催测试手动点回归了。
我之前跟一个在制造企业做数字化的朋友聊过，他们算过一笔账，那些一开始觉得单独划环境太浪费服务器成本的团队，最后花在排查环境问题、反复手动回归上的人力成本，足够把整个机房的服务器都换一遍。
说白了，这事没那么玄。你愿意为了减少环境干扰，付出一点服务器的成本，还是愿意天天让团队成员把时间浪费在无意义的排查上？怎么选都不会错，但大部分人一开始都选了后者。
别把治理做成新的负担
当然也有踩坑踩得特别狠的。
我见过一个团队，一开始下定决心要搞环境治理，上来就立了个大项目，要做全链路的环境纳管平台，要把所有环境的配置、权限、数据全部统一管起来，要做可视化大屏，要做多维度的监控。搞了三个月，平台终于上线了，结果根本没人用。
为啥？
改个测试环境的配置，要走三层审批，流程要走三天。本来5分钟能搞定的事，现在要等一周。最后大家宁愿绕过平台，偷偷登服务器改配置，那个所谓的治理平台，最后成了个没人看的大屏。
麻烦在于，很多人对环境治理的理解错了。
他们觉得治理就是把所有东西都管起来，把所有权限都收上来，定一堆条条框框。但实际上，自动化测试中的环境治理，核心目标特别简单——让跑用例的人，不用操心环境的事。
你不需要搞多么复杂的平台，也不需要定多么严苛的制度。只要保证每次跑用例的时候，环境是干净的，配置是对的，没有别的人随便乱改，就够了。
我见过最蠢的操作，是给自动化环境加了个二次短信验证，每次跑之前要输收到的验证码。最后测试团队宁愿每天花3个小时手动跑回归，也不愿意碰这个动不动就要输验证码的自动化系统。
真的。
没有一劳永逸的方案。今天你刚把快照回滚的流程跑顺了，明天产品加了个新的消息队列中间件，你就得重新打快照，就得改mock的规则。这活没有终点，也别想着靠一套制度、一个平台就把所有问题都解决了。
前几天那个吃夜宵的朋友给我发消息，说他们终于咬着牙申请了单独的自动化环境，现在跑用例基本不用查环境问题，昨天提前半小时下了班。
我回他说，这才是自动化测试本来该有的样子。