手游测试工作总结(5)
5.11 用户体验测试
用户的体验算不算BUG，可以这么来回答，几乎所有的BUG都会导致用户体验不好，而我们从用户那里收到BUG，大多数都是因为设计本就如此，但用户难以理解或体验很差而反馈为BUG。总而言之，用户体验的测试很重要。
移动互联网与传统互联网区别较大的一点就是载体的不同，从而导致用户操作习惯的不同。手游测试的复杂性也体现于此，不同的机型，不同的系统，都会带来不同的用户操作习惯。下面就总结下Android和IOS各自相同的操作习惯。
①Android的操作习惯
感谢上帝，现在带有键盘甚至滚轮的安卓机型已经不太常见。
lHOME键
l菜单键（MENU）
l返回键（BACK）
l长按HOME键
l长按菜单键
l电源键（锁屏）
l音量调整
l自定义快捷键（截图等）
l移动应用到SD卡
l清空应用数据（具体步骤通常为“设置”>“应用管理”>选择应用>“清空数据和缓存”）
l强制停止应用运行（步骤同上，最后一步换为“停止运行”）
②IOS的操作习惯
l单击HOME
l双击HOME
l关闭进程
l打开关闭音量
l调整音量
l电源键
l截图等组合键
知道了这些操作点，我们就知道了测试点，比如在安卓中，返回键是否重写了，点击返回键的反馈是什么，在关键的界面使用这些按键或操作会不会有什么影响等。还有一些移动设备都具有的如在屏幕上划动，重力感应系统带来的横竖屏切换，在每个界面，操作，播放movie的时候进行横竖屏切换，或者上下左右的屏幕切换，看是否符合用户习惯（通常是由引擎来实现的）等等。
上面只是操作习惯的用户体验，对于游戏测试重要的还是玩法，游戏乐趣等带来的用户体验。在用户的体验上我主要分以下几个方向：
①界面UI与整体的游戏风格一致
风格一致，这是最基本的要求，先不论美不美观，至少风格要统一。\
②玩家操作方便快捷
一切从玩家的角度，分辨出那些操作是重复冗余，可以改进优化的。举一个简单的例子，玩家需要进行100次以上的点击操作，就我个人而言，这种体验是非常糟糕的，在这100次以上的反复操作，大多数都是重复枯燥的操作，在进行操作的时候没有体验到很多的乐趣。
③用户友好性
玩家有很多小白，甚至有部分玩家白到不能再白，所以功能必须做到简单，容易理解，不能让玩家看了不知道是干嘛的，必要的时候要加上界面说明。
④用户亲和性
所谓亲和性，就是让玩家感到亲切，有种宾至如归的感觉。游戏的整体风格要和游戏的倾向高度契合。比如，做一个东方武侠的游戏，里面的职业开兰博基尼，开口就是“愿上帝保佑你”，这样看起来就不伦不类的。武侠风格的游戏就要具有武侠的精髓，
如何更好的从用户角度去发现体验问题呢，我总结如下：
①切换到用户这个角色
忘掉自己的身份，忘掉测试用例，测试方法，做测试久了，我发现有时候的提的BUG已经到了一种钻牛角尖的程度，很多用户提的BUG，从我的角度来看都只是些对设计的理解问题。所以，彻底的忘掉自己的一切，把自己当成用户和小白，来进行游戏的体验，把自己在游戏的体验过程中遇到的一切阻碍都记下来。
②场景的模拟
切换到用户的身份，同时也要切换到用户的使用场景。比如在网络中断或缓慢的时候，玩家的心理想法是怎么样的，这时候玩家的体验是什么样的，给玩家什么样的反馈才玩家可能比较容易接受，当然，这些可能需要策划比我们想的更深入，我们需要的是从用户角度来审查并提出建议。场景的模拟包括上面提到的用户操作习惯，游戏运行环境。比如IOS的越狱用户，大多数IOS用户越狱只是为了安装一个输入法，然后就是各种手机美化插件，手机管理软件等，因此需注意这些应用对游戏有无影响。
③对比测试
其实前面有提到过，对游戏太熟了，实在找不出游戏的BUG了，就去玩下同类的竞品游戏。对于用户体验更是如此，玩大量的竞品游戏，不管好的不好的，从下载，安装到启动，注册登录，进入游戏玩。仔细观察并能总结出其他游戏哪些地方做得好，哪些地方做的不好，为什么要这么做，为什么不这么做。我感觉这也是一个策划的基本功，也是我希望我们的策划能回答我的一些问题时能做到的，而不仅仅回答我，你看那个游戏就是这么做的，而且他成功了。
④获取相关的知识
阅读一些设计类的书籍，了解一下相关的知识。经常看一下行业的相关新闻，多了解下相关业务知识。这是一个互联网的时代，信息爆炸的年代，我们能获取的知识的渠道和方法简直太多了，多补充一些，对测试的工作，对自己的成长都有好处（但要分轻重缓急）。同时也可以了解些运营相关的知识，了解下市场的动态和发展趋势。
我们QA的工作围绕着产品的质量进行，那么产品的质量是为什么服务呢，那就是用户。用户是这个产品的最终使用者，就算我们开发代码写的再牛逼，美术画的再好，测试做的再完美，但用户的体验很差一切都是白搭，因此UE的测试很重要，一定要重视起来。
5.12 测试执行总结
以上是我自己掌握的一些在测试中的一些测试方法和工具，写这段总结的是秉承着没有操作和理解的东西就没有话语权，也有一些工具的使用写的比较简略，因为完全写完可能这篇总结就到不了头了，工具毕竟只是工具，是为了我们更加方便的工作，有些东西明白了原理和方法之后才能进一步的去解决问题，不需要太过于去追求和学习工具的使用，在使用之前去了解他的原理会事半功倍，在之前的测试中，我们大多数的测试都是在测试环境中进行的，我们应尽早提出申请的进入正式的测试环境中。
6、BUG生命周期的管理
BUG的生命周期是指BUG从创建，修复，验证，到关闭的一个过程。在我们的测试过程中，BUG的生命周期管理尤为重要。BUG的管理工具有很多，像禅道，BUGFREE，JIRA等等，不必纠结谁好谁坏，用的习惯方便就是最好的选择。
BUG的生命周期中我们需注意以下概念:
l标题：BUG的标题要简明扼要
l类型：对BUG进行分类
l状态：标注BUG的状态（开始，进行中，重新打开，已解决，不解决，延期解决，关闭）
l优先级：表示BUG的优先状态和影响程度。
l
紧急：严重影响开发或测试的问题、紧急线上问题等
l
严重：系统崩溃，丢失数据，或内存溢出等严重错误，或必须完成的任务。
l
一般：一般性问题
l
轻微：部分功能无效，或其他问题目前有简单的解决办法。
l影响版本和修复版本
l模块：BUG所在的模块
l环境：BUG所在的环境（如机型配置）
l经办人：需要解决BUG的人
l描述：对BUG的具体描述，包括BUG所造成的现象，具体的重现步骤，重现几率，以及BUG的影响。
l附件：可以附加一些BUG的截图，必要的时候甚至可以加上视频录像，声音等。
l备注：对BUG的一些补充说明。
发现BUG后，我们按上诉字段在BUG管理工具上创建BUG，并告知相关人员（沟通很重要）。一个BUG的生命周期就开始了。
接下来就是推动相关人员对BUG进行解决。在整个BUG生命周期的过程中，交流沟通是很重要的，测试人员要有清晰的表达能力，在对BUG描述时能够让相关人员马上能明白问题到底是什么，从而能帮助相关人员快速的分析定位BUG的问题所在。如此在推动解决BUG的时候也较为容易，否则则会浪费两边的时间。
在相关人员解决BUG之后，我们要对BUG即修改BUG可能影响到的相关功能进行回归。我们可在程序解决BUG后向他们请教BUG是如何发生和解决的，至少能了解相关的逻辑（不要求懂代码），改动了BUG后可能会有哪些影响，从而方便我们对以后出现相同或类似的BUG后能加以分析，更快的定位和解决问题，也方便我们更加了解业务知识，对发现BUG修正后可能影响到的功能更好的加以针对性测试。
在确保了BUG被修复，且未对相关功能有影响，我们可以将这个BUG的状态标为关闭。但是关闭不代表我们以后就不在关注这个BUG了，在项目过程中，测试有两个较为关键的里程碑，第一个是功能的冻结，经过测试后，确认系统的功能不再做任何改变，第二个是代码的冻结，在版本的质量达到要求之后，冻结程序代码，不再对代码作出任何的修改。而测试在这两个里程碑之间，测试还需做对整体系统的一个回归测试，在这个回归测试中，我们还需注意对之前出现过得BUG进行验证。因此要做到对每个BUG进行认真记录，不能只口头说了就做不记录了，有可能大家一忙就忘掉了，发生遗漏BUG的事故，永远不要相信任何人的记忆力，只相信记下来才是硬道理（这也是测试人员在工作时所要拥有的质疑一切的态度表现之一）。
7、验收测试
验收测试是在上线之前对游戏的验收测试，也是对测试工作的验收。在这个阶段，我们需对项目的质量进行评估，评估项目是否达到了上线标准，对遗留的问题进行评审,
