4、远程测试

4.1 方法说明

在远程测试中，用户在自己的环境中执行一系列任务，通过软件记录完成任务的过程，软件自动记录用户的点击位置和交互过程，并记录他们在使用网站或应用程序时发生的关键事件以及用户提交的反馈。这种类型的测试可以由主持人（使用网络研讨会或电话会议技术）完成，也可以作为自我测试。

在远程可用性测试当中，还会分为同步和异步两种。

所谓同步，是通过视频会议和共享工具（诸如WebEx 和 GoToMeeting）来同步进行远程可用性测试。同步的可用性测试让设计者可以实时观察不同的人是如何使用产品的。另外，如果需要，参与测试的用户是可以从相关人员那里获得一定的支持。

异步的远程可用性测试则相对好处理得多。设计人员会给这些用户设定一些特定的任务，然后会自动搜集产品交互中所有的用户数据，包括点击的位置和用户使用过程中所出现的错误。此外，设计师可能还会要求参与测试的用户在完成之后对于自己的体验进行总结，给予反馈。

4.2 适用阶段

原型设计阶段

4.3 执行规则/注意事项

“远程”意味着用户和测试者在不同空间，这就对用户提出了较高要求，也增加了测试的风险。测试过程中，任何一点挫败感都可能使任务前功尽弃。

而我们需要做的，就是尽量降低用户挫败感，让测试更顺利地进行。

4.3.1 同步测试：挑选连接稳定的镜像工具

如前所述，同步远程可用性测试中，测试者和用户是同步进行的。

一般来说，测试者会要求用户通过镜像工具，将手机屏幕镜像到测试者的电脑，类似于远程投屏。这样，测试者便能在电脑面前观看任何一位用户的手机屏幕及其操作，用户在哪些地方有所迟疑，对哪个页面的设计不理解，都能明显被观察到。

因此，在同步测试中，主要需要注意的点都集中在镜像工具的选择上。

（1）镜像工具必须支持远程测试

现在市面上的镜像工具是很多的，只要一条数据线，就能把手机屏幕投到电脑上观看。这很方便，但数据线连接并不支持远程，所谓远程，就是要在测试者和用户见不到面的时候，还能让用户把他的屏幕连接投射到测试者的电脑上，一般来说，这种远程投屏工具有两种：

• 通过同一账号密码登录进行远程投屏，如向日葵远程控制APP。

• 通过输入用户ID进行远程投屏，如TeamViewer。

 

（2）镜像工具必须简单易用

在远程测试中，应尽量避免让用户产生过多的挫败感，镜像工具的使用是其中之一，如果连接失败或连接不稳定，则会极大影响用户的操作和测试情绪。因此，在选择镜像工具时，应进行多次测试。我一般会根据这几个标准来选择：

• 容易连接操作流程简单，基本上按照“选择投屏→确定被投屏”的逻辑，在2-3步内就可以操作完成，操作步骤越多，用户可能产生挫败感的可能性就越大。

• 连接速度快按照说明操作后，镜像连接应在5-10秒内成功建立，等待时间过长或连接失败频率高的工具都不适合。

• 连接稳定 建立连接后，用户就应该要开始测试了，远程可用性测试一般在15-30分钟，这个过程中，连接一旦中断，就可能扰乱用户的操作过程，影响测试结果，因此，应选择多次试验中中断率最小的镜像工具。

 

4.3.2 异步测试：任务轻量化，让用户轻松录屏

顾名思义，异步远程就是测试者和用户是不同步的，用户在进行可用性测试时，需要记录自己的操作，以便之后提供给测试者进行分析。

整个过程不会有人在旁进行引导和鼓励，用户相当于在独立完成任务，耐心会比现场测试和同步远程测试要低得多，所以，应更加注意将用户的挫败感减到最低。

（1） 明确远程任务，使用用户的语言，避免笼统表达

在前期脚本设计中，应对任务进行明确的目标细化，使用用户的语言，以保证他们正确理解任务。

如“请你体验产品的下载功能”就不及“请你下载一部2017年的西班牙悬疑电影”来得清晰。

（2）尽量使任务轻量化

试想一下，让你一个人在家里做可用性测试，你能忍耐多长时间的任务？

一般来说，异步远程测试的任务最好设置在15-30分钟内，以包含3-5个任务为宜，为免用户失去耐心而放弃。

（3）选择简单易用的录屏工具

与同步测试工具不同，异步测试中，用户和测试者处在不同时空，用户需要自行录下任务过程，因此，主要使用的是录屏工具。

既然是工具，首要考虑便是“简单易用”。不仅要界面设计清晰，让人容易理解（最好有新手引导），还要在交互上做得人性化，让人一下子就懂得怎么用，且用得溜。

推荐的录屏工具：DU Recorder，人性化，页面承载内容虽多，但胜在新手指引明确，上手简易度高。

（4）考虑用户的手机内存

要知道，一段不到5分钟的录屏视频，大小就可能超过30M，如果一个可用性测试超过了20分钟，就要占用120M，如果用户操作相对缓慢，视频大小可能达到200M以上。这不仅会给用户的手机内存增加负担，也提高了视频传输的流量和时间成本，甚至增加传输失败的风险。

而这还不包含录屏工具本身的大小。

因此，在挑选工具时，一是要考虑工具本身的安装包大小。小鹿测试过20余款录屏工具，安装包在10M左右且功能齐全、简单易用的工具是不难找到的，前面提到的DU Recorder和大名鼎鼎的Mobizen皆为其中佼佼者。

另外，要注意录屏工具的功能选择，是否允许用户通过调低视频质量来减小录屏视频的大小。一般来说，只要能看清手机屏幕上的文字即可，不需要求高度清晰，以免给用户带来内存负担。

4.4 优缺点

优点：与实验室测试相比,它通常可以节省时间和金钱,并且参与者不需要呆在实验室中,它可以涉及更广泛的参与者。

它在某些方面更接近于现场测试,因为测试是在用户的环境中进行的,而不是人工实验室环境。这在许多情况下比实验室环境提供更好的结果。

缺点：远程同步测试方法，不好安排和集中；需要硬件支持，如：视频工具和共享设备，数据采集设备。

5、A / B测试

5.1 方法说明

为网站或应用程序的界面或流程制作两个（A/B）或多个（A/B/n）版本，在同一时间维度，分别让组成成分相同（相似）的访客群组随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析评估出最好版本正式采用。

5.2 适用阶段

原型设计阶段、产品上线后

5.3 执行规则/注意事项

5.3.1 AB测试的基本步骤

AB测试是一个反复迭代优化的过程，它的基本步骤如下图所示可以划分为：

1.设定项目目标即AB测试的目标

2.设计优化的迭代开发方案，完成新模块的开发

3.确定实施的版本以及每个线上测试版本的分流比例

4.按照分流比例开放线上流量进行测试

5.收集实验数据进行有效性和效果判断

6.根据试验结果确定发布新版本、调整分流比例继续测试或者在试验效果未达成的情况下继续优化迭代方案重新开发上线试验

从对AB测试的定义中可以看出AB测试强调的是同一时间维度对相似属性分组用户的测试，时间的统一性有效的规避了因为时间、季节等因素带来的影响，而属性的相似性则使得地域、性别、年龄等等其他因素对效果统计的影响降至最低。

 

             

如何提供对用户的有效分组以及如何判断实验中不同分组用户属性的相似性是AB测试需要解决的第一个问题。而在试验过程中如何收集用户的体验和业务数据，如何对收集的数据进行分析并判断不同版本间的优劣是AB测试需要解决的第二个问题，也是AB测试的目的所在。下面我们对AB测试中这两个关键的问题进一步展开。

5.3.2 AB测试的设计

AB测试中分流的设计直接决定了测试结果是否有效。AB测试是对线上生产环境的测试，而之所以进行AB测试通常是对测试中的改进版本所产生效果的好坏不能十分确定，所以测试版本的流量通常不宜过大。尤其对于那些影响范围较大的改版（如主流程页面的重大调整），影响用户决策的新产品上线和其他具有风险性的功能上线通常采用先从小流量测试开始，然后逐步放大测试流量的方法。但是，测试版本的流量如果太小又可能造成随机结果的引入，试验结果失去统计意义。

举个例子：某电商网站对我的历史订单这个页面进行改版的AB测试，测试的目标是提升用户的复购，衡量的指标是经过这个页面的单UV产生的GMV贡献（单日GMV总数／单日进入UV）。假设这个页面每天的UV在2000左右，而我们对新版本取的分流比例是2%，那么一天就会有差不多40个UV进入试验版本。如果试验进行1周然后考察试验结果，这是试验的结果就很容易受到某些异常样本的影响，譬如说某个土豪老王恰好分在了试验组然后购买了一个高价值的东西，那么老王的购买行为就可能带偏整个测试组的统计结果。

为了规避这种因为样本量不足造成的试验结果不可用，在AB测试设计时可以采用如下措施：

1.试验设计时预估进入试验的样本量，做分流规划时避免分配给测试集的样本量过少。

2.除了进行AB测试外增加关于数据有效性考量的AA测试，将原始版本的流量中分出两个和测试版本相同的流量也进入测试。例如：为测试一个新的功能，我们原本准备划分90%流量给老版本，10%流量给新版本；这时我们可以分配70%流量给老版本A，同时生成两个10%流量的老版本C和D进行AA测试，然后把剩余的10%流量给新版本B；在试验过程中通过考察分配给老版本C和D的两股流量是否存在显著性差异，从而认定试验分流是否有效。

 

       

3.如果参与测试新版本已经分配了很大的流量比例，但是仍然存在样本量不足的情况，这时就只能通过拉长试验时间的方式来累积足够的样本量进行比较了

AB测试的设计过程中另一个重要的点就是AB测试延续的时长了，通常AB测试延续的时间不宜太长，因为AB测试是对线上的多个版本的测试，这也就意味着线上系统需要同时维护多个可用的版本，长时间的AB测试无疑加大了系统的复杂性。但是，另一方面如果试验进行的时间太短可能会造成试验样本量不足的问题。同时，如果进行的是UI改版一类影响用户体验的测试，新版本上线后用户通常需要有一个适应的过程，这时我们通常会在试验开始时给用户一个适应期让用户适应新的UI版本，然后再考察试验的结果。适应期的长短通常以足量用户流量参与试验后的2到3天为宜。适应期过后的试验时间长短除了需要考察样本量的情况外，还需要参考用户的行为周期，譬如说电商用户的购买行为有较强的周次规律，周末流量和购买量与工作日会有显著差异，这时测试的周期应该能够覆盖一个完整的周期，也就是应该大于1周。

在试验版本的设计过程中还需要考虑线上进行多个试验相互间的影响，譬如在电商的购买流程中我们同时对搜索算法和商品详情页的UI进行优化，这两个变动贯穿在用户的购物流程中，相互之间可能是有影响的，我们需要区分试验中这两种改动带来的影响分别是怎样的。

在这种情况下当然我们可以将用户流量分成：

A.老的搜索算法和老的详情页UI

B.新的搜索算法和老的详情页UI

C.老的搜索算法和新的详情页UI

D.新的搜索算法和新的详情页UI

这样四个版本，然后进行测试。但是这样分流的问题是对于流程中元素的改动，测试的版本是呈现指数上升的，在多个改动同时进行时就容易造成版本流量不足的情况。在这种情况下就需要引入试验分层的概念，将实验空间横向和纵向进行划分，纵向上流量可以进入独占实验区域或者是并行实验区域。在独占实验区域，只有一层，实验可以独享流量且不受其他实验的干扰。在分层区域，不同的应用属于不同layer，每个应用内部，又可以划分为多层，层与层之间相互不影响。流量可以横向经过多层，每一层可有多个实验。流量在每一层都会被重新打散。

 

         

这样多层次正交的实验方式使多个并发实验都可以保证具备一定流量的并行进行。

最后，在对用户体验有明显影响的实验中通常采用对用户稳定的分流实现。即分到不同版本的用户在多次登录应用落入相同的实验版本，这样可以保证用户体验的一致性，保证用户能够在适应新版本的情况下有稳定的表现。通常会采用不同实验选用不同的hash种子，对用户的guid和上述分层实验的实验层次id的组合进行hash，然后根据hash值取余的方式进行分流。

5.3.3 AB测试效果分析

  关于AB测试实验效果的分析通常分为两个步骤：实验有效性的判断、实验结果的比较。实验有效性的判断即判断实验的分流是否已经到达所需要的最小样本量，从而能够以较大的概率拒绝两类统计错误的发生。最小样本量的判断可以采用假设实验目标指标符合正态分布下，两类错误发生概率的分位数的方式进行估算。或者更一般的可以采用AA测试，对两个老版本的实验结果计算P值，从而判断其是否存在显著差异。如果AA实验的结果不存在显著差异，那么可以认为实验结果是有效的，进而可以对新老版本的实验结果进行进一步的判断。

在确认实验有效后就可以对实验的结果进行判断了，通常通过比较新实验版本和老版本是否存在显著差异（前述的P值判断），以及计算实验结果指标的置信区间（通常选用指标的95%置信区间），从而判断新版本是否相对老版本存在显著提升或下降。

 

            

 

5.3.4 关于AB测试的一些误区

误区1: AB测试运用成本过高，可以通过灰度发布的方式来进行AB测试，进而避免同时维护不同版本的情况。

灰度发布是应用发布通常采用的方式，即对一个pool的部分服务器发布新版本的代码，而其余的服务器采用老版本代码，在确认应用正常的情况下逐步将新版本发布到pool的全部服务器。这样的方式的确可以起到分流的作用，但是这样的分流是不稳定的，用户的两次访问很有可能会被分到新老两个版本上。同时，灰度发布的分流单位通常是以服务器的流量为最小单位的，不能做到对测试流量的精确分配。

误区2: 用参加实验的部分用户的体验质疑AB实验结果的正确性。

经常碰到产品经理或是业务人员提出某些用户在新版本的实验中没有转化，而实际实验数据体现新版本效果好于老版本的情况，从而质疑实验的结果。AB测试是基于统计的结果，是基于大样本量的有效统计结果，实验结果的好坏是针对参与实验的大多数样本而言的，个例不具备代表性。

误区3: AB测试是优化Web应用的利器，应该在所有场合都应用AB测试进行优化。

AB测试从实验的设计、实施和实验结果的收集通常需要一个不短的阶段，且进行AB实验需要在线上维护多个不同的版本，所以不应该所有场景下都采用AB测试对Web应用进行优化迭代。对于那些明显的bug修复，或者对于那些能够明显改善用户体验的功能，应该采用尽快上线并监控关键数据指标的方式。此外，AB测试也不是silver bullet, 通常AB测试的时间不会延续很长时间，对于一些长期效果很难做到有效的监测和对比。

例如，某OTA对机票进行捆绑销售产生的收益进行了为期一年的多版本AB测试，测试的目标是在用户转化率没有显著下降的情况下提升用户客单价。在实验中，通过对价格非敏感用户的个性化展示、默认勾选等方式的确客单价有了很显著的提升，同时用户的线上转化率并没有显著变化甚至有了略微的提升。但是，这种捆绑销售的方式从长远来看可能对用户是有伤害的，这种情况在低频消费的场景下很难在实验的结果上有所体现。而且，这种捆绑销售的产品为媒体和公众所诟病，这些都不是AB测试能够体现的。

综上所述，AB测试是一项复杂的系统工程，除了要掌握AB测试方法，制定严谨的AB测试方案之外，还需要依赖科学的AB测试工具进行试验。

 

5.4 优缺点

优点：有效评估出最优的设计版本

缺点：需要一定的研发和设计成本

6、卡片分类

6.1 方法说明

通常用于测试分类或导航结构，让用户将一组写有信息的卡片分组，并为其分配名称或标签。卡片分类有助于了解用户如何看待内容以及他们如何组织信息，从而决定在每个页面放置什么，对于页面或功能分类很有帮助。

6.2 适用阶段

概念设计阶段

6.3 执行规则/注意事项

1）卡片准备

• 根据项目参与成员的不同，卡片数量也可以不同。比如小孩VS成人，对于小孩，注意力、理解力和精力有限，卡片不宜过多，以免出现完成不了任务的情况；对于成人，相对较好。

• 一般控制在30~100张。小于30张，用户很容易完成，但也许不能体现分类；大于100张，用户会累，而且不易记住分类内容，耗时较多，随着用户完成任务动机的提高会影响完成效率。

• 可选取名片打印纸打印卡片，也可裁剪偏硬的纸张，手写卡片内容。

 

2） 卡片内容特性

• 易懂性
  a，选择用户能够理解的内容。如：网络传输，有用户不明白网络传输和蓝牙传输的区别，认为蓝牙传输也是网络传输。
  b，内容不具有歧义或误导性。如：大数据量操作，用户不清楚是指批量操作很多数据还是指对大数据的量化操作。

• 可行性
  a，选择能够进行归纳的内容。如：“wifi，浏览器，通讯录，视频通话，手机壳”中，前四个明显属于手机的功能，最后一个手机壳属于手机的附属物。

• 条理性
  a，内容在同一层级上，避免包含关系。如：“手机多媒体，音乐，图库，视频”中，后面三个内容都包含在手机多媒体中，此时不应该同时出现来让用户分类。
  b，内容和功能任选其一，不能都选。如：“手机尺寸，开关机”中，前者属于内容，后者属于功能。

 

3）招募用户

可用性专家Nielsen认为大多数可用性研究，5个人就可以达到0.75的( 参与者的实验结果与最终结果) 相关度，他推荐卡片分类的用户数只要15人左右即可达到0.9的相关度。

            

图片来自：Jakob Nielsen，2004

Tullis与Wood经过实验分析得出参与者人数最好是20~30 人，此时邀请参与者的实验结果与最终结果的相关度可达到0.9以上。

         

图片来自：Tullis and Wood，2004

个人建议：一般情况下，每一类用户找15-20名，可以发现大部分问题；若想对不同类型人员进行对比，则每一类人员中都需要有足够多的人员。

 

4）用户进行分类前

• 活动介绍：分发卡片前，清晰地介绍活动，给用户足够多的背景信息，让其明白卡片是关于什么的。

• 分发卡片：尽量将卡片分散放在桌子上，鼓励用户先看看这些卡片（因为大多数人都不会根据后面看到的卡片来回头重新组织内容），而不是上来就划分；

• 不同类别的分类：开放式分类时，先不要告诉用户需要进行标签命名，等到分类结束后再告知，否则用户一开始就会琢磨标签命名，而不是考虑如何分组；闭合式分类可以将标签摆在桌面上。

 

5） 用户进行分类中

• 关注用户分类过程，仔细聆听用户的出声思维并记录，保持中立态度；

• 尽量让用户在没有压力的情况下完成任务；

• 如果用户对卡片内容不理解，主持应给予解释，但不可以引导用户分类；

• 当看到用户对某个卡片犹豫不决时，要立刻询问原因并记录下来。

 

6）分类结束后访谈

• 对类别如何命名？

• 为什么会这么分类，根据什么来分类？

• 类别中哪些卡片是最有代表性的？

• 哪些分类困难？为什么？哪些分类容易？为什么？

• 小组讨论中有哪些观点？

• 对整体分类的结果是否满意？有什么不满意的地方？

• … …

 

6.4 优缺点

优点：可直接接触用户，了解用户的使用习惯

缺点：用户数量有限，测试结果的信度有限