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

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

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

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

集成工具支持多個(gè)測試層

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

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

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

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

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

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

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

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

審核編輯：郭婷