本文中，我們將說明對于GUI而言，大量測試用例的不可用是一個嚴重的問題。我們將展示一個嶄新GUI回歸測試技術，首先在GUI結構發生變化時自動判斷測試用例是否仍然可用。而后判斷那些不可用的測試用例中哪些是可以被修復的并應用到修改后的GUI。最后修復這些可修復的測試用例。我們的技術整合到GUI測試框架中，對于任意一個測試用例，都將自動在GUI執行。我們將通過兩個測試案例說明我們的技術是有效的，可以使很多測試用例修復，時間執行效率也是可以接受的。
1 介紹
GUI在當今的軟件系統中非常普及，占據了軟件代碼的半壁江山。一個軟件系統的GUI的正確性對于確保整個軟件系統的順利運行至關重要。一個普遍的方法是通過對GUI進行測試來確定GUI的正確性。GUI測試要求測試用例（一系列激活GUI窗口的GUI事件）在GUI中產生并執行。然后，目前對于獲取GUI測試用例的可行技術是基于資源，需要大量的人工干預。盡管目前有少量的有關自動產生GUI測試用例的文獻資料，但在實際操作中，測試用例仍然是通過手工的使用[抓取/重放]工具得到的。
當使用[抓取/重放]工具時，測試人員需要與被測應用程序（AUT，application under test）有所互動；[抓取]可以在文件中保存這些互動，以便[重放]工具可以將它們重放。經驗證明，通過使用[抓取/重放]工具，為50個來自不同的窗口的事件生成一個測試用例打工需要20-30分鐘。因為需要花費時間，測試人員對于軟件界面只生成較少（100-300）的測試用例，因此每一個測試用例都是很珍貴的。
另外，大多數的GUI都是使用快速原型法設計的，這樣軟件可以在層疊式地進行更新和測試。GUI結構不斷的修改要求測試用例可以在不同版本的軟件上都是可用的。因為為不同版本的軟件生成新的測試用例是非常昂貴的。
盡管回歸測試對于傳統軟件而言是一項非常重要的軟件維護手段，占據了大約1/3的軟件開發成本，對于GUI的回歸測試仍然是一個巨大的有待開發的領域。對于GUI回歸測試的需求不同于傳統軟件對于回歸測試的需求�；貧w測試的研究過去都集中于發展回歸測試中的選擇技術，這項技術的作用就是從一系列測試用例中選擇一部分，這部分用例表明了正確的輸入并認為對于驗證修改后的軟件是必不可少的。那些不能夠在新的軟件上使用的測試用例將被忽略并丟棄。不可用用例問題對于GUI而言更為嚴重，因為GUI結構的改變將導致大量測試用例不可用，需要昂貴的更新成本。
當GUI發生變化時，一個測試集合中的測試用例就可被歸納為兩類：可用以及不可用。在可用的范疇中，這些測試用例還是可以在修改后的GUI上使用。而在不可用范疇內的測試用例是不能再重用的。例如，一個測試用例里可能包含點擊按鈕的操作，但這個按鈕很可能在新的結構中被刪除或是轉移到其他地方了。早期的[抓取/重放]工具是根據GUI窗口的對應像素來表示用戶事件的。然而，目前的[抓取/重放]工具不再只依賴于坐標，而且還包含了額外的信息如句柄、類型以及（可能的話）窗體的標簽，使得當控件被移走時[重放]工具仍然可以定位到正確的窗口。然而即便是用了這些現代的工具，由于GUI結構的修改，如添加一個新的菜單項，將激活一個對話框的動作從一個菜單換到另一個菜單，或是從一個窗口轉移到另一個窗口，因此仍然有大量的測試用例變為不可用。第6部分將說明超過74%測試用例將變為不可用。
本文提出一個嶄新的GUI回歸測試技術。我們的核心想法是不丟棄那些在修改后的GUI上不可用的測試用例。而是自動地將他們修復以便可以應用到修改后的GUI。我們將注意力集中到產生與原有測試用例有些類似的測試用例上，其原因稍后會加以解釋。通過使用這項新的技術，一名測試人員可以（1）重新在修改后的GUI上使用原有的仍然可用的測試用例。（2）修復并試用原先已經不可用的測試用例。（3）產生新的測試用例去測試新的功能。第6部分將說明我們的技術將使超過70%的測試技術被修復。
為了進一步說明GUI的回歸測試技術，我們在GUI測試框架中簡化了GUI的表示方法。同時我們定義了GUI結構事件的控制模型，使用模型來判斷GUI是否改變，判斷測試用例是否可用，若不可用是否可以被修復。當有很多種方法可以修復一個測試用例時，所有的方法都將被使用，這樣就會生成更多的測試用例。我們已經設計出了自動生成工具、表述工具以及重放已修復測試用例工具。
本文的貢獻包括：
1． 首次提出一項回歸測試技術，該技術可以從不可用測試用例中自動生成新的測試用例。
2． 測試機將決定測試用例在已修改后的GUI上是可用的還是不可用的，以及不可用的測試用例是否可以被修復。
3． 向修復機輸入可修復的測試用例，得到可以在已修改的GUI上使用的測試用例。
4． 實驗表明，在現實的應用中，本文提供的方法是有效實用的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
