【正文】 制流圖，看圖38。因此，測試用例t2, t3, t4, t5必須被選擇到回歸測試集中。實際上，開發(fā)人員可能錯過許多錯誤，代碼改變歷史文檔也可能是不完整的。在我們的方法中，如果這個變化影響到活動圖中的node 和edge，我們就必須在活動圖中有所體現(xiàn)。在這種情況下，原來的系統(tǒng)行為(需求和規(guī)范說明)不會發(fā)生改變。對于僅僅是代碼發(fā)生變化，我們假設(shè)活動圖保持不變。圖36：需求特征和測試用例間的可跟蹤性的聯(lián)系鏈 基于活動圖進行測試用例的選擇在這節(jié)中，我們討論基于活動圖進行測試用例的選擇。在最近幾年，出現(xiàn)了需求的“可檢測性(testability)”這個名詞，慢慢地也被廣泛地接受。表34：對應(yīng)測試用例的活動圖的可追溯性NodeTest CaseEdgeTest Caseat1, 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)系。這可以看表33：表33：測試用例和活動圖元素Test CaseNode CoveredEdges Coveredt1a, 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)通過將表33中的信息重新排列，我們建立了一個測試用例可追溯性模型，用來顯示和檢查測試用例和活動圖元素之間的聯(lián)系。因此，我們說測試用例是用來測試相關(guān)的一系列活動圖元素的。如果我們找到一個方法可以去跟蹤測試用例到活動圖各個元素的關(guān)系，那么我們就可以建立需求特征和測試用例之間的聯(lián)系?；顒訄D的各個元素可以一一映射到項目需求的每個特征。我們假設(shè)無論是需求測試還是設(shè)計測試都完成得很好，通過了所有的可接受的標準。2) 一致性：對于同一個需求點，不會有兩個互相沖突的測試用例。設(shè)計一個面向?qū)ο蟮能浖到y(tǒng)在系統(tǒng)發(fā)布前都不會完結(jié)。就是說輸入和輸出結(jié)果是正確的。在設(shè)計測試階段，測試人員必須保證設(shè)計不僅符合需求的功能性，還要符合需求的性能要求。設(shè)計階段是需求分析階段的后續(xù)階段，將需求的要求完整地轉(zhuǎn)換成一個完整的計劃，以進行后續(xù)的實施階段。但是，需求必須符合項目開發(fā)時間和預(yù)算的要求。2. 完整性：需求必須滿足客戶的所有希望的需求，當然不能超出條件許可范圍。因此，需求測試的目標是驗證每個分析階段的結(jié)果。在本節(jié)中，我們提供了基于活動圖，獲取需求可追溯性的方法。 基于活動圖設(shè)計測試用例在我們的例子中，我們基于圖34設(shè)計了5個測試用例，都列在表32中。先發(fā)請求，圖中我們可以看到同步發(fā)了3個請求到3個銀行。我們用它來進行基于活動圖的測試用例設(shè)計，回歸分析和測試。例如在這個例子中，我們使用a，bc / d, e來表示這個過程的路徑。對于同步行為，一旦系統(tǒng)到達同步fork的時候，所有在fork和它對應(yīng)的join之間的行為都在同步進行，直到下一個出來的行為被激發(fā)。同步行為是存在于同步配對之間的行為，同步配對是指一個fork，一個Join。一個測試覆蓋標準是軟件測試完整性的衡量標準。圖形化工具的使用，我們可以很直觀地了解整個系統(tǒng)的運行情況。在這章中，我們假定我們的測試用例都是基于活動圖來設(shè)計的。一個節(jié)點可能連接到其他圖形元素也可能是單獨的。一個圖的節(jié)點和邊界表達一種關(guān)系，這是另外一種簡單但有力的數(shù)學(xué)概念。作為需求和設(shè)計文檔的一部分，活動圖給開發(fā)人員詳細的設(shè)計和實施信息，同時給測試人員提供基于規(guī)范說明的測試用例的準備材料。因為系統(tǒng)必須跟蹤沒一個訂單，所以消息就被發(fā)送到對象Log File中。因此，這是個同步行為，就是fork。如圖31所示，在收到訂單后，下面是一個分支。箭頭表示活動之間的轉(zhuǎn)換，各種活動之間的流動次序。描述的是航空公司的一個簡單的訂票系統(tǒng)的系統(tǒng)行為。當這個進來的轉(zhuǎn)移被觸發(fā)，所有的出來的轉(zhuǎn)移都并發(fā)進行。用If/Else條件來控制分支的進行。 活動圖的標識活動圖描述活動的先后順序。12. 信息(Message)：一些發(fā)送到對象的或者從對象中發(fā)出的信息。將條件放在轉(zhuǎn)移箭頭附近的方框中。9. 轉(zhuǎn)移(Transition)：表示各種活動狀態(tài)的先后順序。5. 決策點(Decision Point)：通過條件來判定該走那條分支6. 同步示意條(Synchronization Bar)：同步示意條是用于顯示平行分支流。3. 起點(Start Marker)：活動圖的人口(最開始的狀態(tài))。它可以是真實的過程，比如打印一個字母，或者是執(zhí)行一個軟件程序，比如是執(zhí)行一個類的方法[26]。在我們的研究中，我們使用活動圖來詳細描述系統(tǒng)的需求，以達到回歸分析的目的。許多研究人員錯誤理解活動圖的概念，覺得它僅僅就是一個控制流圖(Control Flow Graph(CFG))。2. 理解工作流：即使我們在深入了解用例前，我們可以協(xié)同商業(yè)專家畫出活動圖，理解業(yè)務(wù)流程及其如何變化的?；顒訄D實際上是狀態(tài)圖的特殊形式，它的每個狀態(tài)都有入口動作，用以說明進入該狀態(tài)發(fā)生的操作?；顒訄D中一個活動結(jié)束后立即進入下一個活動。它描述活動的順序，展現(xiàn)從一個活動到另一個活動的控制流?！　ML最適于數(shù)據(jù)建模，業(yè)務(wù)建模，對象建模，組件建模。 UML是在開發(fā)階段，說明，可視化，構(gòu)建和書寫一個面向?qū)ο筌浖芗到y(tǒng)的制品的開放方法。 UML的活動圖活動圖是UML用于對系統(tǒng)的動態(tài)行為建模的一種常用工具。我們用它來解決回歸分析和測試的第一個問題：識別受到影響的組件。根據(jù)Spanoudaki的說法[25]，需求的可追溯性可以被用到：1. 協(xié)助驗證系統(tǒng)滿足需求的要求。也就是說，可追溯性是這么一種能力：跟隨需求從最原始狀態(tài)，經(jīng)過它們的規(guī)范說明和開發(fā)，到產(chǎn)品的隨后的開發(fā)和使用，再通過一段時間的不斷完善，當然也包括在這些階段中任何一個遍歷過程。關(guān)于需求的可追溯性，簡單的，普遍的觀點是通過記賬的方法，這可以防止很多問題[7]。在糾正性維護中，我們可以通過哪些組件里的代碼發(fā)生變化來識別哪些組件受到影響。問題越可能發(fā)生，問題發(fā)生后的影響越大，那么風(fēng)險級別越高。我們的方法是基于項目文檔，包括設(shè)計文檔，系統(tǒng)變化的歷史文檔，測試執(zhí)行的log記錄。同時也將軟件系統(tǒng)的改變，回歸測試進行了分類。Leung 和 White 稱適應(yīng)性維護和完善性維護都被認為是改進性的維護(Progressive Maintenance) 基于上面的分類，我們可以將回歸測試分成兩類：1. 糾錯性回歸測試：就是在糾錯性維護后進行的回歸測試，這時軟件系統(tǒng)的需求規(guī)格說明沒有發(fā)生變化。完善性維護是軟件維護的主要部分，通常占所有軟件維護工作量的一半以上。近年來，硬件基本是一年半一代，操作系統(tǒng)的版本也在不斷地更新，外部設(shè)備，外存儲器和其他系統(tǒng)元素也頻繁地升級和變化，因此為了使老的軟件能夠在新的運行環(huán)境下正常工作，適應(yīng)性維護是必須且經(jīng)常發(fā)生的。由于軟件測試不可能排除大型軟件系統(tǒng)中所有的錯誤，測試階段隱藏下來的軟件錯誤，有可能在軟件投入實際運行之后，才逐步暴露出來并造成系統(tǒng)故障。 每種回歸測試模式都有其優(yōu)點和缺點。在允許的條件下，回歸測試盡可能覆蓋受到影響的部分?；貧w測試所使用的測試用例個數(shù)可以由測試預(yù)算確定，回歸測試可以優(yōu)先選擇那些針對最重要或最頻繁使用功能的測試用例，釋放和緩解最高級別的風(fēng)險，有助于盡早發(fā)現(xiàn)那些對可靠性有最大影響的故障。：選擇基線測試用例庫中的全部測試用例組成回歸測試包，這是一種比較安全的方法，再測試全部用例具有最低的遺漏回歸錯誤的風(fēng)險，但測試成本最高。它們有兩個分類：1) 可以重新測試的測試用例：這些測試用例是依然有效，應(yīng)當被重新執(zhí)行的。在我們的研究當中，我們僅僅關(guān)注從原來的完整測試集中選擇合適的測試用例的技術(shù)方法。4. 獲取和評估測試結(jié)果，包括評估發(fā)生改變的軟件系統(tǒng)的運行情況，報告回歸測試集的覆蓋率。3. 對于這些重新測試的組件的覆蓋標準是什么？4. 怎么選擇回歸測試用例或改變原來的測試用例？為了解決上述問題，對于回歸分析和測試策略，下列的行動是很重要的。回歸測試基本上包含下面幾個步驟：1. 確定從P到P’的改變的內(nèi)容2. 選擇子集T’∈ T，T’是基于P到P’改變的測試集3. 用T’測試P’，確認P’的正確性4. 如果需要，建立T’’，是關(guān)于P’的新的功能的或架構(gòu)的測試用例集5. 用T’’測試P’，確認P’的準確性6. 建立T’’’，是P’的回歸測試集，結(jié)合了T’和T’’。回歸測試和開發(fā)過程中的測試最主要的區(qū)別是回歸測試的測試用例集會不斷的重用。5浙江大學(xué)碩士學(xué)位論文 第2章回歸測試第2章 回歸測試 引言Myers發(fā)現(xiàn)對已經(jīng)存在的程序進行修改比整個系統(tǒng)重新進行編碼更容易產(chǎn)生bug[18]。第四章：討論了風(fēng)險分析，給出一個實用的風(fēng)險模式，可以在回歸分析中使用。3) 我們分析和描述了風(fēng)險分析的用處，怎么使用風(fēng)險敞口(RE)可以用來衡量回歸測試集的質(zhì)量。我們分析了在需求和測試用例之間的聯(lián)系。因為在這個選擇過程中完全是根據(jù)測試的歷史記錄來進行的，那么就必定要求這個歷史記錄是完整，正確的。最后，基于代碼的回歸測試技術(shù)是有編程語言的限制。而且，基于代碼的回歸測試技術(shù)需要測試人員在一定程度上進入和理解代碼[17]?；谶@些測試歷史信息，并根據(jù)當前測試情況來選擇較為合適的回歸測試用例，再將生成的回歸測試用例進行用例優(yōu)先排序，最后利用排序后的用例來進行測試，以進一步提高回歸測試效率。2) 基于歷史記錄的回歸測試選擇。任何一個程序都可以等價于一組程序切片的并集，而這些切片都是根據(jù)某個切片變量和切片準則計算出來的。該方法主要研究在已知代碼的情況下，對代碼相關(guān)的測試用例進行選擇。最近幾年，大家的注意力被集中到回歸測試測試用例選擇領(lǐng)域。他們的研究包含很廣泛的課題。所以本文吸收前人的研究成果，結(jié)合UML活動圖的特點，提出了基于UML活動圖的回歸測試選擇技術(shù)，為了對軟件質(zhì)量更有信心，又提出了基于風(fēng)險的回歸測試選擇技術(shù)，作為基于活動圖的回歸測試的有益補充。目前大多數(shù)回歸用例選擇技術(shù)多是基于代碼的，有些是基于歷史記錄的。該方法主要是根據(jù)測試的歷史記錄進行回歸測試選擇。其目的是選擇一個盡可能小并且又能覆蓋所有改變和影響的代碼的測試用例集?；貧w測試可以重用以前的測試過程，是一種比較有效地測試方法?；貧w測試是軟件測試中一個很重要的環(huán)節(jié)。尤其是這幾年，電子商務(wù)及金融產(chǎn)品的網(wǎng)上交易平臺等這些基于Web應(yīng)用的系統(tǒng)的快速發(fā)展，軟件產(chǎn)品的一點瑕疵就可能導(dǎo)致客戶的巨額財產(chǎn)損失。4）用一個股票交易系統(tǒng)作為實驗對象，驗證了我們提出的方法的有效性，高效性。2）提出了一個基于活動圖的回歸測試選擇策略，用來選擇回歸測試用例。而在回歸測試中回歸測試用例的選擇是最重要的一個步驟，如何選擇一個盡可能小并且又能覆蓋所有改變和影響的測試用例集來進行回歸測試用例選擇是一個重要的課題。浙江大學(xué)碩士學(xué)位論文 Abstract 基于活動圖的回歸測試研究 摘要隨著信息技術(shù)的深入發(fā)展，社會的各個領(lǐng)域的信息電子化進程進行的非常迅速。但是回歸測試是一個成本昂貴的過程。主要研究內(nèi)容及成果包括以下幾個方面：1）分析了需求的可跟蹤性對于進行和管理回歸分析和測試的重要性。提出了基于風(fēng)險的回歸測試選擇技術(shù)，是基于活動圖的回歸選擇技術(shù)的有益補充。一旦這些軟件失效，就會造成巨大的損失。根據(jù)Boehm的統(tǒng)計，目前軟件測試在軟件開發(fā)中的總成本中，其開銷占到了30%~50%[1]，在某些重大軟件項目占得比重更大。所以回歸測試成為整個軟件測試的關(guān)鍵，是軟件質(zhì)量的重要保證。回歸測試選擇是復(fù)用已有用例基進行測試的方法。2）基于歷史記錄的回歸測試選擇。UML對開發(fā)高質(zhì)量軟件起了很大的促進作用，同時也給軟件測試以及回