Իրականացնել, մասշտաբ՝ ՎՏԲ-ում ավտոմատ թեստերի օգտագործման փորձ

Մեր ստորաբաժանումը ստեղծում է լիովին ավտոմատ խողովակաշարեր՝ արտադրական միջավայրում հավելվածների նոր տարբերակները գործարկելու համար: Իհարկե, դա պահանջում է ավտոմատացված ֆունկցիոնալ թեստեր: Հատվածի ներքևում մի պատմություն է այն մասին, թե ինչպես, սկսելով տեղական մեքենայի վրա մեկ շղթայական փորձարկումից, մենք հասանք Selenoid-ի վրա գործարկվող բազմաշերտ ավտոմատ փորձարկման կետին, կառուցման խողովակաշարում, Allure զեկույցով GitLab-ի էջերում և ի վերջո ստացանք ավտոմատացման հիանալի գործիք: որ ապագա մարդիկ կարող են օգտագործել թիմերը:

Որտեղի՞ց սկսեցինք:

Ավտոթեստեր իրականացնելու և դրանք խողովակաշարում ինտեգրելու համար մեզ անհրաժեշտ էր ավտոմատացման շրջանակ, որը կարող էր ճկուն կերպով փոփոխվել՝ մեր կարիքներին համապատասխան: Իդեալում, ես ուզում էի ձեռք բերել ավտոմատ փորձարկման շարժիչի միասնական ստանդարտ, որը հարմարեցված է խողովակաշարի մեջ ավտոմատ փորձարկումներ տեղադրելու համար: Իրականացման համար մենք ընտրել ենք հետևյալ տեխնոլոգիաները.

• 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 ԳԲ RAM, 1 թել)
 
Մեկ թելային թեստերի առավելությունները.

• հեշտ է կարգավորել և գործարկել;
• CI-ում գործարկումները գործնականում չեն տարբերվում տեղական գործարկումներից.
• թեստերը չեն ազդում միմյանց վրա.
• վազորդի ռեսուրսների նվազագույն պահանջները:

Մեկ թելային թեստերի թերությունները.

• ավարտելու համար շատ երկար ժամանակ է պահանջվում;
• թեստերի երկար կայունացում;
• վազող ռեսուրսների անարդյունավետ օգտագործում, չափազանց ցածր օգտագործում:

Փորձարկումներ JVM պատառաքաղների վրա

Քանի որ մենք չենք խնամել շղթայական ապահով ծածկագիրը բազային շրջանակն իրականացնելիս, զուգահեռ գործելու ամենաակնառու ձևն էր. վարունգ-jvm-parallel-plugin Մավենի համար։ Փլագինը հեշտ է կարգավորել, բայց ճիշտ զուգահեռ աշխատանքի համար ավտոմատ փորձարկումները պետք է իրականացվեն առանձին բրաուզերներում: Անելիք չկա, ստիպված էի Սելենոիդ օգտագործել։

Selenoid սերվերը գործարկվել է 32 միջուկով և 24 ԳԲ օպերատիվ հիշողությամբ մեքենայի վրա: Սահմանաչափը սահմանվել է 48 բրաուզեր՝ 1,5 թել մեկ միջուկի համար և մոտ 400 ՄԲ օպերատիվ հիշողություն: Արդյունքում թեստի ժամանակը երեք ժամից կրճատվել է մինչև 40 րոպե։ Գործարկումների արագացումը օգնեց լուծել կայունացման խնդիրը. այժմ մենք կարող էինք արագ նոր ավտոմատ թեստավորումներ կատարել 20-30 անգամ, մինչև համոզվեինք, որ դրանք հուսալի են աշխատում:
Լուծման առաջին թերությունը վազող ռեսուրսների մեծ օգտագործումն էր փոքր թվով զուգահեռ թելերով. 4 միջուկի և 8 ԳԲ օպերատիվ հիշողության վրա, թեստերը կայուն են անցել ոչ ավելի, քան 6 թելերով: Երկրորդ թերությունը. plugin-ը ստեղծում է վազող դասեր յուրաքանչյուր սցենարի համար, անկախ նրանից, թե դրանցից քանիսն են գործարկվում:

Կարեւոր! Մի փոխանցեք պիտակներով փոփոխականը argLine, օրինակ, այսպես.

<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"

Եթե ​​դուք այս կերպ անցնեք պիտակը, ապա plugin-ը կստեղծի վազողներ բոլոր թեստերի համար, այսինքն՝ այն կփորձի կատարել բոլոր թեստերը՝ բաց թողնելով դրանք գործարկումից անմիջապես հետո և ստեղծելով բազմաթիվ JVM պատառաքաղներ։

Ճիշտ է պիտակ ունեցող փոփոխական գցել մեջ Tags plugin-ի կարգավորումներում, տես ստորև բերված օրինակը: Մեր փորձարկված մյուս մեթոդները խնդիրներ ունեն Allure plugin-ը միացնելու հետ:

Սխալ կարգավորումներով 6 կարճ թեստերի գործարկման ժամանակի օրինակ.

[INFO] Total time: 03:17 min

Փորձարկման ժամանակի օրինակ, եթե դուք ուղղակիորեն տեղափոխում եք պիտակը mvn... –Dcucumber.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 ԳԲ RAM, 12 թելեր)
 
Կոալիցիայում:

• հեշտ կարգավորում - պարզապես անհրաժեշտ է ավելացնել plugin;
• մեծ թվով թեստեր միաժամանակ կատարելու ունակություն.
• փորձարկման կայունացման արագացում 1-ին քայլի շնորհիվ: 

Դեմ:

• Պահանջվում է բազմաթիվ ՕՀ/կոնտեյներներ;
• յուրաքանչյուր պատառաքաղի համար ռեսուրսների բարձր սպառում;
• Փլագինը հնացած է և այլևս չի աջակցվում: 

Ինչպես հաղթահարել անկայունությունը 

Փորձարկման նստարաններն իդեալական չեն, ինչպես ինքնաթեստերը: Զարմանալի չէ, որ մենք ունենք մի շարք շերտավոր թեստեր: Օգնության եկավ maven surefire plugin, որն աջակցում է ձախողված թեստերի վերագործարկմանը: Դուք պետք է թարմացնեք 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…
Որպես տարբերակ, սահմանեք Maven ընտրանքներ PowerShell սկրիպտի համար (PS1):

  
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"

Կոալիցիայում:

• կարիք չկա ժամանակ վատնել անկայուն թեստը վերլուծելու համար, երբ այն խափանում է.
• փորձարկման նստարանի կայունության խնդիրները կարող են մեղմվել:

Դեմ:

• լողացող թերությունները կարող են բաց թողնել;
• գործարկման ժամանակը մեծանում է.

Զուգահեռ թեստեր վարունգ 4 գրադարանի հետ

Թեստերի թիվն ամեն օր աճում էր։ Մենք նորից մտածեցինք վազքներն արագացնելու մասին։ Բացի այդ, ես ցանկանում էի հնարավորինս շատ թեստեր ինտեգրել հավելվածի հավաքման խողովակաշարում: Կարևոր գործոնն այն էր, որ վազորդների սերունդը չափազանց երկար տևեց, երբ զուգահեռ վազում էր Maven plugin-ը:

Այն ժամանակ վարունգ 4-ն արդեն թողարկվել էր, ուստի մենք որոշեցինք վերաշարադրել միջուկը այս տարբերակի համար։ Թողարկման նոտաներում մեզ խոստացել էին զուգահեռ գործարկել թելի մակարդակով: Տեսականորեն սա պետք է լիներ.

• զգալիորեն արագացնել ավտոթեստերի անցկացումը՝ ավելացնելով թեմաների քանակը.
• վերացնել ժամանակի կորուստը յուրաքանչյուր ավտոտեստի համար վազորդների գեներացման վրա:

Բազմաթելային ավտոմատ փորձարկումների շրջանակի օպտիմալացումն այնքան էլ դժվար չէր: Cucumber 4-ը յուրաքանչյուր առանձին թեստ է կատարում հատուկ թեմայի վրա սկզբից մինչև վերջ, ուստի որոշ սովորական ստատիկ բաներ պարզապես փոխարկվեցին ThreadLocal փոփոխականների: 
Idea-ի վերամշակման գործիքների միջոցով փոխակերպելիս գլխավորը ստուգելն է այն վայրերը, որտեղ համեմատվել է փոփոխականը (օրինակ՝ ստուգել null-ի առկայությունը): Բացի այդ, դուք պետք է ավելացնեք Allure հավելվածը Junit Runner դասի անոտացիային:

Ավտոթեստերի ստեղծման օրինակ.

 
<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 թելեր գործարկելու ունակություն:

Դեմ:

• դուք պետք է ապահովեք, որ կոդը աջակցում է բազմաշերտ կատարմանը.
• մուտքի շեմը մեծանում է.

Allure-ը հաղորդում է GitLab-ի էջերին

Բազմաթելային կատարումը ներդնելուց հետո մենք սկսեցինք շատ ավելի շատ ժամանակ ծախսել հաշվետվությունների վերլուծության վրա: Այն ժամանակ մենք պետք է յուրաքանչյուր զեկույց վերբեռնեինք որպես արտեֆակտ 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-ի անվտանգ կոդը Cucumber autotest շրջանակում, այժմ պատասխանն ակնհայտ է. Cucumber 4-ի հետ հեշտ է այն իրականացնել՝ դրանով իսկ զգալիորեն մեծացնելով միաժամանակ գործարկվող թեմաների քանակը: Թեստերի վարման այս մեթոդով հարցն այժմ դառնում է Selenoid-ի և փորձարկման նստարանի հետ մեքենայի աշխատանքի մասին:

Պրակտիկան ցույց է տվել, որ թելերի վրա ավտոմատ փորձարկումներ կատարելը թույլ է տալիս նվազագույնի հասցնել ռեսուրսների սպառումը լավագույն կատարողականությամբ: Ինչպես երևում է գրաֆիկներից, թելերի կրկնապատկումը չի հանգեցնում կատարողականի թեստերի նմանատիպ արագացման: Այնուամենայնիվ, մենք կարողացանք ավելի քան 2 ավտոմատացված թեստեր ավելացնել հավելվածի կառուցմանը, որոնք նույնիսկ 200 կրկնություններով աշխատում են մոտ 5 րոպեում։ Սա թույլ է տալիս արագ արձագանք ստանալ նրանցից և անհրաժեշտության դեպքում փոփոխություններ կատարել և նորից կրկնել ընթացակարգը:

Source: www.habr.com