共计 7103 个字符，预计需要花费 18 分钟才能阅读完成。
Testerhome 社区爱好者合力编写了《2021 接口测试白皮书》，并于往年 2 月底公布。本文节选自其中的的「莉莉丝公司接口测试实际分享」章节。点击链接可下载完整版《2021 接口测试白皮书》。
莉莉丝品质管理中心自研伏羲的第三个版本，逐渐往工业化倒退，接口测试工作指派，接口进度工作流等等性能介绍。
目前在公司外部服务了 9 个我的项目，共 50+ 版本，接口 Case 数量约 5 万条以上，产出问题还会有确认流程，过滤了自测等数据，个别周数据能够产出 100+ 问题。
游戏接口测试的难点
对于一般的接口测试，网络协议通常是 常见的字符串、Json 等，间接应用常见的接口测试工具（如 就能够将用例数据发送往服务器，接着期待响应后果即可。
但对游戏接口测试来说，各个游戏我的项目的通信协议和数据格式都不肯定相 同。通信协议可能是 TCP Protobuf、Json、二进制等，并且通常还会须要对数据进行加密解密，压缩解压缩等。
绝对于传统接口测试，这就是游戏接口测试最简单的一环，也是最先须要解决的一环。
游戏接口测试解决方案
游戏公司都是自定义的协定 + 序列化数据结构。
没有什么开箱子可用的开源能够间接和每一个游戏我的项目失常通信。做接口测试的第一步，须要依据定制特定的客户端网络层解决，来实现接口数据的发送与接管。
先须要做的就是实现一个两头服务，它能够依据游戏我的项目的不同，将数据转 换为特定的格局，再由特定的网络协议发送往对应的游戏服务器。
等服务器有回应时，再依据特定的格局将网络层接管的二进制数据解析成方 个别是可视化成 Json，不便后续断言解决，响应模板和 Schema 模板以及断言模式在下文介绍。
用例编辑中，除了设置申请参数，断言也十分重要，断言增加界面如下：
增加断言次要蕴含四个局部：断言名称、表达式、断言形式、断言值。
“表达式”是由接口里的“响应模板”解析进去的，操作时只须要从下拉框 中按层级抉择对应的字段就行了，不须要手动编辑。
“断言形式”反对一些根底的判断形式，比方等于、不等于、大于、小于等，针对数组，还反对判断数组长度或者判断是否蕴含某个数据。
另外，如果伏羲提供的断言形式不能满足理论需要，还反对“自定义断言”，测试人员须要本人写判断脚本，反对 JavaScript 语言。
游戏协定发包和回包数量是不固定的，回包会有多个，能够依据包头外面的 命令号去判断具体去解析哪个包进行断言。如果须要验证数值正确，须要解析多 个包。比方抽卡协定，发一条，收 来判断协定是通的。获取卡牌信息的查看就须要获取其余的包，这个后果如果下 面一个接口须要用到，是须要存在为两头变量的。
测试次要流程
01 次要流程
- 理解并实现游戏网络层代码，确保能够和服务端失常通信
- 筹备接口协议文档、参数配置文档、相熟游戏玩法
- 设计欠缺测试用例
- 筹备协定模块、增加用例参数、增加用例断言
- 发送接口，查看断言后果
- 从流程中能够看出，在真正开始测试前，须要筹备三块内容：网络层解决、接 口文档和测试用例。
02 网络层解决
- 建设连贯
- 收包发包
- 重连心跳
- 加密解密
- 压缩解压缩因为组内平台开发后盾应用的是 终网络层解决抉择了用 Netty 业务需要，能够疾速实现各个游戏我的项目客户端的网络层解决，确保能够和服务端 失常通信。
网络层解决实现
01 建设连贯 片段
02 编解码操作 片段
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 模块治理介绍
伏羲中会应用“模块”来对大量的“接口”和“用例”进行治理，模块界面如下：
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 协定录制界面输出相干信息，点击“开始录制”：
2. 手机上操作游戏，界面上会同步展现设施和服务器的交互信息：
- 操作实现后点击“进行录制”，历史录制信息会保留在【协定记录】里，不便后续查看。
截止目前，咱们还开发了更多新性能，心愿在 2022 年的接口测试白皮书上给大家带来更多的内容。
接口测试系列
接口测试系列之 – 前端交互测试和后端逻辑测试
接口测试系列之——接口平安测试
接口性能测试计划剖析
本文节选自 Testerhome 社区爱好者合力编写的《2021 接口测试白皮书》，点击链接可下载完整版《2021 接口测试白皮书》。
今日份的常识已摄入~
想理解更多前沿测试开发技术：欢送关注「第十届 MTSC 大会·上海」>>>
1 个主会场 +12 大专场，大咖星散精英齐聚
12 个专场包含：
知乎、OpenHarmony、开源、游戏、酷家乐、音视频、客户端、服务端、数字经济、效力晋升、品质保障、智能化测试
