Vår avdeling lager helautomatiske rørledninger for lansering av nye versjoner av applikasjoner i produksjonsmiljøet. Dette krever selvfølgelig automatiserte funksjonstester. Under kuttet er en historie om hvordan vi startet med enkelttrådstesting på en lokal maskin, nådde poenget med flertråds autotest som kjører på Selenoid i byggepipelinen med en Allure-rapport på GitLab-sider og til slutt fikk et kult automatiseringsverktøy at fremtidige mennesker kan bruke team.
Hvor begynte vi?
For å implementere autotester og integrere dem i pipeline, trengte vi et automatiseringsrammeverk som kunne endres fleksibelt for å passe våre behov. Ideelt sett ønsket jeg å få en enkelt standard for autotestmotoren, tilpasset for å bygge inn autotester i rørledningen. For implementering valgte vi følgende teknologier:
- Java,
- Maven,
- selen,
- Agurk+JUNIT 4,
- lokke,
- GitLab.
Hvorfor akkurat dette settet? Java er et av de mest populære språkene for automatiserte tester, og alle teammedlemmer snakker det. Selen er den åpenbare løsningen. Agurk, blant annet, skulle øke tilliten til resultatene av automatiserte tester hos avdelinger som er involvert i manuell testing.
Enkeltgjengede tester
For ikke å finne opp hjulet på nytt, tok vi utviklinger fra ulike repositories på GitHub som grunnlag for rammeverket og tilpasset dem for oss selv. Vi opprettet et depot for hovedbiblioteket med kjernen i autotestrammeverket og et depot med et gulleksempel på implementering av autotester på kjernen vår. Hvert team måtte ta gullbildet og utvikle tester i det, tilpasse det til prosjektet deres. Vi distribuerte den til GitLab-CI-banken, som vi konfigurerte på:
- daglige kjøringer av alle skriftlige autotester for hvert prosjekt;
- lanseres i byggepipeline.
Først var det få tester, og de ble utført i én bekk. Enkeltrådskjøring på Windows-løperen GitLab passet oss ganske bra: testene lastet testbenken veldig lett og brukte nesten ingen ressurser.
Over tid ble antallet autotester flere og flere, og vi tenkte å kjøre dem parallelt, da en full kjøring begynte å ta rundt tre timer. Andre problemer dukket også opp:
- vi kunne ikke bekrefte at testene var stabile;
- tester som ble kjørt flere ganger på rad på den lokale maskinen krasjet noen ganger i CI.
Eksempel på oppsett av autotester:
<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å lokkerapport
Løperbelastning under tester (8 kjerner, 8 GB RAM, 1 tråd)
Fordeler med entrådede tester:
- enkel å sette opp og kjøre;
- lanseringer i CI er praktisk talt ikke forskjellig fra lokale lanseringer;
- tester påvirker ikke hverandre;
- minimumskrav til løperressurser.
Ulemper med entrådede tester:
- ta veldig lang tid å fullføre;
- lang stabilisering av tester;
- ineffektiv bruk av løperressurser, ekstremt lav utnyttelse.
Tester på JVM gafler
Siden vi ikke tok vare på trådsikker kode da vi implementerte basisrammeverket, var den mest åpenbare måten å kjøre parallelt på for Maven. Plugin-en er enkel å konfigurere, men for korrekt parallelldrift må autotester kjøres i separate nettlesere. Det er ingenting å gjøre, jeg måtte bruke Selenoid.
Selenoid-serveren ble lansert på en maskin med 32 kjerner og 24 GB RAM. Grensen ble satt til 48 nettlesere – 1,5 tråder per kjerne og omtrent 400 MB RAM. Som et resultat ble testtiden redusert fra tre timer til 40 minutter. Å få fart på løpeturene hjalp til med å løse stabiliseringsproblemet: nå kunne vi raskt kjøre nye autotester 20–30 ganger til vi var sikre på at de kjørte pålitelig.
Den første ulempen med løsningen var høy utnyttelse av løperressurser med et lite antall parallelle tråder: på 4 kjerner og 8 GB RAM kjørte testene stabilt i ikke mer enn 6 tråder. Den andre ulempen: plugin-en genererer løperklasser for hvert scenario, uansett hvor mange av dem som lanseres.
Viktig! Ikke send en variabel med tagger til argLine, for eksempel slik:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Hvis du passerer taggen på denne måten, vil plugin generere løpere for alle tester, det vil si at den vil prøve å kjøre alle tester, hoppe over dem umiddelbart etter lansering og lage mange JVM-gafler.
Det er riktig å kaste en variabel med en tag inn i tags i plugin-innstillingene, se eksempel nedenfor. Andre metoder vi testet har problemer med å koble til Allure-plugin.
Eksempel på kjøretid for 6 korte tester med feil innstillinger:
[INFO] Total time: 03:17 min
Eksempel på testkjøringstid hvis du overfører taggen direkte til mvn... –Agurk.alternativer:
[INFO] Total time: 44.467 s
Eksempel på oppsett av autotester:
<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 testen, 4 repriser)
Løperbelastning under tester (8 kjerner, 8 GB RAM, 12 tråder)
Pros:
- enkelt oppsett - du trenger bare å legge til en plugin;
- evnen til å utføre et stort antall tester samtidig;
- akselerasjon av teststabilisering takket være trinn 1.
Cons:
- Flere OS/beholdere kreves;
- høyt ressursforbruk for hver gaffel;
- Programtillegget er utdatert og støttes ikke lenger.
Hvordan overvinne ustabilitet
Testbenker er ikke ideelle, akkurat som selve autotestene. Det er ikke overraskende at vi har en rekke feilaktige tester. Kom til unnsetning, som ut av esken støtter omstart av mislykkede tester. Du må oppdatere plugin-versjonen til minst 2.21 og skrive én linje med antall omstarter i pom-filen eller sende den som et argument til Maven.
Eksempel på oppsett av autotester:
<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 oppstart: mvn … -Dsurefire.rerunFailingTestsCount=2 …
Som et alternativ kan du angi Maven-alternativer for PowerShell-skriptet (PS1):
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"Pros:
- ingen grunn til å kaste bort tid på å analysere en ustabil test når den krasjer;
- problemer med testbenkens stabilitet kan reduseres.
Cons:
- flytende defekter kan bli savnet;
- kjøretiden øker.
Parallelle tester med Cucumber 4-biblioteket
Antall tester vokste hver dag. Vi tenkte igjen på å få fart på løpeturene. I tillegg ønsket jeg å integrere så mange tester som mulig i applikasjonsmonteringsrørledningen. Den kritiske faktoren var at generasjonen av løpere tok for lang tid når de løp parallelt med Maven-plugin.
På det tidspunktet var Cucumber 4 allerede utgitt, så vi bestemte oss for å omskrive kjernen for denne versjonen. I utgivelsesnotatene ble vi lovet parallell lansering på trådnivå. Teoretisk sett burde dette vært:
- øke hastigheten på kjøringen av autotester betydelig ved å øke antall tråder;
- eliminer tap av tid på å generere løpere for hver autotest.
Å optimalisere rammeverket for flertrådede autotester viste seg ikke å være så vanskelig. Cucumber 4 kjører hver enkelt test på en dedikert tråd fra start til slutt, så noen vanlige statiske ting ble ganske enkelt konvertert til ThreadLocal-variabler.
Det viktigste når du konverterer med Idea refactoring-verktøy er å sjekke stedene der variabelen ble sammenlignet (for eksempel sjekke for null). I tillegg må du legge til Allure-pluginen til Junit Runner-klassekommentaren.
Eksempel på oppsett av autotester:
<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 testen, 5 repriser)
Løperbelastning under tester (8 kjerner, 8 GB RAM, 24 tråder)
Pros:
- lavt ressursforbruk;
- innfødt støtte fra agurk - ingen ekstra verktøy kreves;
- muligheten til å kjøre mer enn 6 tråder per prosessorkjerne.
Cons:
- du må sørge for at koden støtter flertrådskjøring;
- inngangsterskelen øker.
Allure rapporterer på GitLab-sider
Etter å ha introdusert flertrådsutførelse, begynte vi å bruke mye mer tid på å analysere rapporter. På den tiden måtte vi laste opp hver rapport som en artefakt til GitLab, deretter laste den ned og pakke den ut. Det er ikke veldig praktisk og tar lang tid. Og hvis noen andre ønsker å se rapporten selv, må de gjøre de samme operasjonene. Vi ønsket å få tilbakemelding raskere, og vi fant en løsning - GitLab-sider. Dette er en innebygd funksjon som er tilgjengelig ut av esken i alle nyere versjoner av GitLab. Lar deg distribuere statiske nettsteder på serveren din og få tilgang til dem via en direkte lenke.
Alle skjermbilder av Allure-rapporter ble tatt på GitLab-sider. Skript for å distribuere rapporten til GitLab-sider - i Windows PowerShell (før dette må du kjøre autotester):
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
Med det resultat at
Så hvis du tenkte på om du trenger trådsikker kode i Cucumber-autotestrammeverket, er svaret nå åpenbart - med Cucumber 4 er det enkelt å implementere det, og dermed øke antallet tråder som lanseres samtidig. Med denne metoden for å kjøre tester er spørsmålet om ytelsen til maskinen med Selenoid og testbenken.
Praksis har vist at å kjøre autotester på tråder lar deg redusere ressursforbruket til et minimum med best ytelse. Som det fremgår av grafene, fører ikke doble tråder til tilsvarende akselerasjon i ytelsestester. Vi var imidlertid i stand til å legge til mer enn 2 automatiserte tester til applikasjonsbyggingen, som selv med 200 omkjøringer kjøres på omtrent 5 minutter. Dette lar deg få rask tilbakemelding fra dem, og om nødvendig gjøre endringer og gjenta prosedyren på nytt.
Kilde: www.habr.com