Diffy 是一个开源的自动化测试工具，是一种 Diff 测试技术。它能够自动检测基于 Apache Thrift 或者基于 HTTP 的服务。通过同时运行新/老代码，对比运行结果，发现潜在 bug。使用 Diffy，只需要进行简单的配置，之后不需要再编写测试代码。
一个项目，从第一个版本发布到形成一个相对完善的版本，再到后面的重大更新甚至重构，需要经过许多版本的迭代。
而随着项目的迭代，产品功能不断增加，项目会变得越来越复杂。在后期，每修改增加的功能相对上一版本已存在功能的比例却是越来越小。但每一次或大或小的版本升级,我们都需要保证新增或修改的功能不影响上一版本已存在的功能。但要达到这一点却是困难异常，哪怕只改了一行代码、哪怕这项更改由非常优秀的开发者完成，我们都很难保证这项功能对上一版本的功能无任何影响。
要保证每次上线的安全，我们需要开发和测试完成两项工作。一是，开发者在增加或变动某项新功能后，补充相应的测试用例，但写过单元测试的同学都知道，完成一个单元测试用例所花费的时间可能比完成相应功能花费的时间更多得多。
大多情况只能写几个核心的测试用例，而在人员不足，时间紧张的情况下，则更是难上加难了。在后期，因为功能在不断增加，回归测试的工作量越来越大，同时因为是回归，可能几百甚至上千用例中才会发现一个问题，甚至一个问题也没有，测试投入工作的时间与最终的收益不成比例。
另外测试人员对相同内容的重复测试，会有一种疲惫感，这样一来会给测试人员带来消极情绪，当真的有问题 (尤其是较复杂的数据问题) 发生时，也可能会因为这种疲惫而将问题忽略 (如果一个用例测了 10 遍都没问题,第 11 遍测的时候心里可能会默认这个地方是没问题的了)。这时候有些测试人员可能会考虑做自动化测试，但是自动化测试前期投入的成本较高，另外对测试人员的要求较高。如果项目变动比较频繁，部分自动化测试可能需要重新设计，会带来较高的成本。
而 Diffy 为上述问题提供了较好的解决方案，不同于我们常用的其他测试工具或框架从代码或接口的返回结果的正确性去验证，而是如其名：通过代码的差异去验证测试。
需要注意的是：既然是差异，那至少是两者之间比较才有差异，对于第一行代码或新增的功能无法比较，自然也就无法验证，这时 diffy 无法发挥作用。但在后续增加修改,项目不停迭代的周期中，diffy 就可以发挥它的舞台了，有了上一版本以及测试人员在上一版本测试工作的基础，我们就通过上一版本和当前版本比较差异了。
①、场景验证：
比如某个接口返回的数据中的” name” 字段获取由 user 数据库表改为 mobile_user 数据库表，那么从接口角度来讲，通过对比这个接口在新老版本代码的返回结果，就可以知道其字段的基本正确性与差异性。
②、提升回归效率：
就一般的接口测试来说，每次代码迭代，除了对新接口的测试，还包括对老接口的回归。如果通过手工回归，那么随着接口数量的增加，测试人员的工作量将同样地线性增长，且效率将大幅降低。通过 diff 测试，可以发现相同接口下内部代码逻辑变更对其输出的影响，测试人员只需要对比 diff 接口的差异之处（或自动对比），从而大幅减少人工作业的工作量。
①、分别部署新、老代码：其中老代码为线上稳定版本，新代码为新迭代的测试版本。
②、构造测试数据：我们可以手工构造测试数据，也可以对线上的数据进行抽样，用于 diff 测试。
③、运行测试：使用测试数据分别在新、老代码中运行，并捕获测试结果。
④、结果对比：对比新、老代码，相同接口下的输出，如果出现差异，则可以通过接口反向定位问题。
在测试过程中，Diffy 充当一个代理，它能够将来源请求分发到不同版本的系统中去，通过对各个版本系统的输出进行对比，做出最终的结论。
Diffy 需要三个版本的系统，以实现它的噪声过滤和对比功能，它们分别是：
整个运行流程为：
如图所示，diffy 能够比较 primary（线上稳定版本）和 secondary（线上稳定版本备份）的差异值，通过对这些差异值做减法来消除噪声；通过比较 candidate（测试版本）和 primary（线上稳定版本）得到基本的 diff 结果；最后通过比对基本的 diff 结果与消除噪声后的结果，得到最终的 diff 结果。
其中：
基于上述两个区别集合，Diffy 可以识别出候选版本和稳定版本真实的区别，这些区别很有可能就是一个缺陷。
当然，对于一个概率性出现随机值，仅仅一次请求的结论可能是不准确的。例如对于一个 50% 概率出现 true 或者 false 的布尔值，则有 50% 的概率会出现候选版本和稳定版本的不同，同时又会有 50% 的概率出现稳定版本和其副本出现不同（即将这个值认定为噪声），最终会有 25% 的概率认为这是一个缺陷。因为此时稳定版本和其副本值相同，候选版本和稳定版本值不同。因此，Diffy 还会聚合原始区别和噪声，当发现二者出现的概率类似的时候，会认定之前识别出来的缺陷属于误报。
1、克隆代码并构建
git clone https://github.com/twitter/diffy.git
cd diffy
./sbt assembly
下载diffy-server，也可以在 github 上下载源码编译twitter/diffy , diffy 是 twitter 使用 scala 语言开发的项目，在安装了 jdk 的基础上，还需要安装 scala 和 sbt(类似于 maven), 另外有些 jar 包需要从 twitter 下载。
2、例如，在 localhost:9990 部署 primary（线上稳定版本）的代码。
3、例如，在 localhost:9991 部署 secondary（线上稳定版本备份）的代码。
4、例如，在 localhost:9992 部署 candidate（测试版本）的代码。
5、在下载好 jar 包之后，可直接通过 java 命令启动 diff 服务：
java -jar diffy-server.jar
-candidate=localhost:9992
-master.primary=localhost:9990
-master.secondary=localhost:9991
-service.protocol=http
-serviceName=My-Service
-proxy.port=:8880
-admin.port=:8881
-http.port=:8888
-rootUrl='localhost:8888'
各参数详细说明:
candidate='localhost:9200' (待上线版本部署地址)
master.primary='localhost:9000' (已上线版本地址１)
master.secondary='localhost:9100' (已上线版本地址２)
service.protocol='http' (http协议或https)
serviceName='My Service' (服务名称,无影响)
proxy.port=:8880 (diffy代理端口,所以请求都应从这个端口访问)
admin.port=:8881 ( 通过http://localhost:8881/admin可以查看请求状况)
http.port=:8888 (查看界面,在这里可以比较差异)
rootUrl='localhost:8888' (同上)
responseMode=primary (代理服务器是否返回结果，默认(empty)无返回，可指定primary返回线上版本，secondary(同线上版本，用于噪音消除），candidate（待测试版本）
excludeHttpHeadersComparison＝false (是否排除header的差异，不同服务器，cookie，nginx版本可能有所差异，设置为true可以忽略这些差异）
notifications.targetEmail＝123＠emal.com (对差异发送到指定邮箱)
需要注意的是，为了防止测试对数据造成不必要的影响，diffy 默认只支持读,即 Post 及Ｄelete 影响数据的等请求不会转发,如果需要支持这样的请求,需要增加参数。
allowHttpSideEffects=true
命令模板 (根据实际情况修改参数值即可)
java -jar diffy-server.jar -candidate=localhost:8086 -master.primary=localhost:85 -master.secondary=localhost:85 -service.protocol=http erviceName=My-Service -proxy.port=:8880 -admin.port=:8881 -http.port=:8888 -rootUrl='localhost:8888' -allowHttpSideEffects=true
6、对 diffy 发一些请求
curl localhost:8880/your/application/route?with=queryparams
7、在http://localhost:8888中检查结果，结果展示如下图
如图所示，我们可以看到每个请求在不同节点上的差异之处，如果点击 “Exclude Noise”，则可以消除噪声，看到最终的 diff 结果。
上述对 diffy 作了一些基本的介绍和使用引导，利用 diffy 结合 gor 及 nginx 或 filter 等手段还可以扩展很多其它的测试实践。关于 gor 的介绍和用法可查阅：推荐一款简单易用线上引流测试工具：GoReplay，diffy 更多高级用法，欢迎大家自行探索。
