Ons afdeling skep ten volle outomatiese pyplyne vir die bekendstelling van nuwe weergawes van toepassings in die produksie-omgewing. Dit vereis natuurlik outomatiese funksionele toetse. Onder die snit is 'n storie oor hoe ons, begin met enkeldraad-toetsing op 'n plaaslike masjien, die punt bereik het van multi-draad outotoets wat op Selenoid in die boupyplyn loop met 'n Allure-verslag op GitLab-bladsye en uiteindelik 'n oulike outomatiseringsinstrument gekry het. dat toekomstige mense spanne kan gebruik.
Waar het ons begin
Om outotoetse te implementeer en in die pyplyn te integreer, het ons 'n outomatiseringsraamwerk nodig gehad wat buigsaam verander kon word om aan ons behoeftes te voldoen. Ideaal gesproke wou ek 'n enkele standaard vir die outotoetsenjin kry, aangepas om outotoetse in die pyplyn in te sluit. Vir implementering het ons die volgende tegnologieë gekies:
- Java,
- Maven,
- selenium,
- Komkommer+JUNIT 4,
- Allure,
- gitlab.
Hoekom hierdie spesifieke stel? Java is een van die gewildste tale vir outomatiese toetse, en alle spanlede praat dit. Selenium is die voor die hand liggende oplossing. Komkommer was onder meer veronderstel om vertroue in die resultate van geoutomatiseerde toetse aan die kant van departemente wat by handtoetsing betrokke is, te verhoog.
Enkeldraadtoetse
Om nie die wiel weer uit te vind nie, het ons ontwikkelings uit verskeie bewaarplekke op GitHub as basis vir die raamwerk geneem en dit vir onsself aangepas. Ons het 'n bewaarplek vir die hoofbiblioteek geskep met die kern van die outotoetsraamwerk en 'n bewaarplek met 'n goue voorbeeld van die implementering van outotoetse op ons kern. Elke span moes die Goue-beeld neem en toetse daarin ontwikkel en dit by hul projek aanpas. Ons het dit na die GitLab-CI-bank ontplooi, waarop ons gekonfigureer het:
- daaglikse lopies van alle geskrewe outotoetse vir elke projek;
- bekendstellings in die boupyplyn.
Aanvanklik was daar min toetse, en dit is in een stroom uitgevoer. Enkeldraad-hardloop op die Windows-hardloper GitLab het ons baie goed gepas: die toetse het die toetsbank baie lig gelaai en byna geen hulpbronne gebruik nie.
Met verloop van tyd het die aantal outotoetse al hoe meer geword, en ons het daaraan gedink om dit parallel te laat loop, toe 'n volle lopie ongeveer drie uur begin neem het. Ander probleme het ook verskyn:
- ons kon nie verifieer dat die toetse stabiel was nie;
- toetse wat verskeie kere in 'n ry op die plaaslike masjien uitgevoer is, het soms in CI neergestort.
Voorbeeld van die opstel van outotoetse:
<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>
Allure verslag voorbeeld
Hardloperlading tydens toetse (8 kerne, 8 GB RAM, 1 draad)
Voordele van enkeldraadtoetse:
- maklik om op te stel en te bestuur;
- bekendstellings in CI verskil feitlik nie van plaaslike bekendstellings nie;
- toetse raak mekaar nie;
- minimum vereistes vir hardloperhulpbronne.
Nadele van enkeldraadtoetse:
- neem baie lank om te voltooi;
- lang stabilisering van toetse;
- ondoeltreffende gebruik van hardloperhulpbronne, uiters lae benutting.
Toetse op JVM vurke
Aangesien ons nie gesorg het vir draadveilige kode toe ons die basisraamwerk geïmplementeer het nie, was die mees voor die hand liggende manier om parallel te loop vir Maven. Die inprop is maklik om te konfigureer, maar vir korrekte parallelle werking moet outotoetse in aparte blaaiers uitgevoer word. Daar is niks om te doen nie, ek moes Selenoid gebruik.
Die Selenoid-bediener is bekendgestel op 'n masjien met 32 kerne en 24 GB RAM. Die limiet is op 48 blaaiers gestel - 1,5 drade per kern en ongeveer 400 MB RAM. Gevolglik is die toetstyd van drie uur tot 40 minute verminder. Die bespoediging van die lopies het gehelp om die stabiliseringsprobleem op te los: nou kon ons vinnig nuwe outotoetse 20–30 keer uitvoer totdat ons seker was dat hulle betroubaar gehardloop het.
Die eerste nadeel van die oplossing was die hoë benutting van hardloperhulpbronne met 'n klein aantal parallelle drade: op 4 kerne en 8 GB RAM het die toetse stabiel in nie meer as 6 drade geloop nie. Die tweede nadeel: die inprop genereer hardloperklasse vir elke scenario, maak nie saak hoeveel van hulle bekendgestel word nie.
Belangrik! Moenie 'n veranderlike met etikette aan gee nie argLyn, byvoorbeeld, soos volg:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
As jy die merker op hierdie manier slaag, sal die inprop hardlopers vir alle toetse genereer, dit wil sê, dit sal probeer om alle toetse uit te voer, dit onmiddellik na die bekendstelling oorslaan en baie JVM-vurke skep.
Dit is korrek om 'n veranderlike met 'n merker in te gooi tags in die inpropinstellings, sien voorbeeld hieronder. Ander metodes wat ons getoets het, het probleme om die Allure-inprop te koppel.
Voorbeeld van looptyd vir 6 kort toetse met verkeerde instellings:
[INFO] Total time: 03:17 min
Voorbeeld van toetslooptyd as jy die merker direk oordra na mvn... –Komkommer.opsies:
[INFO] Total time: 44.467 s
Voorbeeld van die opstel van outotoetse:
<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>
Voorbeeld van 'n Allure-verslag (die mees onstabiele toets, 4 herhalings)
Hardloperlading tydens toetse (8 kerns, 8 GB RAM, 12 drade)
Pros:
- maklike opstelling - jy hoef net 'n inprop by te voeg;
- die vermoë om 'n groot aantal toetse gelyktydig uit te voer;
- versnelling van toetsstabilisering danksy stap 1.
Nadele:
- Veelvuldige bedryfstelsels/houers benodig;
- hoë hulpbronverbruik vir elke vurk;
- Die inprop is verouderd en word nie meer ondersteun nie.
Hoe om onstabiliteit te oorkom
Toetsbanke is nie ideaal nie, net soos die outotoetse self. Dit is nie verbasend dat ons 'n aantal swak toetse het nie. Het tot die redding gekom, wat uit die boks die herbegin van mislukte toetse ondersteun. Jy moet die inpropweergawe opdateer na ten minste 2.21 en een reël met die aantal herbeginsels in die pom-lêer skryf of dit as 'n argument aan Maven deurgee.
Voorbeeld van die opstel van outotoetse:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
Of by opstart: mvn … -Dsurefire.rerunFailingTestsCount=2 …
As 'n opsie, stel Maven-opsies vir die PowerShell-skrip (PS1):
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"Pros:
- nie nodig om tyd te mors om 'n onstabiele toets te ontleed wanneer dit ineenstort nie;
- toetsbankstabiliteitsprobleme kan versag word.
Nadele:
- drywende defekte kan gemis word;
- looptyd neem toe.
Parallelle toetse met die Cucumber 4-biblioteek
Die aantal toetse het elke dag gegroei. Ons het weer daaraan gedink om die lopies te versnel. Boonop wou ek soveel toetse as moontlik in die toepassingsamestellingspyplyn integreer. Die kritieke faktor was dat die generasie hardlopers te lank geneem het wanneer hulle parallel gehardloop het met die Maven-inprop.
Op daardie tydstip was Cucumber 4 reeds vrygestel, so ons het besluit om die kern vir hierdie weergawe te herskryf. In die vrystellingnotas is ons beloof om parallelle bekendstelling op draadvlak te hê. Teoreties moes dit gewees het:
- versnel die loop van outotoetse aansienlik deur die aantal drade te verhoog;
- elimineer die verlies van tyd om hardlopers vir elke outotoets te genereer.
Dit blyk nie so moeilik te wees om die raamwerk vir multi-threaded outotoetse te optimaliseer nie. Cucumber 4 voer elke individuele toets op 'n toegewyde draad van begin tot einde, so 'n paar algemene statiese dinge is eenvoudig omgeskakel na ThreadLocal veranderlikes.
Die belangrikste ding by die omskakeling deur gebruik te maak van Idea-herfaktoreringsinstrumente is om die plekke waar die veranderlike vergelyk is, na te gaan (byvoorbeeld om te kyk vir nul). Daarbenewens moet jy die Allure-inprop by die Junit Runner-klasaantekening voeg.
Voorbeeld van die opstel van outotoetse:
<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>
Voorbeeld van 'n Allure-verslag (die mees onstabiele toets, 5 herhalings)
Hardloperlading tydens toetse (8 kerns, 8 GB RAM, 24 drade)
Pros:
- lae hulpbronverbruik;
- inheemse ondersteuning van komkommer - geen bykomende gereedskap benodig nie;
- die vermoë om meer as 6 drade per verwerkerkern te laat loop.
Nadele:
- jy moet verseker dat die kode multi-threaded uitvoering ondersteun;
- die toegangsdrempel verhoog.
Allure berig op GitLab-bladsye
Nadat ons multi-threaded uitvoering bekend gestel het, het ons baie meer tyd begin spandeer om verslae te ontleed. Op daardie tydstip moes ons elke verslag as 'n artefak na GitLab oplaai, dit dan aflaai en uitpak. Dit is nie baie gerieflik nie en neem lank. En as iemand anders die verslag self wil bekyk, sal hulle dieselfde bewerkings moet doen. Ons wou vinniger terugvoer ontvang, en ons het 'n oplossing gevind - GitLab-bladsye. Dit is 'n ingeboude kenmerk wat uit die boks beskikbaar is in alle onlangse weergawes van GitLab. Laat jou toe om statiese werwe op jou bediener te ontplooi en toegang daartoe te verkry via 'n direkte skakel.
Alle skermkiekies van Allure-verslae is op GitLab-bladsye geneem. Skrip vir die implementering van die verslag na GitLab-bladsye - in Windows PowerShell (voor dit moet jy outotoetse uitvoer):
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
Met die gevolg dat
Dus, as jy daaraan gedink het of jy draadveilige kode in die Cucumber-outotoetsraamwerk nodig het, is die antwoord nou voor die hand liggend - met Cucumber 4 is dit maklik om dit te implementeer, en sodoende die aantal drade wat gelyktydig bekendgestel word, aansienlik verhoog. Met hierdie metode om toetse uit te voer, word die vraag nou oor die werkverrigting van die masjien met Selenoid en die toetsbank.
Die praktyk het getoon dat die uitvoering van outotoetse op drade jou toelaat om hulpbronverbruik tot 'n minimum te verminder met die beste werkverrigting. Soos uit die grafieke gesien kan word, lei verdubbelingdrade nie tot 'n soortgelyke versnelling in prestasietoetse nie. Ons kon egter meer as 2 outomatiese toetse by die toepassingsbou voeg, wat selfs met 200 herhalings in ongeveer 5 minute loop. Dit laat jou toe om vinnige terugvoer van hulle te ontvang, en, indien nodig, veranderinge aan te bring en die prosedure weer te herhaal.
Bron: will.com