Naš odjel stvara potpuno automatizirane kanale za lansiranje novih verzija aplikacija u proizvodno okruženje. Naravno, to zahtijeva automatizirane funkcionalne testove. Ispod presjeka je priča o tome kako smo, počevši s testiranjem jedne niti na lokalnom stroju, došli do točke višenitnog automatskog testiranja koje se izvodi na Selenoidu u cjevovodu za izgradnju s izvješćem Allure na stranicama GitLaba i na kraju dobili cool alat za automatizaciju da budući ljudi mogu koristiti timove.
Gdje smo počeli?
Za implementaciju autotestova i njihovu integraciju u cjevovod, trebao nam je okvir za automatizaciju koji se može fleksibilno mijenjati kako bi odgovarao našim potrebama. U idealnom slučaju, želio sam dobiti jedan standard za motor za automatsko testiranje, prilagođen za ugradnju autotestova u cjevovod. Za implementaciju smo odabrali sljedeće tehnologije:
- Java,
- Maven,
- Selen,
- Krastavac+JUNIT 4,
- Vabiti,
- GitLab.
Zašto baš ovaj set? Java je jedan od najpopularnijih jezika za automatizirane testove i svi članovi tima je govore. Selen je očito rješenje. Cucumber je, između ostalog, trebao povećati povjerenje u rezultate automatiziranih testova od strane odjela uključenih u ručno testiranje.
Jednonitni testovi
Kako ne bismo ponovno izmišljali kotač, uzeli smo razvoje iz različitih repozitorija na GitHubu kao osnovu za framework i prilagodili ih sebi. Napravili smo repozitorij za glavnu biblioteku s jezgrom autotest frameworka i repozitorij sa Gold primjerom implementacije autotestova na našoj jezgri. Svaki je tim morao uzeti Gold sliku i u njoj razviti testove, prilagođavajući je svom projektu. Postavili smo ga u GitLab-CI banku, na kojoj smo konfigurirali:
- dnevno pokretanje svih pisanih autotestova za svaki projekt;
- pokreće u fazi izgradnje.
Isprva je bilo malo testova i oni su se provodili u jednom toku. Izvođenje u jednoj niti na Windows pokretaču GitLab prilično nam je odgovaralo: testovi su vrlo malo opterećivali testni stol i nisu koristili gotovo nikakve resurse.
S vremenom je broj autotestova postajao sve brojniji i razmišljali smo o tome da ih izvodimo paralelno, kada je pun rad počeo trajati oko tri sata. Pojavili su se i drugi problemi:
- nismo mogli potvrditi da su testovi stabilni;
- testovi koji su pokretani nekoliko puta za redom na lokalnom stroju ponekad su se srušili u CI.
Primjer postavljanja autotestova:
<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>
Primjer izvješća Allure
Opterećenje pokretača tijekom testova (8 jezgri, 8 GB RAM-a, 1 nit)
Prednosti jednonitnih testova:
- jednostavno postavljanje i pokretanje;
- lansiranja u CI praktički se ne razlikuju od lokalnih lansiranja;
- testovi ne utječu jedni na druge;
- minimalni zahtjevi za resurse pokretača.
Nedostaci jednonitnih testova:
- treba jako dugo da se završi;
- duga stabilizacija testova;
- neučinkovito korištenje trkačkih resursa, izuzetno niska iskorištenost.
Testovi na JVM rašljama
Budući da prilikom implementacije osnovnog okvira nismo vodili računa o kodu koji je siguran za niti, najočitiji način za paralelno pokretanje bio je za Mavena. Dodatak je lako konfigurirati, ali za ispravan paralelni rad, autotestovi moraju biti pokrenuti u zasebnim preglednicima. Nema se što učiniti, morao sam koristiti Selenoid.
Poslužitelj Selenoid pokrenut je na stroju s 32 jezgre i 24 GB RAM-a. Ograničenje je postavljeno na 48 preglednika - 1,5 niti po jezgri i oko 400 MB RAM-a. Kao rezultat toga, vrijeme testiranja smanjeno je s tri sata na 40 minuta. Ubrzavanje izvođenja pomoglo je riješiti problem stabilizacije: sada smo mogli brzo pokrenuti nove automatske testove 20-30 puta dok nismo bili sigurni da rade pouzdano.
Prvi nedostatak rješenja bila je velika iskorištenost resursa pokretača s malim brojem paralelnih niti: na 4 jezgre i 8 GB RAM-a, testovi su radili stabilno u ne više od 6 niti. Drugi nedostatak: dodatak generira runner klase za svaki scenarij, bez obzira koliko ih je pokrenuto.
Važno! Ne prosljeđujte varijablu s oznakama na argLine, na primjer, ovako:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Ako proslijedite oznaku na ovaj način, dodatak će generirati pokretače za sve testove, odnosno pokušat će pokrenuti sve testove, preskačući ih odmah nakon pokretanja i stvarajući mnogo JVM forkova.
Ispravno je ubaciti varijablu s oznakom oznake u postavkama dodatka, pogledajte primjer u nastavku. Druge metode koje smo testirali imaju problema s povezivanjem dodatka Allure.
Primjer vremena izvođenja za 6 kratkih testova s netočnim postavkama:
[INFO] Total time: 03:17 min
Primjer vremena testiranja ako izravno prenesete oznaku na mvn... –Dkrastavac.opcije:
[INFO] Total time: 44.467 s
Primjer postavljanja autotestova:
<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>
Primjer Allure izvješća (najnestabilniji test, 4 ponavljanja)
Opterećenje pokretača tijekom testova (8 jezgri, 8 GB RAM-a, 12 niti)
Pros:
- jednostavno postavljanje - trebate samo dodati dodatak;
- sposobnost istovremenog obavljanja velikog broja testova;
- ubrzanje stabilizacije testa zahvaljujući koraku 1.
Cons:
- Potrebno je više OS-a/spremnika;
- visoka potrošnja resursa za svaku vilicu;
- Dodatak je zastario i više nije podržan.
Kako prevladati nestabilnost
Testne klupe nisu idealne, baš kao ni sami autotestovi. Nije iznenađujuće da imamo veliki broj slabih testova. Priskočio u pomoć, koji izvan kutije podržava ponovno pokretanje neuspjelih testova. Morate ažurirati verziju dodatka na najmanje 2.21 i napisati jedan redak s brojem ponovnih pokretanja u pom datoteci ili ga proslijediti kao argument Mavenu.
Primjer postavljanja autotestova:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
Ili pri pokretanju: mvn … -Dsurefire.rerunFailingTestsCount=2 …
Kao opciju postavite Maven opcije za PowerShell skriptu (PS1):
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"Pros:
- nema potrebe gubiti vrijeme na analizu nestabilnog testa kada se sruši;
- problemi stabilnosti ispitnog stola mogu se ublažiti.
Cons:
- mogu se propustiti plutajući nedostaci;
- vrijeme rada se povećava.
Paralelni testovi s bibliotekom Cucumber 4
Broj testiranja rastao je svakim danom. Ponovno smo razmišljali o ubrzanju trčanja. Osim toga, želio sam integrirati što više testova u cjevovod sklopa aplikacije. Kritični čimbenik bio je taj što je generiranje runnera trajalo predugo kada se radilo paralelno pomoću dodatka Maven.
U to je vrijeme Cucumber 4 već bio objavljen, pa smo odlučili ponovno napisati kernel za ovu verziju. U bilješkama o izdanju obećano nam je paralelno pokretanje na razini niti. Teoretski ovo je trebalo biti:
- značajno ubrzati izvođenje autotestova povećanjem broja niti;
- eliminirati gubitak vremena na generiranje pokretača za svaki autotest.
Pokazalo se da optimizacija okvira za višenitne autotestove nije tako teška. Cucumber 4 izvodi svaki pojedinačni test na namjenskoj niti od početka do kraja, tako da su neke uobičajene statičke stvari jednostavno pretvorene u varijable ThreadLocal.
Glavna stvar pri pretvorbi pomoću alata za refaktoriranje Idea je provjeriti mjesta na kojima je varijabla uspoređena (na primjer, provjera null). Osim toga, trebate dodati dodatak Allure u napomenu klase Junit Runner.
Primjer postavljanja autotestova:
<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>
Primjer Allure izvješća (najnestabilniji test, 5 ponavljanja)
Opterećenje pokretača tijekom testova (8 jezgri, 8 GB RAM-a, 24 niti)
Pros:
- niska potrošnja resursa;
- izvorna podrška od Cucumbera - nisu potrebni dodatni alati;
- mogućnost pokretanja više od 6 niti po jezgri procesora.
Cons:
- trebate osigurati da kôd podržava višenitno izvršavanje;
- povećava se ulazni prag.
Allure izvješća na stranicama GitLaba
Nakon uvođenja višenitnog izvršavanja, počeli smo provoditi mnogo više vremena analizirajući izvješća. U to smo vrijeme morali prenijeti svako izvješće kao artefakt u GitLab, zatim ga preuzeti i raspakirati. Nije baš zgodno i dugo traje. A ako netko drugi želi sam pregledati izvješće, morat će učiniti iste operacije. Htjeli smo brže dobiti povratnu informaciju i pronašli smo rješenje - GitLab stranice. Ovo je ugrađena značajka koja je odmah dostupna u svim novijim verzijama GitLaba. Omogućuje vam postavljanje statičkih stranica na vašem poslužitelju i pristup im putem izravne veze.
Sve snimke zaslona izvješća Allure snimljene su na stranicama GitLaba. Skripta za implementaciju izvješća na GitLab stranice - u Windows PowerShell (prije toga morate pokrenuti autotestove):
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 rezultatom da
Dakle, ako ste razmišljali treba li vam Thread safe kod u Cucumber autotest frameworku, sada je odgovor očigledan - s Cucumberom 4 lako ga je implementirati, čime se značajno povećava broj istovremeno pokrenutih niti. S ovom metodom izvođenja testova, postavlja se pitanje performansi stroja sa Selenoidom i ispitnog stola.
Praksa je pokazala da izvođenje autotestova na nitima omogućuje smanjenje potrošnje resursa na minimum uz najbolje performanse. Kao što se može vidjeti iz grafikona, udvostručenje niti ne dovodi do sličnog ubrzanja u testovima performansi. Međutim, uspjeli smo dodati više od 2 automatiziranih testova u izradu aplikacije, koji čak i s 200 ponavljanja rade za oko 5 minute. To vam omogućuje da od njih dobijete brzu povratnu informaciju te, ako je potrebno, napravite izmjene i ponovite postupak.
Izvor: www.habr.com