基于UML的列車自動防護系統測試用例生成方法研究

李曉潔

（西南交通大學 交通信息工程及控制，成都 610031）

列車自動防護系統是列車控制系統的重要組成部分，對列車安全負有直接責任，因此對其進行全面的功能測試，確保其正確完成系統需求規范所要求的功能，對高速鐵路建設具有十分重要的意義。本文主要研究如何將UML自動測試技術引入到列車自動防護系統的測試中。

1 列車自動防護系統分析

列車自動防護（ATP，Automatic Train Protection）系統作為列車自動運行控制系統的重要組成部分，其主要任務在于保證行車安全、防止列車進入前方列車占用的區段以及防止列車超速運行。ATP系統屬于安全苛求系統，對列車安全負有直接責任，因此，對ATP設備進行系統功能測試等評估測試工作具有重要意義。

ATP系統屬于大規模集成系統，若采用傳統測試方法對其進行安全評估測試，不但無法保證測試的科學性與嚴密性，還會因為測試工作的重復性耗費大量的時間、成本、人力和物力資源。因此，將自動測試技術引入ATP系統的測試很有必要。基于UML的自動測試技術是近年來自動測試技術發展的主流趨勢，本文以ATP系統的動態速度監控功能為例，采用此方法對ATP系統測試進行分析。ATP系統的動態速度監控用例圖如圖1所示。

圖1 ATP系統的動態速度監控用例圖

2 基于UML的自動測試技術

在軟件測試過程中，測試用例和數據設計是非常困難和繁重的工作。測試用例的生成方法主要有2種：基于代碼的測試用例生成和基于規格說明的測試用例生成。

基于代碼的測試用例生成并不適用于大規模的集成測試和系統測試，ATP車載系統屬于大規模集成系統，在開發用于ATP系統的測試用例時，本文選擇基于規格說明的測試用例生成方法。

基于UML的軟件測試的優點在于比其它的形式化方法具有更廣泛的適用性。通過將系統需求規范轉換成標準的UML模型，并將其作為測試需求的直接來源，驅動整個測試過程。基于UML的軟件測試過程如圖2所示。

圖2 基于UML的軟件測試過程

要使UML支持軟件測試，首先需要研究UML模型的可測試性，針對不同類型不同階段的測試，給出嚴格的可測試的UML模型[1]。可測性問題實際上就是研究一個UML模型是否包含足夠的信息來產生測試用例的問題。

一個可測試的模型需要滿足的條件有：

（1）模型是對被測系統完整且準確的描述，而且還描述了所需測試的所有功能特性；

（2）模型是對系統細節的抽象描述；

（3）模型保留了被測系統中有利于發現錯誤和驗證系統一致性的關鍵細節；

（4）對狀態模型而言，模型應該描述了所有的動作、狀態和事件，并且對所有狀態進行了明確的定義。

UML作為一種半形式化的建模語言，具有高度的靈活性，因此在建模的過程中，只要遵循了UML的語法和語義，并且遵循一定的建模方法，得到的UML模型是可以達到可測試性標準的。

建立了良好可測的UML模型后，就需要進一步研究如何從UML模型生成測試用例，自動測試技術要求測試用例具有良好的通用性和可移植性，使用XML規范來對測試用例進行描述滿足上述要求，因此本文采用基于XML的測試用例描述方法。

3 基于XML的測試用例生成方法

3.1 概述

可擴展標記語言（XML）是一種通用語言規范，它以一種開放的自我描述方式定義數據結構，在描述數據內容的同時能突出對結構的描述，從而體現出數據之間的關系[2]。

測試用例是測試系統與被測系統的交互信息集合，包括輸入序列、期望的系統執行操作序列和期望的輸出序列。其本質就是一種數據對象，因此使用XML描述這種數據對象有著相當的優勢。

本文采用一種從UML到XML Schema的3層設計方法來實現從需求分析的UML模型到XML測試腳本的轉化方法。這種3層設計方法是基于UML類圖實現的[3]，其設計思路如圖3所示。

圖3 從UML生成XML測試腳本的3層設計方法

該過程可以描述為3個步驟：（1）根據系統需求規范，創建所需測試系統的UML圖。在創建過程中，要遵守可測試建模規則；（2）根據一系列的轉換規則，將概念層的UML圖轉換為使用XML Schema說明的邏輯層UML類圖；（3）根據邏輯層UML類圖，導出XML Schema文檔[4]。

3.2 邏輯層UML類圖構建

概念層模型無法直接轉換為XML Schema，這是由于概念層模型中的數據類型以及類之間的關系等與XML Schema之間沒有必然關聯，而且概念層模型中沒有對類的結構從屬和嵌套關系的定義，所以需要根據XML Schema定義的構造型來構建邏輯層的UML類圖[5]。

（1）對UML中定義的符號進行擴展，即用UML類圖表示XML Schema中的概念。UML提供了特有的擴展機制，包括構造型、約束和標簽值。在構造邏輯層類圖模型時，只用到構造型擴展機制，這是由于基于一個已經存在的模型元素來定義一種新的模型元素時，構造型的信息內容和形式與已經存在的基本模型元素相同，只是其含義和使用不同。這樣就能使XML Schema中的元素類型嵌入到邏輯層模型中。

（2）需要通過這些擴展過的構造型對屬性的數據類型進行轉化。在邏輯層模型中，有3種適用于描述各種數據類型的構造數據類型：XSDSimpleType、SimpleType和ComplexType，這3種類型分別對應于XML模式中的內置簡單類型、簡單類型和復雜類型。其轉化規則如下：

a.屬性中的數據類型若是內置簡單數據類型，則將其直接轉化為XSDSimpleType構造型，僅在數據類型前加上xsd，表示該數據類型是邏輯層的內置數據類型。例如，string可以直接映射為xsd:string。

b.屬性中的數據類型若是僅在內置簡單數據類型上進行了一定限制，如枚舉類型、列表類型和對數據的上限下限進行限定等，則將該數據類型轉換為SimpleType構造型。在其中將限制內容設定為屬性和值，并被一個XSDSimpleType約束。

c.屬性中的數據類型如果是具體類，則將其轉換為ComplexType構造型。

（3）要確定類的關系走向。將類表示成結構化的關系，即通過類之間的關系確定類的嵌套關系。

根據以上規則，以列車自動防護系統中動態曲線生成功能為例，可以構造其邏輯層UML類圖，如圖4所示。

圖4 動態曲線計算的邏輯層UML類圖

3.3 物理層測試案例生成

物理層測試案例是從邏輯層的模型映射得到的XML Schema，由于在構建轉換邏輯層模型是已經用到了根據XML Schema定義的構造型，所以映射關系為互相對應的，映射方法如下：

表1 結構對應關系：物理模型中的元素、數據類型及關系用邏輯模型表示

表2 文檔包含對應關系：物理模型中的模式文檔包含關系用邏輯模型表示

表3 內容模型及類型對應關系：物理模型中的內容模型以及類型用相應的邏輯模型表示

根據以上對應關系，可以寫出圖4的物理層XML Schema文檔，由于篇幅有限，此處僅對其進行部分描述：

type=”xsd:integer” />

type=”xsd:integer” />

type=”xsd:integer” />

4 結束語

本文對列車自動防護系統測試用例的生成方法進行了描述，以ATP系統動態速度監控功能為例，采用由UML生成XML測試腳本的3層設計方法，從構建測試案例的概念層UML圖開始，使用轉換規則及對應關系，最終生成了測試案例的XML Schema文檔。這種方法基于統一建模語言UML，采用可擴展標記語言XML來對測試案例進行描述。生成的測試文檔具有通用性，有利于自動化測試技術的展開和發展。

由于列車控制系統的復雜性，其自動化測試技術的實現依然存在諸多難點，在得到了測試用例之后，如何分析其可行性，具體生成實際測試中的測試序列，依然是未來研究的重點。

[1] 徐宏喆，陳建明.UML自動化測試技術[M] . 西安：西安交通大學出版社，2006，8.

[2] 高怡新.XML基礎教程[M] ：北京：人民郵電出版社，2006，11.

[3] Routledge N, Bird L, Goodchild A.UML and XML schema[J] . Australian Computer Science Communications, 2002,24(2):157-166.

[4] David Carlson,Modeling XML Applications with UMLPractical e-Business Applications[M] .Pearson Education,2001.

[5] 王明文，朱清新.基于UML的XML Schema設計[J] .電子科技大學學報，2006，35（3）：389-391.