2024年7月18-19日，龍智攜汽車軟件開發(fā)及管理解決方案創(chuàng)新亮相2024 ATC汽車軟件與安全技術(shù)周。龍智技術(shù)支持部負責人&Atlassian認證專家葉燕秀、龍智功能安全高級工程師景玉鑫在活動主會場聯(lián)合發(fā)表了精彩演講，分享推動汽車軟件開發(fā)與功能安全的創(chuàng)新實踐。

本期，龍智功能安全高級工程師景玉鑫將從開發(fā)和測試的角度出發(fā)，探討如何借助靜態(tài)代碼分析及自動化測試工具，確保代碼在符合ISO 26262功能安全標準的同時，提升生產(chǎn)力。

以下為演講實錄（內(nèi)容有精簡潤色）。

大家好，前面我的同事已經(jīng)提及了功能安全標準、質(zhì)量與合規(guī)的重要性，特別是在汽車行業(yè)中，這些方面至關(guān)重要。（ 點此閱讀上期演講回顧）接下來，我們將從開發(fā)和測試的角度出發(fā)，探討如何在確保代碼符合功能安全標準的同時，提升生產(chǎn)力。

靜態(tài)代碼分析

我們知道，以安全至上的汽車行業(yè)對代碼質(zhì)量的要求極為嚴格，而維護代碼質(zhì)量又與企業(yè)成本息息相關(guān)。

首先我們來看一張圖：

該圖的橫坐標代表了軟件開發(fā)周期的不同階段，包括編碼階段、單元測試、功能測試、系統(tǒng)測試和發(fā)布階段；藍色曲線表示代碼問題產(chǎn)生的比例；橙色曲線表示代碼問題被發(fā)現(xiàn)的比例；而紅色曲線則反映了代碼問題的維護成本。

我們不難發(fā)現(xiàn)，隨著產(chǎn)品生命周期的推進，維護成本在不斷增加。在開發(fā)初期，由于環(huán)境相對簡單，發(fā)現(xiàn)問題后的維護成本相對較低。而進入單元測試階段后，由于測試人員需要建立和調(diào)整測試用例，并與開發(fā)人員進行溝通和協(xié)調(diào)，維護成本會有所增加。到了系統(tǒng)測試和發(fā)布階段，維護成本更是呈指數(shù)級增長。因此，盡早地發(fā)現(xiàn)代碼問題對于降低維護成本至關(guān)重要。

那么，如何有效發(fā)現(xiàn)代碼問題呢？依賴人工的審查和審核？顯然，這種方式高度依賴于個人的專業(yè)性和經(jīng)驗，而且面對汽車行業(yè)龐大的代碼量，也顯得不切實際。我們需要借助靜態(tài)代碼掃描工具，以標準、權(quán)威的規(guī)則來掃描代碼，幫助發(fā)現(xiàn)隱藏問題。

如何選擇靜態(tài)代碼掃描工具？

在選擇靜態(tài)代碼掃描工具時，我們期望它能夠滿足功能安全標準的要求，并獲取相應(yīng)的資質(zhì)認證，以此提升掃描代碼的可信度和可靠性。此外，該工具內(nèi)置的掃描規(guī)則也需要全面覆蓋我們?nèi)粘Ｊ褂玫幕蚴熘木幋a標準。

除了功能安全標準的專業(yè)性外，作為代碼掃描工具本身，我們還需關(guān)注以下的關(guān)鍵條件：

檢查規(guī)則是否全面：不僅限于上述涉及的相關(guān)功能安全標準，還應(yīng)涵蓋對特定編程語言模塊的深入掃描規(guī)則。

是否具有較低的誤報率、漏報率，保障精度與準確度。

是否與開發(fā)人員日常使用的工具實現(xiàn)友好集成，以提升工作效率。

掃描結(jié)果是否可以在團隊內(nèi)外進行共享和管理，促進團隊協(xié)作與信息傳遞。

是否具備豐富的報表功能，便于項目管理者或項目成員查看分析報告。

是否支持與現(xiàn)有持續(xù)集成（CI）工具的集成。對此，我們的推薦方式是將CI工具、源代碼管理（SCM）工具以及代碼掃描工具進行集成。通過代碼掃描工具，自動掃描每一次的提交和拉取請求，確保提交至SCM的代碼符合標準和規(guī)范。

單元測試/集成測試

下面，我們來簡要探討一下動態(tài)測試。一些安全標準（如ISO 26262）對單元測試和集成測試都是有一定要求的，我們需要確保代碼能夠滿足不同級別的安全標準。

V模型開發(fā)模式

在上圖以V模型為例的開發(fā)模式中，可以看到，單元測試是首個動態(tài)測試環(huán)節(jié)，通過函數(shù)級別的掃描來發(fā)現(xiàn)代碼中的錯誤，并避免這些錯誤在后續(xù)測試甚至最終用戶處才被發(fā)現(xiàn)。

自動化測試和人工測試

對于動態(tài)測試，大致可以分為自動化測試和人工測試。相比于人工測試，自動化測試具有顯著優(yōu)勢。

? 首先，測試用例和測試動作可以提前定義并保存，當實施重復(fù)性測試時，只需少量修改甚至無需修改，就可以確保測試數(shù)據(jù)的一致性。

? 自動化測試能夠覆蓋人工測試難以或無法覆蓋的用例，測試覆蓋率更高。

? 采用自動化測試，可以利用周末或晚間的非工作時間運行，從而釋放測試人員的精力，以設(shè)計更好的測試用例，提高測試效率。

? 和前面介紹的靜態(tài)代碼掃描工具類似，如果我們的自動化測試工具已經(jīng)通過功能安全標準認證，那么該工具的測試結(jié)果也具有更高的可靠性和可信度。

? 此外，自動化測試還能有效降低項目成本。

下圖是自動化測試（TESSY）和人工測試的Effort的比較，可以看出，盡管前期自動化測試在設(shè)計和定義上需要更多的投入，但長期來看，其優(yōu)勢愈發(fā)明顯。

開展詳盡規(guī)范的單元測試

對于何時開展測試，我們建議嘗試持續(xù)測試和測試左移策略，這是DevOps中的一個概念，即讓測試人員在早期介入，更早地開始設(shè)計和定義測試用例，并伴隨著開發(fā)周期進行測試，同時結(jié)合自動化測試工具，以盡早發(fā)現(xiàn)問題，縮短交付周期。

測試覆蓋率

為了評估軟件本身覆蓋率的可信度，我們還需要特別關(guān)注一些測試覆蓋率。以ISO 26262標準為例，該標準對軟件測試中的覆蓋率提出了明確要求。

上圖的右側(cè)展示了ISO 26262對覆蓋率要求的一部分，包括語句覆蓋率、分支覆蓋率等關(guān)鍵指標。另外也有很多其他的覆蓋率度量，我們在左側(cè)列舉了部分，供大家參考。

測試覆蓋率圖形分析

使用自動化測試工具時，我們希望這些工具在精確計算復(fù)雜的覆蓋率度量的同時，還能以用戶友好的可視化形式，直觀地展示結(jié)果，以便更清晰地了解軟件的測試覆蓋情況。

比如上圖所示的可視化界面，通過流程圖、彩色代碼等圖示，我們能夠直觀地進行分支覆蓋率分析，清晰地看到哪些分支已被執(zhí)行（以綠色標注），哪些分支尚未被執(zhí)行（以紅色標注）。這樣的可視化展示不僅提供了覆蓋率的直觀概覽，也為后續(xù)的優(yōu)化工作指明方向。

便捷的測試用例設(shè)計方式

此外，在使用自動化測試工具的過程中，同樣需要注重測試用例的建立是否便捷。結(jié)合我們使用過的工具，這里向大家推薦兩種有效方式：

第一種，采用測試用例編輯器的模式。該模式可以通過可視化表格將測試的輸入、預(yù)計的輸出及實際的執(zhí)行結(jié)果直觀展現(xiàn)出來，同時清晰且高效地管理測試數(shù)據(jù)。

第二種，采用分類樹編輯器的方式。該方式運用邊界值法和等價類的劃分法，幫助半自動地生成測試用例，從而提高測試覆蓋率，減少測試用例的冗余，并進一步提升測試效率。

以上所提及的理念、相關(guān)數(shù)據(jù)、產(chǎn)品特性和截圖等，均源自兩款備受認可的軟件——靜態(tài)代碼掃描工具Perforce Helix QAC和單元測試工具TESSY。這兩款軟件均獲得了TüV SüD關(guān)于功能安全標準的一系列認證，多年來專注于功能安全標準和安全合規(guī)領(lǐng)域，為用戶提供可靠的技術(shù)支撐。

Helix QAC：

30多年來，Helix QAC一直是值得信賴的C/C ++語言靜態(tài)代碼分析器。憑借其分析的深度和準確性，Helix QAC已成為監(jiān)管嚴格、安全至上的行業(yè)滿足合規(guī)要求的首選靜態(tài)代碼分析器，包括汽車行業(yè)。它能檢測代碼錯誤、是否編碼標準符合（例如MISRA和AUTOSAR），是否存在安全隱患，并幫助團隊遵循合規(guī)標準（例如ISO 26262），提升代碼質(zhì)量和安全性，從而為汽車軟件開發(fā)團隊創(chuàng)造更高標準、更可靠的產(chǎn)品。

TESSY：

TESSY是一款應(yīng)用于嵌入式軟件的自動化測試工具，專門針對嵌入式軟件的C/C++代碼進行單元測試、集成測試。TESSY作為較早的單元測試工具之一，設(shè)計用于支持符合標準的開發(fā)和測試，已經(jīng)成為高質(zhì)量產(chǎn)品和安全關(guān)鍵應(yīng)用的常用工具。

作為一款經(jīng)過認證的測試工具，TESSY支持所有行業(yè)領(lǐng)先的編譯器、調(diào)試器和微控制器，以及主機模擬，符合IEC 61508/ISO 26262、IEC 62304和EN 50128標準的安全相關(guān)軟件開發(fā)要求。眾多汽車整車廠、零部件供應(yīng)商都在使用TESSY。

若您對上述內(nèi)容或相關(guān)軟件有進一步的興趣和疑問，歡迎聯(lián)系Perforce中國授權(quán)合作伙伴、TESSY授權(quán)分銷商——龍智詳細咨詢。謝謝大家。

審核編輯 黃宇