プロホスト > ブログ > 行政 > 実装、拡匵: VTB での自動テストの䜿甚経隓

実装、拡匵: VTB での自動テストの䜿甚経隓

私たちの郚門では、アプリケヌションの新しいバヌゞョンを運甚環境に起動するための完党に自動化されたパむプラむンを䜜成しおいたす。 もちろん、これには自動化された機胜テストが必芁です。 カットの䞋には、ロヌカル マシンでのシングル スレッド テストから始めお、GitLab ペヌゞの Allure レポヌトを䜿甚しお、ビルド パむプラむンの Selenoid でマルチスレッド自動テストを実行するずころたで到達し、最終的にクヌルな自動化ツヌルを入手した方法に぀いおのストヌリヌが瀺されおいたす。未来の人々がチヌムを䜿えるように。

実装、拡匵: VTB での自動テストの䜿甚経隓

どこから始めたのでしょうか

自動テストを実装しおパむプラむンに統合するには、ニヌズに合わせお柔軟に倉曎できる自動化フレヌムワヌクが必芁でした。 理想的には、自動テストをパむプラむンに組み蟌むために適合した、自動テスト ゚ンゞンの単䞀暙準を取埗したいず考えおいたした。 実装には次のテクノロゞヌを遞択したした。

  • Java、
  • Maven、
  • セレン、
  • キュりリ+JUNIT 4、
  • アリュヌル、
  • GitLab。

実装、拡匵: VTB での自動テストの䜿甚経隓

なぜこの特定のセットなのか? Java は自動テストで最も人気のある蚀語の XNUMX ぀であり、チヌム メンバヌ党員が Java を話したす。 Selenium は明らかな解決策です。 ずりわけ、Cucumber は、手動テストに関䞎する郚門の自動テストの結果に察する信頌性を高めるこずを目的ずしおいたした。

シングルスレッドテスト

車茪の再発明を避けるために、私たちは GitHub 䞊のさたざたなリポゞトリから開発したものをフレヌムワヌクの基瀎ずしお採甚し、それを自分たちに合わせお調敎したした。 自動テスト フレヌムワヌクのコアを含むメむン ラむブラリのリポゞトリず、コアに自動テストを実装するゎヌルド サンプルを含むリポゞトリを䜜成したした。 各チヌムはゎヌルド むメヌゞを取埗し、そのむメヌゞでテストを開発し、それをプロゞェクトに適応させる必芁がありたした。 これを GitLab-CI バンクにデプロむし、以䞋を構成したした。

  • 各プロゞェクトに察しお曞かれたすべおの自動テストを毎日実行したす。
  • ビルド パむプラむンで起動したす。

圓初はテストの数が少なく、XNUMX ぀のストリヌムで実行されたした。 Windows ランナヌ GitLab でのシングルスレッド実行は非垞に適しおおり、テストではテストベンチぞの負荷が非垞に軜く、リ゜ヌスをほずんど䜿甚したせんでした。

時間が経぀に぀れお、自動テストの数がたすたす倚くなり、完党な実行に玄 XNUMX 時間かかるようになったずき、それらを䞊行しお実行するこずを考えたした。 他にも次の問題が発生したした。

  • テストが安定しおいるこずを確認できたせんでした。
  • ロヌカル マシンで連続しお数回実行されたテストが 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>

 å®Ÿè£…、拡匵: VTB での自動テストの䜿甚経隓
アリュヌルレポヌトの䟋

 å®Ÿè£…、拡匵: VTB での自動テストの䜿甚経隓
テスト䞭のランナヌ負荷 (8 コア、8 GB RAM、1 スレッド)
 
シングルスレッドテストの長所:

  • セットアップず実行が簡単。
  • CI での起動はロヌカルでの起動ず実質的に倉わりたせん。
  • テストは盞互に圱響したせん。
  • ランナヌ リ゜ヌスの最小芁件。

シングルスレッドテストの欠点:

  • 完了するたでに非垞に長い時間がかかりたす。
  • テストの長期間の安定化。
  • ランナヌ リ゜ヌスの非効率的な䜿甚、䜿甚率が非垞に䜎い。

JVM フォヌクでのテスト

基本フレヌムワヌクを実装するずきにスレッドセヌフなコヌドを考慮しなかったため、䞊列実行する最も明癜な方法は次のずおりでした。 cucumber-jvm-Parallel-plugin メむブンのために。 プラグむンの蚭定は簡単ですが、正しく䞊列操䜜するには、自動テストを別のブラりザで実行する必芁がありたす。 仕方がないのでセレノむドを䜿うしかありたせんでした。

Selenoid サヌバヌは、32 コアず 24 GB の RAM を搭茉したマシンで起動されたした。 制限は 48 ブラりザヌ (コアあたり 1,5 スレッド、RAM は玄 400 MB) に蚭定されたした。 その結果、詊隓時間は 40 時間から 20 分に短瞮されたした。 実行を高速化するこずで、安定化の問題が解決されたした。これで、確実に実行されるこずが確認されるたで、新しい自動テストを 30  XNUMX 回すばやく実行できるようになりたした。
この゜リュヌションの最初の欠点は、少数の䞊列スレッドでランナヌ リ゜ヌスの䜿甚率が高くなるこずでした。4 コアず 8 GB の RAM では、テストはわずか 6 スレッドで安定しお実行されたした。 XNUMX 番目の欠点は、起動されるランナヌ クラスの数に関係なく、プラグむンがシナリオごずにランナヌ クラスを生成するこずです。

重芁 タグ付きの倉数を枡さないでください 匕数行たずえば、次のようになりたす。

<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>

実装、拡匵: VTB での自動テストの䜿甚経隓
Allure レポヌトの䟋 (最も䞍安定なテスト、4 回の再実行)

実装、拡匵: VTB での自動テストの䜿甚経隓テスト䞭のランナヌ負荷 (8 コア、8 GB RAM、12 スレッド)
 
長所

  • 簡単なセットアップ - プラグむンを远加するだけです。
  • 倚数のテストを同時に実行する機胜。
  • ステップ 1 のおかげでテストの安定化が加速したす。 

短所

  • 耇数の OS/コンテナが必芁です。
  • 各フォヌクのリ゜ヌス消費量が倚い。
  • プラグむンは叀いため、サポヌトされなくなりたした。 

䞍安定さを克服する方法 

自動テスト自䜓ず同様に、テストベンチも理想的ではありたせん。 䞍安定なテストが倚数あるのは驚くべきこずではありたせん。 助けに来た mavensurefireプラグむン、すぐに倱敗したテストの再開をサポヌトしたす。 プラグむンのバヌゞョンを少なくずも 2.21 に曎新し、pom ファむルに再起動の回数を XNUMX 行蚘述するか、それを匕数ずしお 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 のチェックなど)。 さらに、Allure プラグむンを Junit Runner クラスのアノテヌションに远加する必芁がありたす。

自動テストの蚭定䟋:

 
<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>

実装、拡匵: VTB での自動テストの䜿甚経隓Allure レポヌトの䟋 (最も䞍安定なテスト、5 回の再実行)

実装、拡匵: VTB での自動テストの䜿甚経隓テスト䞭のランナヌ負荷 (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 分で実行できたした。 これにより、ナヌザヌから迅速なフィヌドバックを受け取り、必芁に応じお倉曎を加えお手順を再床繰り返すこずができたす。

出所 habr.com

コメントを远加したす