使用基于模型的測試工作流進(jìn)行與安全相關(guān)的軟件開(kāi)發(fā)

　　開(kāi)發(fā)與安全相關(guān)的軟件(例如飛機、汽車(chē)、火車(chē)或醫療設備的相關(guān)軟件)需要倍加謹慎，還需要付出額外的努力，因為此類(lèi)軟件一旦發(fā)生故障，就有可能導致人身傷亡。交付遵循嚴格的開(kāi)發(fā)標準和指導準則(例如 DO-178C、DO-178B、ISO 26262、IEC 61508 或 IEC 62304)的安全代碼可能會(huì )增加項目所需的時(shí)間和成本。本文介紹了如何利用 IBM Rational Rhapsody Kit for ISO 26262 和 IEC 61508 中包含的 Rhapsody 參考工作流，開(kāi)發(fā)與安全相關(guān)的應用程序。您將了解 Rhapsody 參考工作流，了解如何利用 Rational Rhapsody TestConductor Add On 的基于模型的測試驗證模型和所生成的代碼。這樣做可以縮短交付高質(zhì)量軟件所需的時(shí)間，同時(shí)保證符合安全標準。

　　安全相關(guān)軟件的挑戰

　　嵌入式軟件已經(jīng)逐漸成為當今創(chuàng )新型產(chǎn)品的核心。對于在我們日常生活中必不可少的產(chǎn)品來(lái)說(shuō)，嵌入式軟件是定義其功能，控制其電氣和機械系統的重要組件。例如，在飛機、汽車(chē)、火車(chē)或醫療設備中，故障可能會(huì )導致人身傷亡。此時(shí)必須倍加謹慎，也需要付出額外的努力，確保系統安全運作，保證用戶(hù)的安全，避免代價(jià)高昂的產(chǎn)品召回。

　　對于極度注重安全的代碼，企業(yè)必須遵循嚴格的開(kāi)發(fā)標準和指導準則，例如針對商業(yè)航空電子設備的 DO-178C 和 DO-178B;針對汽車(chē)的 ISO 26262;針對醫療設備的 IEC 62304;以及針對一般功能安全要求的 IEC 61508。各公司須負責提供其采用良好開(kāi)發(fā)流程的證據，例如從需求到實(shí)現的跟蹤能力，充分的測試，以及其工具不會(huì )造成產(chǎn)品中存在錯誤。此外還必須抽出額外的時(shí)間、執行額外的測試，以確認軟件符合安全要求，而這一切都會(huì )顯著(zhù)增加開(kāi)發(fā)時(shí)間和成本。

　　回頁(yè)首利用基于模型測試的自動(dòng)化測試

　　利用基于模型的測試，您就可以通過(guò)圖形化的方式捕獲測試用例。這有益于創(chuàng )建更易于理解、富有表現力的測試用例，簡(jiǎn)化整個(gè)開(kāi)發(fā)團隊內的溝通。測試用例可跟蹤需求，從而輕松理解需求變化的影響。IBM® Rational® Rhapsody® TestConductor Add On 為 Rational Rhapsody Developer、Rational Rhapsody Designer for Systems Engineers 或 Rational Rhapsody Architect for Software 版本添加了以 UML 測試配置文件為基礎的基于模型的測試功能(請參見(jiàn) 參考資料 部分中的產(chǎn)品概述和評估頁(yè)面的鏈接)。測試配置文件在 UML 中添加了測試架構和測試行為的概念，以便根據測試量身定制開(kāi)發(fā)環(huán)境。測試架構擴展了現有 UML 2.0 結構概念，以便描述相關(guān)測試元素及其之間的關(guān)系。類(lèi)似地，測試行為擴展了現有 UML 2.0 的行為概念，以便包含測試過(guò)程中的所有觀(guān)察結果和活動(dòng)。

　　Rhapsody TestConductor Add On 可自動(dòng)為正在測試的系統創(chuàng )建測試架構。用戶(hù)可以使用 UML 順序圖、狀態(tài)圖或流程圖，以圖形的方式創(chuàng )建測試用例。測試用例的圖形化表示允許更好地就測試進(jìn)行溝通，有助于理解設計的行為。用戶(hù)可以執行測試并檢視結果，以便自動(dòng)化單元測試和回歸測試。通過(guò)在開(kāi)發(fā)流程早期的設計模型階段執行測試，質(zhì)量保障經(jīng)理和軟件工程師可以高效地、有效地對設計進(jìn)行需求驗證，盡快識別出問(wèn)題。

　　回頁(yè)首基于模型的測試在安全相關(guān)開(kāi)發(fā)中的優(yōu)勢

　　安全相關(guān)軟件必須具備從需求到軟件架構再到代碼的完整可跟蹤能力。除此之外，還必須具備從需求到針對所開(kāi)發(fā)軟件檢查需求正確性測試用例的跟蹤能力。實(shí)現元素(例如測試架構、測試案例)以及模型級別的概念允許在模型級別上直接實(shí)現雙向跟蹤能力。這支持自動(dòng)分析模型和代碼的需求覆蓋率以及結構覆蓋率。除此之外，如果使用 UML 順序圖、狀態(tài)機等標注法以圖形的方式指定測試用例，驗證將比傳統以代碼為中心的測試用例更加輕松有效?；谀Ｐ偷姆椒ㄔ试S在統一的框架內開(kāi)發(fā)設計工件和測試工件。因此，該方法能夠提高開(kāi)發(fā)和測試流程的敏捷性，與具有獨立開(kāi)發(fā)和測試階段的流程相比，效率更高、成本更低。IBM Rational Rhapsody TestConductor Add On 可自動(dòng)化許多測試活動(dòng)，包括創(chuàng )建測試架構和執行測試用例。因此，測試人員可以專(zhuān)注于其測試用例的正確性和完整性，不必花時(shí)間去處理繁瑣的、易于出錯的任務(wù)，例如創(chuàng )建測試裝置。與傳統測試腳本語(yǔ)言相比，模型驅動(dòng)的測試架構和測試用例有著(zhù)圖形化的特點(diǎn)和明確的文檔，因此更易于維護。

　　回頁(yè)首采用基于模型的測試的參考工作流概述

　　Rational Rhapsody 參考工作流(請參見(jiàn) 參考資料 部分)描述了一種基于模型的開(kāi)發(fā)方法，包括適用于安全相關(guān)軟件開(kāi)發(fā)的自動(dòng)代碼生成和基于模型的測試。圖 1 展示了該參考工作流中的主要活動(dòng)。工作流的上半部分描述了設計和實(shí)現安全相關(guān)軟件的活動(dòng)。工作流的下半部分描述了驗證軟件的活動(dòng)。

　　該方法同時(shí)解決了設計和實(shí)現，同時(shí)還提供了恰當的測試和驗證。使用文本形式表示的需求來(lái)指導正式 UML/SysML 模型的開(kāi)發(fā)，這些模型隨后將使用代碼生成轉化為代碼。完善步驟均附帶恰當的指南和檢查。

　　從文本需求到可用于代碼生成的設計模型的完善步驟將通過(guò)執行基于與系統需求的模型級測試加以驗證，此驗證過(guò)程將利用 IBM Rational Rhapsody 動(dòng)畫(huà)通過(guò)模型模擬完成。這種測試也稱(chēng)為模型在環(huán)(Model-in-the-Loop，MiL)測試。生成的代碼可在計算機上驗證，方法是執行 MiL 過(guò)程中的相同測試用例，但不包含 Rational Rhapsody 動(dòng)畫(huà)。這種測試也稱(chēng)為軟件在環(huán)(Software-in-the-Loop，SiL)測試。MiL 與 SiL 的測試結果將執行自動(dòng)等效檢查(對比測試)，以驗證結果。此外，還可在目標處理器上執行一組測試來(lái)補充此類(lèi)驗證，這種測試稱(chēng)為處理器在環(huán)(Processor-in-the-Loop，PiL)測試。模型和代碼的測試執行提供了結構化的覆蓋率度量，可評估測試的完整性，避免包含不必要的功能。需求覆蓋率是在測試用例的執行過(guò)程中度量的。

　　圖 1. IBM Rational Rhapsody Reference 工作流的活動(dòng)

　　工作流中的第一項活動(dòng)是利用恰當的建模指導原則，將給定需求轉化為可執行模型。隨后，添加基于模型的測試，確保模型確實(shí)正確地捕獲了需求。覆蓋率測試(需求覆蓋率和模型覆蓋率)可度量基于模型的測試套件的完整性。代碼生成用于通過(guò)模型生成實(shí)現。模型與代碼間的對比測試或等效性測試是代碼驗證的關(guān)鍵要素。在兩個(gè)級別同時(shí)運行測試可驗證模型和代碼是否表現出相同的行為。代碼覆蓋率指標用于根據預定義的代碼覆蓋率標準確保測試套件的完整性。

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