基于模型的测试工作流进行与安全相关的软件开发
开发与安全相关的软件(例如飞机、汽车、火车或医疗设备的相关软件)需要倍加谨慎，还需要付出额外的努力，因为此类软件一旦发生故障，有可能导致人身伤亡。交付遵循严格的开发标准和指导准则(例如 DO-178C、DO-178B、ISO 26262、IEC 61508 或 IEC 62304)的安全代码可能会增加项目所需的时间和成本。本文介绍了如何利用 IBM Rational Rhapsody Kit for ISO 26262 和 IEC 61508 中包含的 Rhapsody 参考工作流，开发与安全相关的应用程序。您将了解 Rhapsody 参考工作流，了解如何利用 Rational Rhapsody TestConductor Add On 的基于模型的测试验证模型和所生成的代码。这样做可以缩短交付高质量软件所需的时间，同时保证符合安全标准。
安全相关软件的挑战
嵌入式软件已经逐渐成为当今创新型产品的核心。对于在我们日常生活中必不可少的产品来说，嵌入式软件是定义其功能，控制其电气和机械系统的重要组件。例如，在飞机、汽车、火车或医疗设备中，故障可能会导致人身伤亡。此时必须倍加谨慎，也需要付出额外的努力，确保系统安全运作，保证用户的安全，避免代价高昂的产品召回。
对于极度注重安全的代码，企业必须遵循严格的开发标准和指导准则，例如针对商业航空电子设备的 DO-178C 和 DO-178B;针对汽车的 ISO 26262;针对医疗设备的 IEC 62304;以及针对一般功能安全要求的 IEC 61508。各公司须负责提供其采用良好开发流程的证据，例如从需求到实现的跟踪能力，充分的测试，以及其工具不会造成产品中存在错误。此外还必须抽出额外的时间、执行额外的测试，以确认软件符合安全要求，而这一切都会显著增加开发时间和成本。
回页首利用基于模型测试的自动化测试
利用基于模型的测试，您可以通过图形化的方式捕获测试用例。这有益于创建更易于理解、富有表现力的测试用例，简化整个开发团队内的沟通。测试用例可跟踪需求，从而轻松理解需求变化的影响。IBM® Rational® Rhapsody® TestConductor Add On 为 Rational Rhapsody Developer、Rational Rhapsody Designer for Systems Engineers 或 Rational Rhapsody Architect for Software 版本添加了以 UML 测试配置文件为基础的基于模型的测试功能(请参见 参考资料 部分中的产品概述和评估页面的链接)。测试配置文件在 UML 中添加了测试架构和测试行为的概念，以便根据测试量身定制开发环境。测试架构扩展了现有 UML 2.0 结构概念，以便描述相关测试元素及其之间的关系。类似地，测试行为扩展了现有 UML 2.0 的行为概念，以便包含测试过程中的所有观察结果和活动。
Rhapsody TestConductor Add On 可自动为正在测试的系统创建测试架构。用户可以使用 UML 顺序图、状态图或流程图，以图形的方式创建测试用例。测试用例的图形化表示允许更好地测试进行沟通，有助于理解设计的行为。用户可以执行测试并检视结果，以便自动化单元测试和回归测试。通过在开发流程早期的设计模型阶段执行测试，质量保障经理和软件工程师可以高效地、有效地对设计进行需求验证，尽快识别出问题。
回页首基于模型的测试在安全相关开发中的优势
安全相关软件必须具备从需求到软件架构再到代码的完整可跟踪能力。除此之外，还必须具备从需求到针对所开发软件检查需求正确性测试用例的跟踪能力。实现元素(例如测试架构、测试案例)以及模型级别的概念允许在模型级别上直接实现双向跟踪能力。这支持自动分析模型和代码的需求覆盖率以及结构覆盖率。除此之外，如果使用 UML 顺序图、状态机等标注法以图形的方式指定测试用例，验证将比传统以代码为中心的测试用例更加轻松有效。基于模型的方法允许在统一的框架内开发设计工件和测试工件。因此，该方法能够提高开发和测试流程的敏捷性，与具有独立开发和测试阶段的流程相比，效率更高、成本更低。IBM Rational Rhapsody TestConductor Add On 可自动化许多测试活动，包括创建测试架构和执行测试用例。因此，测试人员可以专注于其测试用例的正确性和完整性，不必花时间去处理繁琐的、易于出错的任务，例如创建测试装置。与传统测试脚本语言相比，模型驱动的测试架构和测试用例有着图形化的特点和明确的文档，因此更易于维护。
回页首采用基于模型的测试的参考工作流概述
Rational Rhapsody 参考工作流(请参见 参考资料 部分)描述了一种基于模型的开发方法，包括适用于安全相关软件开发的自动代码生成和基于模型的测试。图 1 展示了该参考工作流中的主要活动。工作流的上半部分描述了设计和实现安全相关软件的活动。工作流的下半部分描述了验证软件的活动。
该方法同时解决了设计和实现，同时还提供了恰当的测试和验证。使用文本形式表示的需求来指导正式 UML/SysML 模型的开发，这些模型随后将使用代码生成转化为代码。完善步骤均附带恰当的指南和检查。
从文本需求到可用于代码生成的设计模型的完善步骤将通过执行基于与系统需求的模型级测试加以验证，此验证过程将利用 IBM Rational Rhapsody 动画通过模型模拟完成。这种测试也称为模型在环(Model-in-the-Loop，MiL)测试。生成的代码可在计算机上验证，方法是执行 MiL 过程中的相同测试用例，但不包含 Rational Rhapsody 动画。这种测试也称为软件在环(Software-in-the-Loop，SiL)测试。MiL 与 SiL 的测试结果将执行自动等效检查(对比测试)，以验证结果。此外，还可在目标处理器上执行一组测试来补充此类验证，这种测试称为处理器在环(Processor-in-the-Loop，PiL)测试。模型和代码的测试执行提供了结构化的覆盖率度量，可评估测试的完整性，避免包含不必要的功能。需求覆盖率是在测试用例的执行过程中度量的。
图 1. IBM Rational Rhapsody Reference 工作流的活动
工作流中的第一项活动是利用恰当的建模指导原则，将给定需求转化为可执行模型。随后，添加基于模型的测试，确保模型确实正确地捕获了需求。覆盖率测试(需求覆盖率和模型覆盖率)可度量基于模型的测试套件的完整性。代码生成用于通过模型生成实现。模型与代码间的对比测试或等效性测试是代码验证的关键要素。在两个级别同时运行测试可验证模型和代码是否表现出相同的行为。代码覆盖率指标用于根据预定义的代码覆盖率标准确保测试套件的完整性。
使用基于模型的测试执行 ISO 26262 验证活动的示例
ISO 26262-6 提出了许多推荐或是高度推荐的开发和测试活动执行方法。举例来说，表 1 列出了 ISO 26262-6 推荐的软件单元测试方法。根据 ISO 26262 A 到 ISO 26262 D 对项目的汽车安全整合等级 (ASIL) 提出的要求(其中 D 表示关键性高的等级)，您需要使用表 1 中的部分或全部方法来实现合规性。这些方法包括基于需求的测试、接口测试、错误注入测试、资源使用测试和背对背的对比测试。
表 1. 表 1. ISO 26262-6 推荐的汽车安全整合等级 (ASIL) 单元测试方法
ASIL A 到 ASIL D 高度推荐执行基于需求的测试。换句话说，基于需求的测试是必备的。因此，基于需求的测试也是 Rational Rhapsody 参考工作流中的一项重要验证活动。
图 2. 通过 Rational Rhapsody TestConductor Add On 执行基于需求的测试
在基于需求的测试过程中，您需要系统性地验证所测试的系统 (SUT) 的行为是否与为该系统定义的需求中指定的行为相符。对于每项需求，必须定义一个或多个测试用例，以便检查 SUT 的行为。IBM Rational Rhapsody 提供了四种不同的方法来执行测试用例的行为：顺序图、状态图、活动图和纯文本代码。根据要检查的需求不同，这些方法中的某种方法可能比其他方法更为适用。举例来说，假设 SUT 是一款某个型号的码表。码表有这样一项需求：
“REQ_INIT:After starting the stopwatch， the stopwatch shall display 0 minutes and 0 seconds (0:0)"(启动码表后，码表应显示 0 分 0 秒 (0:0))。
为使用 IBM Rational Rhapsody 验证和测试此需求，您可以创建如图 3 所示的顺序图测试。首先，将此输入发送给 SUT：
evPressKey(KeyVal=1)
此输入表示码表已经启动。对于预期的反应，顺序图指定 SUT 应发出此事件：
evShow(m=0，s=0，b=FALSE)
表示码表应显示时间 0:0。
图 3. 使用顺序图定义测试用例的行为
定义测试用例的行为后，下一步是将测试用例与要测试的需求相联系，方法是向指向需求的测试用例添加一个 TestObjective 。测试目标显式地将测试用例与需求相联系(如图 4 所示)，以实现需求与测试用例之间的可跟踪能力。
图 4. 利用 TestObjective 元素将测试用例与需求相联系
定义测试用例并将其与需求相联系之后，下一步是执行测试用例、计算测试结果(如图 5 所示)。测试执行报告包含有关测试执行的信息，例如测试执行时间和测试结果。
图 5. 测试执行窗口(左下角)和测试报告(右侧)。
必须通过相同的方式为所有需求开发测试用例。此过程迭代执行，直至所有需求均已被恰当的测试用例所覆盖为止。
ISO 26262-6 还要求确定需求的测试覆盖率，以评估需求是否得到了全面的测试。评估哪项需求被哪些测试用例所覆盖(以及反方向的评估)正是 Rhapsody Reference 工作流描述的另一项活动，如图 6 所示。
图 6. 评估测试用例的需求覆盖率
Rational Rhapsody 提供了多种机制，用以评估实际需求覆盖率。图 7 展示了如何利用 测试需求矩阵 自动可视化需求与测试用例之间的关系。需求在纵轴显示，测试用例在横轴显示。如果测试用例通过某个测试目标与需求相关联，那么矩阵的交叉点处会显示一个黄色的测试目标符号。观察测试需求矩阵，您可以看到哪个测试用例覆盖了哪项需求，还可以看出哪项需求未被测试用例所覆盖。图中的这个矩阵表明，已经为所有需求定义了测试用例，而且所有这些测试用例均已成功执行。
图 7. 显示测试用例的完整需求覆盖率以及测试执行结果的表格
如您所见，Rational Rhapsody 参考工作流的开发和验证活动直接对应于 ISO 26262 流程的推荐方法和活动。本文介绍了基于需求的测试活动和测试需求覆盖率的对应情况。参考工作流中的其他活动同样对应于 ISO 26262 活动，比如对比测试和结构覆盖率度量。Rational Rhapsody 工具提供了类似的支持和自动化功能，可帮助您高效利用这些功能。
您也可以为其他标准定义类似的对应 Rational Rhapsody 参考工作流开发和验证活动，比如 DO-178B、DO-178C、IEC 61508 或 IEC 62304。
回页首结束语
交付安全的系统要求采用严格的流程，还要付出大量时间来确认设计确实能够满足需求。利用 Rational Rhapsody Reference 工作流，您可以自动开发必须符合安全标准的设计。
参考工作流提供了加快极其注重安全的系统开发速度的部分优势：
有关如何执行 ISO 26262 和 IEC 61508 推荐的部分活动的具体指南也适用于其他标准。需求可跟踪性有助于确保设计满足需求，还有助于理解需求变化带来的影响。Rational Rhapsody 工具使您能在项目开展过程中有效执行这些活动，大限度地提升产品质量和安全性。Rational Rhapsody 和 Rational Rhapsody TestConductor Add On 提供的高度自动化使您能在给定的时间和预算限制内实现质量目标
