城市軌道交通信號系統的自動化測試平臺設計

張 鑫

（湖南中車時代通信信號有限公司 北京分公司，北京 100070）

0 引 言

近年來，城市軌道交通通信信號項目激增，為了讓有限的人力資源滿足大量的工程項目需求，需要設計一套完整的自動化測試系統來適配不同的工程線路，同時最大程度降低軟件開發的成本并縮短周期。使用軟件對結果進行判定，可以避免人為的錯誤，防止存在安全隱患的軟件發布到現場。

1 測試流程分析

1.1 測試模型的確定

設計自動化測試平臺之前需要清楚整個工作的流程，包括前期人員和環境的準備工作、中期的具體操作過程以及后期的維護工作等。測試模型的選擇對于整個測試工作來說具有很強的引導作用，對于測試平臺的搭建來說也具有一定的指導性。從測試模型中可以很好地知道在測試過程中每項工作之間的相互關聯性或制約性。除此之外，測試工作也是項目開發的一個重要環節，測試模型能夠很好地展現出開發前期工作與一系列測試過程的關聯。測試模型確定好之后，能夠更合理地安排后續的平臺搭建工作，使得多項目共同進行時能夠在最短的時間內保質保量地完成測試工作[1]。

根據流程結構，將目前已有的測試模型分為V、H、W這3種類型。V模型是這幾種模型中最早被提出來的，主要是為了解決研發和測試的協同工作的進度問題，其架構如圖1所示。

圖1 V測試模型架構

為了在完成測試工作任務的同時簡化測試流程和測試平臺開發的工作量，選擇V模型作為測試平臺搭建的依據。

1.2 測試流程設計

為了保證自動化測試能夠很好的執行，需要既有的測試用例作為后盾，這些用例由人工測試驗證過，測試步驟有準確的測試結果相對應。測試人員需要明確每一個用例在經過自動化的步驟后是否能得到預期的測試結果。除此之外，一個優質的自動化測試平臺是可以重復循環執行這些被選中的用例，并且前一次的測試結果不會影響到后續的測試執行和結果的判斷。平臺執行流程如圖2所示。

圖2 平臺執行流程

根據自動化測試流程圖，可將整個自動化測試分為4個階段。

第一階段：軟件更新和環境配置。每一條同程線路的數據都不相同，為了保證城軌信號系統的測試平臺適配不同的項目和工程線路，在城軌信號系統自動化測試平臺設計一個環境配置模快來對不同線路的數據和參數進行配置，以適應多項目同時測試的需求。該模塊在平臺啟動前就完成設置，與后續的測試腳本完全分離，不影響后續測試腳本的編制和讀取。

第二個階段：測試腳本選擇或腳本制作。如果只涉及到軟件問題的修復，那么一些既有的腳本可以加載后直接運行。而如果涉及到軟件新增功能，那么則需要增加與之匹配的用例和腳本[2]。每一次的測試之前根據分析需求的變更和影響的范圍來選擇需要執行的腳本，每一個腳本都具有獨立性，可根據需求獨立執行。

第三個階段：判斷腳本測試結果是否與預期結果相同。在腳本執行過程中也可能存在由于意外信息的刺激或干擾而中斷測試，所有腳本結果判斷和結束的過程都將被記錄下來，跳過這個錯誤并將整個測試環境恢復到初始狀態后繼續執行后續的測試腳本。

第四個階段：測試結果的統計、測試報告的生成以及后續的缺陷管理。通過完整的測試模塊，測試人員能夠有效回溯整個測試的過程，并從中查詢過程中出錯的步驟和原因。

2 自動化測試平臺結構設計

2.1 平臺整體框架設計

本文設計的城軌信號系統的自動化測試平臺結構如圖3所示，主要由被測和陪測對象、仿真模型模塊、自動化測試驅動模塊、交互環境模塊、測試結果比對模塊以及測試管理模塊組成。

圖3 自動化測試平臺結構

2.2 自動化測試驅動模塊設計

自動化測試驅動模塊分成兩個部分：一部分負責加載和識別配置中的數據（不同線路的電子地圖數據和一些基本的網址配置等），并將這些配置數據讀取到模塊內存中，用于后續匹配腳本文件中的信息；另一部分負責分析腳本文件，并根據腳本文件執行相應的動作。驅動模塊主要驅動的是既有的軌旁仿真、駕駛臺仿真模型以及車輛模型，將這3部分按順序編號，驅動模塊根據目標模型的ID編號向目標模型發送后續的執行命令內容。在進行模塊編碼之前，先根據測試的實際需求將所有的測試執行動作列成一個規定的列表。需要執行的動作具有唯一的編號，自動化測試驅動模塊和仿真模塊都要根據這個表的對應關系來執行動作。除此之外，還需要一些數據命令的加入，包括列表中所有的執行動作都需要知道該動作執行到某一個具體的目標設備，如辦理進路的這條動作命令針對的是某一條實際的進路數據。為了使自動化測試平臺可以適配不同實際城軌項目，可以通過讀取配置和電子地圖數據的方式來實現。總的來說，驅動模塊主要識別腳本的仿真目標ID、制動命令ID并執行命令的具體數據，仿真目標根據收到的信息對特定的目標設備執行動作。

2.3 腳本制作模塊設計

從制作的角度來看，腳本是由多條文本命令組合而成。通過文本可視化的方式讓測試人員更加簡單地對腳本進行編輯。通過交互環境中的制作模塊，自動生成由JSON語言寫成的腳本。從測試用例的角度來說，腳本就是將現有的由自然語言寫成的測試用例轉換成測試平臺能夠識別的文件，并存儲在平臺中，每一個用例需要有一個腳本與其對應。生成腳本文件后，測試人員可以根據功能或者按照測試的需求進行分類，為每一個用例和腳本分配唯一的ID編號[3]。

本文設計的腳本結構目前主要包括4部分內容：一是目標，在目標變量里填寫相應的目標仿真模塊ID，即驅動哪一個仿真模塊動作；二是執行的命令ID，驅動模塊通過識別這個ID來確定執行某一個具體的動作；三是腳本的具體數據，如設置某個信號機的開放和禁止狀態時，這里的數據內容為具體的目標信號機的ID號；四是腳本的期望結果，每一個用例都有一個預期的結果狀態，寫在腳本的最后一部分，用于在腳本自動化測試執行完之后進行測試結果判斷。

2.4 測試結果分析模塊

測試結果分析模塊需要考慮兩個方面，分別是確定預期的輸出結果和選擇自動對比的技術。測試執行完一個腳本之后會生成相應的輸出文件，需要與標準的預期結果進行比較來判斷測試或軟件的正確性。測試結果分析模塊具有其軟件期望的輸出，并形成一個特定格式的輸出文件。對于城軌信號系統來說，設備量和數據量太大，測試人員書寫每一個腳本的預期結果時不能描述所有設備的狀態。使用對特定設備ID描述的原則，預期結果格式為設備ID對應期望結果，測試人員只需要對其關注的一些設備進行期望結果的描述，在生成腳本中預期結果部分時其他設備全部自動補充為默認值。自動化測試執行完一個腳本后會將所有的設備狀態轉換為一個輸出文件，該文件包含車載列車防護子系統的狀態等。每個子系統的ID與設備ID結合形成設備唯一ID，輸出設備ID和設備狀態的個數。結果分析模塊從實際輸出狀態文件中挑選出腳本中描述的本次測試所關注的設備對象，只判斷這些設備ID的狀態是否符合預期輸入[4]。對于腳本中所有填寫默認值的設備，結果分析模塊都不會進行分析比對。根據比對結果，如果有實際輸出結果與腳本中預期結果不符合的選項，則本次執行的腳本測試失敗。

3 結 論

通過設計用于城軌信號系統的自動化測試平臺，能夠根據需求實現腳本編寫、自動生成測試報告、全程管理測試缺陷等功能。目前該平臺仍存在一定的問題，未來將進一步完善并優化對腳本進行模塊化的處理和對優先級的處理，使系統的適用性更強。