从本质上说，传统的软件测试和游戏测试在设计测试用例上并没有区别。
游戏测试只是在传统的用例设计方法基础上，根本其自身特有的属性（也就是业务属性），追加了局部功能用例设计粒度而已。而为了让局部功能达到更高的用例设计粒度，很自然的就使用了一些特殊的设计方法。
打个比方，把传统软件测试比作“面食制作”，那么游戏测试就像是做“包子”，而web测试就可以比作做“面条”了。虽然包子和面条有些许不同。但是它们同是在“将面粉发酵后加工并加入辅料”这个原理中完成的。加工方法和选择的辅料则就是依据它们自身的特性而决定的（也就是测试业务决定细节）。
测试过程如此，测试用例设计原理也是如此。
我对游戏不是很熟悉，简单说一下知道的3个在游戏测试中被加强的测试项目：
1. 数字测试
游戏测试中，经常会涉及很多数学算法的测试，如，伤害计算，人物属性/经验成长计算…..这类数字计算的测试内容，在设计用例时，除了单纯的检查各个算法公式的计算结果是否正确外，还需结合用户体验方面考虑算法本身是否合理。比如，人物升级过慢可能导致用户在使用过程中失去耐心，而升级过快则可能降低用户的使用时间….如何让目标算法达到一个合理的曲线，是游戏测试用例设计中的一门独特的学问，需要长时间的业务累计才能做出正确的判断。
2. 组合测试
游戏测试中，单个功能的测试大都和传统测试差不多。但是游戏测试比其他测试更开放，它的各个功能相互连接很紧密。在传统测试中，1个功能可能与10个其他功能存在交互；而在游戏测试中，1个功能则经常会与几十个，上百个其他功能交互。所以游戏测试更强调了功能的组合测试。
处理组合这类问题时，可以先分为“逻辑组合”和“条件组合”两个方面着手。逻辑组合可以画出流程图，根据路径覆盖得到可用用例（也可分类测试元素后，直接使用因果法）；条件组合可以整理出测试元素后，用正交/结对等方法得到用例。当“逻辑组合”和“条件组合”两者需要同时测试时，可先分别设计用例，再将两个用例组的各个用例再一次使用正交/结对 组合合在一起，得到最终用例。
3. UI测试
游戏测试中，有多次重复使用某个UI的特点。如树木图标，它可能是有5个不同的图标，这5个不同的树木图标将出现在游戏中50个UI位置上，每个图标都被多次复用了。
所以，在游戏测试中，UI测试可以分为两个方面：个体测试和整体测试。
个体测试主要主要负责各个单个UI元素的检查；而整体测试则是对整个UI的检查，也就如通常的“跑地图”一般。
在用例管理时，UI个体测试用例，可以单独分类出来；
而UI整体测试用例，一部分可以放到功能测试中，当对切换新UI，需要测试新功能时，则先使用一组UI整体检查用例，再使用功能测试用例；另一部分，则需要独立管理，如纯粹的“跑地图”UI。
当然，也可以把整体UI用例与功能用例结合起来，比如测试背包系统时，将背包使用的UI场景作为1个新的前置条件，那么背包的不同功能测试，将在不同的UI场景完成。这样既可以覆盖不同UI，也可以测试不同功能。但是，不建议这么设计用例，主要原因还是游戏测试本身就具有复杂的功能组合逻辑，即使只增加1个新的前置条件，都将大大增大用例设计的难度。用例设计难度越大，也就意味着设计出的用例出现泄露的风险越大。
所以，“跑地图”这类整体UI测试用例设计，还是以选择UI场景为主，在各个不同的UI场景中，检查不同的主要功能即可。
原帖地址：http://bbs.51testing.com/thread-440341-1-1.html
版权声明：本文由会员Jackc首发于51Testing软件测试论坛“我要做专家-你问我来答”活动第11期。
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
