Divisioonamme luo täysin automaattisia putkistoja sovellusten uusien versioiden käynnistämiseksi tuotantoympäristöön. Tämä tietysti vaatii automaattisia toimintatestejä. Leikkauksen alla on tarina siitä, kuinka aloitimme yksisäikeisen testauksen paikallisella koneella, pääsimme monisäikeiseen automaattiseen testiin, joka suoritettiin Selenoidilla rakennusvaiheessa Allure-raportin avulla GitLab-sivuilla ja lopulta saimme hienon automaatiotyökalun. että tulevat ihmiset voivat käyttää tiimejä.
Mistä aloitimme?
Autotestien toteuttamiseksi ja integroimiseksi prosessiin tarvitsimme automaatiokehyksen, jota voidaan joustavasti muuttaa tarpeidemme mukaan. Ihannetapauksessa halusin saada yhden standardin automaattitestausmoottorille, joka on mukautettu automaattisten testien upottamiseen prosessiin. Valitsimme toteutukseen seuraavat tekniikat:
- java,
- Maven,
- Seleeni,
- Kurkku+JUNIT 4,
- Viehätys,
- GitLab.
Miksi juuri tämä sarja? Java on yksi suosituimmista automaattisten testien kielistä, ja kaikki tiimin jäsenet puhuvat sitä. Seleeni on ilmeinen ratkaisu. Kurkun piti muun muassa lisätä luottamusta automaattisten testien tuloksiin manuaaliseen testaukseen osallistuvien osastojen puolelta.
Yksikierteiset testit
Jotta pyörää ei keksittäisi uudelleen, otimme kehyksiä GitHubin eri tietovarastoista puitteiden pohjaksi ja mukautimme ne itsellemme. Loimme pääkirjastoon arkiston, jossa on automaattinen testikehyksen ydin, ja arkiston, jossa on kultainen esimerkki automaattisten testien toteuttamisesta ytimessämme. Jokaisen tiimin piti ottaa Gold-imago ja kehittää siihen testejä mukauttamalla se projektiinsa. Otimme sen käyttöön GitLab-CI-pankkiin, johon määritimme:
- jokaisen projektin kaikkien kirjallisten automaattisten testien päivittäiset ajot;
- käynnistyy rakennusvaiheessa.
Aluksi testejä oli vähän, ja ne suoritettiin yhtenä virrana. Yksisäikeinen ajo Windows-apuohjelmalla GitLab sopi meille varsin hyvin: testit kuormittivat testipenkkiä erittäin kevyesti eivätkä käyttäneet juuri lainkaan resursseja.
Ajan myötä autotestien määrä lisääntyi ja mietittiin niiden ajamista rinnakkain, kun täysi ajo alkoi kestää noin kolme tuntia. Muitakin ongelmia ilmeni:
- emme voineet varmistaa, että testit olivat vakaita;
- testit, jotka suoritettiin useita kertoja peräkkäin paikallisella koneella, kaatui joskus CI:ssä.
Esimerkki automaattisten testien asettamisesta:
<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>
Esimerkki Allure-raportista
Runner-kuorma testien aikana (8 ydintä, 8 Gt RAM-muistia, 1 säie)
Yksisäikeisten testien edut:
- helppo asentaa ja käyttää;
- laukaisut CI:ssä eivät käytännössä eroa paikallisista laukaisuista;
- testit eivät vaikuta toisiinsa;
- juoksijaresurssien vähimmäisvaatimukset.
Yksisäikeisten testien haitat:
- valmistuminen kestää hyvin kauan;
- testien pitkä stabilointi;
- tehoton juoksijaresurssien käyttö, erittäin alhainen käyttöaste.
Testit JVM-haarukoilla
Koska emme huolehtineet säikeen suojatusta koodista peruskehystä toteutettaessa, ilmeisin tapa ajaa rinnakkain oli Mavenille. Plugin on helppo konfiguroida, mutta oikean rinnakkaistoiminnan varmistamiseksi automaattiset testit on suoritettava erillisissä selaimissa. Ei ole mitään tekemistä, jouduin käyttämään selenoidia.
Selenoid-palvelin lanseerattiin koneella, jossa on 32 ydintä ja 24 Gt RAM-muistia. Rajaksi asetettiin 48 selainta – 1,5 säiettä ydintä kohden ja noin 400 Mt RAM-muistia. Tämän seurauksena testiaika lyheni kolmesta tunnista 40 minuuttiin. Ajojen nopeuttaminen auttoi ratkaisemaan stabilointiongelman: nyt pystyimme ajamaan uusia automaattitestejä nopeasti 20–30 kertaa, kunnes olimme varmoja niiden toimivuudesta.
Ratkaisun ensimmäinen haittapuoli oli runner-resurssien korkea käyttöaste pienellä määrällä rinnakkaisia säikeitä: 4 ytimellä ja 8 Gt RAM-muistilla testit sujuivat vakaasti enintään 6 säikeessä. Toinen haittapuoli: laajennus luo juoksijaluokat kullekin skenaariolle riippumatta siitä, kuinka monta niistä käynnistetään.
Tärkeää! Älä välitä muuttujaa, jossa on tageja argLineesimerkiksi näin:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Jos ohitat tunnisteen tällä tavalla, laajennus luo juoksijat kaikille testeille, eli se yrittää suorittaa kaikki testit ohittaen ne välittömästi käynnistämisen jälkeen ja luomalla useita JVM-haarukoita.
On oikein heittää muuttuja, jossa on tunniste tunnisteet liitännäisasetuksissa, katso esimerkki alla. Muilla testaamillamme menetelmillä on ongelmia Allure-laajennuksen yhdistämisessä.
Esimerkki 6 lyhyen testin ajoajasta väärillä asetuksilla:
[INFO] Total time: 03:17 min
Esimerkki testiajoajasta, jos siirrät tunnisteen suoraan kohteeseen mvn... –Dcucumber.options:
[INFO] Total time: 44.467 s
Esimerkki automaattisten testien asettamisesta:
<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>
Esimerkki Allure-raportista (epävakain testi, 4 toistoa)
Runner-kuorma testien aikana (8 ydintä, 8 Gt RAM-muistia, 12 säiettä)
Plussat:
- helppo asennus - sinun tarvitsee vain lisätä laajennus;
- kyky suorittaa samanaikaisesti suuri määrä testejä;
- testin stabiloinnin kiihtyvyys vaiheen 1 ansiosta.
Miinukset:
- Tarvitaan useita käyttöjärjestelmiä/säiliöitä;
- suuri resurssien kulutus jokaisessa haarukassa;
- Laajennus on vanhentunut, eikä sitä enää tueta.
Kuinka voittaa epävakaus
Testipenkit eivät ole ihanteellisia, kuten itse autotestit. Ei ole yllättävää, että meillä on useita huonoja testejä. Tuli apuun, joka heti valmiina tukee epäonnistuneiden testien uudelleenkäynnistämistä. Sinun on päivitettävä laajennuksen versio vähintään versioon 2.21 ja kirjoitettava yksi rivi uudelleenkäynnistysten lukumäärällä pom-tiedostoon tai välitettävä se argumenttina Mavenille.
Esimerkki automaattisten testien asettamisesta:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
Tai käynnistyksen yhteydessä: mvn … -Dsurefire.rerunFailingTestsCount=2 …
Aseta vaihtoehtona Maven-asetukset PowerShell-skriptille (PS1):
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"Plussat:
- ei tarvitse tuhlata aikaa epävakaan testin analysointiin sen kaatuessa;
- testipenkin vakausongelmia voidaan lieventää.
Miinukset:
- kelluvat viat voidaan jättää huomiotta;
- käyttöaika kasvaa.
Rinnakkaistestit Cucumber 4 -kirjaston kanssa
Testien määrä kasvoi joka päivä. Mietimme taas juoksujen nopeuttamista. Lisäksi halusin integroida mahdollisimman monta testiä sovelluskokoonpanoon. Kriittinen tekijä oli, että juoksijoiden luominen kesti liian kauan, kun ajettiin rinnakkain Maven-laajennuksella.
Tuolloin Cucumber 4 oli jo julkaistu, joten päätimme kirjoittaa tämän version ytimen uudelleen. Julkaisutiedoissa meille luvattiin rinnakkainen lanseeraus säiettätasolla. Teoriassa tämän olisi pitänyt olla:
- nopeuttaa merkittävästi automaattisten testien suorittamista lisäämällä säikeiden määrää;
- eliminoi ajanhukkaa kunkin automaattisen testin juoksijoiden luomiseen.
Kehyksen optimointi monisäikeisille automaattitesteille ei osoittautunut niin vaikeaksi. Cucumber 4 suorittaa jokaisen yksittäisen testin omalla säikeellä alusta loppuun, joten jotkin yleiset staattiset asiat muutettiin yksinkertaisesti ThreadLocal-muuttujiksi.
Idea-refaktorointityökaluilla muunnettaessa tärkeintä on tarkistaa paikat, joissa muuttujaa verrattiin (esim. nullin tarkistus). Lisäksi sinun on lisättävä Allure-laajennus Junit Runner -luokan huomautukseen.
Esimerkki automaattisten testien asettamisesta:
<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>
Esimerkki Allure-raportista (epävakain testi, 5 toistoa)
Runner-kuorma testien aikana (8 ydintä, 8 Gt RAM-muistia, 24 säiettä)
Plussat:
- alhainen resurssien kulutus;
- natiivi tuki Cucumberilta - lisätyökaluja ei tarvita;
- kyky ajaa yli 6 säiettä prosessorin ydintä kohden.
Miinukset:
- sinun on varmistettava, että koodi tukee monisäikeistä suoritusta;
- pääsykynnys nousee.
Allure-raportit GitLab-sivuilla
Monisäikeisen suorituksen käyttöönoton jälkeen aloimme käyttää paljon enemmän aikaa raporttien analysointiin. Tuolloin meidän piti ladata jokainen raportti artefaktina GitLabiin, ladata se ja purkaa se. Se ei ole kovin kätevää ja kestää kauan. Ja jos joku muu haluaa tarkastella raporttia itse, hänen on tehtävä samat toiminnot. Halusimme saada palautetta nopeammin ja löysimme ratkaisun - GitLab-sivut. Tämä on sisäänrakennettu ominaisuus, joka on heti saatavilla kaikissa uusimmissa GitLabin versioissa. Voit ottaa käyttöön staattisia sivustoja palvelimellasi ja käyttää niitä suoran linkin kautta.
Kaikki kuvakaappaukset Allure-raporteista otettiin GitLab-sivuilla. Komentosarja raportin käyttöönottamiseksi GitLab-sivuille - Windows PowerShellissä (ennen tätä sinun on suoritettava automaattiset testit):
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
Sillä seurauksella, että
Joten jos mietit, tarvitsetko Thread-turvakoodia Cucumber-automaattitestikehyksessä, vastaus on nyt ilmeinen - Cucumber 4:n avulla se on helppo toteuttaa, mikä lisää merkittävästi samanaikaisesti käynnistettävien säikeiden määrää. Tällä testausmenetelmällä kysymys tulee nyt selenoidin ja testipenkin koneen suorituskyvystä.
Käytäntö on osoittanut, että automaattisten testien suorittaminen säikeissä mahdollistaa resurssien kulutuksen vähentämisen minimiin parhaalla suorituskyvyllä. Kuten kaavioista voidaan nähdä, säikeiden kaksinkertaistaminen ei johda vastaavaan kiihtyvyyteen suorituskykytesteissä. Pystyimme kuitenkin lisäämään yli 2 automaattista testiä sovelluksen koontiversioon, jotka jopa viidellä uusinnalla suoritetaan noin 200 minuutissa. Näin voit saada heiltä nopeaa palautetta ja tarvittaessa tehdä muutoksia ja toistaa toimenpide uudelleen.
Lähde: will.com