第三篇 测试用例的规范
一、什么是测试用例？
首先对于新人我解释下什么是测试用例：
测试用例是测试过程中操作行为的方法指引，用例让整个测试过程有章可循，高效快捷，不至于有所疏漏；
用例设计的准确性、合理性、覆盖率直接体现测试的效率与质量；
一份合格的测试用例一定要具备逻辑清晰，尽可能覆盖所有功能点，执行快捷的特性等；
测试用例设计是整个测试工作的核心，也是一个优秀测试人员的基本功，注意我这里用的是“设计”而不是简单的“编写”，一份合格的测试用例一定是设计出来的，它需要从各个角度去思考以覆盖到所有可能的测试点，最终尽可能达到系统没有任何缺陷的完美程度。
二、测试用例设计规范
大部分游戏测试团队都使用excel设计测试用例，为了使测试用例的设计尽可能的完善通常还会画思维导图、流程图、关系图等；
1、测试用例规范说明
下面我以“添加好友”在聊天界面的需求设计为例说明，其设计出来的测试用例如下图2-1。
图2-1
系统：通常写游戏功能的系统名称，比如“好友系统”；
一级模块：通常写功能系统的一级模块名称，这个名称通常来源于策划案里的分法，比如“添加好友”；
二级模块：一级模块的二级模块同样来源于策划案，如果没有则可以不写；
优先级：根据功能的重要程度定，通常用0、1、2等表示；
测试目的：最重要的标签，也就是你测试的具体对象或者目标是什么，你要测试验证的“对不对”的哪个点是什么？只有明确锁定这个目的才能集中思考测试点；
前提条件：为了进行测试操作所要准备的环境，或者测试对象所要达到的某个状态，比如“1、当前A、B角色都没有好友且好友系统都解锁；2、AB玩家都在线；”
操作步骤：为了测试目的需要在游戏中进行的具体操作，如果有多个则逐条写出来，比如“1、A玩家在聊天频道点击B玩家头像；2、在弹出的交互界面点击添加好友按钮”；
预期结果：这里的预期结果写的是策划案中要求的设计结果，如果对于一些设计细节，策划并没有给出具体的表现结果，则要和设计人员进行进一步沟通，比如这里可以接着上面列举的操作写“1、A玩家界面弹出提示：“请求发送成功”；2、B玩家好友按钮出现小红点；”；
是否通过：这里其实写的是测试的结果状态，一般有“通过”“不通过”“无法执行”“删除”等，“通过”表示预期结果和实际操作结果一致，反之则是“不通过”，“无法执行”通常表示由于功能阻塞或者其它原因导致该条用例暂时无法操作，“删除”通常表示需求有变动，已经不需要该条用例了。
2、思维导图示例
思维导图的功能在于帮助你详细的拆解需求文档，针对每一个小功能去构思测试点，以避免由于功能太庞大造成遗漏或者测试点设计不到位的情况。很多新人同学画思维导图的时候往往不知道要怎么开始，而且很多简单的功能他们觉得直接编写测试用例就行了，画思维导图没什么用而且还浪费时间，下面我分别说明这两个问题。
一个项目功能需求有大有小，有的很小的需求甚至只是简单的改一行文字，这种简单的需求，测试的时候自然是不用画思维导图的，当然也不用设计测试用例，需要设计测试用例的往往是比较大的系统功能，也就是实现逻辑复杂，所谓逻辑复杂站在测试的角度可以理解为，不能一眼就看到是否正确实现的功能，要验证其正确性往往需要在一定的条件下，进行一系列合理操作才能看到结果，这个时候我们就认为他是复杂的，需要画思维导图辅助设计测试用例。比如一个看似简单的添加好友功能，用思维导图去发散就发现有很多潜在的测试点要去测试，示例图如下2-2。
图2-2
在说说如何画思维导图，画思维导图只要遵循以下两个原则就行了：
拆解最下功能点
最小功能点的测试点构思
拆解最小功能点指的是按照需求文案将每个功能拆解成最小的功能点，其实也就是系统模块的层级划分，一般在策划案中，设计人员已经划分好了，测试人员只是将他们用思维导图的模式呈现出来，但是实际上策划往往会漏掉很多地方，尤其是与其它系统关联的地方，没有考虑充分，这个时候就是体现一个优秀测试价值的时候，测试往往会比一一般策划想的更深入，更细节化。而这个拆解的最小功能点其实就是测试用例中的“测试目的”，但是测试目的不一定是最小功能点，它要别最小功能点包含的更多。
再说测试点，当拆分出某个最小功能点的时候，就要针对该功能点构思测试点，很多的测试方法其实就是在这个环节使用的，比如边界值、等价类等等。在这里我不具体介绍都有哪些方法，我会介绍的一套系统化的思维方法，这个方法会在后面专门介绍，这里重点是让大家搞清楚画思维导图的两个原则，而且特别要注意，在构思测试点的时候一定要紧紧围绕你的测试目的，不要偏离这个点，不然会搞的自己很混乱。
3、流程图示例
流程图也是用来辅助设计测试用例的，他的功能在于搞清楚整个功能的运行过程，偏向于技术实现层面，比如A申请添加B好友，这个过程到底是什么样子的？流程图可以很清晰的展示这个过程。流程图由对象、操作和判定组成，下面依然使用A申请添加B为好友的过程进行示例说明如下图2-3-1。
图2-3-1
当然，这个过程是根据策划的设计文案来画的，不同游戏设计的要求可能不一样，根据这个流程我们就可以很清晰的看出A在申请添加B好友时会有那些具体的条件判断，而这些条件就是我们要设计用例专门去测试的点，这些条件在测试用例中往往表现为“前提条件”的设定。这里的设计要点是当要测试某个条件的判定是否正确时，要把同一判定线上的其它条件设定为满足状态，我再举一个类似的小例子如下图2-3-2。
图2-3-2
假设上图中的电源正常接通，电线也没有问题，台灯没有开关，现在要分别测试A、B、C三个开关的开关功能是否正常，要怎么测试才是最高效的？
第一步：先把所有开关打开，如果台灯正常发光，说明三个开关“开”的功能是正常的，反之至少有一个开关“开”的功能是有问题的，这个时候就要让技术人员检修了，因为作为单纯的测试人员此时没法判定到底是哪个开关的问题。
第二步：基于三个开关“开”的功能都正常的情况下，分别关闭三个开关，每次保证其它开关都是开的。如果每次台灯都能正常关闭，则说明三个开关“关”的功能都是正常的，反之则可以精确定位那个开关“关”的功能是有问题的。
经过上面两步三个开关功能是否正常就测试完了，而游戏中的各种多个条件的测试也是采用这个思想，大家可以多琢磨琢磨，设计用例的时候尽量用最高效的策略遍历所有测试点。
4、关系图
关系图指的是功能系统与其它系统的关联性，当策划设计某个系统的时候，往往在这方面欠缺考虑，导致技术没有做相关处理，测试也没有测到，所以当测试设计测试用例的时候，就要有意识的向这方面考虑，关系图的画法没有太严格的要求，也可以用思维导图去梳理，下面是其中的一种方式的示例，如图2-4。
图2-4
关系图的关键是考虑测试系统与其它那些系统都有关系，有些是策划案中明确提到的，比如好友的聊天功能，有些就要靠测试人员去联想，比如可以通过好友交互界面查看好友信息，这里就要做更多的联想，比如好友的称号通过这个操作路径是否可以在界面上正常展示等。这里能联想到的越多，就越可能避免一些意料之外的问题，而要具备这一能力除了对整个游戏非常熟悉之外，还要积累很多的相关经验才行。
以上就是测试用例的设计规范和设计时的一些辅助手段，不管用什么方式，最主要的还是时刻保持认真的态度，做测试细心是最可贵的品质。还有要千万注意，设计测试用例的目的不是过程中使用了什么花哨的方法，而是要保证用例的高覆盖率，方法只是是为了服务目的，千万不可本末倒置。
四、测试用例的其它表现形式
测试用例有时候不一定非要刻板的采用excel中“操作步骤→预期结果”这样的形式去设计，有时候为了更高效的测试一些逻辑比较复杂的功能，测试用例也可以设计成别的样子，比如下面图4-1是一个多人副本的匹配玩法的用例设计，大家可以体会一下。
图4-1
总之，设计用例的目的是为了更有效的进行测试，用例将思考和执行分成两部分，设计的时候专注于测试点的构思，执行的的时候只需要严格执行即可，而且也可以由其他同学负责执行，用例设计好后，随着项目的开展后续可多次复用，这样极大的减少了思考的成本，可有效保障项目的质量稳定。
<完>
个人浅见，欢迎留言交流。♪(＾∀＾●)ﾉ
