王斌 趙連杰 王宏愿

摘要:隨著軟件的廣泛應用,在追求滿足越來越復雜的邏輯功能的同時也在追求高安全、高可靠的軟件。傳統的軟件單元測試,測試工作量巨大,需要耗費大量的人力、物力,發現缺陷的嚴重等級與數量與測試投入不成正比。故本文,研究并設計嵌入式軟件單元的自動化測試工具,解決源碼解析、靜態分析、控制流分析的自動化執行與測試,并進行缺陷追溯與信息統計,形成軟件單元測試的閉環。
最后針對此工具進行外部接口的開發,可實現與Jenkins等主流工具的持續集成,真正實現源代碼上傳即可觸發軟件單元測試的自動化流程。
關鍵詞:嵌入式;自動化;單元測試;jenkins
1研究背景
本研究主要是基于當前軌道交通裝備技術的高速發展,軟件發展的規模不斷增大,軟件迭代研發周期要求越來越短,測試壓力越來越大;軟件單元測試在軟件測試周期中的所占用的測試時間,測試人員,擁有非常大的比重;幾乎每個項目的軟件單元測試的測試需求一致,導致產生大量的重復性工作量,嚴重延長項目的研發生產周期。故基于現狀進行深化研究,計劃開發嵌入式軟件單元自動化測試工具,以實現自源代碼上傳之后可以自動化執行軟件單元測試的愿景。
2核心技術設計方案
2.1軟件單元自動化測試工具架構設計
此軟件單元自動化測試工具的架構設計如圖1架構設計圖所示
2.2源碼解析
此工具首先解析用戶上傳的源碼庫、編譯依賴庫。在仿真環境下,將源代碼和編譯依賴進行打包,統一進行編譯鏈接。若編譯失敗,則需要不斷補充編譯依賴庫,使得源碼本身對編譯環境依賴的頭文件等都導入到系統中。這樣,源碼可不依賴于原有的編譯器和編譯環境,可實現直接可在工具內編譯執行。
2.3靜態分析
此工具對源碼進行解析后,先對待測單元進行度量分析。從三個方向進行度量分析,分別:圈復雜度分析、注釋率分析、扇入扇出分析。首先對待測單元進行控制流的分析,通過控制流圖的程序流程進行圈復雜度的分析及統計。其次對待測單元的總行數、代碼行數、注釋行數進行統計,并計算注釋率。最后對待測單元的調用情況進行數據統計,計算統計出待測單元的扇入扇出數。
工具設計需具備高效易用的編碼規則檢查功能模塊,集成了包括MISRA C/C++2012、GJB8114等規則集中的重要規則,同時支持自定義規則集導入。源代碼進入規則集檢查器,規則集檢查器運行每條規則的算法,對代碼進行遍歷檢查。通過的代碼,進行代碼遞增和規則遞增;未通過的規則進行缺陷統計和定位。
2.4控制流測試
控制流測試用例自動生成。本工具設計通過符號執行技術對函數路徑的遍歷,讓機器理解代碼。用戶將目標程序提供給系統編譯器前端,在編譯解析產生中間文件后,符號執行工具對中間代碼進行符號執行,即對目標程序路徑空間進行逐路徑探索,從而自動化地對應生成較高覆蓋率的測試用例集。
符號執行以符號值作為程序的輸入,符號化地執行程序,程序的輸出也為變量的表達式。使用約束求解器來判定程序的路徑是否可行。符號執行技術能夠遍歷程序的路徑空間,檢查程序是否滿足特定的性質。
2.5功能測試
進行自動化的控制流測試之后,僅能驗證每個軟件單的語句、分支、修正的條件組合覆蓋,無法驗證每個軟件單元的功能。故開發功能測試模塊,解析羅列出每個軟件單元的全局輸入變量,并對調用的軟件單元進行打樁。用戶通過圖形化的界面,結合軟件詳細設計規范中,每個軟件單元的功能邏輯,對每個軟件單元的全局輸入變量進行賦值,對樁單元進行返回值設置。
2.6缺陷追溯
工具在高覆蓋率分析函數路徑的同時,還具備能實現程序中缺陷的精準查找,結合系統自動化生成測試框架的能力,工具在測試過程中發現的缺陷,是在特定的參數條件下,根據函數路徑執行求解中確定。所以,所有的缺陷都需要能夠準確定位到代碼具體位置,并展示該缺陷發生的具體條件。
2.7信息統計
工具對軟件測試信息進行信息統計,提供統計信息界面和項目看板界面。統計信息界面用數字和圖形方式展示當前用戶全部測試工程統計信息,包括工程數量、總函數數量、總代碼量、測試用例數量、已分析/未分析函數數量、工程類型分布、各工程函數平均覆蓋率以及不同類型工程中函數覆蓋率分布。
2.8持續集成
當前軟件行業的測試多趨向于自動化、智能化。在此工具中,對關鍵的功能點進行了后端調用接口的開發,實現了通過命令行的形式進行自動化調用。分別實現源碼解析、靜態分析、控制流測試、數據導出的腳本驅動操作。通過與jenkins進行插件式集成,實現了源碼上傳即可觸發自動拉取代碼,傳輸至工具,觸發測試的機制。
3總結
隨著功能日益強大的嵌入式系統不斷發展并投入廣泛應用,如何保證軟件質量成為了工程技術人員必須要解決的難題。軟件單元測試是嵌入式軟件開發過程中早期進行軟件功能驗證,可靠性確認的重要手段,對后續階段軟件測試與保證軟件質量具有重要意義。
本文針對嵌入式軟件單元測試,設計了一款源碼解析、靜態分析、控制流測試的自動化執行工具必將在提升嵌入式軟件質量方面發揮愈加重要的作用。