AFC 系統異常連接測試工具的設計與實現

杜孝平，張 祿，李 曄

DU Xiaoping,ZHANG Lu,LI Ye

北京航空航天大學 軟件學院，北京100191

College of Software,Beihang University,Beijing 100191,China

1 引言

AFC（Automatic Fare Collection）系統又稱為自動售檢票系統，是城市公共交通中的一項重要技術[1]，為城市軌道交通帶來了諸多益處。改革開放以來，北京城市公共交通尤其是城市軌道交通基礎設施和運營管理得到了較快發展，AFC 作為城市軌道交通運營不可缺少的核心組成系統，為運營的科學管理提供依據[2]。北京市AFC 系統在投入運營前需要進行常規連接測試、異常連接測試、功能測試、專項測試、集成測試等測試工作。異常連接測試的任務是測試AFC 系統中被測車站設備和系統對異常數據的處理是否符合《北京軌道交通AFC系統設計及實施規范》（簡稱“實施規范”）中的相關要求，它是檢測AFC 系統容錯性的重要手段。

文獻[3-5]討論了在平臺搭建基礎上對AFC 功能和接口進行測試的問題；文獻[6-7]在討論模擬測試工具的設計實現基礎上，介紹了對AFC 系統的功能與接口測試。現有文獻尚未看到對異常連接測試的相關測試工具研究的介紹。

負責北京市AFC 系統檢測的北京市軌道交通指揮中心現在針對異常數據處理的測試方式是利用一個輔助測試工具，通過熟悉AFC 系統的人員對照實施規范中的數據結構，手動構造測試數據，并按測試用例逐步發送/接收數據，人工對比接收到的數據和測試用例中的預期數據是否一致，來判斷被測對象是否滿足要求。其測試方式對人員素質要求較高，且編制數據與控制數據收發過程效率低下，易于出錯。本文對設計實現一個異常連接測試工具用于完成上述測試任務進行討論。該工具可自動生成測試數據，自動控制數據收發流程，降低測試人員對系統業務了解的要求，提高測試效率。

2 問題描述與分析

AFC 系統一般采用5 層架構體系：清算中心（AFC Clearing Center，ACC）、線路中心（Line Center，LC）/多線路中心（Multiple Line Center，MLC）、車站計算機系統（Station Computer，SC）、車站終端設備（Station Level Equipment，SLE）和車票層[8-11]，如圖1 所示。異常連接測試的任務是測試MLC、SC 與SLE 之間對異常數據的處理是否符合實施規范的要求。異常連接測試工具需要具備仿真上述某一層系統或設備同其他被測系統或設備（簡稱被測對象）建立連接，向被測對象發送消息并檢查應答的功能，具體包含仿真MLC 測試SC、仿真SC 測試MLC與SLE以及仿真SLE測試SC四部分。其開發原理是基于AFC 系統各層次的通信接口協議，由仿真工具模擬生成各層次系統或設備的測試數據，與被測對象進行通信，驗證測試數據能否符合實施規范的要求[12]。

圖1 AFC 系統層次圖

3 測試工具設計

3.1 總體設計

異常連接測試的一般流程為先準備測試數據，再與被測對象建立連接，最后按測試用例收發數據，若收發數據的順序和內容都與測試用例一致，則該測試用例通過，否則中斷測試用例的執行，對錯誤進行記錄。工具設計以盡力降低系統耦合度，實現數據共享，加強功能函數復用為原則。基于此原則，本工具的總體架構設計為界面層、支撐層、數據層三層。界面層為直接面向用戶的功能層，包含測試數據準備、實現與被測對象的連接以及執行測試功能；支撐層為工具的運行提供公用的功能函數，為界面層的各個功能提供有效支持；數據層為整個工具的運行提供數據支撐，用于存儲自動生成的測試數據、測試日志以及測試數據結構數據和測試用例結構數據。測試工具的總體結構如圖2 所示。

圖2 測試工具的總體架構

為實現本工具的各功能，使其能替代大部分人工測試工作，需要解決兩個關鍵問題：測試數據的自動生成和測試用例的自動執行，下面為這兩個問題提供解決思路。

3.2 關鍵問題的解決

3.2.1 自動生成測試數據

為了能夠自動生成測試數據，首先需要根據測試數據的特征將其進行分類，再利用這些分類數據根據需要靈活生成滿足測試需求的測試數據。自動生成的測試數據是否正確依據實施規范規定的內容來判斷。

實施規范中規定的測試相關數據由大量數據字段構成。基于自動生成測試數據時每個字段被處理的方式的不同，可將這些數據字段歸納為六類：

（1）固定內容字段。包含由實施規范規定的數據起始、結束標識等字段。這類字段長度與內容都在實施規范中有明確的定義，其值固定不變。

（2）隨本工具模擬的設備不同而變化的字段。包含設備ID、設備IP、設備群組號等設備的基本信息字段。這類字段長度固定，內容隨設備而變。

（3）隨時間變化的字段。包含描述數據發送時間、交易生成時間等與時間相關的字段。這類字段長度不變，內容隨時間變化，且其值來自于數據產生時的系統時間。

（4）隨測試用例變化的字段。這類字段用于描述由本工具向被測對象發送的消息錯誤應答中的錯誤碼，其值由測試用例中規定的錯誤類型確定。這類字段長度不變，內容隨具體測試用例而變。

（5）描述數據包長度的字段。這類字段長度不變，其值隨數據包的大小不同而不同。

（6）需要人工參與填寫數據值的字段。包含請求指定包數目、狀態數量數據等。這類字段長度不變，其值在實施規范和測試用例中都沒有規定，需要測試者按實際情況填寫，該類數據字段很少，僅在少量測試數據中出現，對自動生成測試數據的影響不大。

自動生成測試數據時，每個測試數據由多個前述數據字段構成，單個數據字段的長度和結構不變，但整個測試數據的長度和結構隨測試的不同而不同。

測試數據屬于半結構化數據，利用關系型數據庫存儲管理較為困難。可擴展標記語言（XML）是半結構化數據的一個特例[13]，XML 數據模型能很好地實現對半結構化數據的管理以及不同程序或模塊對半結構化數據的共享[14]。本文以XML 作為測試數據結構數據和測試用例結構數據的存儲語言。

為實現自動生成測試數據的功能，可將每個數據的具體結構和固定內容按一定規則用XML 存儲于配置文件中，通過自動生成測試數據函數（在4.2 節介紹）解析配置文件來生成測試數據。配置文件中測試數據的結構如圖3 所示。

圖3 測試數據存儲結構

圖中第2～4 行分別用于描述實施規范中數據的一級分類（如控制數據）、子分類（如控制數據中的命令數據）與數據的具體名稱（如設備運行控制命令）。

第5～10 行用于表示一個數據字段，其中第10 行中的property 屬性用于標識該字段屬于六個數據字段分類中的哪一類。

第11～20 行用于表示一個特殊的數據片段的結構，該數據片段可以在一個測試數據中重復多次。

自動生成測試數據函數在解析測試數據結構后，根據測試數據結構中每個數據字段的分類來做出相應的處理，生成預期的測試數據。自動生成測試數據函數對各類字段的處理方法如下：

對于第一類字段，直接取其固定值寫入。

對于第二類字段，通過提取本工具模擬設備時填寫的設備相關信息來寫入。

對于第三類字段，取生成該字段時的系統時間填入數據字段。該類字段描述的是數據發送時間、交易生成時間等，屬于即時內容。

對于第四類字段，其數據內容需要在自動執行測試用例時實時填入，即通過讀取測試用例中的相應數值來填入。該類字段的值是在測試用例中規定的，同一類數據在不同的測試用例中該值都可能不同，需要在執行測試用例時實時填入。

對于第五類字段，在數據包生成完成后通過計算數據包長度填入。其值來自于將測試數據中每個字段的字節長度相加的結果。

對于第六類字段，自動生成測試數據函數生成默認的固定值，這些默認值可能并不符合實際情況，但在大部分測試用例中并不影響測試結果，若用戶不想使用默認值，則可以自己修改該類數據字段的值。

3.2.2 自動執行測試用例

執行測試用例時，是由測試人員逐條執行測試用例的每個步驟，觀察實際操作結果與測試用例的描述結果是否相同。其中每個步驟的操作內容可以分為兩類：向被測對象發送數據和對比來自被測對象的數據與測試用例描述數據是否相同。自動執行測試用例的功能，可以通過取出以XML 文件組織的測試用例，根據解析的結果調用相應的功能函數并獲取相應的測試數據來實現[15]。測試用例按一定規則用XML 存儲在配置文件中，測試用例的每個步驟作為一個節點，每個節點中存儲數據名稱，并區分該數據是“發送”還是“接收”。在自動執行測試用例時，自動執行測試用例函數解析配置文件，當節點中的數據標記為“發送”時，則調用自動生成測試數據函數生成相應測試數據或直接獲取已經存在的測試數據并發送，然后繼續讀取下一個節點；當節點中的數據標記為“接收”時，則調用數據解析函數（在4.2節介紹）解析接收到的數據，對比接收到的數據特征與節點中存儲的數據特征是否相同，若相同則繼續讀取下一個節點；若不同則中止測試用例的執行，提示用戶測試用例執行出錯。用例執行過程中收發的數據和提示信息都會記錄于日志文件中。

4 測試工具實現

本測試工具的界面層按用戶行為主要分為三部分：與被測對象連接、數據準備和執行測試。

與被測對象連接部分需要實現配置測試工具的連接信息來與被測對象建立連接，并向被測對象發送測試數據以及接收來自被測對象的數據的功能。

數據準備部分需要實現自動生成測試數據，解析顯示測試數據的功能。

執行測試部分需要實現自動執行測試用例，執行過程中自動生成測試數據，解析來自被測對象的數據的功能。

4.1 與被測對象連接的實現

異常連接測試中要求傳輸的數據利用基于TCP/IP的SOCKET 協議進行傳輸。根據實際測試需求，本工具可模擬測試對象主動連接實際的被測對象（如利用本工具模擬SC 測試MLC 以及模擬SLE 測試SC 時，由本工具向被測對象MLC 和SC 發出連接請求）；或作為模擬的測試對象等待實體被測對象主動連接（如利用本工具模擬MLC測試SC以及模擬SC測試SLE時，本工具被動等待來自實測對象SC 與SLE 的連接請求）。主動請求連接的一方稱為客戶端，等待連接請求的一方稱為服務端。建立連接時，由服務端監聽某個端口，客戶端根據服務端的IP 地址和其監聽的端口號與服務端建立連接。

與被測對象建立連接、發送接收數據通過C#的socket庫實現。建立連接的過程如圖4 所示。

圖4 建立連接過程

4.2 數據準備的實現

該部分由自動生成測試數據函數和數據解析函數來實現。為方便對自動生成測試數據函數的原理進行說明，將圖3 所示的XML 文件抽象為圖5（a）所示的樹狀結構，將實際測試數據（一個二進制文件）內容抽象為圖5（b）所示的結構。自動生成測試數據函數首先解析如圖3 所示的XML 文件，找出要生成的測試數據節點（如DataType_2），然后遍歷該節點下的每個子節點Row1,Row2,…，每個子節點即一個數據字段，函數判斷該數據字段屬于六個數據字段分類中的哪一類，按3.2.1小節中對相應數據字段的處理方法生成數據內容，并將數據內容填入圖5（b）所示的相應片段中。若某個Row節點下存在children 子節點（如Row2，其生成的數據內容設為x），則需要為children 節點的子節點Row′1,Row′2,…生成數據內容，并插入到Row2節點的數據內容之后，且需要循環生成x遍children 節點的子節點內容。當Row節點遍歷完成，則測試數據也生成完畢。

數據解析函數用于解析一個已經存在的數據包，通過取二進制數據中的特定位置的字節與實施規范中的定義比對，以此判斷該數據的具體名稱，并由該具體名稱從圖3 的XML 文件中獲取相應數據結構，然后將該數據包按該結構分解展示給用戶查看和修改，方便用戶對數據包的理解和維護。

圖5 抽象結構

圖6 為本工具的自動生成測試數據的界面。圖中A區域表示數據分類結構樹，由圖3 的XML 文件生成；B區域表示自動生成的測試數據。

圖6 自動生成數據界面

4.3 執行測試的實現

該部分由自動生成測試數據函數、自動執行測試用例函數和數據解析函數來實現。執行測試時調用自動執行測試用例函數，發送數據時調用自動生成測試數據函數生成相應數據并發送，接收數據后調用數據解析函數解析數據，并對比接收到的數據特征與測試用例中存儲的數據特征是否相同。

自動執行測試用例函數讀取存儲有測試用例結構的XML 文件，存儲結構如圖7 所示。

圖7 測試用例存儲結構

圖8 測試用例自動執行結果

當函數讀取到SendData 節點時會發送相應的數據。SendData 節點中存儲需要發送的數據名稱，根據該名稱函數會調用自動生成測試數據函數來生成相應的數據。filledByTester屬性用于標識該數據中是否有需要測試人員填寫的數據，如果其值為true，則測試者可以選擇本地已有的存儲數據的文件作為發送數據，防止每次發送相同的數據時都需要測試者自己填寫數據內容。如果發送的數據需要構造某些異常，則需要errorType屬性。自動執行測試用例函數會根據errorType 屬性的不同來更改發送數據的相應字段，以構造相應的異常數據。當發送的數據是消息錯誤應答，該反饋中需要填寫錯誤類型代碼時，則填入errorCode屬性值。

測試用例自動執行結果如圖8 所示。

5 結束語

本文通過分析當前北京AFC 系統異常連接測試過程中存在的問題，找出了影響測試效率的瓶頸。通過總結歸納測試數據和測試流程步驟，將測試數據分為六類，測試流程步驟分為兩類，并將這些特點信息存儲于XML 文件中，由異常連接測試工具自動解析處理，開發實現了具有自動生成測試數據、自動執行測試用例功能的異常連接測試工具，為測試提供了一種可選的新手段。數據結構和測試用例步驟的可定制性，以及界面的友好性將是下一步工作的重點。

[1] Ampelas A.Automatic fare collection[C]//Proceedings of Intelligent Transportation Systems，2001：1164-1166.

[2] 趙菁.試論城市軌道交通（AFC）系統運營數據分析與運營管理[J].城市建設，2010（11）：128-129.

[3] 陳偉欣，楊俊輝，肖力揚.基于Web 的城市軌道AFC 仿真測試平臺設計[C]//第十屆中國科協年會論文集（一），鄭州，2008：284-287.

[4] 黃鐘.自動售檢票通用測試平臺的構建[J].城市軌道交通研究，2006，9（12）：32-35.

[5] 徐高峻.自動售檢票系統模擬測試平臺的組建與應用[C]//2010 城市軌道交通關鍵技術論壇論文集，上海，2010：503-506.

[6] 張志敏.針對AFC 系統的自動化測試工具研究與實現[D].長沙：湖南大學，2010.

[7] 葉皚.自動售檢票軟件測試方法及其工具應用研究[D].上海：東華大學，2010.

[8] 徐煒煒，徐駿善，葉飛.自動售檢票系統中車站信息管理系統的研究與設計[J].城市軌道交通研究，2012（5）：53-56.

[9] 潘穎芳.城市軌道交通AFC 系統體系結構分析與研究[J].信息技術，2012（2）：166-168.

[10] 裴順鑫，張寧.地鐵自動售檢票系統的互聯標準[J].都市快軌交通，2007（5）：38-41.

[11] 陳鵬輝.城市軌道交通自動售檢票系統的現狀與發展趨勢[J].城市軌道交通研究，2009（5）：10-12.

[12] 蔡佳妮.自動售檢票系統檢測中心檢測理念與實施策略[J].城市軌道交通研究，2011（1）：24-28.

[13] 鄔晶亮.基于XML 的半結構化數據存儲和查詢的研究與實現[D].上海：上海交通大學，2006.

[14] Bertolino A，Gao J，Marchetti E，et al.Automatic test data generation for XML schema-based partition testing[C]//Proceedings of the 2nd International Workshop on Automation of Software Test.[S.l.]：IEEE Computer Society，2007.

[15] 朱菊，王志堅，楊雪.基于數據驅動的軟件自動化測試框架[J].計算機技術與發展，2006（5）：68-70.