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、开源、游戏、酷家乐、音视频、客户端、服务端、数字经济、效能提升、质量保障、智能化测试