【正文】 (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中的信息重新排列，我們建立了一個(gè)測試用例可追溯性模型，用來顯示和檢查測試用例和活動(dòng)圖元素之間的聯(lián)系。我們已經(jīng)列出了表32中每個(gè)測試用例對應(yīng)圖35中的路徑。因此，我們說測試用例是用來測試相關(guān)的一系列活動(dòng)圖元素的。圖35：建立需求特征和測試用例之間的可追溯性的聯(lián)系當(dāng)我們設(shè)計(jì)測試用例時(shí)，我們列出了對應(yīng)每個(gè)測試用例的路徑。如果我們找到一個(gè)方法可以去跟蹤測試用例到活動(dòng)圖各個(gè)元素的關(guān)系，那么我們就可以建立需求特征和測試用例之間的聯(lián)系。換句話說，就是我們必須設(shè)計(jì)測試用例用來測試需求的每個(gè)點(diǎn)?；顒?dòng)圖的各個(gè)元素可以一一映射到項(xiàng)目需求的每個(gè)特征。這些活動(dòng)圖已經(jīng)正確地，完全地，一致地，可行地表現(xiàn)了系統(tǒng)的規(guī)范說明。我們假設(shè)無論是需求測試還是設(shè)計(jì)測試都完成得很好，通過了所有的可接受的標(biāo)準(zhǔn)?；顒?dòng)圖是項(xiàng)目實(shí)施和測試用例設(shè)計(jì)的基礎(chǔ)。2) 一致性：對于同一個(gè)需求點(diǎn)，不會(huì)有兩個(gè)互相沖突的測試用例。2. 測試團(tuán)隊(duì)必須有足夠的信心設(shè)計(jì)的測試集是完整的，一致的和正確的。設(shè)計(jì)一個(gè)面向?qū)ο蟮能浖到y(tǒng)在系統(tǒng)發(fā)布前都不會(huì)完結(jié)。設(shè)計(jì)的可跟蹤性同樣是一個(gè)項(xiàng)目的可跟蹤性中的重要組成部分。就是說輸入和輸出結(jié)果是正確的。一個(gè)好的設(shè)計(jì)必須可以在有限的時(shí)間和預(yù)算中實(shí)施。在設(shè)計(jì)測試階段，測試人員必須保證設(shè)計(jì)不僅符合需求的功能性，還要符合需求的性能要求。因此，測試設(shè)計(jì)的第一個(gè)目標(biāo)是消除非一致性。設(shè)計(jì)階段是需求分析階段的后續(xù)階段，將需求的要求完整地轉(zhuǎn)換成一個(gè)完整的計(jì)劃，以進(jìn)行后續(xù)的實(shí)施階段。 設(shè)計(jì)測試在系統(tǒng)設(shè)計(jì)階段，設(shè)計(jì)人員要嘗試找出解決在需求階段提出的問題。但是，需求必須符合項(xiàng)目開發(fā)時(shí)間和預(yù)算的要求。這些不一致的需求和冗余的需求在需求測試階段必須就被抓出來，并被消除，避免后續(xù)的系統(tǒng)設(shè)計(jì)階段的問題。2. 完整性：需求必須滿足客戶的所有希望的需求，當(dāng)然不能超出條件許可范圍。分析需求必須確保不會(huì)有歧義的單詞出現(xiàn)在需求文檔。因此，需求測試的目標(biāo)是驗(yàn)證每個(gè)分析階段的結(jié)果。在我們的方法中，我們使用活動(dòng)圖來表示理想的系統(tǒng)行為。在本節(jié)中，我們提供了基于活動(dòng)圖，獲取需求可追溯性的方法。這個(gè)測試集覆蓋了圖中所有的node 和 edge，滿足了我們基于規(guī)范說明的測試覆蓋標(biāo)準(zhǔn)，我們稱之為節(jié)點(diǎn)和邊界覆蓋標(biāo)準(zhǔn)。 基于活動(dòng)圖設(shè)計(jì)測試用例在我們的例子中，我們基于圖34設(shè)計(jì)了5個(gè)測試用例，都列在表32中。 同步行為當(dāng)我們使用同步框d 去表示當(dāng)前的3個(gè)同步線程(d1 , d2 , d3)。先發(fā)請求，圖中我們可以看到同步發(fā)了3個(gè)請求到3個(gè)銀行。這個(gè)系統(tǒng)幫助用戶去進(jìn)行加拿大元和美元之間的交換。我們用它來進(jìn)行基于活動(dòng)圖的測試用例設(shè)計(jì)，回歸分析和測試。我們將這種框叫做同步框(Synchronization Box)。例如在這個(gè)例子中，我們使用a，bc / d, e來表示這個(gè)過程的路徑。所以在執(zhí)行虛線盒里面的測試用例總是執(zhí)行盒內(nèi)所有的行為，不受測試人員的控制。對于同步行為，一旦系統(tǒng)到達(dá)同步fork的時(shí)候，所有在fork和它對應(yīng)的join之間的行為都在同步進(jìn)行，直到下一個(gè)出來的行為被激發(fā)。為了識(shí)別這些路徑，我們在圖中標(biāo)識(shí)了所有節(jié)點(diǎn)。同步行為是存在于同步配對之間的行為，同步配對是指一個(gè)fork，一個(gè)Join。我們在本文中不討論基于活動(dòng)圖的測試用例設(shè)計(jì)過程。一個(gè)測試覆蓋標(biāo)準(zhǔn)是軟件測試完整性的衡量標(biāo)準(zhǔn)?；谔囟康牡臏y試用例可能會(huì)覆蓋到同一條路徑，但是可能會(huì)產(chǎn)生不同的測試數(shù)據(jù)。圖形化工具的使用，我們可以很直觀地了解整個(gè)系統(tǒng)的運(yùn)行情況。一個(gè)測試目的可能與控制流，數(shù)據(jù)流相關(guān)。在這章中，我們假定我們的測試用例都是基于活動(dòng)圖來設(shè)計(jì)的。2. 邊界(Edges)：在節(jié)點(diǎn)間的抽象的連接。一個(gè)節(jié)點(diǎn)可能連接到其他圖形元素也可能是單獨(dú)的。在我們的研究中，活動(dòng)圖的元素可以分成節(jié)點(diǎn)和邊界兩類。一個(gè)圖的節(jié)點(diǎn)和邊界表達(dá)一種關(guān)系，這是另外一種簡單但有力的數(shù)學(xué)概念。一個(gè)圖可以通過兩個(gè)簡單的結(jié)構(gòu)來表現(xiàn)對象間的關(guān)系：節(jié)點(diǎn)和邊界。作為需求和設(shè)計(jì)文檔的一部分，活動(dòng)圖給開發(fā)人員詳細(xì)的設(shè)計(jì)和實(shí)施信息，同時(shí)給測試人員提供基于規(guī)范說明的測試用例的準(zhǔn)備材料。在很多方面，活動(dòng)圖是結(jié)構(gòu)化開發(fā)中流程圖和數(shù)據(jù)流程圖 (DFD) 的面向?qū)ο蟮韧w。因?yàn)橄到y(tǒng)必須跟蹤沒一個(gè)訂單，所以消息就被發(fā)送到對象Log File中。郵件系統(tǒng)是預(yù)定和單獨(dú)訂單后的共同行為，當(dāng)消費(fèi)者填完訂單后都會(huì)到郵件系統(tǒng)。因此，這是個(gè)同步行為，就是fork。如果是個(gè)無賬戶的單獨(dú)的訂票，會(huì)隨著訂單出來需要支付的信息，客戶再去支付。如圖31所示，在收到訂單后，下面是一個(gè)分支。粗線條表示可能會(huì)并行進(jìn)行的過程的開始和結(jié)束。箭頭表示活動(dòng)之間的轉(zhuǎn)換，各種活動(dòng)之間的流動(dòng)次序。 圓角矩形表示執(zhí)行的過程或活動(dòng)。描述的是航空公司的一個(gè)簡單的訂票系統(tǒng)的系統(tǒng)行為。只有當(dāng)所有的進(jìn)去的轉(zhuǎn)移都完成他們的行為，出來的轉(zhuǎn)移才會(huì)進(jìn)行。當(dāng)這個(gè)進(jìn)來的轉(zhuǎn)移被觸發(fā)，所有的出來的轉(zhuǎn)移都并發(fā)進(jìn)行。它標(biāo)志著用分支標(biāo)識(shí)的條件行為的結(jié)束。用If/Else條件來控制分支的進(jìn)行?？梢员挥脕砻枋鱿到y(tǒng)運(yùn)行中的基本流，備選流和額外流。 活動(dòng)圖的標(biāo)識(shí)活動(dòng)圖描述活動(dòng)的先后順序。泳道和時(shí)標(biāo)相組合的方法：橫向按時(shí)標(biāo)分組；縱向按泳道分組。12. 信息(Message)：一些發(fā)送到對象的或者從對象中發(fā)出的信息。11. 對象(Object)：對象是系統(tǒng)中相互關(guān)系的參與者。將條件放在轉(zhuǎn)移箭頭附近的方框中。它不同于一般的轉(zhuǎn)移，因?yàn)樗恍枰黠@的觸發(fā)器事件，而是通過完成活動(dòng)（用活動(dòng)狀態(tài)表示）來觸發(fā)。9. 轉(zhuǎn)移(Transition)：表示各種活動(dòng)狀態(tài)的先后順序。7. 信號(hào)發(fā)射(Signal Sender)：當(dāng)前面的活動(dòng)終止，指定的信號(hào)發(fā)射。5. 決策點(diǎn)(Decision Point)：通過條件來判定該走那條分支6. 同步示意條(Synchronization Bar)：同步示意條是用于顯示平行分支流。4. 終點(diǎn)(Stop Marker)：標(biāo)志活動(dòng)圖的出口(最終的狀態(tài))。3. 起點(diǎn)(Start Marker)：活動(dòng)圖的人口(最開始的狀態(tài))。在活動(dòng)圖中，同步線程也可以被叫做同步活動(dòng)(Synch Activity)。它可以是真實(shí)的過程，比如打印一個(gè)字母，或者是執(zhí)行一個(gè)軟件程序，比如是執(zhí)行一個(gè)類的方法[26]。 活動(dòng)圖的元素一個(gè)活動(dòng)圖的核心標(biāo)志是活動(dòng)狀態(tài)或者說是簡單的活動(dòng)。在我們的研究中，我們使用活動(dòng)圖來詳細(xì)描述系統(tǒng)的需求，以達(dá)到回歸分析的目的。有如下兩個(gè)原因：1. 活動(dòng)圖可以用來表達(dá)控制流和數(shù)據(jù)流，但是CFG僅僅可以用來表達(dá)控制流。許多研究人員錯(cuò)誤理解活動(dòng)圖的概念，覺得它僅僅就是一個(gè)控制流圖(Control Flow Graph(CFG))。許多公司，比如IBM公司多年前就開始在系統(tǒng)設(shè)計(jì)中使用活動(dòng)圖。2. 理解工作流：即使我們在深入了解用例前，我們可以協(xié)同商業(yè)專家畫出活動(dòng)圖，理解業(yè)務(wù)流程及其如何變化的。缺點(diǎn)：很難清楚地描述動(dòng)作與對象之間的關(guān)系。活動(dòng)圖實(shí)際上是狀態(tài)圖的特殊形式，它的每個(gè)狀態(tài)都有入口動(dòng)作，用以說明進(jìn)入該狀態(tài)發(fā)生的操作。另一種可視化形式是狀態(tài)圖?；顒?dòng)圖中一個(gè)活動(dòng)結(jié)束后立即進(jìn)入下一個(gè)活動(dòng)?；顒?dòng)圖的應(yīng)用非常廣泛，它既可以用來描述操作（類的方法）的行為，也可以描述用例和對象內(nèi)部的工作過程。它描述活動(dòng)的順序，展現(xiàn)從一個(gè)活動(dòng)到另一個(gè)活動(dòng)的控制流。當(dāng)模型建立之后，模型可以被UML工具轉(zhuǎn)化成指定的程序語言代碼?！　ML最適于數(shù)據(jù)建模，業(yè)務(wù)建模，對象建模，組件建模。UML可以貫穿軟件開發(fā)周期中的每一個(gè)階段。 UML是在開發(fā)階段，說明，可視化，構(gòu)建和書寫一個(gè)面向?qū)ο筌浖芗到y(tǒng)的制品的開放方法。UML為面向?qū)ο箝_發(fā)系統(tǒng)的產(chǎn)品進(jìn)行說明、可視化、和編制文檔的一種標(biāo)準(zhǔn)語言。 UML的活動(dòng)圖活動(dòng)圖是UML用于對系統(tǒng)的動(dòng)態(tài)行為建模的一種常用工具。結(jié)果是，系統(tǒng)的相關(guān)信息轉(zhuǎn)化成不同的形式和在不同階段的不同代碼。我們用它來解決回歸分析和測試的第一個(gè)問題：識(shí)別受到影響的組件。3. 記錄和理解各種文檔的變化過程。根據(jù)Spanoudaki的說法[25]，需求的可追溯性可以被用到：1. 協(xié)助驗(yàn)證系統(tǒng)滿足需求的要求。在過去幾年中，軟件需求可追溯性的研究還是挺多的。也就是說，可追溯性是這么一種能力：跟隨需求從最原始狀態(tài)，經(jīng)過它們的規(guī)范說明和開發(fā)，到產(chǎn)品的隨后的開發(fā)和使用，再通過一段時(shí)間的不斷完善，當(dāng)然也包括在這些階段中任何一個(gè)遍歷過程?！靶枨蟮目勺匪菪浴边@個(gè)專用名詞最初是來自美國國防部。關(guān)于需求的可追溯性，簡單的，普遍的觀點(diǎn)是通過記賬的方法，這可以防止很多問題[7]。然后，當(dāng)在第一步中識(shí)別出哪些組件受到影響后，我們在第2步中選擇測試這些組件的回歸測試用例。在糾正性維護(hù)中，我們可以通過哪些組件里的代碼發(fā)生變化來識(shí)別哪些組件受到影響。從某種意義上說，沒有風(fēng)險(xiǎn)就沒有測試，就像沒有空氣就沒有生命一樣。問題越可能發(fā)生，問題發(fā)生后的影響越大，那么風(fēng)險(xiǎn)級(jí)別越高。 需求的可追溯性測試人員的任務(wù)是在產(chǎn)品中發(fā)現(xiàn)高優(yōu)先級(jí)的問題。我們的方法是基于項(xiàng)目文檔，包括設(shè)計(jì)文檔，系統(tǒng)變化的歷史文檔，測試執(zhí)行的log記錄。在我們的研究中，我們使用UML中的活動(dòng)圖作為需求分析和設(shè)計(jì)的工具，尤其是作為工作流的標(biāo)記。同時(shí)也將軟件系統(tǒng)的改變，回歸測試進(jìn)行了分類。在論文里，我們的討論主要針對這個(gè)分類展開。Leung 和 White 稱適應(yīng)性維護(hù)和完善性維護(hù)都被認(rèn)為是改進(jìn)性的維護(hù)(Progressive Maintenance) 基于上面的分類，我們可以將回歸測試分成兩類：1. 糾錯(cuò)性回歸測試：就是在糾錯(cuò)性維護(hù)后進(jìn)行的回歸測試，這時(shí)軟件系統(tǒng)的需求規(guī)格說明沒有發(fā)生變化。經(jīng)常是增加了新的功能。完善性維護(hù)是軟件維護(hù)的主要部分，通常占所有軟件維護(hù)工作量的一半以上。在一個(gè)應(yīng)用軟件成功運(yùn)行期間，用戶也可能請求增加新功能、建議修改已有功能或提出某些改進(jìn)意見，以便使軟件的功能和質(zhì)量得到進(jìn)一步的完善。近年來，硬件基本是一年半一代，操作系統(tǒng)的版本也在不斷地更新，外部設(shè)備，外存儲(chǔ)器和其他系統(tǒng)元素也頻繁地升級(jí)和變化，因此為了使老的軟件能夠在新的運(yùn)行環(huán)境下正常工作，適應(yīng)性維護(hù)是必須且經(jīng)常發(fā)生的。2. 適應(yīng)性維護(hù)(Adaptive Maintenance)：適應(yīng)性維護(hù)是為使軟件系統(tǒng)適應(yīng)不斷變化的運(yùn)行環(huán)境而進(jìn)行修改的活動(dòng)。由于軟件測試不可能排除大型軟件系統(tǒng)中所有的錯(cuò)誤，測試階段隱藏下來的軟件錯(cuò)誤，有可能在軟件投入實(shí)際運(yùn)行之后，才逐步暴露出來并造成系統(tǒng)故障。 軟件維護(hù)的分類和回歸測試的類型在軟件開發(fā)和維護(hù)階段，當(dāng)軟件進(jìn)行打補(bǔ)丁，升級(jí)或微調(diào)時(shí)，軟件系統(tǒng)可能會(huì)發(fā)生許多變化。 每種回歸測試模式都有其優(yōu)點(diǎn)和缺點(diǎn)。 再測試全部用例的策略是最安全的策略，但已經(jīng)運(yùn)行過許多次的回歸測試不太可能揭示新的錯(cuò)誤，而且很多時(shí)候，由于時(shí)間、人員、設(shè)備和經(jīng)費(fèi)的原因，不允許選擇再測試全部用例的回歸測試策略，此時(shí)，可以選擇適當(dāng)?shù)牟呗赃M(jìn)行縮減的回歸測試。在允許的條件下，回歸測試盡可能覆蓋受到影響的部分。3. 再測試修改的部分：當(dāng)測試者對修改的局部化有足夠的信心時(shí)，可以通過相依性分析識(shí)別軟件的修改情況并分析修改的影響，將回歸測試局限于被改變的模塊和它的接口上?；貧w測試所使用的測試用例個(gè)數(shù)可以由測試預(yù)算確定，回歸測試可以優(yōu)先選擇那些針對最重要或最頻繁使用功能的測試用例，釋放和緩解最高級(jí)別的風(fēng)險(xiǎn)，有助于盡早發(fā)現(xiàn)那些對可靠性有最大影響的故障。：選擇基線測試用例庫中的全部測試用例組成回歸測試包，這是一種比較安全的方法，再測試全部用例具有最低的遺漏回歸錯(cuò)誤的風(fēng)險(xiǎn)，但測試成本最高。測試用例選擇過程圖22所示。它們有兩個(gè)分類：1) 可以重新測試的測試用例：這些測試用例是依然有效，應(yīng)當(dāng)被重新執(zhí)行的。當(dāng)規(guī)格說明和執(zhí)行改變后，這些測試用例都保持有效性，不需要重新運(yùn)行。在我們的研究當(dāng)中，我們僅僅關(guān)注從原來的完整測試集中選擇合適的測試用例的技術(shù)方法。第2點(diǎn)是關(guān)于選擇測試用例去重新執(zhí)行的。4. 獲取和評估測試結(jié)果，包括評估發(fā)生改變的軟件系統(tǒng)的運(yùn)行情況，報(bào)告回歸測試集的覆蓋率。2. 選擇測試用例去測試被影響的組件。3. 對于這些重新測試的組件的覆蓋標(biāo)準(zhǔn)是什么？4. 怎么選擇回歸測試用例或改變原來的測試用例？為了解決上述問題，對于回歸分析和測試策略，下列的行動(dòng)是很重要的。利用回歸分析和測試，我們可以僅僅重新測試受到影響到得那部分軟件系統(tǒng)?；貧w測試基本上包含下面幾個(gè)步驟：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)確性6. 建立T’’’，是P’的回歸測試集，結(jié)合了T’和T’’。如果選擇測試用例的代價(jià)少于重新測試所有測試用例的代價(jià)，那就說明測試用例選擇技術(shù)是經(jīng)濟(jì)有效的[20]?；貧w測試和開發(fā)過程中的測試最主要的區(qū)別是回歸測試的測試用例集會(huì)不斷的重用。 回歸分析和測試概念回歸分析和測試是軟件系統(tǒng)發(fā)生改變后的一個(gè)軟件過程[19]。5浙江大學(xué)碩士學(xué)位論文 第2章回歸測試第2章 回歸測試 引言Myers發(fā)現(xiàn)對已經(jīng)存在的程序進(jìn)行修改比整個(gè)系統(tǒng)重新進(jìn)行編碼更容易產(chǎn)生bug[18]。第六章：用一個(gè)實(shí)驗(yàn)來驗(yàn)證我們提出的回歸測試方法。第四章：討論了風(fēng)險(xiǎn)分析，給出一個(gè)實(shí)用的風(fēng)險(xiǎn)模式，可以在回歸分析中使用。 本文結(jié)構(gòu)組織文章剩下部分組織結(jié)構(gòu)如下：第二章：主要描述回歸測試的背景知識(shí)，相關(guān)技術(shù)。3) 我們分析和描述了風(fēng)險(xiǎn)分析的用處，怎么使用風(fēng)險(xiǎn)敞口(RE)可以用來衡量回歸測試集的質(zhì)量。我們的策略是基于活動(dòng)圖的。我們分析了在需求和測試用例之間的聯(lián)系。 研究內(nèi)容和研究目標(biāo)在我們的研究中，我們提出采用基于活動(dòng)圖的回歸測試選擇技術(shù)和基于風(fēng)險(xiǎn)的回歸測試選擇技術(shù)，作為有效和高效的解決以上所列問題的