Naš oddelek ustvarja popolnoma samodejne cevovode za lansiranje novih različic aplikacij v produkcijsko okolje. Seveda to zahteva avtomatizirane funkcionalne teste. Pod izrezom je zgodba o tem, kako smo, začenši s testiranjem ene niti na lokalnem računalniku, dosegli točko večnitnega samodejnega testiranja, ki se izvaja na Selenoidu v cevovodu gradnje s poročilom Allure na straneh GitLab in na koncu dobili kul orodje za avtomatizacijo da lahko bodoči ljudje uporabljajo ekipe.
Kje smo začeli?
Za implementacijo samodejnih testov in njihovo integracijo v cevovod smo potrebovali ogrodje za avtomatizacijo, ki ga je mogoče prilagodljivo spreminjati, da bo ustrezalo našim potrebam. V idealnem primeru sem želel dobiti en sam standard za motor za samodejno testiranje, prilagojen za vgradnjo samodejnih testov v cevovod. Za izvedbo smo izbrali naslednje tehnologije:
- Java,
- Maven,
- Selen,
- Kumara+JUNIT 4,
- privlačnost,
- GitLab.
Zakaj ravno ta komplet? Java je eden najbolj priljubljenih jezikov za avtomatizirane teste in vsi člani ekipe jo govorijo. Selen je očitna rešitev. Kumara naj bi med drugim povečala zaupanje v rezultate avtomatiziranih testov s strani oddelkov, ki se ukvarjajo z ročnim testiranjem.
Preizkusi z eno nitjo
Da ne bi znova izumljali kolesa, smo za osnovo ogrodja vzeli razvoj iz različnih repozitorijev na GitHubu in jih prilagodili sebi. Ustvarili smo repozitorij za glavno knjižnico z jedrom ogrodja samodejnega testiranja in repozitorij z zlatim primerom izvajanja samodejnih testov v našem jedru. Vsaka ekipa je morala vzeti zlato sliko in v njej razviti teste ter jo prilagoditi svojemu projektu. Razmestili smo ga v banko GitLab-CI, na kateri smo konfigurirali:
- dnevne izvedbe vseh pisnih samodejnih testov za vsak projekt;
- zažene v gradbeni fazi.
Sprva je bilo malo testov in so bili izvedeni v enem toku. Enonitno delovanje na izvajalcu Windows GitLab nam je zelo ustrezalo: testi so zelo malo obremenili preskusno napravo in porabili skoraj nič virov.
Sčasoma je število samodejnih testov postalo vse večje in razmišljali smo, da bi jih izvajali vzporedno, ko je celoten zagon začel trajati približno tri ure. Pojavile so se tudi druge težave:
- nismo mogli preveriti, ali so bili testi stabilni;
- testi, ki so bili večkrat zaporedoma izvedeni na lokalnem računalniku, so se včasih zrušili v CI.
Primer nastavitve samodejnih testov:
<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>
Primer poročila Allure
Obremenitev izvajalnika med preskusi (8 jeder, 8 GB RAM-a, 1 nit)
Prednosti enonitnih testov:
- enostavna nastavitev in zagon;
- zagoni v CI se praktično ne razlikujejo od lokalnih zagonov;
- testi ne vplivajo drug na drugega;
- minimalne zahteve za sredstva tekača.
Slabosti enonitnih testov:
- dokončanje traja zelo dolgo;
- dolga stabilizacija testov;
- neučinkovita uporaba virov tekača, izjemno nizka izkoriščenost.
Testi na vilicah JVM
Ker pri izvajanju osnovnega ogrodja nismo poskrbeli za kodo, varno za niti, je bil najočitnejši način vzporednega izvajanja za Maven. Vtičnik je enostaven za konfiguracijo, a za pravilno vzporedno delovanje je treba samodejne teste izvajati v ločenih brskalnikih. Ničesar ni, moral sem uporabiti Selenoid.
Strežnik Selenoid je bil zagnan na stroju z 32 jedri in 24 GB RAM-a. Omejitev je bila postavljena na 48 brskalnikov - 1,5 niti na jedro in približno 400 MB RAM-a. Posledično se je čas testiranja zmanjšal s treh ur na 40 minut. Pospeševanje izvajanj je pomagalo rešiti težavo s stabilizacijo: zdaj smo lahko hitro zagnali nove samodejne teste 20–30-krat, dokler nismo bili prepričani, da delujejo zanesljivo.
Prva pomanjkljivost rešitve je bila visoka izkoriščenost virov runnerja z majhnim številom vzporednih niti: na 4 jedrih in 8 GB RAM-a so testi potekali stabilno v največ 6 nitih. Druga pomanjkljivost: vtičnik ustvari razrede tekačev za vsak scenarij, ne glede na to, koliko jih je zagnanih.
Pomembno! Ne posredujte spremenljivke z oznakami v argLine, na primer takole:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Če oznako posredujete na ta način, bo vtičnik ustvaril izvajalce za vse teste, to pomeni, da bo poskušal zagnati vse teste, jih preskočil takoj po zagonu in ustvaril številne razcepe JVM.
Pravilno je vrniti spremenljivko z oznako oznake v nastavitvah vtičnika, glejte spodnji primer. Druge metode, ki smo jih preizkusili, imajo težave pri povezovanju vtičnika Allure.
Primer časa delovanja za 6 kratkih testov z nepravilnimi nastavitvami:
[INFO] Total time: 03:17 min
Primer časa preskusnega izvajanja, če neposredno prenesete oznako na mvn... –Dcucumber.options:
[INFO] Total time: 44.467 s
Primer nastavitve samodejnih testov:
<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>
Primer poročila Allure (najbolj nestabilen test, 4 ponovitve)
Obremenitev izvajalnika med preskusi (8 jeder, 8 GB RAM-a, 12 niti)
Profesionalci:
- enostavna nastavitev - samo dodati morate vtičnik;
- sposobnost hkratnega izvajanja velikega števila testov;
- pospešitev preskusne stabilizacije zahvaljujoč 1. koraku.
Cons:
- Potreben je več OS/vsebnikov;
- visoka poraba virov za vsako vilico;
- Vtičnik je zastarel in ni več podprt.
Kako premagati nestabilnost
Testne mize niso idealne, tako kot sami avtotesti. Ni presenetljivo, da imamo številne slabe teste. Priskočil na pomoč, ki takoj po namestitvi podpira ponovni zagon neuspelih testov. Različico vtičnika morate posodobiti na vsaj 2.21 in napisati eno vrstico s številom ponovnih zagonov v datoteko pom ali jo posredovati kot argument Mavenu.
Primer nastavitve samodejnih testov:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
Ali ob zagonu: mvn … -Dsurefire.rerunFailingTestsCount=2 …
Kot možnost nastavite možnosti Maven za skript PowerShell (PS1):
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"Profesionalci:
- ni potrebe po izgubljanju časa z analizo nestabilnega testa, ko se zruši;
- težave s stabilnostjo preskusne naprave je mogoče ublažiti.
Cons:
- plavajoče napake je mogoče spregledati;
- čas delovanja se poveča.
Vzporedni testi s knjižnico Cucumber 4
Število testov je naraščalo vsak dan. Spet smo razmišljali, da bi pospešili teke. Poleg tega sem želel integrirati čim več testov v cevovod za sestavljanje aplikacije. Kritični dejavnik je bil, da je generacija tekačev trajala predolgo pri vzporednem izvajanju z uporabo vtičnika Maven.
Takrat je Cucumber 4 že izšel, zato smo se odločili, da prepišemo jedro za to različico. V opombah ob izdaji nam je bil obljubljen vzporedni zagon na ravni niti. Teoretično bi to moralo biti:
- znatno pospešite izvajanje samodejnih testov s povečanjem števila niti;
- odpravite izgubo časa pri ustvarjanju tekačev za vsak samodejni test.
Izkazalo se je, da optimizacija okvira za večnitne samodejne teste ni tako težka. Cucumber 4 izvaja vsak posamezen test na namenski niti od začetka do konca, zato so bile nekatere običajne statične stvari preprosto pretvorjene v spremenljivke ThreadLocal.
Glavna stvar pri pretvorbi z orodji za refaktoriranje Idea je preverjanje mest, kjer je bila spremenljivka primerjana (na primer preverjanje ničelnosti). Poleg tega morate v opombo razreda Junit Runner dodati vtičnik Allure.
Primer nastavitve samodejnih testov:
<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>
Primer poročila Allure (najbolj nestabilen test, 5 ponovitev)
Obremenitev izvajalnika med preskusi (8 jeder, 8 GB RAM-a, 24 niti)
Profesionalci:
- nizka poraba virov;
- izvorna podpora iz Cucumber - dodatna orodja niso potrebna;
- možnost izvajanja več kot 6 niti na procesorsko jedro.
Cons:
- zagotoviti morate, da koda podpira večnitno izvajanje;
- vstopni prag se poveča.
Poročila Allure na straneh GitLab
Po uvedbi večnitnega izvajanja smo začeli veliko več časa posvečati analizi poročil. Takrat smo morali vsako poročilo naložiti kot artefakt v GitLab, nato pa ga prenesti in razpakirati. Ni zelo priročno in traja dolgo. In če si kdo želi poročilo ogledati sam, bo moral opraviti enake operacije. Želeli smo hitreje prejeti povratne informacije in našli smo rešitev – GitLab strani. To je vgrajena funkcija, ki je takoj na voljo v vseh novejših različicah GitLaba. Omogoča namestitev statičnih spletnih mest na vašem strežniku in dostop do njih prek neposredne povezave.
Vsi posnetki zaslona poročil Allure so bili posneti na straneh GitLab. Skript za razmestitev poročila na strani GitLab - v lupini Windows PowerShell (pred tem morate zagnati samodejne teste):
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
Kar pomeni, da
Torej, če ste razmišljali o tem, ali potrebujete Thread varno kodo v ogrodju za samodejno testiranje Cucumber, je zdaj odgovor očiten - s Cucumber 4 jo je enostavno implementirati in s tem znatno povečati število istočasno zagnanih niti. S to metodo izvajanja testov se zdaj postavlja vprašanje o zmogljivosti stroja s Selenoidom in preskusno napravo.
Praksa je pokazala, da izvajanje samodejnih testov na nitih omogoča zmanjšanje porabe virov na minimum z najboljšo zmogljivostjo. Kot je razvidno iz grafov, podvojitev niti ne vodi do podobnega pospeška pri preizkusih zmogljivosti. Vendar pa smo lahko v gradnjo aplikacije dodali več kot 2 avtomatiziranih testov, ki se tudi s 200 ponovitvami izvedejo v približno 5 minutah. To vam omogoča, da od njih prejmete hitre povratne informacije in po potrebi spremenite in ponovite postopek.
Vir: www.habr.com