可用性测试的六个方法(可用性测试的六个方法是)

在可用性测试中，如何去评估测试的场景或流程呢？应该包含哪些维度？每个维度要如何测量？怎样在不同的任务间做横向对比？本文就此一一讲述。

公司的产品最近发布了一个版本，上线了比较多的新功能。所以需要针对这些新功能做一轮可用性测试。

可用性测试算是用研的一个入门级技能，即使是从业年限不多的我也已经做过多次，基本的方法和流程都比较熟悉了。

但是之前做过的可用性测试有个缺陷：没有建立一个严谨、科学的任务评估模型。

在可用性测试中如何去评估测试的场景或流程呢？应该包含哪些维度？每个维度要如何测量？怎样在不同的任务间做横向对比？

评估模型

ISO9241中对“可用性”的定义是：特定用户在特定的使用场景中，为了达到特定目标而使用某产品时，所感受到的有效性、效率和满意度。

也就是说，在定义好了用户、场景和目标的前提下，可用性包含了下面三个维度：

有效性（Effectiveness）：用户完成特定目标的正确和完整程度。

效率（Efficiency）：用户完成特定目标的效率，与消耗的资源（如时间）成反比。

满意度（Satisfaction）：用户使用产品时感受到的主观满意程度。

良好的可用性必须能够同时满足有效性、效率和满意度三个条件；但是这三个维度也有层次之分，一般来说，有效性问题>效率问题>满意度问题。

在可用性测试中，仅仅了解每个功能的可用性水平还不够。

即使两个功能的可用性水平一样，若一个是产品的基本功能、一个是价值不大的边缘功能，我们还是需要优先去优化价值更高的功能。

也就是说，在评估一个任务时，除了可用性之外我们还需要考虑功能本身的价值。

尤其是在上线了新功能，或者我们对待测功能的价值还不太确信的时候。

功能的价值可以简单分为两部分：用户价值和商业价值。

尽管有时候需要在商业价值和用户价值之间权衡，但是作为一个体验导向的产品，还是应该将用户价值放在第一位。

在用户价值之上，若能够满足商业价值，则是更令人满意的结果。

所以，在可用性测试中可以用下面这个模型来对测试的任务进行评估：

测量方法

在上述模型中，有效性、效率、满意度都是常见的评估维度，有一些经验方法可以参考；用户价值也可以通过用户评价获得。

而商业价值则需要根据产品的实际情况进行评估，并且这一般是既有的知识，不需要在可用性测试过程中收集这个数据。

因此在可用性测试中我们需要收集的数据就只包含四个维度：有效性、效率、满意度和用户价值。

有效性

可以用任务的完成情况来评估有效性，这个数据通过观察用户的操作过程即可获得。

任务完成情况的测量主要参考NNG的建议，将每个用户的操作结果标记为失败、部分完成或全部完成。

失败：如果用户认为自己完成不了而放弃了任务，或者超过了限定时间仍然无法完成任务，则标记为失败。

需要对每个任务都设置一个限定时间。

要求对功能非常熟悉的人（相关的产品、设计师都可以）按照任务提示进行操作，记录完成操作所需的时间，称为熟练用时。

如果想要提高熟练用时的测量准确度，可以多找几个熟手操作然后取其用时平均值。

任务的限定时间根据熟练用时确定，一般是熟练用时的3-10倍，但是最高也不要超过10分钟（没有用户会有耐心花10分钟完成一个任务，如果真的需要这么久，说明任务设计得太复杂了）。

可以根据任务的难度确定倍数，如果任务对于小白用户来说确实很有难度，那么可以适当延长任务限时；如果任务很简单，或者其中包含一些输入的操作，那么可以适当减少任务限时（因为打字往往比较费时，而且对功能熟悉的人打字未必比用户快）。

部分完成：用户只完成了一部分的任务，没有完成任务卡上的所有要求。

比如，你希望用户创建一个日程并邀请小王加入，用户成功创建了日程但是却不知道如何（或者忘了）邀请小王，这就是部分完成。

之所以要区分“部分完成”这个类别，是因为它跟100%完成有差距，但是又不能与失败混为一谈。

完成：这个很容易理解，就是在限定时间内完成了任务卡上的所有要求。

最后，我们需要根据这些数据计算每个任务的成功率。NNG的建议算法是：任务成功率=(完全完成的用户数+部分完成的用户数*0.5)/用户总数，即完全完成率+部分完成率的一半。

除了用完成、部分完成和失败来评价任务完成情况外，还可以考虑另一种方式：顺利完成、遇到障碍后完成、失败。

这是我之前使用的计分方式。

这种方式下，以上所述的部分完成会被归于失败的类别（但如果用户犯的是无伤大雅的错误，比如输入错误，可以视为完成）。

而成功完成的用户会被细分为顺利完成的和遇到障碍后完成的。

之所以这样区分是因为这两种情况揭示了不同的可用水平——能让用户轻松地完成的功能可以说是相当易用的。

效率

效率可以用时间测量，对用户的操作过程计时。

可以从用户拿到任务卡开始计时，在用户宣布自己已经完成、或者限定时间到了的时候即结束计时。

不要等到用户读完任务卡、开始操作时才计时，因为有的用户习惯读完再操作，有的却喜欢一边读一边做。

也不要在看到用户完成了就结束计时，而要等用户自己认为他已经完成了，因为用户有时候会在做完操作之后去检查自己的操作是否成功了，这也应该算作任务用时的一部分。

计时不需要太精确。

手动计时存在几秒钟的误差都算是正常的，而且用户在操作过程中多说了句话、或者应用响应速度慢了些，这些都会影响任务的完成时间（并且很多影响因素跟可用性并没有关系）。

所以计时只要精确到秒就好了，提高记录的精确度也没有意义。

在计算每个任务的效率水平的时候，可以用用户的平均用时除以熟练用时所得的倍数表示（数值越大表示效率越低）。

这是为了便于任务间的横向比较，因为不同任务的复杂度不同，A任务平均用时1分钟、B任务平均用时4分钟，也不能说明A的操作效率比B高。

通过平均用时/熟练用时的比值，可以知道新手与熟手之间的差距，从而了解因为系统的可用性及学习成本给用户带来的操作时间损耗。

满意度

满意度涉及到用户的主观评价，因此需要通过用户自评量表来收集。

这里参考的是JakobNielsen使用的一个单题项七点量表，并根据需要对题目进行了修正：

用户价值

用户价值是指用户感知到的功能价值，也需要通过用户的评价获得。

因为我们做的是一款办公软件，所以通过询问功能对工作的帮助来了解用户价值：

满意度和用户价值都需要用户评分，因此用户在完成每个任务之后都会拿到同样的两个题目，要求对该任务做出评价。我会把不同任务的题目打印在同一张纸上，这样用户在评价时可以参考自己对前面的任务的评价来调整分数。

任务横向对比

用有效性、效率、满意度、用户价值四个维度对任务进行评价后，我们可以根据这些数据对不同的任务做横向对比，可以通过类似下方这样的折线图对比不同任务的情况。

比如从上面这个示例图中，我们可以看到任务2的可用性水平是比较低的（有效性水平低、完成时间长、用户满意度低），但是它的用户价值处于相对较高的水平；而任务3的用户价值最高，可用性水平居中。

有效性、效率和满意度都是用来评估可用性水平的。

如果根据这三个数值计算出可用性水平，直接用可用性去做横向对比，是否更方便呢？前文提到在可用性中，有效性问题>效率问题>满意度问题，所以在计算可用性水平时它们应该有不同的权重；并且由于度量方式的不同，它们的量纲有较大差异（从上图可以看出），需要做标准化处理。

因此，我们需要对有效性、效率、满意度分别做标准化处理，然后按照5:3:2的权重计分（或者其他权重，按需调整）：

可用性水平=Z(有效性)*0.5-Z(效率)*0.3+Z(满意度)*0.2。

（效率处用减号是因为其用时间测量，数值越大效率越低）。

这样我们得以在同个量纲上比较不同任务的可用性水平，结合对功能价值的评估，可以得出类似这样的四象限图：

这样的象限图不仅可以帮助我们比较测试的各个功能的情况，还能帮助确定体验优化的优先级。功能价值高、可用性差的功能应该列入最高优先级，其次是功能价值较低、可用性差的功能。

问题优先级

除了上述的评估模型外，在可用性测试中我们还会发现很多可用性问题，这些问题大概是可用性测试产生的最重要的数据了。那么，这些可用性问题是否需要进行优先级评估呢？

可用性问题当然是有优先级之分的，一个问题是影响了功能的有效性、效率还是满意度，就决定了这个问题的优先级如何。

我认为可以在每个任务之内按照这个标准对发现的可用性问题进行排序，但是不需要把所有任务发现的所有问题罗列出来去排列优先级。

优化可用性问题时应该以功能（即可用性测试中的任务）为单位，而不是以问题为单位——以问题为单位容易只见树木不见森林，可能在修改了很多细节后仍然算不上好用。

所以排列问题优先级时，也建议根据上面的四象限图先确定功能的优先级，然后再去查看每个功能具体的可用性问题的优先级。

题图来自Pexels，基于CC0协议

可用性测试的六个方法是

1、从是否关心内部结构来看

（1）白盒测试：又称为结构测试或逻辑驱动测试，是一种按照程序内部逻辑结构和编码结构，设计测试数据并完成测试的一种测试方法。

（2）黑盒测试：又称为数据驱动测试，把测试对象当做看不见的黑盒，在完全不考虑程序内部结构和处理过程的情况下，测试者仅依据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性，它是站在使用软件或程序的角度，从输入数据与输出数据的对应关系出发进行的测试。

（3）灰盒测试：是一种综合测试法，它将“黑盒”测试与“白盒”测试结合在一起，是基于程序运行时的外部表现又结合内部逻辑结构来设计用例，执行程序并采集路径执行信息和外部用户接口结果的测试技术。

2、从是否执行代码看

（1）静态测试：指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。

(2)动态测试：是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能指标。

3、从开发过程级别看

（1）单元测试：又称模块测试，是针对软件设计的最小单位----程序模块或功能模块，进行正确性检验的测试工作。其目的在于检验程序各模块是否存在各种差错，是否能正确地实现了其功能，满足其性能和接口要求。

(2)集成测试：又叫组装测试或联合，是单元测试的多级扩展，是在单元测试的基础上进行的一种有序测试。

旨在检验软件单元之间的接口关系，以期望通过测试发现各软件单元接口之间存在的问题，最终把经过测试的单元组成符合设计要求的软件。

（3）系统测试：是为判断系统是否符合要求而对集成的软、硬件系统进行的测试活动、它是将已经集成好的软件系统，作为基于整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、人员、数据等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。

在系统测试中，对于具体的测试类型有：

（1）功能测试：对软件需求规格说明书中的功能需求逐项进行的测试，以验证功能是否满足要求。

（2）性能测试：对软件需求规格说明书的功能需求逐项进行的测试，以验证功能是否满足要求。

（3）接口测试：对软件需求规格说明中的接口需求逐项进行的测试。

（4）人机交互界面测试：对所有人机交互界面提供的操作和显示界面进行的测试，以检验是否满足用户的需求。

（5）强度测试：强制软件运行在异常乃至发生故障的情况下（设计的极限状态到超出极限），验证软件可以运行到何种程序的测试。

（6）余量测试：对软件是否达到规格说明中要求的余量的测试。

（7）安全性测试：检验软件中已存在的安全性、安全保密性措施是否有效的测试，。

（8）可靠性测试：在真实的或仿真的环境中，为做出软件可靠性估计而对软件进行的功能（其输入覆盖和环境覆盖一般大于普通的功能测试）。

（9）恢复性测试：对有恢复或重置功能的软件的每一类导致恢复或重置的情况，逐一进行的测试。

（10）边界测试：对软件处在边界或端点情况下运行状态的测试。

（11）数据处理测试：对完成专门数据处理功能所进行的测试。

（12）安装性测试：对安装过程是否符合安装规程的测试，以发现安装过程中的错误。

（13）容量测试：检验软件的能力最高能达到什么程度的测试。

（14）互操作性测试：为验证不同软件之间的互操作能力而进行的测试。

（15）敏感性测试：为发现在有效输入类中可能引起某种不稳定性或不正常处理的某些数据的组合而进行的测试。

（16）标准符合性测试：验证软件与相关国家标准或规范（如军用标准、国家标准、行业标准及国际标准）一致性的测试。

（17）兼容性测试：验证软件在规定条件下与若干个实体共同使用或实现数据格式转换时能满足有关要求能力的测试。

（18）中文本地化测试：验证软件在不降低原有能力的条件下，处理中文能力的测试。

4、从执行过程是否需要人工干预来看

（1）手工测试：就是测试人员按照事先为覆盖被测软件需求而编写的测试用例，根据测试大纲中所描述的测试步骤和方法，手工地一个一个地输入执行，包括与被测软件进行交互（如输入测试数据、记录测试结果等），然后观察测试结果，看被测程序是否存在问题，或在执行过程中是否会有一场发生，属于比较原始但是必须执行的一个步骤。

（2）自动化测试：实际上是将大量的重复性的测试工作交给计算机去完成，通常是使用自动化测试工具来模拟手动测试步骤，执行用某种程序设计语言编写的过程（全自动测试就是指在自动测试过程中，不需要人工干预，由程序自动完成测试的全过程；半自动测试就是指在自动测试过程中，需要手动输入测试用例或选择测试路径，再由自动测试程序按照人工指定的要求完成自动测试）。

5、从测试实施组织看

（1）开发测试：开发人员进行的测试

（2）用户测试：用户方进行的测试

（3）第三方测试：有别于开发人员或用户进行的测试，由专业的第三方承担的测试，目的是为了保证测试工作的客观性。

6、从测试所处的环境看

（1）阿尔法测试：是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。

（2）贝塔测试：是用户公司组织各方面的典型终端用户在日常工作中实际使用贝塔版本，并要求用户报告。

软件测试的内容：

1得到需求、功能设计、内部设计说书和其他必要的文档。

2得到预算和进度要求

3确定与项目有关的人员和他们的责任、对报告的要求、所需的标准和过程(例如发行过程、变更过程、等等)。

4确定应用软件的高风险范围，建立优先级、确定测试所涉及的范围和限制。

5确定测试的步骤和方法──部件、集成、功能、系统、负载、可用性等各种测试。

6确定对测试环境的要求(硬件、软件、通信等)。

7确定所需的测试用具(testware)，包括记录/回放工具、覆盖分析、测试跟踪、问题/错误跟踪、等等。

8确定对测试的输入数据的要求

9分配任务和任务负责人，以及所需的劳动力

10设立大致的时间表、期限、和里程碑

11确定输入环境的类别、边界值分析、错误类别。

12准备测试计划文件和对计划进行必要的回顾。

13准备白盒测试案例

14对测试案例进行必要的回顾/调查/计划

15准备测试环境和测试用具，得到必需的用户手册/参考文件/结构指南/安装指南，建立测试跟踪过程，建立日志和档案、建立或得到测试输入数据。

16得到并安装软件版本

17进行测试

18评估和报告结果

19跟踪问题/错误，并解决它

20如果有必要，重新进行测试

21在整个生命周期里维护和修改测试计划、测试案例、测试环境、和测试用具。