Gure dibisioak kanalizazio guztiz automatikoak sortzen ditu aplikazioen bertsio berriak produkzio-ingurunean abiarazteko. Jakina, honek proba funtzional automatizatuak behar ditu. Ebakiaren azpian, tokiko makina batean hari bakarreko probak egiten hasita, Selenoid-en exekutatzen ari den hari anitzeko autotest puntura iritsi ginen GitLab-eko orrietan Allure txosten batekin exekutatzen ari garen puntua eta azkenean automatizazio tresna bikaina lortu genuen. etorkizuneko pertsonek taldeak erabil ditzaketela.
Nondik hasi ginen?
Autotestak ezartzeko eta kanalizazioan integratzeko, gure beharretara egokitzeko malgutasunez alda zitekeen automatizazio-esparru bat behar genuen. Egokiena, autotest motorrako estandar bakarra lortu nahi nuen, autotestak kanalizazioan txertatzeko egokitua. Ezartzeko teknologia hauek aukeratu ditugu:
- Java,
- Maven,
- selenioa,
- Pepinoa+JUNIT 4,
- Erakargarritasuna,
- GitLab.
Zergatik multzo zehatz hau? Java proba automatikoetarako hizkuntza ezagunenetako bat da eta taldekide guztiek hitz egiten dute. Selenioa irtenbide argia da. Pepinoak, besteak beste, eskuzko probetan parte hartzen duten sailen test automatizatuen emaitzetan konfiantza areagotu behar zuen.
Hari bakarreko probak
Gurpila ez berrasmatzeko, GitHub-eko hainbat biltegitako garapenak hartu genituen markoaren oinarri gisa eta geure buruari egokitu genituen. Liburutegi nagusirako biltegi bat sortu dugu autotest-esparruaren muinarekin eta biltegi bat gure nukleoan autotestak ezartzeko Gold adibide batekin. Talde bakoitzak Urrezko irudia hartu eta bertan probak garatu behar izan zituen, bere proiektura egokituz. GitLab-CI bankuan zabaldu genuen, eta bertan konfiguratu genuen:
- proiektu bakoitzerako idatzitako autoproba guztien eguneroko exekuzioak;
- abiarazteak eraikuntza-bidean.
Hasieran proba gutxi zeuden, eta korronte batean egiten ziren. GitLab Windows runner-en hari bakarreko exekuzioa nahiko ondo egokitu zitzaigun: probek oso arin kargatu zuten proba-bankua eta ez zuten ia baliabiderik erabili.
Denborak aurrera egin ahala, autotest kopurua gero eta ugariagoa izan zen, eta paraleloan egitea pentsatu genuen, korrika oso bat hiru ordu inguru behar izaten hasi zenean. Beste arazo batzuk ere agertu ziren:
- ezin izan dugu egiaztatu probak egonkorrak zirenik;
- tokiko makinan hainbat aldiz jarraian exekutatzen ziren probak batzuetan huts egiten zuten CIn.
Autotestak konfiguratzeko adibidea:
<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 txostenaren adibidea
Korrikalariaren karga probetan (8 nukleo, 8 GB RAM, hari 1)
Hari bakarreko proben abantailak:
- konfiguratzeko eta exekutatzeko erraza;
- CIn abian jartzeak ia ez dira tokiko abiarazteetatik desberdinak;
- probek ez diote elkarri eragiten;
- korrikalarien baliabideetarako gutxieneko baldintzak.
Hari bakarreko proben desabantailak:
- oso denbora luzea behar da osatzeko;
- proben egonkortze luzea;
- korrikalarien baliabideen erabilera ez eraginkorra, erabilera oso baxua.
JVM forketan probak
Oinarrizko markoa ezartzerakoan hari seguruko kodea zaindu ez genuenez, paraleloan exekutatzeko modurik nabarmenena izan zen. Mavenentzat. Plugin-a konfiguratzeko erraza da, baina funtzionamendu paralelo zuzena izateko, autotestak arakatzaile ezberdinetan exekutatu behar dira. Ez dago zer eginik, Selenoid erabili behar nuen.
Selenoid zerbitzaria 32 nukleo eta 24 GB RAM dituen makina batean abiarazi zen. Muga 48 arakatzailetan ezarri zen - 1,5 hari nukleo bakoitzeko eta 400 MB inguru RAM. Ondorioz, probaren denbora hiru ordutik 40 minutura murriztu zen. Korrikak bizkortzeak egonkortze arazoa konpontzen lagundu zuen: orain 20-30 aldiz azkar egin genitzake autotest berriak fidagarritasunez funtzionatzen zutela ziur egon arte.
Irtenbidearen lehen eragozpena korridoreen baliabideen erabilera handia izan zen hari paralelo kopuru txiki batekin: 4 nukleoetan eta 8 GB RAM-n, probak egonkor egin ziren 6 hari baino gehiagotan. Bigarren desabantaila: pluginak agertoki bakoitzerako korrikalari-klaseak sortzen ditu, horietako zenbat abian jarrita ere.
Garrantzitsua da! Ez pasa etiketak dituen aldagai bat argLine, adibidez, honela:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
β¦
Mvn βDTAGS="@smoke"
Etiketa horrela pasatzen baduzu, pluginak proba guztietarako korrikalariak sortuko ditu, hau da, proba guztiak exekutatzen saiatuko da, abiarazi eta berehala saltatu eta JVM fork asko sortuz.
Zuzena da etiketa batekin aldagai bat botatzea Euskal Herria pluginaren ezarpenetan, ikusi beheko adibidea. Probatu ditugun beste metodo batzuek arazoak dituzte Allure plugina konektatzeko.
Ezarpen okerrak dituzten 6 proba laburren exekuzio denboraren adibidea:
[INFO] Total time: 03:17 min
Etiketa zuzenean transferitzen baduzu probaren denboraren adibidea mvn... βDcucumber.aukerak:
[INFO] Total time: 44.467 s
Autotestak konfiguratzeko adibidea:
<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 txosten baten adibidea (probarik ezegonkorrena, 4 errepikapen)
Korrikalari karga probetan (8 nukleo, 8 GB RAM, 12 hari)
Pros:
- konfigurazio erraza - plugin bat gehitu besterik ez duzu behar;
- aldi berean proba ugari egiteko gaitasuna;
- probaren egonkortzearen azelerazioa 1. urratsari esker.
Cons:
- Hainbat OS/edukiontzi behar dira;
- baliabideen kontsumo handia sardexka bakoitzeko;
- Plugin-a zaharkituta dago eta jada ez da onartzen.
Ezegonkortasuna nola gainditu
Proba-bankuak ez dira aproposak, autotestak berak bezala. Ez da harritzekoa hainbat proba flacky izatea. Erreskatera etorri zen, kutxatik kanpo huts egindako probak berrabiaraztea onartzen duena. Pluginaren bertsioa gutxienez 2.21era eguneratu behar duzu eta lerro bat idatzi pom fitxategian berrabiarazteko kopuruarekin edo pasatu argumentu gisa Maven-i.
Autotestak konfiguratzeko adibidea:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
β¦.
<rerunFailingTestsCount>2</rerunFailingTestsCount>
β¦.
</configuration>
</plugin>
Edo abiaraztean: mvn β¦ -Dsurefire.rerunFailingTestsCount=2 β¦
Aukera gisa, ezarri Maven aukerak PowerShell script-erako (PS1):
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"Pros:
- ez da denbora galdu behar proba ezegonkor bat huts egiten duenean aztertzen;
- proba-bankuaren egonkortasun arazoak arindu daitezke.
Cons:
- flotatzaileen akatsak galdu daitezke;
- exekuzio-denbora handitzen da.
Proba paraleloak Cucumber 4 liburutegiarekin
Proba kopurua egunero hazi zen. Korrikak bizkortzea pentsatu genuen berriro. Horrez gain, aplikazioen muntaketa kanalean ahalik eta proba gehien integratu nahi nituen. Faktore kritikoa izan zen korrikalarien sorrerak luzeegia hartzen zuela paraleloan exekutatzen zenean Maven plugina erabiliz.
Garai hartan, Cucumber 4 jada kaleratua zen, beraz, bertsio honetarako nukleoa berridaztea erabaki genuen. Argitalpen-oharretan abiarazte paraleloa agindu ziguten hari mailan. Teorian hau izan beharko litzateke:
- autotesten exekuzioa nabarmen azkartu hari kopurua handituz;
- desagerrarazi autotest bakoitzeko korrikalariak sortzeko denbora galera.
Hari anitzeko autotestetarako esparrua optimizatzea ez zen hain zaila izan. Cucumber 4-k proba bakoitza hari dedikatu batean exekutatzen du hasieratik amaierara, beraz, ohiko gauza estatiko batzuk ThreadLocal aldagai bihurtu ziren.
Idea birfactoring tresnak erabiliz bihurtzerakoan gauza nagusia aldagaia alderatu den lekuak egiaztatzea da (adibidez, nulua egiaztatzea). Horrez gain, Allure plugina gehitu behar duzu Junit Runner klaseko oharpenean.
Autotestak konfiguratzeko adibidea:
<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 txosten baten adibidea (probarik ezegonkorrena, 5 errepikapen)
Korrikalariaren karga probetan (8 nukleo, 8 GB RAM, 24 hari)
Pros:
- baliabideen kontsumo txikia;
- Pepinoaren jatorrizko laguntza - ez da tresna gehigarririk behar;
- prozesadorearen nukleo bakoitzeko 6 hari baino gehiago exekutatzeko gaitasuna.
Cons:
- kodea hari anitzeko exekuzioa onartzen duela ziurtatu behar duzu;
- sarrera-atalasea handitzen da.
Allure txostenak GitLab orrietan
Hari anitzeko exekuzioa sartu ondoren, askoz denbora gehiago ematen hasi ginen txostenak aztertzen. Garai hartan, txosten bakoitza artefaktu gisa igo behar genuen GitLab-era, gero deskargatu eta deskonprimitu. Ez da oso erosoa eta denbora luzea hartzen du. Eta beste norbaitek txostena bere kabuz ikusi nahi badu, eragiketa berdinak egin beharko ditu. Iritzia azkarrago jaso nahi genuen, eta irtenbide bat aurkitu genuen: GitLab orriak. GitLab-en azken bertsio guztietan eskuragarri dagoen funtzio integratua da. Zure zerbitzarian gune estatikoak zabaltzeko eta esteka zuzen baten bidez atzitzeko aukera ematen dizu.
Allure txostenen pantaila-argazki guztiak GitLab orrietan hartu dira. Txostena GitLab orrietan zabaltzeko scripta - Windows PowerShell-en (hau aurretik autotestak exekutatu behar dituzu):
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
Emaitza duten
Beraz, Cucumber autotest esparruan Thread safe kodea behar duzun ala ez pentsatzen ari bazenitu, orain erantzuna begi-bistakoa da - Cucumber 4-rekin erraza da inplementatzea, eta horrela aldi berean abiarazitako hari kopurua nabarmen handitzen da. Probak egiteko metodo honekin, Selenoid-ekin eta proba-bankuarekin makinaren errendimenduari buruzko galdera bihurtzen da.
Praktikak erakutsi du harietan autotestak exekutatzen direla baliabideen kontsumoa errendimendu onenarekin gutxienera murrizten duzula. Grafikoetan ikusten denez, hariak bikoizteak ez du antzeko azeleraziorik ekartzen errendimendu probetan. Hala ere, 2 proba automatizatu baino gehiago gehitu ahal izan ditugu aplikazioaren eraikuntzan, 200 errepikapenekin ere 5 minutu inguru exekutatzen direnak. Horri esker, haien iritzia azkar jaso dezakezu, eta, behar izanez gero, aldaketak egin eta prozedura berriro errepikatu.
Iturria: www.habr.com