嵌入式系統(tǒng)軟件測試

1、. . . . 嵌入式系統(tǒng)軟件測試1.1 概述軟件測試軟件測試是設(shè)計測試用例，并利用測試用例運行程序，發(fā)現(xiàn)錯誤的過程。而測試用例的設(shè)計則需要借助軟件開發(fā)階段的規(guī)格說明書以與程序的部結(jié)構(gòu)。軟件測試是軟件工程研究領(lǐng)域的重要分支，是保證軟件質(zhì)量的關(guān)鍵步驟。發(fā)生于上世紀(jì)70年代末的“軟件危機”， 對軟件理論的研究起到了極大的促進作用，同時“軟件工程”作為一項新興學(xué)科也在此時開創(chuàng)。經(jīng)過30多年的發(fā)展，盡管沒有找到真正的“銀彈(silver bullet)”來徹底解決“軟件危機”問題，但是軟件工程的研究，在軟件開發(fā)技術(shù)和軟件項目管理兩大領(lǐng)域，依然碩果累累。從結(jié)構(gòu)化程序設(shè)計思想到面向?qū)ο罄碚?；從簡單無序的手

2、工作坊式編程到較為規(guī)、可控制的各種開發(fā)模型；從富于個人英雄主義氣質(zhì)的牛仔式的程序員到分工明確、迅速高效的現(xiàn)代化開發(fā)團隊；從只要求程序能夠運行到追求程序的可靠性、兼容性、設(shè)計重用性等高質(zhì)量屬性；這一系列思想的進步和方法的改進，都表明了軟件工程領(lǐng)域的研究正在不斷的取得進步。與此同時，對高質(zhì)量軟件的日益需求，促進了軟件工程領(lǐng)域的重要容之一：軟件測試?yán)碚摰难芯亢蛯嵺`。三十多年的發(fā)展，為我們提供了豐富的經(jīng)驗，使得軟件測試成為一門十分成熟的學(xué)科。1.1.1 軟件測試目的軟件測試的過程是尋找和發(fā)現(xiàn)軟件中潛在的錯誤的過程，因此，軟件測試的首要目的是與早的發(fā)現(xiàn)軟件中所包含的各種錯誤，以此來使軟件獲得相應(yīng)級別的質(zhì)

3、量保證。其次，通過軟件測試，還可以驗證軟件實現(xiàn)的功能是否符合設(shè)計說明書的要求；驗證軟件的性能是否達到設(shè)計要求；通過收集測試過程中的各種數(shù)據(jù)，為軟件質(zhì)量的評價提供一定的依據(jù)。另外，在指定具體的測試目標(biāo)時，人們通常會將投入的時間和人力等成本考慮進去，所以，成功的軟件測試往往是通過最少的人力和時間成本，盡可能多的找出軟件中潛在的各種錯誤和設(shè)計缺陷。1.1.2 軟件測試對象一種常見的觀點認為軟件測試單指程序測試，這種觀點顯然是不全面的。軟件測試貫穿于整個軟件定義和軟件開發(fā)過程。因此，由需求分析得到的需求說明書、由概要設(shè)計得到的概要設(shè)計說明書、由詳細設(shè)計得到的詳細設(shè)計說明書以與由程序編碼得到的源程序等，

4、均應(yīng)該被視為軟件測試的對象。在軟件的開發(fā)過程中，越早發(fā)現(xiàn)的錯誤，改正錯誤的代價就越低，對于軟件開發(fā)過程的影響就越小，見圖3-1。因此，對于軟件生存周期的各個階段所要傳遞的信息，都應(yīng)該盡可能的保證理解和表達的正確性。對每個階段所得到的階段性成果，都應(yīng)該獨立的進行確認和驗證，以求盡早地發(fā)現(xiàn)軟件缺陷。圖 01隨時間推移，修復(fù)軟件錯誤費用驚人增長1.1.3 軟件測試數(shù)據(jù)流圖軟件測試數(shù)據(jù)流圖描述了軟件測試的基本流程，如圖3-2所示。測試過程需要兩類輸入，分別是軟件配置和測試配置。軟件配置包括：軟件需求規(guī)格說明書，軟件設(shè)計規(guī)格說明書，源代碼等；測試配置包括：測試計劃，測試用例，測試驅(qū)動程序和測試工具等。圖

5、 02軟件測試數(shù)據(jù)流圖1.1.4 軟件測試方法軟件測試的方法多種多樣，從不同的角度來看，可以有不同的分類方法。從其貫穿軟件生命周期的過程來看，可以分為模塊測試、集成測試、系統(tǒng)測試和確認測試等測試階段；另外，測試還可以分為靜態(tài)測試和動態(tài)測試；在動態(tài)測試中，又分為基于程序結(jié)構(gòu)的白盒測試和基于功能的黑盒測試?？偟膩碇v，目前軟件測試存在兩大類測試方法，第一類測試方法是將軟件在設(shè)計的環(huán)境下運行以得出結(jié)果，并將該結(jié)果與預(yù)期結(jié)果作對照，如果二者相符則測試通過，如果二者存在出入不相符則視為錯誤。最終在設(shè)計規(guī)定的環(huán)境中將軟件的所有功能加以運行，以逐一發(fā)現(xiàn)錯誤。該方法基于用戶需求和設(shè)計，將測試工作的疇加以界定，可

6、有針對性地部署測試的側(cè)重點。第二類方法與需求和設(shè)計沒有必然的聯(lián)系，更強調(diào)測試人員利用逆向思維發(fā)揮主觀能動性，不斷反思開發(fā)人員的不良習(xí)慣、理解的誤區(qū)、無效數(shù)據(jù)的輸入、程序代碼的邊界以與系統(tǒng)本身的各種弱點，站在破壞和摧毀系統(tǒng)的角度，不斷尋找系統(tǒng)中各種各樣的問題。實踐中，結(jié)合使用以上兩種測試方法往往能夠取得較好的效果。1.2 嵌入式軟件的測試1.2.1 關(guān)于測試策略嵌入式平臺，資源相對稀少，但其卻是嵌入式系統(tǒng)軟件最終的運行環(huán)境,而一般軟件可能運行在超級計算機上或高性能的PC機上。適當(dāng)條件下, 嵌入式系統(tǒng)軟件的測試同樣適用一般軟件的單元測試、系統(tǒng)測試、集成測試和確認測試策略。我們也可以將所謂的適當(dāng)條件

7、看作是關(guān)于嵌入式系統(tǒng)軟件測試的獨特策略。嵌入式系統(tǒng)中的開發(fā)環(huán)境和最終運行環(huán)境又分別被稱為主機(Host)平臺和目標(biāo)(Target)平臺。兩種典型的嵌入式軟件開發(fā)方式分別為:一種是在實際目標(biāo)(Target)平臺上編輯、編譯和調(diào)試代碼進而開發(fā)源代碼;另一種則是將編輯和編譯源代碼的工作在主機平臺上完成,而后移動可執(zhí)行代碼到目標(biāo)機上進行調(diào)試。第二種方法也叫做交叉開發(fā),如圖3-3所示。圖 03 交叉開發(fā)選擇交叉開發(fā)方法使得目標(biāo)機和主機在運行速度上的差別得以緩解。交叉開發(fā)環(huán)境,同時也是交叉測試環(huán)境，因為在交叉測試過程中同樣體現(xiàn)了交叉開發(fā)的有利因素。這即是前面提到的適當(dāng)條件,即關(guān)于嵌入式軟件測試的獨特的交叉

8、測試策略。在主機環(huán)境下，無論是嵌入式軟件的單元測試還是嵌入式軟件的集成測試均可以完成;然而關(guān)于最終的硬軟件集成測試則必須在目標(biāo)環(huán)境下,利用目標(biāo)機與主機間的信息通道,進而實現(xiàn)測試控制和信息反饋通信。1.2.2 測試方法關(guān)于測試方法，覆蓋和質(zhì)量是主要的評測方法。測試覆蓋可用測試需求和測試用例的覆蓋來表示，亦可用已執(zhí)行代碼的覆蓋來表示，主要是評測測試的完全程度。將針對測試對象的穩(wěn)定性、可靠性以與性能的評測稱作是質(zhì)量。不管是對測試結(jié)果的評估，還是在測試過程中針對確定的變更請求(缺陷)所進行的分析，均可作為質(zhì)量評測的基礎(chǔ)。(1)覆蓋測評 測試的完全程度由覆蓋指標(biāo)表示。黑盒的測試覆蓋和白盒的測試覆蓋是最常

9、用的覆蓋測評方法，前者是基于需求的測試覆蓋，而后者則是基于代碼的測試覆蓋。簡單地說，測試覆蓋是對基于需求或基于代碼的完全程度的評測，前者是核實測試用例，后者是評測代碼執(zhí)行。系統(tǒng)的測試活動必須以測試覆蓋策略為基礎(chǔ)，測試的一般目的由覆蓋策略述，用例的設(shè)計也由覆蓋策略指導(dǎo)。此外，所有性能也可由覆蓋策略的述簡單說明。倘若已經(jīng)將需求完全分類，那么覆蓋策略基于需求足以生成測試為完全程度的可計量評測。舉例說明，如若所有性能的測試需求都已經(jīng)被確定，那么評測就可引用測試結(jié)果得到。如若應(yīng)用基于代碼的測試覆蓋，那么測試策略只能根據(jù)測試所得的已執(zhí)行的源代碼的多少來確定。對于安全之上的系統(tǒng)來說，該測試覆蓋策略類型具有非

10、常重要的意義。在測試生命周期中，基于需求的測試覆蓋要評測數(shù)次。測試覆蓋可用以下公式計算：測試覆蓋T是用已計劃或已實施或成功的測試過程或測試用例表示的測試(Test)數(shù)。表示測試需求(Requirement for Test)總數(shù)。制定測試計劃時，通過計算測試覆蓋以確定已計劃的測試覆蓋，計算方法為：測試覆蓋(已計劃的) 是已計劃測試數(shù)，其用測試過程或測試用例表示。實施測試活動時，測試過程按照測試腳本正在實施中，可采用以下公式計算測試覆蓋：測試覆蓋(已執(zhí)行的) 是已執(zhí)行的測試數(shù)，其用測試過程或測試用例表示。執(zhí)行測試活動時，兩個測試覆蓋評測同時使用，其一用來確定由執(zhí)行測試得到的測試覆蓋，另一個用來確

11、定執(zhí)行時未出現(xiàn)失敗即成功的測試覆蓋(如沒有缺陷出現(xiàn)或意外結(jié)果產(chǎn)生的測試)。利用以下公式計算這些覆蓋評測：測試覆蓋(已執(zhí)行的) 是已執(zhí)行的測試數(shù)，其用測試過程或測試用例表示。成功的測試覆蓋(已執(zhí)行的) 也是已執(zhí)行的測試數(shù)，不同的是，其是由沒有缺陷的已完成的測試過程或測試用例來表示。倘若用百分?jǐn)?shù)表示以上比率，那么以下有關(guān)基于需求的測試覆蓋的述同樣成立：已經(jīng)覆蓋的測試用例(同上述公式中的)為 x，成功率為y。關(guān)于測試覆蓋的該種述是有意義的，其與已定義的成功標(biāo)準(zhǔn)作比較，如果不相符，則可利用此述為基礎(chǔ)來預(yù)測剩余測試工作?；诖a的測試覆蓋，在測試過程中，其可以測評已經(jīng)執(zhí)行的代碼的多少，而要執(zhí)行的剩余代碼

12、則與之相對。控制流包括語句、分支或路徑，而代碼覆蓋則即可建立在控制流上，亦可建立在數(shù)據(jù)流上。無論是測試代碼行、測試分支條件、還是測試代碼中的路徑，甚至軟件控制流中的其它元素都被當(dāng)作了控制流覆蓋的目的。數(shù)據(jù)流覆蓋的目的是利用軟件操作對數(shù)據(jù)狀態(tài)的有效與否進行測試。例如，測試在使用之前數(shù)據(jù)元素是否已作定義。利用以下公式對基于代碼的測試覆蓋進行計算：測試覆蓋是已執(zhí)行項目數(shù)，其既可用代碼語句、分支或路徑來表示，還可用數(shù)據(jù)元素名或數(shù)據(jù)狀態(tài)判定點數(shù)來表示。表示代碼中的項目總數(shù)。倘若用百分?jǐn)?shù)表示以上比率，那么以下有關(guān)基于代碼的測試覆蓋的述同樣成立：已經(jīng)覆蓋的測試用例(同上述公式中的I)為 x，成功率為y。關(guān)于

13、測試覆蓋的該種述是有意義的，其與已定義的成功標(biāo)準(zhǔn)作比較，如果不相符，則可利用此述為基礎(chǔ)來預(yù)測剩余測試工作。(2)質(zhì)量評測適用于硬件可靠性設(shè)計中的“簡單就是可靠”原則同樣也適合軟件，隨著功能的增多或增強軟件需要不斷升級與補丁。軟件質(zhì)量是由因應(yīng)用方面和用戶觀點不同而各異的多種因素組成的混合體或綜合體。按照能否直接度量的標(biāo)準(zhǔn)可將影響軟件質(zhì)量的因素分為兩大類：其一是可直接度量的因素，其二是只能間接度量的因素，前者如單位時間所發(fā)現(xiàn)的每千行源代碼的錯誤個數(shù)，后者如可維護性、可復(fù)用性等。以上兩大類影響軟件質(zhì)量的因素都能夠被度量，且都可以具體數(shù)據(jù)描述軟件質(zhì)量的不同方面。關(guān)于軟件的可維護性，主要有三種度量參數(shù)，

14、分別為：Line復(fù)雜度、Halstead復(fù)雜度和McCabe復(fù)雜度。Line復(fù)雜度的計算基準(zhǔn)是代碼的行數(shù)。Halstead復(fù)雜度將程序中使用到的運算元與運算符數(shù)量作為直接測量指標(biāo),然后計算出程序容量和工作量等。McCabe復(fù)雜度又被稱作是圈復(fù)雜度，它定量了測試?yán)щy度以與最終可靠性指標(biāo)的度量。經(jīng)試驗證明，McCabe度量、存在于源代碼中的錯誤數(shù)、發(fā)現(xiàn)并糾正這些錯誤所需的時間，該三者之間存在特定的關(guān)系。McCabe&Associates公司成立于1976年，該公司針對軟件進行結(jié)構(gòu)測試而開發(fā)出了McCabe Cylomatic Complexity Metric（圈復(fù)雜度）技術(shù)。將軟件復(fù)雜度

15、測量的數(shù)目作為基礎(chǔ)的Meric，可幫助工程師較為輕松地識別出難于測試和維護的模塊。人們將圈復(fù)雜度作為評估軟件質(zhì)量的重要標(biāo)準(zhǔn)，利用其來衡量軟件的復(fù)雜度和質(zhì)量，奔著在成本、進度以與性能之間尋求平衡的目的來安排工程進度。McCabe復(fù)雜度包括基本復(fù)雜度、圈復(fù)雜度、設(shè)計復(fù)雜度、模塊設(shè)計復(fù)雜度和集成復(fù)雜度。1.2.3 測試工具1.2.3.1 軟件測試工具純軟件方式的測試大多都是利用軟件仿真技術(shù)，在宿主機上模擬目標(biāo)機，從而在仿真的宿主機上進行大部分的測試?，F(xiàn)在大多數(shù)的嵌入式測試工具，包括Logiscope、Coverage Scope等都采用了這種方式。作為純軟件測試工具Host/Target采用的是軟件

16、插樁技術(shù)。將一些函數(shù)或一段語句插入到被測代碼中，再利用插入的函數(shù)或語句來生成數(shù)據(jù)，并將這些數(shù)據(jù)上送到目標(biāo)系統(tǒng)的共享存中。與此同時，在目標(biāo)系統(tǒng)中利用預(yù)處理任務(wù)對這些數(shù)據(jù)進行預(yù)處理，之后通過目標(biāo)機的調(diào)試口將處理后的數(shù)據(jù)上送到主機平臺，所有的這些都在目標(biāo)處理器的參與下完成。測試者通過以上過程可以得知程序當(dāng)前的運行狀態(tài)。插樁函數(shù)和預(yù)處理任務(wù)作為兩個特點必然存在于純軟件的測試方式中。而插樁函數(shù)和預(yù)處理任務(wù)的存在也增大了系統(tǒng)的代碼，更有甚者，某些代碼會極影響系統(tǒng)的運行效率。預(yù)處理任務(wù)不但占用目標(biāo)系統(tǒng)CPU存，而且需要時間在通信通道中處理和傳送數(shù)據(jù)。鑒于這些弊端的存在，基于Host/Target的純軟件測試

17、工具在進行測試時，其不能對目標(biāo)系統(tǒng)進行精確的性能分析，甚至，在分析覆蓋率時，系統(tǒng)的運行還要受到大量插樁的影響。所以，Host/Target作為一種純軟件測試工具，其缺乏性能分析功能，既不能針對目標(biāo)系統(tǒng)中相關(guān)的時間指標(biāo)做出精確的分析，也不能動態(tài)觀察存的動態(tài)分配。1.2.3.2 硬件測試工具純硬件的手段，如萬用表、示波器、邏輯分析儀等，通常被用于設(shè)計和測試系統(tǒng)的硬件，但也可用來分析測試軟件。邏輯分析儀是最常用的一種純硬件測試工具，其通過監(jiān)控系統(tǒng)運行時總線上的指令周期，利用一定頻率捕獲信號，分析數(shù)據(jù)，通過了解用戶系統(tǒng)的工作狀態(tài)，進而對當(dāng)前程序運行的狀況做出判斷。邏輯分析儀使用采樣的方式，難免會遺漏重

18、要信號，而且，其分析圍也非常有限。舉例說明，邏輯分析儀只能采用抽樣的方式，對有限的函數(shù)進行性能分析，故其要得出滿意的結(jié)果十分困難。針對程序分析覆蓋率時，硬件工具需要從系統(tǒng)總線上捕獲數(shù)據(jù)，例如當(dāng)打開Cache時系統(tǒng)會基于指令預(yù)取技術(shù)，將外存中的一段代碼讀入到一級Cache中，此時，邏輯分析儀利用頻率捕獲到代碼被讀取的信號，然后報告這些代碼已被執(zhí)行，然而實際上被讀入到一級Cache中的代碼可能根本沒有被命中。只有把Cache關(guān)掉才可能避免這種誤差，而把Cache關(guān)掉之后系統(tǒng)的運行環(huán)境就不真實了，更有甚者系統(tǒng)都可能出現(xiàn)無常運行的現(xiàn)象。由此可知，純硬件工具根本不具備分析和檢查存分配的能力。1.2.3.

19、3 軟硬結(jié)合測試工具所謂的軟硬結(jié)合測試工具，也即能夠利用純軟件和純硬件測試工具各自的優(yōu)點，并摒棄它們各自的缺點。例如高性能測試工具CodeTest，其采用插樁技術(shù)由Applied Microsystems Corporation(AMc)公司專為嵌入式開發(fā)者而設(shè)計，可用于本機測試 (native)甚至在線測試(in-circuit)。區(qū)別于純軟件測試工具，CodeTest以插入一條賦值語句來替代插樁函數(shù)，從而大大縮短了執(zhí)行時間，同時也避免了被中斷，相互間的影響都非常小。同時，CodeTest又吸取并改進了純硬件測試工具里從總線捕獲數(shù)據(jù)的技術(shù)，CodeTest摒棄采樣的方式，通過監(jiān)視系統(tǒng)總線，只有在程序運行到插入的特殊點時才會主動捕獲數(shù)據(jù)總線上的數(shù)據(jù)，所以，利用CodeTest所做的數(shù)據(jù)觀察可以很精確。CodeTest主要的功能有:(l) 分析性能。(2) 分析測試覆蓋。(3) 分析動態(tài)存儲器分配。(4) 分析執(zhí)行追蹤 (TRACE)。所以，雖然現(xiàn)在市面上的一些測試工具在某些應(yīng)用中達到了一定或較好的效果，但由于嵌入式的多樣性，使得這些測試工具在針對某些特定的應(yīng)用