移动可用性测试：现场测试

1 现场测试还是远程测试

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

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

用户分布

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

样本量

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

2 何时开始测试

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

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

早期介入

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

后期介入

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

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

3 现场移动可用性测试的常用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下的情况下，前置摄像头几乎没有延迟。两个屏幕在用户横屏的时候都会进行相应的旋转。此时，用户对于正在被记录这件事情也是完全没有感知的。

题外话，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平台。最后，给出我们推荐的移动现场可用性测试的最佳实践。