写好游戏测试用例，你才是一名优秀的游戏测试工程师！

草帽路飞UU

文章目录

一.前言
二.用例工具选择
三.用例设计评判规范
四.用例设计格式组成
五.用例设计的注意事项

一、前言

  如何设计一份优秀的游戏测试用例？本文章将向广大读者说明用例设计的重点和注意事项，话不多说，让我们一起看看吧~ （在后续的实战测试中会进行测试用例的展示，敬请期待！）

二、用例工具选择
  测试用例的编写工具有很多选择：Xmind、Excel，禅道、Tapd、数据库、其他自研用例维护网站、市场主流的用例设计工具还是Xmind与Excel

  Xmind-思维导图，通常用于逻辑性较强的事件梳理，或者带有明确时间线的事件整合，随着测试行业的变化，使用者逐渐增多，其修改便捷、备注灵活、可视化信息明确的特点，使其备受青睐

  Excel-微软电子表格，曾经测试用例设计工具的鼻祖，N年前的曾经与N年后的今天，绝大多数的测试行业从业者仍然在使用Excel进行用例设计，Excel对于数据分析更加灵活，维护更加便捷，用例设计更加清晰明确、严谨。

  选择的工具有很多，笔者这里不逐一进行介绍，建议大家使用Xmind或Excel进行用例设计，没有所谓的最好，只有适合自己的工具~，笔者个人是使用Xmind进行用例设计的，但如果要设计一份真正优秀的测试用例，必定是选择Excel....毫无疑问....
三、用例设计评判规范
  在日常的功能测试工作中会经常接触到测试用例设计，那么你是如何进行用例设计的呢？又是如何进行测试用例评审的呢？以下是笔者个人的评判标准，仅供参考哦（仅代表黑盒测试）：


  1、用例设计的系统性：业务需求梳理清晰，系统与系统、玩法之间的关系明确，列举出系统集成与数据牵连
  2、用例设计的全面性：设计内容覆盖全面、考虑周全，能够深入分析需求并解析为独立的测试用例
  3、用例设计的结构性：用例设计从上至下，从简单到复杂，设计结构清晰明确
  4、用例设计的可执行性：用例从上至下，用例具有顺序性，部分用例进行整合，便捷统一执行
  5、用例设计的可阅读性：用例语句通顺，无错别字、错误语句，阅读性高，易理解，清晰明了
  6、用例设计的可维护性：用例设计有维护信息，编写作者，最新修改时间等，用例维护更加便捷高效
  7、符合项目规范的数据：使用的测试数据由用例设计者提供且符合项目规范中所使用的标准测试数据构造
  8、用例设计的游戏观念：用例设计的检查提及到了关于游戏观、价值观，相关可能影响的法律法规、社会人文等


四、用例设计格式组成
  用例设计的格式是在用例设计中非常重要的一个环节，通常而言，一份优秀的测试用例至少包括的标签头为：


  1、用例序号：序号通常为特定格式，即 项目名称+模块名称+用例序号，例如WZRY_ZC_001 ，则代表王者荣耀项目，注册模块，编号为001的测试用例
  2、所属模块：直接填写对应模块即可，代表该编号的用例是所属于某个模块的测试用例
  3、用例标题：说明该用例的执行目的，检查内容
  4、前置条件：执行用例所需的前置条件，即执行前的准备工作
  5、用例步骤：用例的可执行操作步骤
  6、预期结果：预期执行用例步骤后所产生的结果
  7、实际结果：执行用例后的最终结果
  8、备注信息：通常会写明一些测试方法、注意事项、测试数据等


五、用例设计的注意事项
  一份用例中有很多值得注意的事项，往往很多测试人员在用例设计时会出现的常见问题：


  1、问题一：用例设计标题不清晰，执行者不能通过标题判断编写者的目的，不清楚该用例的设计目的，没有头绪，例如描述有误，过长的标题反而增加阅读难度等
  2、问题二：用例的操作步骤不可执行，按照测试用例的执行步骤执行，发现该用例是无法执行的，只列举了测试点，他人无法通过测试点进行执行
  3、问题三：用例没有备注信息，部分需要测试数据、特定方法执行的测试用例无备注信息，执行者在执行该用例时不清楚执行方式与方法陷入困境
  4、问题四：用例子模块划分不明确，用例的标题和子模块划分不明确，格式不清晰，执行者很难执行
  5、问题五：用例不具有顺序性，用例的顺序性差，能够一起执行的用例分开进行了编写，导致执行一次后反反复复进入同一个模块和界面再次执行另外一个测试用例，耗费时间