嵌入式軟件測試

北京旋極信息技術(shù)有限公司 測控部 任建國

　　目前在嵌入式領(lǐng)域目標系統的應用系統日趨復雜，而由于競爭要求產(chǎn)品快速上市，開(kāi)發(fā)技術(shù)日新月異，同時(shí)硬件發(fā)展的日益穩定，而軟件故障卻日益突出，軟件的重要性逐漸引起人們的重視，越來(lái)越多的人認識到嵌入式系統的測試勢在必行。
　　由于嵌入式系統的自身特點(diǎn)，如實(shí)時(shí)性(Real-timing)，內存不豐富，I / O通道少，開(kāi)發(fā)工具昂貴，并且與硬件緊密相關(guān)，CPU種類(lèi)繁多，等等。嵌入式軟件的開(kāi)發(fā)和測試也就與一般商用軟件的開(kāi)發(fā)和測試策略有了很大的不同，可以說(shuō)嵌入式軟件是最難測試的一種軟件。
　　嵌入式軟件測試使用有效的測試策略是唯一的出路，它可以使開(kāi)發(fā)的效率最大化，避免目標系統的瓶頸。自從出現高級語(yǔ)言，開(kāi)發(fā)環(huán)境與最終運行環(huán)境通常都是存在差異的，嵌入式系統更是如此。開(kāi)發(fā)環(huán)境被認為是主機平臺，軟件運行環(huán)境為目標平臺。相應的測試為host-target測試或cross-testing。
　　討論嵌入式軟件測試首先就會(huì )遇到一個(gè)問(wèn)題：為什么不把所有測試都放在目標上進(jìn)行呢？因為若所有測試都放在目標平臺上有很多不利的因素：
1）測試軟件，可能會(huì )造成與開(kāi)發(fā)者爭奪時(shí)間的瓶頸，避免它只有提供更多的目標環(huán)境。
2）目標環(huán)境可能還不可行。
3）比起主機平臺環(huán)境，目標環(huán)境通常是不精密的和不方便的。
4）提供給開(kāi)發(fā)者的目標環(huán)境和聯(lián)合開(kāi)發(fā)環(huán)境通常是很昂貴的。
5）開(kāi)發(fā)和測試工作可能會(huì )妨礙目標環(huán)境已存在持續的應用
　　從經(jīng)濟上和開(kāi)發(fā)效率上考慮，軟件開(kāi)發(fā)周期中盡可能大的比例在主機系統環(huán)境中進(jìn)行，其中包括測試。
    確定host-target測試環(huán)境后，開(kāi)發(fā)測試人員又會(huì )遇到以下的問(wèn)題：
1）多少開(kāi)發(fā)人員會(huì )卷入測試工作（單元測試，軟件集成，系統測試）?
2）多少軟件應該測試，測試會(huì )花費多長(cháng)時(shí)間？
3）在主機環(huán)境和目標環(huán)境有哪些軟件工具，價(jià)格怎樣，適合怎樣?
4）多少目標環(huán)境可以提供給開(kāi)發(fā)者，什么時(shí)候?
5）主機和目標機之間的連接怎樣？
6）被測軟件下載到目標機有多快?
7）使用主機與目標環(huán)境之間有什么限制（如軟件安全標準）?
　　任何人或組織進(jìn)行嵌入式軟件的測試都應深入考慮以上問(wèn)題，結合自身實(shí)際情況，選定合理測試策略和方案。
    對于嵌入式軟件測試或叫交叉測試（cross-test），在測試的各個(gè)階段有著(zhù)通用的策略：
1．單元測試：
　　所有單元級測試都可以在主機環(huán)境上進(jìn)行，除非少數情況，特別具體指定了單元測試直接在目標環(huán)境進(jìn)行。最大化在主機環(huán)境進(jìn)行軟件測試的比例，通過(guò)盡可能小的目標單元訪(fǎng)問(wèn)所有目標指定的界面。
　　在主機平臺上運行測試速度比在目標平臺上快的多，當在主機平臺完成測試，可以在目標環(huán)境上重復作一簡(jiǎn)單的確認測試，確認測試結果在主機和目標機上沒(méi)有被他們的不同影響。在目標環(huán)境上進(jìn)行確認測試將確定一些未知的，未預料到的，未說(shuō)明的主機與目標機的不同。例如，目標編譯器可能有bug，但在主機編譯器上沒(méi)有。
2．集成測試：
　　軟件集成也可在主機環(huán)境上完成，在主機平臺上模擬目標環(huán)境運行，當然在目標環(huán)境上重復測試也是必須的，在此級別上的確認測試將確定一些環(huán)境上的問(wèn)題，比如內存定位和分配上的一些錯誤。
　　在主機環(huán)境上的集成測試的使用，依賴(lài)于目標系統的具體功能有多少。有些嵌入式系統與目標環(huán)境耦合的非常緊密，若在主機環(huán)境做集成是不切實(shí)際的。一個(gè)大型軟件的開(kāi)發(fā)可以分幾個(gè)級別的集成。低級別的軟件集成在主機平臺上完成有很大優(yōu)勢，越往后的集成越依賴(lài)于目標環(huán)境。
3．系統測試和確認測試
　　所有的系統測試和確認測試必須在目標環(huán)境下執行。當然在主機上開(kāi)發(fā)和執行系統測試，然后移植到目標環(huán)境重復執行是很方便的。對目標系統的依賴(lài)性會(huì )妨礙將主機環(huán)境上的系統測試移植到目標系統上，況且只有少數開(kāi)發(fā)者會(huì )卷入系統測試，所以有時(shí)放棄在主機環(huán)境上執行系統測試可能更方便。

{{分頁(yè)}}
　　確認測試最終的實(shí)施舞臺必須在目標環(huán)境中，系統的確認必須在真實(shí)系統之下測試，而不能在主機環(huán)境下模擬。這關(guān)系到嵌入式軟件的最終使用。

　　使用有效的cross-test測試策略可極大的提高嵌入式軟件開(kāi)發(fā)測試的水平和效率，當然正確的測試工具使用也是必不可少的：
　　下面給出各個(gè)階段的嵌入式軟件測試的方案：

一、靜態(tài)測試:
　　靜態(tài)測試不利用計算機運行被測程序，度量程序靜態(tài)復雜度，檢查軟件是否符合編程   標準。
    靜態(tài)測試工具M(jìn)cCabe QA，QAC/C++
1） 靜態(tài)測試工具-McCabe QA
　　McCabe QA是美國McCabe&Association公司的產(chǎn)品。它利用著(zhù)名學(xué)者M(jìn)cCabe的軟件結構化測試理論，使用V(G)圈復雜度=模塊內部獨立線(xiàn)性路徑數度量軟件的復雜度。

　 
    McCabe最大的特點(diǎn)就是可視化，以獨特的圖形技術(shù)表示代碼。軟件通過(guò)分析源碼，特到整個(gè)軟件系統的結構圖，同時(shí)得到了各種基于工業(yè)標準評估代碼復雜性，包括V(g)，EV(g)，DV(g)，Halstead等數十種靜態(tài)復雜度度量。用不同的顏色表示軟件模塊的復雜性，測試人員的測試重點(diǎn)放在質(zhì)量差的模塊上；提供各種質(zhì)量模型深入評價(jià)軟件質(zhì)量，紀錄軟件質(zhì)量波動(dòng)曲線(xiàn)和版本變化趨勢分析，從而控制軟件修改不同階段的質(zhì)量。在單元級McCabe顯示模塊的流程圖，并且相對應的標出了代碼的位置，視圖與代碼相互對應，可很快找出問(wèn)題所在。分析最終可得到各種可定制的符合工業(yè)標準的綜合報告。
2） 代碼規則檢查工具-QAC/C++
    QAC/QAC++是用于代碼規則檢查的自動(dòng)化工具。
　　代碼審查主要檢查代碼和設計的一致性，代碼對標準的遵循、可讀性，代碼的邏輯表達的正確性，代碼結構的合理性等方面；可以發(fā)現違背程序編寫(xiě)標準的問(wèn)題，程序中不安全、不明確和模糊的部分，找出程序中不可移植部分、違背程序編程風(fēng)格的問(wèn)題，包括變量檢查、命名和類(lèi)型審查、程序邏輯審查、程序語(yǔ)法檢查和程序結構檢查等內容。
　　MISRA Compliance 模塊為QAC可選組件，執行MISRA 2004準則檢查，在MISRA Compliance 模塊的幫助下，分析源代碼查找不符合MISRA的結構。QA C的警告信息直接通過(guò)HTML連接到被分析的源代碼，同時(shí)也與MISRA相關(guān)規則參考信息連接。這些參考信息包括MISRA兼容代碼中解釋性的例子和標準描述。

二、動(dòng)態(tài)測試
    動(dòng)態(tài)測試時(shí)軟件必須被執行。動(dòng)態(tài)測試方法分為黑盒法和白盒法。為了較快得到測試效果，通常先進(jìn)行功能測試，達到所有功能后，為確定軟件的可靠性進(jìn)行必要的覆蓋測試。
    在軟件開(kāi)發(fā)的不同時(shí)期進(jìn)行動(dòng)態(tài)測試，測試又分為單元測試，集成測試，確認測試，系統測試。
1） 單元測試
單元測試方案之一Cantata++
     Cantata++是能夠滿(mǎn)足開(kāi)發(fā)者進(jìn)行高效的單元和集成測試要求的專(zhuān)業(yè)測試工具，該產(chǎn)品能幫助提高測試效率，具有一整套包含測試、覆蓋率分析和靜態(tài)分析的功能。
　　Cantata++含有以下幾個(gè)主要部分：
　　CTH-The Cantata++ Test Harness，測試功能庫，Cantata通過(guò)CTH提供的測試函數執行測試，提供測試所需用例的輸入輸出，并檢查輸出結果是否符合要求，給出PASS / FAIL的確切結果。打樁、封裝和動(dòng)態(tài)分析的執行也是利用CTH。
　　Cantata++主程序包括測試腳本自動(dòng)生成器和管理器。測試腳本生成工具通過(guò)分析源代碼得到參數和數據信息，連同自動(dòng)產(chǎn)生的Stub樁函數和Wrap封裝函數，自動(dòng)生成到測試腳本中。測試腳本完全使用C或C++語(yǔ)言構成，可重用。通過(guò)使用測試腳本管理器可以自動(dòng)完成測試用例定義到測試腳本的轉換。對于熟練的用戶(hù)，可以直接利用CTH提供的庫函數，直接編寫(xiě)C或C++語(yǔ)言的測試腳本。

{{分頁(yè)}}
　　完全支持白盒測試和黑盒測試技術(shù)，通過(guò)腳本檢查所有標準的和用戶(hù)定義的類(lèi)型，對期望和不期望的異常進(jìn)行檢查；對繼承類(lèi)和模板實(shí)例的測試用例重用；為所有預期結果和實(shí)際結果的檢查進(jìn)行詳細的測試分析。支持覆蓋率分析，提供從語(yǔ)句覆蓋級到MC/DC (DO-178B A)的度量。
 
　
2）集成測試IntegratedTesting
　　集成測試是軟件的單元測試完成后進(jìn)行的。
集成測試工具：
　　Cantata++同樣支持集成測試方法，進(jìn)行調用序列，傳遞參數的檢查。并且提供獨一無(wú)二的封裝功能，完成硬件錯誤注入的測試。提供Wrapping技術(shù)，相對于樁函數stub，封裝Wrapping有以下優(yōu)勢：

1) 在被測模塊中模擬errors，避免真實(shí)代碼的執行。模擬硬件問(wèn)題，進(jìn)行逆向測試。
2) 可以校驗集成調用的執行過(guò)程Call 序列：
a) 允許測試者控制被測軟件的外部環(huán)境。
b) 檢查調用其成員函數執行的是否正確（包括參數、執行的順序）
3) 允許真實(shí)調用類(lèi)的某些成員函數，而封裝wrap另一些函數調用，控制其的輸入和返回參數。

　　另一款集成階段測試工具是McCabe Test。正如前一部分提到的，它可很直觀(guān)從整體上把握軟件的結構，生成集成測試Plan，通過(guò)插裝被測試軟件，得到被插裝后的源代碼。運行目標編譯器，最后并測量覆蓋率。McCabe自動(dòng)跟蹤軟件執行，得到測試信息，產(chǎn)生覆蓋率報告。
　　通過(guò)被測試軟件的結構圖，直觀(guān)的評估“測了多少”，深入得到代碼級，以圖形的方式標那些代碼測試過(guò)，而那些還沒(méi)測。支持MC / DC覆蓋分析，滿(mǎn)足DO178B-A標準。

　
    McCabe QA 與McCabe TEST等組件組成McCabe IQ工具包，構成了一整套完整的白盒測試方案。

13）確認測試&系統測試
　　包括恢復測試、安全測試、強度測試、性能測試，已超出了本文討論的范疇，本文暫不詳述。
     總結一下，應用以上測試工具進(jìn)行.Cross-test時(shí)的策略：
A) 使用測試工具的插裝功能（主機環(huán)境）執行靜態(tài)測試分析，并且為動(dòng)態(tài)覆蓋測試準備好一插裝好的軟件代碼。
B) 使用源碼在主機環(huán)境執行功能測試，修正軟件的錯誤和測試腳本中的錯誤。
C) 使用插裝后的軟件代碼執行覆蓋率測試，添加測試用例或修正軟件的錯誤，保證達到所要求的覆蓋率目標。
D) 在目標環(huán)境下重復（B），確認軟件在目標環(huán)境中執行測試的正確性。
E) 若測試需要達到極端的完整性，最好在目標系統上重復（C），確定軟件的覆蓋率沒(méi)有改變。

　　通常在主機環(huán)境執行多數的測試，只是在最終確定測試結果和最后的系統測試才移植到目標環(huán)境，這樣可以避免發(fā)生訪(fǎng)問(wèn)目標系統資源上的瓶頸，也可以減少在昂貴資源如在線(xiàn)仿真器上的費用。另外，若目標系統的硬件由于某種原因而不能使用時(shí)，最后的確認測試可以推遲直到目標硬件可用，這為嵌入式軟件的開(kāi)發(fā)測試提供了彈性。設計軟件的可移植性是成功進(jìn)行cross-test的先決條件，它通?？梢蕴岣哕浖馁|(zhì)量，并且對軟件的維護大有益處。以上所提到的測試工具，都可以通過(guò)各自的方式提供測試在主機與目標之間的移植，從而使嵌入式軟件的測試得以方便的執行。

{{分頁(yè)}}
　　使用有效的cross-test測試策略可極大的提高嵌入式軟件開(kāi)發(fā)測試的水平和效率，提高嵌入式軟件的質(zhì)量。
附錄：
HOST-TARGET的連接方法簡(jiǎn)介：
　
                                    直接連接
　
                            通過(guò)仿真器連接
 
                           使用介質(zhì)進(jìn)行間接連接
　
                           使用PROM等傳遞被測軟件
　
                              測試的交互界面
　
                               無(wú)交互界面的連接