Mūsų padalinys kuria visiškai automatinius vamzdynus, skirtus naujoms programų versijoms paleisti į gamybos aplinką. Žinoma, tam reikalingi automatiniai funkciniai testai. Žemiau yra pasakojimas apie tai, kaip, pradedant vienos gijos testavimu vietiniame kompiuteryje, pasiekėme kelių gijų automatinio testavimo tašką, vykdomą Selenoid kūrimo konvejeryje su Allure ataskaita GitLab puslapiuose ir galiausiai gavome puikų automatizavimo įrankį. kad būsimi žmonės galėtų naudotis komandomis.
Nuo ko pradėjome?
Norint įdiegti automatinius testus ir integruoti juos į gamybos procesą, mums reikėjo automatizavimo sistemos, kurią būtų galima lanksčiai keisti, kad atitiktų mūsų poreikius. Idealiu atveju norėjau gauti vieną automatinio testavimo variklio standartą, pritaikytą automatiniams testams įterpti į vamzdyną. Diegimui pasirinkome šias technologijas:
- „Java“,
- Maven,
- selenas,
- Agurkas + JUNIT 4,
- Viliojimas,
- „GitLab“.
Kodėl būtent šis rinkinys? „Java“ yra viena populiariausių automatizuotų testų kalbų, ja kalba visi komandos nariai. Selenas yra akivaizdus sprendimas. Agurkai, be kita ko, turėjo padidinti skyrių, atliekančių rankinį testavimą, pasitikėjimą automatizuotų testų rezultatais.
Vieno sriegio bandymai
Siekdami neišradinėti dviračio iš naujo, kaip sistemos pagrindą paėmėme patobulinimus iš įvairių GitHub saugyklų ir pritaikėme juos sau. Sukūrėme pagrindinės bibliotekos saugyklą su automatinio testavimo sistemos šerdimi ir saugyklą su auksiniu automatinių testų diegimo mūsų branduolyje pavyzdžiu. Kiekviena komanda turėjo paimti Auksinį įvaizdį ir parengti jame testus, pritaikydama jį savo projektui. Banke įdiegėme „GitLab-CI“, kuriame sukonfigūravome:
- kasdienis visų rašytinių automatinių kiekvieno projekto testų vykdymas;
- paleidžiama tiesimo vamzdyne.
Iš pradžių bandymų buvo nedaug ir jie buvo atliekami vienu srautu. Vienos gijos veikimas „Windows“ paleidiklyje „GitLab“ mums visai neblogai tiko: bandymai labai lengvai apkrovė bandymų stendą ir beveik nenaudojo resursų.
Laikui bėgant automatinių testų vis daugėjo, o apie juos galvojome vykdyti lygiagrečiai, kai pilnas važiavimas pradėjo trukti apie tris valandas. Taip pat atsirado kitų problemų:
- negalėjome patikrinti, ar testai buvo stabilūs;
- bandymai, kurie buvo atlikti kelis kartus iš eilės vietinėje mašinoje, kartais sugesdavo CI.
Automatinių testų nustatymo pavyzdys:
<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 ataskaitos pavyzdys
Bėgio apkrova bandymų metu (8 branduoliai, 8 GB RAM, 1 gija)
Vienos sriegio testų privalumai:
- lengva nustatyti ir paleisti;
- paleidimai KI praktiškai nesiskiria nuo vietinių paleidimo;
- testai neturi įtakos vienas kitam;
- minimalūs bėgiko išteklių reikalavimai.
Vieno sriegio testų trūkumai:
- užbaigti reikia labai ilgai;
- ilgas testų stabilizavimas;
- neefektyvus bėgiko resursų panaudojimas, itin mažas panaudojimas.
JVM šakių bandymai
Kadangi diegdami bazinę sistemą nepasirūpinome saugiu gijų kodu, akivaizdžiausias būdas veikti lygiagrečiai buvo už Maveną. Papildinį lengva konfigūruoti, tačiau norint tinkamai veikti lygiagrečiai, automatiniai testai turi būti vykdomi atskirose naršyklėse. Nėra ką veikti, teko naudoti selenoidą.
Selenoid serveris buvo paleistas mašinoje su 32 branduoliais ir 24 GB RAM. Buvo nustatytas 48 naršyklių limitas – 1,5 gijos branduolyje ir apie 400 MB RAM. Dėl to bandymo laikas sutrumpėjo nuo trijų valandų iki 40 minučių. Važiavimo paspartinimas padėjo išspręsti stabilizavimo problemą: dabar galėjome greitai atlikti naujus automatinius testus 20–30 kartų, kol įsitikinome, kad jie veikia patikimai.
Pirmasis sprendimo trūkumas buvo didelis bėgiko išteklių panaudojimas su nedideliu lygiagrečių gijų skaičiumi: naudojant 4 branduolius ir 8 GB RAM, testai stabiliai vyko ne daugiau kaip 6 gijose. Antras trūkumas: įskiepis generuoja bėgikų klases kiekvienam scenarijui, nesvarbu, kiek jų yra paleista.
Svarbu! Neperduokite kintamojo su žymomis į argLine, pavyzdžiui, taip:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Jei perduosite žymą tokiu būdu, įskiepis sugeneruos bėgikus visiems testams, tai yra, jis bandys vykdyti visus testus, praleisdamas juos iš karto po paleidimo ir sukurdamas daug JVM šakučių.
Teisinga įmesti kintamąjį su žyma tags įskiepio nustatymuose, žr. toliau pateiktą pavyzdį. Dėl kitų mūsų išbandytų metodų kyla problemų prijungiant „Allure“ papildinį.
6 trumpų testų vykdymo trukmės pavyzdys su neteisingais nustatymais:
[INFO] Total time: 03:17 min
Bandymo vykdymo laiko pavyzdys, jei žymą tiesiogiai perkeliate į mvn... –Dcucumber.options:
[INFO] Total time: 44.467 s
Automatinių testų nustatymo pavyzdys:
<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>
Allure ataskaitos pavyzdys (nestabiliausias testas, 4 pakartojimai)
Bėgio apkrova bandymų metu (8 branduoliai, 8 GB RAM, 12 gijų)
Argumentai "už":
- lengva sąranka – tereikia pridėti papildinį;
- galimybė vienu metu atlikti daugybę testų;
- bandymo stabilizavimo pagreitis dėl 1 žingsnio.
Trūkumai:
- Reikalingos kelios OS/konteineriai;
- didelis išteklių suvartojimas kiekvienai šakutei;
- Papildinys pasenęs ir nebepalaikomas.
Kaip įveikti nestabilumą
Bandymų stendai nėra idealūs, kaip ir patys automatiniai testai. Nenuostabu, kad turime daugybę klaidingų testų. Atėjo į pagalbą, kuri iš karto palaiko nesėkmingų bandymų paleidimą iš naujo. Turite atnaujinti papildinio versiją bent iki 2.21 ir pom faile įrašyti vieną eilutę su pakartotinių paleidimų skaičiumi arba perduoti jį kaip argumentą Maven.
Automatinių testų nustatymo pavyzdys:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
Arba paleidžiant: mvn … -Dsurefire.rerunFailingTestsCount=2 …
Kaip parinktį nustatykite „PowerShell“ scenarijaus (PS1) „Maven“ parinktis:
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"Argumentai "už":
- nereikia gaišti laiko analizuojant nestabilų testą, kai jis sugenda;
- galima sušvelninti bandymų stendo stabilumo problemas.
Trūkumai:
- plūduriuojantys defektai gali būti nepastebėti;
- veikimo laikas didėja.
Lygiagretūs testai su Cucumber 4 biblioteka
Kiekvieną dieną testų skaičius augo. Vėl galvojome, kaip paspartinti bėgimus. Be to, norėjau integruoti kuo daugiau testų į programos surinkimo vamzdyną. Svarbus veiksnys buvo tai, kad bėgikų generavimas užtruko per ilgai, kai jie bėgo lygiagrečiai naudojant Maven papildinį.
Tuo metu „Cucumber 4“ jau buvo išleistas, todėl nusprendėme perrašyti šios versijos branduolį. Išleidimo pastabose mums buvo pažadėta lygiagretus paleidimas gijos lygiu. Teoriškai tai turėjo būti:
- žymiai pagreitinti automatinių testų vykdymą padidinant gijų skaičių;
- pašalinti laiko praradimą generuojant bėgikus kiekvienam automatiniam testui.
Optimizuoti kelių gijų automatinių testų sistemą pasirodė ne taip sunku. „Cucumber 4“ atlieka kiekvieną atskirą testą tam skirtoje gijoje nuo pradžios iki pabaigos, todėl kai kurie įprasti statiniai dalykai buvo tiesiog konvertuoti į „ThreadLocal“ kintamuosius.
Pagrindinis dalykas konvertuojant naudojant Idea refactoring įrankius yra patikrinti vietas, kuriose buvo lyginamas kintamasis (pavyzdžiui, patikrinti, ar nėra nulio). Be to, prie Junit Runner klasės anotacijos turite pridėti Allure papildinį.
Automatinių testų nustatymo pavyzdys:
<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>
Allure ataskaitos pavyzdys (nestabiliausias testas, 5 pakartojimai)
Bėgio apkrova bandymų metu (8 branduoliai, 8 GB RAM, 24 gijos)
Argumentai "už":
- mažas išteklių suvartojimas;
- vietinė pagalba iš Agurkų - nereikia papildomų įrankių;
- galimybė paleisti daugiau nei 6 gijas viename procesoriaus branduolyje.
Trūkumai:
- turite įsitikinti, kad kodas palaiko kelių gijų vykdymą;
- didėja įėjimo riba.
Allure ataskaitos GitLab puslapiuose
Įvedę kelių gijų vykdymą, pradėjome daug daugiau laiko skirti ataskaitų analizei. Tuo metu kiekvieną ataskaitą turėjome įkelti kaip artefaktą į „GitLab“, tada atsisiųsti ir išpakuoti. Tai nėra labai patogu ir užtrunka ilgai. Ir jei kas nors kitas nori pats peržiūrėti ataskaitą, jam reikės atlikti tas pačias operacijas. Norėjome greičiau gauti grįžtamąjį ryšį ir radome sprendimą – GitLab puslapiai. Tai yra integruota funkcija, kurią galima įsigyti visose naujausiose „GitLab“ versijose. Leidžia įdiegti statines svetaines serveryje ir pasiekti jas tiesiogine nuoroda.
Visos „Allure“ ataskaitų ekrano kopijos buvo padarytos „GitLab“ puslapiuose. Scenarijus, skirtas ataskaitai diegti „GitLab“ puslapiuose - „Windows PowerShell“ (prieš tai turite paleisti automatinius testus):
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
Todėl
Taigi, jei galvojote, ar jums reikia „Thread“ saugaus kodo „Cucumber“ automatinio testavimo sistemoje, dabar atsakymas yra akivaizdus - naudojant „Cucumber 4“ jį lengva įdiegti ir taip žymiai padidinti vienu metu paleidžiamų gijų skaičių. Taikant šį testų vykdymo metodą, dabar kyla klausimas apie mašinos su selenoidu ir bandymų stendu veikimą.
Praktika parodė, kad automatinių gijų testų vykdymas leidžia sumažinti išteklių suvartojimą iki minimumo ir pasiekti geriausią našumą. Kaip matyti iš grafikų, gijų padvigubinimas nesukelia panašaus pagreičio atliekant veikimo testus. Tačiau mes galėjome pridėti daugiau nei 2 automatizuotų testų prie programos versijos, kuri net su 200 paleidimais paleidžiama maždaug per 5 minutes. Tai leidžia greitai gauti grįžtamąjį ryšį iš jų ir, jei reikia, atlikti pakeitimus ir pakartoti procedūrą dar kartą.
Šaltinis: www.habr.com