Naša divízia vytvára plne automatické pipeline pre spúšťanie nových verzií aplikácií do produkčného prostredia. To si samozrejme vyžaduje automatizované funkčné testy. Pod strihom je príbeh o tom, ako sme počnúc testovaním s jedným vláknom na lokálnom počítači dosiahli bod viacvláknového autotestu spusteného na Selenoid v procese zostavovania pomocou správy Allure na stránkach GitLab a nakoniec sme získali skvelý automatizačný nástroj. že budúci ľudia môžu využívať tímy.
Kde sme začali?
Na implementáciu autotestov a ich integráciu do procesu sme potrebovali rámec automatizácie, ktorý by sa dal flexibilne meniť tak, aby vyhovoval našim potrebám. V ideálnom prípade som chcel získať jednotný štandard pre autotestovací motor prispôsobený na zabudovanie autotestov do potrubia. Na implementáciu sme zvolili nasledujúce technológie:
- java,
- Maven,
- selén,
- Uhorka + JUNIT 4,
- lákadlo,
- GitLab.
Prečo práve tento set? Java je jedným z najpopulárnejších jazykov pre automatizované testy a hovoria ním všetci členovia tímu. Selén je jasným riešením. Uhorka mala okrem iného zvýšiť dôveru vo výsledky automatizovaných testov zo strany oddelení zapojených do manuálneho testovania.
Skúšky s jedným závitom
Aby sme znovu nevynašli koleso, vzali sme vývoj z rôznych úložísk na GitHub ako základ pre rámec a prispôsobili sme si ich pre seba. Vytvorili sme úložisko pre hlavnú knižnicu s jadrom rámca autotestov a úložisko so zlatým príkladom implementácie autotestov do nášho jadra. Každý tím musel vziať imidž zlata a vyvinúť v ňom testy a prispôsobiť ho svojmu projektu. V banke sme nasadili GitLab-CI, na ktorom sme nakonfigurovali:
- denné spustenie všetkých písomných autotestov pre každý projekt;
- spúšťa v procese budovania.
Spočiatku bolo testov málo a prebiehali v jednom prúde. Jednovláknový beh na GitLab Windows runner nám celkom vyhovoval: testy zaťažili testovaciu lavicu veľmi ľahko a nevyužívali takmer žiadne zdroje.
Postupom času bol počet autotestov čoraz početnejší a uvažovali sme o ich spustení paralelne, keď plný chod začal trvať približne tri hodiny. Objavili sa aj ďalšie problémy:
- nemohli sme overiť, či boli testy stabilné;
- testy, ktoré boli spustené niekoľkokrát za sebou na lokálnom počítači, niekedy v CI spadli.
Príklad nastavenia autotestov:
<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>
Príklad správy Allure
Zaťaženie bežca počas testov (8 jadier, 8 GB RAM, 1 vlákno)
Výhody jednovláknových testov:
- jednoduché nastavenie a spustenie;
- štarty v CI sa prakticky nelíšia od lokálnych štartov;
- testy sa navzájom neovplyvňujú;
- minimálne požiadavky na zdroje bežcov.
Nevýhody jednovláknových testov:
- dokončenie trvá veľmi dlho;
- dlhá stabilizácia testov;
- neefektívne využívanie zdrojov bežca, extrémne nízke využitie.
Testy na vidliciach JVM
Keďže sme sa pri implementácii základného rámca nestarali o kód bezpečný pre vlákna, najzrejmejším spôsobom paralelného spustenia bolo pre Mavena. Plugin sa ľahko konfiguruje, ale pre správnu paralelnú prevádzku je potrebné spustiť autotesty v samostatných prehliadačoch. Nedá sa nič robiť, musel som použiť Selenoid.
Selenoid server bol spustený na stroji s 32 jadrami a 24 GB RAM. Limit bol stanovený na 48 prehliadačov – 1,5 vlákna na jadro a približne 400 MB RAM. V dôsledku toho sa čas testu skrátil z troch hodín na 40 minút. Zrýchlenie behu pomohlo vyriešiť problém so stabilizáciou: teraz sme mohli rýchlo spustiť nové autotesty 20 až 30-krát, kým sme si neboli istí, že bežia spoľahlivo.
Prvou nevýhodou riešenia bolo vysoké využitie zdrojov runnera s malým počtom paralelných vlákien: na 4 jadrách a 8 GB RAM testy fungovali stabilne s nie viac ako 6 vláknami. Druhá nevýhoda: plugin generuje runner triedy pre každý scenár, bez ohľadu na to, koľko ich je spustených.
Dôležité! Neodovzdávajte premennú so značkami do argLine, napríklad takto:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Ak tag prejdete týmto spôsobom, plugin vygeneruje bežcov pre všetky testy, to znamená, že sa pokúsi spustiť všetky testy, pričom ich hneď po spustení preskočí a vytvorí mnoho JVM forkov.
Správne je hodiť premennú s tagom do tagy v nastaveniach pluginu, pozri príklad nižšie. Iné metódy, ktoré sme testovali, majú problémy s pripojením doplnku Allure.
Príklad doby chodu pre 6 krátkych testov s nesprávnym nastavením:
[INFO] Total time: 03:17 min
Príklad doby testovania, ak značku priamo prenesiete do mvn... –Dcucumber.možnosti:
[INFO] Total time: 44.467 s
Príklad nastavenia autotestov:
<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>
Príklad správy Allure (najnestabilnejší test, 4 opakovania)
Zaťaženie bežca počas testov (8 jadier, 8 GB RAM, 12 vlákien)
Pros:
- jednoduché nastavenie – stačí pridať plugin;
- schopnosť súčasne vykonávať veľké množstvo testov;
- zrýchlenie stabilizácie testu vďaka kroku 1.
Nevýhody:
- Vyžaduje sa viacero OS/kontajnerov;
- vysoká spotreba zdrojov pre každú vidlicu;
- Doplnok je zastaraný a už nie je podporovaný.
Ako prekonať nestabilitu
Testovacie stolice nie sú ideálne, rovnako ako samotné autotesty. Nie je prekvapujúce, že máme množstvo nestálych testov. Prišiel na záchranu, ktorý po vybalení podporuje reštartovanie neúspešných testov. Musíte aktualizovať verziu pluginu aspoň na 2.21 a do súboru pom napísať jeden riadok s počtom reštartov alebo ho odovzdať ako argument Mavenovi.
Príklad nastavenia autotestov:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
Alebo pri štarte: mvn … -Dsurefire.rerunFailingTestsCount=2 …
Ako možnosť nastavte možnosti Maven pre skript PowerShell (PS1):
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"Pros:
- nie je potrebné strácať čas analýzou nestabilného testu, keď sa zrúti;
- Problémy so stabilitou testovacej stolice možno zmierniť.
Nevýhody:
- plávajúce defekty možno vynechať;
- čas chodu sa zvyšuje.
Paralelné testy s knižnicou Cucumber 4
Počet testov každým dňom rástol. Opäť sme mysleli na zrýchlenie behov. Okrem toho som chcel integrovať čo najviac testov do potrubia montáže aplikácie. Kritickým faktorom bolo, že generovanie bežcov trvalo príliš dlho pri paralelnom behu pomocou pluginu Maven.
V tom čase už vyšla Cucumber 4 a tak sme sa rozhodli prepísať jadro pre túto verziu. V poznámkach k vydaniu nám bolo sľúbené paralelné spustenie na úrovni vlákien. Teoreticky by to malo byť:
- výrazne urýchliť priebeh autotestov zvýšením počtu vlákien;
- eliminovať stratu času pri generovaní bežcov pre každý autotest.
Ukázalo sa, že optimalizácia rámca pre viacvláknové autotesty nie je taká náročná. Cucumber 4 spúšťa každý jednotlivý test na vyhradenom vlákne od začiatku do konca, takže niektoré bežné statické veci boli jednoducho prevedené na premenné ThreadLocal.
Hlavnou vecou pri konverzii pomocou nástrojov na refaktorovanie Idea je kontrola miest, kde bola premenná porovnávaná (napríklad kontrola nuly). Okrem toho je potrebné pridať doplnok Allure do anotácie triedy Junit Runner.
Príklad nastavenia autotestov:
<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>
Príklad správy Allure (najnestabilnejší test, 5 opakovaní)
Zaťaženie bežca počas testov (8 jadier, 8 GB RAM, 24 vlákien)
Pros:
- nízka spotreba zdrojov;
- natívna podpora od Cucumber – nie sú potrebné žiadne ďalšie nástroje;
- schopnosť spustiť viac ako 6 vlákien na jadro procesora.
Nevýhody:
- musíte sa uistiť, že kód podporuje viacvláknové vykonávanie;
- vstupný prah sa zvyšuje.
Allure hlási na stránkach GitLab
Po zavedení viacvláknového spúšťania sme začali tráviť oveľa viac času analýzou zostáv. V tom čase sme museli každú správu nahrať ako artefakt do GitLabu, potom ju stiahnuť a rozbaliť. Nie je to veľmi pohodlné a trvá to dlho. A ak si chce niekto iný zobraziť prehľad, bude musieť vykonať rovnaké operácie. Chceli sme dostávať spätnú väzbu rýchlejšie a našli sme riešenie – stránky GitLab. Toto je vstavaná funkcia, ktorá je k dispozícii hneď po vybalení vo všetkých najnovších verziách GitLab. Umožňuje nasadiť statické stránky na server a pristupovať k nim prostredníctvom priameho odkazu.
Všetky screenshoty správ Allure boli urobené na stránkach GitLab. Skript na nasadenie zostavy na stránky GitLab – v prostredí Windows PowerShell (predtým musíte spustiť autotesty):
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 tým výsledkom, že
Takže, ak ste premýšľali o tom, či potrebujete Thread safe kód v rámci Cucumber autotest, teraz je odpoveď zrejmá – s Cucumber 4 je jednoduché ho implementovať, čím sa výrazne zvýši počet vlákien spúšťaných súčasne. Pri tejto metóde testovania sa teraz vynára otázka výkonu stroja so Selenoidom a testovacej stolice.
Prax ukázala, že spustenie autotestov na vláknach vám umožňuje znížiť spotrebu zdrojov na minimum s najlepším výkonom. Ako vidno z grafov, zdvojenie závitov nevedie k podobnému zrýchleniu pri výkonových testoch. Do zostavy aplikácie sme však mohli pridať viac ako 2 automatizovaných testov, ktoré aj pri 200 reprízach bežia za približne 5 minút. To vám umožní získať od nich rýchlu spätnú väzbu a v prípade potreby vykonať zmeny a zopakovať postup znova.
Zdroj: hab.com