通過覆蓋分析深入研究安全關鍵代碼測試

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

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

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

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

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

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

調用每個入口和出口點

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

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

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

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

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

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

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

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

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

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

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

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

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

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

審核編輯：郭婷