2024年7月18-19日,龍智攜汽車軟件開發(fā)及管理解決方案創(chuàng)新亮相2024 ATC汽車軟件與安全技術周。龍智技術支持部負責人&Atlassian認證專家葉燕秀、龍智功能安全高級工程師景玉鑫在活動主會場聯合發(fā)表了精彩演講,分享推動汽車軟件開發(fā)與功能安全的創(chuàng)新實踐。
本期,龍智功能安全高級工程師景玉鑫將從開發(fā)和測試的角度出發(fā),探討如何借助靜態(tài)代碼分析及自動化測試工具,確保代碼在符合ISO 26262功能安全標準的同時,提升生產力。
以下為演講實錄(內容有精簡潤色)。
大家好,前面我的同事已經提及了功能安全標準、質量與合規(guī)的重要性,特別是在汽車行業(yè)中,這些方面至關重要。( 點此閱讀上期演講回顧)接下來,我們將從開發(fā)和測試的角度出發(fā),探討如何在確保代碼符合功能安全標準的同時,提升生產力。
靜態(tài)代碼分析
我們知道,以安全至上的汽車行業(yè)對代碼質量的要求極為嚴格,而維護代碼質量又與企業(yè)成本息息相關。
首先我們來看一張圖:
該圖的橫坐標代表了軟件開發(fā)周期的不同階段,包括編碼階段、單元測試、功能測試、系統測試和發(fā)布階段;藍色曲線表示代碼問題產生的比例;橙色曲線表示代碼問題被發(fā)現的比例;而紅色曲線則反映了代碼問題的維護成本。
我們不難發(fā)現,隨著產品生命周期的推進,維護成本在不斷增加。在開發(fā)初期,由于環(huán)境相對簡單,發(fā)現問題后的維護成本相對較低。而進入單元測試階段后,由于測試人員需要建立和調整測試用例,并與開發(fā)人員進行溝通和協調,維護成本會有所增加。到了系統測試和發(fā)布階段,維護成本更是呈指數級增長。因此,盡早地發(fā)現代碼問題對于降低維護成本至關重要。
那么,如何有效發(fā)現代碼問題呢?依賴人工的審查和審核?顯然,這種方式高度依賴于個人的專業(yè)性和經驗,而且面對汽車行業(yè)龐大的代碼量,也顯得不切實際。我們需要借助靜態(tài)代碼掃描工具,以標準、權威的規(guī)則來掃描代碼,幫助發(fā)現隱藏問題。
如何選擇靜態(tài)代碼掃描工具?
在選擇靜態(tài)代碼掃描工具時,我們期望它能夠滿足功能安全標準的要求,并獲取相應的資質認證,以此提升掃描代碼的可信度和可靠性。此外,該工具內置的掃描規(guī)則也需要全面覆蓋我們日常使用的或熟知的編碼標準。
除了功能安全標準的專業(yè)性外,作為代碼掃描工具本身,我們還需關注以下的關鍵條件:
檢查規(guī)則是否全面:不僅限于上述涉及的相關功能安全標準,還應涵蓋對特定編程語言模塊的深入掃描規(guī)則。
是否具有較低的誤報率、漏報率,保障精度與準確度。
是否與開發(fā)人員日常使用的工具實現友好集成,以提升工作效率。
掃描結果是否可以在團隊內外進行共享和管理,促進團隊協作與信息傳遞。
是否具備豐富的報表功能,便于項目管理者或項目成員查看分析報告。
是否支持與現有持續(xù)集成(CI)工具的集成。對此,我們的推薦方式是將CI工具、源代碼管理(SCM)工具以及代碼掃描工具進行集成。通過代碼掃描工具,自動掃描每一次的提交和拉取請求,確保提交至SCM的代碼符合標準和規(guī)范。
單元測試/集成測試
下面,我們來簡要探討一下動態(tài)測試。一些安全標準(如ISO 26262)對單元測試和集成測試都是有一定要求的,我們需要確保代碼能夠滿足不同級別的安全標準。
V模型開發(fā)模式
在上圖以V模型為例的開發(fā)模式中,可以看到,單元測試是首個動態(tài)測試環(huán)節(jié),通過函數級別的掃描來發(fā)現代碼中的錯誤,并避免這些錯誤在后續(xù)測試甚至最終用戶處才被發(fā)現。
自動化測試和人工測試
對于動態(tài)測試,大致可以分為自動化測試和人工測試。相比于人工測試,自動化測試具有顯著優(yōu)勢。
? 首先,測試用例和測試動作可以提前定義并保存,當實施重復性測試時,只需少量修改甚至無需修改,就可以確保測試數據的一致性。
? 自動化測試能夠覆蓋人工測試難以或無法覆蓋的用例,測試覆蓋率更高。
? 采用自動化測試,可以利用周末或晚間的非工作時間運行,從而釋放測試人員的精力,以設計更好的測試用例,提高測試效率。
? 和前面介紹的靜態(tài)代碼掃描工具類似,如果我們的自動化測試工具已經通過功能安全標準認證,那么該工具的測試結果也具有更高的可靠性和可信度。
? 此外,自動化測試還能有效降低項目成本。
下圖是自動化測試(TESSY)和人工測試的Effort的比較,可以看出,盡管前期自動化測試在設計和定義上需要更多的投入,但長期來看,其優(yōu)勢愈發(fā)明顯。
開展詳盡規(guī)范的單元測試
對于何時開展測試,我們建議嘗試持續(xù)測試和測試左移策略,這是DevOps中的一個概念,即讓測試人員在早期介入,更早地開始設計和定義測試用例,并伴隨著開發(fā)周期進行測試,同時結合自動化測試工具,以盡早發(fā)現問題,縮短交付周期。
測試覆蓋率
為了評估軟件本身覆蓋率的可信度,我們還需要特別關注一些測試覆蓋率。以ISO 26262標準為例,該標準對軟件測試中的覆蓋率提出了明確要求。
上圖的右側展示了ISO 26262對覆蓋率要求的一部分,包括語句覆蓋率、分支覆蓋率等關鍵指標。另外也有很多其他的覆蓋率度量,我們在左側列舉了部分,供大家參考。
測試覆蓋率圖形分析
使用自動化測試工具時,我們希望這些工具在精確計算復雜的覆蓋率度量的同時,還能以用戶友好的可視化形式,直觀地展示結果,以便更清晰地了解軟件的測試覆蓋情況。
比如上圖所示的可視化界面,通過流程圖、彩色代碼等圖示,我們能夠直觀地進行分支覆蓋率分析,清晰地看到哪些分支已被執(zhí)行(以綠色標注),哪些分支尚未被執(zhí)行(以紅色標注)。這樣的可視化展示不僅提供了覆蓋率的直觀概覽,也為后續(xù)的優(yōu)化工作指明方向。
便捷的測試用例設計方式
此外,在使用自動化測試工具的過程中,同樣需要注重測試用例的建立是否便捷。結合我們使用過的工具,這里向大家推薦兩種有效方式:
第一種,采用測試用例編輯器的模式。該模式可以通過可視化表格將測試的輸入、預計的輸出及實際的執(zhí)行結果直觀展現出來,同時清晰且高效地管理測試數據。
第二種,采用分類樹編輯器的方式。該方式運用邊界值法和等價類的劃分法,幫助半自動地生成測試用例,從而提高測試覆蓋率,減少測試用例的冗余,并進一步提升測試效率。
以上所提及的理念、相關數據、產品特性和截圖等,均源自兩款備受認可的軟件——靜態(tài)代碼掃描工具Perforce Helix QAC和單元測試工具TESSY。這兩款軟件均獲得了TüV SüD關于功能安全標準的一系列認證,多年來專注于功能安全標準和安全合規(guī)領域,為用戶提供可靠的技術支撐。
Helix QAC:
30多年來,Helix QAC一直是值得信賴的C/C ++語言靜態(tài)代碼分析器。憑借其分析的深度和準確性,Helix QAC已成為監(jiān)管嚴格、安全至上的行業(yè)滿足合規(guī)要求的首選靜態(tài)代碼分析器,包括汽車行業(yè)。它能檢測代碼錯誤、是否編碼標準符合(例如MISRA和AUTOSAR),是否存在安全隱患,并幫助團隊遵循合規(guī)標準(例如ISO 26262),提升代碼質量和安全性,從而為汽車軟件開發(fā)團隊創(chuàng)造更高標準、更可靠的產品。
TESSY:
TESSY是一款應用于嵌入式軟件的自動化測試工具,專門針對嵌入式軟件的C/C++代碼進行單元測試、集成測試。TESSY作為較早的單元測試工具之一,設計用于支持符合標準的開發(fā)和測試,已經成為高質量產品和安全關鍵應用的常用工具。
作為一款經過認證的測試工具,TESSY支持所有行業(yè)領先的編譯器、調試器和微控制器,以及主機模擬,符合IEC 61508/ISO 26262、IEC 62304和EN 50128標準的安全相關軟件開發(fā)要求。眾多汽車整車廠、零部件供應商都在使用TESSY。
若您對上述內容或相關軟件有進一步的興趣和疑問,歡迎聯系Perforce中國授權合作伙伴、TESSY授權分銷商——龍智詳細咨詢。謝謝大家。
審核編輯 黃宇
-
測試
+關注
關注
8文章
5574瀏覽量
128091 -
代碼
+關注
關注
30文章
4882瀏覽量
70046 -
汽車軟件
+關注
關注
1文章
116瀏覽量
3390
發(fā)布評論請先 登錄
單元測試在嵌入式軟件中的關鍵作用及winAMS工具的卓越貢獻
嵌入式軟件單元測試的必要性、核心方法及工具深度解析
嵌入式系統開發(fā)中的測試方法 嵌入式系統開發(fā)與AI結合應用
開發(fā)者必讀!CircleCI?組件測試與單元測試全解析
嚴格的單元測試造就完美的軟件

嵌入軟件單元/集成測試工具專業(yè)分析
9月12日云技術研討會 | ECU電控軟件開發(fā)及測試全流程解決方案

評論