跳轉到內容

軟體工程/工具/程式碼覆蓋率簡介

來自華夏公益教科書,開放的世界,開放的書籍

程式碼覆蓋率是軟體測試中使用的一種度量。它描述了程式原始碼被測試的程度。它是一種直接檢查程式碼的測試形式,因此是一種白盒測試形式。[1]隨著時間的推移,程式碼覆蓋率的使用已經擴充套件到數字硬體領域,其當代設計方法依賴於硬體描述語言 (HDL)。

程式碼覆蓋率是最早為系統軟體測試發明的方法之一。第一個公開發表的參考文獻是 Miller 和 Maloney 在 1963 年的《ACM 通訊》中發表的。

程式碼覆蓋率是航空電子裝置安全認證中的一個考慮因素。聯邦航空管理局 (FAA) 對航空電子裝置進行認證的標準記錄在 DO-178B 中。[2]

覆蓋率標準

[編輯 | 編輯原始碼]

為了衡量測試套件對程式的測試程度,使用一個或多個覆蓋率標準

基本覆蓋率標準

[編輯 | 編輯原始碼]

有許多覆蓋率標準,主要標準包括:[3]

  • 函式覆蓋率 - 程式中的每個函式(或子例程)是否都被呼叫過?
  • 語句覆蓋率 - 程式中的每個節點是否都被執行過?
  • 判定覆蓋率(與分支覆蓋率不同 - 請參見 Position Paper CAST10.[4]) - 程式中的每個邊是否都被執行過?例如,每個控制結構(例如 IF 和 CASE 語句)中每個分支的要求是否都得到滿足,以及未得到滿足?
  • 條件覆蓋率(或謂詞覆蓋率) - 每個布林子表示式是否都被評估為真和假?這並不一定意味著判定覆蓋率。
  • 條件/判定覆蓋率 - 判定和條件覆蓋率都應該得到滿足。

例如,考慮以下 C++ 函式

int foo(int x, int y)
{
    int z = 0;
    if ((x>0) && (y>0)) {
        z = x;
    }
    return z;
}

假設此函式是某個更大程式的一部分,並且該程式已使用一些測試套件執行過。

  • 如果在執行過程中,函式“foo”至少被呼叫過一次,那麼此函式的函式覆蓋率就得到滿足。
  • 此函式的語句覆蓋率將得到滿足,例如,如果它被呼叫為 foo(1,1),因為在這種情況下,函式中的每一行都會被執行,包括 z = x;
  • 呼叫 foo(1,1)foo(1,0) 的測試將滿足判定覆蓋率,因為在第一種情況下,if 條件得到滿足並執行 z = x;,而在第二種情況下則沒有。
  • 條件覆蓋率可以透過呼叫 foo(1,1)foo(1,0)foo(0,0) 的測試來滿足。這些測試是必要的,因為在前兩種情況下 (x>0) 的值為 true,而在第三種情況下則為 false。同時,第一種情況下 (y>0) 的值為 true,而在第二種和第三種情況下則為 false

在像 Pascal 這樣的語言中,標準布林運算不進行短路,條件覆蓋率並不一定意味著判定覆蓋率。例如,考慮以下程式碼片段

if a and b then

條件覆蓋率可以透過兩種測試來滿足

  • a=trueb=false
  • a=falseb=true

但是,這組測試並不滿足判定覆蓋率,因為在這兩種情況下,if 條件都不會滿足。

可能需要故障注入才能確保所有條件和異常處理程式碼的分支在測試期間都有足夠的覆蓋率。

修改後的條件/判定覆蓋率

[編輯 | 編輯原始碼]

對於安全關鍵型應用程式(例如航空電子軟體),通常要求滿足修改後的條件/判定覆蓋率 (MC/DC)。此標準擴充套件了條件/判定標準,要求每個條件都應獨立地影響判定結果。例如,考慮以下程式碼

if (a or b) and c then

條件/判定標準將透過以下測試集得到滿足

  • a=true, b=true, c=true
  • a=false, b=false, c=false

但是,以上測試集不會滿足修改後的條件/判定覆蓋率,因為在第一個測試中,'b' 的值,在第二個測試中,'c' 的值不會影響輸出。因此,需要以下測試集來滿足 MC/DC

  • a=false, b=false, c=true
  • a=true, b=false, c=true
  • a=false, b=true, c=true
  • a=true, b=true, c=false

粗體值會影響輸出,每個變數必須至少作為一次影響值為假,一次影響值為真。

多條件覆蓋率

[編輯 | 編輯原始碼]

此標準要求測試每個判定中的所有條件組合。例如,上一節中的程式碼片段將需要八個測試

  • a=false, b=false, c=false
  • a=false, b=false, c=true
  • a=false, b=true, c=false
  • a=false, b=true, c=true
  • a=true, b=false, c=false
  • a=true, b=false, c=true
  • a=true, b=true, c=false
  • a=true, b=true, c=true

其他覆蓋率標準

[編輯 | 編輯原始碼]

還有一些其他不太常用的覆蓋率標準

  • 線性程式碼序列和跳轉 (LCSAJ) 覆蓋率 - 每個 LCSAJ 是否都被執行過?
  • JJ-路徑覆蓋率 - 所有跳轉到跳轉路徑[5](也稱為 LCSAJ)是否都被執行過?
  • 路徑覆蓋率 - 程式碼給定部分中的所有可能路徑是否都被執行過?
  • 入口/出口覆蓋率 - 函式的所有可能呼叫和返回是否都被執行過?
  • 迴圈覆蓋率 - 每個可能的迴圈是否都被執行過零次、一次和多次?

安全關鍵型應用程式通常要求證明測試已實現某種程式碼覆蓋率的 100%。

上述某些覆蓋率標準是相互關聯的。例如,路徑覆蓋率意味著判定、語句和入口/出口覆蓋率。判定覆蓋率意味著語句覆蓋率,因為每個語句都是分支的一部分。

如上所述,完全路徑覆蓋通常不切實際或不可能。任何包含一系列 決策的模組,最多可能包含 條路徑;迴圈結構會導致無限條路徑。許多路徑也可能是不可行的,因為沒有輸入到被測程式可以導致執行該特定路徑。但是,已被證明不可能找到識別不可行路徑的通用演算法(這樣的演算法可以用於解決停止問題)。[6] 用於實際路徑覆蓋測試的方法試圖識別僅在迴圈執行次數上有所不同的程式碼路徑類別,為了實現“基本路徑”覆蓋,測試人員必須覆蓋所有路徑類別。

在實踐中

[edit | edit source]

目標軟體是用特殊選項或庫構建的,或者在特殊環境下執行,這樣程式中執行的每個函式都映射回原始碼中的函式點。此過程允許開發人員和質量保證人員查詢在正常情況下很少或從未訪問過的系統部分(錯誤處理等),並幫助測試工程師確保測試了最重要的條件(函式點)。然後分析生成的結果,檢視程式碼中哪些部分尚未執行,並根據需要更新測試以包含這些部分。結合其他程式碼覆蓋方法,目標是開發一套嚴格且可管理的迴歸測試。

在軟體開發環境中實施程式碼覆蓋策略時,必須考慮以下因素:

  • 最終產品認證的覆蓋率要求是什麼,如果是,需要達到多少程式碼覆蓋率?典型的嚴格程度進展如下:語句覆蓋,分支/決策覆蓋,修改條件/決策覆蓋(MC/DC),LCSAJ(線性程式碼序列和跳轉)
  • 是否會針對驗證被測系統要求的測試衡量程式碼覆蓋率(DO-178B)?
  • 生成的機器碼是否可以直接追溯到原始碼語句?某些認證(例如 DO-178B A 級)要求在彙編級別進行覆蓋,如果不是這樣:“那麼,應該對機器碼執行額外的驗證以確定這些生成的程式碼序列的正確性”(DO-178B)para-6.4.4.2。[7]

測試工程師可以檢視程式碼覆蓋率測試結果,幫助他們設計測試用例和輸入或配置集,以提高重要功能的程式碼覆蓋率。測試人員使用的兩種常見的程式碼覆蓋率形式是語句(或行)覆蓋率和路徑(或邊)覆蓋率。行覆蓋率根據執行測試時執行的程式碼行數來報告測試的執行覆蓋範圍。邊覆蓋率報告執行測試時執行的分支或程式碼決策點。它們都報告一個覆蓋率指標,以百分比衡量。這個指標的含義取決於使用過哪些形式的程式碼覆蓋率,因為 67% 的路徑覆蓋率比 67% 的語句覆蓋率更全面。

一般來說,程式碼覆蓋率工具和庫會消耗一定量的效能和/或記憶體或其他資源,這對於軟體的正常執行來說是不可接受的。因此,它們只在實驗室中使用。正如人們所期望的那樣,有一些軟體類別不能實際進行這些覆蓋測試,儘管可以透過分析而不是直接測試來近似地實現一定程度的覆蓋對映。

也有一些缺陷會受到這些工具的影響。特別是,一些競爭條件或類似的即時敏感操作在程式碼覆蓋環境下執行時可能會被掩蓋;相反,由於測試程式碼的額外開銷,一些這些缺陷可能會更容易發現。

軟體工具

[edit | edit source]

C/C++ 工具

[edit | edit source]
  • CodeScroll 控制器測試器
  • VectorCAST
  • Parasoft C++test
  • Cantata++
  • Insure++
  • IBM Rational Pure Coverage
  • Tessy
  • Testwell CTC++
  • Trucov

C# .NET 工具

[edit | edit source]
  • Parasoft dotTEST
  • NCover
  • Testwell CTC++(帶 C# 外掛)

Java 工具

[edit | edit source]
  • Parasoft Jtest
  • Clover
  • Cobertura
  • Structure 101
  • EMMA
  • Serenity
  • Testwell CTC++(帶 Java 和 Android 外掛)

PHP 工具

[edit | edit source]
  • PHPUnit,還需要 Xdebug 才能生成覆蓋率報告

硬體工具

[edit | edit source]
  • Aldec
  • Atrenta
  • Cadence Design Systems
  • JEDA Technologies
  • Mentor Graphics
  • Nusym Technology
  • Simucad Design Automation
  • Synopsys

備註

[edit | edit source]
  1. Kolawa, Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 254. ISBN 0470042125. {{cite book}}: More than one of |pages= and |page= specified (help); Unknown parameter |coauthors= ignored (|author= suggested) (help)
  2. RTCA/DO-178(b), 空中系統和裝置認證軟體考慮因素,航空無線電技術委員會,1992 年 12 月 1 日。
  3. Glenford J. Myers (2004). The Art of Software Testing, 2nd edition. Wiley. ISBN 0471469122.
  4. [1]
  5. M. R. Woodward, M. A. Hennell, "關於兩種控制流覆蓋標準之間的關係:所有 JJ 路徑和 MCDC", 資訊與軟體技術 48 (2006) pp. 433-440
  6. Dorf, Richard C.: 計算機、軟體工程和數字裝置,第 12 章,第 15 頁。CRC 出版社,2006 年。 ISBN 0849373409,9780849373404;透過 谷歌圖書搜尋
  7. 機載系統和裝置認證中的軟體注意事項 - RTCA/DO-178B,RTCA 公司,華盛頓特區,1992 年 12 月
[編輯 | 編輯原始碼]
華夏公益教科書