基于模型的嵌入式軟件測試技術研究

張 龍

(中國航空工業集團公司洛陽電光設備研究所,河南 洛陽 471009)

0 引言

武器裝備軟件的開發模式正發生深刻變革,從傳統的基于文檔驅動的開發模式向基于模型驅動的開發模式(以下簡稱“MDD模式”)轉變。MDD模式是由OMG組織提出的一種軟件開發框架,其核心思想是以模型,而非代碼為中心的軟件開發模式,來達到分離問題域、業務邏輯以及實現平臺的目標。MDD模式的逐步普及,對軟件開發、測試行業都帶來了深刻的變革。

1 開發模式的變革

傳統的基于文檔驅動、代碼復用的開發模式技術滯后,不能快速響應用戶需求。文檔驅動的開發模式,以明確的產品需求為前提,實現軟件設計和編碼的信息傳遞。但現實項目運行實踐中,存在如下問題[1]:

(1)文檔方面,需求獲取難度較大,自然語言的傳遞信息容易有歧義,且文檔的維護工作量大,難以保證文文、文實一致性。

(2)代碼方面,設計的實現需要人工手動編碼,存在人為引入錯誤的風險,同時代碼不能支持需求和設計的早期形式化驗證。

MDD模式逐步成為業界主要的軟件開發框架,并受到越來越多公司的青睞,如空中客車公司、航空工業集團等。模型驅動使得軟件開發人員能可視化地理解所開發的軟件系統,減少溝通成本,避免傳統軟件文檔描述的模糊性;同時支持在開發初期,驗證軟件行為、安全性,盡早發現軟件缺陷;其自動化的代碼生成功能,也極大地加速軟件開發效率[2]。

2 測試面臨的挑戰

MDD模式是以建模為核心工作,通過建模完成需求開發、架構設計、詳細設計等工作,并針對模型開展分析、評審、測試與評估等驗證工作,設計、驗證的數據在模型與模型之間傳遞,通過模型驅動軟件系統的實現過程。在新模式下,傳統的軟件測試模式和技術已不能很好地適應MDD模式的要求,軟件測試面臨新的問題和挑戰,主要原因如下:

(1)開發模式的不同。傳統的開發模式是基于文檔驅動的通過文檔完成需求開發、架構設計、詳細設計等工作。測試人員通過理解需求文本獲取軟件測試需求,來驗證和評估軟件的功能性、接口、安全性等指標,軟件測試和開發相對分離;MDD開發模式下,是以模型為核心工作,軟件需求分析、設計實現、測試工作分別整合到了軟件需求模型、軟件設計模型、軟件測試模型中,在模型之間傳遞需求、設計、驗證數據,軟件測試和開發高度耦合。

(2)測試對象的不同。傳統的測試對象主要是自然語言和編程語言,主要方法有文檔審查、代碼審查、靜態分析、動態驗證;MDD開發模式下,軟件測試的對象主要是統一的形式化語言,主要方法有模型檢查(MC)、定理證明(TP)、基于模型的動態測試技術、時間堆棧分析等高級驗證手段[3]。

因此,對MDD開發模式下軟件測試流程和軟件測試技術的研究就變得十分必要和迫切。

3 基于模型的測試流程和關鍵技術

3.1 基于模型的測試流程

MDD模式,可將軟件的測試驗證工作大大前移,并在需求分析、概要設計、詳細設計、代碼生成等全生命周期執行基于模型的測試和迭代驗證,開發和測試是螺旋前進的,互相驗證,可規避如瀑布模型、V模型等某一流程的固有缺陷。其支持在開發過程的不同階段,分別構建模型在環(需求模型、設計模型在環)、代碼在環(基于模型生成的代碼在環)、產品在環(基于模型生成的代碼加載到處理器等產品環路)的多級軟件測試過程。該驗證方式區別于傳統驗證,具有手段單一、效率低的特點,其成本更低,效率更高,敏捷性和靈活度更好。

3.2 基于模型的測試技術

MDD模式中,針對測試需求由自然語言到模型語言的轉變,測試人員需要基于統一建模語言(UML)構建具體的測試需求模型,并基于測試需求模型設計測試激勵和規程,在驗證的不同階段結合測試框架自適應生成相關的測試激勵,來達到分層驗證的目的。上述過程貫徹MDD模式的需求分析、概要設計、詳細設計階段、代碼生成階段。整個測試過程主要的驗證技術如圖1所示。

圖1 基于模型的軟件測試技術

3.2.1 靜態驗證技術

在軟件系統需求分析、概要設計、詳細設計等早期階段,可以進行模型的早期驗證。主要技術手段有軟件形式化驗證技術和故障樹分析法,其中形式化驗證技術又分為定理證明和模型檢驗2種。通過模型的靜態驗證,可以在需求分析和設計早期,找出數據流不匹配、死循環等一系列錯誤,并提早進行錯誤定位,及時歸零。

(1)定理證明為使用邏輯的語言和方法對軟件中的算法、邏輯等進行規約描述,明確軟件適用的公理,建立軟件的推理規則,依據公理和推理規則證明軟件的功能正確性。

(2)模型檢查技術在具體使用時,可借助基于時間自動機模型的分析、SysML塊依賴圖模型的分析、基于狀態事件故障樹模型的分析等方法來開展。

3.2.2 測試需求模型的構建技術

依據軟件業務邏輯、接口數據元素、接口約束、FTA故障樹、FMEA軟件失效模式等分別識別軟件功能測試需求,性能、接口、邊界、安全性等非功能性測試需求,以此確定測試需求的內容、范圍及邊界。

對軟件測試需求進行建模主要有軟件功能性測試需求建模、非功能性測試需求建模。多數情況下,功能性測試需求模型可由軟件需求進行分解、合并后得到,使用UML語言中的用例圖、活動圖、狀態圖、時序圖等對功能性測試需求建模。非功能性測試需求獲取較為困難。以安全性需求為例,一般有如下方式。

(1)基于FTA的軟件故障樹分析識別軟件安全性要求。

使用FTA方法從軟件需求中提取軟件故障樹信息,從而識別出導致軟件安全或不安全的基本事件、基本路徑、影響范圍和對象等軟件安全性要求。

(2)基于FMEA的軟件失效模式分析識別軟件安全性要求。

使用FMEA方法從軟件需求中提取軟件潛在失效模式及后果信息,將潛在失效模式描述為Input-Process-Outpt形式的導致軟件不安全的功能邏輯需求,識別為軟件安全性要求。

(3)軟件安全性要求規約。

對于使用FTA、FMEA方法得到的軟件安全性要求信息,再使用形式化規約方法,將自然語言轉化為形式化的UML語言,用以將安全性要求描述出來,并轉化為一組與軟件安全性需求有關的對象、屬性、參數和指標,從而為安全性需求建模提供直接輸入。

3.2.3 測試規程描述和生成技術

依據軟件功能性測試需求模型、非功能性測試需求模型,識別軟件全部的基本事件、基本路徑、異常路徑,生成測試用例集。

(1)依據基本邏輯生成測試用例規程。

依次對照功能性測試需求模型、非功能性測試需求模型,提取模型數據文件中面向相關功能、過程的邏輯信息、狀態遷移條件、時序信息等過程信息,結合邏輯信息、狀態遷移條件、時序信息生成測試用例規程。

(2)依據接口元素模型生成測試用例輸入。

依次對照功能性測試需求模型、非功能性測試需求模型,提取模型數據文件中面向相關功能、過程的數據源、數據目的、接口約束等信息,結合測試框架,生成測試輸入。在測試用例輸入數據的生成方面,可借助傳統的測試用例數據生成方法,如等價類、邊界值,生成面向工程實踐的最優解。

3.2.4 測試驅動和測試框架構建技術

針對功能性、非功能性測試用例模型,利用建模工具如Rhapsody、Scade構建支持單個用例運行的軟件測試驅動,并提前設置測試用例的預期結果,自動判讀是否執行通過;利用建模工具構建軟件測試框架,支持測試用例的批量運行和批量判讀。測試框架可理解為貫穿基于模型的整個測試過程的軟件架構,其支持軟件測試用例的自動化批量執行、自動判讀,在Rhapsody、Scade工具中可使用功能結構圖、類圖等對軟件架構建模。

3.2.5 測試充分性評估方法

測試充分性評估方面一般使用測試需求的覆蓋率分析、結構覆蓋分析(SC覆蓋、DC覆蓋、MC/DC覆蓋)、數據耦合覆蓋和控制耦合覆蓋分析等方法,輔以軟件最壞運行時間(WCET)和堆棧內存分析等方法保證基于模型的軟件測試的充分性要求。具體有如下要求。

(1)測試需求的覆蓋率分析,應開展如下分析: ①針對每一條標識的高層需求都有一條或多條測試用例通過追蹤矩陣來對應,該追蹤矩陣用于驗證高層需求是否被實現; ②針對每一條測試用例在追蹤矩陣里都有一條或多條高層需求相對應; ③測試用例應包括正常和魯棒性測試。如通過SCADE Suite MTC覆蓋率的評審來證明SCADE 模型對高層需求的覆蓋率滿足要求;基于需求的測試可能不能完整地達到模型覆蓋率要求,因此模型覆蓋率可以通過附加驗證來達到要求,如分支覆蓋。

(2)SC覆蓋和DC覆蓋分析基于源代碼進行,使用Testbed、SCADE MTC工具分析和人工分析相結合的方法。

(3)針對代碼在執行基于需求的測試,覆蓋率未達到時,應執行附加分析,含以下4種情況: ①需求不充分。比如缺魯棒性需求,需求需要修改或完善,從而產生附加的測試用例/規程。 ②測試不充分。應當補充測試用例/規程。 ③附加代碼。附加代碼可以保留在源代碼中,但不能在目標代碼中,軟件生成過程(如:通過編譯或鏈接去除)應保證其不會出現在目標代碼中。 ④非激活代碼。應當做一些組合的測試和分析來證明非激活代碼不會被意外地執行或工作。

4 結語

本文結合開發模式的變革介紹了軟件測試的趨勢,并詳細介紹了基于模型的測試流程以及基于模型的測試技術。通過在實際的武器裝備軟件測試中推廣使用,表明其相較于傳統測試技術,更能適應于MDD開發模式的需要,同時其需求傳遞誤差小,測試效率更高,能更快速地響應用戶需求。但相較傳統的測試技術,基于模型的軟件測試技術在工程實踐中仍處于成長階段,需要進一步的研究,如文中提到的形式化驗證技術、基于模型的測試用例生成技術等。