其他的如流程导向，即区别在于更多以操作为指引，如“好友”系统，这个系统的问题一般暴漏在客户端做各种操作所引发，其功能其实很简单也就是添加成功可交互即可。所以选择这种思路比较适合。人人交互，这里的人人是一个概念，主要关注点是复杂交互类的模块，如“组队”“副本”系统。可以考虑A和B，C......等多种单位之间独自行为，整体行为等对组队功能的影响，所以这个是较其他比较复杂的。（一定要衍生到一个独立A的概念，即独立游戏场景行为至单PC帐号角色行为）

　　其他的一些测试思路这里不多讲了，毕竟这是个尴尬的话题。早初寻一本游戏测试的书籍着实不容易，即便现在有了基本也是概念居多，应用于实际效率不尽人意。曾阅过一本外文相关书籍，奈何英文水平有限，打着有道硬是在本上记录完全，最终取之可用之处十之有三罢，加之几年的工作心得而总结出一些。所以实际中的应用体会才是基础。故希望大伙能自己总结。

　　游戏测试用例

　　用例的编写是每个测试人员必备的基本功。所以实际当中我见过的用例模板也是五花八门各有千秋。其中最主要的矛盾集中在两种方式上。

　　1、以独立模块为索引

　　2、以操作流程为索引。

　　其各种利弊在MM图上标明，不多言。其实我认为测试用例设计的初衷是为了帮助查找更广更深入的问题。一味的追求格式的统一有方便部门整体工作的优势，但强调过头即也不值当。只要我们遵循几点：

　　1、实操人员看的懂，看的省事。提出补充可方便更新且不打乱主题结构。

　　2、编写人员要互相更换不同类型模块，并互相审核。

　　3、格式应根据测试模块可作细微调整。

　　4、有独立突出地方存放特殊用例即只有在具体测试过程中才能发现和能发现价值bug的用例。

　　5、用例的从诞生到最后确认过程，应跟随项目的变化，策划案的变化，周遭其他因素的变化而变化，从理念上排除尽早确定已做好测试准备的想法。实际情况中，用例和策划案确定一样，是相对而非绝对。所以至少应经过5轮真正意义上的修改包括审核。

　　游戏白盒测试

　　相关游戏的白盒测试。最多体现在项目研发初期游戏架构和逻辑模块开发阶段。对于此类测试工作没必要退避三舍，不必有非有程序能力才可做的想法。当然在实操过程中积极的学习是很关键的，这个比在大学里学到的更实用和快速。一些白盒测试工具我认为实际应用价值不是很大。所以从架构而言我们可以关注游戏各组件的协同工作关系，从中查找瓶颈，如修改数据库数据，单独加压崩溃聊天服务器而查看区域服务器情况，断开通信服务器查看协议包的处理情况等等。从逻辑模块初期测试而言，我们可以在非完整客户端的环境下改变模块某些变量参数来校验功能模块的整体功能，同时考虑各接口应用，调用的关系。避免模块最终的互相功能影响。

　　我们掌握了基本游戏测试技能后，我们何去何从？

　　1、职业经理人

　　2、职业工程师

　　这只是个方向。是否能做好，取决于你的业务面是否宽广，所以无论你已经是部门主管，经理，总监或是资深测试工程师。发挥部门价值才能突显自我价值是不变的道理。而通俗的多做事是最好的办法。有几个业务是可以考虑的。