滴滴在测试环境探索与实践中的四种模式

持续稳定并体验良好的测试环境，一直是影响产品迭代效率和稳定性的关键环节，也是DevOps自动化测试环节中最具挑战的一环，滴滴在测试环境上的探索从公司成立之初就从未停止，在这过程中沉淀了很多宝贵的经验和教训。本文细数滴滴在测试环境的发展历程，希望能给大家带来一些启发。

1. 前言

伴随着滴滴的不断成长，业务复杂度与日俱增，团队在协作和迭代效率问题上日益严重，"微服务"成了很多公司解决上述问题的必经之路，滴滴也不例外。随着微服务在滴滴的落地，我们确实成功缓解了协作和迭代效率上的问题，但同时也引出了很多新的问题，比如构建测试环境的复杂度，这也是我们今天要聊的主题——滴滴在测试环境上的探索与实践。

2. All in one

在滴滴微服务落地初期，一个业务涉及服务数并不会太多，最多也就十几个，在这种场景下，不管怎么搭建测试环境都是相对容易的，哪怕是手动维护也耗费不了多少成本，所以在这个时期我们通过工具自动构建所有服务，把所有服务都打包在一起基本就够用了，我们管它叫"All in one"环境。这种方式持续了很长时间，直到现在依然支持着部分测试工作，但随着微服务数的增多这种方式越来越难以维护。

3. Fastdev

当我们的微服务数已经达到了四位数的时候，All in one模式早已不能支撑测试需求，所以我们开始探索其他解决方案。我们把目光转移到了UT上，它最大的优势就是下游依赖全部通过mock的方式替换掉，只需部署被测服务即可。常见的类似方案还有契约测试，常用工具是Pact。契约测试认为在微服务架构下E2E测试其实是一个伪需求，应该按照契约分别测试Consumer和Provider。

我们也一度认为微服务下的测试可能真的不适合做E2E测试，但当真正应用的时候，我们