很久很久以前，唯一的動態(tài)軟件測試是系統(tǒng)功能測試。與不可靠軟件的斗爭完全是通過完整的系統(tǒng)測試進行的，其中應用程序的價值是通過參考一組需求、一組測試數(shù)據(jù)和預期結果來證明的。

雖然這仍然是驗證和驗證過程的重要組成部分，但大多數(shù)測試數(shù)據(jù)集僅執(zhí)行代碼的特定部分。不幸的是，正是這種不尋常的代碼路徑只有在發(fā)生異常情況時才會被調用，這可能導致現(xiàn)場災難性的結果。一個例子可能是對除數(shù)的測試，以確保它在計算中使用之前不為零。它不應該發(fā)生 - 但如果它發(fā)生了，并且測試有缺陷怎么辦？

為了防止這種可能性，最好也引入單元和集成測試。單元測試涉及圍繞函數(shù)或過程編寫包裝器“工具”，向其傳遞數(shù)據(jù)，并確保生成的輸出符合設計要求。集成測試通過采用類似的方法建立在這一成功的基礎上，但允許函數(shù)調用調用樹中的其他函數(shù)，從而證明這些單元按預期協(xié)同工作。

單元測試和集成測試可以填補系統(tǒng)測試和練習構造留下的空白，以防止這些意外事件，例如“除以零”。或者，我們可以“自下而上”地練習整個系統(tǒng)，首先證明最小的功能組件已經充分鍛煉，然后證明它們一起工作。

無論哪種方式，盡管我們現(xiàn)在有辦法執(zhí)行所有代碼，但我們怎么知道我們已經這樣做了？好的測試工具提供結構覆蓋指標，以定量分析在結構覆蓋率分析期間執(zhí)行了多少代碼路徑。DO-178等標準的使用已經證明，這種方法可以降低失敗的風險。因此，這已成為大多數(shù)嵌入式軍事標準的規(guī)范。

雖然此類標準不要求您使用工具來生成此信息，但手動演示覆蓋范圍的開銷非常耗時（更不用說更容易出錯），以至于大多數(shù)公司將工具視為顯著降低開發(fā)成本的一種方式。測試工具使用經過驗證的檢測機制創(chuàng)建覆蓋率數(shù)據(jù)，該機制由函數(shù)調用組成，以記錄所采用的執(zhí)行路徑。創(chuàng)建內部實現(xiàn)所需的工作量與應用程序代碼本身類似。

第三方工具也提供了獨立性的衡量標準，證明測試是全面的，使用由沒有既得利益的組織編寫的機制。

故事到此結束，是嗎？使用這些工具和技術，您可以殺死龍并證明所有陳述在功能上都是正確的并且已被執(zhí)行。

好吧，也許吧。這取決于失敗的影響。應用越關鍵，對標準的要求就越高。您生成的覆蓋范圍數(shù)據(jù)量是否反映了項目的關鍵性？代碼是否已在目標或主機上執(zhí)行？

審核編輯：郭婷