對于安全關鍵代碼，確保應用程序執行它應該執行的操作并正確執行這些操作的功能測試只是表面上的問題。應用程序包含隱藏的復雜性，這些復雜性可能會在不可預測的條件下出現。如果編碼不正確，它們可能會導致災難。開發人員必須深入挖掘以測試所有底層代碼是否存在細微錯誤。但這究竟是什么意思？

雖然可以從系統需求文檔手動生成基本功能測試，但使用自動化工具（生成測試工具和測試用例的工具、運行這些測試的工具以及評估測試有效性的工具）進行更深層次的測試會更有效。 最后，關鍵活動是通過覆蓋分析完成的。

在基本層面上，函數（或過程）覆蓋分析顯示每個函數是否已被調用。語句覆蓋更進一步，提供了一種方法來確保每一行代碼至少被執行一次。但是雖然這些都很有用，但覆蓋分析不僅僅是函數和語句覆蓋。

安全關鍵代碼需要更深入的分析

可以在多個級別測試代碼，安全關鍵代碼需要深入、徹底的研究。分支/決策覆蓋提供了更徹底的檢查，旨在證明每個分支至少被采用一次，而分支條件組合覆蓋需要測試所有可能的條件組合。

這聽起來很簡單，但如果一個決定取決于四個或更多條件，那么測試每個組合的要求就會變得不合理。修改條件/決策覆蓋或 MC/DC 旨在提供一種實用的替代方案。MC/DC 確保：

調用每個入口和出口點

每一個決定都有每一個可能的結果

決策中的每個條件都包含所有可能的結果

決策中的每個條件都顯示為獨立地影響決策的結果

函數調用覆蓋擴展了該查詢線，并通過生成有關已執行哪些函數調用的信息來構建函數覆蓋概念。這很重要，因為錯誤通常發生在模塊之間的接口中。

在某些情況下，例如受 DO-178C 等標準約束的關鍵航空電子應用，還需要進行更苛刻的測試。對于最關鍵的“DAL A”應用，DO-178C 需要目標代碼驗證，其中包括分析匯編代碼和源代碼的覆蓋信息。

動態測試通常使用軟件工具進行，該工具檢測源代碼的副本以在運行時提供覆蓋率數據。隨后分析該數據以準確揭示代碼的哪些部分已被執行，以及執行到什么級別。它以數據和控制流程圖以及帶有符號的源代碼等顯示形式使開發人員可以看到結果（圖 1）。

【圖1 | LDRA 的 TBvision 代碼覆蓋為 DO-178C 等安全關鍵標準提供語句、分支和 MC/DC 覆蓋。背景是一個分支/決策圖，交叉引用了帶注釋的源代碼。前景是每個功能和通過/失敗結果的覆蓋范圍摘要。］

使用自動化工具減輕瑣碎的測試任務

動態分析可以應用于完整的應用程序（系統測試）或它的子集（單元測試，包括集成組件測試），并且通常在完整系統可用時使用這兩種方法的組合。一個集成的工具套件整理來自兩個來源的信息，以提供整體覆蓋率指標。單元測試工具通過靜態分析代碼結構，然后圍繞應用程序創建一個“線束”或框架，在測試期間注入輸入并接收輸出，從而減輕了設置測試環境的繁瑣工作。對于安全關鍵型應用程序，“測試向量”必須基于要求，以提供證據證明代碼對預期和未預期的輸入都按預期執行，但仍滿足要求，僅此而已。

還可以通過對源代碼的深入靜態分析自動生成測試向量，這通常會導致在運行時覆蓋 50% 到 75% 的代碼。顯然，這并不能提供正確功能的證據，但它確實在非關鍵應用程序中占有一席之地，否則覆蓋率分析可能不會發生。即使在關鍵應用程序中，這種方法通過驗證面對邊界值、空指針和默認 switch 語句條件等數據的穩健行為，將動態分析超越了基于需求的測試。

在開發周期中盡早開始單元測試是最具成本效益的，甚至可能在目標硬件可供開發人員使用之前。這意味著使用在主機開發系統和目標硬件上應用相同測試向量的工具非常重要，以便生成一次測試用例，從而節省時間和金錢。

一個完整的工具套件還可以提供數據和控制流分析形式的分析，這是 DO-178C（航空電子）和 ISO 26262（汽車）等標準所要求的，以確保功能的每次調用都已執行，并且對數據的每次訪問都已執行。它通過源代碼跟蹤變量并報告異常使用（圖 2）。

【圖2 | 基于當前測試運行的變量和參數使用報告突出顯示文件中使用變量的文件和位置，并使用允許更精細測試的自定義過濾器。］

這種深層次的測試——以及對測試的徹底和嚴格的評估——只有使用一套集成的軟件分析工具才能可靠地完成。

審核編輯：郭婷