在過去美好的時光里，在編寫軟件成為“軟件工程”之前，代碼開發是一門黑藝術，由剛從大學畢業的奇怪書孩子實踐。對他們來說，編碼絕不是一門結構化的學科。如果你設法讓他們溝通，他們可能會告訴你，他們正在一起破解代碼，并使用臨時測試數據來查看它是否做了他們執行它時應該做的事情。

無論他們是否知道，他們都在通過系統功能測試進行動態分析。與靜態分析不同，動態分析涉及代碼執行的定義。

但是，除了顯示基本功能對于任何基本的測試數據大致正確之外，這還做了什么？雖然總比沒有好，但可能不超過一半的代碼被執行。行業軟件專家、Ganssle Group首席顧問兼行業編輯Jack Ganssle對此表示贊同：“研究證實，如果不使用代碼覆蓋率分析，測試通常只執行50%的代碼。給定典型的錯誤率，這意味著程序中的 100K 行代碼將附帶 2500 到 5000 個錯誤。這些錯誤會導致許多系統故障。

為什么？因為無論測試多么富有想象力，現實生活中都有可能拋出一些曲線球來嘗試未經測試的路徑。如果執行某些內容未經測試，您可能會遇到一些意外和潛在的災難性故障。

快進 30 或 40 年。雖然這種樸素的方法并不能與復雜的軍事嵌入式應用相提并論，但功能測試仍然是動態測試的核心。精心挑選的測試數據表明，源代碼中的分支和語句是按照規范執行的，不僅使我們能夠證明系統在功能上是正確的，而且我們已經執行了所有這些功能。當與靜態分析結合使用時，動態分析提供了所需的支持證據，以證明我們所有其他良好的工作和最佳實踐產生了安全、可靠和高質量的最終產品。

與多年前的黑客攻擊不同，今天的自動化測試工具通過使用儀器探針等技術精確地跟蹤執行路線。這些探測器本質上是附加的函數調用，從源代碼中的戰略點生成“我來過這里”消息，并允許整理覆蓋率數據。它們允許動態測試生成有關其全面程度的反饋，以便我們可以在每組結果的基礎上連續構建，直到達到所需的覆蓋水平。

反過來，這為我們一次執行多少代碼提供了靈活性。可以對整個系統進行動態分析，但總有一些通過代碼的路由，我們的系統在正常運行期間無法執行這些路由——例如防御性代碼;也許是除以零的支票。

在這種情況下，最好也使用“單元測試”。單元測試封裝了系統的一個子集，并允許傳遞參數，以便執行示例中的防御機制代碼。我們甚至可以選擇完全基于單元測試進行應用程序動態分析，在每個模塊開發時整理代碼覆蓋率數據，并消除等待完整系統的任何要求。

當今的軍事應用需要支持 ARINC 653 或FACE等架構標準，以提高代碼的可移植性和可重用性。通過動態分析提供全面的覆蓋數據提供了證據，證明即使移植到不同的應用程序，代碼仍然是可維護的、安全的，特別是當與有效的靜態分析制度結合使用時。

審核編輯：郭婷