【文章內(nèi)容簡介】 測試是軟件測試中一個很重要的環(huán)節(jié)。其目的是保證程序在修改后不會引入新的錯誤 [2]。而隨著軟件規(guī)模的日益龐大，回歸測試的成本也相應(yīng)增大，甚至達(dá)到整個測試成本的一半以上 [3]。所以回歸測試成為整個軟件測試的關(guān)鍵，是軟件質(zhì)量的重要保證。 回歸測試可以重用以前的測試過程，是一種比較有效地測試方法。但是，回歸測試需要前期投入，如何減少回歸測試的代價，是整個軟件回歸測試研究的難點和重點。 在所有的難點和重點 中，回歸測試用例選擇（ Regression Test Selection）是重點中的重點。回歸測試選擇是復(fù)用已有用例基進(jìn)行測試的方法。其目的是選擇一個盡可能小并且又能覆蓋所有改變和影響的代碼的測試用例集。目前回歸測試選浙江大學(xué)碩士學(xué)位論文 第 1 章 緒論 2 擇的研究，主要包括： 1）基于代碼信息的回歸測試選擇。該方法主要研究在已知代碼的情況下，對代碼相關(guān)的用例進(jìn)行選擇。 2）基于歷史記錄的回歸測試選擇。該方法主要是根據(jù)測試的歷史記錄進(jìn)行回歸測試選擇。 統(tǒng)一建模語言（ UML）在軟件工程發(fā)展進(jìn)程中具有里程碑的意義，統(tǒng)一建模語言（ UML）的正式發(fā)展是從 1994 年開始的，它匯集了近 20 多年來各種建模技術(shù)。自提出以來，后成為研究熱點，并且迅速在工業(yè)界得到廣泛的應(yīng)用。 UML對開發(fā)高質(zhì)量軟件起了很大的促進(jìn)作用，同時也給軟件測試以及回歸測試帶來新的研究領(lǐng)域。 目前大多數(shù)回歸用例選擇技術(shù)多是基于代碼的，有些是基于歷史記錄的?；诖a的回歸測試選擇對測試人員要求很高，需要測試人員閱讀并理解代碼，這需要很多的時間花費，并且是依賴于編程語言的。而基于歷史記錄的回歸測試選擇要求測試的所有記錄非常完善，很多時候我們達(dá)不到要求。而基于 UML 設(shè)計的回歸測試選擇不依賴于編程語言，比 代碼級的回歸測試選擇更加容易且效率高。 所以本文吸收前人的研究成果，結(jié)合 UML 活動圖的特點，提出了基于 UML活動圖的回歸測試選擇技術(shù)，為了 對軟件質(zhì)量更有信心，又提出了基于風(fēng)險的回歸測試選擇技術(shù)，作為 基于活動圖的回歸測試的有益補充。 國內(nèi)外研究現(xiàn)狀及進(jìn)展 以前相關(guān)研究 回歸測試作為軟件生命周期的一個組成部分，在整個軟件測試過程中占有很大的工作量比重，軟件開發(fā)的各個階段都會進(jìn)行多次回歸測試。在漸進(jìn)和快速迭代開發(fā)中，新版本的連續(xù)發(fā)布使回歸測試進(jìn)行的更加頻繁，而在極端編程方法中，更是要求每天都進(jìn)行若干次回歸測試。 浙江大學(xué)碩士學(xué)位論文 第 1 章 緒論 3 許多研究人員研究 了 回歸測試技術(shù)。他們的研究包含很廣泛的課題。例如，Brown 和 Hoffman[8] 研究了測試環(huán)境和自動化回歸測試過程。 Harrold， Gupta 和Soffa[9]研究了測試用例管理技術(shù)。 Rothermel 和 Harrold[10] 研究了回歸測試選擇技術(shù)。 最近幾年，大家的注意力被集中到回歸測試測試用例選擇領(lǐng)域。大部分的技術(shù)是針對白盒測試 的 ，他們選擇測試用例是基于 代碼 的相關(guān)信息 [1112]。只有少數(shù)的技術(shù)是針對黑盒 測試 ，測試用例選擇基于系統(tǒng)本身特征 [1316]。 目前，回歸測試選擇的研 究主要包括以下兩個方面： 1) 基于代碼的回歸測試選擇。該方法主要研究在已知代碼的情況下，對代碼相關(guān)的測試用例進(jìn)行選擇。這個方法是通過比較修改前后對應(yīng)代碼對基線測試用例進(jìn)行選擇，從而得到回歸測試用例集的一種技術(shù) [28]。 先采用一些分解術(shù)將復(fù)雜的程序分解成一個個相對較小的片段來進(jìn)行分析和維護(hù)。這些片段就叫做程序切片。任何一個程序都可以等價于一組程序切片的并集，而這些切片都是根據(jù)某個切片變量和切片準(zhǔn)則計算出來的。根據(jù)切片的定義 :所有能夠影響到的語句、謂詞等都被包含到該切片變量的切片中了。所以對某個切片變量的修改一定不 會影響到其他切片變量的切片。那么基于代碼方法的回歸測試思想可以描述如下 : 針對修改后的程序，首先找出被修改的變量信息，然后運用切片方法找到由于這些變量的變化所引起的直接定義一使用關(guān)系和間接定義一使用關(guān)系 (通常是一些語句或者控制流和數(shù)據(jù)流信息 )，將這些信息提取出來，組成一個程序片段，設(shè)計測試用例對這些程序片段進(jìn)行測試，最后把這些測試用例加人到原程序測試用例中，構(gòu)成新的回歸測試用例集。 2) 基于歷史記錄的回歸測試選擇。就是以測試用例執(zhí)行的歷史記錄數(shù)據(jù)為依據(jù)進(jìn)行回歸測試選擇 [29]。每一輪測試都有一個測試狀態(tài)與之相對 應(yīng)，浙江大學(xué)碩士學(xué)位論文 第 1 章 緒論 4 該測試狀態(tài) ，該測試狀態(tài)涵蓋了當(dāng)前測試中影響策略選擇的因素 ， 包括測試用例錯誤檢測率要求 、 測試成本 、 測試頻次 。這些就是測試的歷史信息。基于這些 測試歷史信息 ， 并根據(jù)當(dāng)前測試 情況 來選擇較為合適的回歸測試 用例， 再將生成的回歸測試用例進(jìn)行用例優(yōu)先排序 ， 最后利用排序后的用例來進(jìn)行測試 ， 以進(jìn)一步提高回歸測試效率 。 現(xiàn)存理論存在的問題 對于 基于代碼的 回歸測試選擇技術(shù)來說存在一些問題 ?；诖a的回歸測試技術(shù)可以有效的應(yīng)用到回歸測試中的單元級別。但是當(dāng)我們試圖測試一個大的或更加復(fù)雜的組件，比如一個子系統(tǒng)，我們要用基于代碼的回 歸測試技術(shù)從代碼中取得所有所需信息就很困難，因此，基于代碼的回歸測試技術(shù)就很難適應(yīng)較大的組件的測試，例如子系統(tǒng)的測試。 而且 ，基于代碼的回歸測試技術(shù)需要測試人員在一定程度上進(jìn)入和理解代碼[17]。這個需要就會產(chǎn)生一些實際的問題。測試人員不得不去花很多時間去讀懂代碼，而且對測試人員的要求會很高。這是很費時，高成本 的方法 。 最后，基于代碼的回歸測試技術(shù)是有編程語言的限制。在一些軟件系統(tǒng)里面，會使用超過一種的編程語言，比如，在 Web 系統(tǒng)里，我們可能會用到 Java， JSP，HTML 等語言。這會導(dǎo)致分析代碼的過程非常 復(fù)雜。 同樣的對于基于歷史信息的回歸測試選擇技術(shù)也存在著一些問題。因為在這個選擇過程中完全是根據(jù)測試的歷史記錄來進(jìn)行的，那么就必定要求這個歷史記錄是完整，正確的。但是，實際情況是，很多項目的測試歷史記錄是不完整的。 研究內(nèi)容和研究目標(biāo) 在 我們的 研究中，我們提出采用基于 活動圖 的回歸測試 選擇技術(shù)和基于風(fēng)險的回歸測試選擇技術(shù)， 作為有效和高效的解決以上所列問題的途徑。 浙江大學(xué)碩士學(xué)位論文 第 1 章 緒論 5 下面是本論文的 主要工作 ： 1) 我們說明了 需求 可追溯性對于 進(jìn)行 和管理回歸分析和測試的重要性。我們 分析 了在需求 和測試用例之間 的聯(lián)系。 2) 我們提供了一種新的選擇 回歸測試用例的策略。我們的策略是基于 活動圖 的。 將需求里的功能特征一一對應(yīng)到活動圖上，再通過活動圖很直觀地進(jìn)行測試用例的選擇。 3) 我們 分析 和描述了風(fēng)險分析的用處， 怎么使用 風(fēng)險敞口 (RE)可以用來衡量回歸測試集的質(zhì)量。 提供了基于風(fēng)險的回歸測試選擇技術(shù)，作為基于活動圖的回歸測試技術(shù)的有效補充。 本文結(jié)構(gòu)組織 文章剩下部分組織結(jié)構(gòu)如下： 第二章：主要描述回歸測試的背景知識，相關(guān)技術(shù)。 第三章：討論了建立基于活動圖的需求可跟蹤性的方法，在次基礎(chǔ)上建立了對回歸分析和選擇技術(shù)。 第四章： 討論了風(fēng)險分析，給出一個實用的風(fēng)險模 式，可以在回歸分析中使用。 第五章：討論了基于風(fēng)險的回歸測試策略，并使用例子說明。 第六章： 用一個實驗來驗證我們提出的回歸測試方法 。 第七章：總結(jié)全文。浙江大學(xué)碩士學(xué)位論文 第 2 章 回歸測試 6 第 2章 回歸測試 引言 Myers 發(fā)現(xiàn)對已經(jīng)存在的程序進(jìn)行修改比整個系統(tǒng)重新進(jìn)行編碼更容易產(chǎn)生bug[18]。回歸測試 是 被用來確認(rèn)被修復(fù)的 bug 已經(jīng)真正的被修復(fù)了，同時在這個過程中沒有產(chǎn)生新的 bug，系統(tǒng)的功能還要符合需求的規(guī)定。 回歸分析和測試概念 回歸分析和測試是軟件系統(tǒng)發(fā)生改變后的一個軟件過程 [19]?；貧w測試通常就是發(fā)生在被測試的系統(tǒng)發(fā)生改變時 ，原來的 bug 已經(jīng)被完全修復(fù)，不會產(chǎn)生新的問題 ?；貧w測試和開發(fā)過程中的測試最主要的區(qū)別是回歸測試的測試用例集會不斷的重用。使用回歸測試選擇技術(shù)，我們僅僅重新運行被壓縮過的回歸測試用例，這些測試用例根據(jù)修改過的組件或系統(tǒng)而變化。如果選擇測試用例的代價少于重新測試所有測試用例的代價，那就說明測試用例選擇技術(shù)是經(jīng)濟有效的 [20]。 回歸測試技術(shù) Rothermel和 Harrold 在自己的研究中描述回歸測試技術(shù)如下所述 [9]： 程序 P， 修改后的程序 p’，程序 P 的測試用例集 T，回歸分析和測試技術(shù)就是讓 T的子集能滿足程序 P’的質(zhì)量要求 ， 而從 p 到 P’的對應(yīng)未改變部分功能不變。 回歸測試基本上包含下面幾個步驟： 1. 確定從 P 到 P’的改變的內(nèi)容 2. 選擇子集 T’∈ T， T’是基于 P 到 P’改變的測試集 3. 用 T’測試 P’，確認(rèn) P’的正確性 4. 如果需要，建立 T’’，是關(guān)于 P’的新的功能的或架構(gòu)的測試用例集 5. 用 T’’測試 P’，確認(rèn) P’的準(zhǔn)確性 浙江大學(xué)碩士學(xué)位論文 第 2 章 回歸測試 7 6. 建立 T’’’，是 P’的回歸測試集，結(jié)合了 T’和 T’’。 圖 回歸測試技術(shù) 回歸分析的討論 對僅僅發(fā)生少量變化的軟件系統(tǒng)進(jìn)行完全的測試是很昂貴的行為，尤其是對于大型系統(tǒng)。利用回歸分析和測試，我們可以僅僅重 新測試受到影響到得那部分軟件系統(tǒng)。 回歸分析和測試必須列出下面的這些基本問題 [21]： 1. 怎么確定因為某些組件代碼的改變而受到影響的所有組件？ 2. 要采取什么策略去重新測試這些受到影響的組件。 3. 對于這些重新測試的組件的覆蓋標(biāo)準(zhǔn)是什么？ 4. 怎么選擇回歸測試用例或改變原來的測試用例？ 為了解決上述問題，對于回歸分析和測試策略，下列的行動是很重要的。 浙江大學(xué)碩士學(xué)位論文 第 2 章 回歸測試 8 下面是一個實用的回歸測試策略： 1. 確定被影響的組件和選擇回歸測試覆蓋標(biāo)準(zhǔn)。 2. 選擇測試用例去測試被影響的組件。 3. 執(zhí)行選擇好的測試用例。 4. 獲取和評估測試結(jié)果，包括評估發(fā)生改變的軟 件系統(tǒng)的運行情況，報告回歸測試集的覆蓋率。 5. 修改測試計劃以符合下一個階段的回歸分析和測試。 第 2 點是關(guān)于選擇測試用例去重新執(zhí)行的。這些被執(zhí)行的測試用例可能會是新的測試用例，當(dāng)然也會有選出來的適當(dāng)?shù)睦系臏y試用例。在我們的研究當(dāng)中，我們僅僅關(guān)注從原來的完整測試集中選擇合適的測試用例的技術(shù)方法。 Luiu 將完整測試集中的測試用例分成兩類 [19]： 1. 可以重新使用的測試用例：這些測試用例是用來測試沒有更改部分的規(guī)格說明和相應(yīng)未改變部分的執(zhí)行。當(dāng)規(guī)格說明和執(zhí)行改變后，這些測試用例都保持有效性，不需要重新運行。 2. 被影響到 得測試用例：這些測試用例是同發(fā)生改變的那些規(guī)格說明和執(zhí)行相關(guān)的。它們有兩個分類： 1) 可以重新測試的測試用例：這些測試用例是依然有效，應(yīng)當(dāng)被重新執(zhí)行的。 2) 過時的測試用例：這些測試用例對于發(fā)生改變的規(guī)格說明和執(zhí)行已經(jīng)是不相關(guān)或已經(jīng)過時了。 測試用例 選擇 過程圖 22 所示。 浙江大學(xué)碩士學(xué)位論文 第 2 章 回歸測試 9 圖 回歸測試用例選擇 回歸測試模式 Robert Binder 總結(jié)當(dāng)前的回歸測試選擇策略，分成 三 個模式 [7]： 1. 再測試全部用例 ：選擇基線測試用例庫中的全部測試用例組成回歸測試包，這是一種比較安全的方法，再測試全部用例具有最低的遺漏回歸 錯誤的風(fēng)險，但測試成本最高。全部再測試幾乎可以應(yīng)用到任何情況下，基本上不需要進(jìn)行分析和重新開發(fā)，但是，隨著開發(fā)工作的進(jìn)展，測試用例不斷增多，重復(fù)原先所有的測試將帶來很大的工作量，往往超出了我們的預(yù)算和進(jìn)度。 2. 基于操作剖面選擇測試：如果基線測試用例庫的測試用例是基于軟件操作剖面開發(fā)的，測試用例的分布情況反映了系統(tǒng)的實際使用情況?；貧w測試所使用的測試用例個數(shù)可以由測試預(yù)算確定，回歸測試可以優(yōu)先選擇那些針對最重要或最頻繁使用功能的測試用例，釋放和緩解最高級別浙江大學(xué)碩士學(xué)位論文 第 2 章 回歸測試 10 的風(fēng)險，有助于盡早發(fā)現(xiàn)那些對可靠性有最大影響的故障。這 種方法可以在一個給定的預(yù)算下最有效的提高系統(tǒng)可靠性，但實施起來有一定的難度。 3. 再測試修改的部分：當(dāng)測試者對修改的局部化有足夠的信心時，可以通過相依性分析識別軟件的修改情況并分析修改的影響，將回歸測試局限于被改變的模塊和它的接口上。通常，一個回歸錯誤一定涉及一個新的、修改的或刪除的代碼段。在允許的條件下，回歸測試盡可能覆蓋受到影響的部分。 再測試全部用例的策略是最安全的策略，但已經(jīng)運行過許多次的回歸測試不太可能揭示新的錯誤，而且很多時候，由于時間、人員、設(shè)備和經(jīng)費的原因，不允許選擇再測試全部用例的回歸測試 策略，此時，可以選擇適當(dāng)?shù)牟呗赃M(jìn)行縮減的回歸測試。 每種回歸測試模式都有其優(yōu)點和缺點。一種模式可能在某些情況下比另一種好，但是并不是在所有情況下都好。 軟件維護(hù)的分類和回歸測試的類型 在軟件開發(fā)和維護(hù)階段，當(dāng)軟件進(jìn)行打補丁，升級或微調(diào)時，軟件系統(tǒng)可能會發(fā)生許多變化。根據(jù)軟件維護(hù)預(yù)期目的的不同， White 將軟件維護(hù)分成三類 [22]： 1. 糾錯性維護(hù) (Corrective maint