摘要：
修復損壞的 Web 元素定位器是 Web 測試案例的主要維護成本。 為了檢測可能的維修，測試人員通常會通過 GUI 來檢查測試與被測應用程序的交互。 現有的自動測試修復技術專注於代碼，而忽略了應用程序的視覺方面。 在本演示文件中，我們對 VISTA 進行了概述，VISTA 是一種新穎的測試修復技術，它利用計算機視覺和本地爬取的方式自動給出修復損壞的 Web 測試的建議並將其應用。
1 簡介和動機
隨著被測 Web 應用程序的發展，使用諸如 Selenium 之類的工具創建的自動 Web 測試因其易碎性而聞名。 研究人員已經將 Web 元素定位器選為易碎的主要原因。 定位器是測試自動化工具用來識別網頁上元素的命令，這些元素掛在文檔對象模型（DOM）中的特定屬性上，例如元素的標識符、XPath 或文本。
測試破損問題。 不幸的是，DOM 往往是一個非常不穩定的結構，出於進化和修飾目的而進行了大量更新。 即使是簡單的修改（例如元素重定位）也可能會對定位器和 Web 元素之間的映射產生負面影響，從而使測試不適用。 在文獻中，這些問題的實例稱為測試破損。破損的測試與失敗的測試的不同之處在於自然的軟件演進是測試破損的原因，而非生產代碼中存在缺陷。因此，維修活動必須在測試代碼上觸發，而不是在應用程序上觸發。
測試人員如何維修。儘管修復定位器似乎是一項相當平凡的任務，但它卻考慮了許多不同的情況，這使其頗具挑戰性且耗時。當用於版本 V1 的測試 t 在後續版本 V2 上斷裂時，測試人員需要了解斷裂背後的根本原因以及可能的修復方法。該過程至少涉及四個步驟。 （1）測試人員檢查錯誤堆棧跟蹤或控制檯，其中可能包含有關損壞源的信息（例如，“發生 NoSuchElementException。無法找到名稱為密碼的元素”）。 （2）測試人員檢查 t，查找與錯誤消息有關的語句 st。 （3）測試人員瀏覽 V2 的 GUI，以嘗試識別與 st.s 相關的 GUI 部分。 （4）測試人員檢查 DOM 或 GUI，或者檢查 V2 的 DOM 和 GUI，以查找潛在的修復程序。這樣做時，測試人員可能需要手動執行相同的 t 破損情況（即 st 之前的語句中的所有操作），以便複製在 st 處發生的破損並收集有關可能維修的見解。
手動維修的挑戰。修復 Web 測試的第一個挑戰來自這樣一個事實，即測試人員經常需要檢查和鏈接測試代碼行為以及針對已開發應用程序的 GUI 和 DOM 進行的修改。換句話說，經常通過同時檢查 DOM 和 GUI 來找到候選解決方案來修復損壞。因此，與針對桌面應用程序的標準 JUnit 測試相比，修復 Selenium 測試無疑是更具挑戰性和更耗時的工作，因為錯誤信息通常更具參考性，並且 IDE 功能使調試活動更加容易。
第二個挑戰與糾正此類破損所需的時間有關，這可能很重要。主要原因之一是現有測試自動化框架對理解測試破損的根本原因以及它們與 Web 應用程序中所做更改的關係的工具性支持較差。
想法。我們的洞察力是使用 GUI 和可視化技術來支持破損的檢測，方法是檢查測試執行的 GUI 動作並在運行時對其進行驗證（與測試人員類似的方式），及時發現與正確行為的偏差。通過這種方式，我們可以預測破損的發生，並觸發修理程序，建議對測試人員進行可能的修理。當 Web 應用程序進行急劇的結構更改時，現有的定位器修復技術受到限制，因為它們僅將 DOM 視為尋找修復的來源。
工具。我們的工具 VISTA 使用測試執行過程中獲得的視覺信息，以及圖像處理和爬取技術，支持自動修復定位器損壞。
2 運行示例
我們考慮了真實的測試迴歸方案並解釋了 Water 的侷限性，Water 是現有的基於 DOM 的 Web 測試修復解決方案，這激發了對基於視覺的新穎方法的需求。
圖 1：AddressBook Web 應用程序的演變（6.2.12 版 →7.0.0 版），以及 Selenium WebDriver 測試用例。
圖 1 顯示了 AddressBook Web 應用程序的兩個版本，這是我們的經驗研究中使用的實驗主題之一。我們考慮將新條目添加到通訊簿的測試方案。在第一個版本 6.2.12（圖 1a）中，測試日誌登錄到應用程序（第 1 至 3 行），單擊“add new”鏈接（第 4 行），並在表單中填寫新的用戶信息（第 5-7 行）。
當發佈新版本的 AddressBook 時，測試人員可能希望運行此測試，以檢查在開發過程中是否已對應用程序進行迴歸。但是，在 7.0.0 版（圖 1b）上執行時，測試 a 將停止運行，因為存在多個損壞。
非選擇。首先，當嘗試找到“登錄”按鈕時，執行將在第 3 行停止，因為該屬性值已從 HTML 中刪除。但是，在對兩個 GUI 進行外觀檢查時，測試人員會期望測試能夠正常進行，因為在涉及 DOM 級別的更改時，她的看法並不重要。實際上，很明顯，目標元素（即“登錄”按鈕）在視覺上仍顯示在頁面上，並且其在 GUI 上的位置也沒有改變。
這是直接損壞的簡單實例，因為測試方案沒有改變，並且應用程序中（最終）沒有錯誤。但是，該測試不適用，因為與應用程序的同步丟失，並且需要找到修復程序。為此，測試人員可能希望使用 Water 自動修復第 3 行的損壞的語句。具體地說，需要生成另一個“ Login”（登錄）按鈕 3 的定位符，而不是依賴於“ broken”（損壞）屬性值。 Water 將通過分析早期版本 6.2.12 的 DOM 來嘗試收集有關損壞元素（例如 XPath 和各種屬性）的信息，並將此類信息與版本 7.0.0 的已演化 DOM 進行匹配。不幸的是，Water 的技術在這種情況下無效，因為（i）屬性值已從 DOM 中刪除，並且（ii）XPath 和目標元素的標記都已更改（從輸入到按鈕），這使得不可能供 Water 的啟發式方法在已發展的 DOM 上識別它並應用其自動修復。
工作流程中斷。第 5 行發生第二次重要中斷，當嘗試定位“名字”文本字段時，測試將引發 NoSuchElementException 類型的異常。實際上，已經添加了一個新的中間確認頁面（圖 1b），並且必須更正測試的導航工作流程以反映新修改的 Web 應用程序的工作流程。
從測試的角度來看，在執行第 4 行的語句之後，將不再在網頁（測試狀態）上找到“名字”文本字段。但是，從概念上講，需要觸發修復操作才能執行以下操作：糾正測試與第 5 行的定位器無關。實際上，僅考慮 JUnit 引發的異常，除非考慮到測試的直觀執行，否則測試人員很難檢測到此問題。甚至使用 Water 也不成功，因為該工具將嘗試在第 5 行修復損壞的語句（該技術僅處理表單中的語句添加，不適用於一般的損壞的工作流方案）。
錯誤選擇。最後，第 5-6 行的語句將正確執行，而第 7 行的語句將填充“暱稱”字段，而不是“公司”字段。在文獻中，這被稱為選錯問題。錯誤選擇網絡元素會導致無法預測的測試執行，這與測試的預期行為有所不同。根據執行的操作的類型，測試的執行可能會繼續進行，直到達到無法執行操作或找不到元素的位置，但是實際修復必須在先前的測試語句中觸發（傳播性損壞）。Water 不是為了檢測錯誤選擇而設計的；但是，對於測試人員而言，檢測這些場景非常具有挑戰性，因為只有通過手動目測檢查測試的執行情況，才能識別出這種破損模式。
修復測試。圖 1b 顯示了被 VISTA 修復的測試（突出顯示了修復），該測試在 AddressBook 版本 7.0.0 上可以正常工作。具體來說，（i）通過更新測試語句的定位器組件來糾正未選擇和錯誤選擇（第 3 行和第 5 行），並且（ii）通過添加新的測試語句以達到新的頁面來糾正損壞的工作流程（因此會創建丟失的過渡）。
在本文的以下部分，我們將說明我們的工具設計和實現。
3 VISTA 工具
VISTA 開發背後的直覺是，考慮到測試的視覺執行的算法可能能夠通過其外觀來驗證基於 DOM 的定位器的可行性，從而有可能預料到破損的發生。 此外，視覺定位器還可用於匹配新開發的 GUI 中的目標元素。這項工作的一個假設是，Web 應用程序的 GUI 在兩個連續的發行版之間不太容易被大幅度更改，而 DOM 的更新頻率更高。 但是，在兩個 GUI 之間匹配 Web 元素具有挑戰性，需要解決幾個問題。 在所有方法中（1）尋找一種可以處理多個視覺匹配（視覺誤報）的準確的視覺匹配技術，並且在找到良好視覺匹配的情況下，（2）檢索 DOM 中的相應元素。 （3）最後，在工作流中斷的情況下，最好自動執行對應用程序狀態空間的本地探索，以查看目標元素是否已重新定位到另一個測試狀態。
3.1 工具架構
圖 2：VISTA 的高級架構
圖 2 顯示了 VISTA 的高級體系結構，該體系結構在邏輯上由兩個主要模塊組成：視覺執行追蹤器和視覺增強的測試運行器。VISTA 是用 Java 編寫的，並在 Eclipse IDE 中執行 Selenium 測試用例，分析其可視化執行軌跡，以檢測定位器損壞的發生並在運行時查找潛在的修復程序，以報告給用戶進行檢查。
在下文中，我們將說明第 2 節中描述的運行示例中的兩個模塊
3.2 視覺執行追蹤器
在第一階段，我們的工具記錄了每個測試語句與正確版本的應用程序（Web App V1）的視覺交互。 保持語句、DOM 定位器及其外觀之間的關聯非常重要，因為它與測試人員通過眼球手動驗證測試執行時創建的思維模型很接近。
這樣的映射只能在測試執行時的運行時捕獲，因為渲染的元素的視覺外觀可能會在應用程序執行期間發生變化，並且某些元素只有在發生特定事件時才可能可見。 為此，視覺執行追蹤器集成了工具 PESTO ，該工具使用面向方面的編程來攔截 Selenium WebDriver 方法調用（例如 click()），並自動為組成測試用例的每個 Web 元素創建可視定位器。視覺定位器是呈現的網頁的一部分，可在屏幕上唯一標識該 Web 元素。
例如，對於圖 1a 中第 3 行的測試破壞，通過 XPath 定位器// input [@value =''Login'']來標識登錄提交按鈕（在 HTML 中）。工具（i）保存網頁的整個屏幕截圖，（ii）通過 WebDriver 檢索 Web 元素的座標和大小，最後（iii）裁剪以 Web 元素為中心的矩形圖像。請注意，視覺定位器並不總是精確地裁剪出網絡元素的邊界框。 PESTO 還可以管理一些案例，這些案例需要考慮到 Web 元素的可視上下文，以便將其與頁面上出現的其他視覺相似的 Web 元素（例如，表單中的多個文本字段）在視覺上區分開來。
當測試執行終止時，所有這些信息（測試語句、相應的屏幕截圖和可視定位器）將作為 json 文件持久保存，並由該工具的第二個主要組件使用。
3.3 視覺增強的測試運行器
在第二階段，VISTA 在新的應用程序版本（Web App V2）上運行測試。視覺增強測試運行器在受控循環環境中執行每個測試語句，在該環境中，該語句在 Web 應用程序上執行的操作結果通過一系列步驟進行驗證。
首先，該工具將應用程序的 DOM 與原始定位符// input [@ value ='Login'']合併，以觀察 WebDriver 是否返回了 WebElement 對象的實例。在未選擇的情況下（例如，新的 DOM 中沒有與該定位器關聯的 Web 元素），VISTA 會嘗試驗證該 Web 元素是否仍在視覺上顯示在網頁上（通過之前保存的可視定位器），以及因此，它會生成一個新的定位器（請參見第 3.4 節）。
相反，如果元素是由原始 DOM 定位器檢索的，則執行進一步的健全性檢查，仍然依賴於 Web 元素的可視搜索。 VISTA 檢查兩個定位器檢索到的兩個 WebElement 對象的等效性：如果它們確實針對相同的 Web 元素，則該方法已在視覺上驗證了執行的測試語句。然後，該方法繼續驗證下一條語句。
如果視覺定位器和 DOM 定位器之間存在分歧，則可能會發生選擇錯誤的情況，VISTA 將結果輸出到測試人員，測試人員需要通過選擇正確的定位器（如果有）來解決爭議。
當 DOM 和可視定位器都無法選擇當前 DOM（測試狀態）中的任何 Web 元素時，就會發生第三種破壞情況。 在圖 1a 的第 5 行中就是這種情況，其中目標 Web 元素已重新放置到新的 Web 頁面。 在這種情況下，VISTA 會觸發 Web 應用程序狀態空間的本地爬取，以查找與當前頁面相距一級的匹配項。 如果在任何網頁中找到匹配項，則通過向該頁面添加過渡以為匹配的元素生成新的語句（即定位符）來修復工作流程。
如果所有這些驗證檢查均未成功，則 VISTA 將認為該 Web 元素已從應用程序中刪除，並建議用戶刪除該語句。
3.4 VISTA 的關鍵組件
為了開發 VISTA 的視覺組件，我們將開源計算機視覺庫 OpenCV（版本 2.4.9）中可用的各種算法通過管道傳輸到了自定義檢測器中。檢測器旨在評估新 DOM 中視覺定位器的存在，如果是，則旨在在 GUI 及其對應的 DOM 元素中尋找最佳視覺匹配。在下面，我們簡要說明每個步驟。
3.4.1 圖像處理管道 。圖像檢測器結合了兩種特徵檢測算法：SIFT 和 FAST。檢測器使用 SIFT 描述符從模板圖像中提取關鍵點，然後採用距離閾值比為 γ= 0.8 的基於 Flann 的描述符匹配器。如果至少 70％的關鍵點匹配，則執行具有相似性閾值 δ= 0.99 的快速歸一化互相關模板匹配算法。如果存在多個或錯誤的視覺匹配，則我們的過程將通過非最大值抑制（NMS）操作丟棄那些不屬於找到關鍵點的區域的匹配。這樣，僅返回最接近的匹配項（請參見圖 2 中“登錄”按鈕上方的綠色粗矩形）。
3.4.2 從 GUI 到 DOM。一旦找到最佳視覺匹配，我們仍然需要檢索其邊界框中心具有座標（x，y）的對應 DOM 元素。可以以不同的方式完成此操作，例如將 DOM 解析為空間結構（例如 R-Tree），以便於查詢。由於解決方案願意提供運行時驗證技術，因此在我們的探索性實驗中未能提供可接受的性能結果，因為解析操作的成本很高，並且其複雜度會隨著 DOM 樹中元素的數量而增加。因此，VISTA 只是通過 JavaScript 命令 elementFromPoint（x，y）查詢瀏覽器，該命令返回其邊界框包含 x 和 y 的 DOM 元素。這些參數需要指定邊界框的中心，否則將錯誤地返回搜索到的 Web 元素的 DOM 祖先（作為表單或 div 容器）。
3.4.3 定位器生成器。檢索到的 Web 元素的 XPath 已被視為對定位器損壞的有效修復。但是，VISTA 可以根據元素本身的屬性（例如 id 或名稱）合成不同的 DOM 定位器，丟棄被認為易碎的屬性，並根據所謂的健壯性對最終列表進行優先級排序。
3.4.4 用於工作流修復的本地爬網。 對於本地爬網探索，VISTA 提供了 Crawljax 插件，該插件結合了圖像處理管道。 通過這種方式，爬蟲可以視覺上搜索所需的 Web 元素，從而在破損部位附近尋找修復方法。 對於 VISTA 修復不同破損類別的破損的經驗評估，我們請讀者閱讀全文[10]。 VISTA 能夠為 81％的破損提供正確的維修，而 Water 則增加了 41％。
4 結論與未來工作
在本文中，我們介紹了 VISTA，這是一種基於快速圖像處理管道的新穎的 Web 測試修復技術。 儘管 VISTA 已顯示出令人鼓舞的結果，但我們正在考慮一些改進。
在將來，我們計劃研究其他視覺技術，例如 OCR，並評估改變模板大小對工具準確性的影響。
也許更有趣的是雜交的潛力，即將 DOM 和視覺啟發式方法結合在一個解決方案中。 確實，可以通過引入其他信息來改善視覺搜索功能，這些信息可以幫助更智能地過濾多個視覺匹配。 例如，可以收集 DOM 信息和元素的方法調用堆棧，以驗證不同版本之間元素的語義等效性。
對於感興趣的讀者，可以在工具的存儲庫中找到源代碼和演示視頻：https://github.com/saltlab/VISTA
致謝
本文由南京大學軟件學院 2020 級碩士生惲葉霄翻譯轉述。
感謝國家重點研發計劃（2018YFB1003900）和國家自然科學基金（61832009，61932012）支持！
閱讀更多 慕測科技 的文章
