网络游戏协议测试（接口测试）的一些总结

什么是游戏协议？

　协议是网络游戏前后端交互的实现方式。

游戏中协议的收发过程是怎样的？

　当我们在进行游戏的时候，我们点击了某个按钮进行某一种游戏行为，这个时候，客户端会按照跟服务器约定好的一些规则，将我们的游戏行为对应的请求和参数通过网络封包发送给服务器，服务端在收到这个请求后会对请求内容进行解析，以确定客户端进行的是什么游戏行为，并获取到对应的请求参数，之后服务端会根据代码逻辑来对这些数据进行相应的处理，并将处理结果同样以封包的形式返回给客户端，客户端在接收到封包之后，也会按照约定好的规则进行解析，并将解析后的结果展示给玩家。

　不同的游戏有不同的协议类型和实现方式，有可能客户端发送的请求服务器并不会响应（无效请求），也有可能服务器会主动推送协议给客户端（如整点活动的开启）

常见协议

1.TCP协议（传输控制协议）
　市面上大部分的游戏都是使用的TCP协议，当游戏不需要非常强的实时性，能够容忍一定程度延迟的时候，推荐使用TCP协议，但如果是强实时性的游戏（如moba和fps类型的游戏），就需要使用UDP协议来尽量减少延迟
　优点：面向连接（一对一，类似于打电话），传输可靠（能够保证数据的正确性），有序（能保证数据的顺序），可以传输大量数据（流模式），简单直接，无需再次开发
　缺点：对系统资源的要求多，程序结构较复杂，丢包重传时延迟较大

2.UDP协议（用户数据报协议）
　上面讲到了，一些实时性强的竞技类游戏，一般是使用UDP协议
　优点：速度快，对系统资源的要求少，程序结构简单，支持一对一，一对多和多对多的交互通信
　缺点：传输不可靠（可能丢包）、无序（不能保证数据的顺序），传输数据量小，可能需要二次开发来保证实时性

3.websocket协议
　websocket是基于HTML5语言而诞生的一种协议，websocket跟socket不同，websocket是一个完整的应用层协议，包含一套标准的API，多应用于H5和微信小游戏
　而socket是对TCP/IP协议的封装和应用，它并不是一种协议，而是为了方便大家直接使用更底层协议而存在的一个抽象层，将应用层之间的网络通信简单化，当socket连接创建时，通过参数指定使用的传输层协议类型，当使用TCP协议进行连接时，该socket就是一个TCP连接
　在websocket中，需要服务器和客户端（或浏览器）通过http协议进行一次握手动作，然后单独创建一条TCP通信通道进行数据传输

PS：如果不需要写机器人的话，其实不太需要关心协议的实现方式，不管是TCP协议，还是websocket等等，我们需要关注的其实是服务器对协议参数的验证。

常见的游戏协议封包构成

　一般来说，一个通过socket传输的完整的游戏协议封包，通常由包长、协议号、验证码、协议参数构成（具体项目可能实现方式略有不同，具体可跟开发人员求证）

包长：当前封包的字节流长度，用来判断收到的字节流是否是一个完整的封包
协议号：客户端与服务端之间定义的具体的事件编号，通过协议号，我们可以知道客户端是进行了哪种操作
验证码：客户端跟服务端之间定义的一套封包有效性验证机制
协议参数：客户端与服务端进行协议传输的时候附带的实际协议内容，是某种游戏行为的具体实现，协议参数又分为多种类型，有int型，str型，list型，甚至是某种自定义的对象，这个一般需要参照具体的游戏协议文档。

　ps：由于TCP特殊的流模式，某些情况下，我们收到的封包可能是由多个封包黏连在一起的，那么在进行封包处理的时候如何判断是否是一个完整的封包呢？就需要通过包长来判断，如果当前封包的长度等于包长的值，那么就是一个完整的封包，否则就需要对封包进行截取拆分

为什么要测协议？

　游戏中很多行为限制，是在客户端层面的，在我们进行某些非正常游戏行为的时候，客户端已经在逻辑层面阻止了我们的这种行为（比如，在金钱不足的时候我去买一件物品，客户端会判断你的钱是否足够买这件物品，如果不足则会提示金钱不足，并阻止你这次行为），但之前我们讲了，客户端与服务端之间是通过协议封包来进行交互的，客户端阻止你的行为，只是阻止客户端自己来发送这个行为封包，那么服务端对于这种非正常情况是否有做判断呢？如果我伪造一个这样的封包，或者在网络不顺畅的时候，多次点击购买来重复发送封包，是否可以在金钱不足的时候购买成功呢？是否存在刷钱刷道具的漏洞呢？
　这个就是我们进行协议测试的目的：验证服务器逻辑的正确性！

抓包和发包

1.抓包
　既然要分析协议，那么首先就需要看到协议，看到协议那么就需要监听服务端与客户端之间的通信，并抓取游戏封包
　市面上目前有很多抓包工具，常用的游戏抓包神器WPE、其他的还有fiddler、wireshark等，使用方法这里不做过多介绍，网上很多使用教程。

2.发包
　以WPE为例，在我们抓到包之后，右键其中的一条封包选择发送，就可以在新弹出来的界面修改封包内容，在修改好对应的参数之后，点击发送按钮，这条修改后的封包就会发送给服务端了。

　开发人员一般也会留一个GM指令的接口或者其他的发包方式，通过预留接口也可以实现对服务器进行发包测试。
　但一般来讲，WPE的可读性太差，GM指令的操作便利性也比较差，建议有能力的测试人员或开发人员，能自己写一套发包工具（类似下图），方便进行协议测试。

如何分析协议？

　我们在协议测试的时候，主要是针对客户端对服务端发送的协议进行测试，因为游戏数据的处理大部分都是在服务器上进行的，我们需要验证的是服务器的逻辑处理环节，而服务器返回的封包，是已经在服务器逻辑处理完成之后的，我们就算对这些封包进行了修改，也只是修改了客户端的显示而已，并不会对服务器的数据造成任何影响。
　那么怎么样去分析呢？请看下面这张图：

　我们玩游戏时进行的游戏行为，都是具有行为前置条件的，比如我们买东西，那么就需要有足够的钱，想要挑战某个副本，就需要有足够的等级和挑战次数，我们要做的，就是推翻前置条件，在条件不满足的情况下，来发送一个正常的游戏封包。前置条件大概整理了以下几种类型：
1.等级无效
　对于某些具有等级限制的玩法，在等级不足的时候进行发包验证
2.时间无效
　对于某些具有时效性的玩法，在时间范围之外进行发包验证
3.货币无效
　对于需要消耗货币的玩法，在货币数量不足的时候发包验证（这里的货币指的是广义的货币，不单指金钱，还包括副本次数等等）
4.次数无效
　这里指的是一些有次数限制的玩法，在次数不足的时候发包验证，如某个活动奖励，每个角色只能领取1次，那么在领取完奖励之后，再发送一次领取奖励的封包，看服务器的处理逻辑
5.前置条件无效
　这个比较特殊，举个例子：帮派每日礼包，帮派成员每日可以领取1次，前置条件就是角色必须已经加入帮派成为帮派成员，在角色未加入帮派的时候，这个奖励通过发包是否可以领取？
6.参数范围无效
　这个也有点特殊，还是通过一个例子来说明：游戏内的7天登录协议，协议参数为对应奖励的天数，如玩家要领取第一天的奖励，在发送协议的时候参数为1，第二天为2……第七天为7，那么0和8就是范围外的无效参数
7.特殊限制
　未在上述条件中的可能存在的一些其他的限制，如在跟NPC提交任务和领取奖励的时候，需要在一个有效交互范围之内，在这里特殊限制就是交互距离

协议测试用例设计

　测试用例并没有一个固定的格式，看个人喜好，但建议包含协议信息以及有效无效条件等，下图是个示例，供参考：