测试用例是测试人员日常最重要的输出之一，对用例的评价标准一般有三个维度：结构清晰易读、可执行性强、覆盖度高。站在质量维度，最为重要的要属高覆盖度。如何写出高覆盖度的设计用例，离不开以下几个角度的分析。

• 用户角度—— 基于文档全面铺开所有用户场景
• 实现角度—— 基于程序的实现机制针对性的补充或删除
• 测试角度—— 基于常见的用例设计方法进行细节设计
• 通用角度—— 数据存盘、异常中断、耦合功能交叉
• 错题本—— 基于日常积累的易错点和踩坑点进行查漏补缺

本文希望能给大家介绍一种从用户交互角度来展开的设计思路。

01 UI界面向游戏介绍

在开始之前先大概介绍下什么是UI界面向游戏，该类游戏是由大量的全屏UI界面组成，所有功能流程一般都是通过界面上的交互操作来驱动，所有数据也都展示在界面上。如下图游戏主界面，UI层就是一个一个的功能按钮和一些玩家数据展示来组成，玩家的操作就从这里开始。

既然玩家面对的是大量的UI交互，那么我们的用例不妨也就从玩家视角入手，跟着玩家一步一步的交互开始设计展开。所有界面的交互操作都会有策划的交互文档来参考，但由于界面是静态的界面，如何确保用例不会陷入到只覆盖了界面的静态显示，如何确保从界面入手却能由功能驱动下去，下面按步骤来说明我们的设计思路。

02 用例设计思路

如果把我们待测的功能比作一个房子，玩家就是一个人，那么接下来我们关注的就是人如何走进这个房子并在里边的各个房间开始各种探索，以及他再怎么离开房子的过程。这里边可以认为涉及到2个对象，一个是人，一个是房子，二者交互后可彼此给对方产生影响，这个影响其实就是数据的变化。所以我们的思路顺序可以按下图这样：

1.

系统创建

指服务器起服或者某个特定时间点（比如功能开启的时间点），对该功能所做的一些处理逻辑。

比如某个玩法功能开启的时间点，系统创建玩法的一个流程，在需求文档中可能只是一句话，甚至有时候在需求文档中都不会明显说明，但是实际测试点需要注意的事项还是很多的。

2.

入口

每个功能都能找到一个或多个入口，且交互文档里也会有明确的入口显示的界面设计。入口一般有以下几类：

• 常驻入口，指常驻在游戏主界面或者其他功能模块界面上的入口，没有任何条件限制，所以这种入口无需考虑触发显示相关的逻辑。
• 随条件解锁的入口，这种是指摆放位置与常驻入口一样也是固定的，但是入口有解锁条件，达成条件方可显示。这种入口可以联想到一个功能点，即围绕解锁条件的。
• 限时开放的入口，这种一般是指限时活动的入口，也是摆放位置固定，但只在指定时间范围内开放。这种入口需要注意上一节中所说的时间触发功能创建的测试点。
• 有状态的入口，这种一般是对于一些日常玩法的入口，入口常驻开启，但会随玩法有多种状态，比如未完成状态和已完成状态。这个就是需要常规考虑到入口两种状态的显示控制逻辑和状态切换变化涉及到的逻辑，比如从未完成变到已完成或从已完成变到未完成，从而想到玩法完成、玩法重置这两个逻辑点。
• 侵入式的入口，指的是不管玩家现在打开这哪个界面，都有可能忽然出现在他当前界面中的入口。这种入口至少要考虑两个测试点，触发出现的条件和与当前所做事情的冲突。这其中触发条件比较好理解，可以联想到触发逻辑的测试点。但是冲突一般属于隐含需求，我们需要对整体游戏模型做分类分析，来总结出当前玩家有几种状态下会出现该种入口的情况，再按等价类挑选出测试点。

站在用例设计的角度，不管哪种入口，只要看到入口就可以联想入口背后的逻辑：入口如何显示出来的逻辑和点击入口进入功能的逻辑。所以关于入口，我们可以按照3个用例块来设计。

3.

界面交互驱动

按照思路顺序，入口设计完之后，就进到了从入口点击进入遇到的第一层界面，一般也是功能系统的主界面或者流程型玩法的第一环节的界面。

对于界面展开详细测试，我们避免遗漏的最好方法是把界面按照信息分区划分，确保界面上每一个元素控件都有所属分区。这里划分的粒度可以按界面元素排布位置或者按功能块，可以先粗略分为大块，然后对每一个大块继续划分小块，直至最后划分到最小粒度。

比如上图界面，第一次划分可以按图中所示的3大块来分，可以按内部信息继续划分，其中1就是一个tab按钮，已是最小粒度；2作为一个整体数据单位，可以按内部信息继续划分；3作为一个整体列表单位，也以其中一条数据为单位再继续划分。如下图：

然后对每个划分出的元素再按照以下4个维度来联想测试点：UI元素的静态显示、UI元素的动态变化、可执行操作的业务流、数据存储。

1. UI元素的静态显示

每个UI元素要想测到完备的静态显示，那么需要找到它所有可能出现的数据状态 ，然后再采取一些测试用例设计方法，比如等价类划分法或者边界值法等来选取数据进行测试，甚至有些情况下还需要遍历所有数据来测试。

如上图所示交互文档里可以看出等部分设计说明为例，这里挑2个UI元素来说明下静态显示。

2. UI元素的动态变化

动态变化是该元素几种静态显示数据间的变化切换，可能是一个操作业务流触发的，也可能是系统业务流触发的，然后就可以联系到业务流的相关用例点，还以上面小节的界面为例来说明下。

3. 可执行操作的业务流

对于手游上的UI操作，大致分为以下五种：点击、长按、滑动、拖动、双指拨动。对于逻辑的话，我们不用关注操作的类型，只需要关注操作关联的业务流就好，一个操作向的业务流一般可以提取出下面这个较为通用的流程。

其中操作元素的显示状态，可参考上述UI元素的静态显示，用等价类或者边界值等设计方法来选取适当的数据。

执行操作的动态判断和操作完毕后的处理表现可以算作一个业务流，一般遵循如下套路。

4. 数据存储

对于上面小节里是根据用户交互角度找出了一些业务流并检查了这条业务流最后带来的界面数据变化，但这里我们测到的只是数据的即时处理表现，对于数据它还有一个终极归属——存盘。即时的客户端刷新变化虽然说明这条业务流对数据进行了正确处理，但此时数据只在服务器的内存里，并不能说明存盘的正确，所以存盘得需要专门的测试点补充测试。

游戏内数据的存储一般有四种载体：客户端本地文件存储、服务器数据库存储、服务器本地文件存储、第三方存储。

我们设计用例时需要能辨别出哪些数据时需要测存储的，然后再根据存储的这几种实现来分别套用各自的用例点。存储的数据有几个行为主体：玩家个人、玩家组织、系统。

• 玩家个人属性向的数据，比如自己的昵称；
• 玩家个人成长向的数据，比如玩家的等级；
• 玩家个人玩法向的数据，比如玩xx玩法的进度、成绩；
• 公会属性向、成长向、玩法进度向数据；
• 系统，以服务器为单位的。

上面这些数据有的会直接显示在界面中，有的是通过其他表现来体现，有的只是参与计算。对于隐性的数据需要通过对文档的理解来找到，也可以通过了解程序实现来获取。

4.

玩法流程驱动

对于玩法，虽然客户端表现上来看也是一个一个的交互界面串联起来的，但是这里还涉及到一个逻辑流程，一般可以先按照玩家交互角度分成3大块：进入玩法、玩法流程驱动、结算玩法。然后再以此3个节点来扩充联想相关的用例。

1. 进入玩法

进入玩法的测试点设计与上述类似，也可以按下面两个维度来联想设计。

（1）进入点门槛条件判断，比如玩法是否开启、是否有门票、是否有资格、是否有匹配的对手、是否达到每日参加次数上限、服务器压力过大等；

（2）正常进入玩法后的处理，这里要分服务器端处理和客户端的处理两个维度来考虑。

• 服务器端处理，一般包括：扣消耗、初始化个人的玩法数据（一些玩法全局需要用到的数据）、准备玩法第一环节表现需要用到的数据并同步给相关客户端、设置好玩法状态、记录相关log。
• 客户端处理，接受服务器同步过来的数据、界面跳转进玩法界面并展示相关初始化数据。

2. 玩法流程驱动

进入玩法后，接下来就开始驱动玩法流程继续。一般分两种，一种是服务器控制节奏来驱动，一种是客户端操作控制节奏。回到本文主体，界面操作向的游戏都是需要玩家通过交互操作来驱动进入下一环节。所以我们需要对这一个玩法来画一下流程图，并做一下流程环节划分，把每一环节作为一块测试点来拆分设计，而每一个环节也都可以找到它自己的一个流程：入口、进入该环节交互、进入下一环节或退出。

此外需要注意的是，除了正常的玩家主动退出，还需要考虑到实际的用户场景，即玩家可能会被动退出或者被其他功能打扰，这些需要具体实现具体分析。

3. 结算玩法

这里是指玩家自己的玩法流程结束，那一般是有以下几种处理：给玩家结算成绩（这里的成绩可以认为是个广义的说法，即包括计算分数、更新排名、结算擂主之类等）、给玩家发奖励、促使玩家离开玩法、记录玩家的参与数据、同步其他模块需要的数据、同步给客户端结果、客户端做相应表现等。

5.

填表驱动

除了上面的界面驱动、流程驱动，还有一类功能可能是填表向驱动，比如剧情类、技能类，这些功能外围调用比较基本，大量逻辑是从填表开始，一般表格的列会非常多，那么用例也可以遵循设计的原理，按照配表顺序来设计，最终测试也要按照表格的填法来执行测试，对于每一条填表数据思考联想出相应的用例点即可。

03 用例完善

结合文档阅读输出的用例脑图结构加上上述整个用例设计思路带来的联想测试点，已经基本上可以覆盖所有功能点，最终我们可以再查漏补缺、多退少补地梳理一遍，完整的用例除了功能点，还需要能包括以下几个维度的思考：

• 与其他模块交叉部分完善
• 老账号数据兼容
• 开新服时空数据状态相关考虑
• 合服时可能带来的数据冲突、时间不同步等相关考虑
• 弱网测试（网络延迟下连续多次给服务器发同一请求、丢包情况下数据表现、回包乱序情况下客户端表现）
• 断线重连、顶号、切换账号
• 兼容测试（平台相关性的功能、第三方实现的功能）
• 性能测试（客户端性能、服务端压力）
• 用户体验相关（考虑玩家的理解成本）
• 日志完善
• 配表检查
• RPC相关测试（完善测试服务器端接口实现的严谨性）
• 
  

04 小结

以上便是笔者对此类重交互的游戏的一种用例设计思路介绍。站在玩家交互角度，一步一步铺开用例，能确保玩家所能看到的、操作到的数据都能有始有终的被考虑到，由数据和流程串联，最终可以涉及到所有业务流，保障业务逻辑的覆盖度。

其实不论何种形式的游戏功能用例设计，思路都是相通的，不知道从何开始下手时，永远都可以代入一个玩家来看这个功能，希望这篇文章可以帮助有需要的同学整理思路。

作者:测试中心小编

来源:微信公众号:网易雷火测试中心

出处
:https://mp.weixin.qq.com/s/ApwwPzm9zWLvKDj3eA3UgA