所以你現(xiàn)在已經(jīng)測試了你的軟件。但是你知道你測試得有多好嗎？您如何衡量測試的有效性？汽車軟件不斷增長的數(shù)量和復(fù)雜性給開發(fā)人員帶來了越來越重的負(fù)擔(dān)，不僅要驗證它的功能，還要確保它滿足安全和安保的要求。從表面上看，這意味著基于需求的測試。這當(dāng)然很重要，但在更深層次上，您需要確保此類關(guān)鍵代碼已經(jīng)過充分測試。您是否測試過是否可能存在異常情況，再加上代碼中不常用的部分中隱藏的細(xì)微錯誤，可能會導(dǎo)致一些嚴(yán)重的故障？您必須衡量測試的有效性。

覆蓋分析可以全部或有選擇地應(yīng)用，以滿足 ISO 26262 指南

這聽起來像是給開發(fā)人員又增加了一個沉重的負(fù)擔(dān)。然而，它可以通過一套測試工具（例如，需求跟蹤、靜態(tài)和動態(tài)測試、單元和集成測試等）進行有效且具有成本效益的管理，這些工具包括評估測試范圍和性質(zhì)的能力。換句話說，重要的是要了解已經(jīng)測試和未測試的內(nèi)容、為什么以及這些測試如何與功能、安全和安保要求相關(guān)聯(lián)?？傮w而言，這是通過覆蓋分析來實現(xiàn)的，但是該分析具有不同的技術(shù)，更具體地說，具有不同的級別，可以應(yīng)用于整個應(yīng)用程序，或者更有選擇性地應(yīng)用于那些故障可能危及系統(tǒng)功能或?qū)е率軅蛩劳觥?/p>

對于機動車輛，我們有用于汽車軟件開發(fā)的 ISO 26262 標(biāo)準(zhǔn)指南，包括從 A 到 D 分類為汽車安全完整性等級 （ASIL） 的安全指南，其中 D 是最關(guān)鍵的。毫不奇怪，安全指南要求對制動系統(tǒng)進行比娛樂系統(tǒng)更深入的測試。使用一組分析工具，我們應(yīng)該能夠確認(rèn)我們已經(jīng)測試了要部署在車輛中的軟件，以確保安全和安保的適當(dāng)水平。

集成工具支持多個測試層

軟件質(zhì)量分析通常從檢查源代碼的靜態(tài)分析開始。雖然它本身不執(zhí)行覆蓋分析，但靜態(tài)分析可以分析代碼的質(zhì)量和結(jié)構(gòu)，并在需要時檢查是否符合編碼標(biāo)準(zhǔn)。從根本上說，通過靜態(tài)分析獲得的代碼知識和理解可以自動化并加速測試工具生成以及測試用例開發(fā)的輸入生成。

動態(tài)分析與靜態(tài)分析的不同之處在于，被測代碼是經(jīng)過編譯、鏈接和執(zhí)行的。系統(tǒng)測試和單元測試都是動態(tài)分析的例子，一般是結(jié)合使用。顧名思義，系統(tǒng)測試將系統(tǒng)作為一個整體進行練習(xí)，以表明功能、安全和安保要求得到了適當(dāng)?shù)慕鉀Q。單元測試允許更早地驗證功能，提供一種執(zhí)行防御性代碼的方法，并且可以通過組合有效和無效輸入、范圍測試和邊界條件來測試穩(wěn)健性，從而增加更多價值。

工具套件中的覆蓋數(shù)據(jù)是通過輕量級代碼檢測生成的。該工具允許工具跟蹤哪些代碼已被執(zhí)行，并生成有關(guān)使用的測試用例實現(xiàn)的覆蓋范圍和細(xì)節(jié)的信息。根據(jù)由 ASIL 驅(qū)動的所需覆蓋分析的級別和深度，該工具套件報告語句、分支和修改的條件/決策覆蓋等級別的覆蓋率。有關(guān)所需內(nèi)容的列表，請參見 ISO 26262 標(biāo)準(zhǔn)中的表 12 和 15。

Modified Condition/Decision Coverage （MC/DC） 是一種深入的覆蓋分析技術(shù)，但并不總是很好理解。顯然，通過在每個分支上執(zhí)行所有可能的條件（分支條件組合覆蓋，或 BCCC），可以實現(xiàn)非常完整的代碼覆蓋。但是，當(dāng)一個分支依賴于四個或更多條件時，這會導(dǎo)致不切實際的測試數(shù)量。對于這些分支，MC/DC 將所需的測試數(shù)量減少到 N+1 條路徑，而不是 BCCC 所暗示的 N2 條路徑。MC/DC確保每個入口和出口點都參與；每一個決定都有每一個可能的結(jié)果；一個決策中的每個條件都包含每個可能的結(jié)果，并且一個決策中的每個條件都被證明獨立地影響決策的結(jié)果。結(jié)果，以及需要額外注意的任何差距，

一個完整的工具套件還可以提供數(shù)據(jù)形式的分析和控制耦合覆蓋。ISO 26262 要求存在“軟件組件之間的受限耦合”，并且它是該原則的合理擴展，以確保已執(zhí)行每個功能調(diào)用并且已執(zhí)行對數(shù)據(jù)的每次訪問。數(shù)據(jù)耦合分析通過源代碼跟蹤變量，并準(zhǔn)確報告哪些值已用于發(fā)現(xiàn)可能的異常使用。

【圖1 | LDRA 的 TBvision 工具顯示了已分析的代碼部分以及應(yīng)用的不同測試級別的覆蓋結(jié)果。］

在汽車行業(yè)，使用具有該架構(gòu)圖形表示的工具（即基于模型的開發(fā)）生成軟件架構(gòu)設(shè)計也越來越流行。其中包括 IBM Rational Rhapsody、Mathworks Simulink、ANSYS SCADE 等工具。一個軟件測試和分析工具套件可以測試從這些工具自動生成的代碼，然后將測試和覆蓋結(jié)果映射回這個圖形表示，這將有助于完成循環(huán)，以確保開發(fā)人員驗證工作的有效性。

所以答案是：是的，要確保汽車應(yīng)用程序的安全性，僅僅測試您的代碼是不夠的。您還必須衡量測試過程的完整性。但是使用集成的自動化工具套件，該過程是全面的、直接的和無痛的。

審核編輯：郭婷