版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領
文檔簡介
基于活動圖的回歸測試研究摘要隨著信息技術的深入發(fā)展,社會的各個領域的信息電子化進程進行的非常迅速。許多系統(tǒng)都是非常復雜和龐大的,而且更新?lián)Q代的速度非常驚人。那么怎么保證這些系統(tǒng)是高效、安全、可靠的,軟件的回歸測試是非常必要的。但是回歸測試是一個成本昂貴的過程。而在回歸測試中回歸測試用例的選擇是最重要的一個步驟,如何選擇一個盡可能小并且又能覆蓋所有改變和影響的測試用例集來進行回歸測試用例選擇是一個重要的課題。本文對回歸測試選擇方法進行了研究,提出了基于UML活動圖的回歸測試用例選擇技術和基于風險的回歸測試選擇技術。這兩個技術是相輔相成的,能很好地完成回歸測試用例的選擇。主要研究容與成果包括以下幾個方面:1)分析了需求的可跟蹤性對于進行和管理回歸分析和測試的重要性。2)提出了一個基于活動圖的回歸測試選擇策略,用來選擇回歸測試用例。將需求里的功能特征一一對應到活動圖上,再通過活動圖很直觀地進行測試用例的選擇。3)分析和描述了在回歸測試中的風險分析,同時提供了風險敞口(RiskExposure)作為度量回歸測試用例集的質量的指標。提出了基于風險的回歸測試選擇技術,是基于活動圖的回歸選擇技術的有益補充。4)用一個股票交易系統(tǒng)作為實驗對象,驗證了我們提出的方法的有效性,高效性。關鍵詞:回歸測試,風險敞口,活動圖AbstractAlongwiththedeeplydevelopmentofinformationtechnology,lotsofindustrialandfinancialentitiesinvolveinformationtechnologyintotheirdailybusiness.Regressiontestingisessentialtoensuresoftwarequality.Atestteamappliesaregressiontestsuitetoensurethatnewormodifiedfeaturesdonotregress(makeworse)existingfeatures.Althoughexistingresearchhasaddressedmanyrelatedproblemsandputforwardsomesolutions,mostregressiontesttechniquesarecode-based.Code-basedregressiontestselectionisgoodforunittesting,butithasascalabilityproblem.Whenthesizeoftheobjectundertestgrows,itbecomeshardtomanageallrelevantRiskExposureinformationandtocreatecorrespondingtraceabilitymatricesforvalidationandcoverageassessment.Weproposeamethodforregressiontestselectionbasedonactivitydiagramandrisk.Therearetwomajorpartsofourwork:Weproposeandjustifyanewregressionteststrategybasedonactivitydiagram.Weprovidesystematicmethodsforselectingregressiontestcases.Weapplyregressionanalysistorequirementtocheckthroughoutconsistencyof“requirementfollowedbyablank”,anddesignmodels.Thebasicmodelweusefordescribingrequirementsbasedoncustomerfeaturesorbehaviorsistheactivitydiagram,whichisanotationoftheUML.Aprocessispresentedforidentifyingthetestcasesaffectedbychanges.Atthesametime,weuseriskanalysisandpresentamethodofchoosingrisk-basedtestcases.Ourriskanalysisisbasedonapracticalriskmodel,andissimilartothatusedbysomeorganizations.Keywords:Regressiontest,Activitydiagram,Riskexposure目錄摘要iAbstractii第1章緒論11.1課題背景11.2國外研究現(xiàn)狀與進展21.2.1以前相關研究21.2.2現(xiàn)存理論存在的問題41.3研究容和研究目標41.4本文結構組織5第2章回歸測試62.1引言62.2回歸分析和測試概念62.3回歸測試技術62.4回歸分析的討論72.5回歸測試模式92.6軟件維護的分類和回歸測試的類型102.7本章小結11第3章方法1:基于活動圖的回歸測試133.1引言133.2需求的可追溯性133.3UML的活動圖143.3.1活動圖的元素163.3.2活動圖和測試用例關系213.3.3簡化復雜的活動圖223.3.4基于活動圖設計測試用例233.4建立基于活動圖的需求可追溯性233.4.1需求測試,設計測試和活動圖263.4.2跟蹤測試用例到活動圖元素273.5基于活動圖進行測試用例的選擇303.5.1糾正性維護中測試用例的選擇303.5.2基礎:基于CFG的回歸測試選擇技術313.5.3基于活動圖的回歸測試選擇343.5.4糾正性和改進性維護同時發(fā)生時測試用例選擇353.6本章小結36第4章風險和風險分析374.1引言374.2風險性測試374.3風險分析374.4風險分析活動384.5一個實用的風險模型394.6本章小結40第5章方法2:基于風險的回歸測試415.1引言415.2基于風險的回歸測試方法415.3基于風險的回歸測試用例選擇技術425.3.1評估測試用例相對應的潛在的錯誤的成本(第1步)435.3.2評估每個測試用例嚴重度(第2步)485.3.3計算每個測試用例的風險敞口(第3步)495.3.4選擇測試用例作為基于風險的測試用例505.4本章總結51第6章實驗分析和比較526.1引言526.2實驗設計526.3實驗結果和分析54第7章結束語55參考文獻56作者簡歷59致60圖目錄TOC\h\z\c"圖"圖2.1回歸測試技術7圖2.2回歸測試用例選擇9圖3.1活動圖例子20圖3.2同步行為23圖3.3一個取得匯率報價的模塊的活動圖24圖3.4簡化后的活動圖25圖3.5建立需求特征和測試用例之間的可跟蹤的聯(lián)系26圖3.6需求特征和測試用例間的可跟蹤性的聯(lián)系鏈30圖3.7取得報價的功能模塊實施中發(fā)生錯誤和變化32圖3.8控制流圖C和改變后的C’33圖3.9圖4-5中的活動圖的改變35圖4.1風險分析活動39表目錄TOC\h\z\c"表"表3.1活動圖的標識 18表3.2從圖4-5得來的滿足節(jié)點和邊界覆蓋標準的測試集 25表3.3測試用例和活動圖元素 28表3.4對應測試用例的活動圖的可跟蹤性模型 29表3.5CFGC的測試集T的edge覆蓋模型 34表5.1一些測試用例的CC 45表5.2測試用例的CV值 47表5.3一些測試用例的成本 48表5.4測試用例的可能性嚴重度 49表5.5測試用例的風險敞口 50表5.6測試用例選擇 51表6.1原始測試用例規(guī)模 53表6.2原始和補充測試用例的規(guī)模 53表6.3完全測試時測試用例和錯誤規(guī)模 53表6.4幾種回歸測試的實驗數(shù)據(jù) 54表6.5幾種回歸測試的比較 54緒論課題背景隨著計算機技術、網(wǎng)絡技術的不斷發(fā)展,計算機應用的領域越來越廣,軟件系統(tǒng)功能越來越強大,其系統(tǒng)的規(guī)模也越來越大,越來越復雜。計算機已經普遍地應用在航空、航天、工業(yè)控制、金融、醫(yī)療、交通和電子商務等各個領域,這些軟件系統(tǒng)的運行是否正確,已經影響到社會生活得各個方面。一旦這些軟件失效,就會造成巨大的損失。尤其是這幾年,電子商務與金融產品的網(wǎng)上交易平臺等這些基于Web應用的系統(tǒng)的快速發(fā)展,軟件產品的一點瑕疵就可能導致客戶的巨額財產損失。軟件測試就是減少這種損失,保證軟件質量的重要手段。隨著人們對軟件測試的重要性的認識的不斷加深,軟件測試階段在整個軟件開發(fā)周期中所占得比重會日益增大。根據(jù)Boehm的統(tǒng)計,目前軟件測試在軟件開發(fā)中的總成本中,其開銷占到了30%~50%[1],在某些重大軟件項目占得比重更大?;貧w測試是軟件測試中一個很重要的環(huán)節(jié)。其目的是保證程序在修改后不會引入新的錯誤[2]。而隨著軟件規(guī)模的日益龐大,回歸測試的成本也相應增大,甚至達到整個測試成本的一半以上[3]。所以回歸測試成為整個軟件測試的關鍵,是軟件質量的重要保證。回歸測試可以重用以前的測試過程,是一種比較有效地測試方法。但是,回歸測試需要前期投入,如何減少回歸測試的代價,是整個軟件回歸測試研究的難點和重點。在所有的難點和重點中,回歸測試用例選擇(RegressionTestSelection)是重點中的重點?;貧w測試選擇是復用已有用例基進行測試的方法。其目的是選擇一個盡可能小并且又能覆蓋所有改變和影響的代碼的測試用例集。目前回歸測試選擇的研究,主要包括:1)基于代碼信息的回歸測試選擇。該方法主要研究在已知代碼的情況下,對代碼相關的用例進行選擇。2)基于歷史記錄的回歸測試選擇。該方法主要是根據(jù)測試的歷史記錄進行回歸測試選擇。統(tǒng)模語言(UML)在軟件工程發(fā)展進程中具有里程碑的意義,統(tǒng)模語言(UML)的正式發(fā)展是從1994年開始的,它匯集了近20多年來各種建模技術。自提出以來,后成為研究熱點,并且迅速在工業(yè)界得到廣泛的應用。UML對開發(fā)高質量軟件起了很大的促進作用,同時也給軟件測試以與回歸測試帶來新的研究領域。目前大多數(shù)回歸用例選擇技術多是基于代碼的,有些是基于歷史記錄的?;诖a的回歸測試選擇對測試人員要求很高,需要測試人員閱讀并理解代碼,這需要很多的時間花費,并且是依賴于編程語言的。而基于歷史記錄的回歸測試選擇要求測試的所有記錄非常完善,很多時候我們達不到要求。而基于UML設計的回歸測試選擇不依賴于編程語言,比代碼級的回歸測試選擇更加容易且效率高。所以本文吸收前人的研究成果,結合UML活動圖的特點,提出了基于UML活動圖的回歸測試選擇技術,為了對軟件質量更有信心,又提出了基于風險的回歸測試選擇技術,作為基于活動圖的回歸測試的有益補充。國外研究現(xiàn)狀與進展以前相關研究回歸測試作為軟件生命周期的一個組成部分,在整個軟件測試過程中占有很大的工作量比重,軟件開發(fā)的各個階段都會進行多次回歸測試。在漸進和快速迭代開發(fā)中,新版本的連續(xù)發(fā)布使回歸測試進行的更加頻繁,而在極端編程方法中,更是要求每天都進行若干次回歸測試。許多研究人員研究了回歸測試技術。他們的研究包含很廣泛的課題。例如,Brown和Hoffman[8]研究了測試環(huán)境和自動化回歸測試過程。Harrold,Gupta和Soffa[9]研究了測試用例管理技術。Rothermel和Harrold[10]研究了回歸測試選擇技術。最近幾年,大家的注意力被集中到回歸測試測試用例選擇領域。大部分的技術是針對白盒測試的,他們選擇測試用例是基于代碼的相關信息[11-12]。只有少數(shù)的技術是針對黑盒測試,測試用例選擇基于系統(tǒng)本身特征[13-16]。目前,回歸測試選擇的研究主要包括以下兩個方面:基于代碼的回歸測試選擇。該方法主要研究在已知代碼的情況下,對代碼相關的測試用例進行選擇。這個方法是通過比較修改前后對應代碼對基線測試用例進行選擇,從而得到回歸測試用例集的一種技術[28]。先采用一些分解術將復雜的程序分解成一個個相對較小的片段來進行分析和維護。這些片段就叫做程序切片。任何一個程序都可以等價于一組程序切片的并集,而這些切片都是根據(jù)某個切片變量和切片準則計算出來的。根據(jù)切片的定義:所有能夠影響到的語句、謂詞等都被包含到該切片變量的切片中了。所以對某個切片變量的修改一定不會影響到其他切片變量的切片。那么基于代碼方法的回歸測試思想可以描述如下:針對修改后的程序,首先找出被修改的變量信息,然后運用切片方法找到由于這些變量的變化所引起的直接定義一使用關系和間接定義一使用關系(通常是一些語句或者控制流和數(shù)據(jù)流信息),將這些信息提取出來,組成一個程序片段,設計測試用例對這些程序片段進行測試,最后把這些測試用例加人到原程序測試用例中,構成新的回歸測試用例集?;跉v史記錄的回歸測試選擇。就是以測試用例執(zhí)行的歷史記錄數(shù)據(jù)為依據(jù)進行回歸測試選擇[29]。每一輪測試都有一個測試狀態(tài)與之相對應,該測試狀態(tài),該測試狀態(tài)涵蓋了當前測試中影響策略選擇的因素,包括測試用例錯誤檢測率要求、測試成本、測試頻次。這些就是測試的歷史信息。基于這些測試歷史信息,并根據(jù)當前測試情況來選擇較為合適的回歸測試用例,再將生成的回歸測試用例進行用例優(yōu)先排序,最后利用排序后的用例來進行測試,以進一步提高回歸測試效率?,F(xiàn)存理論存在的問題對于基于代碼的回歸測試選擇技術來說存在一些問題?;诖a的回歸測試技術可以有效的應用到回歸測試中的單元級別。但是當我們試圖測試一個大的或更加復雜的組件,比如一個子系統(tǒng),我們要用基于代碼的回歸測試技術從代碼中取得所有所需信息就很困難,因此,基于代碼的回歸測試技術就很難適應較大的組件的測試,例如子系統(tǒng)的測試。而且,基于代碼的回歸測試技術需要測試人員在一定程度上進入和理解代碼[17]。這個需要就會產生一些實際的問題。測試人員不得不去花很多時間去讀懂代碼,而且對測試人員的要求會很高。這是很費時,高成本的方法。最后,基于代碼的回歸測試技術是有編程語言的限制。在一些軟件系統(tǒng)里面,會使用超過一種的編程語言,比如,在Web系統(tǒng)里,我們可能會用到Java,JSP,HTML等語言。這會導致分析代碼的過程非常復雜。同樣的對于基于歷史信息的回歸測試選擇技術也存在著一些問題。因為在這個選擇過程中完全是根據(jù)測試的歷史記錄來進行的,那么就必定要求這個歷史記錄是完整,正確的。但是,實際情況是,很多項目的測試歷史記錄是不完整的。研究容和研究目標在我們的研究中,我們提出采用基于活動圖的回歸測試選擇技術和基于風險的回歸測試選擇技術,作為有效和高效的解決以上所列問題的途徑。下面是本論文的主要工作:我們說明了需求可追溯性對于進行和管理回歸分析和測試的重要性。我們分析了在需求和測試用例之間的聯(lián)系。我們提供了一種新的選擇回歸測試用例的策略。我們的策略是基于活動圖的。將需求里的功能特征一一對應到活動圖上,再通過活動圖很直觀地進行測試用例的選擇。我們分析和描述了風險分析的用處,怎么使用風險敞口(RE)可以用來衡量回歸測試集的質量。提供了基于風險的回歸測試選擇技術,作為基于活動圖的回歸測試技術的有效補充。本文結構組織文章剩下部分組織結構如下:第二章:主要描述回歸測試的背景知識,相關技術。第三章:討論了建立基于活動圖的需求可跟蹤性的方法,在次基礎上建立了對回歸分析和選擇技術。第四章:討論了風險分析,給出一個實用的風險模式,可以在回歸分析中使用。第五章:討論了基于風險的回歸測試策略,并使用例子說明。第六章:用一個實驗來驗證我們提出的回歸測試方法。第七章:總結全文?;貧w測試引言Myers發(fā)現(xiàn)對已經存在的程序進行修改比整個系統(tǒng)重新進行編碼更容易產生bug[18]?;貧w測試是被用來確認被修復的bug已經真正的被修復了,同時在這個過程中沒有產生新的bug,系統(tǒng)的功能還要符合需求的規(guī)定?;貧w分析和測試概念回歸分析和測試是軟件系統(tǒng)發(fā)生改變后的一個軟件過程[19]?;貧w測試通常就是發(fā)生在被測試的系統(tǒng)發(fā)生改變時,原來的bug已經被完全修復,不會產生新的問題?;貧w測試和開發(fā)過程中的測試最主要的區(qū)別是回歸測試的測試用例集會不斷的重用。使用回歸測試選擇技術,我們僅僅重新運行被壓縮過的回歸測試用例,這些測試用例根據(jù)修改過的組件或系統(tǒng)而變化。如果選擇測試用例的代價少于重新測試所有測試用例的代價,那就說明測試用例選擇技術是經濟有效的[20]?;貧w測試技術Rothermel和Harrold在自己的研究中描述回歸測試技術如下所述[9]:程序P,修改后的程序p’,程序P的測試用例集T,回歸分析和測試技術就是讓T的子集能滿足程序P’的質量要求,而從p到P’的對應未改變部分功能不變?;貧w測試基本上包含下面幾個步驟:確定從P到P’的改變的容選擇子集T’∈T,T’是基于P到P’改變的測試集用T’測試P’,確認P’的正確性如果需要,建立T’’,是關于P’的新的功能的或架構的測試用例集用T’’測試P’,確認P’的準確性建立T’’’,是P’的回歸測試集,結合了T’和T’’。圖2.1回歸測試技術回歸分析的討論對僅僅發(fā)生少量變化的軟件系統(tǒng)進行完全的測試是很昂貴的行為,尤其是對于大型系統(tǒng)。利用回歸分析和測試,我們可以僅僅重新測試受到影響到得那部分軟件系統(tǒng)?;貧w分析和測試必須列出下面的這些基本問題[21]:怎么確定因為某些組件代碼的改變而受到影響的所有組件?要采取什么策略去重新測試這些受到影響的組件。對于這些重新測試的組件的覆蓋標準是什么?怎么選擇回歸測試用例或改變原來的測試用例?為了解決上述問題,對于回歸分析和測試策略,下列的行動是很重要的。下面是一個實用的回歸測試策略:確定被影響的組件和選擇回歸測試覆蓋標準。選擇測試用例去測試被影響的組件。執(zhí)行選擇好的測試用例。獲取和評估測試結果,包括評估發(fā)生改變的軟件系統(tǒng)的運行情況,報告回歸測試集的覆蓋率。修改測試計劃以符合下一個階段的回歸分析和測試。第2點是關于選擇測試用例去重新執(zhí)行的。這些被執(zhí)行的測試用例可能會是新的測試用例,當然也會有選出來的適當?shù)睦系臏y試用例。在我們的研究當中,我們僅僅關注從原來的完整測試集中選擇合適的測試用例的技術方法。Luiu將完整測試集中的測試用例分成兩類[19]:可以重新使用的測試用例:這些測試用例是用來測試沒有更改部分的規(guī)格說明和相應未改變部分的執(zhí)行。當規(guī)格說明和執(zhí)行改變后,這些測試用例都保持有效性,不需要重新運行。被影響到得測試用例:這些測試用例是同發(fā)生改變的那些規(guī)格說明和執(zhí)行相關的。它們有兩個分類:可以重新測試的測試用例:這些測試用例是依然有效,應當被重新執(zhí)行的。過時的測試用例:這些測試用例對于發(fā)生改變的規(guī)格說明和執(zhí)行已經是不相關或已經過時了。測試用例選擇過程圖2-2所示。圖2.2回歸測試用例選擇回歸測試模式RobertBinder總結當前的回歸測試選擇策略,分成三個模式[7]:再測試全部用例
:選擇基線測試用例庫中的全部測試用例組成回歸測試包,這是一種比較安全的方法,再測試全部用例具有最低的遺漏回歸錯誤的風險,但測試成本最高。全部再測試幾乎可以應用到任何情況下,基本上不需要進行分析和重新開發(fā),但是,隨著開發(fā)工作的進展,測試用例不斷增多,重復原先所有的測試將帶來很大的工作量,往往超出了我們的預算和進度。
基于操作剖面選擇測試:如果基線測試用例庫的測試用例是基于軟件操作剖面開發(fā)的,測試用例的分布情況反映了系統(tǒng)的實際使用情況?;貧w測試所使用的測試用例個數(shù)可以由測試預算確定,回歸測試可以優(yōu)先選擇那些針對最重要或最頻繁使用功能的測試用例,釋放和緩解最高級別的風險,有助于盡早發(fā)現(xiàn)那些對可靠性有最大影響的故障。這種方法可以在一個給定的預算下最有效的提高系統(tǒng)可靠性,但實施起來有一定的難度。再測試修改的部分:當測試者對修改的局部化有足夠的信心時,可以通過相依性分析識別軟件的修改情況并分析修改的影響,將回歸測試局限于被改變的模塊和它的接口上。通常,一個回歸錯誤一定涉與一個新的、修改的或刪除的代碼段。在允許的條件下,回歸測試盡可能覆蓋受到影響的部分。
再測試全部用例的策略是最安全的策略,但已經運行過許多次的回歸測試不太可能揭示新的錯誤,而且很多時候,由于時間、人員、設備和經費的原因,不允許選擇再測試全部用例的回歸測試策略,此時,可以選擇適當?shù)牟呗赃M行縮減的回歸測試。
每種回歸測試模式都有其優(yōu)點和缺點。一種模式可能在某些情況下比另一種好,但是并不是在所有情況下都好。軟件維護的分類和回歸測試的類型在軟件開發(fā)和維護階段,當軟件進行打補丁,升級或微調時,軟件系統(tǒng)可能會發(fā)生許多變化。根據(jù)軟件維護預期目的的不同,White將軟件維護分成三類[22]:糾錯性維護(Correctivemaintenance):糾錯性維護是為診斷和改正軟件系統(tǒng)中潛藏的錯誤而進行的活動。由于軟件測試不可能排除大型軟件系統(tǒng)中所有的錯誤,測試階段隱藏下來的軟件錯誤,有可能在軟件投入實際運行之后,才逐步暴露出來并造成系統(tǒng)故障。軟件交付使用后,用戶將成為新的測試人員,在使用過程中,一旦發(fā)現(xiàn)錯誤,他們會向開發(fā)人員報告并要求維護。適應性維護(AdaptiveMaintenance):適應性維護是為使軟件系統(tǒng)適應不斷變化的運行環(huán)境而進行修改的活動。一般應用軟件的使用壽命很容易超過十年(比如,波音公司的CobolOS/VS已經運行了22年),但其運行環(huán)境卻更新很快。近年來,硬件基本是一年半一代,操作系統(tǒng)的版本也在不斷地更新,外部設備,外存儲器和其他系統(tǒng)元素也頻繁地升級和變化,因此為了使老的軟件能夠在新的運行環(huán)境下正常工作,適應性維護是必須且經常發(fā)生的。完善性維護(PerfectiveMaintenance):完善性維護是根據(jù)用戶在使用過程中提出的一些建設性意見而進行的維護活動。在一個應用軟件成功運行期間,用戶也可能請求增加新功能、建議修改已有功能或提出某些改進意見,以便使軟件的功能和質量得到進一步的完善。軟件的版本更新就是完善性維護的一種。完善性維護是軟件維護的主要部分,通常占所有軟件維護工作量的一半以上。在適應性維護和完善性維護階段里,軟件系統(tǒng)的變化是由于用戶需求或者系統(tǒng)的規(guī)格說明的變化。經常是增加了新的功能。這兩種維護中發(fā)生的變化同開發(fā)階段發(fā)生的變化很類似。Leung和White稱適應性維護和完善性維護都被認為是改進性的維護(ProgressiveMaintenance)基于上面的分類,我們可以將回歸測試分成兩類:糾錯性回歸測試:就是在糾錯性維護后進行的回歸測試,這時軟件系統(tǒng)的需求規(guī)格說明沒有發(fā)生變化。改進性回歸測試:就是在改進性維護后進行的回歸測試,這時相應的需求規(guī)格說明已經發(fā)生變化。在論文里,我們的討論主要針對這個分類展開。本章小結在這章中,我們提供了回歸分析和測試的背景信息,列出了一般的回歸測試模式。同時也將軟件系統(tǒng)的改變,回歸測試進行了分類。方法1:基于活動圖的回歸測試引言軟件的規(guī)說明階段(specificationphase)對于軟件的整體開發(fā)過程來說是一個非常重要的階段,UML方法是目前比較流行的軟件工程開發(fā)方法,它對軟件整體開發(fā)過程提供了一套有用的模型。在我們的研究中,我們使用UML中的活動圖作為需求分析和設計的工具,尤其是作為工作流的標記。設計測試用例是基于活動圖,這些活動圖來自設計文檔。我們的方法是基于項目文檔,包括設計文檔,系統(tǒng)變化的歷史文檔,測試執(zhí)行的log記錄。如果這些文檔是不完全或不正確的,我們的方法不可能覆蓋所有可能的變化。需求的可追溯性測試人員的任務是在產品中發(fā)現(xiàn)高優(yōu)先級的問題。風險是問題可能發(fā)生的衡量。問題越可能發(fā)生,問題發(fā)生后的影響越大,那么風險級別越高。風險是所有測試的動力所在。從某種意義上說,沒有風險就沒有測試,就像沒有空氣就沒有生命一樣。在第2章中,我們已經指出任何回歸分析和測試策略中我們首先要做的是識別出受系統(tǒng)變化影響的組件。在糾正性維護中,我們可以通過哪些組件里的代碼發(fā)生變化來識別哪些組件受到影響。對于改進性維護,因為系統(tǒng)的變化是因為需求或者是規(guī)說明的變化,我們需要明白需求,規(guī)說明和系統(tǒng)行為之間的聯(lián)系,以識別受到影響的組件。然后,當在第一步中識別出哪些組件受到影響后,我們在第2步中選擇測試這些組件的回歸測試用例。要清楚這些組件和測試用例之間的聯(lián)系。關于需求的可追溯性,簡單的,普遍的觀點是通過記賬的方法,這可以防止很多問題[7]。需求的可追溯性是為了找出因為需求變化受到影響的組件和選擇出相應的測試用例的一個基本要求?!靶枨蟮目勺匪菪浴边@個專用名詞最初是來自美國國防部。需求的可追溯性的一個普遍可以接受的定義是:描述和跟蹤需求的整個生命的能力,包括向前的和向后的方向[24]。也就是說,可追溯性是這么一種能力:跟隨需求從最原始狀態(tài),經過它們的規(guī)說明和開發(fā),到產品的隨后的開發(fā)和使用,再通過一段時間的不斷完善,當然也包括在這些階段中任何一個遍歷過程。需求的可追溯性已經廣泛被認為是有效的軟件項目管理和軟件質量保證的一個重要因素。在過去幾年中,軟件需求可追溯性的研究還是挺多的。許多可追溯性的模式被提了出來。根據(jù)Spanoudaki的說法[25],需求的可追溯性可以被用到:協(xié)助驗證系統(tǒng)滿足需求的要求。確認軟件需求說明變化的影響。記錄和理解各種文檔的變化過程。上面的需求的可追溯性的第2點用處剛好很好地滿足我們的情況。我們用它來解決回歸分析和測試的第一個問題:識別受到影響的組件。從用戶需求到軟件產品的第一個Release,一個軟件開發(fā)過程通常包含四個主要階段:需求分析,設計,實施,測試。結果是,系統(tǒng)的相關信息轉化成不同的形式和在不同階段的不同代碼。我們使用UML的活動圖區(qū)描述我們研究中的分析和設計模式。UML的活動圖活動圖是UML用于對系統(tǒng)的動態(tài)行為建模的一種常用工具。統(tǒng)模語言(UML是UnifiedModelingLanguage的縮寫)是用來對軟件密集系統(tǒng)進行可視化建模的一種語言。UML為面向對象開發(fā)系統(tǒng)的產品進行說明、可視化、和編制文檔的一種標準語言。統(tǒng)模語言(UML)是非專利的第三代建模和規(guī)約語言。UML是在開發(fā)階段,說明,可視化,構建和書寫一個面向對象軟件密集系統(tǒng)的制品的開放方法。UML展現(xiàn)了一系列最佳工程實踐,這些最佳實踐在對大規(guī)模,復雜系統(tǒng)進行建模方面,特別是在軟件架構層次已經被驗證有效。UML可以貫穿軟件開發(fā)周期中的每一個階段。被OMG采納作為業(yè)界的標準。UML最適于數(shù)據(jù)建模,業(yè)務建模,對象建模,組件建模。UML作為一種模型語言,它使開發(fā)人員專注于建立產品的模型和結構,而不是選用什么程序語言和算法實現(xiàn)。當模型建立之后,模型可以被UML工具轉化成指定的程序語言代碼。UML活動圖是UML語言中描述系統(tǒng)動態(tài)行為的一種方法,它廣泛地運用于業(yè)務建模。它描述活動的順序,展現(xiàn)從一個活動到另一個活動的控制流?;顒訄D在本質上是一種流程圖?;顒訄D的應用非常廣泛,它既可以用來描述操作(類的方法)的行為,也可以描述用例和對象部的工作過程?;顒訄D是由狀態(tài)圖變化而來的,他們各自用于不同的目的。活動圖中一個活動結束后立即進入下一個活動。活動圖用途與優(yōu)缺點:活動圖用于對系統(tǒng)的動態(tài)行為建模,它是系統(tǒng)行為狀態(tài)的一種可視化形式。另一種可視化形式是狀態(tài)圖?;顒訄D描述了從活動到活動的流,活動是狀態(tài)機中進行的非原子操作?;顒訄D實際上是狀態(tài)圖的特殊形式,它的每個狀態(tài)都有入口動作,用以說明進入該狀態(tài)發(fā)生的操作。優(yōu)點:最適合支持并行行為,而且也是支持多線程編程的有力工具。缺點:很難清楚地描述動作與對象之間的關系?;顒訄D有很多作用:分析用例:在項目中,我們需要理解什么行為會發(fā)生,按照什么順序發(fā)生等等。理解工作流:即使我們在深入了解用例前,我們可以協(xié)同商業(yè)專家畫出活動圖,理解業(yè)務流程與其如何變化的。描述一個復雜的連續(xù)的運算法則處理多線程應用:活動圖有一系列的元素去描述多線程應用的系統(tǒng)行為。許多公司,比如IBM公司多年前就開始在系統(tǒng)設計中使用活動圖。它是描述系統(tǒng)行為和工作流的很有力工具。許多研究人員錯誤理解活動圖的概念,覺得它僅僅就是一個控制流圖(ControlFlowGraph(CFG))。但是實際上,活動圖不僅僅是控制流圖。有如下兩個原因:活動圖可以用來表達控制流和數(shù)據(jù)流,但是CFG僅僅可以用來表達控制流?;顒訄D可以用來表達大型系統(tǒng),而CFG不能表達大型系統(tǒng)。在我們的研究中,我們使用活動圖來詳細描述系統(tǒng)的需求,以達到回歸分析的目的。因為在面向對象開發(fā)過程中,需求分析和設計工作有時候相互混合在一起,所以活動圖,作為分析和設計階段的成果,可以比最原始的需求包含更多的信息。活動圖的元素一個活動圖的核心標志是活動狀態(tài)或者說是簡單的活動。一個活動就是做某個事情的狀態(tài)。它可以是真實的過程,比如打印一個字母,或者是執(zhí)行一個軟件程序,比如是執(zhí)行一個類的方法[26]。一個活動圖可能包括以下元素:活動(Activity):由人或者軟件系統(tǒng)做的一個任務。在活動圖中,同步線程也可以被叫做同步活動(SynchActivity)。子活動(Sub-activity):就是一個活動下來可以有幾個同步的進程,每個進程叫做子活動。起點(StartMarker):活動圖的人口(最開始的狀態(tài))。每個活動圖只有一個起點。終點(StopMarker):標志活動圖的出口(最終的狀態(tài))。每個活動圖只有一個終點。決策點(DecisionPoint):通過條件來判定該走那條分支同步示意條(SynchronizationBar):同步示意條是用于顯示平行分支流。同步示意條能夠顯示業(yè)務用例的工作流程中的并行線程。信號發(fā)射(SignalSender):當前面的活動終止,指定的信號發(fā)射。信號接收(SignalReceiver):當信號被接收,后續(xù)的活動才能被激活。轉移(Transition):表示各種活動狀態(tài)的先后順序。這種轉移可稱為完成轉移。它不同于一般的轉移,因為它不需要明顯的觸發(fā)器事件,而是通過完成活動(用活動狀態(tài)表示)來觸發(fā)。防衛(wèi)條件(GuardCondition):防衛(wèi)條件可以在轉移上指定,以限制該轉移的使用。將條件放在轉移箭頭附近的方框中。在你可以遵循相關的轉移進入下一個活動前,該條件的測試必須為真。對象(Object):對象是系統(tǒng)中相互關系的參與者。對象可能是一個組件,一個子系統(tǒng),也可能是外面系統(tǒng)的接口。信息(Message):一些發(fā)送到對象的或者從對象中發(fā)出的信息。泳道和時標:活動圖中泳道區(qū)分了其中活動的不同職責,在泳道圖中,每一個活動都只能明確地屬于一個泳道。泳道和時標相組合的方法:橫向按時標分組;縱向按泳道分組?;顒訄D主要元素的圖標列在表3-1中。表3.1活動圖的標識活動圖描述活動的先后順序。這種技術對于熟悉軟件開發(fā)和測試的人員來說同流程圖非常相似??梢员挥脕砻枋鱿到y(tǒng)運行中的基本流,備選流和額外流?;顒訄D既支持條件行為,也支持并行行為:條件行為用分支(Branch)和融合(Merge)表示分支:一個分支有一個單獨的進來的轉移和幾個出來的轉移。用If/Else條件來控制分支的進行。融合:一個融合有多個進入的轉移和一個出來的轉移。它標志著用分支標識的條件行為的結束。并行行為用分叉(Fork)和會和(Join)表示分叉:一個分叉有一個進入的轉移和幾個出來的轉移。當這個進來的轉移被觸發(fā),所有的出來的轉移都并發(fā)進行。會和:一個回合有多個進去的轉移和一個出來的轉移。只有當所有的進去的轉移都完成他們的行為,出來的轉移才會進行。圖3-1是一個簡單的活動圖的例子。描述的是航空公司的一個簡單的訂票系統(tǒng)的系統(tǒng)行為。實心圓表示活動圖的起點,實際上是一個占位符,帶邊框的實心圓表示終點。圓角矩形表示執(zhí)行的過程或活動。菱形表示判定點,雖然在此示例中判定點只有兩種可能結果;但即使有更多可能結果,它也同樣容易。箭頭表示活動之間的轉換,各種活動之間的流動次序。箭頭上的文字表示繼續(xù)轉換所必須滿足的條件,總是使用格式“[條件]”來描述。粗線條表示可能會并行進行的過程的開始和結束。圖3.1活動圖例子在這個例子中,消費者可以用已經存在的系統(tǒng)賬戶預定機票,也可以在沒有系統(tǒng)賬戶的情況下單獨定票。如圖3-1所示,在收到訂單后,下面是一個分支。如果這個訂單是個預定,系統(tǒng)會根據(jù)消費者的賬戶信息找到指定銀行賬號,用這個銀行賬號支付相應的訂單的數(shù)額,同時會在這個賬戶上增加獎勵的點數(shù)。如果是個無賬戶的單獨的訂票,會隨著訂單出來需要支付的信息,客戶再去支付。在預定過程中,系統(tǒng)會并行處理支付和獎勵點數(shù)的行為。因此,這是個同步行為,就是fork。下面是一個join。系統(tǒng)是預定和單獨訂單后的共同行為,當消費者填完訂單后都會到系統(tǒng)。這里就是一個融合(Merge)。因為系統(tǒng)必須跟蹤沒一個訂單,所以消息就被發(fā)送到對象LogFile中。UML活動圖記錄單個操作或方法的邏輯、單個用例或商業(yè)過程的邏輯流程。在很多方面,活動圖是結構化開發(fā)中流程圖和數(shù)據(jù)流程圖(DFD)的面向對象等同體。活動圖和測試用例關系在基于需求規(guī)說明的測試中,測試用例是基于需求規(guī)說明設計出來的,而需求規(guī)說明是需求分析和設計階段的成果。作為需求和設計文檔的一部分,活動圖給開發(fā)人員詳細的設計和實施信息,同時給測試人員提供基于規(guī)說明的測試用例的準備材料。在我們的研究當中,我們主要關注的是活動圖和測試用例之間的關系,而且我們利用這種關系到回歸測試選擇中。一個圖可以通過兩個簡單的結構來表現(xiàn)對象間的關系:節(jié)點和邊界。節(jié)點通過邊界連接其他節(jié)點。一個圖的節(jié)點和邊界表達一種關系,這是另外一種簡單但有力的數(shù)學概念?;顒訄D可以看成這么一種圖,它可以表達許多東西,尤其是控制流關系,因此也為設計測試提供豐富的信息。在我們的研究中,活動圖的元素可以分成節(jié)點和邊界兩類。節(jié)點(Nodes):在活動圖中,一個節(jié)點用一個圓角矩形表示。一個節(jié)點可能連接到其他圖形元素也可能是單獨的。在活動圖中的標記:起點和終點,活動,決策點,同步條,對象,信號發(fā)送,信號接收。邊界(Edges):在節(jié)點間的抽象的連接。在活動圖中的標記:轉移和消息當要準備基于需求規(guī)說明的測試用例時,我們要么基于活動圖進行設計,要么基于需求的文檔。在這章中,我們假定我們的測試用例都是基于活動圖來設計的。 每個測試用例設計出來都是有一定得測試目的。一個測試目的可能與控制流,數(shù)據(jù)流相關?;诨顒訄D設計測試用例,我們就可以通過圖中特定的活動或路徑來表示一定得功能。圖形化工具的使用,我們可以很直觀地了解整個系統(tǒng)的運行情況。在一個圖中,我們可以看到很多路徑,每個測試目的對應一條路徑?;谔囟康牡臏y試用例可能會覆蓋到同一條路徑,但是可能會產生不同的測試數(shù)據(jù)。在設計測試用例時,我們總是應用一個或多個測試策略,定義合適的測試覆蓋標準。一個測試覆蓋標準是軟件測試完整性的衡量標準。Binder總結了對應每一個UML圖的測試策略,提供了完整的供參考的UML圖和測試設計步驟[7]。我們在本文中不討論基于活動圖的測試用例設計過程。簡化復雜的活動圖在一個程序流程中,有時會有很多并行的行為,會導致路徑太多,所以我們引入同步行為的概念,來簡化復雜的活動圖,以便于以后的測試用例選擇。同步行為是存在于同步配對之間的行為,同步配對是指一個fork,一個Join。圖3-2中的虛線框表示的是圖3-1中系統(tǒng)中的同步行為。為了識別這些路徑,我們在圖中標識了所有節(jié)點。邊界可以用下面的表示方法:Edge=(S,D)S表示這個Edge來自哪個節(jié)點,D表示這個節(jié)點的目的地。對于同步行為,一旦系統(tǒng)到達同步fork的時候,所有在fork和它對應的join之間的行為都在同步進行,直到下一個出來的行為被激發(fā)。這些同步線程執(zhí)行是由在執(zhí)行的系統(tǒng)控制。所以在執(zhí)行虛線盒里面的測試用例總是執(zhí)行盒所有的行為,不受測試人員的控制。測試人員通常采用“/”表示同步行為。例如在這個例子中,我們使用a,bc/d,e來表示這個過程的路徑。因為在虛線框中的部分是不受控制的,所以最好的一個方法是將整個虛線框中的部分當成一個節(jié)點(node)。我們將這種框叫做同步框(SynchronizationBox)。圖3-3是一個活動圖,這個活動圖描述的是一個外匯系統(tǒng)里的一個查詢報價功能塊。我們用它來進行基于活動圖的測試用例設計,回歸分析和測試。這是個在線外匯交易系統(tǒng)。這個系統(tǒng)幫助用戶去進行加拿大元和美元之間的交換。這個活動圖描述的是這個交換系統(tǒng)從多個銀行取得當前匯率的值。先發(fā)請求,圖中我們可以看到同步發(fā)了3個請求到3個銀行。我們將這幾個請求定義為3個節(jié)點(node):d1,d2,d3。圖3.2同步行為當我們使用同步框d去表示當前的3個同步線程(d1,d2,d3)。那么活動圖3-3就簡化成了圖3-4?;诨顒訄D設計測試用例在我們的例子中,我們基于圖3-4設計了5個測試用例,都列在表3-2中。在測試集中,每個測試用例都對應一個從起點到終點的路徑,都測試一個特定的系統(tǒng)功能。這個測試集覆蓋了圖中所有的node和edge,滿足了我們基于規(guī)說明的測試覆蓋標準,我們稱之為節(jié)點和邊界覆蓋標準。建立基于活動圖的需求可追溯性我們已經詳細討論了在回歸分析和測試中需求的可追溯性的所處的角色,上節(jié)還詳細描述了活動圖。在本節(jié)中,我們提供了基于活動圖,獲取需求可追溯性的方法。圖3.3一個取得匯率報價的模塊的活動圖圖3.4簡化后的活動圖表3.2從圖3-4得來的滿足節(jié)點和邊界覆蓋標準的測試集TestCasePatht1a,b,c,d,e,f,g,h,it2a,b,c,d,e,j,k,e,f,g,h,it3a,b,c,d,e,j,k,e,j,f,g,h,it4a,b,c,d,e,j,k,e,j,e,k,e,f,g,h,it5a,b,c,l,m需求測試,設計測試和活動圖在開發(fā)的不同階段,我們可以用不同的標識來表示系統(tǒng)的不同階段。在我們的方法中,我們使用活動圖來表示理想的系統(tǒng)行為。需求測試需求分析的目的是準確地,清楚地定義要解決的問題。因此,需求測試的目標是驗證每個分析階段的結果。測試需求包括下面3個方面的基本問題[27]:正確性:需求必須清楚地表達客戶的真實意愿。分析需求必須確保不會有歧義的單詞出現(xiàn)在需求文檔。需求的正確性是系統(tǒng)設計的基本前提。完整性:需求必須滿足客戶的所有希望的需求,當然不能超出條件許可圍。一致性:一個很普遍的情況是在需求中會出現(xiàn)很多先后沖突的需求,或者是冗余的需求。這些不一致的需求和冗余的需求在需求測試階段必須就被抓出來,并被消除,避免后續(xù)的系統(tǒng)設計階段的問題。需求測試最主要的可接受的標準是用戶滿意度。但是,需求必須符合項目開發(fā)時間和預算的要求。一旦客戶同意這個需求,就到了設計階段。設計測試在系統(tǒng)設計階段,設計人員要嘗試找出解決在需求階段提出的問題。他們的目標是使用一系列的工具和語言產生一個完整的系統(tǒng)規(guī)說明。設計階段是需求分析階段的后續(xù)階段,將需求的要求完整地轉換成一個完整的計劃,以進行后續(xù)的實施階段?;谠O計階段的成果,有5個主要的目標需要測試[27]:一致性:非一致性的設計是后續(xù)階段主要的錯誤來源,會成為軟件維護階段的噩夢。因此,測試設計的第一個目標是消除非一致性。完整性:一個好的設計的重要特征是提供一個完整的解決方案解決所有問題。在設計測試階段,測試人員必須保證設計不僅符合需求的功能性,還要符合需求的性能要求。適用性:對于一個項目來說,時間和預算總是有限的。一個好的設計必須可以在有限的時間和預算中實施。正確性:設計中必須解決這個問題。就是說輸入和輸出結果是正確的??筛櫺裕何覀儽仨氄f明可跟蹤性是保證軟件質量的重要性。設計的可跟蹤性同樣是一個項目的可跟蹤性中的重要組成部分。為了測試可跟蹤性,測試人員必須找到設計階段的前后關聯(lián)。設計一個面向對象的軟件系統(tǒng)在系統(tǒng)發(fā)布前都不會完結。在進行下一個階段之前,必須達到下面兩個方面的標準:開發(fā)團隊必須有足夠的信心根據(jù)設計的架構將系統(tǒng)開發(fā)出來,同時要充分考慮到存在的風險。測試團隊必須有足夠的信心設計的測試集是完整的,一致的和正確的。完整性:測試集覆蓋了系統(tǒng)所有的需求要求。一致性:對于同一個需求點,不會有兩個互相沖突的測試用例。正確性:正確的輸入會有正確的輸出。活動圖是項目實施和測試用例設計的基礎?;顒訄D是需求分析和系統(tǒng)設計階段的成果的一部分。我們假設無論是需求測試還是設計測試都完成得很好,通過了所有的可接受的標準。但是,安全起見,我們規(guī)定了如下的假設:假設:我們假設活動圖已經被基線測試檢測過了。這些活動圖已經正確地,完全地,一致地,可行地表現(xiàn)了系統(tǒng)的規(guī)說明。甚至,它們也是可跟蹤的?;顒訄D的各個元素可以一一映射到項目需求的每個特征。跟蹤測試用例到活動圖元素在需求和測試用例之間建立聯(lián)系的目的是抓住需求特征和測試用例之間的關系。換句話說,就是我們必須設計測試用例用來測試需求的每個點。在我們的活動圖假定中,我們假設活動圖的每個元素都一一映射到每個需求特征。如果我們找到一個方法可以去跟蹤測試用例到活動圖各個元素的關系,那么我們就可以建立需求特征和測試用例之間的聯(lián)系。(看圖3-5)。圖3-5:建立需求特征和測試用例之間的可追溯性的聯(lián)系當我們設計測試用例時,我們列出了對應每個測試用例的路徑。一個路徑就是相關聯(lián)的一系列活動圖元素。因此,我們說測試用例是用來測試相關的一系列活動圖元素的。在我們的方法中,我們建立了可跟蹤性模型來發(fā)現(xiàn)測試用例和活動圖元素之間的關系。我們已經列出了表3-2中每個測試用例對應圖3-5中的路徑。對于每個測試用例,我們可以識別出所有的node和edge。這可以看表3-3:表3-3:測試用例和活動圖元素TestCaseNodeCoveredEdgesCoveredt1a,b,c,d,e,f,g,h,i(a,b),(b,c),(c,d),(d,e),(e,f),(f,g),(g,h),(h,i)t2a,b,c,d,e,j,k,e,f,g,h,i(a,b),(b,c),(c,d),(d,e),(e,j),(j,k),(k,e),(e,f),(f,g),(g,h),(h,i)t3a,b,c,d,e,j,k,e,j,f,g,h,i(a,b),(b,c),(c,d),(d,e),(e,j),(j,k),(k,e),(j,f),(f,g),(g,h),(h,i)t4a,b,c,d,e,j,k,e,j,f,g,h,i(a,b),(b,c),(c,d),(d,e),(e,j),(j,k),(k,e),(j,f),(f,g),(g,h),(h,i)t5a,b,c,l,m(a,b),(b,c),(c,l),(l,m)通過將表3-3中的信息重新排列,我們建立了一個測試用例可追溯性模型,用來顯示和檢查測試用例和活動圖元素之間的聯(lián)系。在這個模型中,測試用例作為因變數(shù)。對于每個node和edge,我們列出了相對應的測試用例。例如,對于nodej,測試用例t2,t3,t4相對應。表3-4:對應測試用例的活動圖的可追溯性NodeTestCaseEdgeTestCaseat1,t2,t3,t4,t5(a,b)t1,t2,t3,t4,t5bt1,t2,t3,t4,t5(b,c)t1,t2,t3,t4,t5ct1,t2,t3,t4,t5(c,d)t1,t2,t3,t4dt1,t2,t3,t4(c,l)t5et1,t2,t3,t4(d,e)t1,t2,t3,t4ft1,t2,t3,t4(e,f)t1,t2gt1,t2,t3,t4(e,j)t2,t3,t4ht1,t2,t3,t4(f,g)t1,t2,t3,t4it1,t2,t3,t4(g,h)t1,t2,t3,t4jt2,t3,t4(h,i)t1,t2,t3,t4kt2,t3,t4(j,f)t3,t4lt5(j,k)t2,t3,t4mt5(k,e)t2,t3,t4(l,m)t5這個模型提供了測試用例和活動圖元素間的聯(lián)系。如圖3-6所示。在本文中,我們用這個模型來進行回歸分析。這種可跟蹤性也提供了對于所有的需求特征的一種可檢測性。在最近幾年,出現(xiàn)了需求的“可檢測性(testability)”這個名詞,慢慢地也被廣泛地接受。需求的可檢測性表示每個需求特征擁有至少一個測試用例。我們在需求特征和測試用例之間建立的聯(lián)系可以作為需求的可檢測性的依據(jù)。從另一方面,我們也可以說一個測試用例必須對應至少一個需求特征。圖3-6:需求特征和測試用例間的可跟蹤性的聯(lián)系鏈基于活動圖進行測試用例的選擇在這節(jié)中,我們討論基于活動圖進行測試用例的選擇。我們在節(jié)2.4中指出,在分析軟件系統(tǒng)中的改變,Leung和White認為只有兩種類型的改變[22]:糾正性維護和改進性維護。在糾正性維護中,改變僅僅發(fā)生在實施階段,而不影響需求規(guī)說明,也就是說在這個階段活動圖不改變。在改進性維護中,改變發(fā)生在需求或設計中,活動圖會發(fā)生相應的變化。對于僅僅是代碼發(fā)生變化,我們假設活動圖保持不變。我們會在下一節(jié)描述這個假設。糾正性維護中測試用例的選擇就像2.4節(jié)指出的那樣,糾正性維護并不會影響規(guī)說明(需求)。這種維護經常發(fā)生在開發(fā)階段,比如說,開發(fā)人員修復錯誤,他們通常只是改變下代碼,不會對規(guī)說明有什么影響。在這種情況下,原來的系統(tǒng)行為(需求和規(guī)說明)不會發(fā)生改變。因此,這種時候不用改變活動圖。但是,有時候,代碼改變會對系統(tǒng)行為產生極影響,這種影響必須被記錄下來。對于大部分的開發(fā)人員,任何代碼上的變化都必須在代碼變化歷史記錄文檔中被記錄下來。在我們的方法中,如果這個變化影響到活動圖中的node和edge,我們就必須在活動圖中有所體現(xiàn)。對于測試人員,我們必須在測試用例和錯誤歷史記錄中建立可追溯性。我們稱之為測試檔案。在我們的方法中,每個錯誤必須對應相應的活動圖元素(node和edge)。實際上,開發(fā)人員可能錯過許多錯誤,代碼改變歷史文檔也可能是不完整的。在我們的方法中,測試人員選擇回歸測試用例不僅僅可以依賴開發(fā)人員的文檔,而且可以依據(jù)測試人員自己寫的測試檔案。舉個例子來說,在圖3-7中,一個錯誤發(fā)生在節(jié)點K上,還有一些改變發(fā)生在邊界edge(c,l)上。從表3-4可以看出,我們知道測試用例t2,t3,t4對應節(jié)點K,測試用例t5與edge(c,l)關聯(lián)。因此,測試用例t2,t3,t4,t5必須被選擇到回歸測試集中。我們知道活動圖概念是來自流程圖。所以活動圖支持所有流程圖中的元素。在控制流圖(CFG)中,node是用來表示狀態(tài)的,而edge是用來表示過程中狀態(tài)間的控制流的。我們畫了個簡單的控制流圖,看圖3-8。比較圖3-5和圖3-8,我們會發(fā)現(xiàn)活動圖和控制流圖是很類似的?;A:基于CFG的回歸測試選擇技術本文中基于活動圖的回歸測試技術是由基于CFG的回歸測試選擇方法變化而來的。Rothermel,Harrold,Dedhia研究出了基于CFG的回歸測試選擇方法。他們使用CFG表現(xiàn)程序P和后續(xù)版本P’,同時使用edge作為潛在的受影響的實體[11]。通過比較程序P的CFG和程序P’的CFG,受影響的實體就被選擇出來了。在圖3-8中,我們有控制流圖C和改變后的版本C’。在C’中,一個node4a已經被插入,還有edge(6,2)已經被改變?yōu)閑dge(6.3)。當程序到達node3時,我們發(fā)現(xiàn)分支“T”后的目標變了。當程序到達node6后,我們發(fā)現(xiàn)后續(xù)的node從2變成了3。因此,我們將edge(6,2)加入已經發(fā)生變化的實體??赡苓€有其他的額外的變化發(fā)生在在這個路徑中,但是我們目前先不考慮。當所有的受影響的edge被識別出來后,可以用這些來指導測試用例的選擇。圖3-7:取得報價的功能模塊實施中發(fā)生錯誤和變化舉個例子,看圖3-8,假設C有一個測試集T,T中包含測試用例t1,t2,t3。對于這個測試集的edge覆蓋模型如表3-5所示。我們發(fā)現(xiàn)edge覆蓋模型很像表3-4所示的可跟蹤性模型。圖3-8:控制流圖C和改變后的C’使用這個edge覆蓋模型,我們可以很容易地選擇出相應的回歸測試用例。在我們的例子中,受影響的實體是edge(3,4)和edge(6,2),所以測試用例t1和t2應該被加入回歸測試用例集中。我們采用這個方法去實施在活動圖基礎上的回歸分析。表3-5:CFGC的測試集T的edge覆蓋模型EdgeTestCase(entry,1)(1,2)t1,t2,t3(2,3)(3,4)(4,exit)t1,t2(3,5)(5,6)(6,2)t2(2,7)(7,8)(8,exit)t3基于活動圖的回歸測試選擇我們的回歸測試選擇技術是基于活動圖。因為活動圖與CFG是非常類似,我們使用基于CFG的算法來分析基于活動圖的回歸測試選擇技術。像先前的描述基于CFG的技術,我們的技術也有兩個主要的步驟。首先是我們通過活動圖來辨識那些edge受到影響。然后我們選擇這些與受到影響的edge相關的測試用例。將這些測試用例收集好加入到我們的回歸測試用例集中。有個活動圖A,A的改變版本A’。取得回歸測試用例的方法如下: 第1步.獲取受影響的實體集從A和A’的起點開始,比較兩個圖中的路徑。發(fā)現(xiàn)有什么不同,當出現(xiàn)edge的出口有不同的目標時,將A中的這個edge加入到受影響的實體集中。比較所有的路徑,將發(fā)現(xiàn)的所有受影響的edge加入到受影響的實體集中。 第2步.選擇目標性測試用例對于每一個受影響的實體,研究可跟蹤性模型,選擇相應的測試用例作為回歸測試用例。圖3-9是一個簡單的例子。規(guī)說明或者需求的改變使得圖3-4中的活動圖發(fā)生了改變,變成了圖3-9中的活動圖。edge(j,f)改變成edge(j,n)。從A和A’的起點開始,我們從各個路徑開始比較兩個活動圖。當?shù)竭_nodeJ時,我們發(fā)現(xiàn)j的目標發(fā)生了變化。所以我們將edge(j,f)加入到受影響的實體集中。沒有其他的受影響的edge被發(fā)現(xiàn)。從表3-4中,我們發(fā)現(xiàn)測試用例t3和t4覆蓋edge(j,f)。因此,測試用例t3和t4被加入到回歸測試用例集中。通過以上的方法,我們選擇測試用例到回歸測試用例集中。糾正性和改進性維護同時發(fā)生時測試用例選擇實際上,糾正性維護和改進性維護可能有時會同時發(fā)生。在這種情況下,相應的活動圖會發(fā)生改變,活動圖中許多node和edge都會發(fā)生變化。為了處理這種情況,我們將因為糾正性維護和改進性維護產生的不同變化區(qū)圖3-9:圖3-4中的活動圖的改變分開來,各自選擇這兩種不同的測試用例。舉個例子,在圖3-9中,除了從edge(j,f)到edge(j,n)的變化,nodek同樣發(fā)生了變化。首先,我們選擇與nodek相關的測試用例t2,t3,t4。然后,我們選擇對應edge(j,n)的測試用例t3,t4。最后,聯(lián)合對應nodek和edge(j,n)的測試用例,測試用例包括t2,t3,t4。本章小結在這章中,我們首先討論了需求的可追溯性和它在回歸測試中的角色。接著,我們引入了活動圖作為我們的基礎研究方向,提供了一個方法,去評估和記錄基于活動圖的需求可跟蹤性。最后,我們定義和描述了基于活動圖的回歸測試選擇技術。風險和風險分析引言風險指得是任何威脅到一個項目達到預期目標的事情。特別是指這個事件的可能會發(fā)生,而發(fā)生后會導致一些損失[6]。軟件系統(tǒng)發(fā)布時可能包含很多bug。因為某些風險導致的損失越嚴重,這些風險的級別越高。風險性測試的基本原理是對軟件系統(tǒng)作更高風險的測試以發(fā)現(xiàn)和找到一些潛在的錯誤。風險性測試測試人員的任務是在產品中發(fā)現(xiàn)高優(yōu)先級的問題。風險是問題可能發(fā)生的衡量。問題越可能發(fā)生,問題發(fā)生后的影響越大,那么風險級別越高。風險是所有測試的動力所在。從某種意義上說,沒有風險就沒有測試,就像沒有空氣就沒有生命一樣。風險分析McGregor指出[6]:風險分析是一個識別風險的過程,以與找出合理方法如何防止這些潛在的問題變?yōu)楝F(xiàn)實。風險分析的結果是列出一系列風險,根據(jù)風險級別排好,以便測試人員利用有限的資源做出優(yōu)先級先后的決定。風險分析方法包括3個任務:識別出對應系統(tǒng)每個功能或特征的風險。確定風險的數(shù)量。產生一個根據(jù)風險級別排列的風險列表,一一對應系統(tǒng)功能或特征客觀的風險分析是為了識別出潛在的問題,這些問題可能會影響項目的價值或成果。為了達到這個目的,統(tǒng)計學模型會被用到,可能有時還會用到故障模式分析(最普遍的風險評估分析技術[23])。風險分析活動Karolak在他1996年的書《SoftwareEngineeringRiskManagement》中定義了一種風險分析活動的模式。Amland在這個模式基礎上增加了相關的因素[23],把測試過程中的風險性測試加入到Karolak的模式中。圖4.1描繪了風險分析活動模式。橢圓的是Amland增加的部分。下面會討論每個活動。風險識別:收集項目相關信息,將這些信息分類分析以確定在測試階段和未來產品階段潛在風險的數(shù)量。按照系統(tǒng)的功能和特征模塊等級評估風險。風險策略:識別和評估風險。根據(jù)系統(tǒng)的每個功能定義適當?shù)臏y試級別。這為以后制定測試計劃做準備。測試策略根據(jù)項目不同而變化。這主要根據(jù)開發(fā)和測試項目的類型,開發(fā)和用戶環(huán)境,以與其他質量和商業(yè)需求不同決定。風險評估:確定潛在的發(fā)現(xiàn)在系統(tǒng)功能和特征上的影響。包括失敗的可能性以與失敗后對每個功能產生的不利后果。風險減輕:基于上面的一些行為,減輕和避免風險或者減少風險產生的影響。將測試關注在關鍵性的功能上是減少風險的一個有效方法。風險報告:傳統(tǒng)的報告信息包括錯誤數(shù)目,每個功能對應的錯誤,錯誤的分類,每個錯誤測試花的時間等。風險預測:根據(jù)先前已經確定的風險的歷史和信息預測當前風險.。圖4.1風險分析活動模式一個實用的風險模型風險因為項目的不同而變化。也可能在同一個項目中因為優(yōu)先級和開發(fā)的策略的變化而變化。在面向對象項目中,風險都是同項目的架構特征,對象間復雜的交互,類的復雜行為和項目需求的變化相關的。我們的研究是基于需求規(guī)說明的。我們不考慮風險和代碼之間的關系。Amland引入了專用名詞:風險敞口(RiskExposure)[23],介紹了一種簡單的風險模型,這種風險模型僅僅需要兩個風險敞口的要素。我們在研究中使用這個模式。看下面:缺陷出現(xiàn)的可能性。Myers說[18]:隨著被發(fā)現(xiàn)的錯誤數(shù)量增加,沒被發(fā)現(xiàn)的錯誤數(shù)量也可能增加。因為每個錯誤都可能導致更多的錯誤。
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
- 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
- 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 2025至2030年中國食品刷行業(yè)投資前景及策略咨詢研究報告
- 2025至2030年中國氣相緩蝕劑行業(yè)投資前景及策略咨詢研究報告
- 2025至2030年中國四門冰箱行業(yè)投資前景及策略咨詢研究報告
- LED廣告行業(yè)市場發(fā)展現(xiàn)狀及前景趨勢與投資分析研究報告(2024-2030版)
- 在線客服系統(tǒng)租賃服務合同
- 云端數(shù)據(jù)安全防護服務合同
- 建筑工程項目風險控制協(xié)議書
- 純水管道工程環(huán)保措施方案
- 蘋果運輸合同
- 境外投資項目風險評估與防范協(xié)議
- 《城市違法建設治理研究的文獻綜述》2100字
- 《XL集團破產重整方案設計》
- 智慧金融合同施工承諾書
- 《基于Java web的網(wǎng)上招聘系統(tǒng)設計與實現(xiàn)》10000字(論文)
- 2024年1月國家開放大學法律事務??啤睹穹▽W(1)》期末紙質考試試題及答案
- 【MOOC】模擬電子技術基礎-華中科技大學 中國大學慕課MOOC答案
- 國家開放大學電大本科《工程經濟與管理》2023-2024期末試題及答案(試卷號:1141)
- TBT3134-2023機車車輛驅動齒輪箱 技術要求
- 美國史智慧樹知到期末考試答案章節(jié)答案2024年東北師范大學
- 中國動畫之經典賞析PPT課件
- 浙江省杭州市2021-2022學年九年級(上)期末科學試題【含答案】
評論
0/150
提交評論