時間就是軟件開發中的一切。想想發現軟件缺陷的時間。在發布后發現，這可能是一場災難，危及人們的安全并造成數百萬美元的損失。在發布之前發現，缺陷可以減少到僅僅是一個煩惱。

這就是為什么軟件測試已成為開發生命周期中不可或缺的一部分。事實上，根據 Fraunhofter Esk 研究所 2012 年的一項調查，測試不僅是軟件開發過程的重要部分，對于大多數嵌入式系統開發人員來說，它也是最困難的部分。

由于許多原因，測試可能很困難，但最基本的挑戰之一是衡量進度。在測試期間未能使用可靠的指標跟蹤進度可能會浪費時間并導致軟件質量下降。試圖忽略指標并以測試所有內容為目標是很誘人的，但這種方法很危險，因為軟件測試有可能成為一項無止境的工作。Glennford Myers 在 1976 年的《軟件可靠性：原則與實踐》一書中證明了這一點，當時他表明一個 100 行的程序可以有多達 1018 條獨特的路徑。在現代軟件開發世界中，軟件可以增長到數百萬行代碼。這使得完全詳盡的測試不可行。

此外，通常不僅僅是軟件開發團隊需要對測試水平感到滿意?？蛻艨赡軙筇峁┐a經過適當測試的證據，而航空電子、汽車和醫療領域等安全關鍵行業的監管機構將需要證明對缺陷進行了充分檢查的證據。因此，有必要定義一種衡量“充分”測試的方式，并且需要以一種可以客觀衡量的方式來完成，以滿足開發過程中的所有利益相關者。

對于有效的軟件測試，開發人員需要解決如何衡量測試過程，如何確定多少測試足夠，以及開發團隊如何能夠最具戰略性地確保他們開發的軟件應用程序已經過充分測試。

什么是代碼覆蓋率？

結構代碼覆蓋率分析是一種查看程序邏輯結構的哪些部分在測試執行期間已被執行或“覆蓋”的方法。邏輯結構取決于所使用的代碼覆蓋率指標。例如，“入口點”覆蓋查看在測試中執行了哪些函數調用或“入口點”。同樣，“動態數據流”覆蓋查看數據流的哪些部分已被執行。雖然不同的結構覆蓋率指標從不同的角度檢查代碼，但它們都有一個共同的目的，即通過顯示測試了多少代碼以及執行了代碼的哪些部分來對測試過程提供有意義的洞察。

專門的結構覆蓋度量可以為特殊的測試用例提供服務，例如分析數據和控制耦合。但是，為了衡量一般測試的有效性，三個代碼覆蓋率指標已在行業中得到廣泛使用：

語句覆蓋率 （SC） –已執行程序的多少語句

決策覆蓋率 （DC） –已執行了多少個決策分支；這實際上是語句覆蓋的超集，因為要覆蓋所有決策的所有分支，還必須覆蓋所有語句

修改的條件/決策覆蓋（MC/DC）——這建立在決策覆蓋的基礎上，確保復雜決策的每個子條件在其真假狀態下獨立執行

這些指標已被廣泛認為是衡量測試徹底性的方法。特別是，汽車、航空電子和工業軟件等行業已經在其軟件安全標準中采用了這些指標。

更高的關鍵性需要更徹底的測試

值得注意的是，這些軟件安全標準并未強制要求在所有項目中統一使用聲明、決策和 MC/DC 覆蓋率。相反，每個主要的行業軟件安全標準都建議根據代碼的關鍵程度使用不同級別的結構覆蓋，盡管關鍵級別通常以特定行業的方式確定。例如，航空電子行業的軟件安全標準 DO-178C 使用軟件安全級別的概念，并要求對每個安全級別進行不同級別的結構覆蓋分析。

IEC 61508 是一種通用工業軟件安全標準，它定義了安全完整性等級 （SIL），并根據每個等級推薦了不同的結構覆蓋率指標。

在所有這些標準中，可以看到一個共同的理念：代碼必須“越安全”，所需測試的徹底性就越高。軟件安全意味著什么的確切定義取決于特定行業的關注點、經驗和監管壓力，但這種將所需的更高級別的安全性與所需的更高級別的結構覆蓋相匹配的一般原則在整個標準中保持不變。

測試應源于需求

軟件安全標準中跨行業的另一個共同點是認為測試應該從需求中產生。軟件需求應確定測試所需的輸入和輸出。如果他們不這樣做，測試可能會成為一組并行的需求，這會導致混亂和軟件錯誤。結構覆蓋率不能取代需求作為測試的基礎，因為覆蓋率指標不能決定代碼的行為方式——只有在執行期間可以訪問（并且，考慮到調試器的能力，在執行期間可以訪問可以是一個靈活的概念）。

雖然是互補的，但測試執行代碼的有效性和測試需求的完整性是兩件不同的事情。在結構覆蓋分析中衡量的測試有效性著眼于代碼的哪些部分被執行。測試完整性，有時稱為“需求覆蓋率”，查看代碼是否已經針對所有需求的正確行為進行了測試。如果一個軟件程序是根據其需求構建的，并且如果它不包含與其需求無關的代碼，那么對需求的完整測試應該會導致測試有效地執行所有代碼。如果有代碼沒有被測試執行，這可能是可以刪除的代碼，或者可能是缺少的需求，或者可能是測試中的缺陷。這樣，

執行代碼和測試需求之間的這種關系也存在于單個需求的層面上。雖然從證據收集的角度來看，有多少需求和測試了多少代碼的高級總計更有趣，但更多的是在單個需求測試級別，以及該單個需求測試的結構覆蓋分析，其中大多數缺陷被識別和修復。

結構覆蓋分析通常被認為是實現 100% 指標的簡單目標，但檢查單個測試及其產生的結構覆蓋至關重要。當正在執行的代碼基于正在測試的需求時，尤其如此。通過檢查代碼的結構覆蓋率，可以確定被測代碼的確切行為，并將其與基于被測需求的預期行為進行比較。這種方法減少了由于環境因素或代碼的其他部分補償不正確代碼而導致的誤報。此外，如果存在不正確的行為，結構覆蓋分析通常還可以提供對不正確行為原因的洞察。

當使用結構覆蓋分析以這種詳細的方式理解代碼行為時，能夠將結構覆蓋分析結果覆蓋在代碼結構分析之上是至關重要的。此覆蓋有助于將原始結構覆蓋信息轉換為對代碼中正在發生的事情的有意義的理解。

在單元和系統級別設置覆蓋目標

通常，結構覆蓋分析目標可以在單元和系統級別設置。單元級別的結構覆蓋是通過基于該單元要求的單元級別的測試來實現的。另一方面，系統級覆蓋目標通常從更高級別需求的測試覆蓋開始。然而，如果僅使用高級測試進行系統級覆蓋分析，則覆蓋中經常會出現漏洞。這些漏洞的原因可能會有所不同。在某些情況下，覆蓋漏洞可能是由于編碼標準要求的防御性編程實踐造成的，但這些覆蓋漏洞也可能基于從需求中實現的重要功能。

特別是，當代碼基于只能通過難以或不可能在高級別上創建的條件進行測試的需求時，可能會出現結構覆蓋漏洞。這種場景的一個例子是文件系統故障的功能級檢查。雖然通?？赡軙е挛募到y故障，但要對文件系統故障進行計時以使其在該函數的執行期間發生是非常具有挑戰性的。此外，以可重復的方式為將來的回歸測試執行此操作可能會更加困難。在這種情況下，可能需要使用單獨檢查代碼的較低級別的測試。出于這個原因，在收集實現測試目標的指標時，從較高級別測試測量的結構覆蓋率通常與來自較低級別測試的結構覆蓋率相結合。

聲明、決策或 MC/DC 覆蓋率等指標并不能保證軟件沒有缺陷。如前所述，真正詳盡的測試可能是不可能的，或者至少是不可行的。然而，結構覆蓋率度量可以更好地了解代碼的可靠性和對測試的更大信心。

由于結構覆蓋分析通過顯示測試了多少代碼以及執行了代碼的哪些部分來深入了解測試活動，因此它可以在系統、模塊或單元級別執行，并且可以累積到測試目標。 代碼覆蓋率不應與基于需求的測試隔離開來。此外，除了結構覆蓋分析之外，可能還需要執行一些測試。例如，測試競爭條件和整數限制邊緣條件對于檢測缺陷可能很有價值，但它們可能無助于您的結構覆蓋目標。結構覆蓋分析旨在衡量您已完成的測試并指導您的測試計劃，但不應將其視為目標。

謹防！

在不了解測試的情況下積累結構覆蓋可能會提供一種錯誤的安全感，這比不充分的測試更危險。結構覆蓋分析不是靈丹妙藥，而是需要智能和謹慎使用的工具。但是，如果使用得當，它是一種工具，可以使測試更有用、更有效，并為測試過程提供證據。

審核編輯：郭婷