鐵路信號產品自動化測試探討

宋西欣，郁文斌

(北京全路通信信號研究設計院集團有限公司，北京 100070)

1 概述

近年來，國內高鐵快速發展，路網規模占世界高鐵60%以上。截止2019年底，國內高鐵運營總里程達到3.1萬km，這是一項非常了不起的成就。列車運行控制系統是高速鐵路的“大腦和神經”，旨在確保列車運行安全。CTCS-3級列控系統[1]作為中國高速鐵路安全運行的核心系統，測試是保障其安全可靠的其中一個重要環節。

北京全路通信信號研究設計院集團有限公司（簡稱通號院）作為高鐵信號設備供應商，為中國高鐵列控系統的安全可靠運營做出了很大貢獻。筆者參與高鐵信號設備測試工作多年，深刻體會了測試技術的發展、測試質量的提升對于高鐵快速并且安全可靠的發展具有重要意義。上萬公里的高鐵線路，如何保障每一公里測試的充分性、正確性，一直是業內測試技術發展的動力所在。如此龐大的工程數據量，帶來的測試工作也是巨大的。因此，自動化測試在鐵路行業領域發揮著舉足輕重的作用。

以通用的自動化測試技術作為分析起點，結合鐵路行業的特點，展開高鐵列控系統自動化測試的論述；針對高鐵信號為特點的自動化測試發展所面臨的問題，提出可行的解決方案并推出一套行之有效的自動化測試框架，力求對于高鐵列控系統各類型設備的自動化測試實現有一定的理論指導意義。

2 自動化測試

自動化測試是每一個測試項目的終極目標。對于自動化測試，雖然各行業不同，但具有通用的理念、理論及技術應用。

2.1 業內情況

國內自武廣高鐵開始應用CTCS-3級列控系統，目前鐵路信號領域的列控系統設備面臨數據量大、樞紐工程數據復雜、變更頻繁等諸多問題，與其他行業自動化測試技術相比：1）鐵路信號領域的自動化測試技術相對落后；2）鐵路信號領域的自動化測試覆蓋率較低，尤其是樞紐工程，有些產品甚至仍舊依賴人工測試。

以通號院的CTCS-3級列控系統產品舉例，聯鎖產品[2]、列控中心產品[3]的自動化測試目前主要使用早期自主開發的系統，無線閉塞中心[4]和車載設備[5]采用引進的國外設備自動化測試框架，臨時限速服務器[6]自動化測試則起步較晚。早期自主開發及引進的自動化測試工具，普遍具有更新慢、維護難、對復雜的樞紐線路支持不足等問題，導致無法進一步提高自動化測試覆蓋率；業內的同行企業，很多是在與其合作的外方公司自動化測試框架基礎上進行引進消化吸收的再次開發，選用的方式主要是通過驗證測試完成后的日志記錄分步執行，嚴格意義上不屬于自動化測試。

以上現象說明，目前通用自動化測試技術在鐵路信號領域的應用有較大程度滯后，因此需要深入分析鐵路信號領域的特殊需求，針對運營里程快速增長引起的龐大工程數據量，以及工程樞紐改造帶來的復雜性、既有線與新建線頻繁改造接入等特點，開發適用于鐵路信號的通用自動化測試技術。

2.2 業外情況

行業外的自動化測試則是另外一番景象。自動化測試技術和理念不斷升級更新，新的自動化測試框架頻繁提出，自動化測試工具更是層出不窮。目前流行的JUnit、TestNG、Selenium+WebDriver、Appium、STAF+STAX、Robot Framework等，尤其是Robot Framework具有豐富的生態系統，發布了各種通用的測試庫、擴展庫、拆件、工具，可充分滿足用戶的二次開發需求。尤其是其強大的數據驅動功能，可以支持excel、XML等各種格式的外部數據，對于鐵路信號工程領域的測試具有極大的優勢。

自動化測試的優勢，筆者認同文獻[7-8]的觀點，這些優點同時也適用于鐵路信號領域：

1) 節省測試時間、進行全面的回歸測試；

2) 增強對于系統質量的信心，其又可以反饋到對系統的改進；

3) 節省人力資源，測試人員可以將精力投入到新功能等其他測試領域；

4) 其工作輸出的成果（工具、腳本框架、自動化用例）都是可以長期重復使用的，是“實在”的、“可見”的成果；

5) 自動化在質量守護和問題快速反饋上起了決定性的作用：大部分需要長期更新維護的軟件，都需要自動化能力幫助防止質量劣化、支持重構；

6) 自動化幾乎是測試活動的終極形式：當某一類測試內容已經被研究透徹，形成了一定的規律和模式，那就可以進一步實現自動化測試。因而自動化也是團隊技術進步的標志之一。

基于上述優勢，通過引入這些框架，構建符合鐵路信號自身需要的自動化測試仍不容易。

首先，市場上流行的測試框架對于支持web、mobile、UI等易于實現。由于行業的差異，對于支持鐵路信號軟件還有一定距離。但是，其通用的理念、理論可以借鑒以實現適于鐵路信號的測試框架實現。

根據ThoughtWorks公司的評估，任何一種自動化測試的分層都可以映射到如圖1所示。

圖1 自動化測試分層圖示Fig.1 Layers of an automatic test

鐵路領域信號產品的人工測試目前都是基于交互式的人機界面，由此可以考慮基于圖1的基本概念，引進市場上流行的自動化測試技術，解決鐵路信號領域自動化測試面臨的問題，從而開發出適應于鐵路信號領域的交互式自動化測試產品,以提升測試效率與質量。

3 面臨問題

高鐵信號領域的工程特點與傳統的測試定義差異極大，但面臨的問題具有很大的相似性。“測試是不能窮盡的”這一基本法則表明，測試是成本與質量的矛盾體，有限資源下的測試窮盡涉及的測試數量是巨大的，因此經常會遇到測試驅動的數據源爆炸、測試序列爆炸、組合條件爆炸、測試路徑爆炸、測試場景分類爆炸等各種無法完成的測試需求或任務，尤其是頻繁更新的高鐵信號領域，由于信號產品面臨各工程場景之間條件的復雜性，導致軟件內部涉及業務功能的條件判斷、軟件外部版本管理的分支化，由此產生后續一系列的工程數據配置迭代回歸頻繁、測試配置分支化等問題。

依據鐵路信號工程測試特點，目前自動化測試框架的構建面臨以下幾個問題：

1) 測試數據源處理；

2) 測試框架方案選擇與構建；

3) 測試工具對于框架的適配開發。

因此高鐵信號產品的自動化測試的實現主要圍繞上述問題解決進行闡述。

3.1 測試數據源處理

無論選擇哪種測試框架，最終的測試都需要落實到案例的執行。首先遇到的問題就是測試數據的驅動方式。進行測試數據驅動，首先需要有數據來源。高鐵信號產品由于工程數據源的標準化顆粒度差異性導致了數據源采集時的不確定性，而后續測試工作開展的基礎是工程數據采集結果，涉及到兩方面的工作：

1) 腳本驅動的數據源構建；

藍寶石最大的特點是顏色不均，可見平行六方柱面排列的，深淺不同的平直色帶和生長紋。那么什么是色帶，藍寶石為什么會有色帶呢？藍寶石色帶是指寶石內部可見的120度夾角,由顏色深淺變化的藍色組成的天然紋路。理解色帶的成因之前，我們必須要了解，藍寶石是結晶形成的。結晶是藍寶石，紅寶石，祖母綠，帕拉伊巴這些單晶體寶石的生長方式，原理就和冰糖結晶一樣，從小小的一粒逐漸長大。

2) 腳本結果匹配的期待數據構建。

高鐵信號產品的自動化測試首先需要解決數據源的標準化。自2018年起，行業內開始推進鐵路信號工程領域工程數據表的標準化工作[9]，并對各產品間接口數據表進行規范，解決由于接口數據表描述不統一導致的信號軟件接口兼容性問題。由此，數據源標準化前進了一大步，但是仍舊遺留諸多問題：

1) 雖然標準化了工程數據表格模板，但是模板內部的關鍵字未明確規定；

2) 接口表內部的關鍵字雖然規范化，但是設備商根據自身信號產品的實現方式，需要二次加工的信息由于各設備廠商產品的差異性無法完成統一規范化；

3) 高鐵線路的頻繁變更、改造導致的樞紐站的數據變更無法標準化；

4) 有些輸入源的數據表由于歷史原因等尚未做到標準化。比如聯鎖產品，電子聯鎖表是聯鎖產品自動化測試的前提，只有提供了標準格式的電子聯鎖表，才具備自動測試的必要條件。目前聯鎖設備供應商僅可獲得非電子化的紙質版本聯鎖表，極大影響了聯鎖產品自動化測試的發展，需要行業主管部門大力推進解決。

3.2 測試框架方案

雖然上文提到一些測試框架及工具，根據高鐵信號產品特點，直接在其基礎上構建基本是行不通的，需要進行大量的接口實現和適配等二次開發后才能構建起來。如何選擇適合高鐵信號產品的測試框架方案，也是制約自動化測試的一大問題。

自動化測試框架是骨架結構，支撐自動化測試的執行環境的構建，其包含數據集合方式、流程、腳本編碼標準、概念、項目層次化、實現。一旦確定了框架，則自動化測試奠定了構建的基礎，如圖 2所示。

圖2 自動化測試框架圖示Fig.2 A test automation framework

目前流行的測試框架基本是針對測試腳本語言實現方式進行分類：

2) 函數型、單領域語言型、多領域語言型、富文檔型。

根據高鐵信號測試從業人員的整體水平評估以及長期的業內經驗總結，數據驅動、關鍵字驅動、富文檔型是比較容易在業內推行的測試案例腳本化方式，且選用語言語法越簡單易懂，越有利于普及推廣。

構建了測試框架，自動化測試的開發即可展開，針對高鐵信號產品，自動化測試開發主要集中在：

1) 測試數據的采集及處理；

2) 腳本的數據驅動處理；

3) 腳本以操作命令模式、業務場景模式的關鍵字驅動；

4) 測試數據驅動的信息在被測設備與外部接口模擬設備的交互；

5) 測試數據驅動的信息在測試驅動組件與外部接口模擬設備的交互；

6) 測試案例預期結果數據的計算；

7) 測試結果的匹配及正確性判斷；

8) 其他輔助性信息處理。

因此，適用于高鐵信號地面產品的自動化測試開發，即是在測試框架下的自動化測試引擎開發。其可以選擇在目前流行的功能和擴展庫強大的自動化測試框架產品上開發（例如Robot Framework有豐富的擴展庫，可以廣泛支持通信、進程調度、隊列、事件等），也可以借鑒其先進的理念進行自主開發。無論如何，這也是制約高鐵信號產品自動化測試的又一個問題。

3.3 測試工具

鐵路信號系統是一個龐大的系統集成系統，尤其是CTCS-3級列車運行控制系統，采用國內現行最先進的信號系統技術，該系統包括地面設備和車載設備。其中聯鎖、無線閉塞中心、列控中心、臨時限速服務器等地面設備，都需要配置大量的工程數據。

工程數據測試是對具體設備所承載配置數據的測試，檢測其是否正確。目前國內高鐵列控系統的工程數據主要是由地面設備進行配置和計算，因此工程數據測試集中在地面設備的測試。每種地面設備均與其他設備實現信息交互，共同完成整體系統的計算功能，保證高鐵系統的安全可靠。地面設備的工程數據測試涉及的測試數據量非常可觀，需要遍歷車站的所有進路信息、區間的閉塞分區信息等，因此其測試結果即是驗證被測設備通過交互的輸入信息執行計算后，其向外部接口設備輸出信息或顯示信息是否正確。每種設備的測試工具則主要是外部設備的接口模擬工具。如果進行自動化測試，需要驅動接口模擬設備按測試案例的數據驅動模式進行數據交互。

信號設備的測試工具開發主要集中在：

1) 數據驅動后的信息處理；

2) 以關鍵字驅動的業務場景操作處理；

3) 信息按驅動執行與被測設備的交互功能；

4) 信息按驅動執行與測試驅動組件的交互功能；

5) 其他日志等輔助信息處理。

以合作過的某外國公司信號設備商自動化測試框架為例，有如下缺點：

1) 工具部署異構，接口較多；

2) 存在大量的人工輔助工作；

3) 缺少模塊擴展接口，未考慮維護簡易化；

4) 由于信號產品測試是判斷被測設備輸出信息的正確性，因此腳本化語言選用了匹配自然語言的腳本編程語言，屬于小眾化腳本語言，推廣困難；

5) 未開源且技術未轉讓。

4 解決方案

通過詳細分析并總結從業多年的經驗積累，筆者認為解決上述問題的思路是在引進目前流行的自動化測試技術前提下，構建符合高鐵信號產品自身特點的自動化測試框架，從而自主開發適應高鐵信號產品特點的自動化測試平臺，也就是測試引擎。這樣既可以保持技術的先進性，又可以把核心技術掌握在自己手中，摒棄受制于外來公司技術的瓶頸限制，在測試環節實現和實踐為國內高鐵技術發展安全可靠性的保障。

4.1 測試數據源處理

依據本文3.1節提出的問題，首先需要從數據源上進行分析。當前各設備供應商地面信號設備的處理方式均為數據導入后進行內部標準化，以提供給用戶統一的數據提取接口。其使用的常見技術為數據庫技術，即從數據源直接到數據庫的處理方式。為了解決3.1節的問題，可以采用中間適配技術，在數據源和目標之間實現一層適配，適配的技術可以引進目前流行的技術：

人工智能：CTCS-3級列控系統涉及的地面產品（列控中心、無線閉塞中心、臨時限速服務器等）工程數據配置的來源是工程數據表。3.1節已經提到，雖然目前規范了格式的標準化，但是由于各種客觀原因，仍舊存在無法標準化的內容。例如表頭名稱的定義、公里標數據的字符串格式等。針對這些問題，可以引入AI的“基于概率的推論”，技術推理最有可能的匹配結果進行分析后確定數據的處理方式，“專家系統”的技術對未識別出的內容進行學習擴展。利用AI的機器學習和算法生成最優測試案例或者制定測試策略則是另一個課題，不在本文中討論。

關鍵字模糊匹配：模糊匹配的算法和實現的技術也可以用于解決本節的數據源處理問題，而且跨平臺跨語言提供了豐富的開源庫可以使用。最為熟知的是搜索引擎的模糊匹配處理算法，對于常用的字符串處理，極大程度上適用于工程數據表中關鍵字的模糊匹配。例如錯別字匹配、近義詞匹配、長尾詞擴展匹配等技術可以借鑒后引進，在工程數據表數據導入時用于解決遇到的各種問題。

4.2 測試框架

前面已經提到，沒有流行的測試框架是針對高鐵信號領域提出的，也沒有測試框架可以直接應用于高鐵信號產品設備的自動化測試框架構建。

針對本文3.2節提出的問題，可以借鑒2.2節中的自動化測試框架技術，針對高鐵信號產品承載功能的數據特點進行考慮：

1) 具有勘查設計屬性，例如地面設備線路數據的里程標系、坡度、速度勘查數據；

2) 具有范圍或距離屬性，例如無線閉塞中心的管轄范圍、移動授權距離；

3) 具有靜態和動態屬性，例如地面設備實時輸出的給定條件下經過計算的安全信息，自身固有配置信息；

4) 具有接口信息屬性，例如聯鎖設備的進路狀態信息、信號開放信息；

5) 具有信息交互屬性，所有的高鐵設備工作模式是通過自身已知的信息計算輸出用于其他外圍設備安全控制的協議信息。例如列控中心、無線閉塞中心向列車輸出移動授權范圍內的線路信息；車載人機界面DMI輸出列車的警示、速度、設備狀態、距離等關鍵信息以向司機反映當前車載運行控制信息。

首先需要解決腳本語言的問題，在此基礎上確定測試框架方案。目前流行的腳本語言有python、perl、ruby、javaScript、VBScript、tcl等，根據設計單位提供的工程數據表特性，目前流行的python、ruby有豐富的數據庫支持設計單位提供的數據格式的采集、處理、構建和輸出，而且其語言語法簡單易懂，對于構建基于數據驅動、關鍵字驅動的腳本測試案例具有很大的優勢。

本文針對高鐵信號產品提出一種DRT框架模型，驅動(Driver)/資源(Resource)/任務(Task)框架的邏輯結構，如圖3所示。

圖3 DRT框架結構圖示Fig.3 DRT framework

1) 驅動服務提供一切自動化測試需要運行的程序單元，包括基礎數據處理驅動、測試數據生成驅動、測試數據與測試動作結合驅動、腳本生成和運行控制驅動、被測對象與外圍設備的交互信息定制、獲取、驗證驅動等，是本自動化測試框架運行的工作基礎。所有的驅動組件以函數接口的方式進行組織實現，以方便用戶擴展。驅動服務以測試引擎的方式運行，可以采用分布式進行管理。

2) 資源由測試對象、測試數據、測試腳本、運行列表構成。測試對象是識別測試元素的集合，例如臨時限速服務器產品的限速拆分、無線閉塞中心的坡度速度信息生成、聯鎖設備的進路狀態信息輸出等；測試數據是測試腳本運行所使用的數據載體；測試腳本則是測試對象、測試數據按照測試業務流程組合在一起的運行載體。

3) 任務是用于實現一個、一組測試行為的操作集合。例如信息發送、信息獲取、信息匹配、信息驗證、信息響應等。

還有一些輔助性的內容，例如腳本運行結果記錄、統計信息等，也可納入到本模型中。

本模型可以涵蓋目前高鐵信號產品自動化測試的基本需求集，滿足一般性的自動化測試實現。在測試腳本的設計中，可采用數據驅動和關鍵字驅動結合的方式進行，在本文4.1節提供的數據源的基礎上，使用基礎數據驅動和測試數據生成驅動組件構建符合腳本語言使用的數據組織形式，可以是數據庫、excel以及其他富文檔類型的數據組織形式，而要做到真正的數據驅動，必須有控制測試的業務流，由任務列表中的關鍵字驅動結合實現，測試數據和測試操作結合驅動根據任務列表預先設定的任務關鍵字選取相應的流程函數，根據用戶的數據定制需求生成測試案例。測試腳本是最終測試案例執行的“驅動”。

4.3 測試工具

任何自動化測試框架下實現自動化測試，必須對被測對象進行驅動。例如web的自動化測試必須使用驅動瀏覽器的工具庫。因此，高鐵信號各產品的自動化測試需要驅動被測產品與外圍設備的交互，外圍設備模擬即為驅動被測對象的測試工具。

根據DRT模型，測試工具以被驅動的方式接入測試框架，根據高鐵信號產品特點，測試工具與被測設備的交互均在測試框架內以測試驅動服務實現，即測試工具作為代理在驅動服務組件與被測設備之間進行數據交互。由此，與自動化測試相關的功能盡量在測試驅動內實現，測試工具僅適配測試驅動程序按其驅動指令完成與被測設備的數據交互，如圖4所示，實現方案如下。

1) 被測設備與外圍模擬建立內部通信連接，用于測試驅動的接口實現。

2) 測試驅動接口的收發兩個方向，以不同隊列作為數據交互的數據結構。

3) 腳本中的任務流控制測試數據與測試驅動接口的交互。

4) 測試驅動接口與被測設備的數據交互采用觸發方式，有數據則觸發。

5) 在1）中，被測設備與每個外圍設備模擬間維護獨立的驅動接口，即分布式管理。當然，也可以采用輪詢算法進行單線程調度管理。

6) 上述1～4進行分布式處理，其通過2）中的隊列作為進程或線程的通信方式。

圖4 測試工具圖示Fig.4 Block diagram of test tools

測試工具能夠完成測試案例腳本中業務關鍵字指定的數據驅動功能，按其指令完成數據在測試工具與測試驅動組件或被測設備的信息交互。

5 總結

本文針對鐵路信號產品自動化測試現狀進行匯總分析，總結了高鐵信號產品自動化測試發展的問題。在參考和借鑒其他行業自動化測試框架的流行技術的基礎上，針對這些問題提出一種符合高鐵信號產品自動化測試的DRT框架模型，并在此框架下提出一系列具體實現的技術和理念，對高鐵信號產品工程測試的自動化實現提供一種方案參考。

后續在本文的基礎上，針對某一信號產品開發實現一個通用的自動化測試平臺，驗證其可行性并推廣到其他產品，是本方案進一步的展望和規劃。