一種信號設備功能測試系統方案的研究

李啟翮

（北京全路通信信號研究設計院，北京 100073）

1 概述

軌道交通領域作為高安全需求領域，其信號設備（如聯鎖、列控設備等）多為安全苛求設備，這些設備協同工作，共同保證列車安全運行。

為確保設備安全穩定工作，運營之前必須進行全面的測試。針對不同的設備以及測試的不同級別，需要設計并構建不同的測試系統。針對該問題，本文提出一種通用的設備功能自動化測試系統，針對事件驅動類型（如CTCS-2級列控系統的列控中心、CBTC系統的區域控制中心等）或周期處理類型（如計算機聯鎖）的設備，實現系統級別功能測試，只需針對具體的設備進行適配，就能以相同的測試原理測試不同的設備。

測試通常分為多個級別，如單元測試、針對設備各部件的子系統測試、針對單一設備的系統測試、多個系統設備之間的集成測試以及現場測試等。單元測試由開發人員自己完成；子系統測試是保證該部件能與其余部件相配合工作，組成完整的設備；系統測試則是針對單一設備，確保該設備的功能正常，從而為后續集成測試和現場測試中多個設備之間聯調聯試打下基礎。

實際測試中，若缺陷在后面幾級測試才被發現，其解決成本比在前幾級測試中發現的解決成本高得多。統計表明，后一級的測試與前一級的測試相比，發現和修復一個缺陷的平均成本要提高10倍。因此子系統和系統級別的測試，盡量完整覆蓋所需測試的功能，將盡量少的問題遺留到后面的聯調聯試中，從而極大降低故障定位、缺陷修復的成本。

本文所提出的測試系統，主要針對系統測試這一級別。由于子系統測試和系統測試相近，只需將被測的部件看作一個單一設備即可。因此，本測試系統也同樣適用子系統級別的測試。

CTCS-2級列控系統已在提速線路和客運專線上成功運用，是當前主流的列控系統，列控中心（TCC）是其核心控車設備。本文將以TCC為例，對測試系統進行描述。

2 被測對象

系統測試的對象是一個正常運行設備的內部處理功能，以及該設備與其他設備的交互功能。以TCC為例，就是要測試TCC能否與其外接設備正常交互，并根據自身狀態和外部輸入實時做出正確反應。從本質上說，就是在確定設備自身狀態后，對其實施激勵，檢測其反應是否正確。

TCC根據調度命令、進路狀態、線路參數等產生進路以及臨時限速等相關控車信息，通過有源應答器及軌道電路傳送給列車。以既有線車站列控中心為例，在計算機聯鎖車站，他與調度集中（CTC）、計算機聯鎖（CB I）、地面電子單元（LEU）、集中監測（CSM）等設備相連[1][2]，其連接關系如圖1所示。

3 測試方式

對被測對象的測試，采用根據功能場景、需求規范以及接口規范編制測試用例的方式進行。由于測試工作量巨大，人工手動測試難以滿足實際需求，要求進行自動化測試，這就需要根據測試用例編寫測試腳本以實現測試自動化。即先編寫測試規范與用例，再根據用例編寫腳本，在測試系統上運行測試腳本，觀察并分析其運行結果，確認被測功能是否符合需求。

4 測試系統需求

對設備進行系統測試的目的是為了確認該設備是否符合功能需求，是否能夠可靠地與其他設備協同工作，是否具有足夠的魯棒性，為下一級測試交付一個可用的設備。

一個單獨的不與外部通信的設備是無法正常工作的。每一個設備都與不同數量、種類的其他設備相連，而各接口之間的交互功能往往包括多個步驟，許多測試場景還涉及多個接口之間的配合、協調，因此測試步驟比較復雜。以TCC為例，測試系統必須能夠測試TCC與CBI、LEU、CTC、CSM的交互功能。

由于測試的復雜性，純人工手動完成并不現實，因此測試系統應能進行自動化測試。此外，開發過程中，開發者會根據每一輪的測試結果發布新版本，需要對每一個版本進行迭代測試，為節約成本，測試系統應能提供自動化的迭代測試功能。最后，為了方便測試以及節約時間成本，該測試系統應易于構建，方便使用。

5 測試系統

5.1 測試系統原型

一個正常運行的設備需要與其他設備相連接以進行信息交互，而在對其進行較全面的測試之前又不適合與其他真實設備聯調聯試，即便能夠，也無法滿足系統魯棒性測試的要求，因為真實設備難以方便地實現錯誤注入，因此需要采用外連各設備的仿真器來測試其功能。以TCC為例，為構建測試系統，需要開發CTC仿真器（CTCsim）、聯鎖仿真器（CBIsim）、LEU仿真器（LEU sim）、CSM仿真器（CSMsim）等。

為了實現自動化測試，需要將測試用例以某種語言編寫為測試腳本。為了對測試腳本的運行進行管理并記錄測試結果，還需要一個測試管理器（TM）。

根據以上分析，本文提出如圖2所示的測試系統原型。

5.2 仿真器

為簡化開發工作，測試系統采用接口仿真器。接口仿真器只具有與真實設備相同的接口，而不實現內部處理邏輯，所有需要邏輯處理的地方，均由人工編寫命令腳本實現。這類仿真器制作簡單，但如果被測設備與仿真器之間的交互信息無法準確確定時，將增大測試腳本的編寫難度。由于信號設備多為安全苛求系統，當其自身的內部狀態與外部輸入被確定時，該設備的正確反應也隨之確定。因此，接口仿真器完全能夠滿足測試的需要，即使有部分數據不能精確確定，也可以通過計算其取值范圍，并在編制腳本時增加一些處理即可。

每一個接口仿真器應實現與真實設備相同的接口，其中應用數據層、鏈路層、安全層等應與真實接口完全相同，物理層可以通過接口轉換器實現。此外，仿真器還應能根據用戶的指定，實現錯誤注入，以測試被測設備的魯棒性。最后，仿真器的安裝使用應盡量簡單。

以CTCsim為例，仿真器應實現的功能：（1）實現符合規范[3]的接口協議；（2）能接收用戶命令；（3）能根據用戶命令按正確格式發送CTC消息；（4）能根據用戶要求發送有錯誤的消息，以實現錯誤注入；（5）能接收TCC所發送的消息，并將其以一定格式向用戶顯示；（6）能自動對TCC消息進行CRC校驗，如出錯，則向用戶發送提示；（7）能自動向TCC發送打點時鐘消息，且其頻率能由用戶指定；（8）能自動檢測TCC“列控中心狀態消息”的發送頻率，若超出一個可配置的范圍，能提示用戶；（9）能根據用戶命令與TCC建立或斷開通信連接。

根據以上分析可知，CTCsim的功能并不復雜，主要分為與TCC的消息交互和與用戶的消息交互兩個部分。為了單獨使用和便于調試，用戶命令的接收和TCC消息的顯示分別使用操作系統的標準輸入和輸出，如圖3所示。測試人員可以直接輸入命令讓仿真器向TCC發送消息，并根據TCC回應的消息，判斷TCC處理邏輯的正確與否。從便于安裝使用的角度出發，仿真器實現為一個單獨的應用程序使用時直接運行。其他仿真器也以類似方式實現。

由于與被測設備的物理接口多樣化，例如RS-422串行異步接口、以太網接口等，對不同仿真器實現不同的物理層接口增加了復雜度。為能以一致的方式進行仿真器的開發，決定所有仿真器均采用以太網與外部接口，再根據需要使用接口轉換器與之相連，以實現正確的物理層接口。

5.3 測試管理器

TM的基本功能是腳本解析與命令收發。根據輸入測試腳本，TM依次將腳本中的各條命令向該命令所指定的接收對象轉發。收到TM命令的仿真器會據此與被測設備進行相應的信息交互，并將被測設備的回應消息轉發給TM，TM將該消息與測試腳本所規定的應收到的正確消息進行比較，以確定被測設備的功能是否正確；如否，則向測試人員報告錯誤所在。

TM實現為一個單獨的程序，其功能包括：（1）腳本文件的讀入與內容解析；（2）與仿真器建立通信連接；（3）根據腳本向仿真器發送消息；（4）接收仿真器轉發的被測設備的消息或仿真器的提示信息，并與腳本的規定進行比較以判斷正誤；（5）記錄并顯示測試過程和結果。其中(1)和(5)只涉及文件操作和文本處理，(2)、(3)和(4)是核心功能。

考慮到TM要與測試腳本進行交互，采用同一種腳本語言實現TM和測試腳本（如可采用p er l、ruby等腳本語言），更有利于二者的交互。

如前所述，各仿真器以標準輸入、輸出與用戶交互，而自動化測試時則需要與TM交互，這需要增加仿真器與TM間的通信接口。由于腳本語言的性能較低，此外，與TM交互的仿真器的數量、種類會隨被測設備的不同而變化，為了達到模塊化的設計，決定將消息分發功能獨立出來，增加1個消息分發器（MD）。TM僅與MD相交互，由M D完成消息的分發。

為了不增加仿真器的復雜度，充分復用其已有的I/O接口，可利用U n ix系統的基于進程間通信（IPC）的管道I/O重定向功能。具體方法是啟動MD后，首先由MD根據配置文件，通過fork()產生新的進程，以啟動各個仿真器，再針對每一個仿真器創建兩個管道，分別與其標準輸入、輸出相連，從而實現與仿真器的信息交互。針對每個仿真器，M D設定唯一的標識符，該標識符由配置文件指定，由腳本和MD在消息中加上該標識符，就可容易地實現消息分發。由上可知，M D的功能應包括：（1）讀入配置文件，根據指定的配置，管理各仿真器的啟動與關閉；（2）實現消息分發。M D實現也為一個單獨的程序。

以上方案不僅能實現單一用例的自動化測試，再增加對多個測試案例批量處理的功能，就可以進行自動化迭代測試。這只需給TM增加第6個功能：腳本批量處理，即讀取一個腳本文件名列表文件，根據該列表逐條讀取腳本運行，當完成一個腳本運行后，繼續讀入下一個腳本進行測試。

5.4 測試腳本

由于所用仿真器只有接口而沒有內部處理邏輯、線路數據，因此，這部分功能只能由測試腳本承擔。將測試用例場景，轉化為一個動作執行序列，按步驟將每一步應發送給TCC的消息以及應從TCC接收到的消息以一定格式編寫到一個文件里，由TM讀入并順序執行，該文件即測試腳本。

腳本編寫應簡單明確，既適合測試人員編寫、閱讀，又便于TM進行解析，最終確定以rub y語言[4]編寫，同時TM本身也以rub y編寫實現，有利于二者交互。下面是一個簡單的腳本示例。

ctcSim=ni l

ctcSim=CTC.new(name)

ctcSim.sendConnect()

ctcSim.waitConnected(expire_time)

ctcSim.sendTSRStatusReq()

ctcSim.waitAck(expire_time)

c t c Sim.wa i t TSRSt a t us(seqno,bmai n,cmd n o,t ime1,t ime2,s t a r t,e n d,t s r,lef t,whole,expire_time)

這是一個CTC sim與TCC交互的例子。首先建立仿真器實例，該函數會設置一些默認的初始化參數，如該仿真器的名字、系統時間等，然后與TCC相連接，隨即發送狀態請求消息并等待回應。示例中CTC為事先封裝好的公共類，sendConnect()等均為已經編制好的類方法，可供任意腳本調用。函數括號內斜體所示為參數，實際腳本中應以正確的數據替換，如w aitTSRStatus()的參數分別為幀序號、主備機標志、限速命令號等消息數據，用于和所收到的消息比對以確定消息是否正確，參數expire_time是消息等待時間，如該時間內未收到消息，則報錯。這樣編寫的腳本所反映的場景流程更加清晰，不會被處理細節所干擾。

5.5 測試系統

根據前面的分析，最終測試系統構成如圖4所示。

由于M D使用了U n ix類系統IPC功能，從經濟適用的角度出發，測試平臺采用1臺安裝了Linux操作系統的電腦，TM、MD與各仿真器均安裝于該電腦上，通過以太網與接口轉換模塊相連，再連接至被測對象。

針對不同的被測設備，只需以相同的原理開發所需的仿真器并修改配置文件。TM和M D均為通用產品，毋需修改即可使用。這樣就能以相同的構架、方案測試不同設備。例如要測試區域控制中心（ZCC），只需開發A TS、車載、聯鎖以及相鄰ZCC的仿真器接入測試系統即可。

使用時先啟動TM，指定測試腳本以及數據配置文件。TM首先啟動M D，由M D根據數據配置文件啟動各仿真器與被測對象相連，TM讀入腳本后，根據腳本與M D交互，完成整個測試用例的運行，記錄測試過程和結果。

6 結論

本文提出一個通用的自動化測試系統方案，采用本方案，能以相同的原理實現對各種事件驅動式和周期處理式設備的系統級測試，并能實現自動迭代測試。該方案不僅可用于系統測試，如果將設備內部的某一部件看作一個獨立設備，與之相連的其余各部件看作外接設備，則該系統也可以用于子系統級測試。

[1]科技運[2007]44號 既有線CTCS-2級列控系統車站列控中心技術規范（暫行）[S]．2007.

[2]徐嘯明．CTCS-2級列車運行控制系統應用叢書—列控地面設備[M]．北京:中國鐵道出版社，2007.

[3]科技運[2006]93號 既有線提速CTCS-2區段車站列控中心接口協議（v1.0）[S]. 2006.

[4] Thomas，D．Fowler，C．Hunt，A．Programming Ruby [M]，USA，Progmatic Bookshelf, 2004.