Bizning bo'linmamiz ishlab chiqarish muhitiga ilovalarning yangi versiyalarini ishga tushirish uchun to'liq avtomatik quvurlarni yaratadi. Albatta, bu avtomatlashtirilgan funktsional testlarni talab qiladi. Kesish ostida mahalliy mashinada bitta ipli testdan boshlab, biz GitLab sahifalarida Allure hisoboti bilan qurish quvur liniyasida Selenoidda ishlaydigan ko'p tarmoqli avtotest nuqtasiga qanday erishganimiz va oxir-oqibat ajoyib avtomatlashtirish vositasiga ega bo'lganimiz haqidagi hikoya. kelajakdagi odamlar jamoalardan foydalanishlari mumkin.
Biz qayerdan boshladik?
Avtotestlarni amalga oshirish va ularni quvur liniyasiga integratsiya qilish uchun bizga ehtiyojlarimizga mos ravishda moslashuvchan tarzda o'zgartirilishi mumkin bo'lgan avtomatlashtirish tizimi kerak edi. Ideal holda, men avtotestlarni quvur liniyasiga kiritish uchun moslashtirilgan avtomatik sinov mexanizmi uchun yagona standartni olishni xohlardim. Amalga oshirish uchun biz quyidagi texnologiyalarni tanladik:
- Java,
- Maven,
- Selen,
- Bodring+JUNIT 4,
- Jozibali,
- GitLab.
Nima uchun bu maxsus to'plam? Java avtomatlashtirilgan testlar uchun eng mashhur tillardan biri bo'lib, barcha jamoa a'zolari bu tilda gapirishadi. Selen - bu aniq yechim. Bodring, boshqa narsalar qatorida, qo'lda sinov bilan shug'ullanadigan bo'limlar tomonidan avtomatlashtirilgan testlar natijalariga ishonchni oshirishi kerak edi.
Yagona tishli testlar
G'ildirakni qayta ixtiro qilmaslik uchun biz GitHub-dagi turli xil omborlardan ishlanmalarni ramka uchun asos qilib oldik va ularni o'zimiz uchun moslashtirdik. Biz asosiy kutubxona uchun avtotest tizimi yadrosi va yadromizda avtotestlarni amalga oshirishning oltin misoli bilan omborni yaratdik. Har bir jamoa Oltin tasvirni olishi va unda testlarni ishlab chiqish, uni o'z loyihasiga moslashtirish kerak edi. Biz uni GitLab-CI bankiga joylashtirdik, unda biz sozladik:
- har bir loyiha uchun barcha yozma avtotestlarning kunlik ishlashi;
- qurilish quvurida ishga tushiriladi.
Avvaliga bir nechta sinovlar bor edi va ular bitta oqimda o'tkazildi. Windows ishlovchisi GitLab-da bir torli ishlash bizga juda mos keldi: testlar sinov stolini juda yengil yukladi va deyarli hech qanday resurslar ishlatilmadi.
Vaqt o'tishi bilan avtotestlar soni tobora ko'payib bordi va biz ularni parallel ravishda o'tkazish haqida o'yladik, to'liq yugurish taxminan uch soat davom eta boshladi. Boshqa muammolar ham paydo bo'ldi:
- testlarning barqarorligini tekshira olmadik;
- mahalliy mashinada ketma-ket bir necha marta o'tkazilgan testlar ba'zan CIda qulab tushdi.
Avtotestlarni sozlash misoli:
<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 hisobot namunasi
Sinovlar paytida yuguruvchi yuki (8 yadro, 8 GB RAM, 1 ip)
Bir torli testlarning afzalliklari:
- sozlash va ishga tushirish oson;
- CIda ishga tushirishlar mahalliy ishga tushirishlardan deyarli farq qilmaydi;
- testlar bir-biriga ta'sir qilmaydi;
- yuguruvchi resurslariga minimal talablar.
Bir ipli testlarning kamchiliklari:
- bajarish uchun juda uzoq vaqt talab etiladi;
- testlarni uzoq vaqt barqarorlashtirish;
- yuguruvchi resurslaridan samarasiz foydalanish, juda kam foydalanish.
JVM vilkalari bo'yicha testlar
Asosiy ramkani amalga oshirishda biz iplar xavfsizligi kodiga e'tibor bermaganimiz sababli, parallel ravishda ishlashning eng aniq usuli edi. Maven uchun. Plaginni sozlash oson, lekin to'g'ri parallel ishlash uchun avtotestlar alohida brauzerlarda o'tkazilishi kerak. Hech narsa qilish kerak emas, men Selenoiddan foydalanishim kerak edi.
Selenoid serveri 32 yadroli va 24 Gb tezkor xotiraga ega mashinada ishga tushirildi. Cheklov 48 ta brauzerda o'rnatildi - har bir yadro uchun 1,5 ip va taxminan 400 MB operativ xotira. Natijada test sinovlari uch soatdan 40 daqiqagacha qisqardi. Yugurishlarni tezlashtirish barqarorlashtirish muammosini hal qilishga yordam berdi: endi biz yangi avtotestlarni ishonchli bajarilganiga ishonch hosil qilmagunimizcha 20-30 marta tezda o'tkazishimiz mumkin edi.
Yechimning birinchi kamchiliklari kam sonli parallel iplar bilan yuguruvchi resurslaridan yuqori darajada foydalanish edi: 4 yadro va 8 Gb tezkor xotirada sinovlar 6 tadan ko'p bo'lmagan holda barqaror o'tdi. Ikkinchi kamchilik: plagin qancha ishga tushirilganidan qat'i nazar, har bir stsenariy uchun yuguruvchi sinflarini yaratadi.
Muhim! Teglar bilan o'zgaruvchini o'tkazmang argLine, masalan, bu kabi:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
β¦
Mvn βDTAGS="@smoke"
Agar siz tegni shu tarzda o'tkazsangiz, plagin barcha testlar uchun yuguruvchilarni yaratadi, ya'ni u barcha testlarni bajarishga harakat qiladi, ishga tushirilgandan so'ng darhol ularni o'tkazib yuboradi va ko'plab JVM vilkalarini yaratadi.
Teg bilan o'zgaruvchini tashlash to'g'ri tags plagin sozlamalarida quyidagi misolga qarang. Biz sinab ko'rgan boshqa usullarda Allure plaginini ulashda muammolar mavjud.
Noto'g'ri sozlamalar bilan 6 ta qisqa test uchun ish vaqtiga misol:
[INFO] Total time: 03:17 min
Agar siz tegni to'g'ridan-to'g'ri o'tkazsangiz, sinov muddatiga misol mvn... βDcucumber.options:
[INFO] Total time: 44.467 s
Avtotestlarni sozlash misoli:
<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 hisobotiga misol (eng beqaror test, 4 marta takrorlash)
Sinov paytida yuguruvchi yuki (8 yadro, 8 GB operativ xotira, 12 ta ip)
Taroziga soling:
- oson sozlash - siz faqat plaginni qo'shishingiz kerak;
- bir vaqtning o'zida ko'p sonli testlarni o'tkazish qobiliyati;
- 1-bosqich tufayli test barqarorligini tezlashtirish.
Kamchiliklari:
- Bir nechta OS/konteynerlar talab qilinadi;
- har bir vilka uchun yuqori resurs iste'moli;
- Plagin eskirgan va endi qo'llab-quvvatlanmaydi.
Qanday qilib beqarorlikni engish mumkin
Sinov dastgohlari avtotestlarning o'zlari kabi ideal emas. Bizda bir qator noaniq testlar borligi ajablanarli emas. Qutqarish uchun keldi, bu qutidan muvaffaqiyatsiz testlarni qayta ishga tushirishni qo'llab-quvvatlaydi. Plagin versiyasini kamida 2.21 ga yangilashingiz va pom faylida qayta ishga tushirishlar soni bilan bitta qatorni yozishingiz yoki uni Mavenga argument sifatida topshirishingiz kerak.
Avtotestlarni sozlash misoli:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
β¦.
<rerunFailingTestsCount>2</rerunFailingTestsCount>
β¦.
</configuration>
</plugin>
Yoki ishga tushirilganda: mvn β¦ -Dsurefire.rerunFailingTestsCount=2 β¦
Variant sifatida PowerShell skripti (PS1) uchun Maven parametrlarini o'rnating:
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"Taroziga soling:
- ishdan chiqqanida beqaror testni tahlil qilish uchun vaqt sarflashning hojati yo'q;
- sinov dastgohi barqarorligi muammolarini yumshatish mumkin.
Kamchiliklari:
- suzuvchi nuqsonlarni o'tkazib yuborish mumkin;
- ishlash vaqti ortadi.
Bodring 4 kutubxonasi bilan parallel testlar
Sinovlar soni kundan-kunga oshib bordi. Biz yana yugurishni tezlashtirish haqida o'yladik. Bundan tashqari, men iloji boricha ko'proq testlarni ilovalarni yig'ish quvuriga qo'shishni xohladim. Muhim omil shundaki, Maven plaginidan foydalangan holda parallel ravishda yugurishda yuguruvchilar avlodi juda uzoq davom etdi.
O'sha paytda, Bodring 4 allaqachon chiqarilgan edi, shuning uchun biz ushbu versiya uchun yadroni qayta yozishga qaror qildik. Chiqarish qaydlarida bizga ip darajasida parallel ishga tushirish va'da qilingan edi. Nazariy jihatdan bu shunday bo'lishi kerak edi:
- iplar sonini ko'paytirish orqali avtotestlarning bajarilishini sezilarli darajada tezlashtirish;
- har bir avtotest uchun yuguruvchilarni yaratishda vaqt yo'qotilishini bartaraf qiling.
Ko'p tarmoqli avtotestlar uchun ramkani optimallashtirish unchalik qiyin bo'lmadi. Bodring 4 har bir testni boshidan oxirigacha maxsus ipda o'tkazadi, shuning uchun ba'zi umumiy statik narsalar shunchaki ThreadLocal o'zgaruvchilariga aylantirildi.
Idea refactoring vositalaridan foydalangan holda konvertatsiya qilishda asosiy narsa o'zgaruvchining taqqoslangan joylarini tekshirish (masalan, nullni tekshirish). Bundan tashqari, siz Junit Runner sinf izohiga Allure plaginini qo'shishingiz kerak.
Avtotestlarni sozlash misoli:
<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 hisobotiga misol (eng beqaror test, 5 marta takrorlash)
Sinov paytida yuguruvchi yuki (8 yadro, 8 GB RAM, 24 ta ip)
Taroziga soling:
- kam resurs iste'moli;
- bodringdan mahalliy yordam - qo'shimcha vositalar talab qilinmaydi;
- protsessor yadrosi uchun 6 dan ortiq ipni ishlatish qobiliyati.
Kamchiliklari:
- kod ko'p tarmoqli bajarilishini qo'llab-quvvatlashiga ishonch hosil qilishingiz kerak;
- kirish chegarasi ortadi.
GitLab sahifalarida Allure hisobotlari
Ko'p tarmoqli bajarishni joriy qilgandan so'ng, biz hisobotlarni tahlil qilish uchun ko'proq vaqt sarflashni boshladik. O'sha paytda biz har bir hisobotni GitLab-ga artefakt sifatida yuklashimiz, keyin uni yuklab olishimiz va uni ochishimiz kerak edi. Bu juda qulay emas va ko'p vaqt talab etadi. Va agar kimdir hisobotni o'zi ko'rishni xohlasa, ular xuddi shunday operatsiyalarni bajarishlari kerak bo'ladi. Biz fikr-mulohazalarni tezroq olishni xohladik va biz yechim topdik - GitLab sahifalari. Bu GitLabning barcha so'nggi versiyalarida qutidan tashqarida mavjud bo'lgan o'rnatilgan xususiyatdir. Sizning serveringizda statik saytlarni joylashtirish va ularga to'g'ridan-to'g'ri havola orqali kirish imkonini beradi.
Allure hisobotlarining barcha skrinshotlari GitLab sahifalarida olingan. Hisobotni GitLab sahifalariga joylashtirish uchun skript - Windows PowerShell-da (bundan oldin siz avtotestlarni bajarishingiz kerak):
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
Nima oxir-oqibatda
Shunday qilib, agar siz Bodring avtotest tizimida Thread xavfsiz kodi kerakmi yoki yo'qmi deb o'ylayotgan bo'lsangiz, endi javob aniq - Bodring 4 bilan uni amalga oshirish juda oson va shu bilan bir vaqtning o'zida ishga tushirilgan iplar sonini sezilarli darajada oshiradi. Sinovlarni o'tkazishning ushbu usuli bilan savol endi Selenoid va sinov dastgohi bilan mashinaning ishlashi haqida bo'ladi.
Amaliyot shuni ko'rsatdiki, iplar bo'yicha avtotestlarni o'tkazish eng yaxshi ko'rsatkichlar bilan resurslar sarfini minimal darajaga kamaytirish imkonini beradi. Grafiklardan ko'rinib turibdiki, iplarni ikki baravar oshirish ishlash testlarida shunga o'xshash tezlashuvga olib kelmaydi. Biroq, biz ilovalarni yaratishga 2 dan ortiq avtomatlashtirilgan testlarni qo'shishga muvaffaq bo'ldik, ular hatto 200 marta takrorlashda ham taxminan 5 daqiqada ishlaydi. Bu sizga ulardan tezkor fikr-mulohazalarni olish imkonini beradi va agar kerak bo'lsa, o'zgartirishlar kiritib, protsedurani yana takrorlang.
Manba: www.habr.com