基于界面交互展开的用例设计思路_交互图表测试用例

2401_85599097

于 2024-06-25 03:42:47 发布

阅读量1k

点赞数 10

文章标签：测试用例

本文链接：https://blog.csdn.net/2401_85599097/article/details/139943657

版权

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. 结算玩法

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