4． efg_edges_added =
{(Edit,Edit),(Edit,Cut),(Edit,Copy),(Edit,Paste),(Cut,Edit),(Copy,Edit),(Paste,Eidt)}
表1 原始GUI的4個事件序列
表1 顯示4個事件序列用來測試原始GUI。列1是測試用例號，列2是測試用例的事件序列，列3是在G-CFG圖中用于測試用例的事件，列4是G-CFG圖中的邊。通過測試以下測試用例可以得到以下結果：
1． 由于Print在GUI的結構中被刪除了，因此事件1對于修改后的GUI是非法的。
2． 因為（Cut，Paste）和（Copy，Cut）在GUI的結構被刪除了，事件序列3和4 對于修改后的GUI是非法的。
3． 事件序列2仍然是合法的，因為Cut在修改后的GUI中仍然是可用的。（只要初始的狀態下Edit已經被執行了）
查看原始和修改后的GUI結構，我們知道，事件3和4是可以被修復的以獲得合法的事件序列。對于事件3的修改可以是<Cut; Edit; Paste>；對于事件序列4的修改是<Copy; Edit; Cut; Edit; Paste>。這兩個修改后的序列就是合法的了，并且可以用于修改后的GUI。而對于事件1的修改就不明顯了，因為它包含了在修改后的GUI中不存在的事件Print。在這個例子中，這個事件序列將作為不可修復的測試用例被丟棄。本例說明了一些不可用測試用例是不可以被修復的。在修復工作之后，測試設計人員還要從剩下的3個事件序列中進行選擇，然后使用它們進行回歸測試。需要注意的是，時間2原本就是可以在修改后的GUI上使用的，因此當在事件序列中沒有任何改變時，測試設計人員可以選擇不重新運行該事件序列（除非在暗藏的代碼中進行了改動）。在本例中，剩下的事件序列3和4加上其他新的測試用例，將被用于回歸測試。
對于GUI來說，因為某些改變會造成測試用例不可用，因此在測試用例被修復前，可能要經過很多次的修改工作。我們的技術就是通過多種方式修復測試用例。
也許你會注意到，僅僅在G-CFG中添加新的事件或是關系而不刪除任何的事件或關系，將不會導致事件序列非法。從原始測試集合中得到的事件序列或是沒有使用任何新的事件，或是沒有覆蓋任何新的關系。如果關系和事件都沒有被刪除，則原有的測試用例仍然可以在修改后的GUI上使用。
5 回歸測試
我們的回歸測試技術包含2個方面：測試機將測試用例進行分類，是可用的還是不可用的；如果是不可用的，還要判斷該測試用例是否可被修復。第二部分是修復機，修復可以被修復的測試用例。為了說明清楚，我們將這兩部分分開進行了介紹，但在實際的應用中可以將這兩部分合二為一的。
回歸測試員要將原始GUI和修改后的GUI的G-CFG圖和G-call圖作為輸入，以及修改后的GUI的測試狀態SI，還有原始GUI的測試用例。測試機將原始測試用例分割為可用測試用例和不可用測試用例。關鍵的在于，它還將判斷不可用的測試用例是否可以被修復。很顯然的是，如果一個測試用例的初始狀態在修改后的GUI中仍然是可用的，并且它的事件序列可以被修改為合法序列，則該測試用例就是可修復的。為了使GUI事件序列合法，我們從編譯技術中借用了錯誤發現技術；忽略事件或是將一個新事件插入其中直到生成一個合法的事件序列。這個序列只能通過忽略事件或是包含修改后的GUI事件得到。最終，我們將一個可修復的測試用例定義為：
定義：如果一個不可用測試用例的初始狀態是存在的，并且它的事件序列可以被修復為合法的，例如(ei,ek>i∈E)或者{(ei,ex),(ex,ek>i)∈E}其中1<=i<=n，則該測試用例是可以被修復的。
圖4 新的回歸測試方法
對于不可用測試用例，一部分將被修復并用于回歸測試，而那些不可修復的測試用例將被丟棄。圖4表示了這個新的回歸測試方法。需要注意的是，用于測試GUI新增加部分的測試用例是不可能通過修復原有的測試用例得到的，但這部分測試用例也是回歸測試集合必不可少的一部分。
回歸測試包含以下幾個組成部分：
- 測試機：將原始的測試用例分為（1）可用測試用例，（2）可修復的不可用測試用例，和（3）不可修復的不可用測試用例。
- 修復機：通過增加和刪除測試用例中的事件來修復不可用測試用例，使這些測試用例符合修改后的GUI的事件序列。
圖5 回歸測試的組成部分和它們之間的關系
圖5顯示了回歸測試中的測試機和修復機以及它們之間的聯系。該圖還說明了這些組成部分之間的關系。Test Case Generator和Coverage Evaluator生成新的測試用例用于測試GUI新的部分。這樣，修復的、新的和原本可用的測試用例共同組成了回歸測試用例集合。下面我們將介紹測試機和修復機設計的具體細節。
5.1 測試機
測試機的首要功能是標識不可用測試用例以及其中哪些是可以被修復的。測試機首先通過遍歷G-CFG圖決定了在測試用例中的事件序列是否可重用。
為了使我們的分析有效，我們通過一系列合理的假設簡化分析。我們假設這些事件和成員：（1）有獨一無二的名字（重新命名可以用于完成這個建設）和（2）除非被修改，否則在不同的GUI版本間名字是不改變的。例如，如果事件File沒有被修改，則它在修改后的GUI中的名字仍然為File。如果一些事件和成員被重新命名了，則GUI設計者必須要把這些改變記錄到日志中，這樣測試設計者就會了解到這些改變。
通過這些假設，我們可以簡單地添加或刪除G-CFG圖和G-call樹來自動對GUI的改變標識并進行分類。簡單地通過在控制流圖上查找增加或刪除已經用于自增數據流和代碼最優化以及增加測試。
G-CFG圖中所代表的成員事件，可以通過增加或刪除一個點或邊而改變。假設GCFG0和GCFGm分別代表了出現在原始GUI和改變后的GUI的一個成員，則通過集合相減就可以判斷出是否有改變。在這里，函數Vertices和Edges分別返回的是集合V（點集）和集合E（邊集）。
1．G-CFG圖中所有增加的點的集合：
vertices_added?Vertices(GCFGm)-Vertices(GCFG0);
2. 從原始G-CFG中刪除的所有點的集合：
vertices_deleted?Vertices(GCFG0)-Vertices(GCFGm);
3. 所有新添加的邊的集合：
efg_edges_added?Edges(GCFGm)-Edges(GCFG0);
4. 從原始G-CFG中刪除的邊的集合：
efg_edges_deleted?Edges(GCFG0)-Edges(GCFGm);
像第4部分描述的那樣，以上的集合用于標識不可用的測試用例。
類似地，一棵調用樹也可以通過增加或刪除一個成員或邊而改變。假設G0和Gm分別代表原始GUI和修改后的GUI的調用樹。兩者之間的改變可以通過以下集合的改變得到。在這里，Nodes和CompEdges函數分別返回的是調用樹的N和B集合。
1．添加到G-call圖的成員集合：
components_added?Nodes(Gm)-Nodes(G0);
2. 從G-call圖中刪除成員的集合：
components_deleted?Nodes(G0)-Nodes(Gm);
3. 添加到G-call圖中的邊：
comp_edges_added?CompEdges(Gm)-CompEdges(G0);
4. 從G-call圖中刪除的邊的集合：
comp_edges_deleted?CompEdges(G0)-CompEdges(Gm);
需要注意的是G-CFG圖的邊和G-call圖的邊之間的區別。一個G-CFG圖的邊都是有序對如(ex,ey),其中ex和ey是事件，而G-call圖的邊是有序對如(Cx，Cy)，其中Cx和Cy是成員。G-call圖中的一條邊(Cx，Cy)代表了所有邊(ey, ex)的集合，ey是成員Cx中激活Cy的事件。
修改集包括以上用于標識不可用測試集合。特別以下2個集合：
1. vertices_deleted
2. edges_deleted?efg_edges_deleted∪EventEdges(comp_edges_deleted)，其中EventEdges是函數，輸入是G-call邊的集合，返回的是相應邊的事件形式。
為了標識不可用測試用例，我們一共使用了至少2種不同的技術。首先，稱作圖匹配技術，輸入一個事件序列< e1;e2;…;en>，判斷(ei, ei+1)對于修改后的G-CFG圖在1<i<n-1是否是有效的邊。這項技術對于小型的測試運行簡單，表現出很好的運行效率。另一個可選的技術，是在第6章中說明的，對于大型的測試要比圖匹配更加有效率。該技術是在2個字節向量EDGES-MODIFIED和EVENTS-MODIFIED中記錄GUI的改變。每個測試用例都與2個字節向量EVENTS-USED和EDGES-USED相關聯。因此測試用例是可用/不可用可以通過非常方便的AND（與）運算得到。通過運用這個信息，檢測機標識那些因為改變而變得不可用的測試用例。例如，如果一個事件e從GUI中刪除，則所有使用事件e的測試用例都是不可用的。一個GUI的改變可能會造成多個集合的改變，因為同一個改變，一個測試用例可能被多次標識為不可用測試用例。以后章節中我們還將說明，多次標識對于測試用例的修復并沒有影響。
一旦不可用測試用例被標識了，他們將被修復機修復，這將在下面描述。
5.2 修復機
修復機修復（算法將在圖6中描述）非法的事件序列，使它們可以在修改后的GUI上執行。一個非法事件序列或是使用一個刪除的事件或是一個刪除的邊。如果在事件序列的第i位置的事件ei被刪除，則事件序列修復機會ei從事件序列中刪除。然后，為了得到一個合法的事件序列，事件序列修復機將從左向右瀏覽事件序列，從第i+1位置開始，直到找到一個事件ej符合以下任何一個情況：(1)< ei-1;ej>對于修改后的GUI是合法的事件序列，(2)從修改后的GUI的所有事件中的任何一個事件ex，使得< ei-1; ex;ej>對于修改后的GUI是合法事件序列。
修復一個事件序列可能存在著很多種方式。當找到多種途徑時，所有的這些修復都將用于生成更多的測試用例。
一旦事件ej找到了，則子串< ei;…;ej-1>將從事件序列中被刪除，在第二種情況下，插入事件ex。圖7(a)說明了這兩種情況。在第一種情況下，修復機從ei+1到en中查找ej；在第二種情況下，從修改后的GUI的所有事件中查找事件ex, ex在e j-1執行之后而ej在ex執行之后。
通常情況下，這個方法被擴展到尋找一系列事件串< ep;…;eq>使得< ei-1; ep;…;eq;ej>在修改后的GUI上是合法的事件序列。然而，計算這樣一個字符串的過程是很費時的，并且通過這樣的方式生成的測試用例會與原始的測試用例非常不同。我們的目標是要生成與原始的測試用例相近的，在必要的情況下需要重新測試GUI的功能。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
