什麼是單元測試?
“單元測試”通常又被稱為“白盒測試”,這些概念雖然在測試物件和方法的定義上,業內可能存在略有差異的理解方式,但它們並沒有本質的區別。單元測試,就是對軟體中最小可測單元或單元之間的邏輯關係所做的測試和驗證。比如對C/C++程式碼中的一個函數、類或是少數函數組成的一個集合,抑或是一個小的功能模組的測試,通常都可以歸為單元測試的範疇。
單元測試通過為被測單元設計輸入參數,並驗證其執行後的輸出值、關聯值或執行過程來驗證被測物件的堅固性(魯棒性)和正確性。堅固性取決於被測單元在各種類型或極端輸入條件下運行正常與否;正確性則是通過判定程式碼的運行邏輯是否符合原本的設計需求來驗證。單元測試的效果依賴於測試用例,也就是外部輸入參數是否合理、充分,而這些輸入參數主要需要測試人員根據被測單元的業務邏輯需求來設計,所以並不存在萬能的“銀子彈”代替所有單元測試的工作。
• 對單個函數的單元測試。根據函數的設計需求,來設計輸入值、樁函數和全域變數等相關的外部輸入條件,在測試執行完成後判定實際的輸出值是否符合預定的期望值,以此作為單元測試用例通過與否的依據。如下圖所示:
• 對多個單元的測試,也可以理解為單元之間的集成測試,因為其測試物件仍然集中於底層函數級別,也是單元測試工作中常見的測試場景。對多個單元的測試可以驗證多個單元連續調用執行之後的輸出值,也可以用來測試多個單元之間的相互依賴邏輯。
為什麼要做單元測試?
因為傳統的系統功能測試(又稱“黑盒測試”),由於系統集成後的複雜性,在有限的時間內無法充分地對軟體內部的分支、模組及模組之間的錯誤進行檢測,並且由於系統測試階段的bug所需的修復成本往往較高,所以對於要求高可靠性和安全性的系統,軟體的測試需要“左移”到專案研發的更早期,對底層的程式碼行、函數、類、子模組進行驗證,以實現對軟體更早、更徹底地測試。另外,由於早期bug的修復相對容易,項目整體研發成本也得以降低– 這也就是單元測試初衷。
換言之,單元測試的目的就是為了在系統集成之前根據下層需求測試函數或子模組的bug,以減輕後期系統集成測試的壓力,最終實現對軟體更徹底地測試,提高品質並降低成本。
殊途同歸,關於功能安全ASIL, SIL認證標準,如ISO 26262, IEC 61508, EN 50128, IEC 62304,或是GJB-5000A等標準明確要求了軟體的研發過程中需要進行單元測試,其出發點也正是為了通過強制要求更底層的測試以規避測試不充分可能導致的安全風險,保證汽車、工業、軌道交通、醫療器械和國防軍工等各類事故容忍度極低的系統的安全可靠。
難點和挑戰
單元測試耗時耗力。準備測試環境、編寫驅動程式碼、設計測試用例、執行結果判定、測試用例的管理、回歸和覆蓋率分析等每一步都需要繁瑣的工作,對於一個包含幾百甚至幾千乃至上萬個函數單元的工程來說,人工方式嚴格完成單元測試所需要的工作量不亞於整個軟體的開發工作
下層需求文檔和測試經驗的缺失形成了單元測試實施的門檻。函數級的設計需求文檔不足或不規範的情況,在歷史遺留專案中是非常常見的,單元測試全憑少數的測試人員通過解讀程式碼來進行會造成測試工作舉步維艱
嵌入式軟體的單元測試因為關係到交叉編譯過程,以及對目的機的相容,準備測試環境和執行測試用例會更加困難
海量的單元測試用例庫的變更分析、回歸執行和複用,對測試用例的管理方式有很高的要求
單元測試的覆蓋率統計幾乎不可能通過人工方式完成
解决方案
使用VectorCAST自動生成的單元測試環境,原生態支援絕大部分主流上位機環境編譯器和嵌入式交叉編譯器,避免對程式碼大幅修改或重構、甚至為了測試變更編譯器
VectorCAST支持業界領先的智慧、自動地批量生成單元測試用例,通常可達50%-80%甚至更高的測試覆蓋率
自動解析代碼結構,提供便捷、多樣化的圖形化測試設計平臺,極大簡化單元測試用例設計工作
有機管理單元測試用例,讓測試用例的協作、維護和複用變得非常容易
VectorCAST提供豐富的協力廠商集成,無縫集成開發過程上下游的研發工具鏈和管理平臺,如需求管理、持續集成、模型開發和靜態分析工具等
真正的嵌入式的單元測試,測試用例無縫集成到嵌入式目標板或模擬器上運行
多種報告形式,滿足單元測試不同的使用場景和協力廠商認證審計需求
相關資源
白皮書
博客
新聞資訊
修復和預防Bug的成本量化對比_白皮書
點擊下載
如何評估嵌入式軟體測試工具_白皮書
點擊下載
如何開發高品質的軟體_白皮書
點擊下載
利用Wind River VxWorks7實現自動化軟體測試_白皮書
點擊下載
基於變更的測試_白皮書
點擊下載
故障注入和多維度白盒測試_白皮書
點擊下載
2015軟體測試技術報告_白皮書
點擊下載
如何滿足IEC 61508-3 2010標準相關的軟體驗證和確認要求_白皮書
點擊下載
RELATED RESOURCES
下載申請