藍(lán)新生 封二強(qiáng) 鄭 軍

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

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

藍(lán)新生 封二強(qiáng) 鄭 軍

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

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

UTP；軟件測試；測試建模

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

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

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

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

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

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

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

1 UML測試建模語言UTP

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

1.1 測試體系結(jié)構(gòu)

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

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

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

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

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

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

1.2 測試行為

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

測試目標(biāo)允許測試設(shè)計(jì)人員描述測試的目的。

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

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

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

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

1.4 測試時(shí)間

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

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

關(guān)于UTP更詳細(xì)的介紹可以參考OMG的UML 2.0 Testing Profile[6]。

2 應(yīng)用實(shí)例

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

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

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

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

圖2 ATM及其測試組件實(shí)例

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

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

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

圖4 invalidPIN測試用例

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

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

3 總結(jié)

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

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

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

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

[1] 黃隴，楊宇航. 面向Web Services的UTP測試模型擴(kuò)展[J]. 計(jì)算機(jī)科學(xué), 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設(shè)計(jì)模型到測試模型的研究[J].計(jì)算機(jī)應(yīng)用研究, 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]. 杭州電子科技大學(xué)學(xué)報(bào), 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