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

無論他們是否知道，他們都在通過系統(tǒng)功能測試進(jìn)行動態(tài)分析。與靜態(tài)分析不同，動態(tài)分析涉及代碼執(zhí)行的定義。

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

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

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

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

反過來，這為我們一次執(zhí)行多少代碼提供了靈活性?？梢詫φ麄€系統(tǒng)進(jìn)行動態(tài)分析，但總有一些通過代碼的路由，我們的系統(tǒng)在正常運行期間無法執(zhí)行這些路由——例如防御性代碼;也許是除以零的支票。

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

當(dāng)今的軍事應(yīng)用需要支持 ARINC 653 或FACE等架構(gòu)標(biāo)準(zhǔn)，以提高代碼的可移植性和可重用性。通過動態(tài)分析提供全面的覆蓋數(shù)據(jù)提供了證據(jù)，證明即使移植到不同的應(yīng)用程序，代碼仍然是可維護(hù)的、安全的，特別是當(dāng)與有效的靜態(tài)分析制度結(jié)合使用時。

審核編輯：郭婷