Наша дивизија креира потпуно аутоматске цевоводе за лансирање нових верзија апликација у производно окружење. Наравно, ово захтева аутоматизоване функционалне тестове. Испод реза је прича о томе како смо, почевши од једнонитног тестирања на локалној машини, дошли до тачке вишенитног аутоматског тестирања који је покренут на Селеноиду у цевоводу за прављење са Аллуре извештајем на ГитЛаб страницама и на крају добили кул алат за аутоматизацију да будући људи могу користити тимове.
Где смо почели?
Да бисмо имплементирали аутотестове и интегрисали их у цевовод, био нам је потребан оквир за аутоматизацију који би се могао флексибилно мењати како би одговарао нашим потребама. У идеалном случају, желео сам да добијем један стандард за машину за аутоматско тестирање, прилагођен за уграђивање аутотестова у цевовод. За имплементацију смо изабрали следеће технологије:
- Јава,
- Мавен,
- селен,
- краставац+ЈУНИТ 4,
- привлачност,
- ГитЛаб.
Зашто баш овај сет? Јава је један од најпопуларнијих језика за аутоматизоване тестове и сви чланови тима га говоре. Селен је очигледно решење. Краставац је, између осталог, требало да повећа поверење у резултате аутоматизованих тестова одељења укључених у ручно тестирање.
Тестови са једним навојем
Да не бисмо поново измислили точак, узели смо развоје из различитих спремишта на ГитХуб-у као основу за оквир и прилагодили их за себе. Направили смо спремиште за главну библиотеку са језгром аутотест оквира и спремиште са златним примером имплементације аутотестова на нашем језгру. Сваки тим је морао да узме златну слику и развије тестове у њој, прилагођавајући је свом пројекту. Поставили смо га у ГитЛаб-ЦИ банку, на којој смо конфигурисали:
- дневно покретање свих писаних аутотестова за сваки пројекат;
- лансира у цевоводу за изградњу.
У почетку је било мало тестова, и они су спроведени у једном току. Једнонитно покретање на Виндовс тркачу ГитЛаб нам је сасвим одговарало: тестови су веома лагано оптерећивали тестни сто и скоро да нису користили ресурсе.
Временом је број аутотестова постајао све бројнији и размишљали смо о томе да их изводимо паралелно, када је пун рад почео да траје око три сата. Појавили су се и други проблеми:
- нисмо могли да проверимо да ли су тестови стабилни;
- тестови који су вођени неколико пута заредом на локалној машини понекад су падали у ЦИ.
Пример подешавања аутоматских тестова:
<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>
Пример извештаја Аллуре
Оптерећење тркача током тестова (8 језгара, 8 ГБ РАМ-а, 1 нит)
Предности једнонитних тестова:
- лако се поставља и покреће;
- лансирања у ЦИ се практично не разликују од локалних лансирања;
- тестови не утичу једни на друге;
- минимални захтеви за ресурсе тркача.
Недостаци једнонитних тестова:
- потребно је много времена да се заврши;
- дуга стабилизација тестова;
- неефикасно коришћење ресурса тркача, изузетно ниско коришћење.
Тестови на ЈВМ виљушкама
Пошто нисмо водили рачуна о нито-безбедном коду приликом имплементације основног оквира, најочигледнији начин да се ради паралелно је за Мавен. Додатак се лако конфигурише, али за исправан паралелни рад, аутотестови се морају покренути у одвојеним претраживачима. Нема шта да се ради, морао сам да користим Селеноид.
Селеноид сервер је покренут на машини са 32 језгра и 24 ГБ РАМ-а. Граница је постављена на 48 претраживача – 1,5 нити по језгру и око 400 МБ РАМ-а. Као резултат тога, време тестирања је смањено са три сата на 40 минута. Убрзавање покретања помогло је у решавању проблема стабилизације: сада смо могли брзо да покренемо нове аутотестове 20–30 пута док не будемо сигурни да раде поуздано.
Први недостатак решења била је висока искоришћеност ресурса покретача са малим бројем паралелних нити: на 4 језгра и 8 ГБ РАМ-а, тестови су се одвијали стабилно у не више од 6 нити. Други недостатак: додатак генерише класе покретача за сваки сценарио, без обзира колико их је покренуто.
Важно! Немојте прослеђивати променљиву са ознакама аргЛине, на пример, овако:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Ако проследите ознаку на овај начин, додатак ће генерисати тркаче за све тестове, односно покушаће да покрене све тестове, прескачући их одмах након покретања и креирајући много ЈВМ форкова.
Исправно је убацити променљиву са ознаком ознаке у подешавањима додатака, погледајте пример испод. Друге методе које смо тестирали имају проблема са повезивањем додатка Аллуре.
Пример времена рада за 6 кратких тестова са нетачним подешавањима:
[INFO] Total time: 03:17 min
Пример времена извођења теста ако директно пренесете ознаку на мвн... –Дцуцумбер.оптионс:
[INFO] Total time: 44.467 s
Пример подешавања аутоматских тестова:
<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>
Пример Аллуре извештаја (најнестабилнији тест, 4 понављања)
Оптерећење тркача током тестова (8 језгара, 8 ГБ РАМ-а, 12 нити)
Предности:
- једноставно подешавање - само треба да додате додатак;
- способност истовременог извођења великог броја тестова;
- убрзање стабилизације теста захваљујући кораку 1.
Против:
- Потребно је више ОС/контејнера;
- висока потрошња ресурса за сваку виљушку;
- Додатак је застарео и више није подржан.
Како превазићи нестабилност
Испитне клупе нису идеалне, баш као и сами аутотестови. Није изненађујуће што имамо велики број лоших тестова. Притекао је у помоћ, који из кутије подржава поновно покретање неуспешних тестова. Морате ажурирати верзију додатка на најмање 2.21 и написати један ред са бројем поновних покретања у пом датотеци или га проследити као аргумент Мавену.
Пример подешавања аутоматских тестова:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
Или при покретању: мвн … -Дсурефире.рерунФаилингТестсЦоунт=2 …
Као опцију, поставите Мавен опције за ПоверСхелл скрипту (ПС1):
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"Предности:
- нема потребе да губите време на анализу нестабилног теста када се сруши;
- Проблеми са стабилношћу испитног стола могу се ублажити.
Против:
- плутајући недостаци могу се пропустити;
- време рада се повећава.
Паралелни тестови са библиотеком Цуцумбер 4
Сваки дан је растао број тестова. Поново смо размишљали о убрзању трчања. Поред тога, желео сам да интегришем што више тестова у цевовод за склапање апликације. Критични фактор је био то што је генерација тркача трајала предуго када је трчала паралелно користећи Мавен додатак.
У то време, Цуцумбер 4 је већ био објављен, па смо одлучили да препишемо кернел за ову верзију. У белешкама о издању обећано нам је паралелно покретање на нивоу нити. Теоретски, ово је требало да буде:
- значајно убрзати покретање аутотестова повећањем броја нити;
- елиминише губитак времена на генерисање тркача за сваки аутотест.
Показало се да није тако тешко оптимизовати оквир за аутотестове са више нити. Цуцумбер 4 покреће сваки појединачни тест на наменској нити од почетка до краја, тако да су неке уобичајене статичке ствари једноставно конвертоване у ТхреадЛоцал променљиве.
Главна ствар при конверзији помоћу Идеа алата за рефакторисање је да проверите места на којима је променљива упоређена (на пример, провера нуле). Поред тога, потребно је да додате додатак Аллуре у напомену класе Јунит Руннер.
Пример подешавања аутоматских тестова:
<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>
Пример Аллуре извештаја (најнестабилнији тест, 5 понављања)
Оптерећење тркача током тестова (8 језгара, 8 ГБ РАМ-а, 24 нити)
Предности:
- ниска потрошња ресурса;
- изворна подршка од Цуцумбер-а - нису потребни додатни алати;
- могућност покретања више од 6 нити по језгру процесора.
Против:
- потребно је да се уверите да код подржава вишенитно извршавање;
- повећава се улазни праг.
Аллуре извештава на ГитЛаб страницама
Након увођења вишенитног извршавања, почели смо да трошимо много више времена на анализу извештаја. У то време, морали смо да отпремимо сваки извештај као артефакт у ГитЛаб, затим да га преузмемо и распакујемо. Није баш згодно и дуго траје. А ако неко други жели сам да види извештај, онда ће морати да уради исте операције. Желели смо да брже добијемо повратне информације и нашли смо решење - ГитЛаб странице. Ово је уграђена функција која је доступна из кутије у свим новијим верзијама ГитЛаб-а. Омогућава вам да поставите статичне сајтове на ваш сервер и приступите им путем директне везе.
Сви снимци екрана Аллуре извештаја су снимљени на ГитЛаб страницама. Скрипта за примену извештаја на ГитЛаб странице - у Виндовс ПоверСхелл-у (пре тога морате да покренете аутотестове):
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
Са резултатом да
Дакле, ако сте размишљали о томе да ли вам је потребан Тхреад сафе код у оквиру аутотестирања Цуцумбер, сада је одговор очигледан - са Цуцумбером 4 га је лако имплементирати, чиме се значајно повећава број нити које се истовремено покрећу. Код овог начина вођења тестова поставља се питање перформанси машине са Селеноидом и испитног стола.
Пракса је показала да покретање аутотестова на нитима омогућава смањење потрошње ресурса на минимум уз најбоље перформансе. Као што се може видети из графикона, удвостручавање нити не доводи до сличног убрзања у тестовима перформанси. Међутим, успели смо да додамо више од 2 аутоматизованих тестова у верзију апликације, која чак и са 200 понављања ради за око 5 минута. Ово вам омогућава да добијете брзе повратне информације од њих и, ако је потребно, извршите измене и поновите процедуру.
Извор: ввв.хабр.цом