执行可用性测试的关键步骤的最佳方法是什么？一位专家介绍了器械制造商如何了解用户需求，生成可用性要求，并进行必要的评估。
在许多机构中，迭代可用性测试和成熟的产品设计已成为广泛应用的概念，甚至到了被视为赘述的程度。消费品行业将其视为一种竞争优势，受监管产品的制造商在产品开发过程中所面临的人为因素原则合规性压力越来越大。例如，FDA要求众多医疗器械制造商在产品营
销过程中展示产品的安全性和可用性特性。这些特性都是通过模拟使用和传统的可用性测试来完成的。
然而，产品开发团队和管理人员仍然心存顾虑，例如以用户为中心的活动所需的时间和人力资源，以及评估错误及其影响的最佳方法。产品经理想知道要测试什么，要执行多少次迭代，以及如何确认形成性研究已经完成。为便于规划，同时让整个团队更好地了解和利用可用性测试的结果，需要对“完成”的定义达成一致。
可用性要求的生成和测试为团队提供了可用性结果的评估标准，以判定设计是否足以满足要求，并确保对潜在的错误做出调查和评估。
图1总结了从初始用户需求到最终设计输入的可用性要求的生命周期。红色概述的活动是迭代的。随着可用性数据的收集，需求可能会被精简，其他的错误也会被进一步评估。然后将uFMEA产生的缓解转化为设计输入。
图1.产品开发过程中的可用性要求流程图。
通过使用案例研究，本文将从可用性需求和目标的定义和示例开始，进而讨论用于形成使用功能和可测试需求的活动描述，要求如何驱动测试场景，以及最终它们如何定义用于迭代测试和设计决策的设计控制。
案例
以概念性血压监测系统为例。该系统的主要组件是智能手机应用程序，允许患者通过血压计实时监测，检测低血压或高血压病症，记录活动和相关信息，并将信息发送到诊所。
用户需求
关于用户需求的简要描述。在任何一个行业中，所有产品都是为满足（非常）有限的需求而设计的。这些需求必须无需解决方案，并描述最终用户的预期目标。根据这个定义，对所有医疗器械，我提出了以下的需求。
用户需求1至4与临床结果本身有关。
1. 不会对自身、另一方或患者造成伤害。
2. 准确监测和诊断
3. 维持或改善预期的患者状况。
4. 确定先前规定的治疗的疗效和/或依从性。
用户需求5和6涉及具体疾病的个人需求。
5. 治疗应是独立的，不会对患者隐私造成影响。
6. 治疗应及时进行，以最大限度地提高治疗效果。
功能分析
无需解决方案的下一步是确定用户必须做什么来满足这些需求。这些功能通常用解决方案来定义。即如图1所示，所选择的技术可以推动功能的形成。例如，如果使用手机应用程序，则用户便应根据需要对手机电池进行维护和充电。对于智能手机应用的血压监测，确定了以下功能：
1) 必须根据使用情况不定期地对电池充电。
2) 应用程序设置。系统软件必须根据个体患者的需要量身定做。这是通过软件设置完成的。
3) 日志事件。虽然在使用方面，该系统不是至关重要的，但患者用户可以将重要事件记录到应用程序中。
可用性要求
基于功能分析和用户功能组合，生成一组系统可用性要求或目标。必须对这些要求进行说明，使其具备可测试性。有关的更多信息，请查看美国可用性要求生成标准。为了达到既定的可用性目标，在首次尝试时，所有经过充分培训的用户必须满足每项要求，必要时可借助使用说明书。如有需要，应对任何观察到的误差进行分析，以确定设计缓解的性质。本小节包含了待验证的可用性要求。它们按照其各自的功能进行组织。用户必须能够：
1) 监控电池并充电。
- 适当的用户必须能够确定当前的电池强度。
- 电池电量耗尽时，用户必须能够识别电池何时需要充电。
- 适当的用户必须能够在电池电量将耗尽时对电池充电。
2) 应用程序设置。系统软件必须根据个体患者的需要量身定做。
- 适当的用户必须能够在智能手机上找到并上传应用程序。
- 适当的用户必须能够自定义应用程序是否显示血压计。
- 适当的用户必须能够在设备设置过程中按规定验证收缩压和舒张压时间。
- 适当的用户必须能够按照提示输入校正的血压值。
3) 日志事件。患者用户必须能够输入关于特定压力读数的相关信息到应用程序中。这些事件可能是：
- 适当的用户必须能够按指示输入压力事件。
- 适当的用户必须能够按照指示输入运动事件。
- 适当的用户必须能够按照指示进行整体健康评估。
任务和人为失效分析与测试场景
所识别的可用性要求可以用作面向目标分层的任务分析中的使用目标。对实现目标所需的离散任务和子任务进行评估。然后将此详尽的任务分析用作使用错误分析的基础。图2说明了这一分析的一部分。再次重申，这是一个出于说明目的的不完整分析。此处是人为失效评估过程的详细描述。
图2.部分人为失效分析
一旦任务和人为失效分析完成，设计团队就可以制定可用性测试场景来验证需求。如果存在使用困难，任务和子任务可用作评估测试性能的指南。
可用性vs 安全性
大多数行业如大众消费电子产品，将进行更为正式的需求验证测试，作为形成性研究。通过添加成功标准将每个要求转换为可用性目标。例如，这样的标准可能是90％的测试用户成功执行了与需求相关的任务。如果达到这个水平，那么即达到可用性目标，并且设计将正式化。如果没有达成目标，则会重复并重新测试该设计（如有需要），直到达到可用性目标。
在规范医疗器械开发的情况下，唯一的标准可以是100％的成功率。虽然需求可以驱动情景开发和后续测试，任何错误的原因和潜在风险都必须评估。也就是说，这个要求逐渐将不再是可用性目标，而是更多用于测试场景生成和用户绩效后续评估的指南。然而，可用性目标验证和使用错误测试都可以同时进行。