面向实时嵌入式医疗系统的自动化测试
By: Amit Shah and Tim Bosch
采用自动化软件进行测试不但能缩短产品上市时间、取得行业竞争优势，还可提高实时嵌入式医疗器械产品的质量水平。 实时嵌入式系统医疗产品通常需要漫长的验证周期，即使是较小规模的研发项目也需要经历长达数月的验证。这对医疗器械制造商而言是很大的负担。导致验证过程如此漫长的原因有很多种，而主要原因则有如下几条： ∙因输入或系统配置改变引起的复杂性。
∙测试所需系统环境或系统设置造成的复杂性。
∙在连接性和互操作性方面需要考虑的大量外部系统。
∙全面验证需要依靠手动测试（例如，功能测试和系统行为测试）。
∙产品本身缺乏对自动化测试的支持（例如，缺少驱动自动化程序脚本或代码所必需的钩子或可调用的应用程序接口 (API) ）。
手动测试不但耗时而且容易出错，因为功能测试和系统测试需要到软件开发后期方能启动。仅依靠手动测试可能会延后缺陷的发现时机，往往会拖延产品上市。无法采用自动化测试还可能造成产品生产和支持方面的延误。 尽管市场上已有多种面向单元和集成测试的、行之有效的自动化测试工具和技术，但大多数医疗器械公司尚未到适合实时嵌入式器械的自动化测试策略。这些公司应充分了解实时嵌入式医疗系统检测面临的种种困难，并检视各种测试策略，以提高质量，缩短验证周期，降低验证成本。
嵌入式系统尽管千差万别，但它们都具有如下共性：
∙专为某些特定功能设计的专用控制逻辑。
∙构成包含电子和机械部件的完整器械的一部分。
∙复杂程度不尽相同，从单一微控制器到多处理器、单元和外设。
∙可选用户界面，需与外部系统连接。
上述特征不同于如台式或企业级系统等通用计算平台，这类平台根据编程的不同可以执行多种功能。然而，一些面向通用计算系统的自动化测试应用同样可用于实时 嵌入式系统。这些应用包括：确定需要实行自动化的测试内容；展示投资收益 (ROI) 以说服管理层作出购置决定；制定自动化测试策略；确定所需测试工具。还包括构建测试框架和解决监管要求。
但是嵌入式系统的测试的确具有特殊挑战，譬如硬件的并行开发和用户界面的可用性限制等。在进行后期系统测试之前，实际硬件尚未开发完成，并行开发硬件要求 使用仿真器和模拟器。对于那些带有用户界面的系统来说，其用户界面也通常采用并行开发模式，仅在后期系统测试阶段方可使用。
正因为存在此类困难，所以需要在软件中嵌入测试钩子，以支持整体自动化测试策略中确定的可测试性要求。这种嵌入式测试代码可以模拟一般需通过用户界面或其 他指令控制触发的操作（按设备上的按钮、确认某个操作、选择设定值等）。可通过可调用测试钩子触发一系列操作，从而构建测试案例。另外，如果目标硬件不存 在，则可通过一套仿真器和
模拟器作为部分自动化测试环境来执行此类测试案例。通过这种方法，在开发早期即可进行软件测试，而无需等到用户界面和硬件关联建 成之后。
自动化测试的优势
自动化测试有助于减少手动测试量、缩短开发进程、降低成本。测试通常被视为软件和系统开发过程中的瓶颈。通过自动化测试，测试小组可以确保软件开发以及整个开发过程达到时间和预算目标的要求。
自动化测试能够提高软件开发流程效率。由于自动化测试不断重复和记录特定步骤序列，因此开发小组可以轻松重现自动化测试案例发现的缺陷。这样，在软件开发早期即可发现缺陷，加快了缺陷解决进程。此外，自动化测试可以在源代码入库之前执行，从而有效防止缺陷进入代码库。
自动化测试同时还可提高测试覆盖率。全面自动化测试可以全天候自动执行，无需值守。这样，测试小组就能集中精力，重点关注产品的关键安全部件或复杂部件。
与手动测试相比，自动化测试可以提高测试的一致性和可重复性。手动测试不但耗时而且
单调，即便是责任心极强的测试员也难免出错。自动化测试重复同一步骤序列、记录每次执行结果，由此确保回归、集成和系统测试的总体准确率。
该过程还为性能测试和压力测试提供了便利，若借助手动模式，则很难或根本无法实施。
早期自动化测试有助于将软件中的问题分离出来，因为在早期开发阶段的测试中通常无硬件可用。早期发现软件问题有利于软硬件的集成。此外，嵌入式测试代码还可用于为生产及现场服务系统测试需求提供支持。
自动化测试的局限
如需将自动化测试结果用作正式检验和验证证据，则必须在实际目标硬件上执行相应自动化测试，以对可能最终发布的软件进行检验。额外的代码可能增加代码库的 复杂程度，并因此构成开发和维护负担。此外，由于测试代码将包含在作为实时嵌入式系统组成部分的最终软件之中，因此必须通过验证，以确保不会对产品的预期 作用造成负面影响。
另一个不足之处在于，作为部分自动化测试环境的仿真器和模拟器可能无法精确再现实际设备的行为，由此可能对应用可用性和系统性能产生错误的判断。这种情况下，应对仿真
器和模拟器相对于实际设备的精确度进行评估。
嵌入式软件的开发过程十分复杂。软件界面和硬件变化是平常之事，这使测试显得尤为困难。具有可扩展性的模块化自动化测试环境能够显著降低此类变化带来的不利影响。然而，这种开发模式却需要细致的设计和持续的维护。
医疗器械 OEM 通常利用独立的测试小组来开发和实施手动测试。自动化测试要求专业的编程技能，而这通常需要进行额外的培训。测试小组可通过如 Perl 之类的编程语言来设计和开发测试案例，具体视自动化测试框架而定。
高效自动化测试策略
为便于阐述高效自动化测试策略，本文以患者监护器为例，说明适用于实时嵌入式医疗器械的测试策略。患者监护器是一种可进行标准生理参数如 ECG 、心率、 SpO2 、 NIBP 和体温检测的便携式外用设备。这种设备可以自动分析患者的波形，若任一参数超出正常范围，则会通过视觉或听觉警报提醒临床医生。
F 首先，设计者需要确定自动化的对象。他们必须考虑自动化测试对系统性能的影响。监
护器通过 LCD 屏显示波形。用于对这种实时信号进行完整性验证的嵌入式测试代码可能人为地增加系统的调度能力和资源负荷。这种情况下，设计者很可能决定不对该功能进行自 动化测试。相反，更为妥当的做法是对那些嵌入式测试代码不会对设备性能造成影响的功能（如设备配置）实施自动化。
自动化测试环境。应用程序接口(API)定义了构成测试案例的一系列步骤。
接下来是设计自动化测试的环境。该环境包括 API 、用于调用 API 并通过执行一系列特定操作构建测试案例的测试框架以及（可能）仿真器和模拟器（参见 图 1 ）。开发小组将 API 加入代码中，用以模拟用户操作（如按设备上的按钮等）。这些 API 在用户界面和控制逻辑代码之间构成另一层，实际上形成可以通过框架调用的交替外部可调用接口。除增加可调用接口之外， API 还可添加记录功能，用以记录输入值和结果、捕获开始和停止时间以及记录其他所需数据等。
此处的框架由用以调用 API 和执行测试案例中定义的操作序列的一整套脚本构成。这些测试案例事先已由测试工程师定义并已经过手动执行。自动化测试环境一旦建立，便可与建成系统集成，以对已生效功能进行常规验证，为软件开发过程中的回归测试和 持续反馈提
供了便利。
不同于通用计算平台上使用的自动化测试工具，适用于实时嵌入式系统的系统级和功能测试工具寥寥无几。这是因为此类工具通常需要兼容在测应用所采用的技术 （即 RTOS ）。因此，构建定制式自动化工具的需求普遍存在。这些工具的开发、测试和认证成本构成自动化测试投资的一部分。
有些第三方产品（如 QualiSystems TestShell 和 National Instruments LabVIEW 等）可以作为测试环境或整个测试策略的组成部分。尽管如此，设计者仍需开发测试脚本，而这些工具的许可成本也是需要考虑的投资要素之一。请记住，可能仍然 需要对这些工具进行认证，以符合监管要求。
投资收益
自动化既需要一笔投资，在正常情况下，也可能带来可观的回报。在病人监护器一例中，相关成本可能包括以下几个方面：
∙自动化测试工具的购置或开发费用。
自动化检测∙对员工进行自动化测试工具和脚本相关培训的费用。
∙根据美国 FDA 的要求，对特定用途的自动化测试工具、模拟器和仿真器进行认证的费用。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议