對覆蓋率分析的討論可能會提出許多不同的假設，這些假設并不總是一致的。這是否意味著檢查所有代碼是否已執(zhí)行？這是否意味著所有要求都已得到執(zhí)行和測試？它是否帶來了一些 100% 以外的數(shù)字可以依賴的功能代碼？我們要做的是確保自己，即使在危及生命的情況下，程序也已經(jīng)過徹底的測試，可以信賴。我們?nèi)绾螌崿F(xiàn)這一目標以及覆蓋范圍的哪些方面？會讓我們高枕無憂嗎？

軟件測試和分析可以被認為是由許多相互依賴的部分組成的整體活動。其中包括需求跟蹤、靜態(tài)和動態(tài)分析、編碼標準合規(guī)性等，包括覆蓋范圍分析。歸根結底，覆蓋率分析應該讓我們了解一段代碼的測試程度和徹底程度。當然，這取決于其他測試方法的應用程度和徹底性及其結果。因此，它實際上是對我們測試的測試，而不是對程序本身的測試。

那么，是什么可以讓我們很好地了解我們測試的好壞呢？

一種方法可能是檢查程序中的所有行是否已執(zhí)行。然而，僅憑這一點并不能告訴我們執(zhí)行路徑是如何到達這些行的，或者它以什么順序和在什么條件下這樣做。它與需求沒有直接關系。畢竟，這些要求是首先生成自動和手動測試的基礎。

覆蓋率的另一個做法是分支覆蓋率，它顯示了代碼段之間的執(zhí)行路徑，但不一定是每一行。分支覆蓋率可以根據(jù)執(zhí)行路徑揭示程序的結構。分支是“這個”或“那個”。它告訴我們執(zhí)行可以走哪條路，但它沒有說明為什么代碼會以一種或另一種方式進行。這為我們提供了執(zhí)行結構的圖片，但即使它揭示了所有分支在執(zhí)行過程中至少執(zhí)行過一次，它也沒有顯示從分支獲取一條或另一條路徑的條件。也就是說，它不一定表示所有情況（布爾表達式、條件）都經(jīng)過測試，或者至少測試了所有滿足要求的情況。

表達式“如果 A 是分支”。當然，它可能是一個更復雜的表達式，會導致真或假 A，因此 A 的結果值就是決策。決策覆蓋率意味著每個點分支至少被調(diào)用過一次，并且每個分支采取的所有決策都至少執(zhí)行過一次。這是比分支覆蓋率更強的度量，因為它將分支鏈接到路徑。因此，旨在執(zhí)行程序中每個決策點的每個結果的測試就是分支決策測試。但是，每個結果的執(zhí)行并不涉及可能導致該（如果，那么）決定的不同輸入和條件。為此，我們必須轉向分支/決策測試及其表親，修改條件/決策覆蓋率（MC / DC）。

MC/DC 使用每個條件至少調(diào)用一次程序中的每個進入和退出點，以便決策至少一次采取所有可能的結果，并且可以證明更改決策中的任何條件可以獨立影響該決策。一個條件被證明通過改變該條件同時保持固定所有其他可能的條件來獨立地影響決策的結果。

雖然指標很棒，但僅靠指標并不能幫助我們確信我們的代碼將按照我們預期的方式工作。測試必須與程序的要求相關 - 程序是否做了它應該做的事情 - 并且這些測試必須是生成和跟蹤適當覆蓋指標的測試。這種觀點 - 通過可追溯性增強覆蓋范圍 - 是DO-178B和IEC 61508等不同標準所描述的功能安全的關鍵。這種組合使我們能夠知道代碼做了它應該做的事情——我們已經(jīng)通過測試場景執(zhí)行了它。

審核編輯：郭婷