|
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下的情况下，前置摄像头几乎没有延迟。两个屏幕在用户横屏的时候都会进行相应的旋转。此时，用户对于正在被记录这件事情也是完全没有感知的。
另外，在测试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平台。最后，给出我们推荐的移动现场可用性测试的最佳实践。
| 
