Манай хэлтэс нь хэрэглээний шинэ хувилбаруудыг үйлдвэрлэлийн орчинд нэвтрүүлэх бүрэн автомат шугам сүлжээг бий болгодог. Мэдээжийн хэрэг, энэ нь автоматжуулсан функциональ туршилтыг шаарддаг. Зүсэлтийн доор бид локал машин дээр нэг утастай тест хийхээс эхлээд GitLab хуудсууд дээрх Allure тайланг ашиглан бүтээх шугам дээрх Selenoid дээр ажиллаж байгаа олон урсгалт автомат туршилтын цэгт хүрч, эцэст нь гайхалтай автоматжуулалтын хэрэгсэлтэй болсон тухай түүх байна. ирээдүйн хүмүүс багийг ашиглах боломжтой.
Бид хаанаас эхэлсэн бэ?
Автомат туршилтыг хэрэгжүүлэх, тэдгээрийг дамжуулах хоолойд нэгтгэхийн тулд бидэнд хэрэгцээнд нийцүүлэн уян хатан өөрчлөх боломжтой автоматжуулалтын систем хэрэгтэй байсан. Тохиромжтой нь, би дамжуулах хоолойд автомат туршилтыг оруулахад тохируулсан автомат туршилтын хөдөлгүүрийн нэг стандартыг авахыг хүссэн. Хэрэгжүүлэхийн тулд бид дараах технологийг сонгосон.
- Жава,
- Мэвен,
- селен,
- Өргөст хэмх+JUNIT 4,
- сэтгэл татам,
- GitLab.
Яагаад энэ тусгай багц вэ? Java бол автоматжуулсан тест хийх хамгийн алдартай хэлнүүдийн нэг бөгөөд багийн бүх гишүүд үүнийг ярьдаг. Селен бол тодорхой шийдэл юм. Өргөст хэмх нь бусад зүйлсийн дунд гар аргаар туршилт хийдэг хэлтэсүүдийн автоматжуулсан туршилтын үр дүнд итгэх итгэлийг нэмэгдүүлэх ёстой байв.
Нэг урсгалтай туршилтууд
Дугуйг дахин зохион бүтээхгүйн тулд бид GitHub дээрх янз бүрийн хадгалах сангаас боловсруулалтыг хүрээний үндэс болгон авч, өөрсдөдөө тохируулсан. Бид үндсэн номын санд зориулж автотестийн тогтолцооны гол цөмтэй репозитор болон өөрийн үндсэн дээр автомат тестийг хэрэгжүүлэх Алтан жишээ бүхий репозиторыг бүтээсэн. Баг бүр Алтан зургийг авч, түүн дээрээ туршилт хийж, төсөлдөө тохируулан хийх ёстой байв. Бид үүнийг GitLab-CI банкинд байршуулж, тохируулсан:
- төсөл бүрийн бүх бичигдсэн автомат тестийн өдөр тутмын гүйлт;
- барих шугам хоолойд эхлүүлж байна.
Эхлээд цөөн тооны туршилтууд байсан бөгөөд тэдгээрийг нэг урсгалаар хийдэг байв. GitLab Windows runner дээр нэг урсгалтай ажиллах нь бидэнд маш сайн тохирсон: туршилтууд нь туршилтын ванданг маш хөнгөн ачаалж, бараг ямар ч нөөц ашиглаагүй.
Цаг хугацаа өнгөрөхөд автомат туршилтын тоо улам бүр нэмэгдэж, бүрэн гүйлт гурван цаг орчим үргэлжилж эхлэхэд бид тэдгээрийг зэрэгцүүлэн ажиллуулах талаар бодсон. Бусад асуудлууд бас гарч ирэв:
- туршилтууд тогтвортой байгаа эсэхийг бид шалгаж чадаагүй;
- Орон нутгийн машин дээр хэд хэдэн удаа дараалан явуулсан туршилтууд заримдаа 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 ГБ RAM, 1 урсгал)
Нэг урсгалтай тестийн давуу талууд:
- тохируулах, ажиллуулахад хялбар;
- CI дахь хөөргөлтүүд нь орон нутгийн хөөргөлтүүдээс бараг ялгаагүй;
- туршилтууд бие биедээ нөлөөлдөггүй;
- гүйлтийн нөөцөд тавигдах хамгийн бага шаардлага.
Нэг урсгалтай тестийн сул талууд:
- дуусгахад маш удаан хугацаа шаардагдана;
- туршилтыг удаан тогтворжуулах;
- гүйлтийн нөөцийг үр ашиггүй ашиглах, маш бага ашиглалт.
JVM сэрээ дээрх туршилтууд
Бид үндсэн фрэймворкийг хэрэгжүүлэхдээ thread-safe кодыг анхаарч үзээгүй тул зэрэгцээ ажиллах хамгийн ойлгомжтой арга бол Мэвенийн хувьд. Plugin-ийг тохируулахад хялбар боловч зөв зэрэгцээ ажиллахын тулд автомат тестийг тусдаа хөтөч дээр ажиллуулах ёстой. Хийх зүйл байхгүй, би Selenoid-ийг ашиглах ёстой байсан.
Selenoid серверийг 32 цөм, 24 ГБ RAM бүхий машин дээр эхлүүлсэн. Хязгаарыг 48 хөтчөөр тогтоосон - нэг цөмд 1,5 урсгал, 400 орчим MB RAM. Ингэснээр шалгалтын хугацаа гурван цаг байсныг 40 минут болгон бууруулсан байна. Гүйлтийг хурдасгах нь тогтворжуулах асуудлыг шийдвэрлэхэд тусалсан: одоо бид шинэ автомат туршилтуудыг найдвартай ажиллаж байгаа гэдэгт итгэлтэй болтол 20-30 удаа хурдан ажиллуулах боломжтой болсон.
Шийдлийн эхний сул тал бол цөөн тооны зэрэгцээ утастай гүйгч нөөцийг өндөр ашиглах явдал байв: 4 цөм, 8 ГБ RAM дээр туршилтууд 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... – Өргөст хэмх. сонголтууд:
[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 ГБ RAM, 12 утас)
Нөхцөл:
- хялбар тохиргоо - та зүгээр л залгаас нэмэх хэрэгтэй;
- олон тооны туршилтыг нэгэн зэрэг хийх чадвар;
- 1-р алхамын ачаар туршилтын тогтворжилтыг хурдасгах.
Нөхцөл байдал:
- Олон үйлдлийн систем/контейнер шаардлагатай;
- сэрээ бүрийн нөөцийн өндөр зарцуулалт;
- Plugin нь хуучирсан бөгөөд цаашид дэмжигдэхгүй.
Тогтворгүй байдлыг хэрхэн даван туулах вэ
Туршилтын вандан сандал нь автомат тестийн нэгэн адил тийм ч тохиромжтой биш юм. Бидэнд олон тооны бүдүүлэг туршилтууд байгаа нь гайхах зүйл биш юм. Аврахаар ирсэн, энэ нь амжилтгүй болсон туршилтуудыг дахин эхлүүлэхийг дэмждэг. Та залгаасын хувилбарыг дор хаяж 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"Нөхцөл:
- тогтворгүй туршилтыг эвдэрсэн үед дүн шинжилгээ хийхэд цаг үрэх шаардлагагүй;
- Туршилтын вандан тогтвортой байдлын асуудлыг багасгах боломжтой.
Нөхцөл байдал:
- хөвөгч согогийг орхигдуулж болно;
- ажиллах хугацаа нэмэгддэг.
Өргөст хэмх 4 номын сантай зэрэгцээ туршилтууд
Туршилтын тоо өдөр бүр нэмэгдсээр байв. Бид гүйлтийг хурдасгах талаар дахин бодлоо. Нэмж дурдахад би програмын угсралтын хоолойд аль болох олон тестийг нэгтгэхийг хүссэн. Чухал хүчин зүйл нь Maven залгаасыг ашиглан зэрэгцээ гүйх үед гүйгчдийг үүсгэх нь хэтэрхий удаан үргэлжилсэн явдал байв.
Тухайн үед Өргөст хэмх 4 аль хэдийн гарсан байсан тул бид энэ хувилбарын цөмийг дахин бичихээр шийдсэн. Хувилбарын тэмдэглэлд бидэнд урсгалын түвшинд зэрэгцээ хөөргөх амлалт өгсөн. Онолын хувьд ийм байх ёстой:
- утаснуудын тоог нэмэгдүүлэх замаар автомат туршилтын ажиллагааг ихээхэн хурдасгах;
- автотест бүрт гүйгч үүсгэх цаг алдагдлыг арилгах.
Олон урсгалтай автомат тестийн хүрээг оновчтой болгох нь тийм ч хэцүү биш болсон. Өргөст хэмх 4 нь тест бүрийг тусгай утас дээр эхнээс нь дуустал ажиллуулдаг тул зарим нийтлэг статик зүйлсийг ThreadLocal хувьсагч руу хөрвүүлсэн.
Idea refactoring хэрэгслийг ашиглан хөрвүүлэхэд хамгийн гол зүйл бол хувьсагчийг харьцуулсан газруудыг шалгах явдал юм (жишээлбэл, null эсэхийг шалгах). Нэмж дурдахад та 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 ГБ RAM, 24 утас)
Нөхцөл:
- нөөцийн хэрэглээ бага;
- Өргөст хэмхээс уугуул дэмжлэг - нэмэлт хэрэгсэл шаардлагагүй;
- процессорын цөмд 6-аас дээш урсгалыг ажиллуулах чадвар.
Нөхцөл байдал:
- та код нь олон урсгалтай гүйцэтгэлийг дэмждэг эсэхийг шалгах хэрэгтэй;
- орох босго нэмэгдэнэ.
GitLab хуудсан дээрх Allure тайлангууд
Олон урсгалтай гүйцэтгэлийг нэвтрүүлсний дараа бид тайланд дүн шинжилгээ хийхэд илүү их цаг зарцуулж эхэлсэн. Тухайн үед бид тайлан бүрийг GitLab-д олдвор болгон байршуулж, дараа нь татаж аваад задлах ёстой байсан. Энэ нь тийм ч тохиромжтой биш бөгөөд удаан хугацаа шаарддаг. Хэрэв өөр хэн нэгэн тайланг өөрөө үзэхийг хүсвэл тэд ижил үйлдлүүдийг хийх шаардлагатай болно. Бид санал хүсэлтийг хурдан хүлээн авахыг хүссэн бөгөөд бид шийдэл оллоо - GitLab хуудас. Энэ нь GitLab-ийн сүүлийн үеийн бүх хувилбаруудад байдаг суулгагдсан функц юм. Таны сервер дээр статик сайтуудыг байрлуулж, шууд холбоосоор дамжуулан хандах боломжийг танд олгоно.
Allure тайлангийн бүх дэлгэцийн агшинг GitLab хуудсан дээр авсан. Windows PowerShell дээр GitLab хуудсанд тайланг байршуулах скрипт (Үүнээс өмнө та автомат тестийг ажиллуулах шаардлагатай):
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 минутын дотор ажилладаг. Энэ нь танд тэднээс хурдан санал хүсэлт хүлээн авах, шаардлагатай бол өөрчлөлт хийж, процедурыг дахин давтах боломжийг олгоно.
Эх сурвалж: www.habr.com