测试用例编写说明.docVIP

测试用例编写说明 测试用例编写说明 1 一、 什么是测试用例 1 二、 我们的测试原则 1 三、 理解设计 1 四、 构造测试用例的框架 2 五、 充实用例内容 2 六、 可玩性测试部分 3 七、 易用性测试部分 3 八、 后续维护更新 4 什么是测试用例 为测试游戏中某一个或一组特定功能而制订的测试方法，通常是关于该功能中若干测试点的集合。 我们的测试用例与软件工程行业略有些不同，我们将一组测试点的集合放进一个EXCEL文档中，然后将这个文档称为一个测试用例。 我们的测试原则 测试人员对自己的定位应该是把关人，不仅检查制作质量是否合乎设计和有无错误，同时还要考虑设计质量，包括逻辑合理性、可玩性、数值平衡等方面，以及提示信息、学习门槛、操作便捷性等影响使用感受的其它因素。 因此，测试主要有三个目地：检验功能正确、检验设计合理、检验使用感受。 在测试中，测试在检验、试用功能的同时，还需要有积极主动的心态，去思考功能系统中的各个元素、各个数值实际所起到的作用，以及它的价值，这些和设计定位是否一致、各组成部分之间的设计有无冲突、实际运行是否能达到设计目地。 所有这些考虑，都应将其记录下来，向策划反馈、沟通，尽量能够说服策划，或被策划说服，尽量少留“保留意见”这样的分歧。 只有收集冲突观点，并且将其解决，才能排除设计盲点、照顾更大群体、做出最好的游戏。 理解设计 编写测试用例之前，要明确该功能的设计，在脑中构造出这个设计的基本框架与内容。这样编写出来的用例才能做到测试条理清晰、减少测试漏洞。 为达到这个目地，我们使用功能覆盖法与路径分析法相结合的测试方法。 功能覆盖法就是全面列举系统所表现出来以及自己能想得到的各个细节，并逐一进行测试。这种方法直观简单，但不容易保证测试的全面性。 路径分析法是从设计核心思想出发，按照系统流程与设计框架进行功能划分。这样脉络清晰的方式可以较好地保证测试思路清晰，但需要对设计有较深的理解。 为保证达到目标，我们使用如下步骤与方法来理解功能设计： 确认设计者（策划负责人）、实现者（程序负责人），并在测试用例的表头部分写明。 如果有多个策划合作设计，或分块由不同程序实现，或责任人发生了转移，应在负责人后注明其负责的部分。 明确策划负责人之后，向其索要设计文档，并且尽可能地多利用策划沟通、交流、测试实见等各种方式加强对该功能系统的了解。 将各个方面收集掌握的信息，在脑中、草稿纸或草稿文档中还原出基本设计模型。并与策划沟通核对所还原的设计模型正确、无偏差、无遗漏。 游戏中大部分表现都是由规则驱动的。 一个系统中最根本的思路、最核心的规则通常可以用很少的几句话表述出来。 系统中每一个模块（功能块）都是为一定的目地而存在，都将为丰富、完善、保护系统本身而起到一定的作用。 构造测试用例的框架 按设计的脉络，把系统进行功能块划分，将整个系统拆分为多个功能块。这样就形成了测试用例的基本框架。 一个良好的设计结构中，通常功能块本身就已经有了良好的划分。 划分时要注意不遗漏、不交叉。功能块划分不清晰的部分往往最终就会成为测试盲点。 除了功能块划分之外，测试用例框架中还可以包含公共条件类型、关注点类型、功能与列举类型等其它不同划分。根据具体系统而实际选择，或双重划分方式进行展开来构造用例的框架。 这个阶段完成时，需要上传测试用例，以便及时审核，发现问题时也便于修改调整。 充实用例内容 在框架的基础上继续细化，尽可能将功能块中的所有细节、边界、条件都列举出来，最终形成完善的测试用例。 用例中功能块的细则大体上可以分为条件功能型，与元素列举型两大类： 条件功能型：由规则得出结果，在某个（某些）条件下成功完成功能，而另一些条件下提示不可完成功能。包括游戏中大部分具体操作如购买道具、使用技能等等。 这类功能以边界检查为主。检验在正确条件下系统完成了它所应该做的事情，以及在错误条件下系统没有做它所不应该做的事情。 要考虑到各种可能的条件。例如一个金钱输入框，要确认以下合法与非法的输入：0、负数、小数、超过身上携带有的金钱、超过设计上限、刚好达到身上携带金钱、刚好达到设计上限、公式、字母、汉字、特殊符号，以及不输入直接点确定、输入后点取消等各种边界。 列举元素型：许多系统为了丰富而使用了大量列举元素（如生活技能产出的各种装备、游戏中存在的各种野外常规小怪等）。这些列举元素规则都完全相同，而在输入不同时产生不同的结果。测试时根据具体情况决定是逐个列举全部测试或是抽查结合直接检查策划配置表的方式进行测试。 这类功能需要为每个元素都进行一次相关测试点的验证。确保每一个元素的相关所有信息全部正确无误。 可以复制粘贴，不要嫌麻烦。 列举时要注意各个元素有无和其它元素所不同的特例。有的话要单独写测试点，并且高亮显示出来。 由统一的公式规则演化出来多个元