列控車載設備測試案例輔助管理工具設計

賴 琴，張亞東，饒 暢，郭 進

（1. 西南交通大學 信息科學與技術學院，成都 611756；2. 重慶交通大學 交通運輸學院，重慶 400074）

列車運行控制（簡稱：列控）系統是典型的軟件密集型安全苛求系統，列控車載設備作為列控系統的關鍵組成設備之一，主要實現列車運行安全防護的功能，一旦發生軟件失效可能會導致災難性的后果，因此需開展嚴格測試保證車載設備軟件質量[1]。列控車載設備測試多依賴于專家經驗，測試人員根據列控車載設備需求規范編制測試案例，向車載設備輸入測試內容，觀察其輸出結果，驗證設備功能[2]。

目前，列控車載設備測試過程中缺乏高效的案例輔助管理工具，存在案例覆蓋的測試需求和測試案例管理不便、測試案例編制效率不高、測試案例統計分析依賴人工等問題。因此迫切需要結合數據庫、計算機等技術提升列控車載設備測試過程案例管理的信息化水平。

本文針對現有問題，設計了列控車載設備測試案例輔助管理工具。該工具提供基于規格測試、模型測試和組合測試3 種方法編制測試案例，自動統計案例相關數據，根據測試結果記錄生成測試報告文檔等功能。使用該工具開展測試，降低了人為因素帶來的差錯影響，提升了測試案例編制效率與管理維護水平，進一步規范車載設備的測試流程，為其他鐵路信號設備測試案例管理提供參考。

1 列控車載設備測試

1.1 列控車載設備仿真測試平臺

列控車載設備仿真測試平臺包含仿真數據生成平臺、接口仿真設備平臺與被測車載設備3 個部分，其架構，如圖1 所示。

圖1 列控車載設備仿真測試平臺架構

（1）仿真數據生成平臺：用于生成車載設備運行過程中的環境仿真信息。列車操縱臺模擬司機速度、運行方向等操作信息；數據配置單元產生應答器報文、軌道電路碼序等仿真數據；車輛模擬器根據列車數據實時計算列車速度、位置等信息；地面模擬器根據車輛速度位置信息計算應答器與軌道電路信息的接收時間等信息；測試控制單元實現測試過程監控，傳輸仿真數據并接收車載設備狀態信息。

（2）接口仿真設備平臺：將仿真數據轉換為標準信號接口數據，發送給待測車載設備，同時將接收被測車載設備狀態信息轉發給仿真數據生成平臺。

（3）被測車載設備：根據接口輸入數據，配合DMI（Driver Machine Interface）界面人工操作，執行動態仿真測試，輸出車載狀態信息。

1.2 車載設備測試流程

本文主要關注車載設備的系統測試過程，測試流程，如圖2 所示。

圖2 車載設備測試流程

車載設備測試流程通常分為測試需求提取、測試案例編制、測試執行和測試總結4 個階段[3]。

（1）需求提取階段測試人員分析車載設備相關技術規范，提取被測設備的功能點，確定車載設備測試需求[4]。

（2）對測試需求進行細化，編寫測試案例。

（3）測試人員將測試需求與測試案例作為測試指導文件，在列控車載設備仿真測試平臺配置相關數據，控制列車運行，執行測試，驗證車載設備功能。

（4）記錄測試結果，并形成測試報告。

開發人員依據測試結果修復缺陷后，測試人員以當前測試案例為基礎開展回歸測試，重復測試流程，確保缺陷被修復且現有功能模塊依舊正常。測試案例可指導實施列車運行控制系統的仿真測試執行工作；合理管理測試案例能夠提升測試前期準備與測試后期的分析整理效率，并規范管理案例相關的數據。

2 研究基礎

軟件測試是通過軟件自動運行或人工操作檢查軟件潛在的各種錯誤與缺陷，確保軟件各項指標參數達到規定需求的過程[5]，相關定義如下。

定義1（測試需求）：測試需求表示軟件系統的一個基本測試單元，例如一個功能項或一個被測特征[6]。

定義2（測試案例）：測試案例是待測軟件的一組輸入數據，用于驗證是否滿足某些特定測試需求。

列控車載設備的測試案例遵循歐洲列車控制系統（ETCS，European Train Control System）測試規范Subset076 格式要求[7]，包含了案例基本信息、初始條件、初始接口條件、測試步驟、結束條件、結束接口條件等信息。

定義3（覆蓋）：若測試案例能夠驗證某項測試需求，稱測試案例覆蓋該測試需求。

3 工具開發方案

3.1 功能需求分析

（1）測試需求管理。測試人員能直觀查看測試案例所對應的測試需求，支持測試需求增刪改查，自動校核測試需求避免出現重復錄入的情況，并提供測試需求文檔導出功能。

（2）測試案例輔助編制及管理。工具提供基于規格測試、模型測試和組合測試方法的新增測試案例，提升測試案例編制效率。此外，測試人員還能便捷利用工具對測試案例進行查閱修訂并自動校核案例庫數據，支持自動導出標準格式測試案例。

（3）測試統計分析。工具能根據需求與案例信息自動完成相關數據的智能統計，實現數據可視化展示并實時更新，避免測試案例編制不完善造成漏測。支持測試結果記錄并按照固定模板輸出測試報告，降低人工整理分析測試報告的復雜度與工作量。

3.2 功能設計

根據功能需求分析，本文對工具進行功能模塊劃分，如圖3 所示。

圖3 列控車載設備測試案例輔助管理工具功能架構

3.2.1 測試需求管理

測試需求包括所屬技術規范、需求編號、需求項、需求內容等信息，存儲于MySQL 數據庫。工具測試需求管理模塊主要包含以下內容。

（1）需求增刪改查：支持單條或以CSV 文件形式批量增加需求、批量刪除、修改及查詢測試需求。使用JDBC（Java Database Connectivity）技術訪問需求數據庫完成上述操作。例如批量刪除測試需求，與數據庫建立鏈接，執行sql 語句“delete from req_table where req_num=?”，依次查詢數據庫中被選中的需求并刪除，刷新界面顯示剩余需求信息。

（2）測試需求校核：校核需求數據庫是否存在重復需求。

（3）需求文檔導出：自動導出需求存檔文件。

3.2.2 測試案例輔助編制及管理

測試案例具有規范的格式，利用MySQL 數據庫存儲。工具對案例實現統一管理。

（1）測試案例編制

測試案例編制模塊支持基于規格的測試方法、基于模型的測試方法與組合測試方法，實現以下4 種功能。

①模板調取解析：支持基于規格的測試方法數據庫模板調取，數據庫主要保存等價類劃分法和邊界值法對速度、距離等參數的劃分結果；支持基于模型的測試方法對UML 狀態圖模型文件調取解析，提取狀態、事件等信息存儲于哈希表；支持組合測試模型txt 文件解析，提取參數、參數取值、約束等。

②模板可視化：以列表形式可視化基于規格的測試方法調取的模板信息；以有向圖可視化UML 狀態圖模型；以樹形圖展示組合測試輸入域模型。

③模板修改：支持基于規格的模板數據庫與組合測試輸入域模型修改保存。

④測試案例生成：基于規格生成測試案例，工具提供與待測功能匹配的案例模板快速編制案例。基于模型生成測試案例以文獻[8]提供的測試路徑生成算法為基礎，支持節點覆蓋、邊覆蓋、邊對覆蓋或主路徑覆蓋準則生成測試路徑，實例化為測試案例。組合測試方法生成測試案例時，工具提供最優覆蓋數組重構算法[9]、IPOG 算法[10]與PICT 算法[11]，可選擇不同覆蓋深度一鍵生成組合測試用例集，導入組合測試案例模板，工具通過關鍵字替換技術自動生成組合測試案例集。

（2）案例查詢修訂

支持修改、批量刪除與模糊查找案例。

（3）測試案例校核

檢查測試案例是否重復，主要檢查案例編號、案例目標等內容，工具界面將校核結果進行反饋。

（4）案例文檔導出

基 于Apache POI 技 術 替 換ETCS 測 試 規 范Subset-076 案例Word 模板數據，導出案例歸檔文件。

3.2.3 測試案例統計分析

本文采用以下指標進行測試案例分析：①測試需求覆蓋度：計算當前測試需求覆蓋情況；②測試需求與測試案例追蹤矩陣：雙向追溯，便于查漏查錯；③測試案例分類統計：將案例按功能、編制方式及需求項進行分類，統計案例覆蓋情況。

測試統計分析模塊劃分為以下子模塊：

（1）指標統計：收集分析需求與案例數據，基于JavaFX 技術將測試案例分析指標以圖表、文字等形式直觀展示，供測試人員參考，需求或案例一旦發生變動，可自動關聯更新。

（2）測試結果記錄：工具支持對未通過測試的需求或案例標記，備注測試結果。

（3）測試報告導出：包含測試問題報告、案例分析指標報告、需求-案例雙向追溯矩陣等文件，將所得圖、表等數據基于Apache POI 技術按規定格式導出。

3.3 業務流程設計

通過充分考慮車載設備的主要測試流程，結合工具功能管理特點，設計了測試需求提取、測試案例編制、測試案例分析3 大核心業務流程。

3.3.1 測試需求提取流程設計

測試人員依據車載設備技術規范等文檔，提取涵蓋功能需求、場景及接口等方面的測試內容；將測試需求詳細信息分條或批量導入需求數據庫；使用工具校核重復查看校核結果；修改完善測試需求；導出需求文件。

3.3.2 測試案例編制流程設計

車載設備測試最關鍵的業務流程為測試案例編制，如圖4 所示。

圖4 測試案例編制業務流程

該階段主要業務流程如下：測試人員根據測試需求與相關技術文檔，選擇工具中合適的測試案例編制方法，調取相應模板并支持進行修改，根據模板生成測試案例，校核后導入案例數據庫，測試人員利用工具實現案例庫查詢修訂，保證編寫正確，導出規范的案例文件。

3 種測試案例編制方法在模板調取及生成時的業務流程存在一定區別，具體情況如下。

（1）基于規格的測試案例編制

基于規格的測試方法依托人工經驗，結合邊界值法或等價類劃分法編寫測試案例逐條覆蓋需求規格，應用于實際測試。具體業務流程：明確待測需求規格，人工提取測試功能特征；確認參數，若為車速或距離等連續性數據，調取數據庫中相關參數劃分模板；根據新增案例界面提示，快捷編寫測試案例。

（2）基于模型的測試案例編制

針對較為復雜的功能或場景時，可使用基于狀態圖模型的方法編制測試案例。具體業務流程：測試人員利用現有公開建模工具（例如Papyrus）新建狀態圖模型，檢查無誤后保存.uml 狀態圖模板文件；導入模板，工具解析模板并可視化展示；測試人員選擇合適的覆蓋準則；利用耦合在工具中的測試路徑生成算法自動生成測試路徑，檢查路徑是否符合要求；實例化測試路徑為測試案例。

（3）組合測試案例編制

某些功能或場景測試可能存在參數間交互組合，應選擇組合測試方法編制測試案例。具體業務流程：測試人員提取待測功能或場景的參數、約束等信息新建組合測試模型；檢查模型是否有誤并修正，保存為模板便于復用；確認覆蓋深度及組合測試用例生成算法；利用工具自動生成測試用例，檢查用例是否滿足要求；導入組合測試案例模板，工具自動替換關鍵詞生成組合測試案例集。

3.3.3 測試案例分析流程

測試人員根據案例分析指標，檢查追溯關系是否正確、需求覆蓋情況是否完全；修訂測試需求與案例；實驗室仿真環境執行測試；記錄未通過的需求、案例，備注車載設備存在的問題；導出測試報告系列文件。

4 工具實現

本 文 利 用Intellij IDEA 2019 集 成 開 發 環 境 進行開發，基于Java 編程語言、MySQL 數據庫與JavaFX 技術實現列控車載設備測試案例輔助管理工具。下面以CTCS-2 級列控車載設備實驗室仿真測試為例，驗證工具相關功能。

需求管理界面，如圖5 所示，A 區為需求管理模塊工具欄，B 區為需求列表，C 區為需求占比統計情況。點擊需求導入/導出按鈕，支持.csv 格式的測試需求文件錄入/輸出；C 區統計各需求項所含需求數及占總需求數的百分比；選中右方車載設備功能，查看對應需求。工具直觀地實現了需求數據的管理。

圖5 測試需求管理界面

編制測試案例支持3 種編制方法，舉例如下。

（1）基于規格的測試編制案例。本文以CTCS-2 級列控車載設備速度監控功能測試案例編制為例進行說明。根據相關技術規范[12]，明確當前需求規格為“棚速度監視區速度容限值的選取”。分析可知，不同模式對速度的限制范圍不同。以PS 模式為例，選取邊界值法開展測試，調取PS 模式邊界值劃分結果，如圖6 所示。點擊新增案例按鈕，工具自動匹配預存的速度容限值測試案例模板，快捷編寫案例。

圖6 邊界值劃分結果

（2）基于模型的測試案例編制。本文以列控過分相場景為例進行說明，分析過分相場景流程，利用Papyrus 工具建立自動過分相的狀態圖模型，檢查保存。點擊工具瀏覽模型文件，將得到的.uml 模型文件導入工具并可視化，如圖7 所示。選擇邊覆蓋準則生成測試路徑共4 條。以路徑1（圖7 中玫紅色線條所標示）為例，實例化為測試案例：列車接收到應答器過分相預告信息，驗證車載設備實現自動過分相控制。點擊導入測試案例，工具反饋校核結果。

圖7 基于模型編制測試案例

（3）組合測試案例編制。本文以編制FS 模式轉SH 模式與OS 模式測試內容為例進行說明。利用工具新建組合測試輸入域模型，如圖8 所示，檢查無誤后保存為.txt 模板文件。選擇覆蓋深度為2，測試用例生成算法為IPOG，點擊測試用例生成按鈕，生成測試用例9 條，如圖8 所示（1、2 為種子測試用例）。導入組合測試案例模板，生成測試案例并自動校核。

圖8 組合測試編制測試案例

測試案例編制完成后，導入案例庫進行管理維護，工具將自動統計相關案例指標，如圖9 所示。測試人員根據分析指標修改完善測試案例。

圖9 測試統計分析界面

隨后開展車載設備仿真測試，點擊工具欄測試問題記錄按鈕，記錄測試結果，如圖10 所示，最后導出測試問題報告。

圖10 測試結果記錄

5 結束語

本文提出了列控車載設備測試案例輔助管理工具，該工具不僅完成了對測試案例、測試需求的規范化管理，還提供一套科學的車載設備人工編制測試案例方法，顯著提升了案例編制效率。工具自動統計測試案例分析指標，篩查未覆蓋需求，克服了人工分析測試案例的局限性。論文工作對于提升車載設備測試過程管理的信息水平具有一定的價值和意義。