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

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

1. 

前言

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

 

2. 

All in one

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

 

3. 

Fastdev

当我们的微服务数已经达到了四位数的时候，All in one模式早已不能支撑测试需求，所以我们开始探索其他解决方案。我们把目光转移到了UT上，它最大的优势就是下游依赖全部通过mock的方式替换掉，只需部署被测服务即可。常见的类似方案还有契约测试，常用工具是Pact。契约测试认为在微服务架构下E2E测试其实是一个伪需求，应该按照契约分别测试Consumer和Provider。我们也一度认为微服务下的测试可能真的不适合做E2E测试，但当真正应用的时候，我们发现Pact测试太理想化了，如果针对下游依赖很少的服务来说还行(但我们觉得All in one模式可能比Pact还好用)，但对于最上游依赖成百上千个服务，场景复杂多变的服务来说，Pact维护成本可能比环境维护成本还大(这里我们不讨论架构设计的合理性，只讨论现状)。但Pact测试还是给了我们一些启发，如果我们能解决自动生成契约的方式，似乎问题就解决了。所以从17年开始我们尝试通过线上录制流量，线下回放流量的方式验证了可行性，随后在滴滴内部逐渐推广开来，我们内部管它叫Fastdev，同时对外分别开源了针对PHP的https://github.com/didi/rdebug和针对Go的https://github.com/didi/sharingan，设计思路如下

 

随着Fastdev的成功，似乎我们找到了银弹，它可以完全模拟线上环境，测试场景也最真实，就算流量变了，我们只需要手动编辑一下个别流量也能实现mock能力，