Биздин бөлүм өндүрүш чөйрөсүнө тиркемелердин жаңы версияларын ишке киргизүү үчүн толук автоматтык түтүктөрдү түзөт. Албетте, бул үчүн автоматташтырылган функционалдык тесттер талап кылынат. Төмөндө жергиликтүү машинада бир жиптүү тестирлөөдөн баштап, биз GitLab беттеринде Allure отчету менен куруу түтүкчөсүндө Selenoidде иштеген көп жиптүү автотесттин чекитине жеткенибиз жана акырында сонун автоматташтыруу куралына ээ болгонубуз жөнүндө окуя бар. келечектеги адамдар командаларды колдоно алышат.
Биз эмнеден баштадык?
Автотесттерди ишке ашыруу жана аларды түтүккө интеграциялоо үчүн бизге муктаждыктарыбызга ылайыктуу түрдө ийкемдүү түрдө өзгөртө турган автоматташтыруу системасы керек болду. Идеалында, мен автотестирлөө кыймылдаткычынын бирдиктүү стандартын алгым келди, ал автотесттерди куурга киргизүү үчүн ылайыкташтырылды. Ишке ашыруу үчүн биз төмөнкү технологияларды тандап алдык:
- Java,
- Мэвен,
- Селен,
- Бадыраң+ЖУНИТ 4,
- Алтургай,
- GitLab.
Эмне үчүн бул өзгөчө топтому? Java - автоматташтырылган тесттер үчүн эң популярдуу тилдердин бири жана команданын бардык мүчөлөрү аны сүйлөшөт. Селен айкын чечим болуп саналат. Бадыраң, башка нерселер менен катар, кол менен тестирлөө менен алектенген бөлүмдөр тарабынан автоматташтырылган тесттердин натыйжаларына болгон ишенимди жогорулатуу керек болчу.
Жалгыз жиптүү тесттер
Дөңгөлөктү кайра ойлоп таппоо үчүн, биз GitHubдагы ар кандай репозиторийлерден иштеп чыгууларды негиз катары алып, аларды өзүбүзгө ылайыкташтырдык. Биз автотест негизинин өзөгү менен негизги китепкана үчүн репозиторийди жана өзөктөгү автотесттерди ишке ашыруунун алтын үлгүсү бар репозиторийди түздүк. Ар бир команда «Алтын» сүрөтүн алып, андагы тесттерди иштеп чыгып, аны өз долбооруна ылайыкташтырышы керек болчу. Биз аны GitLab-CI банкына жайгаштырдык, анда биз конфигурациялаганбыз:
- ар бир долбоор үчүн бардык жазылган автотесттердин күнүмдүк жүрүшү;
- куруу куурунда ишке киргизет.
Алгач сыноолор аз болуп, алар бир агымда өткөрүлчү. Windows Runner GitLab боюнча бир жиптүү чуркоо бизге абдан ылайыктуу болду: тесттер тесттик стендди өтө жеңил жүктөдү жана дээрлик эч кандай ресурстарды колдонбоду.
Убакыттын өтүшү менен автотесттердин саны барган сайын көбөйдү жана биз аларды параллелдүү жүргүзүүнү ойлондук, толук чуркоо үч саатка жакын убакытты ала баштаганда. Башка көйгөйлөр да пайда болду:
- биз сыноолордун туруктуу экенин текшере алган жокпуз;
- жергиликтүү машинада катары менен бир нече жолу аткарылган сыноолор CIде кээде бузулуп калат.
Автотесттерди орнотуунун мисалы:
<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 отчеттун мисалы
Сыноолор учурунда жүгүргүч (8 өзөк, 8 ГБ оперативдүү эс, 1 жип)
Жалгыз жиптүү тесттердин жакшы жактары:
- орнотуу жана иштетүү үчүн жеңил;
- CIдеги учуруулар жергиликтүү учуруулардан дээрлик айырмаланбайт;
- тесттер бири-бирине таасир этпейт;
- чуркоочу ресурстар үчүн минималдуу талаптар.
Жалгыз жиптүү тесттердин кемчиликтери:
- аяктоо үчүн абдан көп убакыт талап кылынат;
- сыноолордун узак турукташтыруу;
- күлүк ресурстарын натыйжасыз пайдалануу, өтө төмөн пайдалануу.
JVM айрыларында тесттер
Негизги алкакты ишке ашырууда биз жиптин коопсуз кодуна кам көрбөгөндүктөн, параллелдүү иштөөнүн эң ачык жолу болгон. Maven үчүн. Плагинди конфигурациялоо оңой, бирок туура параллелдүү иштөө үчүн автотесттерди өзүнчө браузерлерде жүргүзүү керек. Эч нерсе жок, мен Селеноидди колдонушум керек болчу.
Selenoid сервери 32 өзөгү жана 24 ГБ оперативдүү эси бар машинада ишке киргизилген. Чектөө 48 браузерде белгиленген - бир ядрого 1,5 жип жана 400 МБга жакын оперативдүү эс. Натыйжада тестирлөө убактысы үч сааттан 40 мүнөткө чейин кыскарды. Чуркоолорду тездетүү турукташтыруу маселесин чечүүгө жардам берди: эми биз жаңы автотесттерди алар ишенимдүү иштегенине ынанмайынча 20–30 жолу тез өткөрө алдык.
Чечимдин биринчи кемчилиги параллелдүү жиптердин аз саны менен жөө күлүк ресурстарын жогорку деңгээлде колдонуу болду: 4 өзөктө жана 8 ГБ оперативдүү эс тутумда, сыноолор 6 жиптен ашык эмес туруктуу өттү. Экинчи жетишпеген жагы: плагин ар бир сценарий үчүн жөө күлүк класстарын жаратат, алардын канчасы ишке кирбесин.
Маанилүү! Тегдери бар өзгөрмөлөрдү өткөрбөңүз argLine, мисалы, бул сыяктуу:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Эгер сиз тегди ушундай жол менен өткөрүп берсеңиз, плагин бардык тесттер үчүн жөө күлүктөрдү жаратат, башкача айтканда, ал бардык тесттерди иштетүүгө аракет кылат, аларды ишке киргизгенден кийин дароо өткөрүп жиберет жана көптөгөн JVM айрыларын түзөт.
теги менен өзгөрмө ыргытуу туура теги плагин орнотууларында, төмөндөгү мисалды караңыз. Биз сынаган башка ыкмаларда Allure плагинин туташтырууда көйгөйлөр бар.
Туура эмес орнотуулар менен 6 кыска сыноо үчүн иштөө убактысынын мисалы:
[INFO] Total time: 03:17 min
Тегти түздөн-түз өткөрүп берсеңиз, сыноонун иштөө убактысынын мисалы mvn... –Dumber.options:
[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>
Allure отчетунун мисалы (эң туруксуз сыноо, 4 кайталоо)
Сыноо учурунда жүгүргүч (8 өзөк, 8 ГБ оперативдүү эс, 12 жип)
артыкчылыктары:
- жеңил орнотуу - жөн гана плагин кошуу керек;
- бир эле учурда көп сандагы сыноолорду жүргүзүү мүмкүнчүлүгү;
- 1-кадамдын аркасында тестти турукташтырууну тездетүү.
жактары:
- Бир нече OS/контейнер талап кылынат;
- ар бир айры үчүн жогорку ресурстарды керектөө;
- Плагин эскирген жана мындан ары колдоого алынбайт.
Туруксуздукту кантип жеңсе болот
Сыноочу отургучтар автотесттердин өздөрү сыяктуу эле идеалдуу эмес. Бизде бир катар катаал сыноолор бар экендиги таң калыштуу эмес. Жардамга келди, ал кутучанын ичинен ийгиликсиз болгон сыноолорду кайра баштоону колдойт. Сиз плагин версиясын жок дегенде 2.21ге жаңыртышыңыз керек жана pom файлында кайра иштетүүлөрдүн саны менен бир сапты жазышыңыз керек же аны Mavenге аргумент катары өткөрүп беришиңиз керек.
Автотесттерди орнотуунун мисалы:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
Же ишке киргизүүдө: mvn … -Dsurefire.rerunFailingTestsCount=2 …
Опция катары, PowerShell скриптине (PS1) Maven параметрлерин орнотуңуз:
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"артыкчылыктары:
- ал бузулганда туруксуз тестти талдоо үчүн убакыт коротуунун кереги жок;
- сыноо стендинин туруктуулук көйгөйлөрүн жумшартууга болот.
жактары:
- калкып жүрүүчү кемчиликтерди байкабай коюуга болот;
- иштөө убактысы көбөйөт.
Cucumber 4 китепканасы менен параллелдүү тесттер
Тесттердин саны күн сайын өсүүдө. Биз дагы чуркоолорду тездетүү жөнүндө ойлондук. Мындан тышкары, мен мүмкүн болушунча көп тесттерди тиркемени монтаждоо түтүкчөсүнө кошууну кааладым. Маанилүү фактор, Maven плагинин колдонуу менен параллелдүү чуркоодо жөө күлүктөрдүн мууну өтө узакка созулган.
Ал убакта, Бадыраң 4 мурунтан эле чыгарылган болчу, ошондуктан биз бул версия үчүн ядрону кайра жазууну чечтик. Чыгарылган жазууларда бизге жип деңгээлинде параллелдүү ишке киргизүү убада кылынган. Теориялык жактан ал төмөнкүлөргө ээ болушу керек:
- жиптердин санын көбөйтүү менен автотесттердин жүрүшүн кыйла тездетүү;
- ар бир автотест үчүн жөө күлүктөрдү түзүүдө убакытты жоготууну жок кылыңыз.
Көп агымдуу автотесттердин негизин оптималдаштыруу анчалык деле кыйын эмес болуп чыкты. Бадыраң 4 ар бир жеке тестти башынан аягына чейин атайын жипте иштетет, андыктан кээ бир жалпы статикалык нерселер жөн эле ThreadLocal өзгөрмөлөргө айландырылды.
Idea рефакторинг куралдарын колдонуу менен конвертациялоодо негизги нерсе өзгөрмө салыштырылган жерлерди текшерүү (мисалы, нөлдү текшерүү). Мындан тышкары, сиз Junit Runner классынын аннотациясына Allure плагинин кошушуңуз керек.
Автотесттерди орнотуунун мисалы:
<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 отчетунун мисалы (эң туруксуз сыноо, 5 кайталоо)
Сыноолор учурунда жүгүргүч (8 өзөк, 8 ГБ оперативдүү эс, 24 жип)
артыкчылыктары:
- ресурстарды аз керектөө;
- бадыраңдан жергиликтүү колдоо - кошумча куралдар талап кылынбайт;
- процессордун ядросуна 6дан ашык жипти иштетүү мүмкүнчүлүгү.
жактары:
- сиз коддун көп жиптүү аткарууну колдогонуна кепилдик беришиңиз керек;
- кирүү босогосу жогорулайт.
GitLab баракчаларында Allure отчеттору
Көп жиптүү аткарууну киргизгенден кийин, биз отчетторду талдоо үчүн көбүрөөк убакыт корото баштадык. Ошол учурда биз ар бир отчетту GitLabга артефакт катары жүктөшүбүз керек болчу, андан кийин аны жүктөп алып, таңгактан чыгарышыбыз керек болчу. Бул абдан ыңгайлуу эмес жана көп убакытты талап кылат. Ал эми кимдир бирөө отчетту өзү көргүсү келсе, анда алар ошол эле операцияларды жасашы керек болот. Биз пикирди тезирээк алгыбыз келди жана биз чечим таптык - GitLab баракчалары. Бул GitLab'тын бардык акыркы версияларында кутудан тышкары орнотулган өзгөчөлүк. Сервериңизде статикалык сайттарды жайгаштырууга жана аларга түз шилтеме аркылуу кирүүгө мүмкүндүк берет.
Allure отчетторунун бардык скриншоттору GitLab баракчаларында тартылган. Отчетту GitLab барактарына жайгаштыруу үчүн скрипт - Windows PowerShell ичинде (ага чейин автотесттерди жүргүзүү керек):
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
Натыйжада менен
Ошентип, эгер сиз бадыраңдын автотест алкагындагы Thread коопсуз коду керекпи же жокпу деп ойлонуп жатсаңыз, азыр жооп айкын - Бадыраң 4 менен аны ишке ашыруу оңой, ошону менен бир эле учурда ишке киргизилген жиптердин санын бир топ көбөйтөт. Сыноолорду жүргүзүүнүн бул ыкмасы менен, маселе азыр Selenoid жана сыноо стенди менен машинанын иштеши жөнүндө болуп калат.
Практика көрсөткөндөй, жиптерде автотесттерди жүргүзүү ресурстун керектөөсүн эң жакшы көрсөткүч менен минимумга чейин кыскартууга мүмкүндүк берет. Графиктерден көрүнүп тургандай, жиптерди эки эсеге көбөйтүү өндүрүмдүүлүк сыноолорунда ушундай эле тездетүүгө алып келбейт. Бирок, биз тиркеменин түзүлүшүнө 2дөн ашык автоматташтырылган тесттерди кошо алдык, алар 200 жолу кайталанса дагы 5 мүнөттө иштейт. Бул алардан тез пикир алууга, керек болсо өзгөртүүлөрдү киргизүүгө жана процедураны кайра кайталоого мүмкүндүк берет.
Source: www.habr.com