游戏测试功能性测试用例设计

游戏测试功能性测试用例设计

在游戏测试过程中，你是否会在事先编写好测试用例来指导你的测试工作呢？相信每个游戏测试员心里都有答案。希望无论是测试前会好好准备用例的朋友，还是从来不写用例的朋友，看多这篇文章会对游戏测试用例有新的认识。

众所周知，在软件测试中，测试用例是重中之重，并且一般都设有专门的用例设计人员。但是反观游戏测试，对于测试用例却不是非常重视，究其原因，我认为有以下几点：

1.缺少时间：现在大多数游戏公司的测试部门一般成立的比较晚，很多都是策划和程序已经实现了游戏的大部分基础功能后才开始组织测试，根本不给测试人员编写用例的时间。

2.急于求成：测试用例属于长跑选手，需要长期的维护和坚持才会有丰厚的成果，但是大多数测试人员希望编写用例后立即收到很大的效果，如果执行一次用例没发现很多bug 后，就觉得原来有用例测试起来也就这样。殊不知很多事情没有坚持到最后，是看不到成果的。

3.人员素质：不可否认，游戏测试人员的学历和知识在IT行业属于中下，因为在多数人眼里，只要会玩游戏，就能做游戏测试，其实这话也没错，因为只要你会玩游戏，你也能发现游戏中很明显的bug，但仅此而已。而且游戏测试多半没有学过专业的测试知识，所以对于用例也自然不是很了解，更谈不上重视了。

4.难于维护：这是游戏测试本身造成的，因为游戏测试不同于软件测试，游戏功能的变动一般比较多，功能一变，用例也得更着变，所以一般测试人员都会觉得用例维护太麻烦了，久而久之也就放弃了虽然测试用例编写和维护都是很花时间的，但是测试用例带来的好处还是不可忽视的。

游戏测试除了发现bug以外，还需要确保游戏系统功能的完成度，这些功能是否按照策划的设定完美的完成了，在可玩性上是否达到了要求等等。而测试用例就可以帮助测试人员完整地测试这些内容。

大家可以在脑海里想象一下，测试员A没有使用用例，就是靠自己的意愿和想法不停地在游戏里跑各个功能，如果发现什么bug就记录，然后继续，期间可能一个测试点重复测试了好几次，工作一天后，测试员A感觉自己把系统都跑了一偏了，但是又不是很确定自己每个测试点都测试过了，因为他没有用例来约束和记录他的测试内容，因此他的测试并不系统，覆盖率不高。而测试员B在测试之前准备了测试用例，然后开始测试时按照测试用例一条一条仔细的测试，发现bug并记录，等用例执行完后，测试员B可以信心十足的说：“这个系统所有的测试点我测试过了”。如果说有遗漏的地方，那就说明这个测试用例还不够完善。

了解测试用例的重要性后，我们来谈谈如何设计测试用例，首先我们先回过头思考，我们为什么要设计测试用例？那是因为：

1.为了测试覆盖更加全面

2.为了测试效率更高

3.为了规范测试工作

这就是我认为测试用例3个最大的作用。所以基于这3点，我设计了下面这个测试用例模板。

PS：我使用的Excel制作的模板

模板一共包含8个部分。

1.变更日志：主要记录文档变更情况，大大小小的变更都应该记录，比如加入了一条新的用例……。

2.目录：这是对于整个文档各模块的一个索引，方便用例执行人员阅读

3.测试计划：制定执行测试用例的内容，时间，测试人员以及其他备注信息

4.模块分层：这是整个用例的灵魂，用例设计的好坏看这一部分就可以大概得知，如果模块分层设计得好，那么这个测试用例的覆盖率就高，遗漏的测试点就少。

5.基本功能：根据策划文档设计的对某个系统的基本功能的用例，属于正面的测试，其中没有考虑过多的特殊情况。

6.自定义用例：就算这是个模板，但我还是希望大家能够加入自己的想法，其实测试用例没有模板，只要适合自己的实际情况就是好的用例。这部分是测试人员发挥自己的创意，运用各种专业的用例设计方法，如场景测试，组合测试，测试TFD，净室测试等，针对不同系统设计的具有个性的测试用例。

7.新增用例：再完美的用例也不能达到100%的覆盖率，所以我们把在测试过程中发现的新用例记录在这里，通过这样的积累，我们的用例就会越来越完善。

8.评分表：这是对于用例和测试系统的一个评价参考，主要通过发现的bug数量和等级以及执行测试用例的效率两个方面来评定。只是一个客观的数据参考。