Meie divisjon loob täisautomaatseid torujuhtmeid rakenduste uute versioonide käivitamiseks tootmiskeskkonda. Loomulikult on selleks vaja automatiseeritud funktsionaalseid teste. Lõike all on lugu sellest, kuidas alustasime ühe lõimega testimisest kohalikus masinas, jätkasime koostamise protsessis Selenoidil töötavate mitme lõimega automaattestidega koos Allure'i aruandega GitLabi lehtedel ja saime lõpuks laheda automatiseerimistööriista, mis tulevased inimesed saavad kasutada meeskondi.
Kust me alustasime?
Autotestide juurutamiseks ja nende integreerimiseks torusse vajasime automatiseerimisraamistikku, mida saaks paindlikult meie vajadustele vastavaks muuta. Ideaalis tahtsin saada automaattestimise mootori jaoks ühtse standardi, mis on kohandatud automaattestide manustamiseks torujuhtmesse. Rakendamiseks valisime järgmised tehnoloogiad:
- Java,
- Maven,
- seleen,
- Kurk+JUNIT 4,
- Ahvatlus,
- GitLab.
Miks just see komplekt? Java on automatiseeritud testide jaoks üks populaarsemaid keeli ja kõik meeskonnaliikmed räägivad seda. Seleen on ilmselge lahendus. Kurk pidi muu hulgas suurendama käsitsi testimisega seotud osakondade usaldust automatiseeritud testide tulemuste vastu.
Ühe keermega testid
Et jalgratast mitte uuesti leiutada, võtsime raamistiku aluseks GitHubi erinevatest hoidlatest pärit arendused ja kohandasime need enda jaoks. Lõime põhiteegi jaoks hoidla automaattesti raamistiku tuumaga ja hoidla kuldse näitega automaattestide rakendamisest meie tuumas. Iga meeskond pidi võtma Kuldpildi ja töötama selles välja testid, kohandades seda oma projektiga. Juurutasime selle GitLab-CI panka, kus konfigureerisime:
- iga projekti kõigi kirjalike automaattestide igapäevased jooksud;
- käivitub ehitusprotsessis.
Algul oli katseid vähe ja need viidi läbi ühes voolus. Ühe lõimega töötamine Windowsi jooksja GitLabi peal sobis meile üsna hästi: testid laadisid testistendi väga kergelt ega kasutanud peaaegu üldse ressursse.
Aja jooksul muutus automaattestide arv järjest suuremaks ja mõtlesime nende paralleelsele läbiviimisele, kui täisjooks hakkas kestma umbes kolm tundi. Ilmnes ka muid probleeme:
- me ei saanud kontrollida, kas testid olid stabiilsed;
- mitu korda järjest kohalikus masinas tehtud testid kukkusid mõnikord CI-s kokku.
Näide automaattestide seadistamisest:
<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 aruande näide
Jooksja koormus testide ajal (8 tuuma, 8 GB RAM, 1 niit)
Ühe keermega testide plussid:
- lihtne seadistada ja käivitada;
- kaatrid CI-s praktiliselt ei erine kohalikest startidest;
- testid ei mõjuta üksteist;
- miinimumnõuded jooksja ressurssidele.
Ühe keermega testide puudused:
- valmimine võtab väga kaua aega;
- testide pikk stabiliseerimine;
- jooksja ressursside ebaefektiivne kasutamine, äärmiselt madal kasutus.
Testid JVM kahvlitel
Kuna me ei hoolitsenud baasraamistiku juurutamisel lõimekindla koodi eest, oli kõige ilmsem viis paralleelseks töötamiseks Maveni jaoks. Pluginat on lihtne seadistada, kuid korrektseks paralleeltööks tuleb automaattestid käivitada eraldi brauserites. Midagi pole teha, pidin kasutama Selenoidi.
Selenoidserver käivitati 32 tuuma ja 24 GB muutmäluga masinas. Piiranguks määrati 48 brauserit – 1,5 lõime tuuma kohta ja umbes 400 MB muutmälu. Selle tulemusena vähenes testi aeg kolmelt tunnilt 40 minutile. Jooksude kiirendamine aitas stabiliseerimisprobleemi lahendada: nüüd saime kiiresti 20–30 korda uusi automaatteste läbi viia, kuni olime kindlad, et need töötavad töökindlalt.
Lahenduse esimene puudus oli jooksja ressursside kõrge kasutamine väikese arvu paralleelsete lõimedega: 4 tuuma ja 8 GB RAM-i puhul jooksid testid stabiilselt mitte rohkem kui 6 lõimes. Teine puudus: pistikprogramm genereerib iga stsenaariumi jaoks jooksjaklassid, olenemata sellest, kui palju neid käivitatakse.
Tähtis! Ärge edastage siltidega muutujat argLine, näiteks nii:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Kui edastate sildi sel viisil, genereerib pistikprogramm kõigi testide jaoks jooksjad, st proovib käivitada kõik testid, jättes need kohe pärast käivitamist vahele ja luues palju JVM-i kahvleid.
Õige on visata sisse sildiga muutuja silte pistikprogrammi seadetes, vt näidet allpool. Muudel testitud meetoditel on probleeme Allure'i pistikprogrammi ühendamisega.
Näide tööaja kohta 6 valede seadistustega lühikese testi jaoks:
[INFO] Total time: 03:17 min
Näide testkäitusaja kohta, kui teisaldate märgendi otse aadressile mvn... –Dcucumber.options:
[INFO] Total time: 44.467 s
Näide automaattestide seadistamisest:
<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'i aruande näide (kõige ebastabiilsem test, 4 kordamist)
Jooksja koormus testide ajal (8 tuuma, 8 GB RAM, 12 lõime)
plussid:
- lihtne seadistamine - peate lihtsalt lisama pistikprogrammi;
- võimalus üheaegselt läbi viia suur hulk teste;
- testi stabiliseerimise kiirendus tänu 1. etapile.
miinuseid:
- Vaja on mitut operatsioonisüsteemi/konteinerit;
- suur ressursikulu iga kahvli jaoks;
- Pistikprogramm on aegunud ja seda enam ei toetata.
Kuidas ebastabiilsusest üle saada
Testipingid pole ideaalsed, nagu ka autotestid ise. Pole üllatav, et meil on mitmeid ebaühtlasi teste. Tuli appi, mis karbist väljas toetab ebaõnnestunud testide taaskäivitamist. Peate pistikprogrammi versiooni värskendama vähemalt versioonile 2.21 ja kirjutama pom-faili ühe rea taaskäivituste arvuga või edastama selle argumendina Mavenile.
Näide automaattestide seadistamisest:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
Või käivitamisel: mvn … -Dsurefire.rerunFailingTestsCount=2 …
Võimalusena määrake PowerShelli skripti (PS1) jaoks Maveni suvandid:
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"plussid:
- pole vaja raisata aega ebastabiilse testi analüüsimiseks, kui see kokku jookseb;
- katsestendi stabiilsusprobleeme saab leevendada.
miinuseid:
- ujuvad defektid võivad märkamata jääda;
- tööaeg pikeneb.
Paralleeltestid Cucumber 4 raamatukoguga
Testide arv kasvas iga päevaga. Jälle mõtlesime jooksude kiirendamisele. Lisaks soovisin integreerida võimalikult palju teste rakenduste kokkupanemise torujuhtmesse. Kriitiline tegur oli see, et jooksjate genereerimine võttis Maveni pistikprogrammi kasutades paralleelselt jooksmisel liiga kaua aega.
Sel ajal oli Cucumber 4 juba välja antud, mistõttu otsustasime selle versiooni kerneli ümber kirjutada. Väljalaskemärkmetes lubati meile paralleelset käivitamist lõime tasemel. Teoreetiliselt oleks see pidanud olema:
- kiirendada oluliselt automaattestide käitamist, suurendades lõimede arvu;
- kõrvaldada ajakadu iga automaattesti jaoks jooksjate genereerimisel.
Mitme keermega automaattestide raamistiku optimeerimine ei osutunud nii keeruliseks. Cucumber 4 käivitab iga üksiku testi algusest lõpuni spetsiaalse lõimega, nii et mõned tavalised staatilised asjad teisendati lihtsalt ThreadLocali muutujateks.
Idea refaktoreerimisvahendite abil teisendamisel on peamine kontrollida kohti, kus muutujat võrreldi (näiteks nulli kontrollimine). Lisaks tuleb Junit Runner klassi annotatsioonile lisada Allure plugin.
Näide automaattestide seadistamisest:
<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'i aruande näide (kõige ebastabiilsem test, 5 kordamist)
Jooksja koormus testide ajal (8 tuuma, 8 GB RAM, 24 lõime)
plussid:
- madal ressursitarbimine;
- kohalik tugi Kurgilt - täiendavaid tööriistu pole vaja;
- võime käitada rohkem kui 6 lõime protsessori tuuma kohta.
miinuseid:
- peate tagama, et kood toetab mitme lõimega täitmist;
- sisenemislävi tõuseb.
Allure'i aruanded GitLabi lehtedel
Pärast mitme lõimega täitmise tutvustamist hakkasime kulutama palju rohkem aega aruannete analüüsimisele. Sel ajal pidime iga aruande artefakdina GitLabi üles laadima, seejärel selle alla laadima ja lahti pakkima. See pole eriti mugav ja võtab kaua aega. Ja kui keegi teine soovib aruannet ise vaadata, peab ta tegema samu toiminguid. Tahtsime saada kiiremini tagasisidet ja leidsime lahenduse – GitLabi lehed. See on sisseehitatud funktsioon, mis on saadaval kõigis GitLabi viimastes versioonides. Võimaldab juurutada oma serveris staatilisi saite ja pääseda neile juurde otselingi kaudu.
Kõik Allure'i aruannete ekraanipildid tehti GitLabi lehtedel. Skript aruande juurutamiseks GitLabi lehtedele - Windows PowerShellis (enne seda peate käivitama automaattestid):
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
Mille tulemusena
Seega, kui mõtlesite, kas vajate Cucumberi automaattesti raamistikus Threadi turvalist koodi, siis nüüd on vastus ilmne - Cucumber 4-ga on seda lihtne rakendada, suurendades seeläbi oluliselt samaaegselt käivitatavate lõimede arvu. Selle testide läbiviimise meetodi puhul on küsimus selenoidiga masina ja katsestendi jõudluses.
Praktika on näidanud, et lõimedel automaattestide käitamine võimaldab parima jõudlusega vähendada ressursikulu miinimumini. Nagu graafikutelt näha, ei too niitide kahekordistamine jõudluskatsetes kaasa sarnast kiirendust. Siiski saime rakenduse järgule lisada üle 2 automatiseeritud testi, mis isegi 200 korduskäivitamisega jooksevad umbes 5 minutiga. See võimaldab neilt kiiret tagasisidet saada ning vajadusel muudatusi teha ja protseduuri uuesti korrata.
Allikas: www.habr.com