作者没兴趣讲原理，直接上干货吧。要讲的内容如下：
1、适用范围（作者个人观点）
2、如何实现
3、日常工作中遇到的各种问题
4、心得体会

1、适用范围

作者才疏学浅，我认为要玩 Diffy ，前提第一是测试环境虚拟化，第二是使用 docker-compose（第二条目测是废话）。

曾经有测试经理建议我拿三套非虚拟化的环境去搞 Diffy，我也真的调研了一下，发现无法满足使用 Diffy 的前提条件：完全相同的环境（待测接口容器不同）和完全相同的数据，那么当待测版本和基线版本的返回结果不同时，也无法保证这些不同一定是问题。

然而局限性来了，测试环境虚拟化不是什么公司都可以用的，理论上简单的服务才适用测试环境虚拟化，复杂服务之间复杂的相互调用关系会极大增加实现测试环境虚拟化的难度。类似的情况也出现在微服务上，我目前公司的微服务有十几个应用，想全部虚拟化，这个容器数量初步估算接近 400 个（ Diffy 3 套环境 + 1 套测试环境），这不是我一个小测试能玩得转的，公司层面不投入资源没法搞。所以看到这里，大部分读者可以洗洗睡了，你们自己学习可以，想在实际中应用基本没戏。

关于 docker-compose 我只想说一句话：我爱死 docker-compose up -d 这个命令了，虽然实际工作中我是自己写脚本来启动几十个容器的。

2、如何实现

首先，玩了命的问开发和运维，人家做的人家才知道细节。
其次，确定都需要什么镜像，然后一个一个先跑起来再说。这里要特别强调，最好用自己 build 的镜像，hub.docker.com 上的好多镜像都是大坑，尤其是那些所谓的官方镜像，你最好先仔细看看 Dockerfile 再决定是否用它。
第三，建立关联关系，调试运行。
第四，写 docker-compose.yml 配置文件，调试运行。
第五，引入 Diffy ，写 Diffy 的配置文件，调试运行。
大功告成。

3、日常工作中遇到的各种问题

问：如何保证环境完全相同和数据完全相同
答：从一个镜像运行多个容器你会吧，解决了。例子如下图

问：如何更新数据
答：这个问题比较麻烦。为了保证测试数据相同，一般是直接 build 镜像时把数据放进去而不是挂载数据目录进去（挂载数据目录到镜像里等于浪费 docker ），所以我的处理办法是在测试环境里保存一份测试数据目录，当需要更新测试数据时，我就先更新本地数据，然后重新 build 镜像。如果大家有好办法，欢迎一起来讨论，也给本小白指点迷津。

问：数据结构变了怎么办
答：如果是字段数据类型变了或者增加修改删除字段或者增加了新的数据表，对不起，重新 build 数据镜像，这是测试环境虚拟化的一个大坑，且本小白找不到合适办法解决。欢迎各路大神指点迷津。

问： docker-compose up -d 运行报类似超出响应时间的错误怎么处理
答：自己写脚本；反复启动；测试环境服务器配置好一些------

问：我想不到其他问题了
答：欢迎大家补充各种问题，我知道的一定会说，不知道的就大家一起讨论好了。

4、心得体会

Diffy 实在是太好用了！

脑补一个场景：早晨开发跑过来告诉你，我改了数据层的一些东西，可能的影响范围是全部查询类的接口，不多，也就几百个，产品要求今天必须上线。

如果没有 Diffy ，你的选择如下：第一、殴打产品经理，成功晋级高级工程师；第二、大喊：我做不完，然后找人帮忙；第三，放弃午餐和午休，准备玩命工作，然后沉浸在各种比对数据准确性的操作中，无法自拔。

如果你用了 Diffy ，你可以微笑的告诉开发 GG：我测得完，你改的完吗？！

是的，飘柔，就是这么自信。 Diffy 的使用条件是完全相同的环境和完全相同的数据，而只是待测接口容器不同，满足这 2 个条件，只要去掉杂音以后的待测接口版本的返回值和基线接口版本的返回值不同，就可以判定为缺陷，而且因为是自动比对返回值的，你只需要把提交接口的过程自动化就好，从而省去了大量的时间，你甚至还可以去深入研究出现问题的原因。比如 A 接口数据冗余的原因是取消的订单被放到待支付订单列表，B 接口数据不同是因为没有过滤已经下架的商品等等。

综上，就是个人对 Diffy 工具的一点理解和使用心得，欢迎各路大神多多指点。