구현, 확장: VTB에서 자동화된 테스트를 사용한 경험

우리 부서는 새로운 버전의 애플리케이션을 프로덕션 환경에 출시하기 위한 완전 자동 파이프라인을 만듭니다. 물론 이를 위해서는 자동화된 기능 테스트가 필요합니다. 아래 컷에는 로컬 머신의 단일 스레드 테스트부터 시작하여 GitLab 페이지의 Allure 보고서를 사용하여 빌드 파이프라인의 Selenoid에서 실행되는 다중 스레드 자동 테스트를 진행하고 결국 멋진 자동화 도구를 얻은 방법에 대한 이야기가 있습니다. 미래의 사람들은 팀을 사용할 수 있습니다.

우리는 어디서 시작했나요?

자동 테스트를 구현하고 이를 파이프라인에 통합하려면 필요에 따라 유연하게 변경할 수 있는 자동화 프레임워크가 필요했습니다. 이상적으로는 자동 테스트를 파이프라인에 내장하도록 조정된 자동 테스트 엔진에 대한 단일 표준을 얻고 싶었습니다. 구현을 위해 우리는 다음 기술을 선택했습니다.

• 자바,
• 메이븐,
• 셀렌,
• 오이+4월 XNUMX일,
• 매력,
• 깃랩.

왜 이 특별한 세트인가요? Java는 자동화 테스트에 가장 널리 사용되는 언어 중 하나이며 모든 팀원이 Java를 사용합니다. 셀레늄은 확실한 해결책입니다. 무엇보다도 오이는 수동 테스트에 참여하는 부서의 자동화된 테스트 결과에 대한 신뢰도를 높이기로 되어 있었습니다.

단일 스레드 테스트

바퀴를 재발명하지 않기 위해 우리는 GitHub의 다양한 리포지토리에서 개발한 내용을 프레임워크의 기초로 삼아 스스로 조정했습니다. 우리는 자동 테스트 프레임워크의 핵심이 포함된 메인 라이브러리용 저장소와 코어에 자동 테스트를 구현하는 Gold 예제가 포함된 저장소를 만들었습니다. 각 팀은 골드 이미지를 가져와서 테스트를 개발하고 이를 프로젝트에 적용해야 했습니다. 우리는 이를 다음과 같이 구성한 GitLab-CI 은행에 배포했습니다.

• 각 프로젝트에 대한 모든 서면 자동 테스트를 매일 실행합니다.
• 빌드 파이프라인에서 시작됩니다.

처음에는 테스트가 거의 없었고 하나의 스트림으로 수행되었습니다. 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>

 
얼루어 리포트 예시

 
테스트 중 러너 로드(8개 코어, 8GB RAM, 1개 스레드)
 
단일 스레드 테스트의 장점:

• 설정 및 실행이 쉽습니다.
• CI 출시는 사실상 로컬 출시와 다르지 않습니다.
• 테스트는 서로 영향을 미치지 않습니다.
• 러너 리소스에 대한 최소 요구 사항.

단일 스레드 테스트의 단점:

• 완료하는 데 시간이 매우 오래 걸립니다.
• 테스트의 장기간 안정화;
• 러너 리소스의 비효율적 사용, 극도로 낮은 활용도.

JVM 포크 테스트

기본 프레임워크를 구현할 때 스레드로부터 안전한 코드를 처리하지 않았기 때문에 병렬로 실행하는 가장 확실한 방법은 다음과 같습니다. 오이-jvm-병렬-플러그인 메이븐의 경우. 플러그인은 구성하기 쉽지만 올바른 병렬 작동을 위해서는 별도의 브라우저에서 자동 테스트를 실행해야 합니다. 할게 없어서 셀레노이드를 써야만 했어요.

Selenoid 서버는 32개 코어와 24GB RAM을 갖춘 시스템에서 시작되었습니다. 제한은 48개 브라우저(코어당 1,5개 스레드, 약 400MB RAM)로 설정되었습니다. 그 결과 테스트 시간이 40시간에서 20분으로 단축됐다. 실행 속도를 높이면 안정화 문제를 해결하는 데 도움이 됩니다. 이제 안정적으로 실행된다는 확신이 들 때까지 새로운 자동 테스트를 30~XNUMX회 빠르게 실행할 수 있습니다.
솔루션의 첫 번째 단점은 적은 수의 병렬 스레드로 실행기 리소스의 활용도가 높다는 것입니다. 즉, 4개 코어와 8GB 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개 코어, 8GB RAM, 12개 스레드)
 
장점 :

• 쉬운 설정 - 플러그인만 추가하면 됩니다.
• 다수의 테스트를 동시에 수행하는 능력;
• 1단계 덕분에 테스트 안정화가 가속화됩니다. 

단점 :

• 여러 OS/컨테이너가 필요합니다.
• 각 포크에 대한 높은 리소스 소비;
• 플러그인이 오래되어 더 이상 지원되지 않습니다. 

불안정성을 극복하는 방법 

테스트 벤치는 자동 테스트 자체와 마찬가지로 이상적이지 않습니다. 불안정한 테스트가 많이 있다는 것은 놀라운 일이 아닙니다. 구조하러 왔어요 메이븐 확실한 플러그인, 실패한 테스트 다시 시작을 즉시 지원합니다. 플러그인 버전을 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개 코어, 8GB 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를 사용하면 구현하기가 쉬워 동시에 실행되는 스레드 수가 크게 늘어납니다. 이 테스트 실행 방법을 사용하면 이제 셀레노이드와 테스트 벤치를 갖춘 기계의 성능에 대한 질문이 생깁니다.

실습에 따르면 스레드에서 자동 테스트를 실행하면 최상의 성능으로 리소스 소비를 최소한으로 줄일 수 있습니다. 그래프에서 볼 수 있듯이 스레드를 두 배로 늘려도 성능 테스트에서는 유사한 가속이 발생하지 않습니다. 그러나 우리는 애플리케이션 빌드에 2개 이상의 자동화된 테스트를 추가할 수 있었으며 200번의 재실행에도 약 5분 만에 실행되었습니다. 이를 통해 빠른 피드백을 받을 수 있으며, 필요한 경우 변경하고 절차를 다시 반복할 수 있습니다.

출처 : habr.com