當嵌入式開發人員測試他們的軟件時，有多種力量在起作用。由于對更大的計算工作負載、更廣泛的連接以及改進的安全性的需求，系統的復雜性不斷增加，這使得開發人員更難根據需求驗證代碼。隨著發布時間的縮短，測試團隊努力使傳統的測試方法適應更大的復雜性和規模。

需要一種新的測試方法，團隊正在尋求數學上證明的代碼正確性，以顯著提高對其應用程序的信心。要了解當今的產品目標與傳統測試方法之間的差距，考慮復雜性如何影響測試會有所幫助：

覆蓋。隨著軟件復雜性的增長，創建涵蓋足夠級別的代碼庫（包括函數、語句、路徑、決策和條件）的測試變得越來越困難。

規模。無論測試范圍（特性、組件、庫或功能）如何，單元越多，測試它們所需的時間和資源就越多。

速度。傳統的測試開發和執行實踐無法跟上發布時間表的步伐，不可避免地迫使在測試覆蓋率和時間之間進行權衡。

長期以來，人們一直認為接近 100% 的代碼覆蓋率是不可能的，因為這樣的目標極難實現且運行成本高昂。單元測試、滲透測試、動態分析 – 所有傳統技術都需要大量的時間和資源來執行，并導致對系統中錯誤和漏洞的不完整視圖。

隨著軟件技術和計算能力的最新進步，這種信念現在已成為一個被證明的神話。學術和行業研究人員已經開發出數學上嚴格的技術，稱為形式化方法，可實現高達 100% 的代碼覆蓋率并保證系統的正確性 - 現在可供企業就緒平臺中的安全和安保關鍵型開發團隊使用。

了解基于正式方法的測試工具

在紙面上，形式化方法明確證明代碼沒有錯誤和安全漏洞等問題。這些方法使用嚴格指定的數學模型，根據精確定義的規范驗證軟件的屬性和行為。換句話說，形式化方法可以找到代碼中出現的所有問題。

在實踐中，任何開發人員都可以使用且負擔得起基于企業級正式方法的測試工具。它們被稱為詳盡的靜態分析工具，經過精心設計和驗證，可將正式方法的強大功能集成到安全和安保關鍵型開發團隊的現有驗證和確認流程中。

與傳統的測試和靜態分析方法相比，這些工具有幾個優點：

高達 100% 的應用程序覆蓋率，涵蓋所有可能的功能、語句、路徑、決策和條件。

高達 100% 的輸入覆蓋率，涵蓋被測單元范圍內的所有可能值。

數學保證代碼中沒有未定義的行為（錯誤和漏洞），導致部署中零問題。

零漏報，因此開發人員可以增強發現所有問題的信心。

誤報率低至零，這意味著開發人員花在追逐并非真正問題上的時間更少。

顯著縮短測試時間，提高資源消耗效率。

圖 1 說明了差異。傳統的測試方法通常是測試用例開發和算法設計的“最大努力”嘗試，受到人力和項目進度的限制。這會導致測試每次運行執行一個代碼分支，并限制團隊在給定測試階段可以覆蓋的內容。以正式方法為后盾的詳盡靜態分析可在單次測試運行中并行分析所有分支，將覆蓋率提高到 100%，并顯著縮短測試時間。

圖 1：傳統測試方法（左）和聲音靜態分析（右）之間的代碼路徑比較。訪問的段以橙色顯示;未訪問的段為黑色。

詳盡的靜態分析可以為開發人員提供一種強大的方法來管理軟件復雜性，從而極大地改變他們對軟件復雜性的看法。

詳盡的靜態分析如何提供幫助

傳統測試方法的一個限制是它們的狀態空間覆蓋，即數據值和輸入、控制和數據流的不同組合的數量以及它們可以覆蓋的輸出路徑的固有限制。例如，傳統的測試方法通常會在給定預期輸入的情況下測試預期輸出的函數。一些靜態分析工具對此進行了擴展，以涵蓋更廣泛的輸入和輸出。但由于測試設計、實現和計劃約束，這些工具無法測試所有可能的行為。

下面的代碼示例演示了一個遞增數組中的單元格值的 C 函數。

典型的單元測試將根據函數的要求進行驗證，檢查函數是否遞增了輸出數組中的單元格值，并根據結果報告通過或失敗。此測試不一定會檢查數組索引 *p 是否由于系統中意外或不希望的副作用而導致越界內存訪問 - 就像本代碼示例中由于 while 循環中指定的不正確條件而發生的那樣。

盡管存在緩沖區溢出，但針對要求的傳統測試將在調用函數后驗證數組是否為 {2， 4， 6， 8}，并且始終通過，如以下控制臺輸出所示：

除非測試設計者考慮越界數組訪問的可能性，否則永遠不會識別此緩沖區溢出。

這些類型的細微缺陷可能導致內存損壞，從而導致潛在的錯誤、崩潰或應用程序漏洞 - 傳統測試方法不可見，但可以通過詳盡的靜態分析工具發現，如圖 2 所示。該工具檢測到數組開頭后有 16 個字節的寫入：緩沖區溢出。

圖 2：在 TrustInSoft 詳盡靜態分析工具中查找結果的屏幕截圖。

這種內存損壞可以通過更詳細的測試用例來揭示，其中越界寫入條件會影響變量名稱的值，即使它不參與測試的函數，如以下控制臺輸出所示：

但是，開發團隊很少實現此級別的測試深度，尤其是當代碼比此示例更復雜時。

硬件感知在靜態分析中的重要性

更 高級 的 詳盡 靜態 分析 工具 為 驗證 和 確認 活動 帶來 硬件 感知， 從而 實現 更 準確 和 高效 的 測試 覆蓋率。硬件感知的重要性怎么強調都不為過，因為編譯器實現、硬件架構和內存對齊的差異可能導致測試條件和代碼行為大不相同。例如：

在 64 位目標上，long 通常為 64 位，int 通常為 32 位。

在 32 位目標上，long 和 int 通常都是 32 位。

這些硬件差異會影響測試條件、輸入和路徑，如以下代碼示例所示：

如果沒有硬件感知，測試或分析方法將無法確定最后一條語句是否導致整數溢出（32 位目標）或不導致整數溢出（64 位目標）。在某些情況下，測試將執行比必要的更多的運行，以涵蓋硬件支持范圍之外的條件。在其他情況下，測試可能只是錯過潛在的溢出。硬件感知靜態分析在 100% 覆蓋率和實現覆蓋率所需的最少測試用例數量之間提供了完美的平衡。

另一個關鍵的硬件差異是字節序，如以下代碼示例所示：

根據底層硬件的字節序，變量 c 將設置為 0xBE（大端序）或0xEF（小端序）——這是測試執行的關鍵區別。

這種微妙的差異可能會導致災難性的結果。請考慮將以下語句添加到上述代碼示例中的情況：

在大端系統上，此語句將導致除以零條件，并可能導致應用程序崩潰或其他不良行為。在小端系統上，此語句是有效的。了解這些差異的測試方法可以得出更準確的結果。

包含硬件感知的詳盡靜態分析工具還具有以下優點：

開發人員可以運行硬件感知分析，而無需將物理目標連接到主機。

目標測試可以在開發生命周期的早期運行，甚至在物理硬件可用之前。

開發團隊可以提高測試能力并降低成本，因為不需要每個主機和開發人員都使用物理硬件。

詳盡靜態分析的未來

優先考慮詳盡靜態分析的嵌入式開發團隊（代碼覆蓋率高達 100%，準確性遠高于傳統測試）將從其測試投資中獲得最高價值。那些現在能夠加入的開發人員將能夠更好地提供更高質量的代碼，并隨著時間的推移提高測試效率。

從長遠來看，從這種嚴格的測試中獲得的結果和知識將導致“零問題”保證。這些原則將在開發過程的早期帶來更強的可測試性，以支持安全和安保關鍵型產品要求和設計，并顯著降低現場軟件故障和漏洞的可能性。

編輯：黃飛