您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  要资料 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
 订阅
  捐助
移动可用性测试(四):远程测试
 
作者:死猫 来源:腾讯ISUX   发布于 2015-02-28
1136 次浏览     评价:      
 

实际工作中,虽然远程测试用得更少,但它确实能解决一些现场测试无法解决的问题。比如在当地无法找到目标用户时,远程测试相对出差是更为廉价可行的做法。或者当需要大量的样本时(现场测试因为时间空间的限制,只能做小样本测试),无主持的远程测试可以完成大样本的测试。此外远程测试相比现场测试,情境还原度更高,更能还原用户真实场景。

1 远程测试的类型和选择

通常来说,远程可用性测试按是否有主持人分为两种类型。一种是有主持的远程测试(Moderated Remote Testing),研究人员需要和被试者通过远程设备连接起来,使得不在同一地点的两方能同时处于同一个“真实”的空间中,研究人员可以通过远程观察设备完整地观察到用户的操作行为,同时能在测试过程中与被试者进行实时的在线交流。另一种是无主持的远程测试(Unmoderated Remote Testing),被试者根据研究人员的要求,按照自己的时间计划完成测试,并对自己的操作全程进行记录。测试过程中,研究人员并不进行干预与互动,所有的分析工作都在测试完成之后进行。

两种类型的远程测试各有千秋,研究人员需要根据项目具体情况进行谨慎地选择。可以从以下几个方面考虑。

项目时间安排和样本量要求

有主持的远程测试,由于需要主持人的参与,一定程度上限制了同时进行测试的数量,测试阶段需要花费的时间较长。而无主持的远程测试能够同时进行多个测试,能在有限的时间内用较低的花费收集大量的数据。所以当需要大样本量的时候,应该采用无主持远程测试。但因测试过程中完全不参与,后期数据分析工作量较大,需要花费较长时间。

任务设置要求

对于有主持的远程测试而言,所有的交流都是实时的。在测试过程中研究的人员有不清楚的地方,可以向被试者进一步的追问,了解被试者行为背后的原因,所以这类测试对那些任务更为复杂的测试更有效。而在无主持的远程测试中,被试者全程独立完成测试,这就要求测试的任务描述需要清楚直接,有明确的结束状态。被试者独立完成任务时,注意力的集中程度有限,通常无法保证长时间高质量地完成任务,有专家建议无主持的远程测试应控制在15-30分钟左右,包含3-5个任务为宜。

被测对象的稳定性要求

无主持的远程测试没有研究人员的干预,被试者过程中过程中遇到任何问题都没办法得到及时的解决。因此,这要求被测的原型或产品的稳定性非常高。一旦产品出现问题,很可能被试者就无法把测试进行下去。并且原型或产品需要对被测者的操作行为作出反应,让被试者明确判断出自己是否完成了任务,是否可以进入下一个阶段。

2 远程移动可用性测试的难点和弊端

做移动可用性测试时,远程方式虽然可以覆盖更多样本类型和样本量,还原用户情境。但也存在存在以下难点和弊端。

互动减少,信息不足

远程测试由于研究人员和被试者在不同的空间,两者无法直接互动。有主持的远程测试中,研究人员无法直接观察到被试者的身体语言和场外信息,提高了沟通成本。无主持的远程测试中,被试者的行为完全是独立的,研究人员基于测试后分析,对于行为背后的原因难以获得。

测试环境不可控

远程测试过程中,我们无法控制被试者的测试环境,被试者很可能被电话、突然的到访者等打扰。这既是远程测试的优势,可以还原被试者的现实情境,但也是劣势,被试者很可能就此中断任务甚至放弃任务。

被试者网络环境影响(有主持)

远程测试需要通过屏幕的共享以及图像的录制来进行数据的收集,虽然现在的网络越来越发达,但是难免受用户当地网络环境的影响。

任务理解偏差(无主持)

无主持的远程测试中,被试者对任务理解有偏差,可能就会导致大量数据失效。建议任务设置明确,同时标明研究人员联系方式,以便能够被联系到。

被试者态度难以甄别(无主持)

无主持的远程测试中,更大的风险在于一些无效数据。如用户敷衍完成任务,我们很难甄别。因此,在招募用户时,需要确定对方是否配合、对产品感兴趣。计划测试时就需要考虑如何定义数据的有效性,以及如何对数据进行有效筛选。

测试工具限制

远程可用性测试,对测试工具的要求更高,工具限制会成为很重要的限制因素,下面工具部分会详细展开。

3 远程移动测试的原型制作和发布

项目早期移动测试原型制作,依然可以采用第一篇介绍的工具Prott。原型制作的部分需要强调的是,因为远程测试更不可控,所以对原型的保真度要求更高,特别是对功能及跳转的完整性上。

原型制作完成之后,远程发布给用户也非常简单,不需要用户安装任何App。用户研究员在Prott项目界面点击分享按钮,在弹出界面中选择Send email。用户收到邮件之后,在浏览器中打开链接,按照提示把快捷方式添加到首页,之后就可以类似原生App的方式进行测试了。

对于项目后期的测试来说,一般做法是内嵌SDK到代码到程序中,所以不存在制作原型的问题。

4 移动远程测试(有主持人)的平台选择

做现场测试的时候,我们面临的平台选择是,iOS还是Android。最终会依据“产品用户平台分布”,“测试工具限制”来决定平台选择。然而在远程测试中,因为工具限制太大,所以我们必须优先考虑工具的限制,然后再考虑用户分布情况。比如iOS平台在远程测试中,将面临以下问题:

iOS的远程测试,基于QuickTime的解决方案,用户必须使用OSX操作系统

iOS的远程测试,无法看到和记录用户手势

在iOS的远程测试中,我们需要先让用户将手机屏幕投影到PC/Mac上,再通过远程屏幕共享软件,将屏幕同步到观察人员面前。而Mac在桌面操作系统的占比太低,使得我们很难募集到足够的Mac用户参与远程测试。PC平台的镜像App延迟都比较严重。另外苹果的安全限制使得手势无法被观察和记录,也让观察效率大大降低。

这些限制使得iOS的远程测试困难重重,所以我们建议iOS平台产品尽量做现场测试。Android平台产品或者全平台覆盖产品的有主持人的远程测试,可以通过下面的工具来实现。

5 移动远程测试(有主持人)的可用性测试工具

有主持的远程移动可用性测试中,研究人员需要利用工具解决两个主要问题:

实时看到用户的手机界面(包括手势)

与用户实时交流

实时看到用户的手机界面,可以利用上篇中提到的工具AirDroid/Mobizen,通过Wifi同步用户的屏幕和手势。以AirDroid举例,在开始测试前,需要让用户预装AirDroid,登录指定账号,并打开系统设置里的“显示屏幕触摸”。

远程与用户实时交流,国外一般会推荐网络会议工具,但是这些工具都太复杂了,需要很高的教育用户成本和预装成本。推荐使用QQ的免费视频功能就好。最后用本地的录屏软件做记录QQ视频和AirDroid的窗口就可以了。下图是我们的测试结果,左侧是AirDroid屏幕镜像窗口,可以看到用户手势,右侧是QQ视频窗口。

虽然AirDroid/Mobizen已经是比较好的基于无线网络的解决方案,但无线网络环境太复杂,实际测试中,AirDroid/Mobizen依然会出现卡顿的情况。所以另一种解决方案是,让用户通过Mobizen先把手机屏幕同步到用户PC上,再通过QQ屏幕分享给用户研究人员。

6 移动远程测试(无主持人)的工具比较

无主持的远程移动可用性测试,主要用于收集用户在移动设备上的定量行为数据,以及定性的操作视频。因为是被试者远程自主进行,也没有研究人员进行指引,所以相应的测试指引和数据收集都需要依靠工具。这就需要专门的移动测试应用具备以下几个主要功能:

1.可以预设测试任务指引

2.可以记录用户操作数据(任务时间、用户手势等)

3.可以录制用户操作视频

4.提供测试后问卷以获取用户的主观反馈和信息

5.分析记录数据(如通过事件追踪视频相应位置等)

目前已知的可用于移动远程测试的工具,并没有完美地兼具以上功能。我们对下表的工具做了简单的对比测试(Reflector,GoToMeeting,Magitest,UXrecorder,UserZoom,Userlytics,Appsee),发现大部分工具都有这样或那样明显的局限性,无法运用于实际测试中,现状令人十分沮丧。最后选择Appsee作为重点体验对象,下面详细分析。

7 Appsee体验

Appsee提供了数据分析功能和用户操作录屏。数据分析功能帮助设计师了解宏观层面的整体使用情况;用户的操作录屏数据,有利于在微观层面,对用户使用问题作进一步定性分析。为了能更深入的了解这个工具,我们在Lightalk app里部署了Appsee,以下是我们在真实使用环境下收集到的数据。

Appsee保存了用户操作录屏的数据,以非常友好的方式将数据展示出来。右侧的时间线清晰的标识出用户的点击及手势操作,你能快速定位到某个你感兴趣的视频片段上。下图展示了其中一个用户在注册Lightalk时设置头像的操作过程,我们在其中发现了有趣的细节,用户首选通过“自拍”的方式来设置头像,然后又取消了此操作。由此我们推断出“自拍”功能的设计没能满足该用户的预期,可能是因为缺乏好看的滤镜效果。通过分析视频,我们能在细节上揣摩每个用户的操作行为,更好的了解他们的预期和心理。 Appsee还对用户进行了分类,分为新用户(First Sessions)、回归用户(Returning Users)、忠诚用户(Royal users)、流失用户(Quick Abandons)、短期停留(Short Sessions)、长期停留(Long Sessions)。

Appsee分析了App的常用页面,统计了每个页面的平均停留时间及交互的情况。你能看到用户在这些页面里执行的主要操作及频率对比,还给出每个页面的上下级页面。如下图所示,我们能看到在Lightalk的通话tab上,80%的用户会选择最近联系人发起通话,20%的用户通过搜索找到目标对象。

基于预先设定的页面跳转路径,Appsee能追踪用户在执行这些路径时的具体情况。你能观察到有多少比例的用户顺利完成了整个流程,有多少比例的用户在哪个页面流失。

为了获取App的使用数据,开发人员需要在App里嵌入Appsee的SDK,花费几小时完成部署工作。iOS、 Android两个平台需要分开部署。Appsee的收费方式是基于App的,针对不用用户规模的App,Appsee定价也会有差异。具体的费用需要与他们的团队通过邮件或Skype沟通。

Appsee也有它的不足。它生成的数据无法保存或导出,只能通过它自己的网站查看,不适用于保密项目。它目前只支持App,不支持Web的可用性测试。Appsee的收费方式有一定的局限性,对于新孵化的项目,要专门为它购买整套服务显然不现实,成本太高。个人认为Appsee更适用于已积累了一定用户量的应用,例如QQ、微信这种。

总体来说,Appsee是笔者认为目前做得最完善的移动可用性测试工具。它能保存用户操作录屏,真实地还原了用户的使用场景。提供的页面分析视图、路径分析视图,非常实用,帮助设计师迅速了解到App关键界面的使用情况。

8 总结

从流程方法上来说,移动可用性测试继承了传统可用性测试的主要框架,但是在具体问题上又有不同。借用张小龙的话来说,“手机是肢体的延伸,和人是一体的,而PC是外物,即外部环境。”虽然手机看上去只是屏幕变小了,但实际上意味着手机对用户来说更私密,会在移动中使用手机,会通过传感器和手机交互,设备和平台充满多样性…

本文选择了几个点来阐述移动可用性测试的不同,包括移动平台选择,移动情境,用户设备还是测试设备等。这里应该有更多可以深入思考和挖掘的差异点,希望不只是我们的产品设计思路,我们的用户研究思路也需要跟上移动的脚步。

从移动原型和测试工具上来说,移动可用性测试面临的原型工具转换,观察困难,记录困难,这些问题会更突出一些。然而问题也是机遇,比如通过我们对工具的测试研究,发现通过前置摄像头拍摄用户表情的可行性,使得在不借助外部摄像头的情况下,手机可以完整记录用户所有信息。移动原型工具大爆发,也使得我们有更多选择,更方便的途径来制作和生成移动原型。

然而工具使用的限制依然很多。在现场测试的部分,我们给出了4种情况下,对应的最佳选择;远程测试部分,通过对大量工具的测试比较,我们认为还没有针对所有场景的解,甚至某些场景下,目前所有的工具都还不够理想。但工具也在持续发展,希望后续有更好的工具可以和大家进一步分享。

写这篇文章的初衷,是因为大家都在做移动可用性测试,但国内很少看到全面整体的介绍文章,大量资料都是零散的,缺乏最佳实践。研究过程比较繁琐,需要阅读大量的资料,梳理总结,并对测试工具做逐一测试,归纳出我们认为最行之有效的做法。希望通过我们的工作,给用研和产品设计同学们一个全面的移动可用性测试的参考资料。

   
 订阅
  捐助
相关文章

性能测试十问:测试经理篇
web前端性能优化进阶路
性能测试综述
VS2010中自动化测试—Web性能测试
相关文档

性能测试
性能测试执行之测试脚本录制
性能测试进阶1-流程篇
性能测试进阶2-方案篇
相关课程

性能测试方法与技术
使用LoadRunner进行性能测试
Android应用的性能测试
基于Android的单元、性能测试
 

LoadRunner性能测试基础
软件测试结果分析和质量报告
面向对象软件测试技术研究
设计测试用例的四条原则
功能测试中故障模型的建立
性能测试综述
更多...   


性能测试方法与技术
测试过程与团队管理
LoadRunner进行性能测试
WEB应用的软件测试
手机软件测试
白盒测试方法与技术

相关咨询服务
建立软件测试规范
性能评测与调优


某博彩行业 数据库自动化测试
IT服务商 Web安全测试
IT服务商 自动化测试框架
海航股份 单元测试、重构
测试需求分析与测试用例分析
互联网web测试方法与实践
基于Selenium的Web自动化测试
更多...   
 
 
 

 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号