被忽视的问题：测试环境稳定性治理

Python微信订餐小程序课程视频

https://edu.csdn.net/course/detail/36074

Python实战量化交易理财系统

https://edu.csdn.net/course/detail/35475

前言

前几天在某个微信群里看到有同学在问测试环境治理的问题，正好我在之前的公司负责过相关的技术项目，在这方面有一定的实践经验，就解答了她的一些疑惑。

今天看书时候突然想到了这件事，发现这几年大家都在讲测试开发、测试效能、精准测试、敏捷测试、全链路压测等等很多高大上的技术实践和理念，

但很少有人关注到测试环境稳定性的这种存在于我们日常工作中，困扰我们工作进度和心态的细节问题（至少对于测试同学来说）。

我并不是要表达上述的一些技术实践空泛或者什么（我自己本人就一直在写性能测试&全链路压测和稳定性保障相关的技术文章），

但业内目前确实存在一些为了证明测试价值和在技术链上不被鄙视而刻意为之的炫技行为。

目前能搜到或者说我个人看到的关于测试环境稳定性治理的文章，仅有阿里和滴滴在这方面的一些实践方法论(链接见下方)。

所以呢，这篇文章我不会去讲一些看起来很厉害的技术，而是和大家聊聊，我之前负责测试环境稳定性治理时候，面临的种种问题和痛点，

我是如何梳理和分析，并尝试去解决这些问题的过程。

附链接：

阿里巴巴线下环境稳定性治理

滴滴在测试环境上的探索和实践

项目背景和痛点

先交代下背景吧，这样能更好的理解做测试环境稳定性治理的出发点和治理方案为什么要如此设计。

我会从业务需求和技术现状两个方面来说明当时技术团队面临的痛点。

业务需求

当时公司业务处在高速发展期，除了日常的版本迭代之外，同时可能还并行着好几个独立项目（其实就是需求排不进版本迭代，需求评审时候被PK掉了，又搞了一个独立项目的名义进行需求交付）。

由于线上发布和灰度的时间节点各不相同，且每个独立项目和日常版本迭代涉及到的业务域以及背后的应用各不相同，有重叠又有新建的服务，因此每个项目都需要不同的测试环境来保证需求交付不受影响。

技术现状

聊完了业务需求背景，再来看看整个技术团队和体系当时面临的问题：

1-整体的需求研发测试交付体系是从Dev-Test-Pre-Pro四个阶段；

Dev：即开发环境，一般由开发自己负责日常维护；

Test：测试环境，也是本文的重点讨论对象，一般由测试维护；

Pre：即预发环境或灰度环境，是线上正式发布的最后一个验证环节；

Pro：我们所理解的生产环境&线上环境，所有