腾讯技术 | 自动化接口测试实践经验

star2017 1月前 ⋅ 39 阅读

作者:faithchen,腾讯 PCG 测试开发工程师

一、背景

自动化测试对于我们提升研发效能、CI/CD(持续集成/持续交付)是不可或缺的部分。在后台自动化测试中,接口测试尤为重要,它能够保证被测后台服务的质量,以及接口逻辑的正确性等,帮助我们快速测试功能、提高测试覆盖率、把控质量风险等。

1.1 后台接口测试

接口测试是功能测试的一种,是测试系统组件间接口的一种测试,重点在于检验对于服务接口的数据交换的正确性,一般全部依赖真实链路,测试时需要启动被测服务。如下图是某个 Server A 的接口测试:

图片然而,写过接口测试的同学可能都会被复杂的数据构造以及繁杂的断言所困扰,可能需要耗费大半天才能写完一个接口测试用例,浪费了许多宝贵的时间!基于以上考虑,为了提高编写接口测试用例的效率,我们希望能够自动化地协助开发或测试人员完成这些耗时耗力的事情,为此而产生的想法是通过流量的录制,再通过录制的流量自动化生成接口测试用例。基于上述想法,我们提供了从录制流量生成接口测试用例完整链路的工具,辅助开发同学快速完成编写接口测试用例。简单来说,只需要以下三个步骤便可以接入:

图片
接下来,我们通过“流量录制-> 生成用例” 的流程来进行阐述我们的实现方法和接入方式。我们会说明通用的平台如 stke、sumeru 服务的接入流程,由于 123 平台对 goreplay 等有较好的支持,除了通用流程外会以 123 平台为例进行说明。最后会说明流量频次筛选方案帮助大家理解我们的流程。

二、流量录制

2.1 流量录制简介

2.1.1 什么是流量录制

我们听得比较多的是“录制与回放”,但目前只需要用到录制功能,后续可能会把回放功能也加上。顾名思义,流量录制就是指将我们期望的接口数据的包括 response、request、协议等等存储起来的操作,可以是正式环境或者是测试环境的数据,开启了录制功能后,只要对应环境的服务有流量,便可以将其捕获存储起来,实现此功能的方式有多种。

通过对多个方案的对比后,我们决定采用 goreplay 的方式,其开源代码是 goreplay ,基于 goreplay 1.2.0 版本改造后已经支持 trpc, http, gofree, wup, videopacket, 后面会陆陆续续支持其他协议,采用 goreplay 的主要优势是它可以分析和记录服务的流量但不会影响服务,并且接入流程相对简单。

goreplay 方案其最大好处是与业务代码解耦,不需要入侵代码。

图片在传输层的 goreplay 录制方式为:

图片

2.1.2 为什么要进行流量录制

接口测试是在真实运行的服务中测试,若想自动化生成用例,理想的情况下,便是要自动化生成真实数据的接口测试用例,那么首先需要的就是真实的接口数据,数据从何而来呢?自然而然的,我们便会想到到线上去录制(无论是测试环境或者正式环境的)。

下面为「通用流程」讲述如何为服务接入 goreplay 流量录制流程。

2.2 「通用流程」服务流量录制

2.2.1 「通用流程」上传 pb 文件至协议中台用于解析二进制流量

首先我们需要一个能够管理协议的系统,它能够对协议文件(如 pb 文件等)进行管理,这样当协议有更新时,依然能够对新的协议生成的流量进行解析。

能够将 goreplay 录制的二进制数据进行解析:

图片

只需要将依赖的 proto 文件进行打包(注意依赖多个 proto 文件时保持相对目录正确)并上传到协议中台即可,并且生成对应此版本 pb 的版本号,用于我们后续生成 goreplay 命令。

2.2.2 「通用流程」生成并执行 goReplay 命令

在上述协议中台获取了版本号之后,我们已知后台服务的 ip 和端口,已经最新的协议版本。将这些填入我们的 goreplay 命令中,如下图所示:

图片将上述命令在对应的容器中执行。

部分参数说明:

--input-raw-logreplay// 这个其实是rawInput插件的参数, 开启这个参数后, 必须ip和port都要填
--output-logreplay-cache-size 200// LogReplayOutPut插件 需要的缓存大小, 可以不设置, 有默认值
--output-logreplay-track-response// 跟--input-raw-track-response含义一样
--input-raw-protocol // 必填需要解析的协议
--output-logreplay-protocol-service-name "app.server" // 协议文件对的服务名
--output-logreplay-commitid "1.0.1" // 必填,如果是http协议, 可以自定义
--output-logreplay-qps-limit 100// 限制录制的qps, 非必填, 有默认值
--output-logreplay-env formal // 选填,默认formal,需要注册到logreplay测试环境可填test

在容器中执行 ps -ef|grep goreplay 看到如图进程便表示成功了:

图片

2.2.3「通用流程」查看录制流量

当服务在对应环境有流量的话,很快我们就可以查看到通过 goreplay 录制到并解析成功的流量了。
图片里面的 request 和 respond 等数据都一目了然(此处是 demo 所以数据很少,真实环境中,可能有非常多的参数及数据),根据这些录制的数据,我们下来就可以自动生成接口测试用例了。

图片

三、生成用例

当录制好流量后,我们会有一个筛选机制来过滤流量,不过这个操作对于用户是无感知的。对于使用方来说,接下来就能够自动化生成流量了。

3.1 px-cmdline 工具简介

我们提供了 px-cmdline 工具,这是一个命令行工具,它可以将 goreplay 录制的流量,通过 proto 文件,自动获取相关依赖后生成符合代码规范的接口测试文件。

3.2 px-cmdline 使用

使用方式也很简单,命令行格式为:



px-cmdline generate -p <proto gomod> [-f] [--env test]

常用参数介绍:

  • -p 指定 proto 依赖路径,从 go.mod 中拷贝
  • -f 是否强制更新,开启后,会替换掉即将生成的同名接口测试文件
  • --env 指定拉取流量的环境变量,默认 test 环境
  • --dest 指定生成的目录,默认 tests 文件夹
  • -j 指定是否切换 JSON 文件模式。默认使用 JSON 文件独立模式;开启后,用例写入到*_test.go 里

示例:

px-cmdline generate -p git.code.oa.com/xxxxprotocol/hello/world

运行后,如果未发生异常,会在当前目录下生成 tests 子目录,根据每个 RPC 接口生成独立的__test.go 文件,以及一个唯一的 suite_bvt_base_test.go 用于启动接口测试。testdata 目录存放 JSON 格式的用例数据。如图:

图片当服务有多个运行节点的时候,还支持选择运行节点,以便用于本地调试接口用例时请求该目标。建议优先选择 test 环境或者开发者的特性环境

[Info] 请选择本地测试目标服务:可只选择环境,或指定节点
[Info] (1) 测试环境 test --------
[Info] (└ 11 ) 9.2.3.4:16916, Development, 权重100, 健康
[Info] (2) 特性环境 sdfdfe --------
[Info] (└ 21 ) 11.1.2.3:11389, Development, 权重100, 健康
[Info] (3) 特性环境 dfadfb --------
[Info] (└ 31 ) 9.3.4.5:11042, Development, 权重100, 健康
[Info] (4) 特性环境 c9d193e8 --------
[Info] (└ 41 ) 11.3.4.5:11222, Development, 权重100, 健康

为了符合代码规范,用例数据目前以 JSON 数据的形式进行存储,展示其中一条数据如下:

{
"request": "{\"pp\":[\"1dfa\"]}",
"response": "{\"sdf\":{\"TPDKH\":{\"basic\":{},\"cosume\":{},\"data\":{\"type\":\"NotSettle\",\"pll\":[733],\"tpl\":\"UG\"}",
"trace_id": "394729374872934"
 },

如此一来就成功生成了接口测试用例了,当我们本地调试 OK 后,就可以将其 mr 进代码主干,在日常流水线运行时都能对接口进行自动化测试。

当然了,如果有同学喜欢用更直观的 IDE 工具,我们也提供了 IDE 插件供大家使用。

3.3 px-cmdline 工具(IDE 版) Jetbrains 插件使用

如果用户希望通过 IDE 插件,可以通过如下操作

第一步:我们有相关的插件供安装

图片

弹出窗里面选择刚才下载的 ZIP 包,然后确定;

第二步:安装完成后重启 IDE,启用插件通过插件简单右键选择来生成接口测试文件可以达到与命令行工具同样的效果:

图片
图片
然后便可以顺利生成接口和用例在特定的文件夹中,用于接口测试执行。

四、流量频次筛选策略

本章节补充说明,当我们数据量较大的时候,如何进行筛选与分析,保留下相对有价值的流量用于生成接口测试用例的。

4.1 流量筛选背景

本章节内容讲述我们的流量筛选策略,这部分内容对于使用用户是无感知的,但是有助于对我们工具的完整链路有更好的理解。

当我们为服务接入 goreplay 后,在服务上有成千上万的流量录制进来,有时候甚至更多,那么怎么知道哪些流量是重复的,哪些流量值得记录下来用于生成用例呢?

由于正式线上环境流量较大,可能存在很多流量数据的重复率和相似度较高的情况,对此,我们不会简单的将所有流量都直接存储到数据后用于后续生成接口测试(毕竟我们也不可能用成千上万个接口用例来测试一条数据),而是会通过一定的策略进行频次筛选,符合我们相似度区分要求的流量我们才会存储到我们的数据库中。

这样做的好处有:

  1. 防止某些服务流量过大,存储数据过大。
  2. 剔除重复流量,对于相似度高的流量不重复存储,同时保证了接口测试的数据多样化。

4.2 相似度对比简述

4.2.1 相似度比较总体流程

如下图,例子中有两个流量的 response,我们是如何对 response 或者 request 的数据进行相似度计算的呢,大致流程为:

  • 取其 body 部分,舍弃 header
  • 计算一级 key 相似度,一级 key 的相似度我们较严格,一般情况下,如果一级 key 不一样那么则可以认为这两个 body 之间的差异是较大的,如下图左侧 response 的一级 key 有 MsgProcITaskOutput,右侧 response 的一级 key 有 MsgProcIC,显然,我们会认为这两个相似度是较低的,应该是差异较大的流量。
  • 假如一级 key 完全一样的话,显然要进一步递归比较,但是层级越高我们会设置影响因子越小,对此完成相似度的递归计算。

图片

4.2.2 字符串相似度

一般计算到二级 key 以后,我们便要开始关心字符串的相似度了,此处我们使用的算法是 Levenshtein 距离 ,定义如下:
图片
简单说来,就是计算一个字符串需要经过多少次编辑才能变成另一个字符串,结合它们的字符长度和编辑次数,我们便可以计算两者之间的相似度。

例如,将“kitten”一字转成“sitting”的莱文斯坦距离为 3:

  1. k itten → s itten (k→s)
  2. sitt e n → sitt i n (e→i)
  3. sittin → sittin g (插入 g)

当获得字符串相似度之后,进而可以计算出 JSON 的相似度即 response 和 request 的相似度,再结合多级 key 的影响因子策略进而计算出两条流量的相似度。

4.3 筛选策略

获得相似度之后,我们还会通过多层策略来筛选。

  • 设置 response 和 request 的比重,因为通常 response 更好地反应接口的差异,设置比重可以更好的衡量流量间的相似度,利于后续筛选。
  • 设置多层动态阈值,随着数据量的增加,动态调节能够存入的相似度阈值,以便更好地控制记录的流量数目,保证记录下来的流量数在后期是收敛的,不会无限增加。
  • 记录流量重复次数,可以用于后续生成用例,我们认为重复更多次数的流量其重要性越大。

通过多重策略,来保证我们能够筛选出“优质”的流量用于后续接口测试。

五、总结及其他

目前本方案已经为多个服务(包括微视、企鹅号等)生成多条接口测试用例,已经超过 1000 条合入到服务中在日常 mr 中进行接口测试。

图片图片


本文地址:https://www.6aiq.com/article/1628117222607
本文版权归作者和AIQ共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出

更多内容请访问:IT源点

相关文章推荐
  • 该目录下还没有内容!

全部评论: 0

    我有话说: