計(jì)算機(jī)外文翻譯--c＃程序的回歸測試選擇

1、<p>　　中文7600漢字，4400單詞，2.2萬英文字符</p><p>　　出處：Mansour N, Statieh W. Regression test selection for c# programs[J]. Advances in Software Engineering, 2009, 2009:10.</p><p><b>　　外文資料翻譯</

2、b></p><p>　　學(xué) 院 </p><p>　　專 業(yè) 計(jì)算機(jī)科學(xué)與技術(shù)（信息處理） </p><p>　　姓 名 </p><p>　　C＃程序的回歸測試選擇<

3、;/p><p>　　Nashat Mansour and Wael Statieh（著）</p><p>　　我們目前正在對(duì)C ＃程序回歸測試選擇技術(shù)進(jìn)行研究。 C＃是比較新穎的，并且經(jīng)常被微軟使用的語言。.Net框架給程序員提供了一個(gè)堅(jiān)實(shí)的基礎(chǔ)來開發(fā)各種應(yīng)用?；貧w測試是在修改程序后進(jìn)行的?；貧w測試的選擇是指從原始的測試套件，以便讓程序再運(yùn)行，目的是在有信心的的前提下確定修改的部分是正確的，并

4、沒有影響到??程序的其他未修改部分選擇的測試用例一個(gè)合適的子集。在本文提出的回歸測試選擇技術(shù)C＃個(gè)體特征占了很大的一部分比例 。我們的技術(shù)是基于三個(gè)階段：第一階段建立一個(gè)受影響的類圖，包括那些受源代碼影響而產(chǎn)生變化的類。第二階段從基于C＃的特定功能受影響的類圖生成一個(gè)C ＃類間圖（ CIG） 。在這個(gè)階段，我們減少選擇的測試用例的數(shù)量。第三階段包括進(jìn)一步減少和分配權(quán)重測試用例優(yōu)先選擇的測試用例一個(gè)新的度量。我們已經(jīng)通過案例研究經(jīng)驗(yàn)驗(yàn)證所

5、提出的技術(shù)。實(shí)證結(jié)果顯示了C＃.Net程序所提出的回歸測試技術(shù)的實(shí)用性。</p><p><b>　　介紹</b></p><p>　　測試軟件是一個(gè)程序的生產(chǎn)生命周期的重要組成部分。測試是一種花費(fèi)大量精力和時(shí)間的工作。因此，合適的測試方法是必要的，這樣才能確保程序的可靠性。回歸測試的目的是有信心提供其修改后的程序的正確性。在計(jì)劃程序的最初發(fā)展階段，有一個(gè)集合T={t

6、1，t2 ， …… ，tN } 其中，N個(gè)測試案例保存和測試用例，方法覆蓋信息的表才能確定。當(dāng)一個(gè)程序被修改以后，回歸測試選擇需要的測試用例的子集，R，也可以選自集合T，為能夠再次運(yùn)行提供可信任的證明，即重新運(yùn)行上修改的程序，沒有意外的影響造成的變形這個(gè)目的。</p><p>　　這將是昂貴的回歸測試，匯集了大量的人力和財(cái)力。用例的回歸測試重復(fù)整套T用于最初的發(fā)展項(xiàng)目和不可靠的測試用例的選擇一個(gè)隨機(jī)子集從T。因

7、此，有必要從T合適的子集中選擇測試用例來運(yùn)行。回歸測試選擇通過將注意力集中在發(fā)生在程序的變化來降低測試成本。</p><p>　　一些回歸測試選擇的辦法已經(jīng)制定。數(shù)的方法和技術(shù)已經(jīng)解決了回歸測試程序的問題。的程序?yàn)榛A(chǔ)的技術(shù)的例子是：切片，數(shù)據(jù)流，防火墻和優(yōu)化[1-4] ；以及其他已經(jīng)處理過面向?qū)ο蟪绦颍?OO）的計(jì)劃。有些面向?qū)ο蠹夹g(shù)的回歸測試選擇是基于UML圖和只利用設(shè)計(jì)信息。這些技術(shù)的例子將在[ 5-9 ]

8、中會(huì)具體介紹 。此外，面向?qū)ο蟮姆阑饓夹g(shù)已經(jīng)被提出，在[10]中有詳細(xì)說明 。提出了面向?qū)ο蠡貧w測試擴(kuò)展防火墻的[ 11 ] 。他們的算法使得受影響的組件，并檢查組件之間的區(qū)別。然后，它會(huì)檢測所有直接或間接調(diào)用改性成分的元件。這些被稱為故障。作者發(fā)現(xiàn)，擴(kuò)展防火墻發(fā)現(xiàn)比正常的防火墻技術(shù)更能夠發(fā)現(xiàn)細(xì)微大量的故障?；诿嫦?qū)ο蟮募夹g(shù)都是基于Java和c++處理程序間控制流和這些語言的特性。處理Java結(jié)構(gòu)和功能，回歸測試選擇算法已經(jīng)開發(fā)了構(gòu)

9、建一個(gè)Java類間圖的控制流圖[ 12 ]的延伸。羅瑟梅爾等。[13]已經(jīng)解決了回歸測試選擇c++軟件技術(shù)問題，這是一個(gè)基于代碼技術(shù),構(gòu)建一個(gè)年級(jí)之間的控制流圖為了找到原始的和新項(xiàng)目的區(qū)別，是建立在為了尋找原來的和新的方案之間的差異的組間控制流圖基于代碼的技術(shù)。 Jang等</p><p>　　C＃是集成在微軟的。net框架的應(yīng)用程序開發(fā)一個(gè)相當(dāng)新的面向?qū)ο缶幊陶Z言。然而，沒有工作一直報(bào)道了回歸測試C＃應(yīng)用程序與

10、他們的特定功能。本文的目的是介紹，第一次，對(duì)C ＃程序代碼為基礎(chǔ)的回歸測試選擇技術(shù)。這種技術(shù)是一種三個(gè)階段的技術(shù)。在第一階段，我們建立一個(gè)受影響的類圖，涵蓋了由這種變化在源代碼中改變或影響的類。在第二階段，我們開發(fā)了一個(gè)C＃類間圖，它表示的方法中考慮的類的控制流在受影響的類圖和它們的相互關(guān)系。這一階段覆蓋的C＃特定功能擴(kuò)展了以前的面向?qū)ο蠹夹g(shù)。在第三階段，我們分配權(quán)重，利用建議的指標(biāo)來測試案例。根據(jù)權(quán)重，我們重新排序需要重新運(yùn)行測試用例

11、。我們表明我們的方法的有用性由呈遞應(yīng)用到的幾個(gè)例子的結(jié)果。</p><p>　　本文的結(jié)構(gòu)如下。第2節(jié)提出了一些假設(shè)，并說明所需的數(shù)據(jù)結(jié)構(gòu)。第3-5節(jié)描述我們的技術(shù)從試驗(yàn)的初始套件選擇測試用例。第6節(jié)提出并討論我們的實(shí)證結(jié)果。第7條提出進(jìn)一步的工作。第8節(jié)總結(jié)全文。</p><p><b>　　假設(shè)和符號(hào)</b></p><p>　　我們假設(shè)我

12、們有測試套件，T，包括方案的初期開發(fā)階段確定的測試案例。每個(gè)測試案例T中涉及的類的一個(gè)或多個(gè)方法。我們使用鄰接表來表示測試用例，方法覆蓋信息。在修改程序之后，我們還保存設(shè)置的直接改變方法，M1，和該組的刪除方法，M2。</p><p>　　這組受影響的方法為直接或間接調(diào)用更改，添加或刪除方法的方法。這些方法從由。NET框架生成的跟蹤文件中收集的。跟蹤文件的主要目的是測試和優(yōu)化的應(yīng)用程序后,</p>

13、<p>　　編譯和發(fā)布。我們的儀器跟蹤文件寫入每個(gè)調(diào)用另一個(gè)方法，方法的信息（例如，上午來電億元，其中A和B是類; m和n的方法）。 </p><p>　　表1列出了本文的其余部分中使用的符號(hào)。</p><p><b>　　技術(shù)概述</b></p><p>　　我們的技術(shù)測試?yán)x擇由三個(gè)階段組成。階段1。根據(jù)受影響的類圖（ACD）的測

14、試用例的選擇。</p><p>　　步驟1.生成包含ACD：所有包含修改和/或刪除的方法的類;基類和派生類中改變類;使用該改變的類（包含直接或間接調(diào)用的方法修改方法）的類。除了上課，排隊(duì)機(jī)還可以包含以下內(nèi)容：接口; Web和Windows服務(wù)，它是利用外部方法或類中的服務(wù)器或互聯(lián)網(wǎng)上的程序外; COM +組件這是由凈注冊(cè)和部署在服務(wù)器上，這樣很多應(yīng)用程序可以使用它的服務(wù)組件。使用COM組件的優(yōu)點(diǎn)是它的可重用性。&

15、lt;/p><p>　　步驟2.這一步涉及到在ACD的基礎(chǔ)上選擇子集合T’ ? T。我們使用的測試方法覆蓋表和測試套件T代表發(fā)現(xiàn)T'覆蓋ACD。 </p><p>　　階段2.基于C＃類間圖（CIG）測試用例的選擇。</p><p>　　步驟3.產(chǎn)生這是涉及到類的ACD中所有受影響的方法控制流圖的CIG。該圖作為輸入的類集合中的ACD，并建立其受影響的方法的控制

16、流圖。 </p><p>　　步驟4.這一步涉及到在CIG集合的基礎(chǔ)上，選擇集合T’’ ? T’。由于舊的和修改過的程序的CIG圖中，我們遍歷兩個(gè)CIG圖形相同的路徑遍歷的邊緣，直到我們到達(dá)目標(biāo)節(jié)點(diǎn)的差異。這個(gè)優(yōu)勢將被標(biāo)記為受影響或可能受影響的邊緣，將被保存。任何測試用例覆蓋此優(yōu)勢將被選定為重新運(yùn)行。</p><p>　　我們遍歷兩個(gè)圖的所有路徑，直到找到所有的設(shè)置受影響或可能受影響的邊緣

17、，然后用選擇測試用例T’’ ? T’來覆蓋它們。 </p><p>　　階段3.進(jìn)一步減少和優(yōu)先級(jí)。</p><p>　　第5步.該步驟包括減少從所述第一或第二相位選擇的測試用例的數(shù)目。在第一階段中，對(duì)于每個(gè)受影響的方法，我們隨機(jī)選擇一個(gè)測試用例覆蓋此方法。在第二階段，我們隨機(jī)選擇一個(gè)測試用例覆蓋每個(gè)受影響或可能受影響的邊緣。 </p><p>　　步驟6.優(yōu)先測試

18、用例T'和T'的基礎(chǔ)上，測試儀的選擇是否去兩相或止步于第一階段。</p><p>　　這六個(gè)步驟進(jìn)行了詳細(xì)的在下面的章節(jié)中說明。</p><p><b>　　基于ACD測試選擇</b></p><p>　　我們建立一個(gè)受影響的類圖包括含有修改或刪除的方法的類。然后，這些類的超類型確定并添加到受影響的類圖。我們將繼續(xù)尋找派生類的所

19、有類的ACD。但是，我們只選擇包含一個(gè)方法覆蓋修改/刪除的方法的類。在ACD中邊緣符號(hào)有以下幾種。</p><p>　?。ㄒ唬├^承邊緣：一個(gè)是父邊從派生類將基類。 </p><p>　?。ǘ┦褂眠吘墸河糜诋?dāng)一個(gè)類包含顯式調(diào)用另一個(gè)類的方法。</p><p>　?。ㄈ╅g接亞型邊緣：用于當(dāng)一個(gè)類包含一個(gè)重寫的方法和類包含一個(gè)方法重寫該方法。他們的將是兩個(gè)類之間的間接

20、亞型邊緣。</p><p>　　算法1給出了用于構(gòu)建一個(gè)受影響的類圖的算法。該ACD包括必須的類，接下來，擴(kuò)大了在C＃類間圖。 </p><p>　　在這個(gè)階段的測試案例的選擇包括選擇的測試用例集T'，涵蓋了類ACD受影響的方法。算法2示出了該算法，用于選擇T'。</p><p><b>　　基于CIG測試選擇</b></

21、p><p>　　5.1。建立了C＃類間圖。在C＃類間圖（CIG）是根據(jù)受影響的類圖。這個(gè)圖表示的類的ACD的不同方法之間的控制流。為了選擇需要被重新運(yùn)行測試案例，我們必須構(gòu)建兩個(gè)CIG圖的原始和修改程序。我們開始遍歷兩個(gè)方案的相同邊緣，直到我們發(fā)現(xiàn)相同的邊緣不同的目標(biāo)節(jié)點(diǎn)。我們紀(jì)念這個(gè)優(yōu)勢，因?yàn)槭苡绊懟蚩赡苁苡绊?，并將其添加到組受影響或可能受影響的邊緣。遍歷整個(gè)CIG圖之后，我們得到了一組邊標(biāo)記為受影響或可能受影響。

22、從這些優(yōu)勢，我們選擇的測試用例T’’ ? T’覆蓋它們。在下面的小節(jié)中，我們將詳細(xì)描述CIG。</p><p>　　5.1.1。邊符號(hào)為CIG圖。在C＃類間圖使用一組邊的識(shí)別方法調(diào)用和方法中語句之間的控制流的類型?？刂屏鬟叡硎镜倪B續(xù)報(bào)表的方法內(nèi)的流動(dòng)。呼叫邊表示一個(gè)方法的顯式調(diào)用。外部路徑的邊緣是標(biāo)識(shí)調(diào)用外部組件，例如類庫或COM +組件的邊緣。此邊表示該應(yīng)用程序用于執(zhí)行特定功能的外部組件的存在。道路邊表示或通過

23、調(diào)用方法總結(jié)了路徑。</p><p>　　在C＃類間圖每條邊都有用，導(dǎo)致被綁定到調(diào)用該方法接收器實(shí)例的類型的標(biāo)簽。用于CIG圖形邊緣符號(hào)表示如下：</p><p><b>　　控制流邊 </b></p><p><b>　?。ǚ椒ǎ┱{(diào)用邊緣 </b></p><p><b>　　外部邊緣的

24、路徑 </b></p><p><b>　　道路邊緣</b></p><p>　　5.1.2 。節(jié)點(diǎn)表示在CIG圖。類庫：是一組你用你的程序中編譯的類。它們不展開，因?yàn)樗且粋€(gè)可重用組件。C＃程序?qū)嵗擃惖囊粋€(gè)對(duì)象，并使用它的方法。我們代表用虛線圓圈節(jié)點(diǎn)和出口節(jié)點(diǎn)調(diào)用一個(gè)類庫。它們之間的路徑邊代表了類library。我們編碼類庫的名稱，里面的路徑，稱為類

25、庫節(jié)點(diǎn)的類和方法。如果我們改變了調(diào)用方法的類的庫里面，調(diào)用這個(gè)類庫中的所有節(jié)點(diǎn)肯定會(huì)被檢測到。所用的符號(hào)被表示在圖1。</p><p>　　調(diào)用一個(gè)Web服務(wù)。我們把這些服務(wù)做了一定的計(jì)算并返回一個(gè)值，該值使用的C ＃程序。這些類執(zhí)行特定的功能在互聯(lián)網(wǎng)上。我們代表通過調(diào)用和返回節(jié)點(diǎn)調(diào)用一個(gè)Web服務(wù)。我們編碼Web服務(wù)節(jié)點(diǎn)名稱和里面的call方法。這使我們能夠檢測到調(diào)用web服務(wù)的類。的符號(hào)被表示在圖2。<

26、/p><p>　　代表：像老的函數(shù)指針，它們指的是基于它實(shí)例化對(duì)象的類型的一些方法。</p><p>　　代表可以是多態(tài)的，允許委托綁定到許多方法。的符號(hào)被表示在圖3。 </p><p><b>　　指針：示于圖4。 </b></p><p>　　COM +組件。它們不會(huì)改變;它們被視為黑盒子。在COM +組件注冊(cè)到服務(wù)器上

27、找到類庫，可以從C＃程序調(diào)用。另外該組件可能是在互聯(lián)網(wǎng)上。我們編碼組件的名稱，類別，以及調(diào)用的方法。這個(gè)符號(hào)被表示在圖5。 </p><p>　　從XML文件中讀取并調(diào)用文件。有可能是C＃程序和XML文件之間的相互作用。閱讀弗羅曼的XML文件中的調(diào)用將被視為等同于調(diào)用一個(gè)內(nèi)部方法。</p><p>　　我們進(jìn)行編碼的XML文件的名稱和節(jié)點(diǎn)內(nèi)該文件的路徑。這使我們能夠檢測到調(diào)用的XML文件的

28、類。這個(gè)符號(hào)被表示在圖6。</p><p>　　調(diào)用執(zhí)行存儲(chǔ)過程。 C＃程序與存儲(chǔ)過程通過發(fā)送存儲(chǔ)過程的名稱SQL服務(wù)器序執(zhí)行它進(jìn)行交互。這些程序運(yùn)行某些查詢數(shù)據(jù)庫并將結(jié)果返回給程序。我們代表呼吁通過調(diào)用和返回節(jié)點(diǎn)的任何調(diào)用一個(gè)內(nèi)部方法的存儲(chǔ)過程。該節(jié)點(diǎn)將包含有關(guān)存儲(chǔ)過程的名稱和位置信息。這個(gè)符號(hào)被表示在圖7。</p><p>　　C＃中的事件就像調(diào)用一個(gè)方法來處理。每個(gè)事件都由一個(gè)事件處

29、理程序處理。你通過提供處理程序的地址引發(fā)事件;將接收事件的方法。調(diào)用一個(gè)處理程序類似于調(diào)用程序中的任何內(nèi)部方法。我們編碼稱為節(jié)點(diǎn)內(nèi)部的方法的名稱。每次調(diào)用處理程序是通過調(diào)用和返回節(jié)點(diǎn)表示。這個(gè)符號(hào)被表示在圖8。</p><p>　　活動(dòng)與多個(gè)處理程序。事件可能由多個(gè)處理程序辦理;處理該事件的所有方法都執(zhí)行。引發(fā)事件的節(jié)點(diǎn)將與所有的處理程序相關(guān)聯(lián)，如果事件x是處理Y，Z ，和q相關(guān)的代碼。當(dāng)事件被引發(fā)，處理程序執(zhí)行

30、的順序?qū)⑹荵，Z和q 。這個(gè)符號(hào)被表示在圖9。</p><p>　　異常處理。當(dāng)一個(gè)C ＃應(yīng)用程序遇到一個(gè)運(yùn)行時(shí)錯(cuò)誤，它會(huì)引發(fā)一個(gè)異常，并在應(yīng)用程序終止。 C＃允許結(jié)構(gòu)化異常處理，這是一種讓你的應(yīng)用程序從意想不到的錯(cuò)誤中恢復(fù)，或者至少有機(jī)會(huì)在關(guān)閉之前保存的數(shù)據(jù)。 C＃的. NET包含內(nèi)置的異常處理程序向我們提供有關(guān)異常的信息。此外，程序員可以創(chuàng)建catch塊捕捉拋出的異常。例外的是像對(duì)待程序中的任何其他聲明。&l

31、t;/p><p>　　5.1.3 。假設(shè)為CIG圖。</p><p>　?。?i）一項(xiàng)陳述的變化是一個(gè)修改。修改的方法的可執(zhí)行語句或刪除也是一個(gè)變化。這是很容易通過選擇測試用例穿越他們處理。</p><p>　?。ǘ┬薷脑贑＃中的變量或常量可以很容易地處理，因?yàn)檫@些常量放在一個(gè)枚舉的方法，每個(gè)方法調(diào)用此枚舉將受到影響。 </p><p>　?。?/p>

32、三）利用全球限定名稱為每個(gè)類。在全球范圍內(nèi)限定的名稱列出這樣一個(gè)類的所有層次。寫的層次結(jié)構(gòu)信息在每個(gè)點(diǎn)實(shí)例化。 </p><p>　?。ㄋ模┟看握{(diào)用外部方法（類庫，COM +組件，存儲(chǔ)過程，XML文件，Web服務(wù)）表示為一對(duì)呼叫節(jié)點(diǎn)和一個(gè)返回節(jié)點(diǎn)。它們與稱為路徑邊緣的邊緣連接起來。 </p><p>　?。ㄎ澹┟看握{(diào)用內(nèi)部方法被表示為一個(gè)對(duì)調(diào)用和返回的節(jié)點(diǎn)。 </p><

33、;p>　　5.2。測試用例的選擇。算法3給出尋找受影響或可能受影響的邊緣作為結(jié)果的算法。</p><p>　　最初CIG圖與經(jīng)過修改的比較。比較該算法在每一個(gè)屬于ACD之類的方法的入口節(jié)點(diǎn)被調(diào)用。它接受一個(gè)節(jié)點(diǎn)從CIG輸入并查找受影響或可能受影響的邊緣;邊緣覆蓋或達(dá)到修改后的代碼。算法4給出了算法來確定一組測試用例T''覆蓋受影響或可能受影響的邊緣。</p><p>

34、　　5.3 。第5步 – 減少測試用例?；貧w測試選擇技術(shù)的第一階段選擇T' ?T，涵蓋修改方法。在第一階段，T'是基于搜索的刪除/修改，影響的方法和選擇的所有測試用例可以覆蓋它們。在第二階段，T ''（ ? T' ）是基于選擇所有的測試用例覆蓋受影響或可能受影響的邊緣。而不是確定的T’（或T '' ）通過隨機(jī)選擇這些測試用例一個(gè)人的基礎(chǔ)上選擇的所有測試用例遍歷受影響的方法（或受影響

35、/潛在受影響的邊緣），我們可以減少T'或T ''的大小。我們將產(chǎn)生的測試結(jié)果集稱為T’’’,即T’或T’’的一個(gè)子集。</p><p>　　在大量的T'或者T’'的情況下，若為了減少回歸測試時(shí)間為目的，這種減少的方式應(yīng)該是最合理的。</p><p><b>　　實(shí)證結(jié)果</b></p><p>　　6.1

36、 。實(shí)證過程。回歸測試選擇技術(shù)應(yīng)用到三個(gè)應(yīng)用程序：歸檔程序，用于出售的存貨采購訂單的應(yīng)用程序，以及處理一個(gè)軟件公司的內(nèi)部任務(wù)的任務(wù)管理應(yīng)用程序。對(duì)于每個(gè)應(yīng)用程序，我們使用不同的版本，導(dǎo)致一共有六個(gè)主題方案。表2列出了這些主題方案的特點(diǎn)。生成每個(gè)版本包括原始測試套件T，一個(gè)檢測方法的覆蓋表（ AT） ，和一個(gè)跟蹤文件的初始信息和數(shù)據(jù)結(jié)構(gòu)。每個(gè)程序邏輯發(fā)生變化。然后，這三個(gè)階段的技術(shù)是根據(jù)以下三個(gè)標(biāo)準(zhǔn)應(yīng)用到每個(gè)主題程序。我們?cè)u(píng)估了回歸測試選

37、擇技術(shù)。</p><p>　?。ㄒ唬┯捎洖門'或T技術(shù)''選擇的測試用例的數(shù)量。</p><p>　?。ǘ┌菪詻Q定了其技術(shù)選擇修改準(zhǔn)確的測試案例[18]的程度。修改揭示試驗(yàn)是指那些產(chǎn)生不同的輸出比原來的程序。先生是修飾透出測試的數(shù)量。當(dāng)一個(gè)回歸測試選擇方法選擇其中的一些測試（記為SMR ）的，包容性是通過100 （ SMR / MR）給出。</p>

38、<p>　?。ㄈ┚葲Q定了該技術(shù)避免了選擇的測試用例，不會(huì)產(chǎn)生不同的輸出比原來的程序[18]。該未被修改的部分揭示的測試由核磁共振表示。測試用例是不可修改揭示省略（記為onmr ）。精度是由100 （ onmr / NMR）給出。</p><p>　　6.2 。結(jié)果與討論。表3給出了結(jié)果六個(gè)主題方案的摘要。 N是測試用例的總數(shù)（在初始套裝）; N'是第一階段結(jié)束后選擇的測試用例數(shù)目（及百分

39、比）; N''是第二階段后選擇的測試用例數(shù)目（及百分比）。表4和表5示出了精度和包容用于將所述第一和第二階段分別經(jīng)過六個(gè)例子。表6給出了N'''進(jìn)一步的還原步驟（步驟5）對(duì)T ''之后選定的測試的次數(shù)。</p><p>　　選擇的測試用例的數(shù)目被認(rèn)為是比較小的（表3） ，對(duì)于N’是從4.3 ％至45 ％（第一階段之后）和對(duì)于N''是從1.5

40、％至35％（應(yīng)用第二階段之后）。這表明我們的方法并不導(dǎo)致在測試用例程序修改后重新運(yùn)行的數(shù)量的減少。</p><p>　　表4和表5描述的精確度和包容性的結(jié)果為前兩個(gè)階段的技術(shù)。 T’的包容性是100％，這意味著所有的修改顯露測試被選中。 T’的精度是相當(dāng)高的，并在71％和96％，這意味著，未被修改的部分揭示測試有限數(shù)量的選擇范圍。表5顯示，T的包容''仍然是100％。也就是說，我們的技術(shù)的第二階段

41、也是安全的選擇所有的修改顯露測試。對(duì)T'的精度是接近100％，這意味著幾乎沒有任何未被修改的部分揭示的測試都被選中。我們也注意到，第二階段（對(duì)T''）后的精度比第一階段（對(duì)T'）高，為同一包容性水平。</p><p>　　表6給出了進(jìn)一步削減步驟（步驟5在第3階段）的結(jié)果，這表明T’’’的包容性已下降（低于26％）與100％T'和T'’的比較。這種下降的發(fā)生是由于疏

42、忽，涵蓋了相同的元素所有冗余和多重測試。因此，我們的方法的步驟5中不提供安全保障。然而，精度提高到100％，所有未被修改的部分揭示試驗(yàn)被省略。我們建議使用此步驟，以及第3階段的優(yōu)先級(jí)僅其中N'或N''大，我們有非常有限的時(shí)間進(jìn)行回歸測試;這會(huì)在緊急情況下，更多的回歸測試時(shí)間是太寶貴了，導(dǎo)致系統(tǒng)的VIS-A-VIS暫停服務(wù)申請(qǐng)。</p><p>　?。ǖ却瓿苫貧w測試） 。此外，所選擇的在第

43、一階段的測試用例集T'將包括在ACD受影響或可能受影響的邊緣。因此，構(gòu)建CIG圖，在第二階段，將導(dǎo)致選擇一個(gè)集合T ' ? T'重新運(yùn)行。測試人員可能沒有時(shí)間去為兩個(gè)階段。他們可以停在受影響的類圖和水平選擇并運(yùn)行所有的測試用例T' 。這取決于下列條件：</p><p>　　TACD + Tselect T’ + Trun T’</p><p>　　<

44、TACD + Tselect T’ + TCIG + Tselect T’’ + Trun T’’ , (1)</p><p>　　其中TG是構(gòu)建圖G的時(shí)候，Tselect X是時(shí)間選擇測試x的子集，并且Trun T是運(yùn)行測試的子集時(shí)X。</p><p>　　我們的方法有一定的局限性，當(dāng)它被應(yīng)用到大型程序。本的算法的復(fù)雜性是在二次CIG節(jié)點(diǎn)的數(shù)目。對(duì)于大的共成像，我們的技術(shù)

45、可以是昂貴的。因此，我們需要探討如何降低成本，仍然維持有效的回歸測試。</p><p>　　測試用例的進(jìn)一步工作</p><p>　　早期的測試用例優(yōu)先級(jí)需要繼承運(yùn)行測試用例的最高優(yōu)先級(jí)。優(yōu)先級(jí)化技術(shù)可提供早期發(fā)現(xiàn)故障在修改后的程序。測試用例可以根據(jù)不同的指標(biāo)進(jìn)行優(yōu)先排序。它們可以根據(jù)所涉及的方法或語句的數(shù)目來區(qū)分優(yōu)先次序。然而，根據(jù)語句的數(shù)量優(yōu)先的測試用例可能最終運(yùn)行，首先，測試用例，覆

46、蓋大量的語句，但少量的修改后的代碼。類似的觀點(diǎn)也適用于方法。</p><p>　　由于我們的測試選擇技術(shù)是基于所有受影響或可能受影響的邊緣的安全范圍，他們可能會(huì)導(dǎo)致選擇了大量的測試用例。因此，優(yōu)先選擇的測試用例可能進(jìn)一步減少測試用例有用。我們建議采用改性方法的數(shù)量新的優(yōu)先級(jí)技術(shù)。每個(gè)測試用例的大小依賴于有多少這個(gè)測試用例覆蓋修改或影響的方法。</p><p>　　我們不同于非階級(jí)庫更改治療

47、類庫的變化。由于庫類是可重用的組件，許多應(yīng)用程序，它以最高的優(yōu)先級(jí)分配給測試案例，涵蓋庫類的變化是很重要的。因此，對(duì)于一個(gè)測試用例，鈦，涵蓋庫類，我們分配的最大重量;即W （鈦）= 1.0 。對(duì)于非庫類，我們提出另一種表達(dá)式來查找測試用例的優(yōu)先級(jí)權(quán)重，鈦，如下所示：</p><p>　　W（鈦） =凈重* CNW /噸， （ 2 ）</p

48、><p>　　其中NW是受鈦修改/刪除受影響的方法的數(shù)量， CNW是涵蓋西北方法的類的數(shù)量，和MT是在程序方法的總數(shù)。的優(yōu)先級(jí)權(quán)重成比例的影響的方法和類，歸一化相對(duì)于方法的總數(shù)兩個(gè)多樣性。也就是說，所選擇的測試用例更重要的是，如果它涵蓋多個(gè)類別之間進(jìn)行分配更多的方法。測試用例是按重量W （Ti）的命令。這有助于在第一選擇更為重要的測試用例。</p><p><b>　　結(jié)論</

49、b></p><p>　　我們已經(jīng)提出了一個(gè)基于識(shí)別變化的程序回歸測試選擇技術(shù)。該技術(shù)涵蓋了C＃的特定功能，并包括相關(guān)的NET功能。該技術(shù)是能夠選擇的亦有修正揭示測試用例適合的子集。這些子集顯示在選定的包容性和精度的適當(dāng)水平的測試數(shù)量的減少。這已被證明的實(shí)證結(jié)果。盡管本主題節(jié)目的有限數(shù)目和大小，其結(jié)果提供置信在我們的技術(shù)的有效性。然而，我們的技術(shù)也提供了測試儀可靈活地使用與包容性和精度要求的水平相適應(yīng)的階段

50、和步驟，并允許回歸測試的時(shí)間。</p><p><b>　　參考文獻(xiàn)</b></p><p>　　[1] H.阿格拉瓦爾， JR霍根， EW克勞薩和SA倫敦， “增量回歸測試”在訴訟上的軟件維護(hù)問題國際會(huì)議（ ICSM '93 ），頁348-357，加拿大蒙特利爾， 1993年9月。</p><p>　　[ 2 ] R·古普塔

51、， MJ哈羅德，和ML Soffa公司， “程序slicingbased回歸測試技術(shù)”軟件測試驗(yàn)證和可靠性，第一卷。頁83-111 ，1996 。</p><p>　　[ 3 ] HKN在軟件維護(hù)的IEEE國際會(huì)議論文集梁和L.白， “防火墻概念的回歸集成測試兩個(gè)控制流和數(shù)據(jù)流” （ ICSM 92年） ，頁262-271 ，奧蘭多，佛羅里達(dá)州，美國，1992年11月。</p><p>　

52、　[ 4 ] N.曼蘇爾和K.埃爾 - Fakih ， “模擬退火和遺傳算法的最優(yōu)回歸測試”雜志SoftwareMaintenance的研究與實(shí)踐，第一卷。頁19-34 ， 1999 。</p><p>　　[ 5 ] LC白里安，華拉比什， K.比伊斯特和G Soccar ， “自動(dòng)化影響分析和基于UML設(shè)計(jì)的回歸測試選擇”在軟件維護(hù)（ ICSM '02 ）第18屆IEEE國際會(huì)議論文集，頁252-26

53、1 ，加拿大蒙特利爾，2002年10月。</p><p>　　[ 6 ]華樂TRAON ， T. J'eron ， J.-M. J'ez'equel ，和P.莫雷爾， “高效的面向?qū)ο蟮募蓽y試和回歸測試” IEEE交易的可靠性，第一卷。頁12-25 ，2000 。</p><p>　　[ 7 ]華武和J.奧夫特， “維護(hù)不斷發(fā)展的基于組件的軟件withUML ，

54、”在軟件維護(hù)與再造（ CSMR 03年） ，頁133-142，第七屆歐洲會(huì)議論文集，貝內(nèi)文托，意大利，2003年3月。</p><p>　　[8] Q.-U.-A.法魯克， MZZ伊克巴爾， ZI馬利克和A.在第三屆國際研討會(huì)論文集納迪姆， “選擇性基于狀態(tài)機(jī)回歸測試的一種方法”在基于模型的測試（ AMOST '07） ，頁44-52進(jìn)展，英國倫敦，2007 。</p><p>　

55、　[ 9 ]全曼蘇爾和H. Takkoush ，在IASTED國際會(huì)議論文集軟件工程與應(yīng)用，第96-101頁，波士頓，大眾，美國2007年11月“基于UML的回歸測試，面向?qū)ο筌浖夹g(shù)”。</p><p>　　[ 10 ] P.夏，十力，直流功夫等， “一個(gè)技術(shù)，面向?qū)ο筌浖倪x擇性再驗(yàn)證”雜志SoftwareMaintenance的：研究與實(shí)踐，第一卷。頁217-233 。在軟件工程10進(jìn)展。</p>

56、;<p>　　[ 11 ]在對(duì)軟件維護(hù)的IEEE國際會(huì)議論文集（ ICSM 05年） ??，頁695-698 K.賈比爾，和B羅賓遜， “擴(kuò)展防火墻面向?qū)ο蟮幕貧w測試，利用” ，匈牙利布達(dá)佩斯， 2005年9月。</p><p>　　[ 12 ] MJHarrold ， JA瓊斯，T.李，在訴訟的第16屆ACM SIGPLAN會(huì)議的面向?qū)ο蟮木幊滔到y(tǒng)，語言和應(yīng)用程序（ OOPSLA '01

57、）等人， “回歸測試選擇的Java軟件”，頁312-326 ，坦帕灣，佛羅里達(dá)州，美國， 2001年10月。</p><p>　　[ 13 ] G.羅瑟梅爾， MJ哈羅德和J. Dedhia ， “回歸測試選擇的C + +軟件”中國軟件測試驗(yàn)證和可靠性，第一卷。頁77-109 。</p><p>　　[ 14 ] YK張， M.蒙羅和YR權(quán)“，選擇回歸測試的C + +程序的改進(jìn)方法”中國軟

58、件維護(hù)與演化的研究與實(shí)踐，第一卷。頁331-350 ，2001。</p><p>　　[ 15 ] W. Li和MJ哈羅德，在訴訟的IEEE國際會(huì)議上的軟件維護(hù)（ ICSM '08） ，頁267-276 ，北京，中國，十月的“使用隨機(jī)測試選擇，以獲得信心在修改后的軟件” 2008。</p><p>　　[16]在第1個(gè)印度軟件工程大會(huì)論文集PK Chittimalli和MJ哈羅德，

59、“回歸測試選擇對(duì)系統(tǒng)要求” ，頁87-96 ，海得拉巴，印度，2008 。</p><p>　　[ 17 ]十曲， MB科恩和G羅瑟梅爾， “ Configurationaware回歸測試：采樣和優(yōu)先級(jí)進(jìn)行了實(shí)證研究， ”國際學(xué)術(shù)研討會(huì)軟件測試與分析（ ISSTA '08） ，第75頁的論文 - 85 ，西雅圖，華盛頓州，美國， 2008年7月。</p><p>　　[ 18 ]

60、T. L.墳?zāi)梗?M. J.哈羅德， J.-M.金， A.波特，和G羅瑟梅爾“的回歸測試選擇技術(shù)的實(shí)證研究， ”在軟件工程國際會(huì)議論文集（ ICSE 98年） ，頁188-197 ，日本京都， 1998年4月。</p><p>　　Regression Test Selection for C# Programs</p><p>　　Nashat Mansour and Wael Stat

61、ieh</p><p>　　We present a regression test selection technique for C# programs. C# is fairly new and is often used within the Microsoft .Net framework to give programmers a solid base to develop a variety of

62、applications. Regression testing is done after modifying a program. Regression test selection refers to selecting a suitable subset of test cases from the original test suite in order to be rerun.It aims to provide confi

63、dence that the modifications are correct and did not affect other unmodified parts of </p><p>　　Introduction</p><p>　　Testing software is an important part of the production life cycle of a prog

64、ram. Testing is an expensive activity. Hence, appropriate testing methods are necessary for ensuring the reliability of a program. Regression testing aims to provide confidence in the correctness of a program after its m

65、odification. During the initial development of the program, a set T = {t1, t2, ……, tN} of N test cases is saved and a table of test case-method coverage information can be determined. After a program is m</p><

66、p>　　It would be costly for regression testing to repeat the whole set of test cases T used in the initial development of the program and unreliable to choose a random subset of test cases from T. Therefore, it is nece

67、ssary to select a suitable subset of test cases from T to run. Regression test selection reduces the cost of testing by focusing on the changes that take place in the program. </p><p>　　A number of regressio

68、n test selection approaches have been developed. Several approaches and techniques have addressed the problem of regression testing for procedural programs. Examples of procedural-based techniques are: slicing, data flow

69、, firewall, and optimization [1–4]. Others have dealt with object oriented (OO) programs. Some of these OO techniques for regression test selection are based on UML diagrams and make use of only design information. Examp

70、les of these techniques are presented i</p><p>　　C# is a fairly new object oriented programming language which is integrated in the Microsoft’s .NET framework for application development. However, no work ha

71、s been reported on regression testing C# applications with their specific features. The objective of this paper is to present, for the first time, a code-based regression test selection technique for C# programs. This te

72、chnique is a three phase technique. In the first phase, we build an Affected Class diagram covering the classes that are c</p><p>　　This paper is organized as follows. Section 2 presents some assumptions and

73、 describes required data structures. Sections 3–5 describe our technique for selecting test cases from the initial suite of tests. Section 6 presents and discusses our empirical results. Section 7 proposes further work.

74、Section 8 concludes the paper.</p><p>　　2. Assumptions and Notation</p><p>　　We assume that we have the test suite, T, consisting of the test cases determined during the initial development of t

75、he program. Each test case in T covers one or more methods in the classes. We use an adjacency table to represent the test case-method coverage information. After modifying the program, we also save the set of directly c

76、hanged methods, M1, and the set of deleted methods, M2.</p><p>　　The set of affected methods are the methods that are directly or indirectly calling the changed, added, or deleted methods. These methods are

77、gathered from the trace file produced by the .Net framework. The main purpose of the trace file is for testing and optimization after an application </p><p>　　is compiled and released. We instrument the trac

78、e file by writing information about each method that calls another method (e.g., A.m calls B.n, where A and B are classes; m and n are methods).</p><p>　　Table 1 lists the notation used in the rest of the pa

79、per.</p><p>　　3. Technique Overview</p><p>　　Our technique for test case selection consists of three phases. Phase-1. Test case selection based on the affected class diagram (ACD).</p>&l

80、t;p>　　Step 1. Generate the ACD that contains: all the classes that contain modified and/or deleted methods; the base classes and derived classes of the changed classes; the classes that use the changed classes (contai

81、ning methods that call directly or indirectly the modified methods). In addition to classes, the ACD may also contain the following: Interfaces; Web and windows services, which is the use of an external method or class o

82、utside the program on a server or on the internet; COM+ components wh</p><p>　　Step 2. This step involves selecting T’ ? T based on the ACD. We use the test-method coverage table and the test suite T for fin

83、ding T’ that cover ACD.</p><p>　　Phase-2. Test case selection based on the C# Interclass Graph (CIG).</p><p>　　Step 3. Generate the CIG which is a control flow graph that involves all the affect

84、ed methods of the classes in ACD. The graph takes as input the set of classes in ACD and builds the control flow graphs of their affected methods.</p><p>　　Step 4. This step involves selecting a set T’’ ? T’

85、 based on the CIG. Given the CIG graph of the old and the modified programs, we traverse the same paths in the two CIG Graphs by traversing the edges until we reach a difference in the target nodes. This edge will be mar

86、ked as affected or potentially affected edge and will be saved. Any test case that covers this edge will be selected for rerunning. </p><p>　　We traverse all the paths of the two graphs until we find all the

87、 set of affected or potentially affected edges and select the test cases T’’ ? T’ that cover them.</p><p>　　Phase-3. Further reduction and prioritization.</p><p>　　Step 5. This step involves red

88、ucing the number of test cases selected from the first or second phase. In the first phase, for each affected method, we randomly select one test case covering this method. In the second phase, we randomly select one tes

89、t case covering each affected or potentially affected edge.</p><p>　　Step 6. Prioritize test cases in T’ or T’’ based on the tester’s choice whether to go for the two phases or stop at the first phase.</p

90、><p>　　The six steps are explained in detail in the following sections.</p><p>　　4. Test Selection Based on ACD</p><p>　　We build an Affected Class Diagram that includes classes that c

91、ontain modified or deleted methods. Then, the supertypes of these classes are determined and added to the Affected Class Diagram. We continue finding the derived classes for all the classes in ACD. But, we select only cl

92、asses that contain a method overriding a modified/deleted method. The edge notations used in ACD are the following.</p><p>　　(i) Inheritance edge: is a supertype edge going from the derived class to the base

93、 class. </p><p>　　(ii) Use edge: is used when a class contains a method that explicitly calls another class</p><p>　　(iii) Indirect subtype edge: is used when a class contains an overridden meth

94、od and a class contains a method overriding that method. Their will be an indirect subtype edge between the two classes.</p><p>　　Algorithm 1 presents the algorithm used for building an Affected Class Diagra

95、m. The ACD includes the classes that need to be, next, expanded in the C# interclass graph.</p><p>　　Test case selection in this phase involves selecting the set of test cases T’ that cover affected methods

96、of the classes in ACD. Algorithm 2 shows the algorithm for selecting T’.</p><p>　　5. Test Selection Based on CIG</p><p>　　5.1. Building the C# Interclass Graph. The C# interclass graph (CIG) is

97、based on the Affected Class Diagram. This graph represents the control flow between the different methods of the classes in the ACD. In order to select the test cases that need to be rerun, we have to build two CIG graph

98、s for the original and modified programs. We begin traversing the same edges of the two programs until we detect a different target node of the same edge. We mark this edge as affected or potentially affected</p>

99、<p>　　5.1.1. Edge Notation for the CIG Graph. The C# interclass graph uses a set of edges to identify the type of method calls and the control flow between statements inside the method. A control flow edge represent

100、s the flow of consecutive statements inside a method. The call edge represents an explicit call to a method. The external path edge is an edge that identifies a call to an external component such as a class library or a

101、COM+ component. This edge denotes the existence of an external componen</p><p>　　Each edge in the C# Interclass Graph has a label with the type of receiver instance that causes the method to be bound to the

102、call. The edge notation for the CIG graph is represented as follows:</p><p>　　Control Flow edge </p><p>　　(Method) Call edge</p><p>　　External Path Edge</p><p><b&g

103、t;　　Path edge</b></p><p>　　5.1.2. Nodes Represented in the CIG Graph. Class library: is a set of compiled classes you use inside your program. They are not expanded because it is a reusable component.

104、The C# program instantiates an object of that class and uses its methods. We represent the call to a Class library by a dotted circle node and an exit node. There is a path edge between them which represents the path ins