本文介绍了一款游戏测试工具的设计思路，包括定义相关概念、典型用户分析、界面原型设计等内容，旨在帮助开发者、测试人员和学生等高效地进行游戏测试。
定义相关概念
| 名称 | 概念 |
|---|---|
| 报告 | 指对游戏进行测试获取到的内容反馈整理成文本形式的文件 |
| 半任意/半可编辑 | 通过内置测试方案，用户可以组合已有的各种方案达到测试效果，但防止bug，不让用户自主编程 |
定义典型用户
| 用户 | 开发者A |
|---|---|
| 身份 | 不知名安卓游戏的开发者 |
| 年龄 | 25岁 |
| 重要性 | 非常重要，所占比例较大，对本产品需求较高 |
| 使用场景 | 测试产品，修改提高产品质量 |
| 使用环境 | 工作室、办公室、家中 |
| 工作/生活 | 工作就是开发，生活就是工作，压力较大 |
| 知识层次/能力 | 熟悉计算机相关知识，有一定的实践经验，但总的开发经验不足 |
| 动机/目的 | 提升产品质量 |
| 用户偏好 | 希望能精准的测到问题，精准的报告问题 |
| 用户 | 开发者B |
|---|---|
| 身份 | 知名公司的安卓游戏测试者 |
| 年龄 | 30岁 |
| 重要性比较 | 比较重要，所占比例不高，对本产品要求较高 |
| 使用场景 | 测试产品，提高工作效率 |
| 使用环境 | 工作室、办公室 |
| 工作/生活 | 又要加班，又要赶版本进度，可别出岔子 |
| 知识层次/能力 | 熟悉计算机相关知识，有充足的实践经验 |
| 动机/目的 | 提高工作效率，发布前不要再有bug了 |
| 用户偏好 | 对测到问题，测到各个角落的问题有极高的要求，报告也要精准 |
| 用户 | 学生C |
|---|---|
| 身份 | 大学计算机系/软件学院学生 |
| 年龄 | 20岁 |
| 重要性 | 比较重要，所占比例较大，对本产品需求较高 |
| 使用场景 | |
| 使用环境 | 图书馆、教室、宿舍、家中 |
| 工作/生活 | 在实践中学习，为将来打下铺垫 |
| 知识层次/能力 | 掌握基本的计算机相关知识，实践经验不足 |
| 动机/目的 | 学习、完成作业、参赛获奖等 |
| 用户偏好 | 主要用于检查、完善自己的作业/作品 |
| 用户 | 玩家D |
|---|---|
| 身份 | 各种各样 |
| 年龄 | 各种各样 |
| 重要性 | 本来极度重要*，所占比例最大，对本产品需求不高 |
| 使用场景 | 玩游戏遇到了影响体验的异常，复现异常报告官方 |
| 使用环境 | 各种各样 |
| 工作/生活 | 各种各样 |
| 知识层次/能力 | 多数没有计算机相关知识 |
| 动机/目的 | 提高自己的游戏体验 |
| 用户偏好 | 复现问题，生成可读报告即可 |
*在第一天的工作中使用monkeyrunner后发现需要真机连接电脑或者电脑开模拟器才可以使用，这一点与手游的本质相违背。在这种情况下导致玩家群体很可能不会使用本产品，这一方面的问题需要再之后的工作中探索并克服。
界面原型设计
| 名称 | 内容 | 原型 |
|---|---|---|
| 主页 | 菜单栏可以打开各种功能 logo装饰 3个按键分别打开引导页面、测试页面、文件夹 |  |
| 引导页 | 左右箭头为上一页/下一页 图片是对应步骤的样子 文本为当前需要进行的操作 帮助是我们总结出来的可能的问题以及解决办法 |  |
| 测试/报告页 | 顶部按钮分别对应 - 开始测试 - 编辑测试序列 - 编辑文本 - 暂停测试 - 终止测试 - 保存报告 - 删除报告 - 清空当前屏幕 左侧为当前的实时报告 右侧为测试序列 |  |
使用场景
| 用户场景 |
|---|
| 开发A想开发一个手机游戏，开发已经进入尾声，现在需要对游戏进行一些测试，先来一波黑盒测试吧，假设现在的产品那到用户手里会怎么样，乱点一通会不会有问题，如果随意乱划、长按又会怎样？这时，A打开了本程序，他先直接来了一波内置的自动测试，一直运行。突然程序识别到他的游戏卡住了，自动停止了运行，并且在实时报告上显示卡死。这时，A就开始对报告进行审查，最终找到了问题根源并且解决了。 |
| 学生C大三了，这次有个游戏设计的小比赛，他准备一展身手。好不容易写完了，自己试试，发现有问题，找啊找，终于找到原来是如此如此这般这般操作引起了bug，累死了，还要debug。搞定了一个之后，想要继续，但是这也太麻烦了，于是打开本程序，设定好一系列操作，让它自动跑起来，结果轻轻松松就找到了问题。 |
| 玩家D跟平常一样打开常玩的游戏，玩着玩着莫名其妙闪退了，问题不大，重开继续，结果关键时刻又闪退了，怎么回事。他很想反应这个问题，但是又说不出个所以然来，于是他打开本程序，凭记忆把之前的操作大致设定一遍，果然找到了问题，于是他向官方发邮件反馈问题，官方收到了详细的报告很快修复了问题，他又能正常玩游戏了。 |
功能描述及验收标准
| 功能 | 检查项 | 验收标准 |
|---|---|---|
| UI | 按钮 | 点击之后有视觉反馈，并且会执行相应功能 |
| UI | 菜单 | 点击之后有视觉反馈，并出现下拉框 |
| UI | 文本 | 双击之后可进入编辑并出现光标，会自动暂停测试 |
| UI | 整体 | 排版美观，主要功能显眼突出，次要功能也能轻易发现 |
| 测试逻辑 | 内置自动测试 | 能够一直随机运行，直到被暂停、终止、关闭或发现问题 |
| 测试逻辑 | 可编辑测试 | 能够对用户行为进行半任意组合，从而达到测试目的 |
| 报告生成 | 报告简明性、准确性 | 报告应该在发现问题时停止，每一步的内容最终对应操作并被翻译为如"点击按钮A"而不是"点击(xxx,xxx)"坐标 |
| 报告生成 | 排版 | 符合Windows记事本一般规则的换行，不能是一团 |
| 图像识别 | 识别精度 | 能对随机拿出的特定类型界面的游戏进行准确识别 |
| 引导界面 | 引导跳转 | 不是主要功能，最低标准能让没用过的人按着引导使用程序，较高标准可以是能够识别连接设备的状态，自动跳转相应步骤 |
潜在副作用
- 如典型用户D，如果不解决必须连接电脑才能使用的问题，将会流失很大一部分可能的用户
- 可能会有用户担心识别屏幕会对其隐私造成侵害而不使用
- 报告仅仅是体现现象上的问题，最终问题的解决终究要通过代码，对与开发者用户来说，这方面的帮助不大
扫一扫
880
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
