宋西欣,郁文斌
(北京全路通信信號研究設(shè)計院集團(tuán)有限公司,北京 100070)
近年來,國內(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)意義。
自動化測試是每一個測試項目的終極目標(biāo)。對于自動化測試,雖然各行業(yè)不同,但具有通用的理念、理論及技術(shù)應(yīng)用。
國內(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ù)。
行業(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ì)量。
高鐵信號領(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)行闡述。
無論選擇哪種測試框架,最終的測試都需要落實到案例的執(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)解決。
雖然上文提到一些測試框架及工具,根據(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)讓。
通過詳細(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ā)展安全可靠性的保障。
依據(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)入時用于解決遇到的各種問題。
前面已經(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ū)動”。
任何自動化測試框架下實現(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è)備的信息交互。
本文針對鐵路信號產(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ī)劃。