近期稍微停歇了下开发的任务，转为进入游戏项目组去探究真正的游戏测试业务是如何进行。在此前做测试工具与平台时会常常遇到业务需求不能准确击中的瓶颈，因此真实投入体验，调研项目组的测试痛点，能够对后续的技术支持工作大有裨益。
游戏，尤其是网游，是一类非常特殊的软件产品，可能会有以下的特点：
- 服务端与客户端强耦合
- 各个系统模块间存在复杂的联系，业务复杂度相对于一般的产品高
- 单体状态的变化，可能影响到多个实体的状态及属性
- 策划配表数值变动多，迭代频率高
- 游戏的新功能特性研发，需要牵扯到很多原有的设定
- etc…
简而言之，游戏是一个高内聚、体量较大、变化需求多的软件系统，因此游戏业务测试本身就是不小的挑战。
项目组现处于刚上线的阶段，主要业务是外网缺陷修复的验收以及新功能的测试及回归。其中，新功能的回归测试在笔者认为是更为艰巨的任务。我们首先可以看一下一个基本的测试用例是怎样的:
1 | 用例 = 前置条件（在X条件下） + 操作（执行Y） + 预期结果（每个关联实体的状态变化） |
在回归测试里，不说关联实体的数量，单说前置条件，一方面由于新功能关联的旧模块可能较多，这样就导致前置条件的可能性也会很多，排列组合后呈指数级增长；另一方面在实际游戏体验中，达成前置条件所需要的步骤也较繁琐。针对这两个问题，最稳妥的的解决方案是：
- 测试方式：最稳妥的是黑盒测试。黑盒测试能够直接观察客户端与服务端的表现，并且当下也只有人类能够判断哪些表现属于缺陷（某些细节要考虑到策划的设定）。AI跑游戏即使可能实现，但也不能直接与测试业务交互；UI自动化能够保证操作的成功，但难以观测操作所产生的对其它实体的影响是否正确。
- 用例设计：先设计出所有可能的用例单元，再在实际游戏中进行覆盖。一次正常的游戏流程中，尽可能过滤掉那些现实游戏运行中难以发生的状态变化，并且尽可能覆盖不同分支的用例单元，从而真实提升
- GM指令：通常是客户端发给服务端的快速达成某些条件的指令，比如一键99级、改系统时间那种。熟悉GM指令与游戏设计，能够显著提升测试效率。
因此脑海中衍生了以下的技术支撑思路：
- 上游&资源管理：在实际测试中最怕遇到协议对不上、配表对不上之类的外在问题，因此需要一套稳定的上游&资源管理机制，提供稳定的测试环境，并监控资源与代码的变更。
- 用例工具：通常业务测试中用例设计会分模块，采用思维导图软件划分支。但这是有局限性的，如果有一个巨大的图能够表现整个游戏系统，能够对功能用例的设计组合起到更好的指导作用。因此针对游戏的用例设计&管理工具，也是长线调研的方向。
诸多想法都也只是萌芽，希望后面继续深入的话，能发掘更多的东西吧~