基于UML的軟件測試的研究與應(yīng)用

梁利亭

(三門峽職業(yè)技術(shù)學(xué)院，河南 三門峽 472000)

〔專題研究與新論〕

基于UML的軟件測試的研究與應(yīng)用

梁利亭

(三門峽職業(yè)技術(shù)學(xué)院，河南 三門峽 472000)

文章首先分析了軟件測試的起源、發(fā)展，然后分析了面向?qū)ο蟮能浖y試技術(shù)，接著論述了面向?qū)ο蟮能浖y試當(dāng)中最常用的UML技術(shù)，最后利用UML圖在面向?qū)ο蟮南到y(tǒng)中生成測試用例。

軟件測試；面向?qū)ο?；UML

軟件的漏洞和缺陷是伴隨著軟件的出現(xiàn)而產(chǎn)生的，同時，為了盡可能地解決軟件的漏洞和缺陷，軟件測試也同樣伴隨著軟件的開發(fā)而出現(xiàn)。隨著軟件體系結(jié)構(gòu)的日益復(fù)雜、軟件種類的日益增多、新的編程技術(shù)的不斷出現(xiàn)，軟件漏洞和缺陷也日益增多，并且危害性也越來越大。例如2009年7月份，微軟的OFFICE組件的一個“OFFICE內(nèi)存破壞”安全漏洞，導(dǎo)致了7000萬人次被攻擊和近3萬個網(wǎng)站被掛馬，造成了巨大的損失。因此，軟件測試成為了提高軟件的開發(fā)效率和保證軟件質(zhì)量的最有效的手段。

一、軟件測試的起源和發(fā)展

軟件測試主要經(jīng)歷了如下幾個重要的發(fā)展階段：

1.軟件調(diào)試：早期的軟件規(guī)模小、結(jié)構(gòu)簡單，在開發(fā)過程當(dāng)中如果遇到其中的漏洞和錯誤，經(jīng)過軟件開發(fā)人員的調(diào)試后基本上就可以解決了。

2.獨(dú)立的軟件測試：隨著軟件開發(fā)的日益復(fù)雜，軟件開發(fā)過程當(dāng)中涉及的內(nèi)容越來越多，僅靠軟件開發(fā)人員的調(diào)試不能夠發(fā)現(xiàn)軟件當(dāng)中的漏洞和缺陷，這時就引入了一個獨(dú)立的測試小組來完成軟件的測試。

3.軟件測試概念的提出：直到20世紀(jì)70年代，Bill Hetzel在North Carllina大學(xué)舉行第一次以軟件測試為主題的正式議會提出了軟件測試的概念。在這個階段，軟件測試主要的內(nèi)容是：軟件測試被用來檢測相關(guān)軟件產(chǎn)品能否正確執(zhí)行，滿足相關(guān)需求。

4.軟件測試成了獨(dú)立的學(xué)科：20世紀(jì)80年代后，隨著軟件需求的快速發(fā)展，軟件的復(fù)雜度和規(guī)模越來越大，人們對軟件的開發(fā)效率和軟件質(zhì)量要求越來越高，并開始將軟件測試作為保證軟件質(zhì)量的重要手段。1981年Bill Hetzel博士開設(shè)了一門結(jié)構(gòu)化軟件測試“Structured Soft-ware Testing”公共課。1983年IEEE給出了軟件測試的定義：軟件測試是使用人工或自動手段來運(yùn)行或測定某個系統(tǒng)的過程，檢驗(yàn)它是否滿足規(guī)定的需求或是弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別。軟件測試是一站需要經(jīng)過設(shè)計(jì)、開發(fā)和維護(hù)等完整階段的軟件工程。

5.開發(fā)與測試的融合階段：20世紀(jì)90年代以來，各種各樣的軟件開發(fā)模式開始出現(xiàn)，特別是面向?qū)ο蟪蔀榱塑浖_發(fā)的主流，由于面向?qū)ο蟮能浖_發(fā)模式的優(yōu)勢，使得人們開始將軟件測試和軟件開發(fā)進(jìn)行融合，軟件開發(fā)人員和軟件測試人員開始協(xié)調(diào)工作，軟件測試和軟件開發(fā)的界限開始變得模糊，測試驅(qū)動開發(fā)（Test-Driven Development，TDD）技術(shù)出現(xiàn)，它的基本思路是：通過測試來推動整個開發(fā)的進(jìn)行，于是測試驅(qū)動開發(fā)并不只是單純的測試工作，而是把需求分析、設(shè)計(jì)、質(zhì)量控制量化的過程。

二、面向?qū)ο筌浖y試

20世紀(jì)80年代后期以來，面向?qū)ο筌浖夹g(shù)開發(fā)發(fā)展迅速，其多態(tài)、封裝和繼承的新特性使軟件開發(fā)具有易維護(hù)、質(zhì)量高、效率高、易擴(kuò)展等優(yōu)勢，但這些新特點(diǎn)也改變了軟件測試的相關(guān)要求和方法，給軟件測試提出了新的挑戰(zhàn)。

面向?qū)ο筌浖y試是根據(jù)面向?qū)ο蟮能浖_發(fā)過程結(jié)合面向?qū)ο蟮奶攸c(diǎn)提出的。它包括分析與設(shè)計(jì)模型測試技術(shù)、類測試技術(shù)、對象交互測試技術(shù)、類層次結(jié)構(gòu)測試技術(shù)、面向?qū)ο笙到y(tǒng)測試技術(shù)五大部分。

與傳統(tǒng)的軟件測試技術(shù)相比，面向?qū)ο蟮膯卧獪y試就是類測試；面向?qū)ο蟮念惡蛯ο筮M(jìn)行交互測試就是類簇測試；面向?qū)ο蟮南到y(tǒng)測試與傳統(tǒng)的系統(tǒng)測試基本上是相同的，與傳統(tǒng)系統(tǒng)測試不同的是，面向?qū)ο蟮南到y(tǒng)測試還需要驗(yàn)證OOA分析的結(jié)果，對軟件的架構(gòu)設(shè)計(jì)部分進(jìn)行驗(yàn)證，確保軟件可以順利實(shí)現(xiàn)用戶需求。

三、UML技術(shù)在面向?qū)ο筌浖y試中的應(yīng)用

統(tǒng)一建模語言(Unified Modeling Language UML)，是面向?qū)ο筌浖_發(fā)的重要工具之一，它是一種可視化的建模語言，系統(tǒng)構(gòu)建者用標(biāo)準(zhǔn)的、易于理解的方式建立一種有效的和共享的軟件開發(fā)系統(tǒng)藍(lán)圖。UML提供了一套描述軟件系統(tǒng)模型的概念和圖形表示方法，軟件開發(fā)人員可以使用UML對復(fù)雜的面向?qū)ο筌浖到y(tǒng)建立可視化的模型，并通過增量式的不斷細(xì)化，直接控制從設(shè)計(jì)、編碼、測試到文檔編制的整個軟件開發(fā)過程。

UML包含三個方面的內(nèi)容:模型的概念和表示法、語言的公用機(jī)制、對象約束語言。UML提供的標(biāo)準(zhǔn)模塊有三種:事務(wù)、關(guān)系和圖。事務(wù)是一個模型的一級抽象成員。UML定義的事務(wù)包括結(jié)構(gòu)性事務(wù)、行為性事務(wù)、成組性事務(wù)和注釋性事務(wù)。而UML提供的模型之間的關(guān)系包括依賴、關(guān)聯(lián)、范化、實(shí)現(xiàn)四種。利用UML建立的模型，可以應(yīng)用于C#、C++、Java以及任何一種面向?qū)ο蟮某绦蛟O(shè)計(jì)語言當(dāng)中。

在利用UML模型進(jìn)行軟件測試時，測試人員首先應(yīng)注意利用UML的面向?qū)ο筇匦裕浯?，在利用UML進(jìn)行軟件建模時，是以用戶模型視圖所捕獲的用戶規(guī)約為中心而展開的，可以利用OCL來確定描述各種UML圖所不能刻畫的不變式、前置條件和后置條件等模型約束，這些規(guī)約是UML模型功能測試和驗(yàn)收測試的基礎(chǔ)。軟件測試的目的就是為了發(fā)現(xiàn)軟件系統(tǒng)執(zhí)行期間所可能出現(xiàn)的錯誤，因此UML的用戶模型視圖和行為模型視圖通常是軟件測試的重點(diǎn)。一般來說，在面向?qū)ο蟮能浖y試當(dāng)中，使用類圖和狀態(tài)圖進(jìn)行單元測試，使用協(xié)作圖、活動圖、狀態(tài)圖和構(gòu)件圖進(jìn)行集成測試，使用用案圖來進(jìn)行系統(tǒng)測試。

基于UML的測試有下列優(yōu)點(diǎn)：通用性強(qiáng)，形式化好，有著強(qiáng)大的管理能力和描述能力，可重用性和可迭代性?；谝陨显?，UML不僅是軟件開發(fā)的重要工具，同時也是指導(dǎo)軟件測試的重要模型。

四、軟件測試實(shí)例

1.軟件簡介

Cacti是一套基于PHP、MySQL、SNMP及RRDTool開發(fā)的網(wǎng)絡(luò)流量監(jiān)測圖像分析工具，可以實(shí)現(xiàn)網(wǎng)絡(luò)狀態(tài)的實(shí)時圖像化顯示、故障報(bào)警、創(chuàng)建監(jiān)測模板等功能，同時它還提供了豐富的網(wǎng)絡(luò)監(jiān)測插件，基于Cacti網(wǎng)絡(luò)管理者可以構(gòu)建本地網(wǎng)絡(luò)的、滿足監(jiān)測功能的網(wǎng)絡(luò)監(jiān)測系統(tǒng)。目前，隨著IPv6網(wǎng)絡(luò)協(xié)議的全面實(shí)驗(yàn)，特別是在高等院校當(dāng)中已經(jīng)進(jìn)行了IPv6大規(guī)模的部署實(shí)驗(yàn)，對IPv6網(wǎng)絡(luò)的監(jiān)控管理系統(tǒng)的開發(fā)就顯得日益重要，本系統(tǒng)是一個基于Cacti和RRDTool框架開發(fā)的完整的網(wǎng)絡(luò)管理圖形解決方案。最重要的是支持IPv6網(wǎng)絡(luò)設(shè)備的監(jiān)視與管理，而且通過創(chuàng)建圖形使網(wǎng)絡(luò)管理員的工作更容易照顧到網(wǎng)絡(luò)的細(xì)節(jié)。通過Cacti的圖形用戶界面，使得網(wǎng)絡(luò)管理員可以直觀地觀測到網(wǎng)絡(luò)的實(shí)時流量信息，為IPv6網(wǎng)絡(luò)在未來的大規(guī)模應(yīng)用提供了良好的管理保障。

2.利用UML活動圖進(jìn)行集成測試

在面向?qū)ο蟮能浖y試當(dāng)中，集成測試的一個主要目標(biāo)就是確保每個類或組件對象的消息以正確的順序發(fā)送和接收，同時確保接收消息的外部對象的狀態(tài)獲得預(yù)期的影響。利用UML活動圖，能夠針對面向?qū)ο蟮能浖y試生成良好的測試用例。在利用活動圖生成相應(yīng)的測試用例的時候，需要的條件有：

（1）需要由客戶或開發(fā)人員進(jìn)行討論后以自然語言形式給出的需求文檔，文檔描述了開發(fā)系統(tǒng)所具有的所有必要的行為。

（2）可以利用需求文檔給出的信息生成用案圖集，如果有必要，將這些用案圖和客戶經(jīng)行進(jìn)一步的修改，利用確定好的用案圖來刻畫與系統(tǒng)之間交互以及這些交互期望輸出的活動圖。

（3）所得到的活動圖將被變換成能區(qū)分系統(tǒng)的輸入、輸出以及系統(tǒng)本身的任務(wù)，刻畫輸入輸出的順序以及各活動之間的并發(fā)性的形式活動圖 (Formal Activity Diagrams，F(xiàn)AD)。為構(gòu)造測試用例，F(xiàn)AD被劃分成多個“片段”，其中的每個片段都要單獨(dú)地進(jìn)行分析以得到一個不完整的測試用例。

（4）通過特定的方法將這些不完整的測試用例合并成完整的測試用例。

（5）形式活動圖(FAD)以圖的形式來描述用戶和待測試系統(tǒng)之間的交互關(guān)系，用來修改后的活動圖刻畫系統(tǒng)的輸入和輸出所具有的特性，使得測試用例的生成較為容易。利用形式活動圖生成測試用例的基本思想是：將一個FAD分割成多個片段，接著對每個片段進(jìn)行分析，以便找出其對應(yīng)的可能事件序列，然后為已分成若干片段的FAD建立一個片段方程。片段方程描述了如何合并與各個片段對應(yīng)的事件序列以構(gòu)造出完整的測試用例。將事件序列進(jìn)行合并的方法較簡單，該合并方法只使用3個操作：其中兩個是非常基本的集合操作，第3個是用來將兩個片段進(jìn)行交叉的操作。最后，該方法對所得到的完整的測試用例集進(jìn)行進(jìn)一步的處理，以消除其中重復(fù)的或不可能操作的測試用例。

（6）根據(jù)生成的測試用例就可以用來對數(shù)據(jù)填充模塊進(jìn)行集成測試，只要所有測試用例的實(shí)際輸出和期望輸出一樣，就可以說該模塊對于活動圖而言是正確的。

［1］梁利亭.基于UML的面向?qū)ο蟮能浖y試的研究與應(yīng)用［D］.南京理工大學(xué)碩士論文，2010.

TP

A

1673-0046（2011）03-0159-02