基于用户操作展开的设计思路分享 - 火星时代教育

发布时间:2024-05-16 19:27:03 浏览量:151次

基于用户操作展开的设计思路分享

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

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

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

UI界面向游戏介绍

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

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

用例设计思路

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

在设计用例时,需要按以下4个维度来联想测试点:UI元素的静态显示、UI元素的动态变化、可执行操作的业务流、数据存储。

1. 系统创建

指服务器起服或者某个特定时间点,对该功能所做的一些处理逻辑。比如某个玩法功能开启的时间点,系统创建玩法的一个流程,在需求文档中可能只是一句话,但实际测试点需要注意的事项还是很多的。

2. 入口

每个功能都能找到一个或多个入口,且交互文档里也会有明确的入口显示的界面设计。入口一般有常驻入口、随条件解锁的入口、限时开放的入口、有状态的入口、侵入式的入口等,需要按照不同情况设计用例。

  • 常驻入口,指常驻在游戏主界面或其他功能模块界面上的入口,无需考虑触发显示相关的逻辑。
  • 随条件解锁的入口,需要考虑解锁条件方可显示。
  • 限时开放的入口,在指定时间范围内开放,需注意时间触发功能创建的测试点。
  • 有状态的入口,需要考虑入口两种状态的显示控制逻辑和状态切换变化。
  • 侵入式的入口,需要考虑触发出现的条件和与当前所做事情的冲突。

关于入口,我们可以按照不同类型的入口分别设计用例。

3. 界面交互驱动

对于界面展开详细测试,需要按照信息分区划分,确保每一个元素控件都有所属分区。可以按界面元素排布位置或功能块进行划分,设计对应的测试点。

再对每个划分出的元素按UI元素的静态显示、UI元素的动态变化、可执行操作的业务流、数据存储这四个维度来设计测试点。

数据存储

游戏内数据的存储一般有客户端本地文件存储、服务器数据库存储、服务器本地文件存储、第三方存储。设计用例时需要考虑哪些数据需要测试存储,然后根据实现方式设计相关用例点。

  • 玩家个人属性、成长向、玩法向数据
  • 公会属性向、成长向、玩法进度向数据
  • 系统数据

对于每种数据类型,需要设计相应的存储测试点。

填表驱动

除了界面驱动、流程驱动,还有一类功能可能是填表向驱动,如剧情类、技能类,需要按照表格填法来设计测试点。

用例完善

结合整体用例设计思路,再查漏补缺、多退少补地梳理一遍,确保用例覆盖所有功能点,并考虑与其他模块交叉部分、老账号数据兼容、开新服时空数据状态等相关情况。

小结

以上就是对重交互游戏的一种用例设计思路分享,通过从玩家角度出发设计用例,确保覆盖度和质量,提升交互体验。无论何种形式的游戏功能用例设计,思路都是相通的,永远可以代入一个玩家来看这个功能,希望这篇文章可以帮助有需要的同学整理思路。

作者: 测试中心小编

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

出处: 点击查看

热门课程推荐

热门资讯

请绑定手机号

x

同学您好!

您已成功报名0元试学活动,老师会在第一时间与您取得联系,请保持电话畅通!
确定