基于TCP协议的游戏代理接口测试工具＜一＞：设计初衷与工具构想

设计初衷

大势所逼

众所周知，区别于HTTP之类的协议，由于tcp协议包体通信的高度定制化导致业内基本没有通用的接口工具用于游测人员进行日常使用，大部分的情况是基于这种状态下只能进行测试工具定制。在日益兴盛的游戏行业中，对于游测的各种测试维度的要求也在逐步增长，而接口测试，也就是常规所说的协议测试在日常的测试工作中重要性和占比也是高居不下，毕竟直接关系到游戏的营收和寿命，从而在自我折磨的道路上越走越远。

难点与破局

• 高度定制化：由于tcp在游戏内应用的特性，在协议的约定上面就必定存在各种各样的特殊设定，常见的有字段类型-int、string、array之类和定制类型、字段位数、包体预留位乃至加密字段等等。所以要去模拟协议和解析协议就必须要实现一套与双端（C/S）一致的封包和解析机制；
• 不可避免的自动生成：由于需要定制解析和封包，所以必须要面临的一个问题就是要构造出所有协议的封包和解析方法，而这个时候面对整个游戏项目下的协议处理，手写方法明显是不现实且成本巨大的。因此必须要根据公司或者项目组内的生成方式再一模一样复刻出双端协议封包和解析的自动生成方法（PS:当然如果测试权限够或者公司内部有单独的测试版本可供使用-即测试可以直接改造游戏代码的话就不用重复造轮子了）；
• 测试定制化：测试工具做出来肯定是为了给测试服务的，所以测试用途、便利性、功能拓展方面也需要有充分的考虑。以常规的协议测试举例：测试人员通过wireshark之类的工具抓取到协议包，提取到data包之后，再通过对照协议规则进行对应数据提取，提取出来后再对数据进行编解码从而得到可读的数据，然后才能进行数据验证，判断协议数据是否正常。在这个流程上面就能提取到多个工具的测试用途需求：协议抓取、协议解析、可视化，同时延伸出：协议拦截、特定协议抓取、二次封包、包体构造转发等等；

• 承上启下-破局：基于完整的解析机制下的压测，已经存在上述机制之后，批量真实登录不是梦，用于服务端场景压测、登录压测等等用途也是顺势而为；接口测试自动化开展，基于协议拦截和包体封装的机制可以轻松实现协议录制，然后辅以自动化测试框架pytest+allure即可逐步实现接口自动化。

工具构想

工具开发历程（记录走过的弯路）:简易测试客户端–>游戏内置可视化工具–>接口代理工具。
提效是测试第一生产力（顺便创造摸鱼空间，emm，顺便…）

• 简易测试客户端：作为最初版的接口工具，它的初衷往往是朴素的，当时由于组内测试人员较少（emm,没错就在下一个），加上公司体量相对较小，个人算是组内引进的首任测试人员，各种基建和测试方面的构建基本都是从0开始，所以初版的工具只是为了解决一个小小问题：批量创建测试号。它的设计就是基于Python写一个简易的客户端用于连接游戏服务器，然后定制协议内容根据设定的顺序发送给到服务端，由于当时缺少解析机制，全靠手写协议解析，从而导致可扩展性很差，维护成本也很高，后续在应用时测试用途也逐步变成有限的几种。当前如果能加上前面所说的全套解析机制后，就能发挥更大的作用；
  

• 游戏内置可视化工具：在上一代的基础上痛定思痛：手动编码折磨、无法支持可视化，为了避过协议解析这块的工作（为什么不直接上解析？实在是规则太多太麻烦），调整方案改为在游戏客户端内搭建一个工具功能。通过对游戏客户端内部协议通信基类的分析，发现在基类的解析方法中可以很方便的拦截和抓取到明文的协议内容，所以心生一计-‘借鸡生蛋’，在客户端现有的机制上增加一个测试模块，用于获取协议基类的通信数据同时通过unity的Gui搭建一个内嵌的展示面板展示出协议数据和其他操作。但是这个方法面临一个问题就是内嵌测试代码到游戏主题中是一个比较大的风险项，尽管采用的是非拦截式（即不拦截协议只收集一份）的方式，在缺少特定分割的测试环境的情况下也是有不少的风险，同时内嵌的方式意味着工具的兼容性会相对一般，针对不同项目要额外处理接入，另外无法支持多用户登录，最后在组内讨论缺少测试环境情况下，风险不可接受，该方案夭折（不过有环境和条件的同仁可以试试，业内也有类似的做法）；
  

• 接口代理工具：为了在方案二的基础上完全与游戏版本解耦，通过搭建中继服务器来进行协议
  次处理。游戏客户端连接中继服务器，然后中继服务器再连接游戏服务器，从而实现游戏客户端和游戏服务端所有的通信数据都经由中继服务器进行转发处理，而中继服务器可以对转发的数据进行二次的处理，并且支持可视化的需求。在此基础上搭建完整的解析机制，可拓展新更强，同时可以支持即插即用。