🥇अंमलबजावणी, स्केल: VTB वर ऑटोटेस्ट्स वापरण्याचा अनुभव

आमचा विभाग उत्पादन वातावरणात अनुप्रयोगांच्या नवीन आवृत्त्या लॉन्च करण्यासाठी पूर्णपणे स्वयंचलित पाइपलाइन तयार करतो. अर्थात, यासाठी स्वयंचलित कार्यात्मक चाचण्या आवश्यक आहेत. स्थानिक मशीनवर सिंगल-थ्रेड चाचणीपासून सुरुवात करून, आम्ही गिटलॅब पृष्ठांवर अल्युअर अहवालासह बिल्ड पाइपलाइनमध्ये सेलेनोइडवर चालत असलेल्या मल्टी-थ्रेडेड ऑटोटेस्टच्या टप्प्यापर्यंत पोहोचलो आणि शेवटी एक छान ऑटोमेशन टूल कसे मिळवले याबद्दलची कथा खाली दिली आहे. जेणेकरून भविष्यातील लोक संघ वापरू शकतील.

आम्ही कुठे सुरुवात केली?

ऑटोटेस्ट्स अंमलात आणण्यासाठी आणि त्यांना पाइपलाइनमध्ये समाकलित करण्यासाठी, आम्हाला ऑटोमेशन फ्रेमवर्कची आवश्यकता होती जी आमच्या गरजांनुसार लवचिकपणे बदलली जाऊ शकते. आदर्शपणे, मला ऑटोटेस्टिंग इंजिनसाठी एकच मानक मिळवायचे होते, जे ऑटोटेस्ट्स पाइपलाइनमध्ये एम्बेड करण्यासाठी स्वीकारले गेले. अंमलबजावणीसाठी आम्ही खालील तंत्रज्ञान निवडले:

जावा,
मावेन,
सेलेनियम,
काकडी+जूनिट ४,
मोह,
गिटलॅब.

हा विशिष्ट संच का? जावा ही स्वयंचलित चाचण्यांसाठी सर्वात लोकप्रिय भाषांपैकी एक आहे आणि सर्व कार्यसंघ सदस्य ती बोलतात. सेलेनियम हे स्पष्ट उपाय आहे. काकडी, इतर गोष्टींबरोबरच, मॅन्युअल चाचणीमध्ये गुंतलेल्या विभागांच्या स्वयंचलित चाचण्यांच्या निकालांवर आत्मविश्वास वाढवायचा होता.

सिंगल थ्रेडेड चाचण्या

चाक पुन्हा शोधू नये म्हणून, आम्ही फ्रेमवर्कचा आधार म्हणून GitHub वरील विविध रिपॉझिटरीजमधून घडामोडी घेतल्या आणि त्या स्वतःसाठी अनुकूल केल्या. आम्ही मुख्य लायब्ररीसाठी ऑटोटेस्ट फ्रेमवर्कच्या कोरसह भांडार तयार केले आणि आमच्या कोरवर ऑटोटेस्ट लागू करण्याच्या सुवर्ण उदाहरणासह एक भांडार तयार केला. प्रत्येक संघाला गोल्ड इमेज घ्यायची होती आणि त्यात चाचण्या विकसित करायच्या होत्या, त्या त्यांच्या प्रोजेक्टमध्ये जुळवून घ्यायच्या होत्या. आम्ही ते GitLab-CI बँकेत तैनात केले, ज्यावर आम्ही कॉन्फिगर केले:

प्रत्येक प्रकल्पासाठी सर्व लिखित स्वयंचाचण्यांचे दैनिक धावणे;
बिल्ड पाइपलाइनमध्ये लाँच करते.

सुरुवातीला काही चाचण्या होत्या आणि त्या एकाच प्रवाहात घेतल्या गेल्या. विंडोज रनर गिटलॅबवर सिंगल-थ्रेडेड रनिंग आम्हाला खूप अनुकूल आहे: चाचण्यांनी चाचणी बेंच खूप हलके लोड केले आणि जवळजवळ कोणतीही संसाधने वापरली नाहीत.

कालांतराने, ऑटोटेस्ट्सची संख्या अधिकाधिक असंख्य होत गेली आणि आम्ही त्यांना समांतर चालवण्याचा विचार केला, जेव्हा पूर्ण धावायला सुमारे तीन तास लागायला लागले. इतर समस्या देखील दिसू लागल्या:

आम्ही तपासू शकलो नाही की चाचण्या स्थिर आहेत;
स्थानिक मशीनवर सलग अनेक वेळा चालवल्या गेलेल्या चाचण्या कधीकधी 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>

अल्युअर रिपोर्टचे उदाहरण

चाचण्यांदरम्यान रनर लोड (8 कोर, 8 जीबी रॅम, 1 थ्रेड)

सिंगल-थ्रेडेड चाचण्यांचे फायदे:

सेट अप आणि चालवणे सोपे;
सीआय मधील प्रक्षेपण व्यावहारिकदृष्ट्या स्थानिक प्रक्षेपणांपेक्षा भिन्न नाहीत;
चाचण्यांचा एकमेकांवर परिणाम होत नाही;
धावपटू संसाधनांसाठी किमान आवश्यकता.

सिंगल-थ्रेडेड चाचण्यांचे तोटे:

पूर्ण होण्यासाठी खूप वेळ लागतो;
चाचण्यांचे दीर्घ स्थिरीकरण;
धावपटू संसाधनांचा अकार्यक्षम वापर, अत्यंत कमी वापर.

JVM काट्यांवर चाचण्या

बेस फ्रेमवर्क अंमलात आणताना आम्ही थ्रेड-सेफ कोडची काळजी घेतली नसल्यामुळे, समांतर चालण्याचा सर्वात स्पष्ट मार्ग होता cucumber-jvm-समांतर-प्लगइन मावेन साठी. प्लगइन कॉन्फिगर करणे सोपे आहे, परंतु योग्य समांतर ऑपरेशनसाठी, स्वतंत्र ब्राउझरमध्ये ऑटोटेस्ट्स चालवणे आवश्यक आहे. करण्यासारखे काही नाही, मला सेलेनोइड वापरावे लागले.

सेलेनोइड सर्व्हर 32 कोर आणि 24 GB RAM असलेल्या मशीनवर लॉन्च करण्यात आला. मर्यादा 48 ब्राउझरवर सेट केली गेली - 1,5 थ्रेड प्रति कोर आणि सुमारे 400 MB RAM. परिणामी, चाचणीची वेळ तीन तासांवरून 40 मिनिटांपर्यंत कमी करण्यात आली. धावांचा वेग वाढवल्याने स्थिरीकरण समस्या सोडवण्यास मदत झाली: आता आम्ही 20-30 वेळा नवीन ऑटोटेस्ट्स त्वरीत चालवू शकतो जोपर्यंत आम्हाला खात्री होत नाही की ते विश्वसनीयरित्या धावतील.
सोल्यूशनची पहिली कमतरता म्हणजे कमी संख्येने समांतर थ्रेडसह धावक संसाधनांचा उच्च वापर: 4 कोर आणि 8 जीबी रॅमवर, चाचण्या 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>

अॅल्युअर रिपोर्टचे उदाहरण (सर्वात अस्थिर चाचणी, 4 रन)

चाचण्यांदरम्यान रनर लोड (8 कोर, 8 जीबी रॅम, 12 थ्रेड)

साधक:

सोपे सेटअप - आपल्याला फक्त एक प्लगइन जोडण्याची आवश्यकता आहे;
एकाच वेळी मोठ्या संख्येने चाचण्या करण्याची क्षमता;
चाचणी स्थिरीकरणाचा प्रवेग चरण 1 धन्यवाद.

बाधक

एकाधिक OS/कंटेनर आवश्यक;
प्रत्येक काट्यासाठी उच्च संसाधनांचा वापर;
प्लगइन जुने आहे आणि यापुढे समर्थित नाही.

अस्थिरतेवर मात कशी करावी

चाचणी बेंच आदर्श नसतात, जसे स्वत: चाचणी करतात. आमच्याकडे अनेक फ्लॅकी चाचण्या आहेत हे आश्चर्यकारक नाही. बचावासाठी आले maven खात्रीफायर प्लगइन, जे अयशस्वी चाचण्या रीस्टार्ट करण्यास समर्थन देते. तुम्हाला प्लगइन आवृत्ती किमान 2.21 वर अपडेट करायची आहे आणि pom फाइलमध्ये रीस्टार्टच्या संख्येसह एक ओळ लिहा किंवा मावेनला युक्तिवाद म्हणून पास करा.

ऑटोटेस्ट सेट करण्याचे उदाहरण:

   	
<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 …
एक पर्याय म्हणून, पॉवरशेल स्क्रिप्ट (PS1) साठी Maven पर्याय सेट करा:

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

साधक:

जेव्हा ती क्रॅश होते तेव्हा अस्थिर चाचणीचे विश्लेषण करण्यात वेळ वाया घालवण्याची गरज नाही;
चाचणी खंडपीठाच्या स्थिरतेच्या समस्या कमी केल्या जाऊ शकतात.

बाधक

फ्लोटिंग दोष गमावले जाऊ शकतात;
धावण्याची वेळ वाढते.

काकडी 4 लायब्ररीसह समांतर चाचण्या

चाचण्यांची संख्या दिवसेंदिवस वाढत गेली. आम्ही पुन्हा धावांचा वेग वाढवण्याचा विचार केला. याव्यतिरिक्त, मला ऍप्लिकेशन असेंबली पाइपलाइनमध्ये शक्य तितक्या चाचण्या समाकलित करायच्या होत्या. मावेन प्लगइन वापरून समांतर धावताना धावपटूंच्या पिढीला खूप वेळ लागला हा महत्त्वाचा घटक होता.

त्या वेळी, काकडी 4 आधीच प्रसिद्ध झाली होती, म्हणून आम्ही या आवृत्तीसाठी कर्नल पुन्हा लिहिण्याचा निर्णय घेतला. रिलीझ नोट्समध्ये आम्हाला थ्रेड स्तरावर समांतर लाँच करण्याचे वचन दिले होते. सैद्धांतिकदृष्ट्या हे असावे:

थ्रेड्सची संख्या वाढवून ऑटोटेस्ट्स चालवण्यास लक्षणीय गती द्या;
प्रत्येक ऑटोटेस्टसाठी धावपटू तयार करताना होणारा वेळ कमी करा.

मल्टी-थ्रेडेड ऑटोटेस्ट्ससाठी फ्रेमवर्क ऑप्टिमाइझ करणे इतके अवघड नव्हते. काकडी 4 प्रत्येक वैयक्तिक चाचणी एका समर्पित थ्रेडवर सुरुवातीपासून शेवटपर्यंत चालवते, म्हणून काही सामान्य स्थिर गोष्टी फक्त ThreadLocal व्हेरिएबल्समध्ये रूपांतरित केल्या गेल्या.
आयडिया रिफॅक्टरिंग टूल्स वापरून रूपांतरित करताना मुख्य गोष्ट म्हणजे व्हेरिएबलची तुलना कुठे केली गेली ते तपासणे (उदाहरणार्थ, शून्य तपासणे). याव्यतिरिक्त, तुम्हाला ज्युनिट रनर क्लास एनोटेशनमध्ये अॅल्युअर प्लगइन जोडण्याची आवश्यकता आहे.

ऑटोटेस्ट सेट करण्याचे उदाहरण:

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

अॅल्युअर रिपोर्टचे उदाहरण (सर्वात अस्थिर चाचणी, 5 रन)

चाचण्यांदरम्यान रनर लोड (8 कोर, 8 जीबी रॅम, 24 थ्रेड)

साधक:

कमी संसाधनांचा वापर;
काकडीचे मूळ समर्थन - अतिरिक्त साधनांची आवश्यकता नाही;
प्रत्येक प्रोसेसर कोरवर 6 पेक्षा जास्त थ्रेड चालवण्याची क्षमता.

बाधक

कोड मल्टी-थ्रेडेड एक्झिक्यूशनला सपोर्ट करतो याची खात्री करणे आवश्यक आहे;
प्रवेश थ्रेशोल्ड वाढते.

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

परिणाम काय आहे

तर, जर तुम्ही काकडी ऑटोटेस्ट फ्रेमवर्कमध्ये तुम्हाला थ्रेड सेफ कोडची गरज आहे का याचा विचार करत असाल, तर आता उत्तर स्पष्ट आहे - काकडी 4 सह ते अंमलात आणणे सोपे आहे, ज्यामुळे एकाच वेळी लॉन्च केलेल्या थ्रेड्सची संख्या लक्षणीय वाढते. चाचण्या चालवण्याच्या या पद्धतीसह, प्रश्न आता सेलेनोइड आणि चाचणी खंडपीठासह मशीनच्या कार्यक्षमतेबद्दल बनतो.

सरावाने दर्शविले आहे की थ्रेड्सवर ऑटोटेस्ट्स चालवल्याने तुम्हाला सर्वोत्तम कामगिरीसह संसाधनाचा वापर कमीतकमी कमी करता येतो. आलेखांवरून पाहिले जाऊ शकते, थ्रेड्स दुप्पट केल्याने कामगिरी चाचण्यांमध्ये समान प्रवेग होत नाही. तथापि, आम्ही ॲप्लिकेशन बिल्डमध्ये 2 हून अधिक स्वयंचलित चाचण्या जोडण्यात सक्षम होतो, जे 200 रन करूनही सुमारे 5 मिनिटांत चालतात. हे तुम्हाला त्यांच्याकडून द्रुत अभिप्राय प्राप्त करण्यास अनुमती देते आणि आवश्यक असल्यास, बदल करा आणि प्रक्रिया पुन्हा करा.

स्त्रोत: www.habr.com

अंमलबजावणी, स्केल: VTB वर स्वयंचलित चाचण्या वापरण्याचा अनुभव

आम्ही कुठे सुरुवात केली?

सिंगल थ्रेडेड चाचण्या

JVM काट्यांवर चाचण्या

अस्थिरतेवर मात कशी करावी

काकडी 4 लायब्ररीसह समांतर चाचण्या

GitLab पृष्ठांवर मोहक अहवाल

परिणाम काय आहे

एक टिप्पणी जोडा Отменить ответ