連續運行自動化測試似乎很容易。CI系統是關鍵，可為敏捷開發團隊提供對其應用程序運行狀況的及時可見性。如果自動測試通過，則該應用程序運行狀況良好。如果測試失敗，則應用程序會以某種方式損壞。還是？不幸的現實是，自動化測試并不總是給我們這樣的信心，特別是在運行Selenium測試時。Selenium測試可能由于多種原因而失敗，無論應用程序是否以任何方式損壞或更改。這些問題在上一篇博客文章（UI測試自動化：輕松擺脫Selenium問題）中進行了詳細介紹。在這里，我將說明如何修改CI/CD管道以自動解決這些問題，從而提高對CI系統測試結果的信心。

Selenium CI的悲哀

CI/CD放大了Selenium測試問題。讓我們看看這是怎么發生的。首先，開發會進行一些代碼更改。CI系統檢測到更改并觸發構建管道。編譯模塊，運行并通過單元測試（是！），然后打包應用程序以進行部署。接下來，部署管道將觸發下一步，搭建測試環境，部署被測應用程序，然后啟動集成測試，其中許多測試是使用Selenium編寫的。并非所有Selenium測試都通過了這一點，CI系統會通過電子郵件將測試失敗通知各個人。這些人會做出反應，有時會花費大量時間進行調查和故障排除。產品所有者、經理和其他相關方也可以在儀表板上看到故障，從而將注意力從其他方面轉移到其他方面。知道Selenium測試本身是不穩定的，那么誰能相信CI/CD報告了真正的回歸或缺陷？排查誤報浪費了多少時間？

簡單地改進Selenium測試可能并非易事，有時涉及反復試驗，尤其是在問題斷斷續續或難以重現時。從一個構建到另一個構建，可能會四處走動的故障，沒有任何可歸咎的測試。它們可能是系統問題，也可能是環境問題。CI系統可以使用性能特性不一致的VM或基于云的執行程序。測試在開發人員工作站上運行并通過，但CI自動化失敗。聽起來有點耳熟？

Selenium CI如何解決

開發是為了幫助應對此類挑戰。Selenic可以自動分析和糾正Selenium測試問題，提供對這些問題的修復或洞察力，并在CI系統通知人類時使這些發現可用。負擔轉移到CI系統，而不是對來自CI系統通知的人員做出反應。僅需兩個簡單的步驟，即可使用自動完成將Selenium測試作為CI/CD管道的一部分進行修復的過程。

注入Selenium代理

要集成，您可以對現有的測試執行腳本進行單行更改。假設我在管道中有一個Maven執行步驟正在驅動基于Java的Selenium測試。通常，我指定兩個Maven目標：“清除”和“測試”，這兩個目標作為命令行參數傳遞給Maven。在這里，您只是添加了一個額外的Maven命令行參數：

-DargLine=-javaagent:${SELENIC_HOME}/selenic_agent.jar=selfHealing=true,sessionId=${BUILD_TAG}

在Jenkins CI中，這可能看起來像這樣：

現在，只要在“SELENIC_HOME”變量所引用的位置安裝并許可了Selenic，就可以將Selenic代理注入到測試執行過程中。Selenic代理可以做各種事情，但是出于穩定測試的目的，我僅啟用“自我修復”功能，該功能試圖實時識別和修復Selenium測試問題。

要仔細考慮的一件事是您的Selenium測試是否全部存在于一個模塊中，或者是否存在多個模塊中的測試。通常出于組織目的將測試分為多個模塊。為了讓Selenic聚合來自多個測試模塊的信息，必須配置“sessionId”參數。在上面的示例中，我使用的是“BUILD_TAG”，它是Jenkins CI系統中的一個預定義變量，可以很好地實現此目的。無論使用哪種CI系統，我的建議都是使用CI系統提供的變量來構造唯一的會話標識符。

進行了單行更改后，Selenic會自動識別并糾正測試穩定性問題，使每個人對CI系統發布的測試結果更有信心。但是，我建議再集成一個Selenic組件。

運行Selenic Analyzer

我們如何知道Selenic發現了什么問題或糾正了什么問題？我應該對Selenium測試進行一些更改，以避免Selenic發現的問題嗎？要獲取此信息，您可以將Selenic Analyzer運行為管道中的另一個執行步驟。這是第二個單行更改，但仍然微不足道：

java -jar $SELENIC_HOME/selenic_analyzer.jar -report target/selenic-reports -sessionId ${BUILD_TAG}

在Jenkins CI中，這可能看起來像這樣：

Selenic Analyzer收集早期由Selenic Agent記錄的信息，對數據執行一些附加分析，然后構建一些報告，然后由CI系統將其存檔。默認情況下，分析器處理來自最新會話的信息，但出于魯棒性的考慮，我建議使用配置Selenic Agent時使用的相同值顯式配置“-sessionId”參數。

Selenic Analyzer默認情況下將報告寫入當前工作目錄中。但是，為了使報告的歸檔更加容易，您應該添加“-report”參數來指示Selenic將報告寫入項目的構建輸出目錄中的“selenic-reports”文件夾中。完成此操作后，您將在管道中再添加一個步驟來存檔“target/selenic-reports/**”：

現在，通過CI系統，每個人都可以使用該報告文件。對于Jenkins CI，可以通過穩定的URL方便地訪問報告：

//{ci_server}/job/{test_job}/lastSuccessfulBuild/artifact/target/selenic-reports/report.html

//{ci_server}/job/{test_job}/lastSuccessfulBuild/artifact/target/selenic-reports/report.json

第一個URL指向可以在Web瀏覽器中直接查看的Selenic HTML報告。第二個URL指向JSON報告，開發人員可以將其提供給Selenic IDE插件，以從上一次自動測試運行中導入建議。

其他注意事項

Selenic還有許多其他選項，您可以考慮根據測試環境和其他特定需求啟用它們。

Selenic記錄每個測試會話的數據。記錄的數據可作為知識庫，使Selenic能夠隨著時間的推移學習并做出更好的自我修復決策和建議。默認情況下，此數據存儲在執行測試的計算機上。因此，如果您有一個執行程序池，那么您希望此數據位于所有執行程序都可以訪問的共享文件夾中。可以通過將“data={path}”參數傳遞給Selenic Agent和將“-data {path}”參數傳遞給Selenic Analyzer來顯式配置數據位置，其中“{path}”將是共享文件夾的文件系統路徑。在Windows上，這可能是UNC路徑，例如\\HostName\SharedFolder。除非受到約束，否則記錄的數據還將無限期累積。最終可能導致高磁盤使用率。可以通過將“maxSessionDaysToKeep={num_days}”參數傳遞給Selenic代理來配置記錄的測試會話數限制。“{num_days}”是記錄數據的天數，而不是日歷天。換句話說，Selenic不會計算沒有記錄測試會話數據的任何日子。如果不經常地、以不固定的間隔運行測試，或者由于服務器停機而導致您錯過了幾天的運行測試，這將很有幫助。

Selenic還可以配置為以各種粒度級別捕獲其他診斷信息。例如，可以將Selenic配置為捕獲每個Selenium操作或僅針對失敗操作的屏幕截圖。要啟用有關測試失敗的屏幕截圖，您可以將“screenshot= failures”參數傳遞給Selenic Agent。 Selenic Analyzer生成的HTML報告中提供了失敗的屏幕截圖。

CI/CD + Selenic = ?

的構建旨在使用Selenium作為CI/CD的一部分來加速敏捷開發。開發人員和測試人員可以提高生產效率，減少追尋Selenium“幽靈”的時間，而將更多的時間用于處理真實事物。使用Selenic增強對Selenium測試結果的信心。。