Naša divizija kreira potpuno automatske kanale za lansiranje novih verzija aplikacija u proizvodno okruženje. Naravno, ovo zahtijeva automatizirane funkcionalne testove. Ispod reza je priča o tome kako smo, počevši od jednonitnog testiranja na lokalnoj mašini, došli do tačke višenitnog automatskog testiranja koji je pokrenut na Selenoidu u build pipeline-u sa Allure izveštajem na GitLab stranicama i na kraju dobili kul alat za automatizaciju da budući ljudi mogu koristiti timove.
Gdje smo počeli?
Da bismo implementirali autotestove i integrirali ih u cevovod, trebao nam je okvir za automatizaciju koji bi se mogao fleksibilno mijenjati kako bi odgovarao našim potrebama. U idealnom slučaju, želeo sam da dobijem jedinstveni standard za mašinu za autotestiranje, prilagođen za ugrađivanje autotestova u cevovod. Za implementaciju smo odabrali sljedeće tehnologije:
- Java,
- Maven,
- selen,
- Krastavac+JUNIT 4,
- privlačnost,
- gitlab.
Zašto baš ovaj set? Java je jedan od najpopularnijih jezika za automatske testove i svi članovi tima ga govore. Selen je očigledno rešenje. Krastavac je, između ostalog, trebao povećati povjerenje u rezultate automatiziranih testova od strane odjela uključenih u ručno testiranje.
Testovi sa jednim navojem
Kako ne bismo ponovo izmislili točak, uzeli smo razvoje iz različitih spremišta na GitHub-u kao osnovu za okvir i prilagodili ih za sebe. Napravili smo spremište za glavnu biblioteku sa jezgrom autotest frameworka i spremište sa zlatnim primjerom implementacije autotestova na našem jezgru. Svaki tim je morao uzeti zlatnu sliku i razviti testove u njoj, prilagođavajući je svom projektu. Postavili smo ga u GitLab-CI banku, na kojoj smo konfigurisali:
- dnevno pokretanje svih pisanih autotestova za svaki projekat;
- lansira u toku izgradnje.
U početku je bilo nekoliko testova, i oni su se izvodili u jednom toku. Jednonitno trčanje na GitLab Windows runner-u nam je sasvim odgovaralo: testovi su vrlo lagano opterećivali testni sto i gotovo da nisu koristili resurse.
Vremenom je broj autotestova postajao sve brojniji, pa smo razmišljali o tome da ih izvodimo paralelno, kada je puna runda počela da traje oko tri sata. Pojavili su se i drugi problemi:
- nismo mogli da potvrdimo da su testovi stabilni;
- testovi koji su pokrenuti nekoliko puta zaredom na lokalnoj mašini ponekad su pali 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 Allure izvještaja
Opterećenje trkača tokom testova (8 jezgara, 8 GB RAM-a, 1 nit)
Prednosti jednonitnih testova:
- jednostavan za postavljanje i pokretanje;
- lansiranja u CI se praktički ne razlikuju od lokalnih lansiranja;
- testovi ne utiču jedni na druge;
- minimalni zahtjevi za resurse trkača.
Nedostaci jednonitnih testova:
- treba mnogo vremena da se završi;
- duga stabilizacija testova;
- neefikasno korištenje resursa trkača, izuzetno nisko iskorištenje.
Testovi na JVM viljuškama
Budući da prilikom implementacije osnovnog okvira nismo vodili računa o nito-sigurnom kodu, najočitiji način da se radi paralelno je za Maven. Dodatak se lako konfiguriše, ali za ispravan paralelni rad, autotestovi se moraju pokrenuti u odvojenim pretraživačima. Nemam šta da radim, morao sam da koristim Selenoid.
Selenoid server je pokrenut na mašini sa 32 jezgra i 24 GB RAM-a. Ograničenje je postavljeno na 48 pretraživača - 1,5 niti po jezgru i oko 400 MB RAM-a. Kao rezultat toga, vrijeme testiranja je smanjeno sa tri sata na 40 minuta. Ubrzavanje pokretanja pomoglo je u rješavanju problema stabilizacije: sada smo mogli brzo pokrenuti nove autotestove 20-30 puta dok ne budemo sigurni da rade pouzdano.
Prvi nedostatak rješenja bila je visoka iskorištenost runner resursa s malim brojem paralelnih niti: na 4 jezgre i 8 GB RAM-a, testovi su stabilno radili u ne više od 6 niti. Drugi nedostatak: dodatak generiše klase pokretača za svaki scenario, bez obzira koliko ih je pokrenuto.
Važno! Nemojte prosljeđivati varijablu s oznakama argLine, na primjer, ovako:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Ako prođete oznaku na ovaj način, dodatak će generirati trkač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 sa oznakom tags u postavkama dodatka, pogledajte primjer ispod. Druge metode koje smo testirali imaju problema sa povezivanjem dodatka Allure.
Primjer vremena rada za 6 kratkih testova s pogrešnim postavkama:
[INFO] Total time: 03:17 min
Primjer vremena izvođenja testa ako direktno prenesete oznaku na mvn... –Dcucumber.options:
[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štaja (najnestabilniji test, 4 ponavljanja)
Opterećenje trkača tokom testova (8 jezgara, 8 GB RAM-a, 12 niti)
Pros:
- jednostavno postavljanje - samo trebate dodati dodatak;
- mogućnost istovremenog izvođenja velikog broja testova;
- ubrzanje stabilizacije testa zahvaljujući koraku 1.
Cons:
- Potrebno je više OS/kontejnera;
- visoka potrošnja resursa za svaku viljušku;
- Dodatak je zastario i više nije podržan.
Kako prevazići nestabilnost
Testne ploče nisu idealne, baš kao ni sami autotestovi. Nije iznenađujuće što imamo niz loših testova. Pritekao je u pomoć, koji izvan kutije podržava ponovno pokretanje neuspjelih testova. Morate ažurirati verziju dodatka na najmanje 2.21 i napisati jedan red sa brojem ponovnih pokretanja u pom fajlu ili ga proslediti 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 za gubljenjem vremena na analizu nestabilnog testa kada se sruši;
- Problemi sa stabilnošću ispitnog stola mogu se ublažiti.
Cons:
- plutajući defekti mogu se propustiti;
- vreme rada se povećava.
Paralelni testovi sa bibliotekom Cucumber 4
Broj testova je rastao svakim danom. Ponovo smo razmišljali o ubrzanju trčanja. Osim toga, želio sam integrirati što više testova u cjevovod sklapanja aplikacije. Kritični faktor je bio to što je generacija pokretača trajala predugo kada je radila paralelno koristeći Maven dodatak.
U to vrijeme, Cucumber 4 je već bio objavljen, pa smo odlučili da prepišemo kernel za ovu verziju. U bilješkama o izdanju obećano nam je paralelno pokretanje na nivou niti. Teoretski je ovo 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 autotestove sa više niti nije bila tako teška. Cucumber 4 pokreće svaki pojedinačni test na posebnoj niti od početka do kraja, tako da su neke uobičajene statičke stvari jednostavno konvertovane u ThreadLocal varijable.
Glavna stvar pri konverziji pomoću Idea alata za refaktoriranje je provjeriti mjesta na kojima je varijabla upoređena (na primjer, provjera nule). Osim toga, morate 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štaja (najnestabilniji test, 5 ponavljanja)
Opterećenje trkača tokom testova (8 jezgara, 8 GB RAM-a, 24 niti)
Pros:
- niska potrošnja resursa;
- izvorna podrška od Cucumber-a - nisu potrebni dodatni alati;
- mogućnost pokretanja više od 6 niti po jezgri procesora.
Cons:
- morate osigurati da kod podržava višenitno izvršavanje;
- povećava se ulazni prag.
Allure izvještava na GitLab stranicama
Nakon uvođenja višenitnog izvršavanja, počeli smo da trošimo mnogo više vremena na analizu izvještaja. U to vrijeme, svaki izvještaj smo morali učitati kao artefakt u GitLab, zatim ga preuzeti i raspakirati. Nije baš zgodno i dugo traje. A ako neko drugi želi sam da vidi izvještaj, onda će morati da uradi iste operacije. Željeli smo brže dobiti povratne informacije i pronašli smo rješenje - GitLab stranice. Ovo je ugrađena funkcija koja je odmah dostupna u svim novijim verzijama GitLaba. Omogućava vam da postavite statične stranice na vaš server i pristupite im putem direktne veze.
Svi snimci ekrana Allure izvještaja su snimljeni na GitLab stranicama. Skripta za postavljanje izvještaja na GitLab stranice - u Windows PowerShell-u (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
Šta je na kraju
Dakle, ako ste razmišljali o tome da li vam je potreban Thread siguran kod u okviru autotestiranja Cucumber, sada je odgovor očigledan - s Cucumberom 4 ga je lako implementirati, čime se značajno povećava broj istovremeno pokrenutih niti. Sa ovom metodom izvođenja testova, sada se postavlja pitanje performansi mašine sa Selenoidom i testnom klupom.
Praksa je pokazala da pokretanje autotestova na nitima omogućava smanjenje potrošnje resursa na minimum uz najbolje performanse. Kao što se može vidjeti iz grafikona, udvostručavanje 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 uz 200 ponavljanja rade za oko 5 minute. To vam omogućava da dobijete brze povratne informacije od njih i, ako je potrebno, izvršite izmjene i ponovite postupak.
izvor: www.habr.com