接口测试系列

Testerhome社区爱好者合力编写了《2021接口测试白皮书》，并于今年2月底发布。本文节选自其中的的「莉莉丝公司接口测试实践分享」章节。点击链接可下载完整版《2021接口测试白皮书》。

莉莉丝质量管理中心自研伏羲的第三个版本，逐步往工业化发展，接口测试任务指派，接口进度工作流等等功能介绍。

目前在公司内部服务了9 个项目，共 50+版本，接口 Case 数量约5万条以上，产出问题还会有确认流程，过滤了自测等数据，一般周数据可以产出100+问题。

游戏接口测试的难点

对于普通的接口测试，网络协议通常是常见的字符串、Json 等，直接使用常见的接口测试工具（如就可以将用例数据发送往服务器，接着等待响应结果即可。

但对游戏接口测试来说，各个游戏项目的通信协议和数据格式都不一定相同。通信协议可能是 TCP Protobuf、Json、二进制等，并且通常还会需要对数据进行加密解密，压缩解压缩等。

相对于传统接口测试，这就是游戏接口测试最复杂的一环，也是最先需要解决的一环。

游戏接口测试解决方案

游戏公司都是自定义的协议+序列化数据结构。

没有什么开箱子可用的开源可以直接和每一个游戏项目正常通信。做接口测试的第一步，需要根据定制特定的客户端网络层处理，来实现接口数据的发送与接收。

先需要做的就是实现一个中间服务，它可以根据游戏项目的不同，将数据转换为特定的格式，再由特定的网络协议发送往对应的游戏服务器。

等服务器有回应时，再根据特定的格式将网络层接收的二进制数据解析成方一般是可视化成 Json，方便后续断言处理，响应模板和Schema模板以及断言模式在下文介绍。

用例编辑中，除了设置请求参数，断言也非常重要，断言添加界面如下：

添加断言主要包含四个部分：断言名称、表达式、断言方式、断言值。

“表达式”是由接口里的“响应模板”解析出来的，操作时只需要从下拉框中按层级选择对应的字段就行了，不需要手动编辑。

“断言方式”支持一些基础的判断方式，比如等于、不等于、大于、小于等，针对数组，还支持判断数组长度或者判断是否包含某个数据。

另外，如果伏羲提供的断言方式不能满足实际需求，还支持“自定义断言”，测试人员需要自己写判断脚本，支持 JavaScript 语言。

游戏协议发包和回包数量是不固定的，回包会有多个，可以根据包头里面的命令号去判断具体去解析哪个包进行断言。如果需要验证数值正确，需要解析多个包。比如抽卡协议，发一条，收来判断协议是通的。获取卡牌信息的检查就需要获取其他的包，这个结果如果下面一个接口需要用到，是需要存在为中间变量的。

测试主要流程

01 主要流程

了解并实现游戏网络层代码，确保可以和服务端正常通信
准备接口协议文档、参数配置文档、熟悉游戏玩法
设计完善测试用例
准备协议模块、添加用例参数、添加用例断言
发送接口，查看断言结果
从流程中可以看出，在真正开始测试前，需要准备三块内容：网络层处理、接口文档和测试用例。

02 网络层处理

建立连接
收包发包
重连心跳
加密解密
压缩解压缩因为组内平台开发后台使用的是终网络层处理选择了用 Netty 业务需求，可以快速实现各个游戏项目客户端的网络层处理，确保可以和服务端正常通信。

网络层处理实现

01 建立连接片段

02 编解码操作片段

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-z3C46AhL-1651128783479)(https://upload-images.jianshu.io/upload_images/11651132-f1f0c234cfd2e12d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]

03 心跳处理片段

04 重连处理片段

05 保持长链接片段

b.option(ChannelOption.TCP_NODELAY, true);
设置连接超时 b.option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 5000);
设置读写超时 ch.pipeline().addLast(new IdleStateHandler(10, 10, 10)
发包 channel.writeAndFlush(“”);
收包 ChannelInboundHandlerAdapter.channelRead()

接口协议文档

网络层的问题解决了之后，还需要知道具体的接口参数应该怎么填，否则随便发送一堆消息服务器也是不认的。而且设计接口测试用例的时候也需要根据接口协议来设计。

这里的接口文档获取包含两个部分：接口协议文档和参数配置文档。

通常接口文档应该包含以下几个部分的信息：请求方式、请求参数、返回参数以及描述信息等，如下图所示：

从接口文档中可以清晰的了解到接口的请求路径，接口的请求或者响应结果中包含了哪些字段，字段应该是什么类型的以及字段是否必填，还有各个字段以及接口的描述信息。

游戏项目的接口文档，由于目前接触到公司的各个游戏项目都是使用的数据结构，所以这里的接口协议文档也以 Protobuf 来进行介绍。

可以直接用来当作接口文档，但使用起来会相对不太方便。主要有以下几个问题：

proto 版本不同，测试人员可能学习不同版本 proto 的各种语法规则，并 proto3 文件中是不能看到的；
结构体定义不同，比如请求和响应，有的项目使用做区分，有的项目使用 req down.proto；
结构体嵌套，在 proto 至嵌套的结构体会在另一个用不便；
备注信息不准确，通常项目组提供的段都是没有描述信息的，测试人员每次都需要找项目组同学询问，也是比较麻烦。

综上所述，做游戏接口测试的时候，会单独整理一份接口文档，以便更好的进行接口测试。在平台内，整理后的接口文档如下：

因为通常游戏项目的接口数量会特别多，如果每个接口都需要手动添加，费时费力，会有点得不偿失，并且如果遇到试人员来说也是一场灾难，因为他需要一个个字段进行对比。

所以我们会使用代码解析 proto 文件，来自动添加或者更新接口文档。

参数配置文档

"接口文档"整理完后可以知道应该传哪些参数和某个参数是什么格式，除了这些，还得知道参数应该传哪些值，比如商店购买道具，需要知道商店ID。

可以把策划配置表做数据验证的时候，存入到数据库，用的时候进行查询。我们拿到的一个相关参数配置表：

游戏接口测试案例

正常协议是可以减轻一些回归的压力，接口验证数据是否和配置表一致。

异常协议在跨场景发送，重发，提前触发修改时序，参数异构，异步快速发，以上是支持所有游戏类型的。

网络层处理和接口文档的问题解决了之后，接下来最重要的就是测试用例的设计了，完善的用例设计既能效率。

这里整理了一些接口测试用例设计的思路，可以从三个方面来进行：

输入：针对参数类型进行设计
逻辑处理：按照游戏逻辑进行设计
输出：根据结果进行设计
输入：输入主要是针对参数类型进行设计。

常见的参数类型有：数字、字符串、数组、布尔值等。

针对数字，设计思路：

等价类

取值范围内、取值范围外

边界值

取值范围边界：边界值最大、最小、边界值最大

数据类型边界：数据类型的最大值、最小值等

特殊值

0、负数、空

遍历法：对取值范围内的所有值进行遍历

举例

比如任务 ID 字段，字段类型是 int 类型，取值范围是 1-10：

按照等价类方法，可以取值为 5 和 11。

按照边界法，可以取值为：0、1、10、11、2147483647、-2147483648。

按照特殊值，可以取值为-1。

按照遍历法，1-10 所有值都取一遍。

常见问题

任务 ID 不在取值范围内也可以请求成功

购买数量为负数也可以购买成功

等级字段为 0 也可以升级成功

针对字符串类型的参数，可以从长度和内容两个方面来设计测试用例，设计思路：

长度

等价类：取值范围内、取值范围外

边界值：规定范围边界

特殊值：空格、空字符串

内容：

特定类型：中文、英文、大小写等
特殊字符：！@#￥%?&等
敏感字：法轮功等

举例

比如工会名称字段，字段类型是 string 类型，长度不能超过 20 个字符串：

按照等价类方法，可以设置 20 字符串以内的内容和超过 20 字符串的内容；
按照边界值方法，可以设置正好 20 个字符串和正好 21 个字符串的内容；
按照特殊值的方法，可以设置空字符串按照特定类型，可以设置同时包含中英文、大小写字母的内容；
还可以设置内容包含特殊字符或者敏感词的内容。

常见问题：

设置工会名称超长，可以设置成功

设置公告包含敏感字，可以设置成功

发送消息内容为空，可以发送成功

针对数组，设计思路

成员个数

等价类：取值范围内、取值范围外

边界值：规定范围边界成员内容

等价类：合法和非法成员

重复值：重复的成员比如上阵英雄最多五个，需要以数组形式传入英雄 id：

按照等价类方法，可以设置 4 个英雄和一次设置 7 个英雄

按照边界值法，可以设置 5 个英雄、0 个英雄和 6 个英雄

按照成员内容等价类，可以设置非法的英雄 id

按照重复成员方法，可以设置两个同样的英雄 id

常见问题

可以设置两个同样的英雄

设置非法英雄

可以设置超过最大数量的英雄

业务逻辑

常见的业务逻辑处理，可以分为以下几个方面：约束条件，操作对象，状态转换，时序分析。

约束条件，设计思路

数值限制

比如分数、等级、金币边界值限制

状态限制

登录状态、任务完成状态等

关系限制

好友、非好友，解锁、未解锁等

权限限制

会员、非会员，会长、非会长等

状态转换，设计思路

主要检查对象状态的转换，状态改变后是否还可以继续之前的操作。

常见问题

优惠券使用过后还可以再次使用

加入工会后还可以再次加入另外的工会

重复领取奖励

时序

在一些复杂的操作中，通常共包含了多个接口，而这一系列接口通常需要按照指定的顺序来进行

执行顺序设计思路

1.正常顺序

2.错乱顺序或者不存在顺序（已经领取过的继续领取，把发送等等）

返回结果断言的设计思路

返回结果会两个方面：

1.正确回包，是指回包内容是否正确，比如回包里面有想要的命令号信息，字段的信息的值正确。

2.错误回包，对应命令号和错误码是否正确，错误信息是否正确。不至于说应该错误的回包回了正确的包。

比如：针对正确回包，比如执行完购买操作后检查回包里金币数量是否正确针对错误回包，比如金币不足时购买道具，查看错误回包的提示信息是否准确

响应时间

通常接口请求都是能在特定时间内返回的，但是也有个别例外的情况。比如接口本身没有返回，或者返回很慢。

"伏羲"中可以设置接口请求的超时时间，将超时完第一个接口立刻就发送第二个接口，查看返回结果是否正确。

伏羲平台基础流程

01 版本管理相关操作

伏羲中每一轮的接口测试，都是从置服务器地址、对应的协议版本、版本测试进度、接口测试范围等。

02 版本一览

界面如下

【版本一览】中展示了版本名称、服务器地址、负责人、描述信息、更新时间等。

03 版本添加/编辑

版本的添加或者编辑界面如下：

“等级"对应的是版本类型，默认是默认是"父版本”，不过通常一个整个版本下的用例数量比较多，所以可能会有多个人参与接口测试，"子版本"功能会将每个人负责的用例隔离开，防止多人操作时用例冲突；

"名称"是伏羲中对应的版本名称，可以随便创建，但最好设置有特殊含义的名称；

"协议"是服务器的版本号，对应的是伏羲后台会根据什么协议来处理收发包的数据；

“host”、“post”、“url” 指的时当前版本测试所使用的游戏服务器地址。

版本协议更新

对于一个已接入的项目，通常服务端网络层处理是不需要修改的。

如果遇到网络层处理变动，比如收发包方式修改，加密解密方式修改等，需要通知测开组来修改伏羲后台处理。

游戏服务器更新，对于接口测试来说只有协议文件更新和一些业务步骤的修测试人员直接在伏羲平台上传更新的 proto 文件即可（这部分拆分出了微服，上传时需要填写 proto 文件对应的服务端版本号，操作界面如下：

业务步骤的修改在接口测试选择用例的地方进行编辑就行。

接口测试范围

按照伏羲中的测试步骤，第一步需要确定接口测试范围，确认完成后，可以直接在版本中配置测试接口，配置界面如下：

羲后台会根据当前版本的 proto 文件解析出所有的接口名称，并展示到前端界面，测试人员只要将需要测试的接口勾选上即可。

这里所配置的测试接口，会影响到最后“覆盖率报告”的统计结果，的通过标准就是所有配置的测试接口必须全覆盖。

比如通常 GM 指令（req_gm 和 req_gm）是不需要测试的，如果勾选上了，不会影响用例测试，但会影响到覆盖率统计结果不为 100%，版本最终测试结果为失败。

版本测试进度

当前伏羲一个稍微简陋点的进度管理，这个是可以后续对接到任务管理引擎里（这个不在该白皮书上面描述)，接口测试负责人需要根据实际情况，在 ”版本测试进度“中更新当前进度，版本进度会展示在伏羲“首页”，方便所有人知道当前测试情况。

除了管理进度，界面上还支持任务分配，可以把当前阶段的部分任务分配给其他人，多人执行，加快测试进度：

模块和接口管理

01 模块管理介绍

伏羲中会使用“模块”来对大量的“接口”和“用例”进行管理，模块界面如下：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0hwG0fbD-1651128783486)(https://upload-images.jianshu.io/upload_images/11651132-da5130f442fdd7f1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]

02 模块一览

这个模块展示了当前版本下的所有模块信息，包括：模块名称，测试状态，模块下包含的接口数、用例数、所产生的员根据实际情况手动创建，动解析当前模块下实际情况得出。

根据“任务分配”，还会展示当前模块是谁负责的；如果使用了会展示出本次版本下的的所有接口更新内容，提醒测试人员关注接口变动。

03 接口管理

因为公司大多数项目都是使用 proto 作为通信数据格式，但 proto 文件并不方便直接拿来做接口测试，或者有的项目不是使用的 proto 文件，并且是没有接口文档的。

所以伏羲中会有单独的界面来管理所有项目的接口内容，接口管理界面如下：

通常接口数据是由伏羲后台自动解析 proto 文件得出的，如果自动解析的数据不能满足需求，或者有的项目本身不能做到自动解析，接口管理中也支持手动编辑。

接口文档中主要包含三部分内容：接口名称和描述信息；请求和响应参数；数据模板。

请求和响应参数指的是接口的具体字段信息，包含了字段名称、字段类型、默认值、是否必填以及描述信息等。

数据模板分为请求模板、响应模板和 Schema模板，三种模板数据都是自动生成的，暂时不支持手动编辑。

协议参数数据生成

举例的该项目接口可以分为两类：TCP，HTTP，不同类型的接口模板以同。所有游戏项目都算作 TCP类型的接口；如果是平台的项目，协议类型是 HTTP 或者 HTTPS 的项目，在伏羲中都会算作HTTP 类型的接口。

如果是游戏项目，伏羲都支持根据接口名称自动生成接口数据。添加接口时可以直接从下拉框中选择对应的接口名称，伏羲后台会根据接口名称自动解析 proto 文件，并以特定的格式生成接口的请求或者响应数据。

添加界面如下：

01 请求模板

伏羲中的接口请求也是要按照对应格式来的，也就是这里的请求模板。请求模板是为了方便用例数据添加，添加用例数据时，就可以只填字段对应的数据，而不用关注要填哪些字段以及按什么格式填写。

02 响应模板

伏羲中支持自动断言，这就需要指定回包数据格式，响应模板主要用在断言功能里。可以很方便的指定要判断回包里的什么内容，不需要手动编辑。

03 Schema 模板

因为通常断言时，我们只会判断回包里的个别字段，比如回包里有上百个甚至更多字段，一个个判断就不太现实了。

为了更大程度得防止漏测，根据响应参数，自动生成了Schema 模板，每次收到回包后，除了根据断言判断个别字段是否正确，还会根据Schema数据对接口测试回包的数据值、数据类型以及数据结构进行详细的校验。如果 Schema 验证不通过，即使断言是成功的，接口测试也算失败。

协议录制

游戏接口测试过程中，我们需要知道接口应该怎么传参数。获取参数有两种方式：向程序同事去问参数如何填写，和自己抓包。

考虑到我们已经开发了微服务对于项目的网络层处理，再结合抓包获取到的网络二进制数据以及一些其他处理，就可以很方便的将手机和游戏服务器之间的交互信息读取出来，然后展示到界面。

除了可以实时录制接口协议，它还有一个功能，就是检查是否会重复发包。通常接口请求或者服务端响应都是不重复的，如果在协议录制过程中发现有紧跟着的两个协议是一摸一样的，那就可能是客户端或者服务端的处理有问题了。

协议录制界面展示的信息，包括"协议版本",“游戏服务器地址”,“抓包服务地址”。

协议版本：选择相应的 proto 协议版本（比如游戏版本_序号，在后台是按资源目录进行划分的）；
游戏服务器地址：就是要录制的游戏对应的服务器地址；
抓包服务地址：要启动抓包服务后获取。

具体操作：

启动本地服务：

为了执行接口协议录制，需要在 PC 机上安装"湛卢"，它是一个抓包服务，可以抓取并解析到手机和游戏服务器之间的交互信息，然后将信息转发到伏羲平台。

具体使用界面如下，极简使用：

1.1 启动湛卢

1.2 协议录制界面输入相关信息，点击“开始录制”：

手机上操作游戏，界面上会同步展示设备和服务器的交互信息：
操作完成后点击“停止录制”，历史录制信息会保存在【协议记录】里，方便后续查看。

截止目前，我们还开发了更多新功能，希望在 2022年的接口测试白皮书上给大家带来更多的内容。

接口测试系列之–前端交互测试和后端逻辑测试
接口测试系列之——接口安全测试
接口性能测试方案分析

本文节选自Testerhome社区爱好者合力编写的《2021接口测试白皮书》，点击链接可下载完整版《2021接口测试白皮书》。

今日份的知识已摄入~
想了解更多前沿测试开发技术：欢迎关注「第十届MTSC大会·上海」>>>
1个主会场+12大专场，大咖云集精英齐聚
12个专场包括：
知乎、OpenHarmony、开源、游戏、酷家乐、音视频、客户端、服务端、数字经济、效能提升、质量保障、智能化测试