背景：
所在的项目组一直是基于 tcp 通信的游戏项目，其中协议的定制化基本是无法避免，所幸的是公司内部的协议模板基本是一脉相承，也算是省了一些功夫。初入公司的时候和大多数小厂相同的情况是接口测试（协议测试）这块都是依赖于开发提供 GM 工具来进行协议的调试发送，怎么说呢，在一定程度是降低了接口测试的难度，至少不用去自己去抓包发送，方便了测试人员的使用。

缺陷
由于前面提到定制化的问题，GM 工具在发送由于需要进行协议结构的组包，常规就是数组内容、字典嵌套之类的，而在这个时候就会出现一种困扰，出现需要多重嵌套的时候，由于协议文本没有细分标记类型，统一用了 array 来表示，很难确定到底是 []，还是{}，导致在进行组包时面临试错和沟通成本，降低了便捷性。再就是协议解包，做接口测试和定位一些数据方面的 BUG 时经常需要进行协议的时序和解包方面的工作，GM 工具只能发送，而日志 LOG 显然也不太可能让客户端把所有信息都输出出来，解包这块就会对不熟悉协议结构的测试成员带来困扰。
求变
阶段一：搭建简易客户端。这个方案其实并不算是上述缺陷的解决方案，算是走向深渊的第一步吧，其诞生的目的单纯是定位为快捷创建测试号的小工具，通过打通基础的登录通信逻辑来实现批量创建账号的目的，后续利用抓包工具直接抓取存储一些通信的 hex 信息来实现协议发送的目的，但是缺点是显而易见的就是成本太高，直接放弃打回原籍。

阶段二：基于客户端的定制协议工具。这个方案算是对于 GM 方式的直接方式，应该也是不少公司的成熟方案。基于游戏内客户端现有接口的类 SDK 方案，在客户端的协议基类中接入，实现拦截抓取或者 copy 协议数据，然后明文展示到工具面板上，这个方案的好处就在于借鸡生蛋，不需要测试人员自己再去进行编解码，直接调用客户端的接口就行，还可以随心所欲的定制功能，比如指定抓取、一键转发等等，肥肠的方便。

阶段三：完全解耦的接口代理工具。来到这个阶段可能就纳闷了，既然上面的这么方便为啥还要搞事？emm,肥肠的简单，一方面是公司的架构不支持这样搞，由于风险和额外的技术管理成本，导致只能在内网环境使用，便捷性就大大的受限；另一方面是测试的野望，作为一个追求 KPI 的测试当然不能放过更进一步的机会 dog。工具方面顾名思义就是一个中继的代理，在中继的过程中进行协议方面的测试需求定制化，至于定制的内容就基于不同组的不同需求，相对来说会更加的自由，常规的拦截、抓取、转发、解包、时序参考定制等等。整个工具中最为麻烦的还是协议封解包，之前采用阶段二的原因也是因为这个，要实现全套的逻辑对于还要应付业务的点点点来说成本无疑是巨大的。通过实现对标双端完全一致的编解码模块，采用 SVN 版本管理方式，定期根据开发的协议文本进行自动的协议代码转换来实现与开发的协议通信保持一致的目的。

感想与延伸
第一次在社区发文，在经历过多次曲折的接口测试路上趁机抒发一下自身的感想。怎么说呢，多年来测试工作上的探索撵过鸡也赶过鸭，测试工作方面的突破不得不正视环境的支撑，看过很多尝试各种新潮技术的同仁，当然很多同仁也是成绩斐然，逛社区算来也有 2 年多了，个人也是尝试中的一员，不可否认的是自身能力受限是一方面，另一方面公司层面的架构也挺受限的，所以在有限的环境内找到更适合落地的尝试对于小厂的测试人员来说算是最佳的选项了，毕竟是 KPI 战士的血泪史。至于延伸嘛，emm，接口自动化可以顺势搞起来。