宋西欣，郁文斌

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

1 概述

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

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

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

2 自動化測試

自動化測試是每一個測試項目的終極目標(biāo)。對于自動化測試，雖然各行業(yè)不同，但具有通用的理念、理論及技術(shù)應(yīng)用。

2.1 業(yè)內(nèi)情況

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

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

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

2.2 業(yè)外情況

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

自動化測試的優(yōu)勢，筆者認(rèn)同文獻(xiàn)[7-8]的觀點，這些優(yōu)點同時也適用于鐵路信號領(lǐng)域：

1) 節(jié)省測試時間、進(jìn)行全面的回歸測試；

2) 增強(qiáng)對于系統(tǒng)質(zhì)量的信心，其又可以反饋到對系統(tǒng)的改進(jìn)；

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

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

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

6) 自動化幾乎是測試活動的終極形式：當(dāng)某一類測試內(nèi)容已經(jīng)被研究透徹，形成了一定的規(guī)律和模式，那就可以進(jìn)一步實現(xiàn)自動化測試。因而自動化也是團(tuán)隊技術(shù)進(jìn)步的標(biāo)志之一。

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

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

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

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

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

3 面臨問題

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

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

1) 測試數(shù)據(jù)源處理；

2) 測試框架方案選擇與構(gòu)建；

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

因此高鐵信號產(chǎn)品的自動化測試的實現(xiàn)主要圍繞上述問題解決進(jìn)行闡述。

3.1 測試數(shù)據(jù)源處理

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

1) 腳本驅(qū)動的數(shù)據(jù)源構(gòu)建；

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

2) 腳本結(jié)果匹配的期待數(shù)據(jù)構(gòu)建。

高鐵信號產(chǎn)品的自動化測試首先需要解決數(shù)據(jù)源的標(biāo)準(zhǔn)化。自2018年起，行業(yè)內(nèi)開始推進(jìn)鐵路信號工程領(lǐng)域工程數(shù)據(jù)表的標(biāo)準(zhǔn)化工作[9]，并對各產(chǎn)品間接口數(shù)據(jù)表進(jìn)行規(guī)范，解決由于接口數(shù)據(jù)表描述不統(tǒng)一導(dǎo)致的信號軟件接口兼容性問題。由此，數(shù)據(jù)源標(biāo)準(zhǔn)化前進(jìn)了一大步，但是仍舊遺留諸多問題：

1) 雖然標(biāo)準(zhǔn)化了工程數(shù)據(jù)表格模板，但是模板內(nèi)部的關(guān)鍵字未明確規(guī)定；

2) 接口表內(nèi)部的關(guān)鍵字雖然規(guī)范化，但是設(shè)備商根據(jù)自身信號產(chǎn)品的實現(xiàn)方式，需要二次加工的信息由于各設(shè)備廠商產(chǎn)品的差異性無法完成統(tǒng)一規(guī)范化；

3) 高鐵線路的頻繁變更、改造導(dǎo)致的樞紐站的數(shù)據(jù)變更無法標(biāo)準(zhǔn)化；

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

3.2 測試框架方案

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

自動化測試框架是骨架結(jié)構(gòu)，支撐自動化測試的執(zhí)行環(huán)境的構(gòu)建，其包含數(shù)據(jù)集合方式、流程、腳本編碼標(biāo)準(zhǔn)、概念、項目層次化、實現(xiàn)。一旦確定了框架，則自動化測試奠定了構(gòu)建的基礎(chǔ)，如圖 2所示。

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

目前流行的測試框架基本是針對測試腳本語言實現(xiàn)方式進(jìn)行分類：

2) 函數(shù)型、單領(lǐng)域語言型、多領(lǐng)域語言型、富文檔型。

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

構(gòu)建了測試框架，自動化測試的開發(fā)即可展開，針對高鐵信號產(chǎn)品，自動化測試開發(fā)主要集中在：

1) 測試數(shù)據(jù)的采集及處理；

2) 腳本的數(shù)據(jù)驅(qū)動處理；

3) 腳本以操作命令模式、業(yè)務(wù)場景模式的關(guān)鍵字驅(qū)動；

4) 測試數(shù)據(jù)驅(qū)動的信息在被測設(shè)備與外部接口模擬設(shè)備的交互；

5) 測試數(shù)據(jù)驅(qū)動的信息在測試驅(qū)動組件與外部接口模擬設(shè)備的交互；

6) 測試案例預(yù)期結(jié)果數(shù)據(jù)的計算；

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

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

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

3.3 測試工具

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

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

信號設(shè)備的測試工具開發(fā)主要集中在：

1) 數(shù)據(jù)驅(qū)動后的信息處理；

2) 以關(guān)鍵字驅(qū)動的業(yè)務(wù)場景操作處理；

3) 信息按驅(qū)動執(zhí)行與被測設(shè)備的交互功能；

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

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

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

1) 工具部署異構(gòu)，接口較多；

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

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

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

5) 未開源且技術(shù)未轉(zhuǎn)讓。

4 解決方案

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

4.1 測試數(shù)據(jù)源處理

依據(jù)本文3.1節(jié)提出的問題，首先需要從數(shù)據(jù)源上進(jìn)行分析。當(dāng)前各設(shè)備供應(yīng)商地面信號設(shè)備的處理方式均為數(shù)據(jù)導(dǎo)入后進(jìn)行內(nèi)部標(biāo)準(zhǔn)化，以提供給用戶統(tǒng)一的數(shù)據(jù)提取接口。其使用的常見技術(shù)為數(shù)據(jù)庫技術(shù)，即從數(shù)據(jù)源直接到數(shù)據(jù)庫的處理方式。為了解決3.1節(jié)的問題，可以采用中間適配技術(shù)，在數(shù)據(jù)源和目標(biāo)之間實現(xiàn)一層適配，適配的技術(shù)可以引進(jìn)目前流行的技術(shù)：

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

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

4.2 測試框架

前面已經(jīng)提到，沒有流行的測試框架是針對高鐵信號領(lǐng)域提出的，也沒有測試框架可以直接應(yīng)用于高鐵信號產(chǎn)品設(shè)備的自動化測試框架構(gòu)建。

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

1) 具有勘查設(shè)計屬性，例如地面設(shè)備線路數(shù)據(jù)的里程標(biāo)系、坡度、速度勘查數(shù)據(jù)；

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

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

4) 具有接口信息屬性，例如聯(lián)鎖設(shè)備的進(jìn)路狀態(tài)信息、信號開放信息；

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

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

本文針對高鐵信號產(chǎn)品提出一種DRT框架模型，驅(qū)動(Driver)/資源(Resource)/任務(wù)(Task)框架的邏輯結(jié)構(gòu)，如圖3所示。

圖3 DRT框架結(jié)構(gòu)圖示Fig.3 DRT framework

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

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

3) 任務(wù)是用于實現(xiàn)一個、一組測試行為的操作集合。例如信息發(fā)送、信息獲取、信息匹配、信息驗證、信息響應(yīng)等。

還有一些輔助性的內(nèi)容，例如腳本運行結(jié)果記錄、統(tǒng)計信息等，也可納入到本模型中。

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

4.3 測試工具

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

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

1) 被測設(shè)備與外圍模擬建立內(nèi)部通信連接，用于測試驅(qū)動的接口實現(xiàn)。

2) 測試驅(qū)動接口的收發(fā)兩個方向，以不同隊列作為數(shù)據(jù)交互的數(shù)據(jù)結(jié)構(gòu)。

3) 腳本中的任務(wù)流控制測試數(shù)據(jù)與測試驅(qū)動接口的交互。

4) 測試驅(qū)動接口與被測設(shè)備的數(shù)據(jù)交互采用觸發(fā)方式，有數(shù)據(jù)則觸發(fā)。

5) 在1）中，被測設(shè)備與每個外圍設(shè)備模擬間維護(hù)獨立的驅(qū)動接口，即分布式管理。當(dāng)然，也可以采用輪詢算法進(jìn)行單線程調(diào)度管理。

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

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

測試工具能夠完成測試案例腳本中業(yè)務(wù)關(guān)鍵字指定的數(shù)據(jù)驅(qū)動功能，按其指令完成數(shù)據(jù)在測試工具與測試驅(qū)動組件或被測設(shè)備的信息交互。

5 總結(jié)

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

后續(xù)在本文的基礎(chǔ)上，針對某一信號產(chǎn)品開發(fā)實現(xiàn)一個通用的自動化測試平臺，驗證其可行性并推廣到其他產(chǎn)品，是本方案進(jìn)一步的展望和規(guī)劃。