18326051278
2017-09-29
毅耘科技
1797
【毅耘科技】
现场测试可以面对面接触用户，能够观察和记录所有的现场信息。远程测试虽然情境还原度较高，但通过摄像头和麦克风得到的信息毕竟有限，许多场外信息包括用户肢体语言都会有所缺失。此外，现场测试更容易控场，可以保证无干扰的环境、通行的网络，也可以及时解答用户的问题，保证用户能专注在测试自己，而远程测试在控场方面有所不足。最后，现场测试对工具的要求更低，不论是制作测试原型，照旧测试环境的搭建。
然而现场测试也有它的局限性。因为时间、空间及成本的限制，现场测试方法只适用于少量、有限制的样本测试。比如研究人员在一线城市，现场测试可能只能招募本地的被试者，难以触达其他地域的用户。缺少三四线城市的用户分析，那么最后的研究效果很可能会产生误差。这种情况下，低成本的远程测试会是一个很好的增补。决定采用现场测试照旧远程测试，主要取决于以下两点：
假如产品的目标用户在本地无法招募，如面向海外市场的产品；或者产品的用户分布在地域上比较分散，如覆盖全国一二三四线城市的产品，本地招募的被试者不具代表性，那么远程测试就很有需要。
现场测试适合做小样本测试，当需要大样本效果时，无主持的远程测试可能是更好的方案。
现场测试和远程测试的选择，还要考虑此次可用性测试处在产品研发的哪个流程阶段。下面就“何时开始测试”这个话题，简单说下我们的看法。
大部分公司的研发流程，都可以大致归类为需求阶段、设计阶段、开发阶段、测试阶段和发布阶段。我们把设计结束作为分界线，可以将可用性测试时机分为早期介入和后期介入。
这个阶段做可用性测试，一般没有很充裕的预备和测试时间，测试原型和最终上线的产品也会有出入。然而早期介入的优点是，这个阶段产品还未定型，测试的效果可以立即反馈给产品和设计人员用于迅速迭代，测试效果落地和推动的成原形对较低。此外，也可以通过卷入产品设计人员参与测试，从而分担或省略掉一部分可用性测试记录工作。
进入开发阶段之后，可以拿到更接近制品的原型用于测试（如内嵌代码到程序中），也有更充裕的测试时间。但这个阶段，产品的需求变更会更郑重，测试效果的推动落地难度成本也会上升，因此需要更多的证据支撑。在腾讯的环境下，这个阶段得到的测试结论，假如被接受了，一般要到下个版本才能排期。
对于形成性测试来说，我们更推荐在项目早期测试。这时会更多采用现场测试的方法。一般在交互完成后开始测试，测试过程和视觉设计阶段并行。可以运用第一篇介绍的原型制作工具快速生成移动测试原型。也可以在产品需求完成阶段进行测试，和交互设计并行，但此时的测试原型会更粗糙。
在实验室中进行现场测试是目前做移动可用性测试较多的体例。相比PC可用性测试，移动可用性测试对如何有用观察和记录用户行为操作提出了挑战。
一方面，因为移动设备屏幕较小，主持人难以直接观察被试者的移动设备屏幕，可能会遗漏主要问题。对于记录员和其他观察者，能够直接清楚地观察到被试者屏幕的可能性更小。另一方面，不同于PC互联网时代使用鼠标和键盘交互，移动互联网时代，用户通过手势与触摸屏进行交互，测试时不仅要记录界面行为，还要记录用户手势，最好还要同步记录用户表情和语音。因此，进行移动可用性测试，我们需要找到新的观察、记录体例和工具。
现场移动可用性测试工具需要解决3个问题：
通过对主流方法的研究，以及对第三方App的探索，我们整顿了以下这些工具：
（注：工具研究主要针对手机上的App测试，对于移动Web测试和平板设备测试并未覆盖）
对于现场测试，我们首先要解决的是现场多人观察的问题。通过镜像类App，把手机屏幕同步到PC/Mac屏幕上，可以很方便地进行多人现场观察和录屏。
之前iOS下的镜像解决方案主要是reflector + 录屏App。但苹果发布了Yosemite之后，原生的QuickTime可以支撑对屏幕或摄像头进行录屏操作。iPhone需要升级到iOS8，然后通过数据线与Mac连接。Mac上打开QuickTime，新建影片录制，这时QuickTime会先激活摄像头。再点击录制按钮旁的下拉箭头，将相机源改为测试的iPhone，这时屏幕中将出现手机画面，就可以进行iPhone录屏了。Quicktime解决方案完全不需要用到第三方App就可以完成镜像和录屏，并且因为是系统级的解决方案，镜像特别很是流畅。即使是用户手机，只要升级了iOS8，插上数据线之后也可以很方便地扩展到Mac进行观察和录屏。
QuickTime作为苹果原生解决方案，操作特别很是简便。无论是使用同一测试设备，照旧用户自己的设备，都很方便，只需要一根数据线。但因受到苹果的限制，这个解决方案无法观察和记录用户的手势，记录表情和声音也需要借助其他设备，所以一般只用作iOS屏幕镜像和观察。
在安卓平台上，许多手机助手类的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的系统设置-开发者选项中打开“显示触摸操作”即可。
记录移动设备手势对移动可用性测试来说特别很是主要，比如用户在屏幕上尝试的滑脱手势，或者用户对着一个按钮点了10次但是没有响应。通过记录用户手势信息，这些场景都能够被我们有用地记录和还原。
因为苹果的系统限制，任何App都无法记录用户手势。唯一的解决方案只有逃狱。逃狱后，找到一款叫Display Recorder的插件，装上它就能够记录屏幕和手势了。虽然是逃狱插件，但Display Recorder的体验特别很是优异，最新的版本已经更新到支撑iOS8。
录屏结束后，视频会存在手机上，需要从手机上导出。假如不希望在iPhone上记录之后再导出，也可以选择Display Recorder + QuickTime的解决方案，再配合摄像头、麦克风在PC/Mac上来记录用户的表情和声音。
这个解决方案最大的局限是，必须使用同一的测试设备，因为不太可能拿着用户的iPhone去逃狱。
假如能够同时记录屏幕、手势、表情和声音，且不依靠于硬件，那该是多么美好的一件事情。所有的手机都是带前置摄像头和麦克风的。因此，假如前置摄像头可以同步记录用户表情，是不是就解决这个问题了？带着这个目的，我们研究了一下Android上的录屏App。
Android上的录屏App许多，通过现实测试和比较之后，我们建议使用SCR。除了常规的录屏功能之外，SCR还支撑开启手机前置摄像头（如下图）。这样，在录屏的时候，还可以同步记录用户表情。在开始记录之前，前置摄像头的画面位置还可以拖放到你希望的位置，但一旦开始记录之后，就无法再改变它的位置了。
SCR比较周全地解决了记录用户屏幕、手势、表情和声音的问题，最后输出的视频质量也很高。但存在一个瑕玷，前置摄像头的画面无法隐藏。虽然可以调节透明度，但始终对屏幕有遮挡。因此，用户会很显明意识到自己正在被拍摄。
使用SCR时，要解决多人现场观察的问题，需要结合Mobizen一路使用。另外，在使用录屏App的过程中，要注重手机的电量和剩余内存空间。在现实测试过程中，我们发现录屏App比较耗电，且录制一段30分钟视频就会很占空间，一旦空间满了，App就很容易出错。
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用于做移动可用性测试的限制还特别很是多，程序也不太稳定。
上面介绍的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。实物摄像机比较轻便，拥有较高的分辨率，可以和桌面软件优秀地整合，但是实物摄像机原本是用于拍摄文档的，因此每秒的帧数较低。也可以自制这样的装配，我们建议采用可以调整摄像头方位的底座，比如带有云台的小型三脚架，或者是其他任何带有摇臂的底座。在我们的现实工作中，我们还尝试过使用工作台灯的底座，将摄像头固定在原本安装在灯泡的位置。
但是摄像头的底座固定，要求被试者在测试过程中也要相对固定移动屏幕位置，一旦移动设备屏幕位置改变角度、方向，或是不小心超出摄像头可视范围，录制的效果将会受到很大影响。假如调整了摄像头位置，还另需花时间调整响应的移动屏幕位置。因此，这种装配在测试平板设备上的产品时可能相对有用，用户原本一般就是将平板设备放在桌面上进行操作。但对于智能手机，用户更习惯手持操作，过程中可能存在移动和晃动的情况，这时下面介绍的雪橇装配可能更为有用。
除了固定镜头位置的记录体例外，另一种是行使将摄像机/摄像头支在可手持的支架上，移动设备放在支架上进行测试，这种装配形似雪橇，因此也通常被俗称为“雪橇装配”。
雪橇装配，市面上有现成可以直接购买的，如MOD1000。其实，许多研究人员会使用他们自制的雪橇装配进行测试。在自制雪橇装配时，有几点需要注重：
在选取外置摄像头时，除了考虑摄像头自己的影像质量，还需要考虑摄像头的重量，以及是否方便安装在雪橇装配上。一些研究人员比较推荐Hue的高清网络摄像头，很轻便，分辨率也不错，每秒帧数也足够，自己带有一个可调节的软管支架。
雪橇装配也存在一些瑕玷。首先，雪橇装配有一定重量，用户可能会感到不习惯、不天然，用户手持一准时间后，会特别很是容易疲惫，从而将设备放置在桌面上进行测试。其次，画面质量不如实物摄像机。
回顾一下以上解决方案：
从测试工具的角度来讲，使用同一测试设备的实现成本最低，尤其是Android平台。最后，给出我们推荐的移动现场可用性测试的最佳实践。
下一篇，我们聊聊远程测试。
附：
《移动可用性测试 (一)：概述》
《移动可用性测试 (二): 问题讨论》
来自：腾讯ISUX
作者：小杨梅
导航
返回列表
在线咨询