一種ATS 系統(tǒng)自動化測試工具的設(shè)計與實現(xiàn)

陳慧琍 陳曉軒

列車自動監(jiān)控系統(tǒng)（ATS） 是列車自動控制系統(tǒng)的一個重要組成部分，針對ATS 系統(tǒng)的測試是保障列車安全運(yùn)行的前提。傳統(tǒng)ATS 系統(tǒng)的測試邏輯復(fù)雜、界面操作繁瑣，從制定計劃、編寫案例，到執(zhí)行測試、記錄結(jié)果，需要大量重復(fù)的或相似的操作，極大地增加了測試時間和人力成本。為了推動ATS 系統(tǒng)自動化測試進(jìn)程，急需一套切實可靠的ATS 系統(tǒng)自動化測試工具。

1 測試要求

ATS 系統(tǒng)的自動化測試，要求測試前后結(jié)果相關(guān)聯(lián)、測試需求多樣和實時性高，具體要求如下。

1）與真實測試無偏差，需正確解讀ATS 系統(tǒng)的測試邏輯，使測試流程嚴(yán)格匹配。

2）采用模塊化設(shè)計，可以根據(jù)測試需求靈活組合。

3）具有魯棒性和普適性，對不同ATS 系統(tǒng)均可進(jìn)行自動化測試。

4） 需提供ATS 系統(tǒng)測試的日志和可視化結(jié)果，便于測試人員核查。

對于以界面操作為主的軟件，按測試機(jī)制可分為侵入式測試和非侵入式測試。侵入式測試，需要修改測試目標(biāo)軟件的內(nèi)部代碼，或者控制其運(yùn)行環(huán)境；而非侵入式測試，則不修改軟件內(nèi)部代碼，只是監(jiān)控測試目標(biāo)軟件的用戶界面，模擬測試人員完成測試流程。由于ATS 系統(tǒng)涉及列車控制系統(tǒng)數(shù)據(jù)，不能修改其內(nèi)部代碼，所以ATS 系統(tǒng)自動化測試工具只能采用非侵入方式。

2 模塊設(shè)計

為了實現(xiàn)地鐵信號系統(tǒng)自動測試，設(shè)計了圖像數(shù)據(jù)采集、OCR 圖像處理、測試腳本配置、客戶端內(nèi)網(wǎng)間通信、日志處理、測試結(jié)果可視化等6 個模塊。

2.1 圖像數(shù)據(jù)采集模塊

圖像數(shù)據(jù)采集模塊，實時監(jiān)控ATS 系統(tǒng)測試軟件界面，需要采集信息時截取界面圖像。根據(jù)實際的測試流程編寫測試腳本，需要提取信息時，例如識別字符或判斷路段形態(tài)，該模塊會采集地鐵信號系統(tǒng)測試軟件圖形化界面中的界面信息；也可以通過按鍵的中斷方式，實時截取界面圖像，作為測試樣例和構(gòu)造字符特征庫。

2.2 OCR 圖像處理模塊

OCR（光學(xué)字符識別）圖像處理模塊，識別和處理地鐵信號測試系統(tǒng)軟件中的屏幕信息，主要有界面中的菜單信息、站場圖中的字符信息和路段形態(tài)信息。

界面中的菜單信息，是指需要點(diǎn)選菜單才能進(jìn)行的操作，比如建立進(jìn)路、取消進(jìn)路和解除引導(dǎo)總鎖等命令，都需要通過識別菜單中的文字，找到相應(yīng)的指令后執(zhí)行操作。

站場圖中的字符信息，是指在站場圖上顯示的道岔號、軌道區(qū)段編號、信號機(jī)編號等文字信息。

以上兩類信息，對于人類來說非常好理解，但是對于計算機(jī)來說，完全是兩類不同的信息。菜單信息的底紋大多為灰色，字體字號較為統(tǒng)一；站場圖中的字符信息底紋顏色是可以自定義的，黑色、灰色都可以，字體、字號也是可以改變和縮放的。這些不同是需要重點(diǎn)解決的技術(shù)問題。

為了識別并處理菜單信息和站場圖中的字符信息，本文采用先定位、再識別的策略，即先定位文字位置，提取字符識別候選值，再對候選值進(jìn)行字符識別，最終整合信息輸出識別結(jié)果。

在定位待識別文字時，采用一種基于Gabor 和SVM 的復(fù)雜背景中的文字檢測方式。通過不同方向尺度的Gabor 濾波器得到表示中文字符橫、豎、撇、捺4 個方向的紋理圖像；使用SVM 分類器對紋理圖像進(jìn)行訓(xùn)練，構(gòu)建一個SVM 分類網(wǎng)絡(luò)來得到最終的文字區(qū)域。對字符定位時的具體操作是：先對圖像以灰度均值為閾值做二值化操作（將整個圖像呈現(xiàn)出明顯的黑白效果），再使圖像通過4 種針對橫、豎、撇、捺紋理提取特征的Gabor 濾波器，最后使用SVM 分類器對提取出的候選文本區(qū)域進(jìn)行細(xì)分類，得到準(zhǔn)確的文本位置。

在對候選值進(jìn)行字符識別時，首先對候選值使用垂直投影法，對二值化操作后的圖像垂直方向的黑色像素點(diǎn)進(jìn)行統(tǒng)計，低于閾值處判斷為字符分割點(diǎn)，將字符識別候選值分割后獲得單獨(dú)的字符圖。對單獨(dú)的字符圖，參考一種基于聯(lián)合HOG 特征的車牌識別算法，分別提取漢字、數(shù)字字母的灰度方向梯度直方圖（histogram of oriented gradients，HOG） 特征、二值灰度方向梯度直方圖特征和16 值（用最基本的16 種顏色顯示圖像）灰度方向梯度直方圖特征，將它們組合成聯(lián)合HOG 特征。聯(lián)合HOG 特征是三維數(shù)據(jù)集，在計算機(jī)中不僅占用很大的存儲空間，而且處理起來很復(fù)雜。核主成分分析方法（kernel principal com?ponent analysis，kernel PCA） 是多變量統(tǒng)計領(lǐng)域中的一種分析方法，能把高維數(shù)據(jù)x 投射到k 個特征向量上，從而把它降低到k 維。運(yùn)用這種方法把聯(lián)合HOG 特征進(jìn)行降維，將降維后的聯(lián)合HOG 特征送入支持向量機(jī)進(jìn)行訓(xùn)練和預(yù)測，將漢字和數(shù)字字母的識別結(jié)果進(jìn)行組合，得到最終的字符識別結(jié)果。

路段形態(tài)信息，是指站場圖中的軌道區(qū)段、道岔區(qū)段和列車按鈕等圖形。對路段形態(tài)信息進(jìn)行識別時，首先對圖像以灰度均值為閾值做二值化操作，通過調(diào)用opencv 的方法對圖像中的圓形和直線段做擬合，可分別得到站點(diǎn)位置和路段位置的參考信息。通過對兩路段做角度計算，可以推斷出岔道信息。針對不同任務(wù)，對界面中的圖像進(jìn)行矩形或者圓形擬合，能夠找出軌道區(qū)段或信號燈，再判斷其顏色的變化，可以對特定組件進(jìn)行識別，進(jìn)而滿足不同的測試需求。

2.3 測試腳本配置模塊

測試腳本配置模塊，是測試人員預(yù)先根據(jù)測試需求，按照預(yù)定義的格式編寫測試腳本的模塊。實際測試時，模塊中的腳本解釋器會讀取測試腳本文件，解析并執(zhí)行腳本內(nèi)容，并將各個功能模塊按照測試腳本的要求串聯(lián)成測試流程，模擬測試人員實操測試，并記錄日志，供人工分析問題和后續(xù)日志處理模塊處理使用。測試腳本配置模塊工作流程見圖1。

圖1 測試腳本配置模塊工作流程

測試人員根據(jù)不同的測試需求，通過配置函數(shù)級的子模塊組合成不同的測試流程；可以選擇預(yù)定義的子任務(wù)，例如Menu OCR （菜單識別）、Route Check（進(jìn)路檢測）等指令，直接實現(xiàn)單個測試流程；也可以選擇子函數(shù)模塊，例如Move Mouse（移動鼠標(biāo)）、Save Window（保存窗口）、Left Click（左鍵單擊）、Wait（等待）等指令，模擬實際測試流程，并可以自定義新的復(fù)雜的測試場景，編寫測試腳本進(jìn)行自動化測試。

由于地鐵信號測試具有要點(diǎn)多、邏輯復(fù)雜、流程不一致等因素，測試需求變動較大，該模塊可以按不同需求進(jìn)行測試，大大縮短了重復(fù)開發(fā)時間，也給測試人員提供了一定的自由度。

2.4 客戶端內(nèi)網(wǎng)間通信模塊

客戶端內(nèi)網(wǎng)間通信模塊由主控模塊和被控模塊組成，分別布置在中心、車站和車站聯(lián)鎖的控顯機(jī)中，可實現(xiàn)中心和車站控顯機(jī)的協(xié)同操作，模擬傳統(tǒng)測試中人工比對多機(jī)信息的測試流程，解決ATS 系統(tǒng)測試中多機(jī)聯(lián)調(diào)的任務(wù)?？蛻舳藘?nèi)網(wǎng)間通信流程見圖2。

首先，主控模塊與被控模塊建立TCP 連接。在測試過程中，主控模塊將測試需求內(nèi)容以約定的編碼形式編寫成協(xié)議內(nèi)容，并向被控模塊發(fā)送TCP 協(xié)議包；被控模塊監(jiān)聽TCP 協(xié)議包，接受TCP 協(xié)議包后，根據(jù)約定的解碼形式解析協(xié)議并做出相應(yīng)動作。

圖2 客戶端內(nèi)網(wǎng)間通信流程

以多進(jìn)路連排的具體需求為例，被控模塊操控車站控顯機(jī)，使路段進(jìn)入占用模式；主控模塊在中心控顯機(jī)核對占用情況后，命令被控模塊在車站控顯機(jī)模擬占用路段出清；被控模塊完成模擬后，主控模塊收到被控模塊反饋的車站狀態(tài)變化信息，比對在界面中顯示的車站控顯機(jī)、中心控顯機(jī)兩端的占用/出清狀態(tài)記錄是否與預(yù)期一致。

測試車站排路、區(qū)段占用和出清狀態(tài)，以及其在中心顯示的狀態(tài)，是出廠驗收測試中ATS 與聯(lián)鎖之間最重要的測試環(huán)節(jié)。在這個過程中，客戶端內(nèi)網(wǎng)間通信模塊使用了多種輔助方式，包括編寫多個控制軟件、接口遠(yuǎn)程調(diào)用；定義幾種接口遠(yuǎn)程調(diào)用的協(xié)議方式，所有接口調(diào)用使用TCP 方式，約定雙方每2s 發(fā)送一次含有時間戳消息的心跳消息，用于校對主控端與被控端時間是否一致，保證操作上沒有時差，避免因為2 個機(jī)器的時差導(dǎo)致誤判操作而超時。加入心跳包后，能夠有效地避免因為網(wǎng)絡(luò)中斷導(dǎo)致測試失敗而給出誤報警。傳送車站的操作記錄到主控端作為比對依據(jù)，實時在線檢測中心控顯機(jī)的界面顯示是否正常，界面顯示延時是否在可以接受的范圍內(nèi)。

2.5 日志處理模塊

日志處理模塊主要解析測試結(jié)果，與測試用例的預(yù)期結(jié)果進(jìn)行比對，生成測試結(jié)果可視化模塊的輸入，以供展示。

日志主要記錄當(dāng)前時間、操作日志、運(yùn)行輸出日志，以及聯(lián)鎖和ATS 的碼位變化表，檢查碼位表是否按照操作日志中記錄的步驟進(jìn)行變化，與預(yù)期的結(jié)果是否一致，有沒有超時等情況發(fā)生。在地鐵信號系統(tǒng)測試過程中，經(jīng)常采用這種方法，將自然語言描述的測試預(yù)期結(jié)果，人工編寫成比對腳本，對測試日志進(jìn)行判斷處理，可以得出最終的測試結(jié)果是否通過，并且輸出異常情況，待測試人員核查。

2.6 測試結(jié)果可視化模塊

測試結(jié)果可視化模塊用于對測試用例的輸出結(jié)果進(jìn)行可視化，便于測試人員復(fù)查。在綜合OCR圖像處理模塊、日志處理模塊等多個模塊輸出后，測試結(jié)果可視化模塊統(tǒng)計測試結(jié)果，并將統(tǒng)計結(jié)果可視化輸出，輸出文件包括站點(diǎn)狀態(tài)、逐條測試結(jié)果成功率、測試異常點(diǎn)等重要信息，提供給測試人員作為核查的依據(jù)。

3 工作流程

ATS系統(tǒng)自動化測試工具的工作流程見圖3。

圖3 ATS 系統(tǒng)自動化測試工具工作流程

1） 啟動ATS 系統(tǒng)和工具后，調(diào)用Windows API 操作，模擬人工測試中的鍵盤和鼠標(biāo)操作。

2）圖像數(shù)據(jù)采集模塊，依據(jù)測試用例中給定的信息，在界面中定位站點(diǎn)、股道、道岔和操作按鈕等信息，使用Windows 的API 進(jìn)行截圖操作，將結(jié)果傳給OCR 圖像處理模塊。

3）OCR 圖像處理模塊，對圖片進(jìn)行預(yù)處理，定位并識別圖片中的被測對象，判斷圖片中被測對象的狀態(tài)和編號；采用不同的圖像處理策略，經(jīng)過圖片預(yù)處理、中英文字符檢測識別、軌道岔路形態(tài)識別等流程后，將當(dāng)前任務(wù)中需要的圖像信息在整張圖中定位并記錄，構(gòu)建帶有信息位置坐標(biāo)的整體測試圖像。

4）測試腳本配置模塊讀取并解析任務(wù)，獲得設(shè)定好的狀態(tài)機(jī)模型信息；根據(jù)OCR 圖像處理模塊給出的顯示界面狀態(tài)，判斷狀態(tài)機(jī)的運(yùn)行情況；發(fā)送控制命令給客戶端內(nèi)網(wǎng)間通信模塊，實現(xiàn)多站聯(lián)調(diào)測試；最后將狀態(tài)機(jī)的處理結(jié)果傳給日志處理模塊。

5）客戶端內(nèi)網(wǎng)間通信模塊，根據(jù)測試腳本配置模塊的控制命令來操作車站控顯機(jī)，配合中心控顯機(jī)的操作，并將驗證后的車站聯(lián)鎖控顯機(jī)碼位信息反饋給中心控顯機(jī)。

6）日志處理模塊，將收到的結(jié)果匯總后與測試用例的預(yù)期結(jié)果進(jìn)行比對，判別當(dāng)前測試任務(wù)是否成功。

7）測試結(jié)果可視化模塊，根據(jù)日志處理模塊的判別結(jié)果，整合多次測試的結(jié)果，輸出可視化的測試日志，供測試人員查看。

4 關(guān)鍵技術(shù)

狀態(tài)機(jī)建模和驗證是ATS 系統(tǒng)自動化測試工具的關(guān)鍵技術(shù)，將ATS 系統(tǒng)中的操作信息作為狀態(tài)機(jī)的狀態(tài)并建立模型，系統(tǒng)對操作的響應(yīng)和反饋作為狀態(tài)轉(zhuǎn)變的條件，配合OCR 技術(shù)從屏幕獲得信息后，通過狀態(tài)機(jī)的狀態(tài)變化、前后的邏輯關(guān)系，對測試結(jié)果進(jìn)行判斷。以實際道岔測試邏輯作為狀態(tài)機(jī)舉例，狀態(tài)機(jī)的驗證方式見圖4。

首先，圖像數(shù)據(jù)采集模塊采集道岔操作前后的界面截圖；然后，OCR 圖像處理模塊對圖像進(jìn)行去噪、定位字符候選區(qū)域、對候選區(qū)域分割、識別單個字符、判斷目標(biāo)道岔位置、道岔特征提取和判斷等圖像處理，判斷道岔前后形態(tài)的變化，由此得到測試界面在狀態(tài)機(jī)中的當(dāng)前狀態(tài)，對道岔形態(tài)進(jìn)行判斷。若道岔形態(tài)為不水平，則驗證道岔的狀態(tài)；如果道岔狀態(tài)符合預(yù)期，則驗證經(jīng)過軌道路線；否則該條測試失敗。若道岔為水平，則驗證軌道路線；如果經(jīng)過的軌道路線符合預(yù)期，則該條測試成功，否則該條測試失敗。

可以看出，OCR 圖像處理模塊識別道岔形態(tài)而得到差值圖等動作是狀態(tài)機(jī)建模和驗證中的關(guān)鍵步驟，OCR 不僅要在ATS 界面中找到被測對象，而且要識別操作結(jié)果，才能夠判斷狀態(tài)機(jī)的狀態(tài)并記錄測試結(jié)果。狀態(tài)機(jī)的判斷結(jié)果均通過日志處理模塊記錄，傳送給可視化模塊進(jìn)行結(jié)果整合以及可視化輸出。

圖4 狀態(tài)機(jī)的驗證方式示意圖

狀態(tài)機(jī)建模與驗證技術(shù)，并不局限于ATS 的操作邏輯，只要能夠建立操作邏輯的狀態(tài)機(jī)，結(jié)合OCR 識別技術(shù)，就可以不依賴被測對象的控顯接口，直接獲得界面狀態(tài)，實現(xiàn)這些具有控顯界面的信號系統(tǒng)的自動化測試。

5 應(yīng)用效果

目前，ATS 系統(tǒng)自動化測試工具已在多個城市、多條地鐵線路上進(jìn)行了應(yīng)用，相比傳統(tǒng)的人工測試，測試過程極大簡化，測試時間大大縮短，主要應(yīng)用效果如下。

1） 利 用Windows 的API 和OCR 等 技 術(shù)，模擬測試人員的操作，在未影響系統(tǒng)性能的前提下，實現(xiàn)了界面測試自動化。

2）客戶端內(nèi)網(wǎng)間通信模塊實現(xiàn)了多機(jī)聯(lián)合測試功能，能夠同時操作3 個車站，測試車站間的接口，并模擬車輛折返和接發(fā)車等場景。

3）不依賴于被測對象界面顯示接口，降低了被測對象的依賴度。國內(nèi)大部分ATS 系統(tǒng)采用微軟的Visual Studio 技術(shù)開發(fā)，但為了安全起見，操作界面都去除了微軟的消息響應(yīng)接口，使得界面操作只能依靠鼠標(biāo)等輸入設(shè)備。采用OCR 技術(shù)后，結(jié)合輸入設(shè)備的控制功能，可不依賴被測對象就能夠獲得其界面變化。

4）實現(xiàn)了測試配置靈活可變，不依賴于測試人員的開發(fā)技術(shù)，降低了人員要求，減少了培訓(xùn)和測試成本。

ATS 系統(tǒng)自動化測試工具，節(jié)約了ATS 系統(tǒng)測試的人力資源和時間資源，簡化了測試流程制定、測試人員培養(yǎng)、測試結(jié)果核對的流程，為現(xiàn)階段城市軌道交通快速發(fā)展提供了幫助。