Divíziónk teljesen automatikus folyamatokat hoz létre az alkalmazások új verzióinak a termelési környezetbe való elindításához. Természetesen ehhez automatizált funkcionális tesztek szükségesek. A vágás alatt egy történet arról szól, hogy a helyi gépen végzett egyszálas teszteléssel kiindulva eljutottunk a többszálas automatikus tesztig, amely a Selenoidon futott a build folyamatban egy Allure-jelentéssel a GitLab oldalain, és végül kaptunk egy klassz automatizálási eszközt. hogy a jövő emberei csapatokat használhatnak.
Hol kezdtük?
Az automatikus tesztek megvalósításához és a folyamatba való integrálásához szükségünk volt egy automatizálási keretrendszerre, amely rugalmasan módosítható az igényeinknek megfelelően. Ideális esetben egyetlen szabványt szerettem volna beszerezni az automatikus tesztelő motorhoz, amely alkalmas arra, hogy az automatikus teszteket beágyazza a folyamatba. A megvalósításhoz a következő technológiákat választottuk:
- Jáva,
- Maven,
- Szelén,
- Uborka+JUNIT 4,
- csábítás,
- GitLab.
Miért pont ez a készlet? A Java az egyik legnépszerűbb nyelv az automatizált tesztekhez, és a csapat minden tagja beszéli ezt. A szelén a kézenfekvő megoldás. Az uborkának többek között a kézi teszteléssel foglalkozó részlegek automatizált tesztek eredményeibe vetett bizalmát kellett volna növelnie.
Egymenetes tesztek
Annak érdekében, hogy ne találjuk fel újra a kereket, a GitHub különböző tárhelyeiből származó fejlesztéseket vettük át a keretrendszer alapjául, és adaptáltuk azokat magunknak. Létrehoztunk egy tárat a fő könyvtár számára az automatikus tesztelési keretrendszer magjával, és egy tárat, amely az automatikus tesztek magunkon való megvalósításának arany példáját tartalmazza. Minden csapatnak el kellett készítenie az Arany képet, és teszteket kellett kidolgoznia benne, adaptálva a projektjéhez. Telepítettük a GitLab-CI bankba, amelyen a következőket konfiguráltuk:
- az összes írásos automatikus teszt napi futtatása minden projekthez;
- építési folyamatban indul.
Eleinte kevés teszt volt, és azokat egy folyamban hajtották végre. Az egyszálú futtatás a Windows futtató GitLab-on elég jól bevált nekünk: a tesztek nagyon enyhén terhelték a tesztpadot, és szinte semmilyen erőforrást nem használtak.
Az idő múlásával az automatikus tesztek száma egyre szaporodott, és akkor gondolkoztunk a párhuzamos futtatáson, amikor a teljes lefutás körülbelül három órát vett igénybe. Más problémák is megjelentek:
- nem tudtuk ellenőrizni, hogy a tesztek stabilak;
- a helyi gépen egymás után többször lefutott tesztek néha összeomlottak a CI-ben.
Példa az automatikus tesztek beállítására:
<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 jelentés példa
Futóterhelés a tesztek során (8 mag, 8 GB RAM, 1 szál)
Az egyszálas tesztek előnyei:
- könnyű beállítani és futtatni;
- a CI-ben történő indítás gyakorlatilag nem különbözik a helyi indításoktól;
- a tesztek nem hatnak egymásra;
- a futó erőforrásokra vonatkozó minimális követelmények.
Az egyszálas tesztek hátrányai:
- nagyon sokáig tart a befejezés;
- a tesztek hosszú stabilizálása;
- a futó erőforrások nem hatékony felhasználása, rendkívül alacsony kihasználtság.
Tesztek JVM villákon
Mivel az alapkeretrendszer megvalósítása során nem ügyeltünk a szálbiztos kódra, a párhuzamos futtatás legkézenfekvőbb módja az volt. Maven számára. A bővítmény könnyen konfigurálható, de a megfelelő párhuzamos működéshez az automatikus teszteket külön böngészőben kell futtatni. Nincs mit tenni, Selenoidot kellett használnom.
A Selenoid szervert egy 32 magos és 24 GB RAM-mal rendelkező gépen indították el. A korlátot 48 böngészőben határozták meg – magonként 1,5 szálat és körülbelül 400 MB RAM-ot. Ennek eredményeként a vizsgálati idő három óráról 40 percre csökkent. A futások felgyorsítása segített megoldani a stabilizációs problémát: most már 20-30-szor is gyorsan le tudtunk új automatikus teszteket futtatni, amíg meg nem bizonyosodtunk a megbízható működésről.
A megoldás első hátránya a futóerőforrások magas kihasználása volt kevés párhuzamos szál mellett: 4 magon és 8 GB RAM-on a tesztek nem több, mint 6 szálon futottak stabilan. A második hátrány: a beépülő modul futtató osztályokat generál minden forgatókönyvhöz, függetlenül attól, hogy hányat indítanak el.
Fontos! Ne adjon át címkékkel rendelkező változót argLinepéldául így:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Ha így adjuk át a címkét, a beépülő modul futtatókat generál minden teszthez, azaz megpróbál minden tesztet lefuttatni, azonnal kihagyva azokat az indítás után, és sok JVM forkot hoz létre.
Helyes egy címkével ellátott változót bedobni címkék a plugin beállításainál, lásd lent a példát. Az általunk tesztelt más módszereknél problémák merülnek fel az Allure beépülő modul csatlakoztatásakor.
Példa futási időre 6 rövid teszthez hibás beállításokkal:
[INFO] Total time: 03:17 min
Példa tesztfutási időre, ha a címkét közvetlenül a következőre viszi át mvn... –Dcucumber.options:
[INFO] Total time: 44.467 s
Példa az automatikus tesztek beállítására:
<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élda egy Allure-jelentésre (a leginstabilabb teszt, 4 ismétlés)
Futóterhelés a tesztek során (8 mag, 8 GB RAM, 12 szál)
Előnyök:
- egyszerű beállítás - csak egy bővítményt kell hozzáadnia;
- nagyszámú teszt egyidejű elvégzésének képessége;
- a tesztstabilizáció felgyorsítása az 1. lépésnek köszönhetően.
Hátrányok:
- Több operációs rendszer/tároló szükséges;
- nagy erőforrás-fogyasztás minden egyes villa esetében;
- A bővítmény elavult, és már nem támogatott.
Hogyan lehet legyőzni az instabilitást
A tesztpadok nem ideálisak, akárcsak maguk az automatikus tesztek. Nem meglepő, hogy számos hibás tesztünk van. Jött a mentő, amely a dobozból támogatja a sikertelen tesztek újraindítását. Frissítenie kell a bővítmény verzióját legalább 2.21-re, és egy sort kell írnia az újraindítások számával a pom fájlba, vagy át kell adnia argumentumként a Mavennek.
Példa az automatikus tesztek beállítására:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
Vagy indításkor: mvn … -Dsurefire.rerunFailingTestsCount=2 …
Lehetőségként állítsa be a Maven-beállításokat a PowerShell-szkripthez (PS1):
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"Előnyök:
- nem kell időt vesztegetni egy instabil teszt elemzésére, amikor összeomlik;
- mérsékelhetők a próbapadi stabilitási problémák.
Hátrányok:
- lebegő hibák kimaradhatnak;
- futási ideje nő.
Párhuzamos tesztek a Cucumber 4 könyvtárral
A vizsgálatok száma napról napra nőtt. Ismét arra gondoltunk, hogy felgyorsítjuk a futásokat. Ezenkívül a lehető legtöbb tesztet szerettem volna integrálni az alkalmazás-összeállítás folyamatába. A kritikus tényező az volt, hogy a futók generálása túl sokáig tartott, amikor párhuzamosan futottak a Maven bővítménnyel.
Ekkor már megjelent az Cucumber 4, ezért úgy döntöttünk, hogy ehhez a verzióhoz átírjuk a kernelt. A kiadási megjegyzésekben ígéretet kaptunk a párhuzamos elindításra a szálak szintjén. Elméletileg ennek így kellett volna lennie:
- jelentősen felgyorsítja az automatikus tesztek futtatását a szálak számának növelésével;
- kiküszöböli az időveszteséget a futók generálásával minden egyes automatikus teszthez.
A keretrendszer optimalizálása a többszálú automatikus tesztekhez nem volt olyan nehéz. A Cucumber 4 minden egyes tesztet egy dedikált szálon futtat az elejétől a végéig, így néhány gyakori statikus dolog egyszerűen ThreadLocal változókká lett konvertálva.
Az Idea refaktoráló eszközökkel való konvertálás során a legfontosabb az, hogy ellenőrizzük azokat a helyeket, ahol a változót összehasonlították (például nulla ellenőrzése). Ezenkívül hozzá kell adnia az Allure bővítményt a Junit Runner osztály annotációjához.
Példa az automatikus tesztek beállítására:
<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élda egy Allure-jelentésre (a leginstabilabb teszt, 5 ismétlés)
Futóterhelés a tesztek során (8 mag, 8 GB RAM, 24 szál)
Előnyök:
- alacsony erőforrás-fogyasztás;
- natív támogatás az uborkától - nincs szükség további eszközökre;
- processzormagonként több mint 6 szál futtatásának képessége.
Hátrányok:
- meg kell győződnie arról, hogy a kód támogatja a többszálú végrehajtást;
- nő a belépési küszöb.
Allure jelentések a GitLab oldalain
A többszálas végrehajtás bevezetése után sokkal több időt kezdtünk tölteni a jelentések elemzésével. Abban az időben minden jelentést műtermékként kellett feltöltenünk a GitLab-ra, majd letöltenünk és ki kellett csomagolnunk. Nem túl kényelmes, és sokáig tart. Ha pedig valaki más saját maga szeretné megtekinteni a jelentést, akkor neki is el kell végeznie ugyanezt a műveletet. Szerettünk volna gyorsabb visszajelzést kapni, és megtaláltuk a megoldást – a GitLab oldalakat. Ez egy beépített funkció, amely a GitLab összes legújabb verziójában azonnal elérhető. Lehetővé teszi statikus webhelyek telepítését a kiszolgálón, és közvetlen hivatkozáson keresztül elérheti őket.
Az Allure-jelentések összes képernyőképe a GitLab oldalain készült. Szkript a jelentés GitLab oldalakra való telepítéséhez - a Windows PowerShellben (előtte automatikus teszteket kell futtatnia):
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
Aminek eredményeképpen a
Tehát, ha azon gondolkodott, hogy szüksége van-e Thread biztonságos kódra a Cucumber autoteszt keretrendszerében, most a válasz kézenfekvő - a Cucumber 4-gyel könnyen megvalósítható, ezáltal jelentősen megnövelve az egyidejűleg elindított szálak számát. Ezzel a tesztfutási módszerrel a kérdés most a szelenoiddal ellátott gép és a tesztpad teljesítményével kapcsolatos.
A gyakorlat azt mutatja, hogy az automatikus tesztek futtatása a szálakon lehetővé teszi az erőforrás-fogyasztás minimálisra csökkentését a legjobb teljesítmény mellett. Amint az a grafikonokból látható, a szálak megkettőzése nem vezet hasonló gyorsuláshoz a teljesítménytesztekben. Azonban több mint 2 automatizált tesztet tudtunk hozzáadni az alkalmazás buildhez, amely 200 újrafutással is körülbelül 5 perc alatt fut le. Ez lehetővé teszi, hogy gyors visszajelzést kapjon tőlük, és ha szükséges, módosítsa, és ismételje meg az eljárást.
Forrás: will.com