移动可用性测试(三):现场测试

0 评论 6308 浏览 10 收藏 25 分钟

现场测试还是远程测试

现场测试可以面对面接触用户,能够观察和记录所有的现场信息。远程测试虽然情境还原度较高,但通过摄像头和麦克风得到的信息毕竟有限,很多场外信息包括用户肢体语言都会有所缺失。此外,现场测试更容易控场,可以保证无干扰的环境、通畅的网络,也可以及时解答用户的问题,保证用户能专注在测试本身,而远程测试在控场方面有所不足。最后,现场测试对工具的要求更低,不论是制作测试原型,还是测试环境的搭建。

然而现场测试也有它的局限性。由于时间、空间及成本的限制,现场测试方法只适用于少量、有限制的样本测试。比如研究人员在一线城市,现场测试可能只能招募本地的被试者,难以触达其他地域的用户。缺少三四线城市的用户分析,那么最后的研究结果很可能会产生偏差。这种情况下,低成本的远程测试会是一个很好的补充。决定采用现场测试还是远程测试,主要取决于以下两点:

  • 用户分布

如果产品的目标用户在本地无法招募,如面向海外市场的产品;或者产品的用户分布在地域上比较分散,如覆盖全国一二三四线城市的产品,本地招募的被试者不具代表性,那么远程测试就很有必要。

  • 样本量

现场测试适合做小样本测试,当需要大样本结果时,无主持的远程测试可能是更好的方案。

何时开始测试

现场测试和远程测试的选择,还要考虑此次可用性测试处在产品研发的哪个流程阶段。下面就“何时开始测试”这个话题,简单说下我们的看法。

大部分公司的研发流程,都可以大致归类为需求阶段、设计阶段、开发阶段、测试阶段和发布阶段。我们把设计结束作为分界线,可以将可用性测试时机分为早期介入和后期介入。

早期介入

这个阶段做可用性测试,一般没有很充裕的准备和测试时间,测试原型和最终上线的产品也会有出入。然而早期介入的优点是,这个阶段产品还未定型,测试的结果可以立即反馈给产品和设计人员用于敏捷迭代,测试结果落地和推动的成本相对较低。此外,也可以通过卷入产品设计人员参与测试,从而分担或省略掉一部分可用性测试记录工作。

后期介入

进入开发阶段之后,可以拿到更接近成品的原型用于测试(如内嵌代码到程序中),也有更充裕的测试时间。但这个阶段,产品的需求变更会更谨慎,测试结果的推动落地难度成本也会上升,因此需要更多的证据支持。在腾讯的环境下,这个阶段得到的测试结论,如果被接受了,一般要到下个版本才能排期。

对于形成性测试来说,我们更推荐在项目早期测试。这时会更多采用现场测试的方法。一般在交互完成后开始测试,测试过程和视觉设计阶段并行。可以运用第一篇介绍的原型制作工具快速生成移动测试原型。也可以在产品需求完成阶段进行测试,和交互设计并行,但此时的测试原型会更粗糙。

 移动可用性测试(三):现场测试

现场移动可用性测试的常用App和装置

在实验室中进行现场测试是目前做移动可用性测试较多的方式。相比PC可用性测试,移动可用性测试对如何有效观察和记录用户行为操作提出了挑战。

一方面,由于移动设备屏幕较小,主持人难以直接观察被试者的移动设备屏幕,可能会遗漏重要问题。对于记录员和其他观察者,能够直接清楚地观察到被试者屏幕的可能性更小。另一方面,不同于PC互联网时代使用鼠标和键盘交互,移动互联网时代,用户通过手势与触摸屏进行交互,测试时不仅要记录界面行为,还要记录用户手势,最好还要同步记录用户表情和语音。因此,进行移动可用性测试,我们需要找到新的观察、记录方式和工具。

现场移动可用性测试工具需要解决3个问题:

  • 扩展移动设备屏幕便于现场观察
  • 记录屏幕和用户手势
  • 记录用户表情和声音

通过对主流方法的研究,以及对第三方App的探索,我们整理了以下这些工具:

(注:工具研究主要针对手机上的App测试,对于移动Web测试和平板设备测试并未覆盖)

  • QuickTime (iOS) — 现场观察,仅记录屏幕
  • Mobizen (Android) — 现场观察,记录屏幕、手势
  • Display Recorder (iOS) — 记录屏幕、手势、声音
  • SCR (Android) — 记录屏幕、手势、表情、声音
  • Magitest (iOS) — 记录屏幕、手势、表情、声音
  • Mobizen + AirDroid (Android) — 现场观察并记录手势、表情、声音
  • 固定摄像机/摄像头解决方案
  • 雪橇装置解决方案

3.1 QuickTime (iOS) — 现场观察,仅记录屏幕

对于现场测试,我们首先要解决的是现场多人观察的问题。通过镜像类App,把手机屏幕同步到PC/Mac屏幕上,可以很方便地进行多人现场观察和录屏。

之前iOS下的镜像解决方案主要是reflector + 录屏App。但苹果发布了Yosemite之后,原生的QuickTime可以支持对屏幕或摄像头进行录屏操作。iPhone需要升级到iOS8,然后通过数据线与Mac连接。Mac上打开QuickTime,新建影片录制,这时QuickTime会先激活摄像头。再点击录制按钮旁的下拉箭头,将相机源改为测试的iPhone,这时屏幕中将出现手机画面,就可以进行iPhone录屏了。Quicktime解决方案完全不需要用到第三方App就可以完成镜像和录屏,并且因为是系统级的解决方案,镜像非常流畅。即使是用户手机,只要升级了iOS8,插上数据线之后也可以很方便地扩展到Mac进行观察和录屏。

 移动可用性测试(三):现场测试

QuickTime作为苹果原生解决方案,操作非常简便。无论是使用统一测试设备,还是用户自己的设备,都很方便,只需要一根数据线。但因受到苹果的限制,这个解决方案无法观察和记录用户的手势,记录表情和声音也需要借助其他设备,所以一般只用作iOS屏幕镜像和观察。

3.2 Mobizen (Android) — 现场观察,记录屏幕、手势

在安卓平台上,很多手机助手类的App都支持手机屏幕镜像到PC/Mac,如豌豆荚、91手机助手等。但我们实际测试下来发现,手机助手的屏幕镜像速度都令人捉急,延迟比较厉害,还会发生卡顿的情况。

经过实际的测试比较,我们推荐使用Mobizen作为Android平台上的屏幕镜像解决方案。这个方案下,需要安装Android版Mobizen,以及PC/Mac客户端版Mobizen。然后把手机和PC/Mac通过数据线相连,选择“USB连接”的方式镜像屏幕,基本无延迟。下图是Mobizen的界面和在Mac上的镜像效果。此外,在切换成横屏应用时,Mobizen的手机模拟器也会同步旋转,这个细节非常友好。(题外话,Mobizen有个Bug,密码设得过于复杂会提示账户不存在。)

 移动可用性测试(三):现场测试

对比QuickTime解决方案,Mobizen也可用于统一测试设备或者用户自己设备两种情况。但在用户自己的设备做测试时,需要在用户的手机里预装Mobizen App。此外,Android平台有一个iOS平台不具备的优势,就是可以显示手势。在Android的系统设置-开发者选项中打开“显示触摸操作”即可。

3.3 Display Recorder (iOS) — 记录屏幕、手势、声音

记录移动设备手势对移动可用性测试来说非常重要,比如用户在屏幕上尝试的滑动手势,或者用户对着一个按钮点了10次但是没有响应。通过记录用户手势信息,这些场景都能够被我们有效地记录和还原。

由于苹果的系统限制,任何App都无法记录用户手势。唯一的解决方案只有越狱。越狱后,找到一款叫Display Recorder的插件,装上它就能够记录屏幕和手势了。虽然是越狱插件,但Display Recorder的体验非常优秀,最新的版本已经更新到支持iOS8。

录屏结束后,视频会存在手机上,需要从手机上导出。如果不希望在iPhone上记录之后再导出,也可以选择Display Recorder + QuickTime的解决方案,再配合摄像头、麦克风在PC/Mac上来记录用户的表情和声音。

这个解决方案最大的局限是,必须使用统一的测试设备,因为不太可能拿着用户的iPhone去越狱。

3.4 SCR (Android) — 记录屏幕、手势、表情、声音

如果能够同时记录屏幕、手势、表情和声音,且不依赖于硬件,那该是多么美好的一件事情。所有的手机都是带前置摄像头和麦克风的。因此,如果前置摄像头可以同步记录用户表情,是不是就解决这个问题了?带着这个目的,我们研究了一下Android上的录屏App。

Android上的录屏App很多,通过实际测试和比较之后,我们建议使用SCR。除了常规的录屏功能之外,SCR还支持开启手机前置摄像头(如下图)。这样,在录屏的时候,还可以同步记录用户表情。在开始记录之前,前置摄像头的画面位置还可以拖放到你希望的位置,但一旦开始记录之后,就无法再改变它的位置了。

 移动可用性测试(三):现场测试

SCR比较全面地解决了记录用户屏幕、手势、表情和声音的问题,最后输出的视频质量也很高。但存在一个缺点,前置摄像头的画面无法隐藏。虽然可以调节透明度,但始终对屏幕有遮挡。因此,用户会很明显意识到自己正在被拍摄。

使用SCR时,要解决多人现场观察的问题,需要结合Mobizen一起使用。另外,在使用录屏App的过程中,要注意手机的电量和剩余内存空间。在实际测试过程中,我们发现录屏App比较耗电,且录制一段30分钟视频就会很占空间,一旦空间满了,App就很容易出错。

3.5 Magitest (iOS) — 记录屏幕、手势、表情、声音

SCR是Android上的解决方案,那iOS上是否有类似的解决方案呢?经过研究,我们发现有两款App:UX Recorder和Magitest。UX Recorder只能用于移动Web测试,这里主要分析下Magitest这款App。

Magitest能够支持对App的测试,这是它对比竞品的一个明显优势。然而如上文所说,苹果是不支持第三方App直接获得手势信息的。Magitest实现获得手势的方法是内嵌代码到发布程序中。然而这带来了一个缺陷,就是无法将Magitest用于项目早期的原型测试,使得这个工具的应用场景大大减少。

Magitest最后会把屏幕记录和前置摄像头的画面记录拼到一个视频结果中,这样可以同步看到用户表情和界面上的变化。在开始测试前,可以设置把前置摄像头的画面放在界面的4个角落中的哪一个。如下图,Front Camera选择了Bottom Right的话,前置摄像头拍到的用户表情画面就会出现在视频中界面的右下角。对比SCR,Magitest是专门为了测试而设计的App,所以它在测试的时候不会显示前置摄像头的画面,这一点很贴心(然而也带来了问题,下面会讲)。我们从AppStore上扒了介绍截图下来供大家参考,左侧是起始设置界面,可以选择前置摄像头画面的位置;右侧是最后录制的视频的界面,能看到手势和用户表情。

 移动可用性测试(三):现场测试

最后吐槽下Magitest的缺点。SCR的实现逻辑是把前置摄像头的画面直接显示在手机上,然后一起录下来;而Matigest并不显示前置摄像头画面,所以它实现逻辑应该是分开记录两段视频,最后再拼起来。这会带来以下两个问题,一是会在测试过程中感觉到手机延迟,二是在测试结束后会有一个视频生成的过程(应该是在拼合两段视频),这个过程很慢,甚至在过程中发生过无法完成的情况。

另外,如上文所说,Magitest对App做测试时,只能使用统一的测试设备,且因为需要内嵌代码,也因此无法用于早期原型测试。总的来说,将Magitest用于做移动可用性测试的限制还非常多,程序也不太稳定。

3.6 Mobizen + AirDroid (Android) — 现场观察并记录手势、表情、声音

上面介绍的SCR的解决方案,还是有个小缺陷,就是前置摄像头拍摄的画面会显示在手持设备屏幕上。在Android平台上,有没有可能利用Mobizen镜像屏幕和手势,再用另一个程序远程观测前置摄像头,最后在PC/Mac上进行录屏呢?

在监控类App里做了很多寻找但无果之后,意外发现AirDroid这款手机助手类工具,在它的Web版里竟然可以实现远程调用手机摄像头。

下图是在Mac上,Nexus5使用Mobizen和AirDroid记录前置摄像头和屏幕镜像的效果。装有AirDroid的Mac和Nexus5在同一Wifi下的情况下,前置摄像头几乎没有延迟。两个屏幕在用户横屏的时候都会进行相应的旋转。此时,用户对于正在被记录这件事情也是完全没有感知的。

移动可用性测试(三):现场测试

另外,在测试Mobizen+AirDroid时,我们还录制了一小段视频。

题外话,AirDroid作为一款手机助手工具,本身也可以镜像屏幕和手势。但是,因为目前版本只支持基于Wifi的连接,所以镜像同步速度不如Mobizen。我们在测试时,也尝试了AirDroid Web版监控前置摄像头+AirDroid客户端版本镜像手机屏幕的方案,但因为两者都是走Wifi连接,所以比较卡,有明显的延迟,不如AirDroid + Mobizen解决方案来得好。

3.7 使用固定摄像机/摄像头记录

以上App类工具的解决方案,绝大部分都需要对手机做App预装和调试,更适合统一设备的测试。如果我们要测试用户自己的手机,那可能摄像头方案更合适。

使用摄像机/摄像头,可以同时捕捉移动设备屏幕和用户的操作手势,全面记录被试者的实际操作。而且,还可以直接与桌面设备上的测试、观察软件整合使用,比如Morae,它可以同时支持两个摄像头输入,一个记录用户的操作行为,一个记录用户的表情。这样,即使是身在观察室的观察者们,也能实时看到全部测试过程。

这里的摄像机/摄像头,我们指的是有内置软件可以实时处理录制画面的实物摄像机(Document Camera)或是网络摄像头(Webcam)。此时,摄像机/摄像头位置相对固定,移动设备屏幕置于摄像头的可视范围内进行测试。

这种形式的装置,可直接使用带有灵活支架的实物摄像机,如Ipevo。实物摄像机比较轻巧,拥有较高的分辨率,可以和桌面软件良好地整合,但是实物摄像机原本是用于拍摄文档的,因此每秒的帧数较低。也可以自制这样的装置,我们建议采用可以调整摄像头方位的底座,比如带有云台的小型三脚架,或者是其他任何带有摇臂的底座。在我们的实际工作中,我们还尝试过使用工作台灯的底座,将摄像头固定在原本安装在灯泡的位置。

移动可用性测试(三):现场测试

但是摄像头的底座固定,要求被试者在测试过程中也要相对固定移动屏幕位置,一旦移动设备屏幕位置改变角度、方向,或是不小心超出摄像头可视范围,录制的效果将会受到很大影响。如果调整了摄像头位置,还另需花时间调整相应的移动屏幕位置。因此,这种装置在测试平板设备上的产品时可能相对有效,用户本来一般就是将平板设备放在桌面上进行操作。但对于智能手机,用户更习惯手持操作,过程中可能存在移动和晃动的情况,这时下面介绍的雪橇装置可能更为有效。

3.8 使用雪橇装置记录

除了固定镜头位置的记录方式外,另一种是利用将摄像机/摄像头支在可手持的支架上,移动设备放在支架上进行测试,这种装置形似雪橇,因此也通常被俗称为“雪橇装置”。

雪橇装置,市面上有现成可以直接购买的,如MOD1000。其实,很多研究人员会使用他们自制的雪橇装置进行测试。在自制雪橇装置时,有几点需要注意:

  • 雪橇必须足够轻巧,使用户可以连同移动设备一起拿在手中进行测试。
  • 不能让雪橇遮挡住设备屏幕,干扰用户测试。
  • 雪橇的尺寸规格应该能够适应多种主流设备,便于被试者通过自己的设备进行测试。最理想做法的是使雪橇外形和尺寸可调节。
  • 雪橇的造型应该允许用户调转设备的屏幕方向。
  • 雪橇整体应该足够稳固。

 移动可用性测试(三):现场测试

在选取外置摄像头时,除了考虑摄像头本身的影像质量,还需要考虑摄像头的重量,以及是否方便安装在雪橇装置上。一些研究人员比较推荐Hue的高清网络摄像头,很轻巧,分辨率也不错,每秒帧数也足够,本身带有一个可调节的软管支架。

雪橇装置也存在一些缺点。首先,雪橇装置有一定重量,用户可能会感到不习惯、不自然,用户手持一定时间后,会非常容易疲惫,从而将设备放置在桌面上进行测试。其次,画面质量不如实物摄像机。

3.9 现场移动测试工具总结

回顾一下以上解决方案:

  • Display Recorder + QuickTime,iOS上记录手势必须要越狱,所以只能用统一测试设备做测试。利用Display Recorder显示手势之后,配合摄像头和麦克风记录用户表情和声音,最后再录屏。
  • Magitest方案看起来很美,但实际使用中限制和问题都比较多,更像是一个探索性的解决方案。
  • Mobizen + SCR,预装难度低,视频质量高,缺陷在于前置摄像头画面对手机屏幕有遮挡,用户对于被拍摄有感知,事后需要导出视频。
  • Mobizen + AirDroid,是比较完美的解决方案,只需要一根数据线,用户对被拍摄也没有感知。但如果使用用户自己的设备做测试,有安装App和调试的成本。
  • 摄像头(雪橇)可以适用于所有场景,但缺点就是硬件架设难度,以及给用户带来的心理压力。

从测试工具的角度来讲,使用统一测试设备的实现成本最低,尤其是Android平台。最后,给出我们推荐的移动现场可用性测试的最佳实践。

 移动可用性测试(三):现场测试

作者:小杨梅

文章来源:腾讯ISUX (http://isux.tencent.com/mobile-usability-testing-three.html)

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!