楊永國
摘要:為了緩解嵌入式信號處理軟件構件人工測試的不足,設計一種自動化測試框架極為必要。基于此,本文從特征與主要流程入手,明確了嵌入式信號處理軟件構件測試的內容,并依托三層體系架構完成嵌入式信號處理軟件構件測試框架的設計,分析了測試框架中不同的功能單元。
關鍵詞:嵌入式信號處理軟件;構件測試;自動化測試
中圖分類號:TP274.2 文獻標識碼:A 文章編號:1007-9416(2019)10-0184-02
0 引言
對于嵌入式系統來說,其主要被應用于特定的硬件設備上。由于有著更高的功能性與可靠性,因此在當前更加常用于雷達信號處理中。受到嵌入式系統自身特征的影響,對其展開測試工作具有較高的難度,傳統的人工測試難以更好滿足當前嵌入式系統的測試需求。以此,探究嵌入式系統自動化測試方法有著極高的現實價值。
1 嵌入式信號處理軟件構件測試的簡述
1.1 測試的特征分析
對于嵌入式信號處理軟件構件測試來說,其特征主要如下:第一,在實際的測試中,必須要保證在實物板卡中展開。造這一情況的原因主要為多數硬件設備難以匹配上合適的模擬器,同時一些能夠匹配上的模擬器無法滿足實際要求的處理性能[1]。第二,軟件單一測試中的測試數據量的最高可達到MB級。在這樣的背景下,并不能直接展開測試數據值的直接輸入,必須依賴仿真程序實現數據的產生。第三,硬件與測試的驅動程序必須維持在緊密耦合的狀態。同時,測試的驅動程序必須要在與硬件庫包交叉編譯并形成可執行文件的條件下,才能夠投入實際的運行。
1.2 測試的過程分析
在嵌入式信號處理軟件構件測試的輸入層面中,包含著待測構件、測試場景;在上位機層面中,包含著測試數據生成、預期結果生成、測試用例生成、結果驗證、測試報告編寫、測試結果上傳等等,主要實現了對測試的設計、用例的生成與比較;在硬件設備層面,主要實現了測試過程的執行,并在網口的支持下與上位機層面實現連接。
對于嵌入式信號處理軟件構件測試來說,其主要流程如下所示:依托待測構件的實際情況完成用例場景的測試,在形成測試輸入數據、預期輸出結果后,實現測試用例的生成;在測試用例的支持下展開測試驅動的編寫,并在交叉編譯后直接下載到硬件運行層面;測試完成后輸出結果,并對比前期產生的預期輸出,實現測試結果的形成與確認;依托測試結果輸出嵌入式信號處理軟件構件的測試報告。
2 嵌入式信號處理軟件構件測試的框架設計
2.1 總體測試框架設計
在本研究中,主要使用三層體系架構完成嵌入式信號處理軟件構件測試框架的設計。其中,主要將測試框架劃分為數據訪問層、業務邏輯層以及表示層[2]。在該測試框架的數據訪問層中,包含著數據庫的訪問接口(與數據庫進行連接)以及硬件通信接口(與硬件設備進行連接),主要與數據庫、硬件設備建立起交互的關系,在相應接口的支持下,完成數據的上傳與提取。在本測試框架的業務邏輯層中,包含著數據產生、測試執行以及結果驗證單元,主要實現了預期結果、測試用例輸入數據的生成。同時,在前期設置的測試步驟的支持下,實現驅動代碼的生成,并交叉編譯至硬件設備中展開運行。業務邏輯層還能夠實現測試結果的接收,并在此基礎上驗證測試結果的正確性。對于本測試框架的表示層來說,包含著測試用例、測試報告以及系統日志單元,主要為用戶提供了人機交互界面、數據輸入與輸出的接口。此時,用戶可以完成測試用例的導入、下載測試結果,與此同時,還能夠在實際的測試中展開測試過記錄的實時性查詢。
2.2 測試框架的具體單元設計
2.2.1 驅動調用單元
對測試執行過程展開描述的代碼為測試驅動代碼,其中,最為簡單、常見的測試驅動代碼為待測試構件的調用函數。對于嵌入式信號處理軟件來說,其測試驅動的內容一般為固定內容,包括測試輸入數據的載入、待測構件執行的調用、構件輸出數據的保存。然而,上述操作內容均需要硬件地層函數的支持,因此在傳統的嵌入式信號處理軟件構件測試中更多的使用了人工編程的方法。
針對這一情況,在本次構件測試框架的驅動調用單元設計中,主要引入了一種自動生成測試驅動代碼的方法。為了實現這一目標,需要依托不同的硬件平臺完成硬件庫、基礎驅動程序模板的打包,并轉化成基礎鏡像。在此基礎上,引入了加載參數以及被調構件信息,并將其視為配置納入驅動中。此時。測試框架可以依托硬件平臺的不同類型,直接在基礎鏡像庫中提取與硬件平臺相對應的驅動鏡像,實現配置文件的生成。
2.2.2 數據產生單元
對于數據產生單元來說,主要實現了輸入硬件設備中測試數據的生成,并為測試結果與預期結果的對比提供支持。由于上述兩項功能的實現均需要仿真程序生成數據的支持,因此,在本單元設計主要因進入了測試用力表的解析,完成對仿真程序、相關參數的獲取,最終實現測試數據的批量產生。
2.2.3 結果驗證單元
在結果驗證單元中,主要實現了測試用例表中的預期數據、實測結果的計算,并在此基礎上形成測試結果,為后續嵌入式信號處理軟件構件測試結果報告的生成提供支持。
2.2.4 報告編寫單元
在報告編寫單元中,包含著的標準的測試結果輸出模板及文本轉換工具,例如T4工具箱、mlreportgen庫等等。該單元能夠結合用戶的實際選擇完成文本模式的轉換,并自動融入測試報告的編寫中,最終生成標準的測試報告。
2.2.5 日志單元
對于該測試框架中的日志單元來說,主要實現了整個嵌入式信號處理軟件構件測試過程的監控,并完成測試信息的保存,為用戶排查測試問題提供了有力支撐。在日志單元的實際運行中,會對硬件設備、測試代理以及測試業務展開重點監測。其中,對硬件設備的監控需要依托硬件設備中額外設置的監控線路完成。在監控測試代理中,主要依托自動化測試工具檢查點產生的檢測結果完成。在監控測試業務中,主要利用了不同單元關鍵點的插樁所反饋的實時狀態信息完成。
2.2.6 測試代理單元
測試框架與底層軟硬件的接口為測試代理,該單元主要完成了訪問數據庫、下載數據、控制硬件設備上傳數據等功能。在測試腳本的支持下,測試代理單元實現了與硬件設備的連接。在本測試框架中,主要使用了QTP腳本錄制功能,控制上位機完成硬件設備中FTP的訪問,最終完成清理、上傳與下載數據。
在測試代理單元中,包含著能夠連接數據庫的標準接口,對測試業務訪問數據庫的實現提供支持。此時,測試驅動能夠結合實際需求完成基礎鏡像庫及報告模板的調取。
3 結語
綜上所述,為了更好滿足當前嵌入式系統的測試需求,設計一種嵌入式系統自動化測試方法極為必要。依托三層體系架構,實現了嵌入式信號處理軟件構件測試框架的設計。在驅動調用單元、數據產生單元、結果驗證單元、報告編寫單元、日志單元、測試代理單元的支持下,該測試框架的可行性更高,且實現了對嵌入式系統的自動化分析,彌補了傳統人工測試的不足。
參考文獻
[1] 程知敬,張晉文,劉鳳.一種嵌入式信號處理軟件構件測試框架[J].現代雷達,2019,41(06):82-85.
[2] 楊光.基于FPGA的嵌入式信號采集與顯示系統的設計[J].電子技術與軟件工程,2016(16):200-201.