車輛已經從機械設備發展為復雜的集成技術平臺，其嵌入式軟件為所有主要系統提供動力，包括：發動機控制、動力總成、制動、駕駛員輔助和信息娛樂。現在，研究預測，到 2017 年，五分之四的新車將擁有互聯網連接［1］。隨著消費級信息娛樂軟件和安全關鍵軟件之間的界限變得模糊，這種“永遠在線”的連接將帶來新的挑戰。

　　例如，遠程信息處理系統提供車載語音控制應用程序等功能，以及與 GPS 系統交互以實現導航和交通功能。很快，車輛的 GPS 系統將不僅僅用于指示方向。隨著我們進入聯網和自動駕駛汽車的時代，諸如“自動 SOS”之類的功能將在這種現有的遠程信息處理架構之上構建，該功能可以在發生碰撞時召喚幫助。

　　當閱讀最近有關主要汽車制造商與美國國家公路交通安全管理局 （NHTSA） 達成協議將自動緊急制動 （AEB） 作為大多數汽車的標準設備的新聞時，我想到了從消費級向安全關鍵型轉變的另一個例子。到 2021 年，AEB 系統由軟件控制，這些軟件為攝像頭、雷達、接近傳感器等提供動力，所有這些都需要完美運行，以便在駕駛員反應緩慢時安全停車。這也意味著以前用于被動駕駛輔助（例如停車）的嵌入式攝像頭現在將成為安全關鍵系統的一部分。

　　前方無法克服的質量問題

　　大多數新軟件應用程序都建立在遺留代碼庫之上。由于大量金錢和時間投資已投入到開發現有應用程序中，因此自然會對盡可能多地利用已經完成的工作感興趣。

　　重用現有代碼的問題在于，遺留應用程序通常背負著大量的技術債務。技術債務是系統初始設計和開發過程中走捷徑的隱喻。這種“債務”通常是由于軟件的持續開發而沒有正確的質量控制流程造成的，通常是由于發布新版本的巨大業務壓力。所產生的技術債務的累積責任最終使軟件難以維護。

　　減少技術債務和提高質量的關鍵是重構組件（在不改變其外部行為/API 的情況下重構應用程序組件的過程），但開發人員常常因為害怕破壞現有功能而猶豫不決。重構的最大障礙之一是缺乏足夠的測試來形式化應用程序的現有正確行為。

　　如果沒有足夠的測試，很難重構應用程序并且不會導致功能或性能的回歸。根據 Gartner 的一項研究，“缺乏可重復的測試用例限制了組織以客觀、可衡量的方式展示功能等效性的能力。”缺乏足夠的測試最終意味著軟件應用程序無法輕易修改以支持新的應用程序。特征。

　　償還技術債務

　　基線測試，也稱為特征測試，對于測試不足的遺留代碼庫很有用。已經部署的應用程序的開發人員不太可能返回并實現所有應該生成的低級測試。他們正確地認為部署的應用程序“運行良好”，那么他們為什么要花幾個月的時間重新測試呢？

　　在這種情況下，更好的選擇是使用自動測試用例生成 （ATG） 來快速提供一組基線測試，以捕獲和表征現有應用程序行為。雖然這些測試不能證明正確性，但它們確實使應用程序今天所做的工作正式化，這非常強大，因為它允許驗證未來的更改以確保它們不會破壞現有功能。

　　擁有一套完整的基線測試的另一個好處是可以使用基于變更的測試 （CBT） 來減少總測試周期時間。完整的應用程序測試需要一到兩周的時間并不少見。使用基于更改的測試，可以在幾分鐘內測試小的更改。基于更改的測試計算每個代碼更改所需的最小測試用例集，并僅運行這些測試。

　　因此，開發人員能夠對代碼進行增量更改，并確保這些更改不會破壞軟件的現有行為。他們還能夠做進一步的分析，如果有什么東西被打破了，如果引入了一個錯誤，一個實際上應該存在的功能已經被刪除，或者是否有一個應該解決的錯誤，因為它可能有其他后果。

　　到銀行進行基線測試

　　在支持物聯網的世界中，大量遺留代碼將進入新應用程序的關鍵路徑。如果沒有適當的軟件質量方法來確保此遺留代碼的完整性，系統的整體安全性可能會受到影響。

　　基線測試可以幫助減少現有代碼庫中的技術債務，讓開發人員有信心重構和增強這些代碼庫，并最終讓這些遺留應用程序的所有者獲得更多價值。

　　審核編輯：郭婷