校服杀人魔

订阅者

277
文章

0
粉丝

测试资讯评论188字数 2303阅读7分40秒阅读模式

摘要这款工具能够自动检测基于Apache Thrift或者基于HTTP的服务。通过同时运行新老代码，对比运行结果，发现潜在bug。使用Diffy，只需要进行简单的配置，之后不需要再编...

Diffy是什么

Diffy是一个开源的自动化测试工具，是一种Diff测试技术。它能够自动检测基于Apache Thrift或者基于HTTP的服务。通过同时运行新/老代码，对比运行结果，发现潜在bug。使用Diffy，只需要进行简单的配置，之后不需要再编写测试代码。

1. Diffy主要为了解决什么问题

一个项目，从第一个版本发布到形成一个相对完善的版本，再到后面的重大更新甚至重构，需要经过许多版本的迭代。文章源自玩技e族-https://www.playezu.com/204343.html

而随着项目的迭代，产品功能不断增加，项目会变得越来越复杂。在后期，每修改增加的功能相对上一版本已存在功能的比例却是越来越小。但每一次或大或小的版本升级,我们都需要保证新增或修改的功能不影响上一版本已存在的功能。但要达到这一点却是困难异常，哪怕只改了一行代码、哪怕这项更改由非常优秀的开发者完成，我们都很难保证这项功能对上一版本的功能无任何影响。文章源自玩技e族-https://www.playezu.com/204343.html

要保证每次上线的安全，我们需要开发和测试完成两项工作。一是，开发者在增加或变动某项新功能后，补充相应的测试用例，但写过单元测试的同学都知道，完成一个单元测试用例所花费的时间可能比完成相应功能花费的时间更多得多。文章源自玩技e族-https://www.playezu.com/204343.html

大多情况只能写几个核心的测试用例，而在人员不足，时间紧张的情况下，则更是难上加难了。在后期，因为功能在不断增加，回归测试的工作量越来越大，同时因为是回归，可能几百甚至上千用例中才会发现一个问题，甚至一个问题也没有，测试投入工作的时间与最终的收益不成比例。文章源自玩技e族-https://www.playezu.com/204343.html

另外测试人员对相同内容的重复测试，会有一种疲惫感，这样一来会给测试人员带来消极情绪，当真的有问题(尤其是较复杂的数据问题)发生时，也可能会因为这种疲惫而将问题忽略(如果一个用例测了10遍都没问题,第11遍测的时候心里可能会默认这个地方是没问题的了)。这时候有些测试人员可能会考虑做自动化测试，但是自动化测试前期投入的成本较高，另外对测试人员的要求较高。如果项目变动比较频繁，部分自动化测试可能需要重新设计，会带来较高的成本。文章源自玩技e族-https://www.playezu.com/204343.html

而Diffy为上述问题提供了较好的解决方案，不同于我们常用的其他测试工具或框架从代码或接口的返回结果的正确性去验证，而是如其名：通过代码的差异去验证测试。文章源自玩技e族-https://www.playezu.com/204343.html

需要注意的是：既然是差异，那至少是两者之间比较才有差异，对于第一行代码或新增的功能无法比较，自然也就无法验证，这时diffy无法发挥作用。但在后续增加修改,项目不停迭代的周期中，diffy就可以发挥它的舞台了，有了上一版本以及测试人员在上一版本测试工作的基础，我们就通过上一版本和当前版本比较差异了。文章源自玩技e族-https://www.playezu.com/204343.html

2. Diffy适用场景

①、场景验证：文章源自玩技e族-https://www.playezu.com/204343.html

比如某个接口返回的数据中的”name”字段获取由user数据库表改为mobile_user数据库表，那么从接口角度来讲，通过对比这个接口在新老版本代码的返回结果，就可以知道其字段的基本正确性与差异性。文章源自玩技e族-https://www.playezu.com/204343.html

②、提升回归效率：文章源自玩技e族-https://www.playezu.com/204343.html

就一般的接口测试来说，每次代码迭代，除了对新接口的测试，还包括对老接口的回归。如果通过手工回归，那么随着接口数量的增加，测试人员的工作量将同样地线性增长，且效率将大幅降低。通过diff测试，可以发现相同接口下内部代码逻辑变更对其输出的影响，测试人员只需要对比diff接口的差异之处（或自动对比），从而大幅减少人工作业的工作量。

3. Diffy一般操作流程

①、分别部署新、老代码：其中老代码为线上稳定版本，新代码为新迭代的测试版本。

②、构造测试数据：我们可以手工构造测试数据，也可以对线上的数据进行抽样，用于diff测试。

③、运行测试：使用测试数据分别在新、老代码中运行，并捕获测试结果。

④、结果对比：对比新、老代码，相同接口下的输出，如果出现差异，则可以通过接口反向定位问题。

4. Diffy工作原理

在测试过程中，Diffy充当一个代理，它能够将来源请求分发到不同版本的系统中去，通过对各个版本系统的输出进行对比，做出最终的结论。

Diffy需要三个版本的系统，以实现它的噪声过滤和对比功能，它们分别是：

候选版本：该版本是待测版本，相对于生产环境版本有着跟新的代码。
稳定版本：该版本通常是已经上线版本，或者是已知功能正常的版本。
稳定版本副本：该版本是稳定版本的副本，和稳定版本运行相同的代码，主要用于排除噪声。

整个运行流程为：

如图所示，diffy能够比较primary（线上稳定版本）和secondary（线上稳定版本备份）的差异值，通过对这些差异值做减法来消除噪声；通过比较candidate（测试版本）和primary（线上稳定版本）得到基本的diff结果；最后通过比对基本的diff结果与消除噪声后的结果，得到最终的diff结果。

其中：

原始区别为候选版本和稳定版本之间输出的区别，其中可能会包含上述的噪声。
噪声从稳定版本和其副本中获得，如果两个运行相同代码的系统输入相同输出却不同，则Diffy会认为这是开发人员不需要关心的噪声。

基于上述两个区别集合，Diffy可以识别出候选版本和稳定版本真实的区别，这些区别很有可能就是一个缺陷。

当然，对于一个概率性出现随机值，仅仅一次请求的结论可能是不准确的。例如对于一个50%概率出现true或者false的布尔值，则有50%的概率会出现候选版本和稳定版本的不同，同时又会有50%的概率出现稳定版本和其副本出现不同（即将这个值认定为噪声），最终会有25%的概率认为这是一个缺陷。因为此时稳定版本和其副本值相同，候选版本和稳定版本值不同。因此，Diffy还会聚合原始区别和噪声，当发现二者出现的概率类似的时候，会认定之前识别出来的缺陷属于误报。