განხორციელება, მასშტაბი: ვითიბი-ში ავტომატური ტესტების გამოყენების გამოცდილება

ჩვენი განყოფილება ქმნის სრულად ავტომატურ მილსადენებს აპლიკაციების ახალი ვერსიების საწარმოო გარემოში გასაშვებად. რა თქმა უნდა, ეს მოითხოვს ავტომატურ ფუნქციურ ტესტებს. ფრაგმენტის ქვემოთ არის ამბავი იმის შესახებ, თუ როგორ, დაწყებული ლოკალურ მანქანაზე ერთი ძაფიანი ტესტირებით, მივედით Selenoid-ზე გაშვებული მრავალსართულიანი ავტოტესტის ეტაპამდე, build pipeline-ში Allure ანგარიშით GitLab-ის გვერდებზე და საბოლოოდ მივიღეთ მაგარი ავტომატიზაციის ინსტრუმენტი. რომ მომავალ ადამიანებს შეუძლიათ გამოიყენონ გუნდები.

საიდან დავიწყეთ?

ავტოტესტების განსახორციელებლად და მილსადენში მათი ინტეგრირებისთვის, ჩვენ გვჭირდებოდა ავტომატიზაციის ჩარჩო, რომელიც შეიძლება მოქნილად შეიცვალოს ჩვენი საჭიროებების შესაბამისად. იდეალურ შემთხვევაში, მინდოდა მიმეღო ერთი სტანდარტი ავტომატური ტესტირების ძრავისთვის, რომელიც ადაპტირებულია მილსადენში ავტოტესტების ჩასართავად. განხორციელებისთვის ჩვენ ავირჩიეთ შემდეგი ტექნოლოგიები:

• ჯავა,
• მეივენი,
• სელენი,
• კიტრი+JUNIT 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 ჩანგლებზე

იმის გამო, რომ ჩვენ არ ვიზრუნეთ ძაფებზე უსაფრთხო კოდზე საბაზისო ფრეიმურის დანერგვისას, პარალელურად გაშვების ყველაზე აშკარა გზა იყო კიტრი-jvm-პარალელური-პლაგინი მავენისთვის. მოდულის კონფიგურაცია მარტივია, მაგრამ სწორი პარალელური მუშაობისთვის, ავტომატური ტესტები უნდა განხორციელდეს ცალკეულ ბრაუზერებში. არაფერია გასაკეთებელი, მომიწია სელენოიდის გამოყენება.

Selenoid სერვერი ამოქმედდა მანქანაზე 32 ბირთვით და 24 GB ოპერატიული მეხსიერებით. ლიმიტი დაწესდა 48 ბრაუზერზე - 1,5 თემა თითო ბირთვზე და დაახლოებით 400 მბ ოპერატიული მეხსიერება. შედეგად, ტესტის დრო შემცირდა სამი საათიდან 40 წუთამდე. რბენების დაჩქარებამ ხელი შეუწყო სტაბილიზაციის პრობლემის გადაჭრას: ახლა ჩვენ შეგვიძლია სწრაფად გავუშვათ ახალი ავტოტესტი 20-30-ჯერ, სანამ არ დავრწმუნდით, რომ ისინი საიმედოდ მუშაობდნენ.
გადაწყვეტის პირველი ნაკლი იყო მორბენალი რესურსების მაღალი გამოყენება მცირე რაოდენობის პარალელური ძაფებით: 4 ბირთვზე და 8 GB ოპერატიული მეხსიერებაზე, ტესტები სტაბილურად გადიოდა არაუმეტეს 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... –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 GB ოპერატიული მეხსიერება, 12 ძაფი)
 
დადებითი:

• მარტივი დაყენება - თქვენ უბრალოდ უნდა დაამატოთ დანამატი;
• დიდი რაოდენობით ტესტების ერთდროულად შესრულების შესაძლებლობა;
• ტესტის სტაბილიზაციის დაჩქარება 1 ნაბიჯის წყალობით. 

Cons:

• საჭიროა მრავალი OS/კონტეინერი;
• რესურსის მაღალი მოხმარება თითოეული ჩანგლისთვის;
• მოდული მოძველებულია და აღარ არის მხარდაჭერილი. 

როგორ დავძლიოთ არასტაბილურობა 

სატესტო სკამები არ არის იდეალური, ისევე როგორც თავად ავტოტესტები. გასაკვირი არ არის, რომ ჩვენ გვაქვს არაერთი ფხვიერი ტესტი. მოვიდა სამაშველოში maven surefire მოდული, რომელიც გარედან მხარს უჭერს წარუმატებელი ტესტების გადატვირთვას. თქვენ უნდა განაახლოთ მოდულის ვერსია მინიმუმ 2.21-ზე და ჩაწეროთ ერთი ხაზი გადატვირთვების რაოდენობით პომ ფაილში ან არგუმენტად გადასცეთ 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"

დადებითი:

• არ არის საჭირო დროის დაკარგვა არასტაბილური ტესტის გაანალიზებაზე, როდესაც ის ავარიულია;
• ტესტის სკამზე სტაბილურობის პრობლემები შეიძლება შემცირდეს.

Cons:

• მცურავი დეფექტების გამოტოვება შეიძლება;
• გაშვების დრო იზრდება.

პარალელური ტესტები კიტრი 4 ბიბლიოთეკასთან

ტესტების რაოდენობა ყოველდღიურად იზრდებოდა. ჩვენ ისევ ვიფიქრეთ სირბილის დაჩქარებაზე. გარდა ამისა, მინდოდა რაც შეიძლება მეტი ტესტის ინტეგრირება განაცხადის შეკრების მილსადენში. კრიტიკული ფაქტორი იყო ის, რომ მორბენალთა თაობას ძალიან დიდი დრო დასჭირდა Maven მოდულის გამოყენებით პარალელურად გაშვებისას.

იმ დროს კიტრი 4 უკვე გამოშვებული იყო, ამიტომ გადავწყვიტეთ ამ ვერსიისთვის ბირთვის გადაწერა. გამოშვების ნოტებში დაგვპირდნენ პარალელურად გაშვებას ძაფების დონეზე. თეორიულად ასე უნდა ყოფილიყო:

• საგრძნობლად დააჩქაროს ავტოტესტების გაშვება ძაფების რაოდენობის გაზრდით;
• აღმოფხვრა დროის დაკარგვა თითოეული ავტოტესტისთვის მორბენალთა გენერირებისთვის.

მრავალსართულიანი ავტოტესტებისთვის ჩარჩოს ოპტიმიზაცია არც ისე რთული აღმოჩნდა. Cucumber 4 აწარმოებს თითოეულ ინდივიდუალურ ტესტს გამოყოფილ ძაფზე თავიდან ბოლომდე, ამიტომ ზოგიერთი ჩვეულებრივი სტატიკური რამ უბრალოდ გადაკეთდა ThreadLocal ცვლადებად. 
Idea refactoring ინსტრუმენტების გამოყენებით კონვერტაციისას მთავარია შეამოწმოთ ადგილები, სადაც ცვლადი შედარებულია (მაგალითად, ნულის შემოწმება). გარდა ამისა, თქვენ უნდა დაამატოთ 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 GB ოპერატიული მეხსიერება, 24 ძაფი)

დადებითი:

• რესურსების დაბალი მოხმარება;
• მშობლიური მხარდაჭერა კიტრისგან - დამატებითი ხელსაწყოები არ არის საჭირო;
• პროცესორის ბირთვზე 6-ზე მეტი ძაფების გაშვების შესაძლებლობა.

Cons:

• თქვენ უნდა დარწმუნდეთ, რომ კოდი მხარს უჭერს მრავალ ხრახნიან შესრულებას;
• შესვლის ბარიერი იზრდება.

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-ით მისი დანერგვა მარტივია, რითაც მნიშვნელოვნად გაზრდის ერთდროულად გაშვებული თემების რაოდენობას. ტესტების გაშვების ამ მეთოდით, კითხვა ეხება აპარატის მუშაობას სელენოიდთან და სატესტო სკამთან.

პრაქტიკამ აჩვენა, რომ ძაფებზე ავტოტესტების გაშვება საშუალებას გაძლევთ მინიმუმამდე შეამციროთ რესურსების მოხმარება საუკეთესო შესრულებით. როგორც გრაფიკებიდან ჩანს, ძაფების გაორმაგება არ იწვევს მსგავს აჩქარებას შესრულების ტესტებში. თუმცა, ჩვენ შევძელით 2-ზე მეტი ავტომატური ტესტის დამატება აპლიკაციის build-ში, რომელიც 200 განმეორებითაც კი გადის დაახლოებით 5 წუთში. ეს საშუალებას გაძლევთ მიიღოთ სწრაფი გამოხმაურება მათგან და, საჭიროების შემთხვევაში, განახორციელოთ ცვლილებები და კვლავ გაიმეოროთ პროცედურა.

წყარო: www.habr.com