嵌入式軟件測試
北京旋極信息技術(shù)有限公司 測控部 任建國
目前在嵌入式領(lǐng)域目標(biāo)系統(tǒng)的應(yīng)用系統(tǒng)日趨復(fù)雜,而由于競爭要求產(chǎn)品快速上市,開發(fā)技術(shù)日新月異,同時(shí)硬件發(fā)展的日益穩(wěn)定,而軟件故障卻日益突出,軟件的重要性逐漸引起人們的重視,越來越多的人認(rèn)識到嵌入式系統(tǒng)的測試勢在必行。
由于嵌入式系統(tǒng)的自身特點(diǎn),如實(shí)時(shí)性(Real-timing),內(nèi)存不豐富,I / O通道少,開發(fā)工具昂貴,并且與硬件緊密相關(guān),CPU種類繁多,等等。嵌入式軟件的開發(fā)和測試也就與一般商用軟件的開發(fā)和測試策略有了很大的不同,可以說嵌入式軟件是最難測試的一種軟件。
嵌入式軟件測試使用有效的測試策略是唯一的出路,它可以使開發(fā)的效率最大化,避免目標(biāo)系統(tǒng)的瓶頸。自從出現(xiàn)高級語言,開發(fā)環(huán)境與最終運(yùn)行環(huán)境通常都是存在差異的,嵌入式系統(tǒng)更是如此。開發(fā)環(huán)境被認(rèn)為是主機(jī)平臺,軟件運(yùn)行環(huán)境為目標(biāo)平臺。相應(yīng)的測試為host-target測試或cross-testing。
討論嵌入式軟件測試首先就會遇到一個(gè)問題:為什么不把所有測試都放在目標(biāo)上進(jìn)行呢?因?yàn)槿羲袦y試都放在目標(biāo)平臺上有很多不利的因素:
1)測試軟件,可能會造成與開發(fā)者爭奪時(shí)間的瓶頸,避免它只有提供更多的目標(biāo)環(huán)境。
2)目標(biāo)環(huán)境可能還不可行。
3)比起主機(jī)平臺環(huán)境,目標(biāo)環(huán)境通常是不精密的和不方便的。
4)提供給開發(fā)者的目標(biāo)環(huán)境和聯(lián)合開發(fā)環(huán)境通常是很昂貴的。
5)開發(fā)和測試工作可能會妨礙目標(biāo)環(huán)境已存在持續(xù)的應(yīng)用
從經(jīng)濟(jì)上和開發(fā)效率上考慮,軟件開發(fā)周期中盡可能大的比例在主機(jī)系統(tǒng)環(huán)境中進(jìn)行,其中包括測試。
確定host-target測試環(huán)境后,開發(fā)測試人員又會遇到以下的問題:
1)多少開發(fā)人員會卷入測試工作(單元測試,軟件集成,系統(tǒng)測試)?
2)多少軟件應(yīng)該測試,測試會花費(fèi)多長時(shí)間?
3)在主機(jī)環(huán)境和目標(biāo)環(huán)境有哪些軟件工具,價(jià)格怎樣,適合怎樣?
4)多少目標(biāo)環(huán)境可以提供給開發(fā)者,什么時(shí)候?
5)主機(jī)和目標(biāo)機(jī)之間的連接怎樣?
6)被測軟件下載到目標(biāo)機(jī)有多快?
7)使用主機(jī)與目標(biāo)環(huán)境之間有什么限制(如軟件安全標(biāo)準(zhǔn))?
任何人或組織進(jìn)行嵌入式軟件的測試都應(yīng)深入考慮以上問題,結(jié)合自身實(shí)際情況,選定合理測試策略和方案。
對于嵌入式軟件測試或叫交叉測試(cross-test),在測試的各個(gè)階段有著通用的策略:
1.單元測試:
所有單元級測試都可以在主機(jī)環(huán)境上進(jìn)行,除非少數(shù)情況,特別具體指定了單元測試直接在目標(biāo)環(huán)境進(jìn)行。最大化在主機(jī)環(huán)境進(jìn)行軟件測試的比例,通過盡可能小的目標(biāo)單元訪問所有目標(biāo)指定的界面。
在主機(jī)平臺上運(yùn)行測試速度比在目標(biāo)平臺上快的多,當(dāng)在主機(jī)平臺完成測試,可以在目標(biāo)環(huán)境上重復(fù)作一簡單的確認(rèn)測試,確認(rèn)測試結(jié)果在主機(jī)和目標(biāo)機(jī)上沒有被他們的不同影響。在目標(biāo)環(huán)境上進(jìn)行確認(rèn)測試將確定一些未知的,未預(yù)料到的,未說明的主機(jī)與目標(biāo)機(jī)的不同。例如,目標(biāo)編譯器可能有bug,但在主機(jī)編譯器上沒有。
2.集成測試:
軟件集成也可在主機(jī)環(huán)境上完成,在主機(jī)平臺上模擬目標(biāo)環(huán)境運(yùn)行,當(dāng)然在目標(biāo)環(huán)境上重復(fù)測試也是必須的,在此級別上的確認(rèn)測試將確定一些環(huán)境上的問題,比如內(nèi)存定位和分配上的一些錯(cuò)誤。
在主機(jī)環(huán)境上的集成測試的使用,依賴于目標(biāo)系統(tǒng)的具體功能有多少。有些嵌入式系統(tǒng)與目標(biāo)環(huán)境耦合的非常緊密,若在主機(jī)環(huán)境做集成是不切實(shí)際的。一個(gè)大型軟件的開發(fā)可以分幾個(gè)級別的集成。低級別的軟件集成在主機(jī)平臺上完成有很大優(yōu)勢,越往后的集成越依賴于目標(biāo)環(huán)境。
3.系統(tǒng)測試和確認(rèn)測試
所有的系統(tǒng)測試和確認(rèn)測試必須在目標(biāo)環(huán)境下執(zhí)行。當(dāng)然在主機(jī)上開發(fā)和執(zhí)行系統(tǒng)測試,然后移植到目標(biāo)環(huán)境重復(fù)執(zhí)行是很方便的。對目標(biāo)系統(tǒng)的依賴性會妨礙將主機(jī)環(huán)境上的系統(tǒng)測試移植到目標(biāo)系統(tǒng)上,況且只有少數(shù)開發(fā)者會卷入系統(tǒng)測試,所以有時(shí)放棄在主機(jī)環(huán)境上執(zhí)行系統(tǒng)測試可能更方便。
{{分頁}}
確認(rèn)測試最終的實(shí)施舞臺必須在目標(biāo)環(huán)境中,系統(tǒng)的確認(rèn)必須在真實(shí)系統(tǒng)之下測試,而不能在主機(jī)環(huán)境下模擬。這關(guān)系到嵌入式軟件的最終使用。
使用有效的cross-test測試策略可極大的提高嵌入式軟件開發(fā)測試的水平和效率,當(dāng)然正確的測試工具使用也是必不可少的:
下面給出各個(gè)階段的嵌入式軟件測試的方案:
一、靜態(tài)測試:
靜態(tài)測試不利用計(jì)算機(jī)運(yùn)行被測程序,度量程序靜態(tài)復(fù)雜度,檢查軟件是否符合編程 標(biāo)準(zhǔn)。
靜態(tài)測試工具M(jìn)cCabe QA,QAC/C++
1) 靜態(tài)測試工具-McCabe QA
McCabe QA是美國McCabe&Association公司的產(chǎn)品。它利用著名學(xué)者M(jìn)cCabe的軟件結(jié)構(gòu)化測試?yán)碚?,使用V(G)圈復(fù)雜度=模塊內(nèi)部獨(dú)立線性路徑數(shù)度量軟件的復(fù)雜度。
McCabe最大的特點(diǎn)就是可視化,以獨(dú)特的圖形技術(shù)表示代碼。軟件通過分析源碼,特到整個(gè)軟件系統(tǒng)的結(jié)構(gòu)圖,同時(shí)得到了各種基于工業(yè)標(biāo)準(zhǔn)評估代碼復(fù)雜性,包括V(g),EV(g),DV(g),Halstead等數(shù)十種靜態(tài)復(fù)雜度度量。用不同的顏色表示軟件模塊的復(fù)雜性,測試人員的測試重點(diǎn)放在質(zhì)量差的模塊上;提供各種質(zhì)量模型深入評價(jià)軟件質(zhì)量,紀(jì)錄軟件質(zhì)量波動曲線和版本變化趨勢分析,從而控制軟件修改不同階段的質(zhì)量。在單元級McCabe顯示模塊的流程圖,并且相對應(yīng)的標(biāo)出了代碼的位置,視圖與代碼相互對應(yīng),可很快找出問題所在。分析最終可得到各種可定制的符合工業(yè)標(biāo)準(zhǔn)的綜合報(bào)告。
2) 代碼規(guī)則檢查工具-QAC/C++
QAC/QAC++是用于代碼規(guī)則檢查的自動化工具。
代碼審查主要檢查代碼和設(shè)計(jì)的一致性,代碼對標(biāo)準(zhǔn)的遵循、可讀性,代碼的邏輯表達(dá)的正確性,代碼結(jié)構(gòu)的合理性等方面;可以發(fā)現(xiàn)違背程序編寫標(biāo)準(zhǔn)的問題,程序中不安全、不明確和模糊的部分,找出程序中不可移植部分、違背程序編程風(fēng)格的問題,包括變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結(jié)構(gòu)檢查等內(nèi)容。
MISRA Compliance 模塊為QAC可選組件,執(zhí)行MISRA 2004準(zhǔn)則檢查,在MISRA Compliance 模塊的幫助下,分析源代碼查找不符合MISRA的結(jié)構(gòu)。QA C的警告信息直接通過HTML連接到被分析的源代碼,同時(shí)也與MISRA相關(guān)規(guī)則參考信息連接。這些參考信息包括MISRA兼容代碼中解釋性的例子和標(biāo)準(zhǔn)描述。
二、動態(tài)測試
動態(tài)測試時(shí)軟件必須被執(zhí)行。動態(tài)測試方法分為黑盒法和白盒法。為了較快得到測試效果,通常先進(jìn)行功能測試,達(dá)到所有功能后,為確定軟件的可靠性進(jìn)行必要的覆蓋測試。
在軟件開發(fā)的不同時(shí)期進(jìn)行動態(tài)測試,測試又分為單元測試,集成測試,確認(rèn)測試,系統(tǒng)測試。
1) 單元測試
單元測試方案之一Cantata++
Cantata++是能夠滿足開發(fā)者進(jìn)行高效的單元和集成測試要求的專業(yè)測試工具,該產(chǎn)品能幫助提高測試效率,具有一整套包含測試、覆蓋率分析和靜態(tài)分析的功能。
Cantata++含有以下幾個(gè)主要部分:
CTH-The Cantata++ Test Harness,測試功能庫,Cantata通過CTH提供的測試函數(shù)執(zhí)行測試,提供測試所需用例的輸入輸出,并檢查輸出結(jié)果是否符合要求,給出PASS / FAIL的確切結(jié)果。打樁、封裝和動態(tài)分析的執(zhí)行也是利用CTH。
Cantata++主程序包括測試腳本自動生成器和管理器。測試腳本生成工具通過分析源代碼得到參數(shù)和數(shù)據(jù)信息,連同自動產(chǎn)生的Stub樁函數(shù)和Wrap封裝函數(shù),自動生成到測試腳本中。測試腳本完全使用C或C++語言構(gòu)成,可重用。通過使用測試腳本管理器可以自動完成測試用例定義到測試腳本的轉(zhuǎn)換。對于熟練的用戶,可以直接利用CTH提供的庫函數(shù),直接編寫C或C++語言的測試腳本。
{{分頁}}
完全支持白盒測試和黑盒測試技術(shù),通過腳本檢查所有標(biāo)準(zhǔn)的和用戶定義的類型,對期望和不期望的異常進(jìn)行檢查;對繼承類和模板實(shí)例的測試用例重用;為所有預(yù)期結(jié)果和實(shí)際結(jié)果的檢查進(jìn)行詳細(xì)的測試分析。支持覆蓋率分析,提供從語句覆蓋級到MC/DC (DO-178B A)的度量。
2)集成測試IntegratedTesting
集成測試是軟件的單元測試完成后進(jìn)行的。
集成測試工具:
Cantata++同樣支持集成測試方法,進(jìn)行調(diào)用序列,傳遞參數(shù)的檢查。并且提供獨(dú)一無二的封裝功能,完成硬件錯(cuò)誤注入的測試。提供Wrapping技術(shù),相對于樁函數(shù)stub,封裝Wrapping有以下優(yōu)勢:
1) 在被測模塊中模擬errors,避免真實(shí)代碼的執(zhí)行。模擬硬件問題,進(jìn)行逆向測試。
2) 可以校驗(yàn)集成調(diào)用的執(zhí)行過程Call 序列:
a) 允許測試者控制被測軟件的外部環(huán)境。
b) 檢查調(diào)用其成員函數(shù)執(zhí)行的是否正確(包括參數(shù)、執(zhí)行的順序)
3) 允許真實(shí)調(diào)用類的某些成員函數(shù),而封裝wrap另一些函數(shù)調(diào)用,控制其的輸入和返回參數(shù)。
另一款集成階段測試工具是McCabe Test。正如前一部分提到的,它可很直觀從整體上把握軟件的結(jié)構(gòu),生成集成測試Plan,通過插裝被測試軟件,得到被插裝后的源代碼。運(yùn)行目標(biāo)編譯器,最后并測量覆蓋率。McCabe自動跟蹤軟件執(zhí)行,得到測試信息,產(chǎn)生覆蓋率報(bào)告。
通過被測試軟件的結(jié)構(gòu)圖,直觀的評估“測了多少”,深入得到代碼級,以圖形的方式標(biāo)那些代碼測試過,而那些還沒測。支持MC / DC覆蓋分析,滿足DO178B-A標(biāo)準(zhǔn)。
McCabe QA 與McCabe TEST等組件組成McCabe IQ工具包,構(gòu)成了一整套完整的白盒測試方案。
13)確認(rèn)測試&系統(tǒng)測試
包括恢復(fù)測試、安全測試、強(qiáng)度測試、性能測試,已超出了本文討論的范疇,本文暫不詳述。
總結(jié)一下,應(yīng)用以上測試工具進(jìn)行.Cross-test時(shí)的策略:
A) 使用測試工具的插裝功能(主機(jī)環(huán)境)執(zhí)行靜態(tài)測試分析,并且為動態(tài)覆蓋測試準(zhǔn)備好一插裝好的軟件代碼。
B) 使用源碼在主機(jī)環(huán)境執(zhí)行功能測試,修正軟件的錯(cuò)誤和測試腳本中的錯(cuò)誤。
C) 使用插裝后的軟件代碼執(zhí)行覆蓋率測試,添加測試用例或修正軟件的錯(cuò)誤,保證達(dá)到所要求的覆蓋率目標(biāo)。
D) 在目標(biāo)環(huán)境下重復(fù)(B),確認(rèn)軟件在目標(biāo)環(huán)境中執(zhí)行測試的正確性。
E) 若測試需要達(dá)到極端的完整性,最好在目標(biāo)系統(tǒng)上重復(fù)(C),確定軟件的覆蓋率沒有改變。
通常在主機(jī)環(huán)境執(zhí)行多數(shù)的測試,只是在最終確定測試結(jié)果和最后的系統(tǒng)測試才移植到目標(biāo)環(huán)境,這樣可以避免發(fā)生訪問目標(biāo)系統(tǒng)資源上的瓶頸,也可以減少在昂貴資源如在線仿真器上的費(fèi)用。另外,若目標(biāo)系統(tǒng)的硬件由于某種原因而不能使用時(shí),最后的確認(rèn)測試可以推遲直到目標(biāo)硬件可用,這為嵌入式軟件的開發(fā)測試提供了彈性。設(shè)計(jì)軟件的可移植性是成功進(jìn)行cross-test的先決條件,它通??梢蕴岣哕浖馁|(zhì)量,并且對軟件的維護(hù)大有益處。以上所提到的測試工具,都可以通過各自的方式提供測試在主機(jī)與目標(biāo)之間的移植,從而使嵌入式軟件的測試得以方便的執(zhí)行。
{{分頁}}
使用有效的cross-test測試策略可極大的提高嵌入式軟件開發(fā)測試的水平和效率,提高嵌入式軟件的質(zhì)量。
附錄:
HOST-TARGET的連接方法簡介:
直接連接
通過仿真器連接
使用介質(zhì)進(jìn)行間接連接
使用PROM等傳遞被測軟件
測試的交互界面
無交互界面的連接
評論