城市軌道交通車輛運行參數監測系統軟件單元測試方法研究

秦 昊，肖曼琳，王振宇，楊 霄，蔡燁玲

（上海工程技術大學城市軌道交通學院，上海 200000）

隨著中國城市化進程的加快以及基礎設施建設的發展，城市軌道交通客運里程以及客運量不斷增加，保證城市軌道列車的安全運行成為相關行業和社會越來越關注的任務。

目前，國內大部分列車均搭載基于MVB 標準的網絡控制系統，即實時采集列車運行情況，并將這些信息通過MVB 網絡數據顯示出來，并加以分析和處理，從而完成對車輛運行系統的參數監測，并且最后通過上位機軟件，即車輛運行參數監測系統軟件，動態顯示以告知司機列車當前的各種狀態。車輛運行系統參數監測系統工作流程如圖1 所示。

圖1 車輛運行參數監測系統工作流程示意圖

本文介紹了車輛運行參數監測系統軟件單元測試的方法以及研究過程，但是由于該軟件的功能單元數量巨大，并且每個單元中設計的函數運算數量龐大、邏輯復雜，軟件工作時輸入信號多變，所以設計合理的軟件單元測試方法，完整并高效地完成功能單元測試，具有很強的軟件工程實踐意義。本文主要研究了車輛運行參數監測系統軟件單元測試的方法以及過程，其具體內容安排如下：第1 節敘述了單元測試的背景，第2 節介紹了單元測試原理以及測試方法，第3節分析了軌道交通車輛信號軟件單元測試的基本要求并設計了測試步驟，第4 節展示了車輛運行參數監測系統軟件單元測試流程及測試結果，第5 節總結。

1 單元測試背景

對自己書寫代碼的檢測往往會被工程師忽視，且代碼檢測存在粗略、不規范等諸多特點，如文獻[1]僅僅介紹了計算機軟件的黑盒測試這一種方法。在文獻[2]中采用了C++test 動態測試來測試軟件函數運行中存在的問題，用函數覆蓋率體現，具體點就是通過函數調用的檢測來快速準確找到具體的問題函數，卻無法確定整體函數的運行模式等，即不完整的動態測試。文獻[3]是從單元測試中動態測試方法與規范方面引入，是一篇理論指導方面的論文，側重于動態測試的闡述與分析，缺少在動態情況下函數調用獨立運行、靜態測試等在軟件測試中的問題解決方法與實際操作。文獻[4]采用底層模擬技術優化了打樁技術，因為大部分軌道運行的軟件都是嵌入式的，與電腦的操作系統不同，有著獨立的無法識別的函數，這個時候就需用打樁技術來解決，但又不是所有的函數都需要進行，所以不具有普遍性。對比以上文獻中所提到的測試方法，本文所包含的測試方法更加全面，而對于檢測工具的合理使用也使測試效率大幅提升，也能更加直觀地發現未被覆蓋的代碼，便于測試人員以及開發人員后續修改和檢測。現在還不存在一套對各類軟件都通用的測試方法和流程，所以本文旨在保證被測軟件正常運行，研究和設計一套測試方法和測試流程，并完成對該軟件的單元代碼全面和嚴格的測試，保證軟件良好運行。

2 軟件單元測試

2.1 單元測試原理

單元是由人指定要測試的最小的功能模塊。單元測試是軟件開發過程中最低層次的測試活動。獨立的軟件單元將與程序的其他部分分開進行測試。根據軟件源代碼程序和軟件設計說明書，了解輸入輸出范圍的功能限制和代碼邏輯原理，測試分析軟件編碼是否正確，并確定軟件界面和單元功能是否滿足軟件設計規范的要求。

2.2 單元測試方法

2.2.1 靜態測試

靜態測試指不需要軟件代碼運行即可進行的測試[5]。可用來檢測軟件代碼的基本質量，檢測是否存在簡單錯誤，包括定義的沖突或歧義，它進一步測試的前提，可以為之后的測試排除基礎錯誤，也可以檢測軟件代碼的完整性以及是否一致，代碼編寫是否符合規范[6]。

2.2.2 白盒測試

白盒測試又名邏輯驅動測試，是一種對代碼結構的測試，運用白盒測試前需要了解代碼的邏輯以及代碼如何運作，白盒法是窮舉路徑測試。

2.2.3 黑盒測試

黑盒測試是一種關注軟件外部結構的測試，是將軟件代碼看做一個無法打開的黑盒子，不需要考慮內部結構，是一種主要面對軟件界面以及軟件功能的測試。

3 軌道交通車輛信號軟件單元測試

3.1 軌道交通車輛信號軟件單元測試基本要求

目前，軌道交通信號軟件測試的標準規范主要為ISO 29119-3《軟件測試國際標準》和MISRA-C：2004《Guidelines for the use of the C language in critical systems》等文件。

軌道交通信號軟件單元測試一般應滿足以下要求：首先，要保證軟件的行為和性能滿足對應測試規格的要求，軟件測試應遵循先靜態再動態的測試原則；其次，測試用例應包含輸入、輸出2 部分，能驗證函數的正確性，測試通過準則為BUG 數等于0，對于錯誤較多的函數，應進行多次測試；最后，組合條件覆蓋率應達到100%，特殊情況下，組合覆蓋率不能達到100%，應經過人工驗證代碼，并給出合理解釋和說明[7]。

根據認證標準以及行業規范總結了以上要求，并以此作為測試規范。

3.2 軌道交通車輛信號軟件單元測試方法步驟

根據軟件測試的易錯性和單一性，筆者們選擇C++Test 9.5 以及Keil uVision5 作為單元測試的工具。C++Test 是面向C 語言的單元測試工具，該軟件能夠自動進行白盒測試、黑盒測試和回歸測試。因此，該軟件可以高效完成對軟件的底層測試，能夠有效降低軟件錯誤率，提升軟件運行穩定性。Keli uVsion5 主要用于嵌入式單片機編程。

4 車輛運行參數監測系統軟件單元測試過程

4.1 測試流程研究

設計針對被測軟件的測試方法和測試流程，并完成對被測軟件的具體測試。基本的軟件測試大致流程如圖2 所示。

圖2 軟件測試基本流程示意圖

代碼質量測量、控制流、數據流和編碼規則檢查是通過C++測試、結合工具和手動檢查完成的。采用人工方法分析編碼規范的一致性以及編碼與詳細設計的一致性。流程如下：首先對被測代碼進行解讀，根據代碼的運行流程與復雜程度從而制定相應的檢查單，分為軟件分析與人工走查2 類，分別進行測試，再將軟件測試中出現錯誤的代碼進行人工走查，人為修改約束條件，進行針對性測試。

4.2 測試過程及結果

第一階段為基于C++Test 的軟件靜態分析。代碼質量度量、控制流、數據流和編碼規則檢查是通過C++測試來執行的。檢查內容為MISRA-C：2004 規則、度量指標規則、最優化規則等規則，規則搭建方法如圖3所示，目的是找出欠缺和可疑之處，測試流程如圖4所示。結果將展示被測代碼中有多少行代碼違反了何種規則，測試結果如圖5 所示，并將靜態分析中產生的錯誤整理出來，包括錯誤代碼發生的位置及內容。

圖3 靜態測試規則搭建

圖4 靜態測試流程

圖5 靜態測試結果

單元測試菜單如圖6 所示，在C++Test 任務欄里發現，有30 行代碼違反了規則，其中25 行代碼違反了MISRA-C： 2004 規則，3 行代碼違反了度量指標規則，2 行代碼違反了最優化規則。

圖6 單元測試菜單

第二階段為基于覆蓋率分析的白盒測試。通過分析測試系統軟件模塊內部的路徑執行和邏輯分支，選擇覆蓋分析的方法，使軟件的4 個覆蓋率達到100%。具體測試流程如下：建立單元測試、建立樁函數、收集樁函數信息、運行單元測試。以上流程均由圖7 所示菜單完成，由測試結果可以得出被測代碼的各種覆蓋率。由此可以對代碼的質量進行分析，并判斷該代碼是否需要進行人工走查。

圖7 單元測試結果（被測軟件覆蓋率）

第三階段為基于等價類和邊界值的黑盒測試。通過4 步完成黑盒測試：①明確函數代碼結構中所包含的輸入、輸出變量，以及輸入輸出邊界值，如圖8 所示，分析輸入輸出判斷是否為無效等價類數據；②建立測試用例，需在測試工具中建立外部數據庫，手動建立測試用例庫；③添加測試用例數據，同時，對函數內部調用的其他函數進行打樁處理，生成樁函數；④對樁函數輸入值進行修改，以滿足軟件運行需求，在樁函數與測試用例都無誤后，進行測試。

圖8 函數代碼的輸入輸出值

5 結束語

目前，在軟件測試領域，單元測試的重要性正在被逐漸發現，但往往由于項目時間短、資金缺乏等原因導致了軟件單元測試工作難以開展，測試質量不能被保證。因此了解單元測試的優點，并研究一種高效準確的測試方法有著重要的意義。本文在理論方法的研究和實際軟件測試的基礎上，對軌道交通車輛信號軟件單元測試方法進行了研究，并對系統中重要組成部分進行測試與分析，能夠高效地找出軟件開發過程中存在的缺陷，并提醒開發人員及時糾正，確保軌道交通車輛信號軟件的穩定性和可靠性，進一步提高信號系統的安全性。