游戏接口协议测试

随着对于质量保障和安全性等各方面的要求越来越高，接口测试在测试工作中所占的比重越来越大，不论是web项目、app还是游戏，接口测试都是不可或缺的一环。而在游戏业中，是否做好接口测试格外重要，往小了说影响是单个接口单系统，往大了说可能影响游戏的整体运营。此篇主要以游戏测试作为锚点，重点阐述在游测岗位怎么开展接口测试，协议方面的话以tcp为例，希望能对想了解的同学有一定的帮助。

一、协议分析

对于测试人员常常说的测试第一步便是需求分析，那进行接口测试的时候也不外如是，做功能的时候有需求文档，而做接口的时候并没有什么设计文档给到，测试人员拿到的可能就是一份协议文本或者说连文本都没有，那要怎么分析呢？

假设现在开发提供到一个协议文本，从上图中的文本可以清晰的看到协议的基本信息，包括客户端协议键值和服务端的返回信息，因此我们可以从文本中提取的信息主要就是键值、键值格式、以及键值的字段长度，所以我们在做介入前分析的时候主要针对以上的信息进行分析，会有这些考量方向：1、字段长度是否合理；2、是否存在过度数据暴露；3、是否存在关键数据客户端强依赖。

1. 字段长度是否合理
   从图中可以看到出去个别定制结构外，每个键值后都标注了字段长度int8、int32等（略微解释下，可能有些同学不明白是代表什么意思，int8可以理解为2的8次方也就是长度为256，其他以此类推），这个长度往往对应协议封解包所预留的字节长度，一旦超出可能存在截断显示、异常显示等情况。因此在分析时需要对每个键值的数值上限有一个大概的评估或者与数值策划进行勾兑，确认每个键值长度的是足够的。
   通常情况下，类似于战力、伤害统计、货币等一些较大值比较容易出现定错长度的情况，比如上面的value字段，该协议属于伤害统计榜单数据的查询协议，int32位表示能容纳42亿多的数据，而对于我们游戏来说42亿的伤害对于相对后期的玩家来说几乎都能达到，所以可以判定该字段长度不足。

2. 是否存在过度数据暴露
   数据暴露主要考量的是有些比较敏感或私密性的信息被后端暴露的情况，比如账号信息、明文密钥等等。

3. 是否存在关键数据客户端强依赖
   强依赖的意思是服务端需要直接使用来自客户端的关键数据，像此种情况的话通常容易出现被篡改数据、被刷的情况。

   
   以上图为例：该战斗协议中客户端存在一个result键值，该键值用于发送战斗结果，也就是说胜负结论由客户端给出，因此很容易辨别其中的风险性。而在实际的功能开发中，有时候迫于现实情况需要把一部分的性能开销大的东西交由客户端去做，所以类似这种情况也不罕见，需要额外做好服务端的相关校验。

二、通信交互模式

通信交互严格意义上来说不算是对于单接口的测试，放到第2节点主要是因为这块对于接口测试介入后的测试设计是一个不容忽视的补充。
在游戏业务中交互模式无非两种：客户端请求、服务端推送。这两种方式往往是影响客户端表现或者数据同步的问题，而接口测试这块我想补充的是另外的方向，比如请求频次、协议时序，乃至于说接口压力。

• 请求频次
  请求频次的问题不多见，加上很多时候没有特意去关注协议交互情况时不会发现，除非有明显的表现特征，比如频繁弹出提示、界面频繁刷新、界面卡顿等情况，
  
  比如说游戏内常见的培养系统，常常会有类似一键升级、自动升级等操作，这类操作通常会涉及较大数量道具的连续使用或者大批量使用，特别是连续使用方式，客户端如果协议采用的是以单个消耗作为单体协议发送，当道具数量较大的时候，就会出现短时间内的大量协议请求，在一定程度上会造成协议堆积，如果又恰好需要根据服务端返回的数据来进行界面刷新表现，那就只能恭喜，界面必定极为卡顿，所以像这种请求设计一定需要提前预防，尽量在开发周期内去解决，同时在一定程度上还可以降低流量消耗。

• 协议时序
  协议时序方面的问题在测试执行过程中去发掘要更为困难一些，这种情况往往隐藏的颇深，甚至于说出现的可能性很小，往往体现在依赖数据的异步处理，也就是说下一条协议需要的数据还没回来就进行了下一步操作，这种问题需要提前与技术沟通之外，测试人员可以通过弱网的方式进行模拟，或者进行重复性的发包验证，当然有条件阅读代码就更好了。

三、常规的字节流格式

字节流格式常由包体长度—协议号—协议内容三个主体结构组成，而出安全的目的，可能各个项目会在协议内容部分增加一些偏移量或者额外键值处理。

通过wireshark对协议进行抓包，得到以上的协议包体数据，结合协议文本进行拆解：

分解结构如下：

16位包体长度：000a ---->10
16位协议号：81bf ----->33215
协议内容：000300010000
{
subtype:0003
ranktype:0001
page:0000
}

四、接口测试用例设计

完成需求分析之后，就可以对接口进行用例设计，可以从以下方向进行考量。

• 等价类
• 边界值
• 幂等性
• 非对称传参
• 异常检查-健壮性
• 敏感、特殊字符

前三个测试祖传三件套就不赘述了，先说非对称传参，这里的非对称指的是协议文本格式键值的数量、位置的不一致，比如缺参、加参、参数错位，缺参常见于默认值检查，检查出现缺参时服务端是否存在默认值设置，且默认值能够绕过限制或者获得额外的收益，加参和参数错位更多是对接口健壮性的检查；
异常检查除了上面非对称传参之外，异常检查主要是健壮性检查，比如异常结构引起接口报错、异常键值引起掉线、甚至说发送超限数据引起广播报错，比如在聊天频道发送无法解析的表情包代码之类的情况；
敏感、特殊字符 敏感词校验，函数式字符或者函数式字符串等可能带来解析后异常识别问题的的内容；

五、接口测试开展

• 目标选择
  可能新入行的测试小伙伴或者平时做接口偏少的同学对于测试过程中哪些节点需要进行接口测试会有些迷惑，这里简单做一个概念的表述，如有错漏，敬请指正。
  常规来说我们做接口测试的目的是为了跳过客户端本身的限制去检查服务端接口逻辑的正确性，也就是说接口测试实际是模拟客户端对服务端业务的测试。那在游戏测试中应该对哪些协议做接口测试呢？首先该协议是由客户端发起的，而不是服务端主推协议，其次便是重点业务的检查，主要是对条件、系统状态的检查，特别是游戏系统中常存在的系统开放、操作前置条件、奖励领取、数值上限，行为限制等等这些类型的接口都需要重点检查。

• 介入时机
  测试介入的时机跟测试人员实际业务下沉深度关联，比如说黑盒功能、灰盒、白盒测试等介入时间节点各有不同，原则上介入越早成本越低，白灰盒测试可以与开发人员保持相对并行的测试进度，通过mock或者内部工具提前在双端联调之前就进行接口方面的介入，当然也有一部分公司选择白盒阶段交由开发人员自行测试，而测试人员提供测试思路与用例，实现一定程度的左移。而对于黑盒功能测试人员来说，通常需要等到联调结束提供到初始版本的情况下方才介入，这个阶段介入需要对于早期问题的预防或者测试时间分配上面会稍微弊端，但是在一定程度上是相对减少测试工时的，因为表现与数据可以同时进行，相对工时会耗费小些。

• 开展与工具
  完成前面4项的工作准备之后，在双端提交测试版本后，测试人员可以正式进入接口测试的开展。

• GM工具
  游戏工作室通常会提供内嵌在开发版的GM工具，用于辅助各类调试和各类功能系统测试，接口模拟转化基本也是可以实现的。比如通过定制一条协议用于指定发送包体，然后服务端进行统一的触发分发包体去目标接口来达到模拟协议的目的。但是像这样一类的工具的话，通常为了兼顾其他非接口方面的需求，接口测试方面的拓展性会稍差一些，面临复杂的测试场景模拟稍有些不足，优势的话就是不用单独管理，随时取用。

• 自研接口工具
  1、类GM工具的接口定制工具，这个工具是一种比较普遍的实现方式，通过在游戏客户端内置一个单独的悬浮窗或者窗口UI的方式，依托客户端已有的通信底层构造接口测试工具，这种方式在较大程度上提高了测试开展的自由度和降低测试成本，由于tcp协议的封解包的难度并不低，对于很多功能测试人员来说如何去维护和新增协议是比较繁琐的事情，通过可视化和底层借用不仅降低测试门槛，对于测试提效也有不错的作用。
  工具实现逻辑大致如下：
  
  初版的demo界面：
  

  2、完全解耦的代理工具，代理工具由于独立于游戏包体之外，无疑可拓展性和自由度是更高的，但是对于测试人员来说前期的成本也是更大的，除了实现协议收发之外，最主要的是要有一套完全与双端一致的封解包逻辑，同时需要支持自动更新或一键生成，手工对齐解析体成本会巨大无比。具体实现过程点击这里可以去我之前写的单章<O…O>

工具框架如图所示：

成品展示：这里个人只选择了做窗口工具，而不是做web框架。

PS：背景图随便找了一张有点粗糙，敬请忽略dog。

• 第三方工具
  与tcp协议相关的第三方工具主流的有抓包工具 wireshark、tcpdump,经典封包工具wpe，还有比较主流的jmeter。
  个人对于jmeter的使用实践相对较少，但是初略使用下来感觉对于tcp接口测试的自由度和拓展性会稍差些，比较依赖二开才能满足测试需要。