基于UML Testing Profile的軟件測試過程淺析

藍新生 封二強 鄭 軍

（中航工業(yè)綜合技術研究所，北京 100028）

基于UML Testing Profile的軟件測試過程淺析

藍新生 封二強 鄭 軍

（中航工業(yè)綜合技術研究所，北京 100028）

對軟件測試過程的現(xiàn)狀進行了分析，并對對象管理組織（Object Management Group，OMG）提出的測試建模標準（UMLTesting Profile，UTP）進行了簡要介紹，對UTP的建模特點進行了分析，最后結合實例對UTP進行測試建模的有效性進行了說明。

UTP；軟件測試；測試建模

軟件測試是提高軟件質量和可靠性的重要手段。隨著軟件規(guī)模的增大和復雜程度的提高，特別是攸關生命和財產安全的領域，如航空、航天、鐵路、金融，醫(yī)療等領域，軟件測試對提高軟件質量和可靠性的作用愈發(fā)明顯。

然而，軟件開發(fā)人員、設計人員、測試人員通常使用不同的語言和工具，導致不同角色的交流和文檔信息交換變得困難。

另一方面，目前軟件測試工作主要還是通過手工方式來完成，軟件測試的大部分時間都是用來進行測試文檔的編寫，由于測試存在分工，測試產品的非形式化表示容易造成不同的測試人員對同一測試產品產生不同的理解；測試產品的形式化可以有效地避免上述問題，也有利于測試的實施，但測試產品的形式化要求測試人員具有較高的專業(yè)知識和形式化能力，再加上測試項目緊張，形式化的測試產品表示往往是不允許的。

半形式化語言的出現(xiàn)，大大緩解了上述兩種矛盾，如統(tǒng)一建模語言（United Modeling Language，UML），它提供了9種視圖，可以從不同應用層次和不同角度為軟件開發(fā)人員、設計人員、測試人員提供交流的途徑，很好的避免了測試產品表示的不準確性、歧義性。

由于測試產品中往往存在著時間性能約束、測試結果等描述，而UML無法直接支持這些元素的測試建模，將UML引入軟件測試領域，進行軟件測試產品的表示，還需要進一步的拓展。

為了彌補UML測試建模能力的不足，OMG提出UTP測試建模標準[1]，并分別于2005年7月、2012年4月和2013年4月發(fā)布了該標準的V1.0、V1.1、V1.2版本。UTP為用UML進行建模的系統(tǒng)提供用于系統(tǒng)結構和行為方面測試的確切定義。它可以支持測試相關的設計、可視化、規(guī)格說明、分析、構造以及文檔化。

UTP是基于UML2. 0的測試建模語言，可以獨立于UML使用，支持從單元測試到系統(tǒng)測試的各個級別的測試建模[2，3，4]。UTP可以進一步擴展并應用到多個領域，如遠程通信、IT、航空航天等。

1 UML測試建模語言UTP

UTP從UML繼承而來，具有與UML相同的建模特性，此外，UTP提供了4個邏輯概念對軟件測試進行支持[5]，即測試體系結構（Test Architecture）；測試行為（Test Behavior）；測試數(shù)據(jù)（Test Data）；測試時間（Test Time）。測試體系結構指定了UTP的靜態(tài)結構；測試行為指定了UTP的動態(tài)行為；測試數(shù)據(jù)是代表了貫穿UTP測試行為始終需要的數(shù)據(jù)；測試時間是對UTP測試行為的量化。

1.1 測試體系結構

測試體系架構定義了一組概念，用來描述測試系統(tǒng)的靜態(tài)組成結構，主要包括測試上下文（Test Context）、測試結果判決器（Arbiter）、調度器（Scheduler）、被測對象（SUT）、測試組件（Test Component）等。

被測對象是一個待測的系統(tǒng)或者系統(tǒng)的行為。

測試上下文用來管理整個測試，包括測試組件和測試用例，以及測試的配置、測試控制等。

測試組件用于測試系統(tǒng)中與被測對象或其他測試組件進行交互，以完成某個測試行為。

測試結果判決器用于判斷測試用例的執(zhí)行是否通過。

調度器用來以啟動、終止測試用例及動態(tài)創(chuàng)建測試組件。

1.2 測試行為

測試行為定義一組概念，來用來描述測試系統(tǒng)的行為，包括測試用例（Test Case）、測試目標（Test Objectives）、測試日志（Test Log）、測試結果類別（Verdict）等。

測試目標允許測試設計人員描述測試的目的。

測試用例作為測試上下文的一個行為，用來描述被測對象如何與測試組件進行交互以實現(xiàn)測試的目的。

測試日志用以記錄在測試用例執(zhí)行過程中的實體以便進行更深入的分析。

U T P共定義了4種測試結果類別：通過（Pass），測試行為和預期結果一致；失?。‵ail），測試行為和預期結果不一致；錯誤（Error），測試系統(tǒng)本身存在錯誤或者異常；不可判定（Inconclusive），無法判定測試行為和預期結果的一致性。可通過測試結果判決器設置或者獲取測試用例模型的測試結果類別。

1.3 測試數(shù)據(jù)

測試數(shù)據(jù)定義了一組概念，用以描述測試過程中使用的數(shù)據(jù)，主要包括數(shù)據(jù)池（Data Pool）、數(shù)據(jù)分區(qū)（Data Partition）、數(shù)據(jù)選擇器（Data Selector）和編碼規(guī)則（Coding Rules）。

數(shù)據(jù)池與測試上下文相關，包含數(shù)據(jù)分區(qū)與具體的數(shù)據(jù)值；數(shù)據(jù)分區(qū)用以定義一組劃分測試數(shù)據(jù)的規(guī)則；測試選擇器提供了不同的策略來選擇和驗證數(shù)據(jù)；編碼規(guī)則允許用戶定義測試數(shù)據(jù)的編碼和解碼規(guī)則。

1.4 測試時間

測試時間控制主要定義了兩個概念，即定時器（Timers）和時區(qū)（Time Zone）。

時區(qū)用于描述各個測試組件的協(xié)調與同步問題（尤其在分布式測試中），并規(guī)定每個測試組件屬于至多一個時區(qū)，在同一個時區(qū)中的測試組件具有同樣的時間特性，即同步。定時器用于操作和控制測試行為以保證測試用例的終止。

關于UTP更詳細的介紹可以參考OMG的UML 2.0 Testing Profile[6]。

2 應用實例

在本節(jié)我們通過一個實例來對UTP的測試建模進行說明。以ATM系統(tǒng)為例，為了簡要說明，假設與ATM系統(tǒng)交互的包含兩部分：外部硬件設備HWEmulator和銀行BankEmulator。

圖1描述了AT M系統(tǒng)的測試上下文、測試組件，其中，測試上下文包含3個測試用例（validWiring、validPIN和authorizeCard）來描述ATM測試行為，測試組件HWEmulator和BankEmulator描述了測試的初始配置，包括各個組件與被測對象ATM的連接關系，其中測試組件BankEmulator包括兩種類型的接口，需求接口（required interface）和供給接口（provided interface），其中供給接口IHardware描述了HWEmulator需要的接口，需求接口IATM描述了HWEmulator實現(xiàn)的接口。

圖1 ATM測試上下文和測試組件

圖2描述實例化了ATM及其測試組件，atm、be和hwe分別表示BankATM、BankEmulator和HWEmulator的實例，各測試組件通過各自的接口與ATM進行連接。

圖2 ATM及其測試組件實例

為了提高UML模型表示的簡潔性以及優(yōu)化UML模型的結構，UML中引進了時序組合片段，如ref、alt、opt、par等，其中ref表示了引用其他地方定義的組合片段，alt表示在一組行為中根據(jù)特定的條件選擇某個交互等，UTP完全繼承了UML的這些建模特性。圖3使用了兩個ref組合片段來描述測試用例invalidPIN和validWiring的執(zhí)行順序，即當測試用例invalidPIN執(zhí)行通過時才能執(zhí)行測試用例validWiring。

圖3 ATM系統(tǒng)測試用例執(zhí)行順序

圖3中測試用例invalidPIN的測試目的是驗證ATM是否插入有效的銀行卡，以及在輸入錯誤的PIN碼后是否立即提醒用戶重新輸入密碼。圖4利用順序圖對invalidPIN的行為進行描述，并使用定時器t1來對插入有效的銀行卡后硬件顯示端提示用戶輸入銀行卡PIN碼的時間進行約束，即在用戶插入有效的銀行卡后ATM必須2s內提示用戶輸入PIN碼。

圖4 invalidPIN測試用例

圖4的最后表明當向ATM輸入錯誤的PIN碼后，ATM向硬件顯示終端發(fā)送重新輸入PIN碼的消息，則通過測試。

在本節(jié)中我們通過實例簡單介紹了UTP的基本概念和建模過程。值得說明的是，UTP測試可以支持從單元測試到系統(tǒng)測試各個級別的測試建模。

3 總結

本文介紹了軟件測試的現(xiàn)狀和UTP產生的背景，并對UTP的概念和建模的特點進行介紹和分析。隨著諸如GJB/Z 141-2004《軍用軟件測試指南》和GJB 2725-1996《校準實驗室和測試實驗室通用要求》等標準的出現(xiàn)，軟件測試過程日趨成熟。UTP在UML的基礎上進行擴展，可以有效的復用開發(fā)階段的UML模型，提高了軟件測試建模的能力，大大提高了軟件測試過程階段產品的規(guī)范化。

與UML類似，UTP也是與平臺無關的，即UTP表示的軟件測試模型可以在不同的平臺之間復用，大大提高了測試產品的可移植性。

此外，UTP表示的軟件測試產品可以進一步轉換成可擴展標記語言（Extensive Markup Language，XML）或基于XML的元數(shù)據(jù)交換（XML Metadata Interchange，XMI）形式，通過對XML或XMI測試模型信息的提取，可實現(xiàn)后續(xù)測試產品的自動生成。

目前，已有一些學者研究了UTP概念與其他可執(zhí)行測試腳本之間的轉換關系，如Java單元測試框架JUnit[7]和樹表結合表示法（Tree And Tabular Combined Notation，TTCN）[8,9]，進一步提高了軟件測試的自動化程度。

[1] 黃隴，楊宇航. 面向Web Services的UTP測試模型擴展[J]. 計算機科學, 2010(09)： 第135-136+ 176頁.

[2] Donglin, L. and X. Kai. Test-Driven Component Integration with UML 2.0 Testing and Monitoring Profile[C]. Proceedings of 2007 Seventh International Conference onQuality Software,2007： 32-39.

[3] Lamancha, B.P., M.P. Usaola and M.P. Velthius. Towards an automated testing framework tomanage variability using the UML Testing Profile[C]. Proceedings of 2009 ICSE Workshop on Automation of Software Test, 2009： 10-17.

[4] L, P.R., S. B and X. PULEI.Framework testing of web applications using TTCN-3[J]. International International Journal on Software Tools for Technology Transfer，2008：371-381.

[5] 劉冬懿. 從UML設計模型到測試模型的研究[J].計算機應用研究, 2007, 24(5)：56-59.

[6] OMG ptc/04-04-02：UML 2.0 Testing Profile, Finalized Specification[S].

[7] Palacios, F. and C. Pons. A tool for automatic generation of executable code from testing models[C]. Proceedings of the 22nd IFIP ICTSS, 2010：47-54.

[8] 梁曦, 魏仰蘇. UML2.0 Testing Profile到TTCN-3的映射研究[J]. 杭州電子科技大學學報, 2007(4)：第17-21頁.

[9] Baker, P. and C. Jervis. Early UML Model Testing using TTCN-3 and the UML Testing Profile[C]. Proceedings of Testing： Academic and Industrial Conference on Practice and Research Techniques - MUTATION (2007TAICPART-MUTATION), 2007： 47-54.

（編輯：雨晴）

T–65

C

1003–6660（2015）04–0049–04

10.13237/j.cnki.asq.2015.04.014

[收修訂稿日期] 2015-05-13