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

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种情况下，对应的最佳选择;远程测试部分，通过对大量工具的测试比较，我们认为还没有针对所有场景的解，甚至某些场景下，目前所有的工具都还不够理想。但工具也在持续发展，希望后续有更好的工具可以和大家进一步分享。

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