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

例如，遠(yuǎn)程信息處理系統(tǒng)提供車載語音控制應(yīng)用程序等功能，以及與 GPS 系統(tǒng)交互以實(shí)現(xiàn)導(dǎo)航和交通功能。很快，車輛的 GPS 系統(tǒng)將不僅僅用于指示方向。隨著我們進(jìn)入聯(lián)網(wǎng)和自動駕駛汽車的時(shí)代，諸如“自動 SOS”之類的功能將在這種現(xiàn)有的遠(yuǎn)程信息處理架構(gòu)之上構(gòu)建，該功能可以在發(fā)生碰撞時(shí)召喚幫助。

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

前方無法克服的質(zhì)量問題

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

重用現(xiàn)有代碼的問題在于，遺留應(yīng)用程序通常背負(fù)著大量的技術(shù)債務(wù)。技術(shù)債務(wù)是系統(tǒng)初始設(shè)計(jì)和開發(fā)過程中走捷徑的隱喻。這種“債務(wù)”通常是由于軟件的持續(xù)開發(fā)而沒有正確的質(zhì)量控制流程造成的，通常是由于發(fā)布新版本的巨大業(yè)務(wù)壓力。所產(chǎn)生的技術(shù)債務(wù)的累積責(zé)任最終使軟件難以維護(hù)。

減少技術(shù)債務(wù)和提高質(zhì)量的關(guān)鍵是重構(gòu)組件（在不改變其外部行為/API 的情況下重構(gòu)應(yīng)用程序組件的過程），但開發(fā)人員常常因?yàn)楹ε缕茐默F(xiàn)有功能而猶豫不決。重構(gòu)的最大障礙之一是缺乏足夠的測試來形式化應(yīng)用程序的現(xiàn)有正確行為。

如果沒有足夠的測試，很難重構(gòu)應(yīng)用程序并且不會導(dǎo)致功能或性能的回歸。根據(jù) Gartner 的一項(xiàng)研究，“缺乏可重復(fù)的測試用例限制了組織以客觀、可衡量的方式展示功能等效性的能力?！比狈ψ銐虻臏y試最終意味著軟件應(yīng)用程序無法輕易修改以支持新的應(yīng)用程序。特征。

償還技術(shù)債務(wù)

基線測試，也稱為特征測試，對于測試不足的遺留代碼庫很有用。已經(jīng)部署的應(yīng)用程序的開發(fā)人員不太可能返回并實(shí)現(xiàn)所有應(yīng)該生成的低級測試。他們正確地認(rèn)為部署的應(yīng)用程序“運(yùn)行良好”，那么他們?yōu)槭裁匆◣讉€月的時(shí)間重新測試呢？

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

【圖2 | 基線測試正式確定了應(yīng)用程序今天所做的事情，這允許驗(yàn)證未來的更改以確?，F(xiàn)有功能不會被破壞?；谧兏臏y試可用于僅運(yùn)行顯示變更效果所需的最小測試用例集。］

擁有一套完整的基線測試的另一個好處是可以使用基于變更的測試 （CBT） 來減少總測試周期時(shí)間。完整的應(yīng)用程序測試需要一到兩周的時(shí)間并不少見。使用基于更改的測試，可以在幾分鐘內(nèi)測試小的更改?；诟牡臏y試計(jì)算每個代碼更改所需的最小測試用例集，并僅運(yùn)行這些測試。

因此，開發(fā)人員能夠?qū)Υa進(jìn)行增量更改，并確保這些更改不會破壞軟件的現(xiàn)有行為。他們還能夠做進(jìn)一步的分析，如果有什么東西被打破了，如果引入了一個錯誤，一個實(shí)際上應(yīng)該存在的功能已經(jīng)被刪除，或者是否存在一個應(yīng)該解決的錯誤，因?yàn)樗赡苡衅渌蠊?/p>

到銀行進(jìn)行基線測試

在支持物聯(lián)網(wǎng)的世界中，大量遺留代碼將進(jìn)入新應(yīng)用程序的關(guān)鍵路徑。如果沒有適當(dāng)?shù)能浖|(zhì)量方法來確保此遺留代碼的完整性，系統(tǒng)的整體安全性可能會受到影響。

基線測試可以幫助減少現(xiàn)有代碼庫中的技術(shù)債務(wù)，讓開發(fā)人員有信心重構(gòu)和增強(qiáng)這些代碼庫，并最終讓這些遺留應(yīng)用程序的所有者獲得更多價(jià)值。

審核編輯：郭婷