基于界面交互展开的用例设计思路_交互图表测试用例，软件测试权限处理

2401_84265592

已于 2024-04-13 23:37:55 修改

阅读量924

点赞数 24

分类专栏：程序员文章标签：测试用例

于 2024-04-13 23:37:53 首次发布

本文链接：https://blog.csdn.net/2401_84265592/article/details/137728735

版权

程序员专栏收录该内容

17 篇文章 0 订阅

订阅专栏

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

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