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

張 龍

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

0 引言

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

1 開發(fā)模式的變革

傳統(tǒng)的基于文檔驅(qū)動、代碼復(fù)用的開發(fā)模式技術(shù)滯后,不能快速響應(yīng)用戶需求。文檔驅(qū)動的開發(fā)模式,以明確的產(chǎn)品需求為前提,實(shí)現(xiàn)軟件設(shè)計(jì)和編碼的信息傳遞。但現(xiàn)實(shí)項(xiàng)目運(yùn)行實(shí)踐中,存在如下問題[1]:

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

(2)代碼方面,設(shè)計(jì)的實(shí)現(xiàn)需要人工手動編碼,存在人為引入錯(cuò)誤的風(fēng)險(xiǎn),同時(shí)代碼不能支持需求和設(shè)計(jì)的早期形式化驗(yàn)證。

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

2 測試面臨的挑戰(zhàn)

MDD模式是以建模為核心工作,通過建模完成需求開發(fā)、架構(gòu)設(shè)計(jì)、詳細(xì)設(shè)計(jì)等工作,并針對模型開展分析、評審、測試與評估等驗(yàn)證工作,設(shè)計(jì)、驗(yàn)證的數(shù)據(jù)在模型與模型之間傳遞,通過模型驅(qū)動軟件系統(tǒng)的實(shí)現(xiàn)過程。在新模式下,傳統(tǒng)的軟件測試模式和技術(shù)已不能很好地適應(yīng)MDD模式的要求,軟件測試面臨新的問題和挑戰(zhàn),主要原因如下:

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

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

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

3 基于模型的測試流程和關(guān)鍵技術(shù)

3.1 基于模型的測試流程

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

3.2 基于模型的測試技術(shù)

MDD模式中,針對測試需求由自然語言到模型語言的轉(zhuǎn)變,測試人員需要基于統(tǒng)一建模語言(UML)構(gòu)建具體的測試需求模型,并基于測試需求模型設(shè)計(jì)測試激勵(lì)和規(guī)程,在驗(yàn)證的不同階段結(jié)合測試框架自適應(yīng)生成相關(guān)的測試激勵(lì),來達(dá)到分層驗(yàn)證的目的。上述過程貫徹MDD模式的需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)階段、代碼生成階段。整個(gè)測試過程主要的驗(yàn)證技術(shù)如圖1所示。

圖1 基于模型的軟件測試技術(shù)

3.2.1 靜態(tài)驗(yàn)證技術(shù)

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

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

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

3.2.2 測試需求模型的構(gòu)建技術(shù)

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

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

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

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

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

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

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

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

3.2.3 測試規(guī)程描述和生成技術(shù)

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

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

依次對照功能性測試需求模型、非功能性測試需求模型,提取模型數(shù)據(jù)文件中面向相關(guān)功能、過程的邏輯信息、狀態(tài)遷移條件、時(shí)序信息等過程信息,結(jié)合邏輯信息、狀態(tài)遷移條件、時(shí)序信息生成測試用例規(guī)程。

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

依次對照功能性測試需求模型、非功能性測試需求模型,提取模型數(shù)據(jù)文件中面向相關(guān)功能、過程的數(shù)據(jù)源、數(shù)據(jù)目的、接口約束等信息,結(jié)合測試框架,生成測試輸入。在測試用例輸入數(shù)據(jù)的生成方面,可借助傳統(tǒng)的測試用例數(shù)據(jù)生成方法,如等價(jià)類、邊界值,生成面向工程實(shí)踐的最優(yōu)解。

3.2.4 測試驅(qū)動和測試框架構(gòu)建技術(shù)

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

3.2.5 測試充分性評估方法

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

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

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

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

4 結(jié)語

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