嵌入式代碼覆蓋率如何進行統(tǒng)計有哪些方法和經(jīng)驗

代碼覆蓋率是衡量軟件測試完成情況的指標，通?；跍y試過程中已檢查的程序源代碼比例 計算得出。代碼覆蓋率可以有效避免包含未測試代碼的程序被發(fā)布。

代碼覆蓋率能不能提高軟件的可靠性？答案是肯定的，代碼的覆蓋率分析是保證軟件質(zhì)量最簡 便易行的方法。

代碼覆蓋率等級

代碼覆蓋率可以通過多種方法測量。最常用的是測量以下一個或多個指標：語句覆蓋率，分支 覆蓋率，修訂的條件/判定覆蓋率（MC/DC）。以下章節(jié)中將逐一詳解這些代碼覆蓋率。

語句覆蓋率

語句覆蓋率用來度量被測代碼中的可執(zhí)行語句是否被執(zhí)行到，它并不考慮循環(huán)或者條件語句， 只針對語句度量可執(zhí)行代碼。應(yīng)當特別注意的是：“語句”并不等同于代碼行。

一般情況下，對于 C，C++，Java或Ada，分號代表語句結(jié)束。在某些情況下，一條語句會跨越多 行代碼。語句覆蓋率可以有效度量可執(zhí)行代碼是否被執(zhí)行，但同時也有一定的局限性。

語句覆蓋率的局限

考慮如下圖1的代碼段：

int* p = NULL;

if （condition）

p = &variable;

*p = 123;

圖 1 – 語句覆蓋局限代碼示例

如果“condition”為true，那么就有可能達到100%的語句覆蓋，然而這個測試用例忽略了另 一種情況：如果“condition”為假，程序?qū)⒁每罩羔?，因此，雖然語句覆蓋率是一個很好 的度量指標，它仍舊是入門級的代碼覆蓋率。理想情況下，即使“condition”為false，測試 用例也應(yīng)當被計算。

分支覆蓋率

分支覆蓋率用來度量程序中所有的判定和分支以及相應(yīng)的輸出是否都被測試執(zhí)行到，例如 “if”語句必須將“true”和“false”都考慮到以覆蓋所有的輸出。如果只有一個路徑被執(zhí)行，那么覆蓋率將被標記為部分執(zhí)行。

和語句覆蓋率類似，分支覆蓋浪費也有一些需要注意的細節(jié)，尤其在針對“惰性求值”的編程語言時，惰性求值是將代碼的求值操作延遲到需要結(jié)果值時再進行的一項技術(shù)。

分支覆蓋率的局限

典型的情況是當有復雜的布爾表達式的“惰性求值”出現(xiàn)時，如下圖2的代碼片段：

int* p = NULL;

if （condition1 && （condition2 || function1（*p）））

statement1;

else

圖 2 – 分支覆蓋率局限代碼示例

考慮“condition1”為假的情況，惰性求值將不會度量“condition2”或，此種情況同樣會導致 代碼“if （condition1 && （condition2 || function1（*p）））”的分支覆蓋率計算錯誤。

繼續(xù)考慮“condition1”和“condition2”都為真的情況。惰性求值將再次導致“function1（*p）” 不會被度量，也同樣會導致代碼“if （condition1 && （condition2 || function1（*p）））”的分支覆蓋率 計算錯誤。在此種情況下，有可能出現(xiàn)分支覆蓋率為100%但軟件中仍有潛在缺陷的情況。

修訂條件/判定覆蓋率（MC/DC）

MC/DC是一種特殊的分支覆蓋率，它不但會使用分支覆蓋率報告復雜條件下的true和false輸出，同時也會報告復雜條件下的全部分支條件輸出。

MC/DC最初由波音公司創(chuàng)建，用于航空軟件中DO-178B的A級認證。通過對所有的子條件輸出分支的獨立證明，有效解決了惰性求值帶來的問題。

繼續(xù)討論代碼示例2，我們需要在“condition2”和“function1（*p）”固定的條件下驗證“condition1” 的“true”和“false”判定分支，之后繼續(xù)固定“condition1”和“function1（*p）”驗證“condition2” 的判定分支。

同樣的，讓我們在固定“condition1”和“condition2”的條件下討論 “function1（*p）”。在其他分支條件固定的情況下驗證某個分支條件的“true”和“false”值稱作“MC/DC對”。MC/DC對一般使用MC/DC真值表描述。表1就是一個MC/DC真值表示例。

在軟件開發(fā)的不同階段獲取覆蓋率

軟件測試有很多種類，本文將其簡要的分為三類：

》 系統(tǒng)/函數(shù)測試： 測試集成后的整個應(yīng)用

》 集成測試：：測試集成的子系統(tǒng)

》 單元測試：測試一個或多個文件或類

每個軟件項目在系統(tǒng)測試的過程中都會模擬最終用戶的操作對源代碼做一些系統(tǒng)測試。導致軟件發(fā)布后仍舊存在缺陷最重要的一個原因通常是程序在運行過程中遇到了非預期的，即沒有測試的輸入組合。

很多軟件項目并不是沒有做集成測試或者單元測試。只是在完成集成測試或單元測試后，開發(fā)團隊可能苦于為隔離程序中的單個或多個文必須所需的大量測試代碼量。

對于最嚴格的單元測試和集成測試來說，最終生成的測試代碼量比待測代碼量還要龐大是很經(jīng)常出現(xiàn)的情況。因此，這兩種級別的測試普遍適用于關(guān)鍵和高安全領(lǐng)域，例如：航空航天、醫(yī)療、交通運輸、工業(yè)過程控制、高速汽車等。此類軟件中包含大量的嵌入式應(yīng)用軟件。

關(guān)鍵領(lǐng)域的結(jié)構(gòu)化測試流程一般會將需求的級別高低作為重點，代碼覆蓋率因而會在這種“基于需求”的測試中進行分析。在許多項目中，高等級的需求最先被測試。此時代碼覆蓋率可以被用來檢測和報告所達到的覆蓋比例。

然而不幸的是，在系統(tǒng)測試和功能測試階段想要達到100%的代碼覆蓋率幾乎是不可能的。通常情況下系統(tǒng)測試和功能測試只能達到60%-70%的代碼覆蓋率，剩余30%-40%的代碼覆蓋率需要在單元測試和集成測試階段才能夠完成。

單元測試使用包含驅(qū)動和樁的測試代碼隔離系統(tǒng)中的特定函數(shù)，同時使用測試用例模擬這些函數(shù)的執(zhí)行。這些所謂的“低等級測試需求” 對被測試代碼提供了更高的控制，可以提高先前執(zhí)行的系統(tǒng)測試覆蓋率（甚至能達到100%）。因此，在不同的測試之間共享覆蓋率數(shù)據(jù)是非常有必要的。

嵌入式環(huán)境中獲取覆蓋率帶來的挑戰(zhàn)

常言道“有得必有失”，在嵌入式環(huán)境獲取代碼覆蓋率的問題上，要付出的代價是對待測代碼額外的插樁工作。

插樁是將額外的代碼添加到程序中，從而實現(xiàn)測試過程中的覆蓋率收集和分析操作。

由于插樁的相關(guān)操作將導致程序源代碼增多，進而延長程序的執(zhí)行時間，因而需要預測插樁后的源代碼的覆蓋范圍預測，尤其當測試實時嵌入式系統(tǒng)環(huán)境時，此項工作就更為重要。

事實上，要精準的預測程序文件插樁的影響幾乎是不可能的。沒有算法支持（也不可能有）。 每個系統(tǒng)都包含很多的變量，具有獨立唯一的復雜性。當然，對于典型的示例系統(tǒng)來說，獲取一組準確的估計還是可能實現(xiàn)的。

在共享環(huán)境中獲取覆蓋率數(shù)據(jù)

在嵌入式環(huán)境下管理代碼覆蓋率的主要問題在于如何配置內(nèi)存以容納額外的插樁代碼。

VectorCAST針對大量示例代碼評估后發(fā)現(xiàn)添加了上文中提出的各種覆蓋率額外配置之后，源代碼量增長量普遍達到了10%。對于絕大多數(shù)的32位目標板，這并不是一個很大的問題，但對于存儲容量有限的8位或者16位目標板來說，幾乎可以肯定這會是一個問題。

為了降低可執(zhí)行文件的大小，各種各樣的代碼插樁技術(shù)被發(fā)明出來，針對不同大小的存儲區(qū)域有不同的數(shù)據(jù)采集技術(shù)。植入存儲器內(nèi)部的收集系統(tǒng)可以用于監(jiān)測被檢測到的代碼。這是插樁技術(shù)中保證使用最少RAM的關(guān)鍵技術(shù)。