系统测试用例中一个重要类别，是专门用于发现人为因素（或称可用性）问题的测试。在本书第一版出版时，计算机行业大多忽视了与计算机软件相关的人为因素问题。开发者很少关注人类是如何与他们的软件进行交互的。但这并非意味着当时没有开发者在用户层面测试应用程序。早在 20 世纪 80 年代初，包括施乐帕洛阿尔托研究中心（PARC）的开发者在内，就已经有部分人员在开展基于用户的软件测试工作。
到了 1987 或 1988 年，我们三人都深度参与到早期个人计算机软硬件的可用性测试中。我们与计算机制造商签订合同，在新台式电脑面向公众发布前对其进行测试和评审。在大约两年的时间里，这种预发布测试成功避免了新软硬件设计中潜在的可用性问题。显然，这些早期的计算机制造商都深信，投入这种级别的用户测试所耗费的时间与成本，最终会带来实实在在的市场优势和经济效益。

可用性测试基础
如今的软件系统——尤其是面向大众商业市场的软件——普遍经过了大量人为因素研究，现代程序也无疑受益于此前成千上万的程序与系统积累。尽管如此，人为因素分析仍然是极具主观性的工作。以下是我们整理的一份问题清单，可用于推导测试关注点：

  1. 每个用户界面是否都针对最终用户的知识水平、教育背景和使用环境压力做了定制化设计？
  2. 程序的输出是否有意义、不冒犯用户，且避免了计算机术语堆砌？
  3. 错误诊断信息（如报错提示）是否直白易懂？还是需要用户拥有计算机科学博士学位才能理解？例如，程序是否会输出类似 IEK022A OPEN ERROR ON FILE 'SYSIN' ABEND CODE=102 这样的信息？这类信息在20世纪70-80年代的软件系统中并不罕见。如今面向大众市场的系统在这方面已有改善，但用户仍会遇到“发生未知错误”“程序遇到错误，必须重启”这类毫无帮助的提示。
    你自己设计的程序完全可以避免这类无用提示。即便你并非程序设计者，只要身处测试团队，也可以推动人机交互领域的改进。
  4. 所有用户界面是否在概念上保持高度一致，在语法、约定、语义、格式、风格和缩写上具备底层连贯性与统一性？
  5. 在对准确性要求极高的场景（如网上银行系统）中，输入环节是否设置了足够的冗余验证？例如，这类系统应要求用户同时提供账号、客户姓名和个人识别码（PIN），以确认访问账户信息的是本人。
  6. 系统是否包含过多选项，或极少被使用的冗余选项？现代软件的一个趋势是：基于测试与设计考量，仅向用户展示他们最可能使用的菜单选项；设计精良的程序还能学习用户习惯，逐步展示其高频访问的菜单项。即便采用这类智能菜单系统，成功的软件仍需保证各类选项的访问逻辑直观易懂。
  7. 系统是否会对所有输入做出某种即时反馈？例如，鼠标点击时，选中项可变色，或按钮呈现按下/弹起状态；若用户需从列表中选择，选择完成后应在屏幕上显示选中项编号。此外，若所选操作需要一定处理时间（尤其是软件访问远程系统时），应显示提示信息告知用户当前进度。这类测试有时被称为组件测试，即验证交互式软件组件的合理选择与用户反馈机制。
  8. 程序是否易于使用？例如，输入是否区分大小写却未向用户明确说明？若程序需要通过多级菜单或选项导航，是否清晰标注了返回主菜单的路径？用户能否轻松在层级间上下切换？
  9. 设计是否有助于提升用户操作准确性？可通过分析用户在数据输入或选择程序选项时的错误次数来验证：这些错误是否只是用户可自行纠正的小麻烦？还是错误选择或操作会导致应用程序故障？
  10. 用户操作是否便于在后续会话中重复执行？换句话说，软件设计是否有助于用户学习更高效地使用系统？
  11. 用户在浏览各类路径或菜单选项时是否感到自信？可通过用户对应用的主观反馈来评估：会话结束时，用户是感到压力还是满意？是否愿意自己使用该系统，或向他人推荐？
  12. 软件是否兑现了设计承诺？最后，可用性测试应包含软件规格与实际运行效果的对比评估：从用户视角（真实用户在真实环境中使用软件）来看，软件是否按规格正常运行？

可用性（或基于用户的）测试本质上是一种黑盒测试技术。回顾第2章的讨论，黑盒测试专注于发现程序未按规格运行的场景，无需关注软件内部实现或程序结构。从这个角度看，可用性测试无疑是任何开发流程的重要环节。若因设计不当、界面繁琐或规格遗漏，导致用户认为应用未按预期运行，那么整个开发流程就是失败的。用户测试应能发现从设计缺陷到软件工效学错误的各类问题。

可用性测试流程
从上述测试项不难看出，可用性测试绝非简单收集用户对软件的意见或宏观反应。当错误被修复、应用准备发布或销售时，可通过焦点小组收集用户或潜在购买者的意见——这属于市场调研与用户定位范畴。而可用性测试发生在流程更早阶段，且涉及更深入的工作。

任何可用性测试都应从制定计划开始（可参考第2章表2.1的关键软件测试指南）。需为每位用户设计实用、可复现、贴近真实场景的测试任务，测试场景应覆盖软件的所有功能模块，顺序可随机安排。例如，在客户跟踪应用中，可测试以下流程：

  • 定位并修改单个客户记录
  • 定位并修改公司记录
  • 创建新公司记录
  • 删除公司记录
  • 生成某类公司的列表
  • 打印该列表
  • 将选定联系人列表导出为文本文件或电子表格格式
  • 从其他应用导入联系人文本文件或电子表格文件
  • 为一条或多条记录添加照片
  • 创建并保存自定义报表
  • 自定义菜单结构

测试各阶段需安排观察员记录用户完成任务的过程；测试结束后，通过访谈或书面问卷收集用户对使用体验、规格匹配度等方面的反馈。

此外，需为用户测试编写详细说明，确保每位用户接收的初始信息和呈现方式完全一致，否则不同用户收到的不同指令可能影响测试结果的客观性。

测试用户选择
完整的可用性测试方案通常包含同一用户的多次测试和多用户参与测试。为何要让同一用户多次测试？我们需要测试用户的记忆留存度——即用户对软件操作的学习内容能在会话间保留多少。新系统首次向用户展示时，必然需要学习时间，但如果应用设计与目标用户群体熟悉的行业或技术规范保持一致，学习过程会相对高效。

例如，熟悉计算机辅助工程设计的用户，会预期同行业新软件遵循特定的术语、菜单设计，甚至颜色、阴影和字体规范。开发者可能为优化操作刻意偏离这些规范，但过度偏离行业标准与预期会延长用户学习周期，甚至导致用户接受度过低，使应用沦为商业失败品。若应用为单一客户开发，这类偏差可能导致客户拒绝设计，或要求全面重制用户界面——无论哪种结果，都是开发者的昂贵失误。

因此，面向特定终端用户类型或行业的软件，应由专家用户测试（即已在真实环境中熟悉此类应用的人群）；而面向更广泛市场的软件（如移动设备软件、通用网页），则更适合随机选择用户测试（这类测试有时被称为走廊测试，即从路过走廊的人群中随机挑选测试者）。

需要多少名测试用户？
制定可用性测试计划时，“需要多少名测试者？”是核心问题。可用性测试人员的雇佣常被开发流程忽视，可能给项目带来意外的高额成本。需找到能以最低资金投入发现最多错误的测试人数。

直觉上，你可能认为测试者越多越好——毕竟足够多的评估者能发现所有错误。但首先，这成本高昂；其次，会造成后勤管理的噩梦；最后，几乎不可能检测到应用100%的可用性问题。

幸运的是，过去15年间可用性领域已有大量研究。根据可用性测试专家雅各布·尼尔森（Jakob Nielsen）的研究，所需测试者数量可能比你想象的更少。尼尔森的研究发现，测试中发现的可用性问题数量符合以下公式：
$$E = 100 \times (1 - (1-L)^n)$$
其中：

  • $E$ = 发现的错误百分比
  • $n$ = 测试者数量
  • $L$ = 单个测试者发现的可用性问题百分比

若取尼尔森研究中得出的合理值 $L=31%$，可得到图7.1所示的曲线。

从图中可得出几个有趣结论：

  1. 正如直觉判断，永远不可能检测到应用的所有可用性错误——理论上曲线仅趋近于100%，永远无法达到。
  2. 仅需少量测试者：仅5名测试者即可发现约83%的错误。

对项目经理而言，这是令人振奋的消息：无需再为大量测试者承担成本与管理复杂度，可将精力与资金投入到测试设计、执行与分析中——聚焦于能产生最大价值的环节。

更少的测试者也意味着更少的分析工作，可快速实施应用与测试方法的改进，再组织新一批测试者重复测试。通过这种迭代方式，能以最低成本和时间发现大部分问题。

尼尔森的研究完成于20世纪90年代初，当时他在太阳微系统公司（Sun Microsystems）担任系统分析师。一方面，他的数据与可用性测试方法为软件设计从业者提供了具体指导；另一方面，随着可用性测试的重要性日益提升、实践测试积累更多证据、公式分析更完善，部分研究者开始质疑尼尔森“3-5名测试者足够”的绝对论断。

尼尔森本人也提醒，测试者的精确数量取决于经济因素（预算能支持多少测试者）和测试系统的类型：关键系统（如导航应用、银行或其他金融软件、安全相关程序）必然需要比非关键软件更严格的用户审查。

对设计可用性测试方案的开发者而言，需考虑：测试用户数量及各自背景是否能充分代表潜在用户总体；部分程序复杂度更高，意味着发现更高比例错误的难度更大；不同用户因背景与经验差异，可能发现不同类型的错误——特定测试场景下可能需要更多测试者。

与任何测试方法一样，最终需由开发者和项目管理者设计测试、制定合理预算、评估中期结果，并根据软件系统、整体项目和客户需求开展回归测试。

数据收集方法
测试管理者或观察员可通过多种方式收集测试结果：

  • 录像+出声思考协议：为用户测试录像，并采用出声思考协议（用户在执行测试任务时大声说出自己的想法与观察），能提供关于软件可用性和用户感知的优质数据。测试参与者需口头描述任务、对任务的思考，以及测试过程中想到的任何内容。即便采用出声思考协议，开发者也可能需要在测试后跟进参与者，获取测试后的评论、感受与观察——这两层用户反馈能为软件修正或改进提供宝贵信息。
  • 远程用户测试：出声思考协议的缺点在于，录像或观察员的存在可能让用户处于不自然环境，影响体验。开发者也可选择远程用户测试，即将应用安装在测试用户的工作环境（即软件最终应用场景）中。远程测试的优势是让用户处于熟悉环境，消除外部因素对测试结果的干扰；缺点是可能无法获得出声思考协议那样详细的反馈。

即便在远程测试环境中，仍可收集准确的用户数据：可在待测试应用中附加软件，记录用户按键操作和完成每项任务的耗时。这需要额外开发时间（及更多软件），但测试结果能提供详尽且有价值的洞察。

若没有计时或按键记录软件，可要求测试用户记录每项任务的起止时间，并在过程中添加简短的单字或短语评论；测试后通过问卷或访谈帮助用户回忆对软件的想法与意见。

  • 眼动追踪：一种复杂但潜在有用的数据收集协议是眼动追踪。人类阅读印刷页面、查看图形演示或与电脑屏幕交互时，眼睛会以特定模式移动。超过100年的眼动研究数据表明，眼动（尤其是观察者在特定视觉元素上的停留时长）至少在一定程度上反映了其思维过程。通过视频系统和其他技术追踪眼动，可向研究者展示哪些视觉元素吸引了观察者的注意力、关注顺序及时长——这类数据对评估软件界面的效率极具价值。

尽管20世纪下半叶有大量研究，但眼动研究在特定应用中的最终价值仍存在争议。不过，结合其他用户测试技术，在开发者需要最深层用户输入数据以确保软件最高效率（如武器制导系统、机器人控制系统、车辆控制或其他需要快速准确响应的系统）时，眼动追踪仍是有用的工具。

可用性问卷
与软件测试流程本身一样，可用性问卷需精心设计，以获取测试流程所需信息。尽管可包含一些引导用户自由评论的问题，但总体上应设计能生成可统计、可跨测试者分析的回答问卷，主要分为三类：

  • 是/否回答
  • 对/错回答
  • 同意/不同意量表（通常为1-5分，5代表完全同意，1代表完全不同意）

例如，不要问“你对主菜单系统的看法是什么？”，而应设计一系列1-5分制问题：

  1. 主菜单易于导航。
  2. 能轻松从主菜单找到正确的软件操作。
  3. 界面设计引导我快速找到正确的软件操作选项。
  4. 操作过系统后，我能轻松记住如何重复操作。
  5. 菜单操作未提供足够反馈以验证我的选择。
  6. 主菜单比我使用的其他类似程序更难导航。
  7. 我难以重复之前完成的操作。

建议从正反两个视角重复提问（一个引导负面回答，一个引导正面回答），确保用户理解问题且感知一致。此外，需将用户问卷按测试的软件领域或分配的测试任务分模块。

经验会快速告诉你哪些问题类型利于数据分析，哪些实用性低。可借助统计分析软件捕获和解读数据：若测试用户数量较少，可用性测试结果可能一目了然；也可在电子表格中开发临时分析程序，更好地记录结果；对于面向大量用户进行广泛测试的大型软件系统，统计软件可能发现人工解读无法察觉的趋势。

何时测试才算足够？
如何在可接受预算内，规划覆盖软件所有方面的可用性测试？答案部分取决于被测试系统或单元的复杂度。若预算和时间允许，建议分阶段测试软件（每个模块完成后即测试）——若开发过程中已对单个组件进行测试，最终测试仅需验证各部分的集成运行效果。

此外，可设计组件测试，即测试交互式组件的可用性（需要用户输入并以用户可感知的方式响应的模块）。这类反馈测试有助于提升用户体验、减少操作错误、增强软件一致性。若在用户界面设计阶段已完成此级别的测试，在全面系统测试开始前，就能积累大量重要的测试与运行知识。

需要多少名独立用户测试软件？同样，系统复杂度和初始测试结果应决定数量。例如，若3-5名（或其他合理数量）代表目标市场的用户在从启动界面到任务界面的导航中遇到困难，那么基本可以确定用户界面需要更多设计工作。

一个合理的推论是：若初始测试者均未在任务导航中遇到问题，也未发现任何错误或故障，那么测试样本可能过小——毕竟，复杂度合理的软件系统的可用性测试，真的能零错误、零修改需求吗？回顾第2章表2.1的原则6：检查程序是否未按预期运行只是战斗的一半，另一半是检查程序是否做了它不该做的事。两者存在微妙差异：你可能发现一系列用户确认程序确实做了它该做的事，未发现任何错误，但这是否证明程序没有做任何不该做的事？若初始测试进展过于顺利，或许是时候增加测试了。

我们认为不存在能告诉你“每个用户应测试多少次”“每项测试应迭代多少次”的公式，但相信通过对合理数量测试者和测试结果的仔细分析与理解，能引导你找到“何时测试足够”的答案。

总结
现代软件面临激烈竞争和紧迫工期，任何软件产品的用户测试对成功开发都至关重要。目标软件用户无疑是测试阶段的宝贵资产：专业用户能判断产品是否符合设计目标，通过执行真实任务发现 commission（做了不该做的事）和 omission（没做该做的事）类错误。

根据软件目标市场，开发者也可选择随机用户测试（即不熟悉程序规格、甚至不熟悉目标行业或市场的人群）——这类用户能发现专家用户可能忽略的错误或用户界面问题。正如开发者自身不适合做错误测试者，专家用户因知晓软件“应该如何工作”，可能会避开可能产生问题的操作区域。多年软件开发经验让我们发现一个无法避免的测试真理：开发者测试过数小时的软件，很容易被一名经验不足的用户在短时间内“攻破”——这类用户会尝试用户界面或软件未设计的任务。

同时请记住，成功的用户（或可用性）测试的关键是准确、详细的数据收集与分析。数据收集流程从制定详细的用户说明和任务清单开始，到汇总用户观察或测试后问卷的结果结束。

最后，必须解读测试结果，并由开发者落实数据中指出的软件修改。这可能是一个迭代过程：在完成 identified 的软件修改后，再次邀请同一批测试用户完成类似任务。