Naše divize vytváří plně automatické pipeline pro spouštění nových verzí aplikací do produkčního prostředí. To samozřejmě vyžaduje automatizované funkční testy. Pod střihem je příběh o tom, jak jsme počínaje jednovláknovým testováním na místním počítači dosáhli bodu vícevláknového autotestu běžícího na Selenoid v procesu sestavování pomocí zprávy Allure na stránkách GitLab a nakonec jsme získali skvělý automatizační nástroj. že budoucí lidé mohou používat týmy.
kde jsme začali?
K implementaci autotestů a jejich integraci do potrubí jsme potřebovali automatizační rámec, který by bylo možné flexibilně měnit tak, aby vyhovoval našim potřebám. V ideálním případě jsem chtěl získat jednotný standard pro autotestovací engine, přizpůsobený pro zabudování autotestů do potrubí. Pro implementaci jsme zvolili následující technologie:
- Jáva,
- Mavene,
- Selen,
- Okurka+JUNIT 4,
- lákat,
- GitLab.
Proč právě tato sada? Java je jedním z nejoblíbenějších jazyků pro automatizované testy a mluví jím všichni členové týmu. Selen je jasné řešení. Okurka měla mimo jiné zvýšit důvěru ve výsledky automatizovaných testů ze strany oddělení zapojených do ručního testování.
Jednovláknové testy
Abychom znovu nevynalézali kolo, vzali jsme vývoj z různých úložišť na GitHubu jako základ pro framework a přizpůsobili jsme je pro sebe. Vytvořili jsme úložiště pro hlavní knihovnu s jádrem rámce autotestů a úložiště se zlatým příkladem implementace autotestů na našem jádru. Každý tým musel vzít obrázek Gold a vyvinout v něm testy a přizpůsobit ho svému projektu. Nasadili jsme jej do banky GitLab-CI, na které jsme nakonfigurovali:
- denní běhy všech písemných autotestů pro každý projekt;
- spouští v procesu budování.
Zpočátku bylo testů málo a byly prováděny v jednom proudu. Jednovláknový běh na Windows runneru GitLab nám docela vyhovoval: testy zatěžovaly testovací lavici velmi lehce a nevyužívaly téměř žádné prostředky.
Postupem času přibývalo autotestů a přemýšleli jsme o jejich paralelním běhu, kdy plný běh začal trvat zhruba tři hodiny. Objevily se i další problémy:
- nemohli jsme ověřit, že testy byly stabilní;
- testy, které byly spuštěny několikrát za sebou na místním počítači, někdy v CI selhaly.
Příklad nastavení autotestů:
<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>
Příklad zprávy Allure
Zatížení běžce během testů (8 jader, 8 GB RAM, 1 vlákno)
Výhody jednovláknových testů:
- snadné nastavení a spuštění;
- starty v CI se prakticky neliší od lokálních startů;
- testy se navzájem neovlivňují;
- minimální požadavky na zdroje běžců.
Nevýhody jednovláknových testů:
- dokončení trvá velmi dlouho;
- dlouhá stabilizace testů;
- neefektivní využití zdrojů běžců, extrémně nízké využití.
Testy na vidlicích JVM
Vzhledem k tomu, že jsme se při implementaci základního rámce nestarali o kód bezpečný pro vlákna, nejviditelnějším způsobem paralelního běhu bylo pro Mavena. Plugin se snadno konfiguruje, ale pro správný paralelní provoz musí být autotesty spuštěny v samostatných prohlížečích. Nedá se nic dělat, musel jsem použít Selenoid.
Selenoid server byl spuštěn na stroji s 32 jádry a 24 GB RAM. Limit byl stanoven na 48 prohlížečů – 1,5 vlákna na jádro a cca 400 MB RAM. V důsledku toho se doba testu zkrátila ze tří hodin na 40 minut. Zrychlení běhů pomohlo vyřešit problém se stabilizací: nyní jsme mohli rychle spustit nové autotesty 20–30krát, dokud jsme si nebyli jisti, že probíhají spolehlivě.
Prvním nedostatkem řešení bylo vysoké využití zdrojů runnerů s malým počtem paralelních vláken: na 4 jádrech a 8 GB RAM probíhaly testy stabilně maximálně v 6 vláknech. Druhá nevýhoda: plugin generuje běžecké třídy pro každý scénář, bez ohledu na to, kolik jich je spuštěno.
Důležité! Nepředávejte proměnnou se značkami do argLine, například takto:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Pokud tag předáte tímto způsobem, plugin vygeneruje běžce pro všechny testy, to znamená, že se pokusí spustit všechny testy, přeskočí je ihned po spuštění a vytvoří mnoho JVM forků.
Správné je hodit proměnnou s tagem do tagy v nastavení pluginu, viz příklad níže. Jiné metody, které jsme testovali, mají problémy s připojením pluginu Allure.
Příklad doby běhu pro 6 krátkých testů s nesprávným nastavením:
[INFO] Total time: 03:17 min
Příklad doby testovacího běhu, pokud značku přímo přenesete do mvn... –Dcucumber.options:
[INFO] Total time: 44.467 s
Příklad nastavení autotestů:
<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>
Příklad zprávy Allure (nejnestabilnější test, 4 opakování)
Zatížení běžce během testů (8 jader, 8 GB RAM, 12 vláken)
výhody:
- snadné nastavení – stačí přidat plugin;
- schopnost současně provádět velké množství testů;
- zrychlení stabilizace testu díky kroku 1.
nevýhody:
- Je vyžadováno více OS/kontejnerů;
- vysoká spotřeba zdrojů pro každou vidlici;
- Plugin je zastaralý a již není podporován.
Jak překonat nestabilitu
Testovací stolice nejsou ideální, stejně jako samotné autotesty. Není divu, že máme řadu zbytečných testů. Přišel na záchranu, který po vybalení podporuje restartování neúspěšných testů. Musíte aktualizovat verzi pluginu alespoň na 2.21 a do souboru pom napsat jeden řádek s počtem restartů nebo jej předat jako argument Mavenu.
Příklad nastavení autotestů:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
Nebo při startu: mvn … -Dsurefire.rerunFailingTestsCount=2 …
Jako možnost nastavte možnosti Maven pro skript PowerShell (PS1):
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"výhody:
- není třeba ztrácet čas analýzou nestabilního testu, když se zhroutí;
- problémy se stabilitou zkušební stolice lze zmírnit.
nevýhody:
- plovoucí defekty lze přehlédnout;
- doba běhu se zvyšuje.
Paralelní testy s knihovnou Cucumber 4
Počet testů každým dnem rostl. Opět jsme přemýšleli o zrychlení běhů. Kromě toho jsem chtěl do potrubí montáže aplikace integrovat co nejvíce testů. Kritickým faktorem bylo, že generování běžců trvalo příliš dlouho při paralelním běhu pomocí pluginu Maven.
V té době již vyšla Cucumber 4, a tak jsme se rozhodli přepsat jádro pro tuto verzi. V poznámkách k vydání nám bylo slíbeno paralelní spuštění na úrovni vláken. Teoreticky by to mělo být:
- výrazně zrychlit běh autotestů zvýšením počtu vláken;
- eliminovat ztrátu času při generování běžců pro každý autotest.
Optimalizace frameworku pro vícevláknové autotesty se ukázala jako ne tak obtížná. Cucumber 4 spouští každý jednotlivý test na vyhrazeném vláknu od začátku do konce, takže některé běžné statické věci byly jednoduše převedeny na proměnné ThreadLocal.
Hlavní věcí při převodu pomocí nástrojů Idea refactoring je kontrola míst, kde byla proměnná porovnána (například kontrola null). Kromě toho je třeba přidat plugin Allure do anotace třídy Junit Runner.
Příklad nastavení autotestů:
<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>
Příklad zprávy Allure (nejnestabilnější test, 5 opakování)
Zatížení běžce během testů (8 jader, 8 GB RAM, 24 vláken)
výhody:
- nízká spotřeba zdrojů;
- nativní podpora od Cucumber – nejsou potřeba žádné další nástroje;
- schopnost provozovat více než 6 vláken na jádro procesoru.
nevýhody:
- musíte zajistit, aby kód podporoval vícevláknové provádění;
- vstupní práh se zvyšuje.
Allure hlásí na stránkách GitLab
Po zavedení vícevláknového spouštění jsme začali trávit mnohem více času analýzou sestav. V té době jsme museli každý report nahrát jako artefakt do GitLabu, poté jej stáhnout a rozbalit. Není to příliš pohodlné a trvá to dlouho. A pokud si někdo jiný chce zobrazit sestavu pro sebe, bude muset provést stejné operace. Chtěli jsme rychleji dostávat zpětnou vazbu a našli jsme řešení – stránky GitLab. Toto je vestavěná funkce, která je k dispozici ihned po vybalení ve všech nejnovějších verzích GitLab. Umožňuje nasadit statické stránky na váš server a přistupovat k nim prostřednictvím přímého odkazu.
Všechny screenshoty zpráv Allure byly pořízeny na stránkách GitLabu. Skript pro nasazení sestavy na stránky GitLab – v prostředí Windows PowerShell (před tím je třeba spustit 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ýsledkem, že
Pokud jste tedy přemýšleli o tom, zda potřebujete Thread safe kód v rámci Cucumber autotest, nyní je odpověď zřejmá – s Cucumber 4 je snadné jej implementovat, čímž se výrazně zvýší počet souběžně spuštěných vláken. Při tomto způsobu provádění testů nyní vyvstává otázka ohledně výkonu stroje se Selenoidem a zkušební stolice.
Praxe ukázala, že spuštění autotestů na vláknech umožňuje snížit spotřebu prostředků na minimum s nejlepším výkonem. Jak je vidět z grafů, zdvojení vláken nevede k podobnému zrychlení ve výkonnostních testech. Do sestavení aplikace jsme však mohli přidat více než 2 automatizovaných testů, které i s 200 reprízami běží zhruba za 5 minut. To vám umožní získat od nich rychlou zpětnou vazbu a v případě potřeby provést změny a opakovat postup znovu.
Zdroj: www.habr.com