虐杀原形1伊丽莎白之死:面向实时嵌入式医疗系统的自动化测试

By: Amit Shah and Tim Bosch

采用自动化软件进行测试不但能缩短产品上市时间、取得行业竞争优势，还可提高实时嵌入式医疗器械产品的质量水平。

实时嵌入式系统医疗产品通常需要漫长的验证周期，即使是较小规模的研发项目也需要经历长达数月的验证。这对医疗器械制造商而言是很大的负担。导致验证过程如此漫长的原因有很多种，而主要原因则有如下几条：

• 因输入或系统配置改变引起的复杂性。
• 测试所需系统环境或系统设置造成的复杂性。
• 在连接性和互操作性方面需要考虑的大量外部系统。
• 全面验证需要依靠手动测试（例如，功能测试和系统行为测试）。
• 产品本身缺乏对自动化测试的支持（例如，缺少驱动自动化程序脚本或代码所必需的钩子或可调用的应用程序接口 (API) ）。

手动测试不但耗时而且容易出错，因为功能测试和系统测试需要到软件开发后期方能启动。仅依靠手动测试可能会延后缺陷的发现时机，往往会拖延产品上市。无法采用自动化测试还可能造成产品生产和支持方面的延误。

尽管市场上已有多种面向单元和集成测试的、行之有效的自动化测试工具和技术，但大多数医疗器械公司尚未找到适合实时嵌入式器械的自动化测试策略。这些公司应充分了解实时嵌入式医疗系统检测面临的种种困难，并检视各种测试策略，以提高质量，缩短验证周期，降低验证成本。

嵌入式系统尽管千差万别，但它们都具有如下共性：

• 专为某些特定功能设计的专用控制逻辑。
• 构成包含电子和机械部件的完整器械的一部分。
• 复杂程度不尽相同，从单一微控制器到多处理器、单元和外设。
• 可选用户界面，需与外部系统连接。

上述特征不同于如台式或企业级系统等通用计算平台，这类平台根据编程的不同可以执行多种功能。然而，一些面向通用计算系统的自动化测试应用同样可用于实时嵌入式系统。这些应用包括：确定需要实行自动化的测试内容；展示投资收益 (ROI)以说服管理层作出购置决定；制定自动化测试策略；确定所需测试工具。还包括构建测试框架和解决监管要求。

但是嵌入式系统的测试的确具有特殊挑战，譬如硬件的并行开发和用户界面的可用性限制等。在进行后期系统测试之前，实际硬件尚未开发完成，并行开发硬件要求使用仿真器和模拟器。对于那些带有用户界面的系统来说，其用户界面也通常采用并行开发模式，仅在后期系统测试阶段方可使用。

正因为存在此类困难，所以需要在软件中嵌入测试钩子，以支持整体自动化测试策略中确定的可测试性要求。这种嵌入式测试代码可以模拟一般需通过用户界面或其他指令控制触发的操作（按设备上的按钮、确认某个操作、选择设定值等）。可通过可调用测试钩子触发一系列操作，从而构建测试案例。另外，如果目标硬件不存在，则可通过一套仿真器和模拟器作为部分自动化测试环境来执行此类测试案例。通过这种方法，在开发早期即可进行软件测试，而无需等到用户界面和硬件关联建成之后。

自动化测试的优势

自动化测试有助于减少手动测试量、缩短开发进程、降低成本。测试通常被视为软件和系统开发过程中的瓶颈。通过自动化测试，测试小组可以确保软件开发以及整个开发过程达到时间和预算目标的要求。

自动化测试能够提高软件开发流程效率。由于自动化测试不断重复和记录特定步骤序列，因此开发小组可以轻松重现自动化测试案例发现的缺陷。这样，在软件开发早期即可发现缺陷，加快了缺陷解决进程。此外，自动化测试可以在源代码入库之前执行，从而有效防止缺陷进入代码库。

自动化测试同时还可提高测试覆盖率。全面自动化测试可以全天候自动执行，无需值守。这样，测试小组就能集中精力，重点关注产品的关键安全部件或复杂部件。

与手动测试相比，自动化测试可以提高测试的一致性和可重复性。手动测试不但耗时而且单调，即便是责任心极强的测试员也难免出错。自动化测试重复同一步骤序列、记录每次执行结果，由此确保回归、集成和系统测试的总体准确率。

该过程还为性能测试和压力测试提供了便利，若借助手动模式，则很难或根本无法实施。

早期自动化测试有助于将软件中的问题分离出来，因为在早期开发阶段的测试中通常无硬件可用。早期发现软件问题有利于软硬件的集成。此外，嵌入式测试代码还可用于为生产及现场服务系统测试需求提供支持。

自动化测试的局限

如需将自动化测试结果用作正式检验和验证证据，则必须在实际目标硬件上执行相应自动化测试，以对可能最终发布的软件进行检验。额外的代码可能增加代码库的复杂程度，并因此构成开发和维护负担。此外，由于测试代码将包含在作为实时嵌入式系统组成部分的最终软件之中，因此必须通过验证，以确保不会对产品的预期作用造成负面影响。

另一个不足之处在于，作为部分自动化测试环境的仿真器和模拟器可能无法精确再现实际设备的行为，由此可能对应用可用性和系统性能产生错误的判断。这种情况下，应对仿真器和模拟器相对于实际设备的精确度进行评估。

嵌入式软件的开发过程十分复杂。软件界面和硬件变化是平常之事，这使测试显得尤为困难。具有可扩展性的模块化自动化测试环境能够显著降低此类变化带来的不利影响。然而，这种开发模式却需要细致的设计和持续的维护。

医疗器械 OEM 通常利用独立的测试小组来开发和实施手动测试。自动化测试要求专业的编程技能，而这通常需要进行额外的培训。测试小组可通过如 Perl 之类的编程语言来设计和开发测试案例，具体视自动化测试框架而定。

高效自动化测试策略

为便于阐述高效自动化测试策略，本文以患者监护器为例，说明适用于实时嵌入式医疗器械的测试策略。患者监护器是一种可进行标准生理参数如 ECG、心率、 SpO2 、 NIBP和体温检测的便携式外用设备。这种设备可以自动分析患者的波形，若任一参数超出正常范围，则会通过视觉或听觉警报提醒临床医生。

F 首先，设计者需要确定自动化的对象。他们必须考虑自动化测试对系统性能的影响。监护器通过 LCD屏显示波形。用于对这种实时信号进行完整性验证的嵌入式测试代码可能人为地增加系统的调度能力和资源负荷。这种情况下，设计者很可能决定不对该功能进行自动化测试。相反，更为妥当的做法是对那些嵌入式测试代码不会对设备性能造成影响的功能（如设备配置）实施自动化。

接下来是设计自动化测试的环境。该环境包括 API 、用于调用 API并通过执行一系列特定操作构建测试案例的测试框架以及（可能）仿真器和模拟器（参见 图 1 ）。开发小组将 API加入代码中，用以模拟用户操作（如按设备上的按钮等）。这些 API在用户界面和控制逻辑代码之间构成另一层，实际上形成可以通过框架调用的交替外部可调用接口。除增加可调用接口之外， API还可添加记录功能，用以记录输入值和结果、捕获开始和停止时间以及记录其他所需数据等。

此处的框架由用以调用 API 和执行测试案例中定义的操作序列的一整套脚本构成。这些测试案例事先已由测试工程师定义并已经过手动执行。自动化测试环境一旦建立，便可与建成系统集成，以对已生效功能进行常规验证，为软件开发过程中的回归测试和 持续反馈提供了便利。

不同于通用计算平台上使用的自动化测试工具，适用于实时嵌入式系统的系统级和功能测试工具寥寥无几。这是因为此类工具通常需要兼容在测应用所采用的技术（即 RTOS ）。因此，构建定制式自动化工具的需求普遍存在。这些工具的开发、测试和认证成本构成自动化测试投资的一部分。

有些第三方产品（如 QualiSystems TestShell 和 National Instruments LabVIEW等）可以作为测试环境或整个测试策略的组成部分。尽管如此，设计者仍需开发测试脚本，而这些工具的许可成本也是需要考虑的投资要素之一。请记住，可能仍然需要对这些工具进行认证，以符合监管要求。

投资收益

自动化既需要一笔投资，在正常情况下，也可能带来可观的回报。在病人监护器一例中，相关成本可能包括以下几个方面：

• 自动化测试工具的购置或开发费用。
• 对员工进行自动化测试工具和脚本相关培训的费用。
• 根据美国 FDA 的要求，对特定用途的自动化测试工具、模拟器和仿真器进行认证的费用。
• 为自动化测试案例的构建、执行和结果报告提供支持的模块化测试框架的开发费用。
• 应用可测试性的构建和维护费用（即嵌入式测试代码）。
• 自动化测试案例的开发、调试、同行评议和维护费用。

成本的节约程度取决于在功能、回归和系统测试中所减少的手动测试执行时间。此外，自动化测试案例通过无人值守和重复执行可提早发现软件缺陷，由此节省更多成本。行业数据显示，在系统测试阶段发现和修复缺陷所需成本是编码阶段的七倍。 1对于后续投放的产品，如果在开发阶段实施标准化测试，开发初期还可进一步节省成本。

初期投资通常在二次投放中得到偿还，而在之后的后续投放中，成本优势将日渐突显出来。若要获得管理层的支持，进行前期投资收益分析是必不可少的。

遵循监管要求

美国 FDA 制定的《 软件验证一般准则：行业和 FDA 工作人员最终指南》 为医疗器械制造商提供了有关软件检验和验证方面的指导。 ²

A 自动化测试工具验证。 指南第 6.3节（现有软件和自动化设备验证）建议，医疗器械制造商负责对特定用途的现有软件进行验证。该要求适用于自动化测试中使用的所有软件。通过购自第三方供应商的自动化测试工具生成自动化测试案例及可作为产品正式验证证据的测试结果。这种情况下，此类工具需达到预期功能要求，并需验证其特定用途的适用性。应作为验证记录审查、核准和收集的内容包括需求文档、认证程序和认证结果。

注意，如果第三方供应商已对其工具进行过认证，就可以提供自动化测试工具的认证文件。这种情况下，医疗器械制造商可使用该认证文件，作为符合美国 FDA 有关现有软件验证要求的证据。

软件检验和验证计划。 指南第 5.2.1 节（质量规划）建议对检验和验证活动进行规划和记录。作为产品软件检验和验证整体规划的一部分，必须对自动化测试策略及相关活动进行记录、审查和核准。

自动化测试案例和测试结果。 指南第 5.2.5节（由软件开发商实施的测试）称，“需对测试步骤、测试数据和测试结果进行记录，以便能以此为据作出客观的通过 /失败决策。”由于通过脚本语言创建自动化测试案例的行为属于开发范畴，因而需要采用与应用程序代码开发相似的流程和标准。自动化测试代码须采用源代码控制、适当加注、同行评议（包括质量及对预设编码标准的遵循情况）和核准一体化模式。自动化测试案例执行后产生的测试结果若要用作产品的正式验证证据，则必须经过审查和核准。

结论

自动化软件测试并非放之四海而皆准的真理。这种模式需要一定的前期投入和适当的努力，才能确保其适用性。否则，采用自动化模式不仅代价高昂，而且可能收效甚微。在了解自动化的优势的基础上，确立期望值并向管理层提交充分的项目支持数据就显得非常重要，只有这样他们才能进行相应的规划。

自动化软件测试程序需要采用结构化实施模式。这就要求针对某种产品及相关监管要求而专门制定测试策略。同时还要求设计者创建或选择合适的自动化测试工具，要求测试环境采用自动化测试框架和相应的仿真器和模拟器。

只要遵循本文所列原则，医疗器械公司即可实现自动化软件测试带来的可观回报，不但能缩短产品上市时间、取得行业竞争优势，还可提高实时嵌入式医疗器械产品的质量水平。

Amit Shah 是 Foliage 公司的测试工程经理，可通过电邮与他联系： ashah@foliage.com 。

Tim Bosch 是 Foliage 公司医疗器械部的首席设计师，他的电邮是： tbosch@foliage.com 。

参考文献

1. Case Study: Finding Defect Earlier Yields Enormous Savings,[online] (Dulles, VA: Cigital [cited 8 July 2008]); available fromInternet: www.cigital.com/solutions/roi-cs2.php.

2. “General Principles of Software Validation; Final Guidance forIndustry and FDA Staff,” (Rockville MD: FDA) January 11, 2002.