Vores afdeling skaber fuldautomatiske pipelines til lancering af nye versioner af applikationer i produktionsmiljøet. Dette kræver naturligvis automatiske funktionstests. Nedenfor klippet er en historie om, hvordan vi, startende med enkelttrådstest på en lokal maskine, gik videre til multi-trådede autotest, der kørte på Selenoid i byggepipelinen med en Allure-rapport på GitLab-sider og til sidst fik et sejt automatiseringsværktøj, der fremtidige mennesker kan bruge teams.
Hvor startede vi?
For at implementere autotests og integrere dem i pipelinen havde vi brug for en automatiseringsramme, der kunne ændres fleksibelt, så den passer til vores behov. Ideelt set ønskede jeg at få en enkelt standard for autotestmotoren, tilpasset til indlejring af autotest i pipelinen. Til implementering har vi valgt følgende teknologier:
- Java,
- Maven,
- Selen,
- Agurk+JUNIT 4,
- Lokke,
- GitLab.
Hvorfor netop dette sæt? Java er et af de mest populære sprog til automatiserede tests, og alle teammedlemmer taler det. Selen er den oplagte løsning. Agurk skulle blandt andet øge tilliden til resultaterne af automatiserede tests hos afdelinger, der er involveret i manuel test.
Test med enkelt gevind
For ikke at genopfinde hjulet, tog vi udviklinger fra forskellige repositories på GitHub som grundlag for rammerne og tilpassede dem til os selv. Vi oprettede et lager til hovedbiblioteket med kernen i autotest-rammeværket og et lager med et Gold-eksempel på implementering af autotest på vores kerne. Hvert hold skulle tage guldbilledet og udvikle test i det, tilpasse det til deres projekt. Vi implementerede det til GitLab-CI-banken, hvorpå vi konfigurerede:
- daglige kørsler af alle skriftlige autotests for hvert projekt;
- lanceres i byggepipeline.
Først var der få tests, og de blev udført i én strøm. Enkelt-trådet kørsel på Windows-løberen GitLab passede os ganske godt: testene belastede testbænken meget let og brugte næsten ingen ressourcer.
Med tiden blev antallet af autotest flere og flere, og vi tænkte på at køre dem sideløbende, da en fuld løbetur begyndte at tage omkring tre timer. Andre problemer dukkede også op:
- vi kunne ikke verificere, at testene var stabile;
- test, der blev kørt flere gange i træk på den lokale maskine, styrtede nogle gange ned i CI.
Eksempel på opsætning af autotest:
<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>
Eksempel på Allure-rapport
Løberbelastning under test (8 kerner, 8 GB RAM, 1 tråd)
Fordele ved enkelt-trådede test:
- let at sætte op og køre;
- lanceringer i CI adskiller sig praktisk talt ikke fra lokale lanceringer;
- test påvirker ikke hinanden;
- minimumskrav til løberressourcer.
Ulemper ved enkelttrådede test:
- tage meget lang tid at fuldføre;
- lang stabilisering af tests;
- ineffektiv brug af løberressourcer, ekstrem lav udnyttelse.
Test på JVM gafler
Da vi ikke tog os af trådsikker kode, da vi implementerede basisrammen, var den mest oplagte måde at køre parallelt på for Maven. Pluginnet er nemt at konfigurere, men for korrekt paralleldrift skal autotest køres i separate browsere. Der er ikke noget at gøre, jeg var nødt til at bruge Selenoid.
Selenoid-serveren blev lanceret på en maskine med 32 kerner og 24 GB RAM. Grænsen blev sat til 48 browsere - 1,5 tråde pr. kerne og omkring 400 MB RAM. Som et resultat blev testtiden reduceret fra tre timer til 40 minutter. At fremskynde kørslerne hjalp med at løse stabiliseringsproblemet: Nu kunne vi hurtigt køre nye autotests 20-30 gange, indtil vi var sikre på, at de kørte pålideligt.
Den første ulempe ved løsningen var den høje udnyttelse af løberressourcer med et lille antal parallelle tråde: På 4 kerner og 8 GB RAM fungerede testene stabilt med ikke mere end 6 tråde. Den anden ulempe: plugin'et genererer løberklasser for hvert scenarie, uanset hvor mange af dem der lanceres.
Vigtigt! Send ikke en variabel med tags til argLinefor eksempel sådan her:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Hvis du passerer tagget på denne måde, vil plugin'et generere løbere til alle test, det vil sige, at det vil forsøge at køre alle test, springe dem over umiddelbart efter lanceringen og skabe mange JVM-gafler.
Det er korrekt at smide en variabel med et tag ind i tags i plugin-indstillingerne, se eksempel nedenfor. Andre metoder, vi testede, har problemer med at forbinde Allure-plugin'et.
Eksempel på køretid for 6 korte test med forkerte indstillinger:
[INFO] Total time: 03:17 min
Eksempel på testkørselstid, hvis du direkte overfører tagget til mvn... –Agurk.optioner:
[INFO] Total time: 44.467 s
Eksempel på opsætning af autotest:
<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>
Eksempel på en Allure-rapport (den mest ustabile test, 4 gentagelser)
Løberbelastning under test (8 kerner, 8 GB RAM, 12 tråde)
Teknikere:
- nem opsætning - du skal blot tilføje et plugin;
- evnen til at udføre et stort antal test samtidigt;
- acceleration af teststabilisering takket være trin 1.
Ulemper:
- Flere OS/containere påkrævet;
- højt ressourceforbrug for hver gaffel;
- Pluginnet er forældet og understøttes ikke længere.
Hvordan man overvinder ustabilitet
Testbænke er ikke ideelle, ligesom selve autotestene. Det er ikke overraskende, at vi har en række dårlige tests. Kom til undsætning, som ud af æsken understøtter genstart af mislykkede tests. Du skal opdatere plugin-versionen til mindst 2.21 og skrive en linje med antallet af genstarter i pom-filen eller sende det som et argument til Maven.
Eksempel på opsætning af autotest:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
Eller ved opstart: mvn … -Dsurefire.rerunFailingTestsCount=2 …
Som en mulighed skal du indstille Maven-indstillinger for PowerShell-scriptet (PS1):
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"Teknikere:
- ingen grund til at spilde tid på at analysere en ustabil test, når den går ned;
- problemer med testbænkens stabilitet kan afhjælpes.
Ulemper:
- flydende defekter kan overses;
- køretiden øges.
Parallelle tests med Cucumber 4-biblioteket
Antallet af test voksede hver dag. Vi tænkte igen på at sætte fart på løbeturene. Derudover ønskede jeg at integrere så mange tests som muligt i applikationsmontage-pipeline. Den kritiske faktor var, at generationen af løbere tog for lang tid, når man løb parallelt med Maven-plugin.
På det tidspunkt var Cucumber 4 allerede blevet frigivet, så vi besluttede at omskrive kernen til denne version. I udgivelsesnoterne blev vi lovet parallel lancering på trådniveau. Teoretisk burde dette have været:
- fremskynde afviklingen af autotest betydeligt ved at øge antallet af tråde;
- eliminer tab af tid på at generere løbere for hver autotest.
At optimere rammerne for multi-threaded autotest viste sig ikke at være så svært. Cucumber 4 kører hver enkelt test på en dedikeret tråd fra start til slut, så nogle almindelige statiske ting blev simpelthen konverteret til ThreadLocal-variabler.
Det vigtigste, når du konverterer ved hjælp af Idea refactoring-værktøjer, er at kontrollere de steder, hvor variablen blev sammenlignet (f.eks. check for null). Derudover skal du tilføje Allure-pluginnet til Junit Runner-klasseannotationen.
Eksempel på opsætning af autotest:
<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>
Eksempel på en Allure-rapport (den mest ustabile test, 5 gentagelser)
Løberbelastning under test (8 kerner, 8 GB RAM, 24 tråde)
Teknikere:
- lavt ressourceforbrug;
- indfødt støtte fra Agurk - ingen yderligere værktøjer påkrævet;
- evnen til at køre mere end 6 tråde pr. processorkerne.
Ulemper:
- du skal sikre dig, at koden understøtter multi-threaded udførelse;
- indgangstærsklen stiger.
Allure rapporterer på GitLab-sider
Efter at have introduceret multi-threaded udførelse, begyndte vi at bruge meget mere tid på at analysere rapporter. På det tidspunkt skulle vi uploade hver rapport som en artefakt til GitLab, derefter downloade den og pakke den ud. Det er ikke særlig bekvemt og tager lang tid. Og hvis en anden selv ønsker at se rapporten, skal de udføre de samme handlinger. Vi ønskede at modtage feedback hurtigere, og vi fandt en løsning - GitLab-sider. Dette er en indbygget funktion, der er tilgængelig ud af boksen i alle nyere versioner af GitLab. Giver dig mulighed for at implementere statiske websteder på din server og få adgang til dem via et direkte link.
Alle skærmbilleder af Allure-rapporter blev taget på GitLab-sider. Script til at implementere rapporten til GitLab-sider - i Windows PowerShell (før dette skal du køre autotest):
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
Således at
Så hvis du tænkte på, om du har brug for trådsikker kode i Cucumber autotest-rammeværket, er svaret nu indlysende - med Cucumber 4 er det nemt at implementere det, og derved øge antallet af tråde, der lanceres samtidigt. Med denne metode til at køre test bliver spørgsmålet nu om maskinens ydeevne med Selenoid og testbænken.
Praksis har vist, at kørsel af autotest på tråde giver dig mulighed for at reducere ressourceforbruget til et minimum med den bedste ydeevne. Som det kan ses af graferne, fører fordoblingstråde ikke til en tilsvarende acceleration i ydeevnetest. Vi var dog i stand til at tilføje mere end 2 automatiserede test til applikationsopbygningen, som selv med 200 gentagelser kører på cirka 5 minutter. Dette giver dig mulighed for at modtage hurtig feedback fra dem, og om nødvendigt foretage ændringer og gentage proceduren igen.
Kilde: www.habr.com