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

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

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

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

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

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

第三方工具也提供了獨(dú)立性的衡量標(biāo)準(zhǔn)，證明測試是全面的，使用由沒有既得利益的組織編寫的機(jī)制。

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

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

審核編輯：郭婷