ProHoster > Blogs > Administrācija > Ieviest, mērogot: pieredze automatizēto testu izmantoÅ”anā VTB

Ieviest, mērogot: pieredze automatizēto testu izmantoÅ”anā VTB

MÅ«su nodaļa veido pilnÄ«bā automātiskus cauruļvadus jaunu lietojumprogrammu versiju palaiÅ”anai ražoÅ”anas vidē. Protams, tas prasa automatizētas funkcionālās pārbaudes. Zem griezuma ir stāsts par to, kā, sākot ar viena pavediena testÄ“Å”anu vietējā datorā, mēs sasniedzām vairāku pavedienu automātisko testÄ“Å”anu, kas darbojās Selenoid bÅ«vÄ“Å”anas konveijerā ar Allure ziņojumu GitLab lapās un galu galā ieguvām lielisku automatizācijas rÄ«ku. ka nākotnes cilvēki var izmantot komandas.

Ieviest, mērogot: pieredze automatizēto testu izmantoÅ”anā VTB

Kur mēs sākām?

Lai ieviestu automātiskos testus un integrētu tos cauruļvadā, mums bija nepiecieÅ”ama automatizācijas sistēma, kuru varētu elastÄ«gi mainÄ«t atbilstoÅ”i mÅ«su vajadzÄ«bām. Ideālā gadÄ«jumā es gribēju iegÅ«t vienotu automātiskās testÄ“Å”anas dzinēja standartu, kas pielāgots automātisko testu iegulÅ”anai cauruļvadā. IevieÅ”anai mēs izvēlējāmies Ŕādas tehnoloÄ£ijas:

  • Java,
  • Maven,
  • selēns,
  • GurÄ·is+JUNIT 4,
  • PievilcÄ«ba,
  • GitLab.

Ieviest, mērogot: pieredze automatizēto testu izmantoÅ”anā VTB

Kāpēc Å”is konkrētais komplekts? Java ir viena no populārākajām automātisko testu valodām, un tajā runā visi komandas locekļi. Selēns ir acÄ«mredzams risinājums. Cita starpā gurÄ·im bija jāpalielina manuālajā testÄ“Å”anā iesaistÄ«to departamentu uzticÄ«ba automatizēto testu rezultātiem.

Viena vītnes testi

Lai neizgudrotu riteni no jauna, mēs izmantojām dažādu GitHub krātuvju izstrādi kā ietvara pamatu un pielāgojām tos sev. Mēs izveidojām galvenās bibliotēkas repozitoriju ar automātiskās pārbaudes sistēmas kodolu un repozitoriju ar zelta piemēru automātisko testu ievieÅ”anai mÅ«su kodolā. Katrai komandai bija jāņem Zelta attēls un jāizstrādā tajā testi, pielāgojot to savam projektam. Mēs to izvietojām GitLab-CI bankā, kurā konfigurējām:

  • katra projekta visu rakstisko automātisko testu ikdienas palaiÅ”ana;
  • tiek palaists bÅ«vniecÄ«bas cauruļvadā.

Sākumā testu bija maz, un tie tika veikti vienā plūsmā. Viena pavediena darbība Windows palaidējā GitLab mums bija diezgan piemērota: testi ļoti viegli noslogoja testa stendu un gandrīz neizmantoja nekādus resursus.

Laika gaitā autotestu skaits kļuva arvien kuplāks, un mēs domājām par to palaiÅ”anu paralēli, kad pilnais skrējiens sāka aizņemt apmēram trÄ«s stundas. ParādÄ«jās arÄ« citas problēmas:

  • mēs nevarējām pārbaudÄ«t, vai testi bija stabili;
  • testi, kas tika izpildÄ«ti vairākas reizes pēc kārtas vietējā maŔīnā, dažkārt avarēja CI.

Automātisko testu iestatÄ«Å”anas piemērs:

<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>

 Ieviest, mērogot: pieredze automatizēto testu izmantoÅ”anā VTB
Allure ziņojuma piemērs

 Ieviest, mērogot: pieredze automatizēto testu izmantoÅ”anā VTB
Skrējēja slodze testu laikā (8 kodoli, 8 GB RAM, 1 pavediens)
 
Viena vītnes testu priekŔrocības:

  • viegli uzstādÄ«t un palaist;
  • palaiÅ”ana CI praktiski neatŔķiras no vietējām palaiÅ”anām;
  • testi viens otru neietekmē;
  • minimālās prasÄ«bas skrējēja resursiem.

Viena vītnes testu trūkumi:

  • aizpildÄ«Å”ana aizņem ļoti ilgu laiku;
  • ilgstoÅ”a testu stabilizācija;
  • neefektÄ«va skrējēja resursu izmantoÅ”ana, ārkārtÄ«gi zema izmantoÅ”ana.

Testi uz JVM dakŔām

Tā kā, ievieÅ”ot pamata sistēmu, mēs nerÅ«pējāmies par pavedienu droÅ”u kodu, visredzamākais veids, kā darboties paralēli, bija cucumber-jvm-parallel-plugin Mavenam. Spraudnis ir viegli konfigurējams, taču pareizai paralēlai darbÄ«bai automātiskās pārbaudes ir jāpalaiž atseviŔķās pārlÅ«kprogrammās. Neko darÄ«t, nācās lietot Selenoid.

Selenoid serveris tika palaists maŔīnā ar 32 kodoliem un 24 GB RAM. Ierobežojums tika noteikts 48 pārlÅ«kprogrammās ā€“ 1,5 pavedieni uz kodolu un aptuveni 400 MB RAM. Rezultātā pārbaudes laiks tika samazināts no trim stundām lÄ«dz 40 minÅ«tēm. DarbÄ«bu paātrināŔana palÄ«dzēja atrisināt stabilizācijas problēmu: tagad mēs varējām ātri palaist jaunus automātiskos testus 20ā€“30 reizes, lÄ«dz bijām pārliecināti, ka tie darbojas uzticami.
Pirmais risinājuma trÅ«kums bija augstā skrējēja resursu izmantoÅ”ana ar nelielu skaitu paralēlu pavedienu: uz 4 kodoliem un 8 GB RAM testi darbojās stabili ar ne vairāk kā 6 pavedieniem. Otrs trÅ«kums: spraudnis Ä£enerē skrējēju klases katram scenārijam neatkarÄ«gi no tā, cik no tām tiek palaists.

SvarÄ«gi! Nenododiet mainÄ«go ar tagiem uz argLine, piemēram, Ŕādi:

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

Ja jÅ«s Ŕādā veidā nodosit tagu, spraudnis Ä£enerēs skrējējus visiem testiem, tas ir, tas mēģinās izpildÄ«t visus testus, izlaižot tos uzreiz pēc palaiÅ”anas un izveidojot daudzus JVM dakÅ”as.

Ir pareizi iemest mainÄ«go ar tagu tagi spraudņa iestatÄ«jumos, skatiet piemēru zemāk. Citām mÅ«su pārbaudÄ«tajām metodēm ir problēmas ar Allure spraudņa pievienoÅ”anu.

Darbības laika piemērs 6 īsiem testiem ar nepareiziem iestatījumiem:

[INFO] Total time: 03:17 min

Testa izpildes laika piemērs, ja tagu tieÅ”i pārsÅ«tāt uz mvn... ā€“DgurÄ·is.opcijas:

[INFO] Total time: 44.467 s

Automātisko testu iestatÄ«Å”anas piemērs:

<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>

Ieviest, mērogot: pieredze automatizēto testu izmantoÅ”anā VTB
Allure pārskata piemērs (nestabilākais tests, 4 atkārtojumi)

Ieviest, mērogot: pieredze automatizēto testu izmantoÅ”anā VTBSkrējēja slodze testu laikā (8 kodoli, 8 GB RAM, 12 pavedieni)
 
Plusi:

  • vienkārÅ”a iestatÄ«Å”ana - jums vienkārÅ”i jāpievieno spraudnis;
  • spēja vienlaikus veikt lielu skaitu testu;
  • testa stabilizācijas paātrinājums, pateicoties 1. darbÄ«bai. 

MÄ«nusi:

  • NepiecieÅ”amas vairākas OS/konteineri;
  • liels resursu patēriņŔ katrai dakÅ”ai;
  • Spraudnis ir novecojis un vairs netiek atbalstÄ«ts. 

Kā pārvarēt nestabilitāti 

Testu stendi nav ideāli, tāpat kā paÅ”i autotesti. Tas nav pārsteidzoÅ”i, ka mums ir vairāki vāji testi. Nāca palÄ«gā spraudnis maven surefire, kas atbalsta nesekmÄ«gu testu restartÄ“Å”anu. Jums ir jāatjaunina spraudņa versija vismaz uz 2.21 un jāieraksta viena rindiņa ar restartÄ“Å”anas reižu skaitu pom failā vai jānodod kā arguments Maven.

Automātisko testu iestatÄ«Å”anas piemērs:

   	
<plugin>
        	
<groupId>org.apache.maven.plugins</groupId>
  	
      <artifactId>maven-surefire-plugin</artifactId>
        	
<version>2.21.0</version>
        	
<configuration>
           	
ā€¦.
            	
<rerunFailingTestsCount>2</rerunFailingTestsCount>
            	
ā€¦.
            	
</configuration>
</plugin>

Vai startÄ“Å”anas laikā: mvn ā€¦ -Dsurefire.rerunFailingTestsCount=2 ā€¦
Kā opciju iestatiet Maven opcijas PowerShell skriptam (PS1): 

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

Plusi:

  • nav jātērē laiks, analizējot nestabilu testu, kad tas avarē;
  • var mazināt testa stenda stabilitātes problēmas.

MÄ«nusi:

  • peldoÅ”os defektus var palaist garām;
  • darbÄ«bas laiks palielinās.

Paralēli testi ar gurķu 4 bibliotēku

Pārbaužu skaits pieauga ar katru dienu. Atkal domājām par skrējienu paātrināŔanu. Turklāt es vēlējos lietojumprogrammu montāžas konveijerā integrēt pēc iespējas vairāk testu. Kritiskais faktors bija tas, ka skrējēju Ä£enerÄ“Å”ana aizņēma pārāk ilgu laiku, skrienot paralēli, izmantojot spraudni Maven.

Tajā laikā Cucumber 4 jau bija izlaists, tāpēc mēs nolēmām pārrakstÄ«t kodolu Å”ai versijai. Izlaiduma piezÄ«mēs mums tika solÄ«ts paralēla palaiÅ”ana pavedienu lÄ«menÄ«. Teorētiski tam vajadzēja bÅ«t:

  • ievērojami paātrināt automātisko testu darbÄ«bu, palielinot pavedienu skaitu;
  • novērst laika zudumu, Ä£enerējot skrējējus katram automātiskajam testam.

Vairāku vÄ«tņu automātisko testu sistēmas optimizÄ“Å”ana izrādÄ«jās ne tik sarežģīta. Cucumber 4 katru atseviŔķo testu veic Ä«paŔā pavedienā no sākuma lÄ«dz beigām, tāpēc dažas parastās statiskās lietas tika vienkārÅ”i pārveidotas par ThreadLocal mainÄ«gajiem. 
Galvenais, veicot konvertÄ“Å”anu, izmantojot Idea refaktoringa rÄ«kus, ir pārbaudÄ«t vietas, kur tika salÄ«dzināts mainÄ«gais (piemēram, pārbaudot, vai nav nulles). Turklāt jums ir jāpievieno Allure spraudnis Junit Runner klases anotācijai.

Automātisko testu iestatÄ«Å”anas piemērs:

 
<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>

Ieviest, mērogot: pieredze automatizēto testu izmantoÅ”anā VTBAllure pārskata piemērs (nestabilākais tests, 5 atkārtojumi)

Ieviest, mērogot: pieredze automatizēto testu izmantoÅ”anā VTBSkrējēja slodze testu laikā (8 kodoli, 8 GB RAM, 24 pavedieni)

Plusi:

  • zems resursu patēriņŔ;
  • vietējais atbalsts no Cucumber - nav nepiecieÅ”ami papildu rÄ«ki;
  • spēja darbināt vairāk nekā 6 pavedienus vienā procesora kodolā.

MÄ«nusi:

  • jums jāpārliecinās, ka kods atbalsta vairāku pavedienu izpildi;
  • ieejas slieksnis palielinās.

Allure ziņojumi GitLab lapās

Pēc vairāku pavedienu izpildes ievieÅ”anas mēs sākām tērēt daudz vairāk laika pārskatu analÄ«zei. Toreiz mums bija jāaugÅ”upielādē katrs pārskats kā artefakts GitLab, pēc tam tas jālejupielādē un jāizpako. Tas nav Ä«paÅ”i ērti un aizņem daudz laika. Un, ja kāds cits vēlas skatÄ«t pārskatu pats, tad viņam bÅ«s jāveic tās paÅ”as darbÄ«bas. Gribējām ātrāk saņemt atsauksmes, un atradām risinājumu ā€“ GitLab lapas. Å Ä« ir iebÅ«vēta funkcija, kas ir pieejama visās jaunākajās GitLab versijās. Ä»auj izvietot statiskas vietnes serverÄ« un piekļūt tām, izmantojot tieÅ”u saiti.

Visi Allure ziņojumu ekrānuzņēmumi tika uzņemti GitLab lapās. Skripts pārskata izvietoÅ”anai GitLab lapās - programmā Windows PowerShell (pirms tam jums ir jāpalaiž automātiskās pārbaudes):

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

Kā rezultātā 

Tātad, ja jÅ«s domājāt par to, vai jums ir nepiecieÅ”ams Thread droÅ”s kods Cucumber automātiskās pārbaudes ietvaros, tagad atbilde ir acÄ«mredzama - ar Cucumber 4 to ir viegli ieviest, tādējādi ievērojami palielinot vienlaikus palaisto pavedienu skaitu. Izmantojot Å”o testu veikÅ”anas metodi, tagad rodas jautājums par maŔīnas ar selenoÄ«du un testa stenda veiktspēju.

Prakse ir parādÄ«jusi, ka automātisko testu veikÅ”ana pavedieniem ļauj samazināt resursu patēriņu lÄ«dz minimumam, nodroÅ”inot vislabāko veiktspēju. Kā redzams no grafikiem, pavedienu dubultoÅ”ana neizraisa lÄ«dzÄ«gu paātrinājumu veiktspējas testos. Tomēr mēs varējām lietojumprogrammas bÅ«vējumam pievienot vairāk nekā 2 automatizētus testus, kas pat ar 200 atkārtotām palaiÅ”anas reizēm tiek izpildÄ«ti aptuveni 5 minÅ«tēs. Tas ļauj ātri saņemt atsauksmes no viņiem un, ja nepiecieÅ”ams, veikt izmaiņas un atkārtot procedÅ«ru vēlreiz.

Avots: www.habr.com

Pievieno komentāru