蔣倩　岳龍　李書杰

摘要：針對ATS系統(tǒng)在工程化應用測試過程中大批量回歸測試耗時耗力的問題，構建了一個自動化測試平臺。該平臺的核心模塊仿真管理器提供測試腳本編寫、構造測試環(huán)境、自動加載被測對象、自動執(zhí)行測試等功能。在結合ATS系統(tǒng)功能及內部接口特征人工完成測試腳本的基礎上，可重復進行大批量回歸測試。本文以ATS應用服務器子系統(tǒng)為例，展示了如何在該平臺上實現(xiàn)自動化測試，并總結了每輪回歸試驗的測試用時和人力資源消耗情況。試驗結果表明該自動化測試平臺幫助測試人員提高測試效率，幫助研發(fā)人員進行缺陷預防，以減少系統(tǒng)開發(fā)成本、縮短系統(tǒng)開發(fā)周期，為系統(tǒng)持續(xù)集成提供可能性。

關鍵詞：自動化測試;缺陷預防;ATS系統(tǒng)

中圖分類號：TP24 文獻標識碼：A 文章編號：1007-9416（2019）05-0160-03

0 引言

ATS系統(tǒng)（列車自動監(jiān)控系統(tǒng)）廣泛應用于城市軌道交通信號控制領域，它與ATP系統(tǒng)（列車自動防護系統(tǒng)）、ATO系統(tǒng)（列車自動駕駛系統(tǒng)）合稱ATC系統(tǒng)（列車自動運行控制系統(tǒng)），共同完成高密度城市軌道交通安全高效運輸作業(yè)。ATS系統(tǒng)主要提供列車運行監(jiān)督和控制的自動化行車調度指揮功能[1]，對保障軌道交通線路運營高效率和高質量具有重要意義。

目前，湖南中車時代通信信號有限公司的ATS系統(tǒng)已投入長沙地鐵3號線，長沙地鐵4號線的工程應用，在項目后期系統(tǒng)已趨于成熟，功能需求不會發(fā)生重大變更。當系統(tǒng)發(fā)生輕微變更時，除對變更點及其影響范圍進行測試外，為防止變更影響范圍識別不充分會期望對整個系統(tǒng)進行全面的回歸測試。然而該階段工期緊、任務重，這就對測試效率及測試資源提出更高要求。為解決這一困難，提出用自動化測試方法代替一部分人工手動的測試方法來提高測試效率，解放生產力。

現(xiàn)有的軟件自動化測試工具種類繁多，例STAF，LR（Load Runner）和QTP（QuickTest Professional）等，但是對于軌道交通信號系統(tǒng)領域，商業(yè)的自動化測試工具都存在一定的不足，例如，無法滿足實時性要求，無法支持專用協(xié)議，傾向于單一類型測試[2][3][4]。本文根據(jù)ATS子系統(tǒng)測試方法，設計出一套通用ATS系統(tǒng)自動化測試平臺。

1 ATS自動化測試平臺設計

ATS系統(tǒng)自動化測試平臺采用黑盒測試的方式，只調用被測子系統(tǒng)的接口來測試程序的功能。測試平臺的結構如圖1所示，由被測對象、子系統(tǒng)模擬器和仿真管理器組成。測試平臺采用VisualC++軟件開發(fā)。

1.1 仿真管理器

仿真管理器主要提供配置測試環(huán)境、編譯測試腳本、加載測試計劃、執(zhí)行測試腳本、生成測試報告等功能。人機界面如圖2所示。

1.1.1 測試腳本編譯模塊

腳本的編輯環(huán)境和執(zhí)行模塊。測試人員根據(jù)測試用例人工在仿真管理器上手動編寫測試腳本，將測試用例轉化為測試腳本語言。該模塊支持測試腳本的增加、刪除、重命名、編寫、保存、關鍵字查找功能。測試腳本可采用JS和VBS兩種格式來儲存，需要構造發(fā)送的消息和期望接收的消息。該模塊在執(zhí)行測試腳本的過程中記錄并顯示發(fā)送和接收的消息，根據(jù)測試腳本中的預期結果進行比較和判斷，輸出測試結果，更新腳本執(zhí)行狀態(tài)。

1.1.2 消息發(fā)送模塊

消息發(fā)送處理模塊根據(jù)測試腳本中設置的輸出消息的目的地隊列和類型，向目標隊列中發(fā)送構造好的數(shù)據(jù)，可支持批量發(fā)送消息。

1.1.3 消息接收模塊

消息接收處理模塊根據(jù)測試腳本中設置的輸入消息的源隊列和類型，當監(jiān)聽到消息隊列中接收到期望的消息類型時，觸發(fā)消息處理函數(shù)對消息進行反解。該模塊能同時處理多個消息源發(fā)送來的多包消息。

1.1.4 生成測試報告模塊

每次測試計劃的腳本全部執(zhí)行完畢都會自動生成本次測試的測試報告，記錄和存儲每個測試用例的編號，測試執(zhí)行的開始時間結束時間，測試結果，測試日志以及測試過程中出現(xiàn)的異常。報告采用excel格式統(tǒng)一模板輸出，以供測試人員再次編輯。

1.2 子系統(tǒng)模擬器

由于ATS系統(tǒng)是一個基于網(wǎng)絡通信的分布式系統(tǒng)，針對某個子系統(tǒng)的測試往往需要其他多個子系統(tǒng)同時配合參與，因此，設計了子系統(tǒng)模擬器來構造外部測試環(huán)境。子系統(tǒng)模擬器類似于消息路由器，作為仿真管理器和被測子系統(tǒng)的通信橋梁，可自定義消息路由規(guī)則和消息收發(fā)隊列。子系統(tǒng)模擬器是個只讀對話框，只顯示收發(fā)的消息信息不可編輯。

1.3 被測子系統(tǒng)

在該自動化測試平臺中，被測對象可以是ATS系統(tǒng)中某一子系統(tǒng)，也可以是多個子系統(tǒng)的集成，該設計可同時支持ATS子系統(tǒng)階段和系統(tǒng)集成階段的測試。

2 ATS自動化測試平臺應用

應用服務器子系統(tǒng)為ATS核心服務器，提供主要處理列車跟蹤識別，列車調整，自動進路，運行圖編輯，派班管理等功能。與應用服務器交互的子系統(tǒng)有車站服務器、通信服務器、運行圖管理客戶端、站場監(jiān)控客戶端等。應用服務器承擔功能重大，涉及子系統(tǒng)眾多，交互消息復雜，對其開展自動化測試顯得尤為重要。本章以應用服務器單個子系統(tǒng)為被測對象，選擇設置道岔定操功能為例來詳細說明如何在該平臺上實現(xiàn)自動化測試。

2.1 測試用例定義

設置道岔定操功能是指聯(lián)鎖系統(tǒng)與ATS系統(tǒng)通信正常的情況下，ATS系統(tǒng)向聯(lián)鎖系統(tǒng)發(fā)送道岔定操命令，由聯(lián)鎖系統(tǒng)來實現(xiàn)將道岔置于定位。從各個子系統(tǒng)之間相互傳遞消息的順序關系，可設計一條正向測試用例描述為：采用中心調度臺模擬器向應用服務器發(fā)送內部消息m，采用車站服務器模擬器驗證應用服務器是否向其發(fā)送正確的內部消息n，采用中心調度臺模擬器驗證應用服務器是否向其發(fā)送正確的記錄事件消息k。

2.2 測試腳本編寫

在完成測試用例定義后，即可在仿真管理器中編寫腳本。為便于測試腳本與測試用例的追溯，腳本名稱直接采用測試用例的用例編號。測試腳本在編寫過程中要注意以下幾個關鍵點：

（1）構造測試前置條件。構造正確的測試環(huán)境，離不開對前置條件的充分理解，只有構造了正確的前置條件測試才是有效的。本條測試用例中隱藏的前置條件有：中心調度在客戶端登錄，控制模式為中心控。（2）構造輸入消息和監(jiān)聽輸出消息。無論是構造輸入消息還是監(jiān)聽輸出消息，都需要了解兩個交互子系統(tǒng)之間的內部接口協(xié)議，明確消息的每個字段含義。本條測試用例中客戶端與應用服務器內部消息m的字段有時間戳、CRC校驗、消息ID、消息長度、控制句柄值、聯(lián)鎖區(qū)編號等。（3）發(fā)送消息隊列和接收消息隊列。如果隊列配置錯誤，則會導致消息發(fā)不出去或者接收不到，所以明確被測對象的收發(fā)隊列也是測試執(zhí)行的關鍵。這個需要平臺配置和腳本共同配合解決。從平臺配置上看，針對某個子系統(tǒng)模擬器需要配置四個隊列，分別是從被測節(jié)點接收消息隊列A，向仿真管理器發(fā)送消息隊列B，從仿真管理器接收消息隊列C和向被測節(jié)點發(fā)送消息隊列D;針對仿真管理器，與其交互的所有子系統(tǒng)模擬器的隊列B都需要配置正確。從測試腳本上看，需在腳本中寫入正確的隊列B和D，保持一致則可使消息發(fā)送成功或者監(jiān)聽到期望消息。（4）判定測試通過條件。被測對象輸出的消息是待驗證的消息，在測試過程中需實時監(jiān)聽，一旦收到消息反解后，需根據(jù)消息字段含義對其關鍵字段進行驗證，以確保被測對象輸出消息的正確性。本條測試用例中內部消息n和記錄事件消息k是驗證對象。驗證的內容包含消息n的消息ID、聯(lián)鎖區(qū)編號、控制句柄值等，消息k的消息ID、報警等級等。

2.3 測試用例執(zhí)行

完成腳本編寫后便可在仿真管理器上直接執(zhí)行測試腳本。執(zhí)行腳本可以一次執(zhí)行一條腳本，也可以一次執(zhí)行一個文件夾下的所有腳本，也可以按測試計劃執(zhí)行腳本。在仿真管理器上，執(zhí)行腳本開始時會打印開始時間和被執(zhí)行腳本名稱，執(zhí)行腳本過程中會根據(jù)腳本打印出關鍵消息以及出現(xiàn)的異常，執(zhí)行腳本結束后會打印執(zhí)行完畢的時間和執(zhí)行結果。在子系統(tǒng)模擬器上，會打印出收發(fā)消息的時間，隊列名稱和消息內容。針對本條測試用例，選擇當前測試腳本點擊執(zhí)行，執(zhí)行成功后在被執(zhí)行腳本名稱前更新一個畫勾的圖標顯示測試通過。

2.4 測試結果分析

執(zhí)行本條腳本共耗時2s，針對該功能還需定義很多反向測試用例，例如，發(fā)送CRC錯誤，消息長度錯誤，時間戳錯誤的內部消息m，發(fā)送被篡改的內部消息m，未登陸的客戶端發(fā)送內部消息m等。事實上，對于該功能我們共定義了13條測試用例，只需要一個操作耗時78s即可完成測試，大大節(jié)省了人工成本和時間成本。

當系統(tǒng)功能趨于穩(wěn)定時，工人編寫的測試腳本利用率極高，只需人工啟動本次測試計劃就可以開展自動測試。測試過程無需人工參與，選擇非工作時間執(zhí)行測試，既可以節(jié)省人工成本又可以節(jié)省時間成本。測試腳本一旦創(chuàng)建對測試執(zhí)行人員要求較低，可釋放更多的人力用于維護測試腳本和開展進一步測試開發(fā)工作。當軟件變更不影響系統(tǒng)功能時，研發(fā)人員在完成軟件變更發(fā)布給測試人員前對其進行全功能自動化測試，便可以提前發(fā)現(xiàn)軟件缺陷，對軟件缺陷進行預防，避免一次無用發(fā)布。

3 結語

ATS系統(tǒng)自動化測試平臺的意義在于，第一，執(zhí)行測試的過程無需人工參與無需上班時間，有效節(jié)省了人工成本和時間成本;第二，有效杜絕修改一個缺陷引入更多缺陷;第三，在發(fā)布前由研發(fā)人員執(zhí)行自動化測試可有效預防缺陷發(fā)生;第四，針對業(yè)主不斷提出的新需求，可縮短開發(fā)周期。然而，該測試平臺仍存在一定的局限，當功能發(fā)生變更則需要人工重新編寫測試用例和測試腳本，維護成本較高。在未來，ATS系統(tǒng)自動化測試平臺仍有很多工作可以開展，例如：與現(xiàn)有的缺陷管理系統(tǒng)結合將測試發(fā)現(xiàn)的缺陷自動錄入系統(tǒng)，或通過e-mail將測試結果通知指定人員;與現(xiàn)有的配置管理系統(tǒng)結合對編譯完成的代碼自動下載部署，自動執(zhí)行測試腳本;與測試用例結合探討自動生成測試腳本的方法等;與人機交互界面結合探討UI功能測試。

參考文獻

[1] 趙威.城市軌道交通列車自動監(jiān)控系統(tǒng)的研究[J].鐵路通信信號工程技術（RSCE），2008，5（5）：30-32.

[2] 傅李育.軌交信號系統(tǒng)自動化測試集成平臺設計與實現(xiàn)[M].上海：上海交通大學，2013.

[3] 高璐瑤.安全苛求軟件的自動化測試技術研究[M].杭州：浙江大學，2013.

[4] 王丹.CBTC系統(tǒng)的自動化測試研究[M].北京：北京交通大學，2010.