摘要

現(xiàn)有的 Web 測試生成器從 Web 應(yīng)用程序的導(dǎo)航模型中得出測試路徑，通過手動或隨機生成的輸入值來完成。但是，手動測試數(shù)據(jù)選擇的成本較高，而在不可行的輸入序列中往往會產(chǎn)生隨機生成的結(jié)果，但被測試中的應(yīng)用程序拒絕了。只有在嘗試執(zhí)行大量測試執(zhí)行后，隨機和基于搜索的生成才能達到所需的模型覆蓋級別，并且在執(zhí)行過程中，需要與瀏覽器進行交互才能降低所需的覆蓋率。在這項工作中，我們提出了一種新穎的 Web 測試生成算法，該算法根據(jù)之前的測試從多樣性中預(yù)先選擇了最有希望的候選測試案例。

1 簡介

當今可用的現(xiàn)代 Web 應(yīng)用程序提供了與本地桌面應(yīng)用程序相同的高級用戶交互功能，同時消除了站點部署，安裝和更新所需的實例。例如，單頁 Web 應(yīng)用程序（SPA）通過動態(tài)更新文檔對象模型（DOM）來實現(xiàn)動態(tài)響應(yīng)，并通過 JAVAScript 功能來實現(xiàn)用戶友好性。

為了測試這種復(fù)雜的軟件系統(tǒng)，工程師通常采用諸如 Selenium 之類的測試自動化框架。在這種情況下，測試人員使用測試腳本來驗證被測應(yīng)用程序（AUT）的正確功能，該腳本可自動執(zhí)行最終用戶將在 Web 應(yīng)用程序的圖形用戶界面（GUI）上執(zhí)行的手動操作的集合，例如，通過單擊來完成的交付活動。測試人員使用此類測試腳本以及必要的輸入數(shù)據(jù)實施針對業(yè)務(wù)的測試場景。因此，每個測試案例都應(yīng)沿著網(wǎng)絡(luò)應(yīng)用程序的導(dǎo)航圖執(zhí)行特定的測試路徑。

盡管在自動測試生成方面已有研究進展，但在網(wǎng)絡(luò)領(lǐng)域中僅提出了一些工具，遺憾的是，其仍然適用于當今可用的復(fù)雜系統(tǒng) 相當有限。 因此，迄今為止，諸如硒等系統(tǒng)級測試用例的開發(fā)仍大部分是手動執(zhí)行的。

由于事件和相關(guān)數(shù)據(jù)的特定順序，必須生成 Web 測試用例以確保啟動，因此自動生成 Web 測試用例四倍速度超長。存在動態(tài)網(wǎng)頁和事件基力的常用格式他們之間的皮疹。那么是 啊。測試路徑（也稱為抽象測試用例）是從模型中派生出來的，以確保能夠覆蓋航空圖形，例如，第一次訪問或語義交互事件。要生成可執(zhí)行測試，測試路徑需要指定適當?shù)妮斎霐?shù)據(jù)，這些數(shù)據(jù)可以手動或隨機生成。

但是，這些方法有一些缺點，限制了它們在實踐中的適用性。首先，隨機輸入生成使現(xiàn)有方法非常無效，因為它們可能（1）反復(fù)行使 AUT 的相同部分，而沒有探索可能暴露出先前未知故障的新行為，或者（2） 產(chǎn)生不可行的測試，這會違反約束和對 AUT 的先決條件。在充分發(fā)現(xiàn)導(dǎo)航圖之前，需要生成大量隨機測試用例的缺點，這是非常低效的。此外，由于與瀏覽器的交互作用，Web 測試的執(zhí)行時間很短，這在限制時序限制的情況下進一步支持了現(xiàn)有測試生成技術(shù)的適用性。 這樣，所提到的技術(shù)主要依靠手動輸入生成，這顯示了昂貴的成本，并且受限于測試人員可用的測試資源（例如時間）。

圖 1 PetClinic Web 應(yīng)用程序的簡化導(dǎo)航模型。 狀態(tài)之間的轉(zhuǎn)換用相應(yīng)的動作標記，可以對其進行參數(shù)化。 粗體顯示的路徑表示覆蓋率最大化的測試路徑的實例，該測試路徑是基于多樣性的技術(shù)生成的。

在本文中，我們提出了生成系統(tǒng)級 web 測試用例的新的解決方案。我們的方法的目標是生成一組測試用例，使航空圖的覆蓋范圍和輸入數(shù)據(jù)的使用多樣化，以應(yīng)對在實踐中不可執(zhí)行或不產(chǎn)生任何覆蓋改進的不可行情況。

評估新產(chǎn)生的測試案例的質(zhì)量時，評估新產(chǎn)生的測試案例的質(zhì)量時，關(guān)鍵的觀點是評估新產(chǎn)生的測試案例的質(zhì)量，只需評估其與先前執(zhí)行的候選人之間的差異。基于多樣性的測試生成降低了輸入空間的局部最優(yōu)區(qū)域的容量，其中相似的測試用例幾乎覆蓋了相同的環(huán)境和導(dǎo)航，并且在瀏覽器執(zhí)行中只選擇了其中的幾個不同的場景和日期。

我們實現(xiàn)了名為 DIG（基于多樣性的生成器）的工具，它會自動提取一個 Web 應(yīng)用程序的通用模型，按照頁面對象設(shè)計模式對每個網(wǎng)頁中可能執(zhí)行的操作進行基于代碼的抽象。然后，選擇測試用例（即。，可能） 的路徑和輸入）是基于神經(jīng)系統(tǒng)的多樣而產(chǎn)生的，完全有效地覆蓋了血液。

我們的工作做出了以下主要貢獻：

• 基于創(chuàng)新的 Web 應(yīng)用程序的系統(tǒng)級測試用例生成器。
• 用于識別覆蓋率和輸入最大化的候選測試用例的算法。測試用例之間的聽覺距離算法可以最大限度地減少瀏覽器執(zhí)行所需的聽覺距離。
• 我們的方法在稱為 DIG 的工具中的實現(xiàn)，該工具自動提取由頁面對象抽象組成的導(dǎo)航模型，并生成最大化導(dǎo)航序列和輸入數(shù)據(jù)多樣性的測試用例。
• 對六個開源 Web 應(yīng)用程序進行 DIG 測試的經(jīng)驗評估。DIG 生成的具有較高覆蓋率和故障檢測率的測試套件的速度明顯高于基于搜尋和基于搜索的測試生成器。

2 背景

我們提供了可以理解本文其余部分的網(wǎng)絡(luò)測試概念。我們提供了有關(guān) Web 應(yīng)用程序，其特性和屬性的通用模型的背景信息，并探討了如何使用該信息來實現(xiàn)自動測試用例的生成。

2.1 導(dǎo)航模型

Web 應(yīng)用程序的導(dǎo)航模型可以表示為狀態(tài)流圖（SFG），其中節(jié)點是網(wǎng)頁的動態(tài) DOM 狀態(tài)，并且邊緣之間是基于事件的轉(zhuǎn)換。

定義 1（狀態(tài)流圖）。 Web 應(yīng)用程序 W 的狀態(tài)流圖 SFG 是帶標簽的有向圖，用 4 元組表示，其中：

（1）r 是表示 W 已完全加載到瀏覽器中時初始 DOM 狀態(tài)的根節(jié)點（稱為索引）。

（2）V 是表示節(jié)點的一組頂點。每個 v∈V 代表 W 的抽象 DOM 狀態(tài)。

（3）E 是頂點之間的一組有向邊，我們稱其為動作。每個（v1，v2）|g|a∈E 表示當且僅當通過執(zhí)行節(jié)點 v1 中的動作 a 達到了節(jié)點 v2 并且滿足守護 g，才可能在兩個節(jié)點 v1，v2 之間進行轉(zhuǎn)換。

（4）在邊（v1，v2）|g|a∈E 上給出一組保護。

（5）SFG 可以具有多邊并且是循環(huán)的。

2.2 航空模型示例

圖 1 顯示了 PetClinic 的簡化導(dǎo)航模型，這是一個允許獸醫(yī)管理關(guān)于其客戶和 pet 中心的信息的 web 應(yīng)用程序，該應(yīng)用程序與實驗相同根據(jù)我們的評估。圖中顯示了八個表各州，每個州之間都有幾個可能發(fā)生的轉(zhuǎn)移。

其次，根據(jù)可行性的定義現(xiàn)象，分析了影響自動測試用例生成的新實例。

2.3 可行性

在給定的摘要 DOM 狀態(tài)下，可能采取的行動 E 可能受到一個或多個保安人員的限制（又稱前提條件）。

定義 2（守衛(wèi)）。 在特定應(yīng)用狀態(tài)下，guardд（s，a，i）是布爾值，作用于動作 a 的可能輸入值 i∈I。

為了使狀態(tài) n 和動作的目標狀態(tài)（通常是另一個狀態(tài) n'或 n 本身）之間的轉(zhuǎn)換，需要使防護人員滿意。 應(yīng)用程序狀態(tài) s 包括全局變量值，DOM 和跨用戶交互保持可用的任何持久性數(shù)據(jù)。

因此，防護依賴項的可滿足性是：（1）為給定操作 a，as 生成的輸入值 i∈（2）由先前用戶交互序列產(chǎn)生的應(yīng)用程序的內(nèi)部業(yè)務(wù)狀態(tài)。

例如，在圖 1 的所有者狀態(tài)中，操作顯示所有者允許向所有者信息狀態(tài)導(dǎo)航。作為對此措施的保護，建議在執(zhí)行操作之前，應(yīng)用程序中必須存在由輸入所有者名稱標識的所有者。 （出于可讀性考慮，在圖中省略了防護罩。）因此，防護罩不僅取決于分配給顯示所有者操作的輸入所有者名稱的特定值，而且還取決于應(yīng)用程序的內(nèi)部業(yè)務(wù)邏輯狀態(tài)。實際上，必須由先前執(zhí)行的操作（例如，由所有者執(zhí)行）將顯示的所有者事先插入到應(yīng)用程序中。

回顧一下，如果在給定的應(yīng)用程序狀態(tài)下警戒輸入值失真，那么我們認為這種過渡是可行的；否則是不可行的。

2.4 測試生成問題

給定 Web 應(yīng)用程序的導(dǎo)航模型，Web 測試生成器的目標是自動提取動作序列并生成適當?shù)妮斎耄匀嫘惺箲?yīng)用程序的行為，從而潛在地覆蓋導(dǎo)航模型中的所有轉(zhuǎn)換。

定義 3（測試路徑）。 測試路徑是一系列測試狀態(tài)，這些狀態(tài)與未指定輸入值的相應(yīng)動作序列配對。

然后，可以通過使用測試路徑實例化具體的輸入值來定義最新情況。

定義 4（測試用例）。 測試用例是特定測試路徑中相應(yīng)動作序列的具體值序列。

例如，在 PetClinic 中，作為一個簡單的測試路徑，該路徑可為 pet 添加新的訪問路徑，該路徑包括測試狀態(tài)序列⟨Index, Find, AddOwner, Owners, OwnerInfo, NewVisit⟩。相關(guān)的執(zhí)行順序是由⟨goToFind, addNewOwner, add, displayOwner, addNewVisit⟩提供的。

在此操作序列中，需要指定三個輸入值：（1）info，所有者的數(shù)據(jù)要插入，由狀態(tài) AddOwner 的操作添加，（2）ownerName，所有者的名稱，由狀態(tài)所有者的操作顯示所有者要求，以及（3）pet，要訪問的 Pet 的數(shù)據(jù)狀態(tài)，由操作 addNewVisist 要求。 動作 addNewVisit 有一個前提條件保護，該前提條件是由寵物標識的寵物必須在執(zhí)行該動作之前存在。由于考慮的紅色測試路徑否是在執(zhí)行 addNewVisit 之前通過任何動作添加的，因此對于輸入寵物的任何可能值，均不能采用選擇的測試路徑。 因此，我們說這樣的路徑是不可行的。

定義 5（測試路徑可行性）。 如果存在一個滿足所有與測試路徑中的動作有關(guān)的防護措施的輸入?yún)?shù)-值分配，則有一條測試路徑是可行的； 否則是不可行的。

2.5 現(xiàn)有的測試生成方法

將采用不同的策略來從導(dǎo)航模型中生成測試案例。在本節(jié)中，我們簡單討論了最顯著的現(xiàn)有解決方案以及其局限性，這些動機促使人們需要更高效的方法。在第 3 節(jié)中，我們將著眼于我們基于新穎性的測試。

2.5.1 圖訪問方法。 廣度優(yōu)先和深度優(yōu)先圖訪問算法已應(yīng)用于 Web 應(yīng)用程序的導(dǎo)航模型以得出測試路徑（也稱為抽象測試用例，即狀態(tài)序列和動作序列使具體的輸入數(shù)據(jù)無法執(zhí)行）。 在工具 ATUSA 中，建議隨機輸入數(shù)據(jù)生成以填補測試路徑和具體測試用例之間的差距。然而，隨機生成的輸入通常很少有機會生成可行的測試用例，因此，它們通常需要大量的輸入生成和相應(yīng)的測試執(zhí)行。此外，ATUSA 生成了 32 個測試集，因為即使是簡單的 5 抽象函數(shù)創(chuàng)建大量的測試狀態(tài)，并相應(yīng)地產(chǎn)生大量的測試路徑。

2.5.2 基于語義的方法。或者，測試路徑可以限制在那些進行語義相關(guān)的交互，即事件序列，其中事件的順序影響交互結(jié)束時達到的狀態(tài)。這種方法已經(jīng)成功地應(yīng)用于應(yīng)用程序，但它產(chǎn)生了一系列嚴格的測試用例（語義交互事件序列），這些測試用例需要對輸入數(shù)據(jù)進行大量的指定才能使其可執(zhí)行。

2.5.3 基于搜索的方法。基于搜索的技術(shù)對輸入空間進行迭代采樣，選擇最合適的候選測試用例，并選擇使用遺傳搜索運算符創(chuàng)建新測試用例。由于這些測試有效地引導(dǎo)生成更多的輸入空間的測試用例，因此它們適用于系統(tǒng)級測試，一個有效的配合功能可以根據(jù)活動模型中提供的近似信息來定義。研究人員已經(jīng)表明，這種方法可以引導(dǎo)搜索生成不受路徑不可行性問題影響的測試用例。然而，這種方法需要為每個操作手動指定所有保護，這項任務(wù)對于測試人員來說既耗時又費力。事實上，這些信息依賴于 Web 應(yīng)用程序的業(yè)務(wù)邏輯和有內(nèi)涵的行為，而且 USCA 無法生成完全自動。另外，對功能的評估通常是因為在重新進行相同的測試之前，需要在瀏覽器中生成和執(zhí)行大量候選測試。

2.5.4 摘要。雖然所有討論的方法都為所需的輸入值提供了漸近收斂的理論保證，但是當應(yīng)用于 Web 應(yīng)用程序時，它們的執(zhí)行時間性能較差，例如，標準 Java 桌面應(yīng)用程序。有一種說法是，為什么人們總是需要花費大量精力和精力來解決這個問題，這是因為在整個測試過程中，（2）都考慮到了局部因素的重要性。同樣不可行的），因此增加了測試代算法的運行時間，卻沒有完全覆蓋整個系統(tǒng)。本節(jié)中討論的局限性（測試者的規(guī)模，計算成本高，需要正式的護衛(wèi)規(guī)范）證明了對替代算法的研究是合理的，可能更合理，并且算法更自動化。

圖 2 系統(tǒng)級 Web 測試生成方法

3 基于多樣性的最佳生成方式

在概念上，我們通過適當?shù)臏y試模型推導(dǎo)了我們的方法的主要步驟。圖 2 描述了我們的方法的主要步驟。 面向?qū)ο蟮念悾鼈冊诰W(wǎng)頁上以可執(zhí)行的方式公開這些操作。 最后，我們的測試生成器使用測試動作與輸入數(shù)據(jù)之間的新度量距離來生成可以完全執(zhí)行應(yīng)用的測試。我們的方法不需要在安全的模型上指定防護軟性動作。

我們現(xiàn)在將詳細介紹方法的每一步，以及測試之間的距離的計算，這是在我們的運行示例中得到的例證。

3.1 測試模型提取

第一步，獲取 Web 應(yīng)用程序的導(dǎo)航模型。這可以通過手動探索 Web 應(yīng)用程序功能來手動執(zhí)行，或手動執(zhí)行。我們采用這種方法：我們使用 Web 爬蟲自動探索 Web 應(yīng)用程序的狀態(tài)空間（請參閱第 3.5 節(jié)，詳細說明此模型的狀態(tài)，然后在此狀態(tài)下研究此模型的詳細說明）。

然后爬蟲檢索到的一種通用模型可以生成一種基于中間代碼的抽象，該抽象可以方便地支持基于多樣性的自動測試用例的生成。我們使用頁面對象（以下稱為 POs）將其表示為 DOM，并按照其指示的方式將它們按照設(shè)計的方式按每種模型所指示的方式進行了模擬。 例如，在運行示例寵物診所時，AddOwner 狀態(tài)將由其自己的類表示，包含三個方法（add，goToIndex 和 goToFind）。

選擇狀態(tài)代表 PO 的動機是雙重的：（1）在 Web 測試自動化中使用眾所周知的頁面對象并利用其模式，以增強測試用例的開發(fā)和可維護性，以及（2）它們可以從具有良好準確性的導(dǎo)航模型自動創(chuàng)建。

3.2 基于多樣性的路徑和輸入生成

受到自適應(yīng)隨機測試的啟發(fā)，該假設(shè)使得可以假定連續(xù)的故障區(qū)域，網(wǎng)絡(luò)應(yīng)用程序也可能具有連續(xù)的不可行區(qū)域。 相應(yīng)地，在 Web 應(yīng)用程序的情況下，測試用例多樣性的主要優(yōu)勢是可以在整個范圍內(nèi)探索搜索空間，使導(dǎo)航序列采樣的區(qū)域多樣化。這預(yù)計將有助于逃脫本地解決方案，并避免產(chǎn)生可行的測試路徑，從而避免了對各種可能的研究（即，多樣的）的探索性的發(fā)現(xiàn)。 而來自連續(xù)區(qū)域的輸入可能會暴露相同的程序故障。

基于多樣性的測試案例生成的第二個優(yōu)勢是，相對于現(xiàn)有的隨機性和基于搜索的方法，其效率更高。實際上，通過評估在以前生成的測試案例中的多樣性并評估這種潛在的評估案例的質(zhì)量，并使用這種度量來評估其潛在的潛力，從而增加了對各種行為的探索。

有趣的是，如第 3.3 節(jié)所述，可以在沒有實際執(zhí)行候選測試用例的情況下進行這種評估。算法 1 描述了基于多樣性的路徑和輸入生成的整個過程。測試生成從一組無條件的測試開始，因此首先生成了隨機的測試。該算法生成一組候選測試用例 C，實例化候選測試路徑并帶有具體的輸入向量（第 8-10 行）。為了選擇最有前途的候選者，將計算每個候選測試用例與當前已執(zhí)行的測試用例集 Texec 之間的距離（第 11-15 行），并且僅執(zhí)行最遠的測試用例（第 16 行）。將測試用例限制為可行的前綴，以防其包括一個差異（第 17-18 行）。每當執(zhí)行該測試的路徑與實例之間的差異時，就會發(fā)生差異。測試用例僅添加到最終測試套件中，以增加導(dǎo)航模型 M 的覆蓋率（第 19-20 行）。

算法 2 顯示了如何創(chuàng)建候選測試路徑。 在我們的表示中，V 表示 AST 序列，表示以 X 為輸入向量序列的方法序列。 V，A 和 X 在主循環(huán)（第 5-11 行）中通過根據(jù)導(dǎo)航模型 M 在狀態(tài) v 可用的概率中隨機選擇具有統(tǒng)一概率的邊沿⟩v，v'⟩a 來增量創(chuàng)建。

這些選擇受到實際上必須從 v'保持目標方法的約束。最后，隨機選擇輸入值的向量作為參數(shù)（第 8 行）。

3.3 測試案例之間的距離

算法 1 需要一個距離度量來評估測試用例之間的差異。 與面向?qū)ο蟮幕驍?shù)字應(yīng)用程序測試不同，由于距離函數(shù) ρ 還必須考慮到構(gòu)成這種情況的作用序列，因此輸入設(shè)置不能僅取決于輸入值。因此，我們考慮到兩個情況之間的差異性，考慮到不同情況之間的差異，我們設(shè)計了兩個測試用例之間的旅行距離，并且， 通過使動作序列多樣化，以及與之相關(guān)的輸入值，我們推測我們可以逃離可行的測試路徑區(qū)域，并且可以使應(yīng)用行為多樣化。

3.3.1 距離公式。 直觀地講，我們的距離公式包含兩個術(shù)語，第一是測量要比較的兩個測試用例中動作序列之間的距離，第二是測量兩個序列中匹配動作所使用的輸入值之間的距離。要計算第一項，距離函數(shù) α 報告這兩個序列中不匹配動作的數(shù)量。 根據(jù)每個匹配的動作，我們計算其參數(shù)值之間的標準化距離 β。

給定兩個測試用例（ti，tj），其中 ti =⟨Vi，Ai，Xi⟩和 tj =⟨Vj，Aj，Xj⟩，距離 ρ（ti，tj）由公式（1），（2）給出：

在等式 1 中，符號 Vx :: Ay 表示這兩個動作序列都由其動作 Ai，Aj 和適用的狀態(tài) Vi，Vj 標識。 這有助于消除使用相同名稱表示不同動作的情況下的歧義。

函數(shù) α 表示序列編輯距離，它確定兩個序列中不匹配元素的數(shù)量（例如，當比較 a，b，b，c，to，e，b 時，4 = |⟨a，b⟩| + |⟨e，f⟩| ，c，f⟩）。 當比較⟨a，b，b，c⟩和⟨e，b 時，LCS 是最長公共子序列中的匹配索引的集合（例如，{（2,2），（4,3）} ，c，f⟩）。函數(shù) β 計算兩個匹配動作（分別在 Vi :: Ai 和 Vj :: Aj 中分別由 k1 和 k2 索引）的兩個參數(shù)值序列 Xi [k1]，Xj [k2]之間的距離。最后，函數(shù) δ 計算兩個基本輸入值軟件類型之間的標準化距離（請參見表 1 ）。

等式 1 的第二項與兩個序列中的動作 Ai [k1]，Aj [k2]相匹配。相應(yīng)地，兩個輸入向量 Xi [k1]和 Xj [k2]具有相同的基數(shù)。函數(shù) β 計算參數(shù)值 x 與兩個匹配動作 y 的平均距離。 函數(shù) δ 的運算根據(jù)操作中使用的參數(shù)類型而變化（請參見表 1）。輸入距離 δ 在 0 和 1 之間進行歸一化。對于字符串或數(shù)字類型，使用 Arcuri 等人提出的函數(shù) η（x）= x/(x + 1)進行歸一化。將值映射到范圍[0,1]。

公式 1 類似于分支覆蓋度的擬合函數(shù)的計算，通常在基于搜索的測試中采用。 在這種情況下，適應(yīng)度函數(shù)的兩個項分別是逼近水平和標準化分支距離。我們與該定義共享一個概念，即使第一項（動作序列距離）占主導(dǎo)地位，而僅在第一項不具有判別力的情況下重新排列為第二項（輸入值距離）。實際上，α 的范圍為 N，而 β 的范圍為零，而零的范圍為零 這樣，每個動作對的對 ρ 的貢獻就不會大于 1。直覺主義者認為，對動作的主要貢獻來自于動作序列的距離，而每個匹配對的輸入值距離則幾乎是最小的非零動作序列（即，1）的貢獻。

表 1 輸入距離計算

3.4 實現(xiàn)

我們實現(xiàn)了一種名為 DIG（基于多樣性的生成器）的 Java 工具，該工具公開可用。要檢索 PO 測試模型，DIG 依賴于 Apogen。最后，在基于 EvoSuite 的實例上實現(xiàn)基于多樣性的測試發(fā)生器，并在方法上進行了擴展，以評估 PO 模型。 最后，只有最多樣化的候選者才能通過 Selenium Web Driver 無頭執(zhí)行模式執(zhí)行。

4 經(jīng)驗驗證

4.1 研究問題

我們針對以下研究問題進行了解答：

RQ1（效果）：基于分集，搜索和爬網(wǎng)的隨機測試生成如何在狀態(tài)覆蓋率，代碼覆蓋率和故障檢測方面進行比較？

RQ2（效率）：基于多樣性和搜索的測試生成如何隨時間推移進行效率比較？

RQ3（Distance Computation）：基于多樣性的測試生成過程中的距離計算有什么意義？

RQ4（Manual POs）：在基于多樣性和基于搜索的測試生成方法中使用手動定義的 PO 有什么作用？

4.2 主題系統(tǒng)

表 2 總結(jié)了受試者的主要特征。

表 2 實驗主題

4.3 過程和計量

過程和計量數(shù)據(jù)如表 3 所示。

表 3 所有對象和方法的 RQ1，RQ2 和 RQ3 的有效性，效率和距離計算結(jié)果（自動 POs）。 粗體字的值表示 DIG 與 SubWeb 之間的統(tǒng)計上顯著差異。 星號表示 DIGS + 1 和 DIGS 之間的統(tǒng)計顯著性差異。 NC 表示不可比較的值，因為測試生成在給定的預(yù)算之前終止。

RQ1：基于分集和搜索的方法比基于爬行的隨機方法實現(xiàn)了更高的狀態(tài)覆蓋、代碼覆蓋和故障檢測。盡管效果相當好，但基于多樣性的應(yīng)用程序?qū)崿F(xiàn)了良好的效果，因為它是完全自動化的。

RQ2：基于分集的方法比基于搜索的方法實現(xiàn)更高的覆蓋率和故障檢測率。

RQ3：距離計算帶來的開銷被效率和自動化方面的好處所掩蓋。此外，所提出的距離度量的輸入分量可以被丟棄，而幾乎沒有相關(guān)的懲罰。

RQ4：通過使用手動定義的 POs，基于多樣性的方法在生成的測試套件所達到的結(jié)構(gòu)覆蓋方面優(yōu)于基于搜索的方法。

4.4 對有效性的威脅

在我們的評估中使用有限數(shù)量的主題系統(tǒng)，就結(jié)果的可概括性而言，構(gòu)成了外部有效性威脅。 我們試圖通過選擇六個使用現(xiàn)實世界的 JavaScript 框架開發(fā)的主題系統(tǒng)來緩解這種威脅，這些主題系統(tǒng)都包含不同的域，盡管為了更好地解決泛化威脅，我們還是選擇了其他主題系統(tǒng)。

內(nèi)部有效性的威脅可能來自實驗的混雜因素。我們在現(xiàn)實世界的 Web 應(yīng)用程序上，以相同的參數(shù)設(shè)置（例如，時間預(yù)算間隔）比較了所有競爭算法。手動的 PO 開發(fā)任務(wù)面臨對有效性的威脅，因此必須遵循嚴格的系統(tǒng)性過程來阻止這種有效性。

結(jié)論有效性與否定性和統(tǒng)計測試的正確使用有關(guān)。為了減輕設(shè)定值的耗損，每次實驗都要進行 15 次并使用非參數(shù)的 Mann-Whitney Utest 進行統(tǒng)計測試。

考慮到結(jié)果的可重復(fù)性，可以在線獲取 DIG 和所有主題系統(tǒng)的源代碼，從而使評估可重復(fù)且結(jié)果可重復(fù)。

5 討論

5.1 有效性和自動化

通過將 PO 與測試生成相結(jié)合，基于多樣性和搜索的方法比基于最新的基于爬網(wǎng)的 PO 不可知方法具有更高的狀態(tài)覆蓋率，代碼覆蓋率和故障檢測。

由于需要指定手動前提條件，因此將 DIWebisally 自動化，而 SubWebisonly 則半自動化。 我們的結(jié)果表明，DIG 可以通過自動生成 PO 和測試用例，從而為測試人員節(jié)省大量時間。必要時，測試人員可以細化生成的 PO，使其沒有動作或過渡，并重復(fù)測試的生成。

此外，由我們的方法生成的測試服務(wù)是基于頁面對象設(shè)計模式的，這在可維護性方面具有已知優(yōu)勢。

5.2 效率

我們的效率證明我們的方法是可取的，特別是在嚴格的測試時間或在開發(fā)過程中經(jīng)常執(zhí)行測試用例的情況下。實際上，基于多樣性的方法要比基于軟件的開發(fā)方法和軟件對 XP 的信任程度要高得多，這要比基于軟件的方法和方法對這種方法的信心大得多。

5.3 效益可行性

在連續(xù)可行區(qū)域的猜想下，促進多樣性不僅有利于徹底探索應(yīng)用程序的行為，而且有利于自動生成測試用例的可行性。相反，基于搜索的方法使用保護性模型作為通用模型，可以指導(dǎo)用戶進行搜索以找到滿意的輸入。

5.4 與手動 PO 的比較

Apogen 自動生成的 PO 通常要比手動開發(fā)的 PO 簡單，因為要進行測試的操作的數(shù)量和復(fù)雜性。Apogen 根據(jù)從每個測試狀態(tài)靜態(tài)提取的操作創(chuàng)建方法。因此，在大多數(shù)情況下，這些方法可能會遺漏在 Web GUI 上可能會產(chǎn)生的復(fù)雜交互（對于策略 GUI 而言是不可能的）。 ，DIG 可以生成的可能的測試路徑/案例的數(shù)量會降低。

盡管存在這些局限性，自動化 POs 在考慮的應(yīng)用程序子集下仍可與手動 POs 競爭。測試人員可以采用一種有趣的選擇，對自動生成的 PO 進行細化，從而以較低的開發(fā)成本實現(xiàn)與手動 PO 相同的性能。 總體而言，我們的經(jīng)驗結(jié)果表明，當可以使用高質(zhì)量的 PO 時，基于多樣性的方法要比其他所有方法都更有效（狀態(tài)和分支覆蓋率）和效率（達到覆蓋率）。

致謝

本文由南京大學(xué)軟件學(xué)院 iSE 實驗室 2020 級碩士生王旭翻譯轉(zhuǎn)述