在軟件測試領域，MC/DC或許已經是一個耳熟能詳的詞匯了，但是我們還是要不斷強調如何正確使用MC/DC以及它與安全相關的重要作用。

在測試中，想要對所有變量進行100%的測試幾乎是不可能的。有限的時間和資本成本也決定了測試人員無法對軟件進行徹底完盡的測試。但是，測試是為軟件質量保駕護航的關鍵，不可或缺。所以對測試人員的挑戰就在于如何合理的分配測試資源以及最優化地使用這些資源。選擇一個“完成標準”并據此對測試目標進行計劃和優先排序，這可能是一個測試團隊成功與否的關鍵所在。

測試計劃是基于測試目標來制定的，可以有不同的顆粒度。首先，針對測試組織給出的一般定義開始制定計劃，對每個測試層級上的測試對象以及每次發布的內容都給出詳細的信息。本質上來講，對測試目標的定義就隱含了衡量信息，從而決定了哪些內容應該測試，哪些內容無需測試。產品的開發階段和邊界條件會最大程度地影響測試目標的制定。

同時，測試也要符合安全標準。在軟件測試中，標準是非常重要的，尤其在安全相關的產品測試中。這些標準對安全相關產品的驗證提出了很高的要求。IS026262-6中指出，需求覆蓋度和結構覆蓋度都必須由恰當的覆蓋度量來測量。這也可以視作是對驗證完整性的評估。對最高安全等級（ASIL-D）的軟件來說，單元級的MC/DC（修正條件/判定覆蓋）是強烈推薦的。

有些人可能會因此認為MD/DC就是測試目標。實則非也。測試目標的定義是驗證被測軟件的屬性。被測單元正確的功能性應該是測試的首要目標。MC/DC僅僅展示了是否所有的判定和條件都能通過測試，并不能用來驗證系統是否正確無誤的運行。因此，覆蓋度是不能作為測試目標的。

一般來說，覆蓋度量只能作為測試完成的標準。測試完成的標準指被測系統在何時被認為是充分測試的。測試目標和測試完成標準都在測試概念中有明確的定義。建議測試人員們在每次版本迭代發布時更新測試概念，以明確具體實施中的變化及其可能帶來的影響。

如何提高MC/DC測試效率？

首先，定義基于需求的測試用例。將需求表示為用例和使用需求，例如邊界值的考慮或者等價類的構建。這會幫助測試人員驗證被測軟件是否具備理想中的完整功能。這會幫工作人員開個好頭。通過測量代碼覆蓋度，測試人員可能會發現尚未測試的漏洞，并據此編寫相應的測試用例。

覆蓋度的目標值是100%。ISO26262要求對那些未達到100%的情況做出解釋。如果測試項目中包含一些測試不到的部分，例如用于調試的部分或者并行軟件的配置。我們建議直接在報告中闡述覆蓋度降低的原因，而不是在測試之前預先設置一個較低的覆蓋度目標值。這樣能提高整體測試效率，因為測試人員無需在每次改變測試單元時通過復雜的計算重新檢查和調整那些需要減少的覆蓋度值。

如果通過上述方法測試卻沒有達到100%的覆蓋度，可能是由于以下幾個原因:

1. 需求缺失或不完整

2. 測試用例不夠

3. 測試用例識別了無效的、不可訪問的或禁用的代碼，或者非預期的功能

因為ISO26262要求對每一個偏差值都做出合理解釋，對相關部分的代碼進行可視化能夠幫助測試人員快速找出導致問題的原因。（見圖1）

測試往往取決于需求的質量以及軟件的設計和所選的架構。為了使測試工作盡可能高效，建議測試人員了解軟件架構和軟件設計對測試過程的影響，以選擇合適的架構和設計模式。

因此，測試過程中與軟件架構和設計人員的溝通也很重要。軟件架構師和設計師是縱觀整個軟件產品的生命周期，并有機會通過重組和分離對軟件發布產生重大影響的人。

TPT與MC/DC

北匯信息和Piketec希望幫助客戶輕松快速地滿足所需的指標。為了實現這一目標，我們將在TPT 18中增加了兩個MC/DC新功能：

1.測量C/C++和Simulink的MC/DC覆蓋率；

2.使用TPT自動生成測試用例:通過這種方式，用戶可以快速且輕松地將覆蓋率提高到100%。

我們對算法進行了調整，用盡可能少的測試用例來做MC/DC測試。無需自己創建測試用例，只需要執行和維護最小數量的測試用例即可，也不需要購買額外的測量工具來確定覆蓋率，將為客戶節省大量的時間和資金成本。