🥇實施、規模：在 VTB 使用自動測試的經驗

我們的部門創建全自動管道，用於將新版本的應用程序啟動到生產環境中。當然，這需要自動化的功能測試。下面是一個故事，講述我們如何從本地機器上的單線程測試開始，通過GitLab 頁面上的Allure 報告，達到在構建管道中的Selenoid 上運行多線程自動測試的階段，並最終獲得一個很酷的自動化工具未來的人們可以使用團隊。

我們從哪裡開始？

為了實現自動測試並將其集成到管道中，我們需要一個可以靈活更改以滿足我們的需求的自動化框架。理想情況下，我希望為自動測試引擎制定一個單一標準，適合將自動測試嵌入到管道中。為了實現，我們選擇了以下技術：

Java
馬文，
硒，
黃瓜+JUNIT 4，
引誘，
亞搏體育app

為什麼是這個特定的集合？ Java 是自動化測試最流行的語言之一，所有團隊成員都會使用它。硒是顯而易見的解決方案。除其他外，Cucumber 應該可以提高參與手動測試的部門對自動化測試結果的信心。

單線程測試

為了不重新發明輪子，我們將 GitHub 上各個存儲庫的開發成果作為框架的基礎，並進行了適合我們自己的修改。我們為主庫創建了一個存儲庫，其中包含自動測試框架的核心，以及一個存儲庫，其中包含在我們的核心上實現自動測試的黃金示例。每個團隊都必須獲取黃金鏡像並在其中開發測試，使其適應他們的項目。我們將其部署到 GitLab-CI 銀行，並在其上配置：

每天啟動每個項目的所有書面自動測試；
在構建管道中運行。

一開始測試很少，都是一股腦兒去的。 GitLab Windows 運行器上的單線程啟動對我們來說很好：測試加載的測試平台非常少，幾乎沒有利用資源。

隨著時間的推移，自動測試越來越多，當完整運行開始需要大約三個小時時，我們考慮並行運行它們。還出現了其他問題：

我們無法驗證測試是否穩定；
在本地計算機上連續運行多次的測試有時會在 CI 中崩潰。

設置自動測試的示例：

<plugins>
	
<plugin>
    	
<groupId>org.apache.maven.plugins</groupId>
    	
<artifactId>maven-surefire-plugin</artifactId>
    	
<version>2.20</version>
    	
<configuration>
        	
<skipTests>${skipTests}</skipTests>
        	
<testFailureIgnore>false</testFailureIgnore>
        	
<argLine>
            	
-javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
            	
-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"
        	
</argLine>
    	
</configuration>
	
    <dependencies>
        	
<dependency>
            	
<groupId>org.aspectj</groupId>
            	
<artifactId>aspectjweaver</artifactId>
            	
<version>${aspectj.version}</version>
        	
</dependency>
    	
</dependencies>
	
</plugin>
	
<plugin>
    	
<groupId>io.qameta.allure</groupId>
    	
<artifactId>allure-maven</artifactId>
    	
<version>2.9</version>
	
</plugin>
</plugins>

傾城報告示例

測試期間的運行器負載（8 核、8 GB RAM、1 線程）

單線程測試的優點：

易於設置和運行；
CI 中的發布實際上與本地發布沒有什麼不同；
測試互不影響；
跑步者的最低資源要求。

單線程測試的缺點：

需要很長時間才能完成；
測試長期穩定；
流道資源利用效率低，利用率極低。

JVM 分叉測試

由於我們在實現基本框架時沒有考慮線程安全代碼，因此並行運行的最明顯的方法是黃瓜 jvm 並行插件對於行家來說。該插件很容易設置，但為了正確的並行操作，自動測試需要在單獨的瀏覽器中運行。沒辦法，我只好使用Selenoid。

Selenoid 服務器在具有 32 個內核和 24 GB RAM 的機器上啟動。限制設置為 48 個瀏覽器 - 每個核心 1,5 個線程和大約 400 MB 的 RAM。結果，測試時間從 40 小時減少到 20 分鐘。加快運行速度有助於解決穩定性問題：現在我們可以快速運行新的自動測試 30-XNUMX 次，直到我們確定它們運行可靠。
該解決方案的第一個缺點是並行線程數量較少，運行程序資源利用率較高：在 4 核和 8 GB RAM 上，測試在不超過 6 個線程中穩定運行。第二個缺點：插件會為每個場景生成運行器類，無論啟動了多少個。

重要的信息! 不要將帶有標籤的變量傳遞給 精氨酸線，例如，像這樣：

<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"

如果以這種方式傳遞標籤，插件將為所有測試生成運行程序，也就是說，它將嘗試運行所有測試，在啟動後立即跳過它們，並在此過程中創建許多 JVM 分支。

正確地將帶有標籤的變量放入標籤在插件設置中，請參閱下面的示例。在我們測試過的其他方法中，連接Allure插件都存在問題。

設置不正確的 6 個簡短測試的運行時間示例：

[INFO] Total time: 03:17 min

如果直接將標籤傳輸到，測試運行時間示例 mvn... –Dcucumber.options:

[INFO] Total time: 44.467 s

設置自動測試的示例：

<profiles>
	
<profile>
    	
<id>parallel</id>
    	
<build>
        	
<plugins>
            	
<plugin>
                	
<groupId>com.github.temyers</groupId>
                	
<artifactId>cucumber-jvm-parallel-plugin</artifactId>
                	
<version>5.0.0</version>
                	
<executions>
                    	
<execution>
                        	
<id>generateRunners</id>
                        	
<phase>generate-test-sources</phase>
                        	
<goals>
                            	
<goal>generateRunners</goal>
                        	
</goals>
                        	
<configuration>
                	
            <tags>
                            	
<tag>${TAGS}</tag>
                            	
</tags>
                            	
<glue>
                                	
<package>stepdefs</package>
                            	
</glue>
                        	
</configuration>
     	
               </execution>
                	
</executions>
    	
        </plugin>
            	
<plugin>
                	
<groupId>org.apache.maven.plugins</groupId>
                	
<artifactId>maven-surefire-plugin</artifactId>
        	
        <version>2.21.0</version>
                	
<configuration>
                    	
<forkCount>12</forkCount>
                    	
<reuseForks>false</reuseForks>
                    	
<includes>**/*IT.class</includes>
                   	
 <testFailureIgnore>false</testFailureIgnore>
                    	
<!--suppress UnresolvedMavenProperty -->
                    	
<argLine>
  	
 -javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar" -Dcucumber.options="--plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm TagPFAllureReporter --plugin pretty"
                    	
</argLine>
                	
</configuration>
                	
<dependencies>
                    	
<dependency>
                        	
<groupId>org.aspectj</groupId>
                        	
<artifactId>aspectjweaver</artifactId>
                        	
<version>${aspectj.version}</version>
                 	
   </dependency>
                	
</dependencies>
         	
   </plugin>
        	
</plugins>
    	
</build>
	
</profile>

Allure 報告示例（最不穩定的測試，重新運行 4 次）

測試期間的運行器負載（8 核、8 GB RAM、12 線程）

優點：

簡單設置 - 您只需要添加一個插件；
同時運行大量測試的能力；
由於步驟 1，加速了測試穩定性。

缺點：

需要多個操作系統/容器；
每個分叉資源消耗高；
該插件已過時，不再受支持。

如何克服不穩定因素

測試台並不理想，就像自動測試本身一樣。我們有許多不穩定的測試並不奇怪。前來救援 Maven Surefire 插件，它開箱即用地支持重新啟動失敗的測試。您需要將插件版本更新到至少 2.21，並在 pom 文件中寫入一行重啟次數或將其作為參數傳遞給 Maven。

設置自動測試的示例：

   	
<plugin>
        	
<groupId>org.apache.maven.plugins</groupId>
  	
      <artifactId>maven-surefire-plugin</artifactId>
        	
<version>2.21.0</version>
        	
<configuration>
           	
….
            	
<rerunFailingTestsCount>2</rerunFailingTestsCount>
            	
….
            	
</configuration>
</plugin>

或者在啟動時： mvn … -Dsurefire.rerunFailingTestsCount=2 …
作為一個選項，為 PowerShell 腳本 (PS1) 設置 Maven 選項：

  
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"

優點：

當測試崩潰時，無需浪費時間分析不穩定的測試；
測試台的穩定性問題可以得到解決。

缺點：

浮動缺陷可能會被遺漏；
運行時間增加。

使用 Cucumber 4 庫進行並行測試

測試數量每天都在增加。我們再次考慮加快運行速度。此外，我想將盡可能多的測試集成到應用程序組裝管道中。關鍵因素是使用 Maven 插件並行運行時，生成運行程序花費的時間太長。

當時Cucumber 4已經發布，因此我們決定重寫該版本的內核。在發行說明中，我們承諾在線程級別並行啟動。理論上應該有：

通過增加線程數量顯著加快自動測試的運行速度；
消除為每次自動測試生成運行程序的時間損失。

事實證明，優化多線程自動測試框架並不是那麼困難。 Cucumber 4 從頭到尾在專用線程中運行每個單獨的測試，因此一些常見的靜態內容被簡單地轉換為 ThreadLocal 變量。
使用 Idea 重構工具進行轉換時最主要的事情是檢查變量進行比較的位置（例如，檢查 null）。另外，還需要在Junit Runner類註解中添加Allure插件。

設置自動測試的示例：

 
<profile>
	
<id>parallel</id>
	
<build>
    	
<plugins>
        	
<plugin>
            	
<groupId>org.apache.maven.plugins</groupId>
 	
           <artifactId>maven-surefire-plugin</artifactId>
            	
<version>3.0.0-M3</version>
   	
         <configuration>
                	
<useFile>false</useFile>
                	
<testFailureIgnore>false</testFailureIgnore>
        	
        <parallel>methods</parallel>
                	
<threadCount>6</threadCount>
                	
<perCoreThreadCount>true</perCoreThreadCount>
                	
<argLine>
                    	
-javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
                	
</argLine>
            	
</configuration>
            	
<dependencies>
                	
<dependency>
                    	
<groupId>org.aspectj</groupId>
   	
                 <artifactId>aspectjweaver</artifactId>
                    	
<version>${aspectj.version}</version>
                	
</dependency>
            	
</dependencies>
        	
</plugin>
    	
</plugins>
	
</build>
</profile>

Allure 報告示例（最不穩定的測試，重新運行 5 次）

測試期間的運行器負載（8 核、8 GB RAM、24 線程）

優點：

資源消耗低；
Cucumber 的本機支持 - 無需額外工具；
每個處理器核心運行 6 個以上線程的能力。

缺點：

您需要確保代碼支持多線程執行；
進入門檻提高。

GitLab 頁面上的 Allure 報告

引入多線程啟動後，我們開始花更多時間分析報告。當時，我們必須將每個報告作為工件上傳到 GitLab，然後下載、解壓。不是很方便而且時間長。而如果其他人想在家看報告，那麼他也需要做同樣的操作。我們希望更快地獲得反饋，並且找到了出路 - GitLab 頁面。這是一個內置功能，在所有最新版本的 GitLab 中都可以開箱即用。允許您在服務器上部署靜態站點並通過直接鏈接訪問它們。

Allure 報告的所有屏幕截圖均在 GitLab 頁面上截取。用於將報告部署到 GitLab 頁面的腳本 - 在 Windows PowerShell 中（在此之前您需要運行自動測試）：

New-Item -ItemType directory -Path $testresulthistory | Out-Null

try {Invoke-WebRequest -Uri $hst -OutFile $outputhst}
Catch{echo "fail copy history"}
try {Invoke-WebRequest -Uri $hsttrend -OutFile $outputhsttrnd}
Catch{echo "fail copy history trend"}

mvn allure:report
#mvn assembly:single -PzipAllureReport
xcopy $buildlocationtargetsiteallure-maven-plugin* $buildlocationpublic /s /i /Y

其結果是

因此，如果您正在考慮 Cucumber 自動測試框架中是否需要線程安全代碼，現在答案很明顯 - 使用 Cucumber 4 可以輕鬆實現它，從而顯著增加同時啟動的線程數量。通過這種運行測試的方法，現在的問題就變成了帶有 Selenoid 的機器和測試台的性能。

實踐表明，在線程上運行自動測試可以讓您最大限度地減少資源消耗並獲得最佳性能。從圖中可以看出，線程數量增加 2 倍並不會導致通過性能測試的類似加速。儘管如此，我們還是能夠向應用程序構建添加 200 多個自動化測試，即使重新運行 5 次，也能在大約 24 分鐘內完成。這使您可以從他們那裡獲得快速反饋，並在必要時進行更改並再次重複該過程。

來源： www.habr.com

實施、規模：在 VTB 中使用自動測試的經驗

我們從哪裡開始？

單線程測試

JVM 分叉測試

如何克服不穩定因素

使用 Cucumber 4 庫進行並行測試

GitLab 頁面上的 Allure 報告

其結果是

添加評論取消回复

實施、規模：在 VTB 中使用自動測試的經驗

我們從哪裡開始？

單線程測試

JVM 分叉測試

如何克服不穩定因素

使用 Cucumber 4 庫進行並行測試

GitLab 頁面上的 Allure 報告

其結果是

添加評論 取消回复

添加評論取消回复