测试开发学苑 一款开源的 Diffy 自动化测试框架:实战过程讲解

狂师 · 2020年06月17日 · 最后由 吴大熊 回复于 2023年02月06日 · 6762 次阅读

1. 前言

软件测试是软件开发生命周期一个十分重要的环节,测试工作开展的好坏,很大程度上决定了产品质量的好坏,但软件产品随着版本的持续迭代,功能日益增多,系统愈加复杂,而从质量保障的角度,除了要保障好每次新增、优化的产品质量外,还需要确认新增或修改的功能不影响之前已存在的功能。若要进行产品功能全量回归,这个测试的工作量将会非常巨大。同时因为是回归,可能几百甚至上千用例中才会发现一个问题,甚至一个问题也没有,测试投入工作的时间与最终的收益不成比例。

因此如何在有限的时间、人力投入下,有效、高效的保证产品回归测试的质量,也一度成为了行业老司机以及团队管理者头疼的问题!

而今天的主角Diffy则为上述问题提供了较好的解决方案。它基于稳定版本和它副本的输出,对候选版本的输出进行严格对比,以检查候选版本是否正确,大大降低了回归工作量

接下来,让我们详细了解一下Diffy的工作原理,以及结合实战演练带大家感受一下它的魅力。

2. 关于 Diffy

关于Diffy,公号此前发表过一篇文章:
推荐一款 Diffy:Twitter 的开源自动化测试工具
有过详细介绍,之前不了解的读者,可详细阅读一下。

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

3. Diffy 工作原理

在整个测试开展过程中,Diffy 需要部署三个版本的系统,以实现它的噪声过滤和对比功能,它们分别是:

  • 候选版本(candidate):该版本为待测版本,有着最新待测代码。
  • 稳定版本(primary):该版本通常是已经上线版本,或者是已知功能正常的版本。
  • 稳定版本副本(secondary):该版本是稳定版本的副本,和稳定版本运行相同的代码,主要用于排除噪声。

Diffy主要职责充当了一个前置代理服务的角色,它能够将来源请求分发到不同版本的系统中去,通过对各个版本系统的输出进行对比,做出最终的结论。

Diffy整个工作原理流程图如下:

说明:

  • diffy本身作为一个代理服务(proxy),需要人为构造或引流 http 请求,发到 proxy 代理服务中。
  • 当 proxy 代理服务接收到请求后,会把请求分发到三个地方:被测服务,通常称之为侯选版本(candidate)、稳定版本(primary)服务、稳定版本副本(secondary)服务;
  • 接着,侯选版本服务与稳定版本服务的返回结果进行 diff,生成原始 diff 结果(raw differences),即原始区别;
  • 其次,稳定版本与稳定版本副本的返回结果进行 diff,生成噪声 diff 差异值结果(non-deterministic noise),即噪声,通过对这些差异值做减法来消除噪声。
  • 最后,通过比对原始的 diff 结果与消除噪声后的结果,得到最终的 diff 结果通过去噪声,得到最终过滤后的 diff 结果(filtered differences);

最终过滤后的对比结果会在平台提供的 html 页面中展示出来。

为了方便大家更好的理解上述工作流程,在网上找了一张图,标注了一下示例(本图来源于网络):

其中:

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

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

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

4. Diffy 编译、部署

Diffy 是 Twitter 使用 scala 语言开发的项目,并且在 GitHub 持续更新中,关于diffy的源码,github 上对应有两个版本:

1. twitter/diffy:

https://github.com/twitter/diffy

2. opendiffy/diffy:

https://github.com/opendiffy/diffy

按照官方的说明,建议优先使用opendiffy/diffy进行编译部署。

由于我们最终是需要用到diffy编译成功生成的jar包(实际上 diffy 平台使用的是 scala 语言),此时运行环境需要安装 JDK,这里建议安装Java 8,编译环境安装好之后,克隆 diffy 源码并进行 sbt 编译构建。

git clone https://github.com/opendiffy/diffy
cd diffy
./sbt assembly

需要注意的是./sbt assembly这个编译下载过程十分漫长,有条件的同学建议挂个代理。

编译好之后,生成的 Jar 包位置:diffy/target/scala-xx/diffy-server.jar(diffy 根目录的相对路径下)

除了利用 Github 的源码进行搭建外,还有两种方式也可以搭建 Diffy。其一是直接利用 jar 包,但该方法或者使用 docker 的 Diffy 容器(https://hub.docker.com/r/diffy/diffy)进行搭建,在此不一一赘述。

5. Diffy 常用命令参数

编译生成好 jar 包后,直接通过 java 命令启动 diffy 服务即可,其中,运行 Diffy 服务的常用参数如下:

参数配置 含义
candidate='PC1:8888' 待上线版本部署地址,即候选版本
master.primary='PC2:8888' 已上线版本地址 1,即稳定版本
master.secondary='PC3: 8888' 已上线版本地址 2,即稳定版本副本
service.protocol='http' http 协议或 https
serviceName='Test Service' 服务名称
proxy.port=:9990 Diffy 代理端口,所以请求都应从这个端口访问
admin.port=:9991 通过http://PC0:8881/admin可查看请求状况
http.port=:9999 查看界面,在这里可以比较差异
responseMode=primary 代理服务器是否返回结果,默认 (empty) 无返回,可指定 primary 返回线上版本,secondary(同线上版本,用于噪音消除),candidate(待测试版本)
allowHttpSideEffects=true Diffy 考虑到安全性,POST,PUT,DELETE 请求默认忽略,因此该参数为 true 则表示这三种类型请求仍能正常代理发送
excludeHttpHeadersComparison=false 是否排除 header 的差异,不同服务器,cookie,nginx 版本可能有所差异,设置为 true 可以忽略这
notifications.targetEmail (对差异发送到指定邮箱)

例如:

java -jar diffy-server.jar \
       -candidate='127.0.0.1:80' \
       -master.primary='127.0.0.1:81' \
       -master.secondary='127.0.0.1:82' \
       -service.protocol='http' \
       -serviceName='My Diffy Service' \
       -proxy.port=:8880 \
       -admin.port=:8881 \
       -http.port=:8888 \
       -allowHttpSideEffects=true \
       -excludeHttpHeadersComparison=false \
       -notifications.targetEmail=tester@emal.com 

6. Diffy 项目实战演练

安装和使用 Diffy 的一般步骤如下:

  • 安装 Diffy;
  • 启动候选服务、稳定服务和稳定服务副本;
  • 运行 Diffy;
  • 发送请求&查看结果;

接下来,通过一则简单的实战项目示例,为大家演示整个diffy的使用过程。

本文示例项目:是基于Django搭建的一套简易型REST API服务。关于如何通过 Django 来实现 REST API 服务过程可参考:Python 利用 Django 构建 Rest Api: 快速入门教程

假设按照上述教程,你已经成功的搭建好了 REST API 服务,项目名为:blog_project,接下来,继续往下操作:

1. 部署 primary(稳定版本)

由于本文不区分线上正式环境和测试环境,皆通过本地环境演示。(读者在实际生产&测试环境操作时,除了环境差异外,操作思路皆一样)

将示例项目blog_project代码拷贝一份到其它目录(为了和测试版本区分开来),激活虚拟环境,启动Django服务,端口设置为8001,此服务作为稳定版本服务,命令如下:

source env/bin/activate
cd blog_project
python manage.py runserver 8001

2. 部署 secondary(稳定版本副本)

同上一步操作一样,激活虚拟环境,启动Django服务,端口设置为8002,此服务作为稳定版副本服务,命令如下:

source env/bin/activate
cd blog_project
python manage.py runserver 8002

3. 验证 primary 和 secondary(稳定版本服务)
此步非必须,但为了让大家直观能和测试版本的服务区分开来,我们先验证一下,当前稳定版本服务的接口输出信息,比如:

http http://127.0.0.1:8001/api/

输出信息:

从上述输出信息中,我们可以知道访问 api/接口时,会输出两条信息,并且每条记录,分别对应有content,id,title,updated_at,create_at几个字段。

接着验证secondary副本服务:

http http://127.0.0.1:8002/api/

可以看出,secondary 副本服务和 primary 稳定版本服务输出结果是一样的。

4. 部署 candidate(测试版本)

接下来,我们开始部署测试版本服务,为了和稳定版本服务有所不同,我们在测试版本中,给 api 接口请求记录中,增加一个data字段。(实际工作中,也经常会面临接口字段的增、删、改)

1、修改 blog_api/models.py 文件,在原来的数据模型中,增加一个 data 字段:

from django.db import models

# Create your models here.

from django.db import models

class Post(models.Model):
    title = models.CharField(max_length=50)
    data = models.CharField(max_length=250,default='--')
    content = models.TextField()
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    def __str__(self):
        return self.title

2、修改 serializers.py 文件,在 fields 中增加返回 data 字段。

class PostSerializer(serializers.ModelSerializer):
    class Meta:
        fields = ('id', 'title', 'content', 'data','created_at', 'updated_at',)
        model = models.Post

3、生成迁移文件、同步执行数据库变更

python manage.py makemigrations
python manage.py migrate

4、启动服务,默认端口为8000,作为待测版本服务。

python manage.py runserver

5. 启动 diffy 服务
由于演示需要,直接在本地启动 diffy 服务即可,命令如下:

java -jar diffy-server.jar 
    -candidate=localhost:8000 
    -master.primary=localhost:8001 
    -master.secondary=localhost:8002 
    -service.protocol=http 
    serviceName=My-Service 
    -proxy.port=:8880 
    -admin.port=:8881 
    -http.port=:8888 
    -rootUrl='localhost:8888' 
    -allowHttpSideEffects=true

从上述启动命令中,可知:

在命令行中,输入如下命令,运行测试:

http http://127.0.0.1:8880/api/

命令经执行后,经 diffy 代理转发到稳定版本服务(端口8001)、稳定版本副本服务 (端口8002)、测试版本服务 (端口8000) 中。

访问http://localhost:8888,查看 diff 请求对比界面,功能说明如下图所示:

通常接口差异主要分为以下几类:

  • 每次调用本身返回值就不同,如 updatetime(可忽略);
  • 测试环境和线上环境数据不一致(可忽略);
  • 实时数据接口、动态变化数据(可忽略);
  • 软件缺陷或非预期修改。

对于可忽略的差异,可点击按钮忽略。

访问http://localhost:8881/admin,查看 diff 后台界面,功能说明如下图所示:

连续运行几次测试请求,访问http://localhost:8888,对比请求差异,如图所示。

从上图中,可知,已经成功 diffy 出在测试版本中,新增了一个data字段。

6. 修改测试版本服务

继续在测试版本服务上面修改以验证 diffy 的有效性,比如修改 api/接口返回的记录内容。

1、访问http://localhost:8000/admin,访问测试版本服务后台,修改其中一条记录,比如:

更新date中的内容,并点击保存。此时需要注意,当点击保存后,此时记录的updated_at字段值会被修改。

2、再次运行 diffy 代理请求。

http http://127.0.0.1:8880/api/

3、此时再观察http://localhost:8888界面,

可以看到,在 diffy 界面中,检查出了三个差异:返回的内容长度Content-lengthdataupdated_at

当然,实际业务中,Content-lengthupdated_at这类型的差异可被忽略掉。

通过结合接口返回详情功能,可查看到稳定版本和测试版本返回响应的差异处:

7. 小结

最后,小结几点建议:

  1. 在使用 Diffy 时,需要通过 Diffy 代理服务发送待测请求,虽然我们可以通过 postman、curl 等工具一个个发送,实践时,可通过 Charles 工具记录所有线上待测请求,然后利用 Charles 的 Rewrite 功能将修改成 Diffy 的代理服务器地址,重写请求,再重发。
  2. 除上借助 Charles 代理工具外,在实际应用时,也可借助线上引流工具(比如通过 goreplay 等引流工具)进行请求流量回放,或通过已有的接口自动化测试用例触发请求。
  3. 在使用 Diffy 时,可以看到有些差异是请求头部导致的,并不是我们想要发现的内容上的差异,如 cookie 的差异,nginx 版本的差别,不同服务器等等,可以在命令行中加入配置可忽略头部差异:excludeHttpHeadersComparison=true

如果你觉得文章还不错,请转发分享下,你的肯定是我最大的鼓励和支持。

详细可参考:原文阅读

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 8 条回复 时间 点赞

感谢分享!

这个工具是覆盖后端代码的吗?

运行上来代理接口访问报错 栈溢出

请问一下,你回放的时候有遇到过 java.lang.StackOverflowError: null 这个问题吗?
我大概回放的 1000+ 条数据 diffy 服务就会报错
java.lang.StackOverflowError: null
at java.util.regex.Pattern$Branch.match(Pattern.java:4618)
at java.util.regex.Pattern$BranchConn.match(Pattern.java:4582)
at java.util.regex.Pattern$GroupTail.match(Pattern.java:4731)
at java.util.regex.Pattern$Curly.match0(Pattern.java:4293)
at java.util.regex.Pattern$Curly.match(Pattern.java:4248)
at java.util.regex.Pattern$GroupHead.match(Pattern.java:4672)
at java.util.regex.Pattern$Branch.match(Pattern.java:4618)
at java.util.regex.Pattern$Branch.match(Pattern.java:4616)
at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3812)
at java.util.regex.Pattern$Start.match(Pattern.java:3475)
at java.util.regex.Matcher.search(Matcher.java:1248)
at java.util.regex.Matcher.find(Matcher.java:664)
at java.util.Formatter.parse(Formatter.java:2549)
at java.util.Formatter.format(Formatter.java:2501)
at java.util.Formatter.format(Formatter.java:2455)
at java.lang.String.format(String.java:2940)
at com.fasterxml.jackson.core.base.ParserMinimalBase._reportUnexpectedChar(ParserMinimalBase.java:587)
at com.fasterxml.jackson.core.json.ReaderBasedJsonParser._handleOddValue(ReaderBasedJsonParser.java:1902)
at com.fasterxml.jackson.core.json.ReaderBasedJsonParser.nextToken(ReaderBasedJsonParser.java:757)
at com.fasterxml.jackson.databind.ObjectMapper._readTreeAndClose(ObjectMapper.java:4042)
at com.fasterxml.jackson.databind.ObjectMapper.readTree(ObjectMapper.java:2551)
at ai.diffy.lifter.JsonLifter$.decode(JsonLifter.scala:52)
at ai.diffy.lifter.StringLifter$.$anonfun$lift$1(StringLifter.scala:9)
at com.twitter.util.Try$.apply(Try.scala:26)

死鬼吹灯. 回复

你好,我也遇到这个问题了
请问你解决了嘛?

大佬,有个问题想咨询一下,这个噪音过滤, 能去除所有噪音吗,比如这种实时数据接口、动态变化的数据,比如稳定版和稳定版的副版恰巧数据返回一样了,但是跟待测环境的不一样,但其实这是个噪音,这种的能去除吗

真实场景中 同一个请求在 3 个环境不能同时有效 (cookie 校验失败,接口无权限),这种情况,大佬你们是怎么做的?

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册