開發與安全相關的軟件(例如飛機、汽車、火車或醫療設備的相關軟件)需要倍加謹慎,還需要付出額外的努力,因為此類軟件一旦發生故障,就有可能導致人身傷亡。交付遵循嚴格的開發標準和指導準則(例如 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 順序圖、狀態機等標注法以圖形的方式指定測試用例,驗證將比傳統以代碼為中心的測試用例更加輕松有效?;谀P偷姆椒ㄔ试S在統一的框架內開發設計工件和測試工件。因此,該方法能夠提高開發和測試流程的敏捷性,與具有獨立開發和測試階段的流程相比,效率更高、成本更低。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