很明顯，Selenium是使UI測試自動化的組織的最受歡迎的選擇，但是團隊仍然面臨著挑戰。了解如何解決這些挑戰而不完全放棄該框架。

當我們對UI測試工具進行調查時，很明顯Selenium已成為事實上的標準。但是奇怪的是，無論我們問誰，我們總是有同樣的警告：“我們愛Selenium，但也有挑戰。”

因此，我們回到了社區，問：“您在UI測試方面面臨的主要挑戰是什么？”

結果很明顯：首要挑戰是建立可隨時間推移保持的測試。通過進一步的客戶采訪，我們將主要的Selenium問題歸結為以下五個挑戰：

1. 創建可靠的定位器和等待條件
2. UI更改時維護測試
3. 調試和診斷自動化故障
4. 執行整個套件所需的時間
5. 創建腳本的知識/技能

然后，我們開始研究如何能夠在不擺脫Selenium的情況下幫助解決這些問題。事實證明，您可以通過將添加到組合中來解決所有這些挑戰，但是有很多相對簡單的方法可以解決Selenium的所有挑戰，而無需放棄每個人都明確喜歡的平臺。

如何用Selenium解決前5大挑戰

因此，讓我們更深入地研究這些挑戰以及如何解決它們。

挑戰1：創建可靠的定位器和等待條件

創建可靠的定位器涉及了解如何構建每次都與正確元素交互并且在不同執行之間穩定的標識符。用戶發現自己正在瀏覽Chrome開發人員工具，以找到合適的HTML塊，弄清楚它在做什么，然后花時間來構建最智能的定位器。通常最終會發生的情況是，當元素定位器處于當前狀態時，會在應用程序中選擇它，并且在播放時，東西會有所不同。這真的很令人沮喪。

等待條件在這里也起著巨大的作用。對于現代Web應用程序，在單個頁面中動態加載內容意味著即使找到正確的定位器，也必須聰明地建立正確的等待條件以確保元素準備好與之交互。這可能是一個巨大的痛苦。

解決方案：智能定位器

有很多UI測試解決方案都專注于使用術語“智能定位器”解決這一確切的挑戰。 最初創建測試腳本時，智能定位器會捕獲最智能的定位器，以使其更易于更改。 我最近的帖子指出了用于UI測試的10種出色的新工具，其中包括一些具有記錄和回放功能的工具。

此外，還有適用于Chrome的插件，可在腳本創建過程中提供幫助，以從頁面外提取最佳元素定位符。我一直在研究其中的幾個插件，到目前為止，我見過的最好的插件是TruePath。

挑戰2：當UI更改時維護測試。

對于正在進行的敏捷測試活動，這是組織面臨的一項艱巨挑戰。我們一次又一次地聽到這個故事——測試人員花費大量時間來構建他們的Selenium測試（具有良好的定位條件和等待條件），然后應用程序UI更改并且測試中斷，通常使夜間構建失敗。然后，測試人員必須返回并找出應用程序中發生了什么變化，確定這是真正的缺陷/回歸還是測試腳本有問題。然后通過識別和創建新的定位器/等待條件來完成修復或更新測試的過程。這是一個惡性循環。

解決方案：人工智能

人工智能確實可以在這方面為您提供幫助。是的，我知道，這些天AI真是個時髦的詞。但是有非常實際的用法。特別是，在Selenium測試執行過程中使用機器學習來解決這一確切的挑戰。每次測試運行都會在其歷史記錄中產生一個唯一的條目，顯示DOM的當前狀態并指示測試是否成功。

如果測試由于應用程序UI更改而失敗，那么會時光倒流，并告訴您如何構建與新版本的應用程序一起使用的新定位器。這真的很強大，因為它意味著您不必離開Selenium即可解決因更改UI帶來的維護挑戰（該技術的另一個好處是它具有自我修復CI/CD管道的能力，可以在運行時自動將定位器更新為停止不必要的構建）。

挑戰3：調試和診斷自動化故障

調試和診斷Selenium測試非常困難，并且可能會浪費大量的時間（尤其是在與不斷變化的UI結合使用時）。我們發現，各種解決方案都試圖通過為自己的框架提供高級報告功能來解決這一難題，但是隨后，測試人員最終被鎖定在專有平臺或IDE中。如果您打算在整個余生中繼續使用該供應商或工具，那么這是“好的”，但是想要保留開源所提供的原始自由的Selenium用戶又如何呢？

解決方案：智能自動化和報告

為了解決這一挑戰，您可以結合使用報告和測試執行分析，以及IDE工具。

通過將報告工具（如）插入現有的CI / CD管道中，您可以更輕松地了解哪些測試失敗以及原因。通過運行時自我修復，Parasoft Selenic可以防止由于不穩定的測試而導致構建不必要地失敗。測試完成后，將提供修復那些損壞的測試的建議，這些建議可以直接導入IDE以進行自動修復。

IDE本身（例如Eclipse和IntelliJ）具有調試功能，可讓您在Selenium測試中設置斷點并在特定點暫停應用程序，因此您可以提取有關UI狀態以及可能發生的情況的信息，因為應用程序失敗。

挑戰4：執行整個腳本所花費的時間

與在應用程序的API/服務層上運行的測試相比，自動UI測試的運行時間更長（并且比隔離的單元測試要更長），并且創建的UI測試越多，執行這些測試所花費的時間就越多，并且您需要等待CI/CD管道反饋的時間更長。問題在于，由于頻繁的代碼更改，管道每天要觸發多次，因此您不能等到第二天（有時是在周末）才能獲得有用的反饋。需要一種優化測試套件執行的方法，以在快速反饋與全面覆蓋之間取得平衡。

解決方案：測試影響分析

您可以在這里利用諸如的測試影響分析之類的技術。通過跟蹤每個Selenium測試涵蓋的代碼，并將其與代碼庫中的更改相關聯，您可以確定需要執行以驗證代碼更改的測試子集的優先級。使用，您無需訪問基礎代碼，因為它只需掃描二進制文件（例如.war或文件），識別在構建之間已更改了哪些類，然后將其映射到受影響的測試用例即可啟用。您可以將一部分Selenium測試作為CI/CD管道的一部分運行。（查看Parasoft Selenic：如何在CI/CD管道中修復Selenium）

挑戰5：創建腳本所需的知識和技能

最后，首先創建Selenium測試所需的知識和技能會使Selenium的使用令人望而卻步。根據我們與誰交談，這是人們所面臨挑戰中的第一個或最后一個。我們通常會看到，當用戶剛開始使用Selenium時，他們面臨的第一大挑戰是測試創建-但是一旦他們開始并建立成熟的測試實踐，它就不再是第一挑戰，而實際上是另一個挑戰問題變得更加重要。因此，從我的角度來看，克服最初的障礙是真正的挑戰。

解決方案：代碼助手

諸如無代碼的Selenium和NLP驅動的Selenium創建之類的事情，但是我還沒有特別看到一種能像我們所有人希望的那樣運作的東西。Selenium的主要現實之一是它的代碼。這是好是壞？很好，因為如果您需要做的事情超出了“常規做法”范圍，可以通過快速Google搜索找到一些好的代碼示例。這很糟糕，因為它是代碼，這對某些測試人員來說是一個障礙。

因此，您需要成為一名開發人員來構建Selenium腳本嗎？答案是否定的，但是某些開發技能確實可以提供幫助。正如我之前提到的，許多出色的新UI測試工具都具有可以構建Selenium腳本的記錄器，例如，SeleniumIDE和Katalon。這些幫助器工具將為剛接觸Selenium的用戶提供快速入門，并在無代碼和已編碼之間提供中間立場。當然，您必須意識到沒有一個UI記錄和回放工具是完美的（當然，也有解決這些挑戰的方法）。

結論

Selenium是UI自動化的第一選擇，技術每天都在進步，圍繞支持Selenium并幫助解決其一些基本挑戰的技術很多。UI測試對于驗證客戶體驗至關重要，并且能夠構建可長期維護的豐富且有意義的Selenium測試，將有助于增加我們行業的整體測試覆蓋率，從而在將來構建更好、更有意義的體驗。