使用基于模型的测试工作流进行与安全相关的软件开发

　　开发与安全相关的软件(例如飞机、汽车、火车或医疗设备的相关软件)需要倍加谨慎，还需要付出额外的努力，因为此类软件一旦发生故障，就有可能导致人身伤亡。交付遵循严格的开发标准和指导准则(例如 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 工作流的活动

　　工作流中的第一项活动是利用恰当的建模指导原则，将给定需求转化为可执行模型。随后，添加基于模型的测试，确保模型确实正确地捕获了需求。覆盖率测试(需求覆盖率和模型覆盖率)可度量基于模型的测试套件的完整性。代码生成用于通过模型生成实现。模型与代码间的对比测试或等效性测试是代码验证的关键要素。在两个级别同时运行测试可验证模型和代码是否表现出相同的行为。代码覆盖率指标用于根据预定义的代码覆盖率标准确保测试套件的完整性。

原文转自：http://www.ibm.com/developerworks/cn/rational/safety-related-software-development/index.html