कार्यान्वयन, पैमाना: वीटीबी में स्वचालित परीक्षणों का उपयोग करने का अनुभव

हमारा प्रभाग उत्पादन परिवेश में अनुप्रयोगों के नए संस्करण लॉन्च करने के लिए पूरी तरह से स्वचालित पाइपलाइन बनाता है। बेशक, इसके लिए स्वचालित कार्यात्मक परीक्षणों की आवश्यकता होती है। कट के नीचे एक कहानी है कि कैसे, एक स्थानीय मशीन पर सिंगल-थ्रेड परीक्षण से शुरू करके, हम GitLab पेजों पर एक एल्योर रिपोर्ट के साथ बिल्ड पाइपलाइन में सेलेनॉइड पर चलने वाले मल्टी-थ्रेडेड ऑटोटेस्ट के बिंदु तक पहुंचे और अंततः एक अच्छा ऑटोमेशन टूल प्राप्त किया। भविष्य में लोग टीमों का उपयोग कर सकते हैं।

हमने कहां से शुरुआत की?

ऑटोटेस्ट को लागू करने और उन्हें पाइपलाइन में एकीकृत करने के लिए, हमें एक स्वचालन ढांचे की आवश्यकता थी जिसे हमारी आवश्यकताओं के अनुरूप लचीले ढंग से बदला जा सके। आदर्श रूप से, मैं ऑटोटेस्टिंग इंजन के लिए एक एकल मानक प्राप्त करना चाहता था, जो पाइपलाइन में ऑटोटेस्ट को एम्बेड करने के लिए अनुकूलित हो। कार्यान्वयन के लिए हमने निम्नलिखित तकनीकों को चुना:

• जावा,
• मावेन,
• सेलेनियम,
• खीरा+जूनिट 4,
• लुभाना,
• GitLab।

यह विशेष सेट क्यों? स्वचालित परीक्षणों के लिए जावा सबसे लोकप्रिय भाषाओं में से एक है, और टीम के सभी सदस्य इसे बोलते हैं। सेलेनियम स्पष्ट समाधान है. ककड़ी, अन्य बातों के अलावा, मैन्युअल परीक्षण में शामिल विभागों की ओर से स्वचालित परीक्षणों के परिणामों में विश्वास बढ़ाने वाली थी।

एकल थ्रेडेड परीक्षण

पहिए का दोबारा आविष्कार न करने के लिए, हमने गिटहब पर विभिन्न रिपॉजिटरी से विकास को ढांचे के आधार के रूप में लिया और उन्हें अपने लिए अनुकूलित किया। हमने मुख्य लाइब्रेरी के लिए ऑटोटेस्ट फ्रेमवर्क के मूल के साथ एक रिपॉजिटरी और हमारे कोर पर ऑटोटेस्ट को लागू करने के स्वर्ण उदाहरण के साथ एक रिपॉजिटरी बनाई। प्रत्येक टीम को सोने की छवि लेनी थी और उसमें परीक्षण विकसित करना था, इसे अपने प्रोजेक्ट में अनुकूलित करना था। हमने इसे GitLab-CI बैंक में तैनात किया, जिस पर हमने कॉन्फ़िगर किया:

• प्रत्येक प्रोजेक्ट के लिए सभी लिखित ऑटोटेस्ट का दैनिक संचालन;
• बिल्ड पाइपलाइन में लॉन्च किया गया।

पहले तो कुछ परीक्षण हुए और उन्हें एक ही धारा में किया गया। विंडोज़ रनर GitLab पर सिंगल-थ्रेडेड रनिंग हमारे लिए काफी उपयुक्त रही: परीक्षणों ने परीक्षण बेंच को बहुत हल्के ढंग से लोड किया और लगभग कोई संसाधन उपयोग नहीं किया।

समय के साथ, ऑटोटेस्ट की संख्या अधिक से अधिक हो गई, और हमने उन्हें समानांतर में चलाने के बारे में सोचा, जब एक पूर्ण परीक्षण में लगभग तीन घंटे लगने लगे। अन्य समस्याएं भी आईं सामने:

• हम यह सत्यापित नहीं कर सके कि परीक्षण स्थिर थे;
• स्थानीय मशीन पर लगातार कई बार चलाए गए परीक्षण कभी-कभी सीआई में क्रैश हो जाते थे।

ऑटोटेस्ट स्थापित करने का उदाहरण:

<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 थ्रेड)
 
एकल-थ्रेडेड परीक्षणों के लाभ:

• स्थापित करना और चलाना आसान;
• सीआई में लॉन्च व्यावहारिक रूप से स्थानीय लॉन्च से अलग नहीं हैं;
• परीक्षण एक दूसरे को प्रभावित नहीं करते;
• धावक संसाधनों के लिए न्यूनतम आवश्यकताएँ।

एकल-थ्रेडेड परीक्षणों के नुकसान:

• पूरा करने में बहुत लंबा समय लगेगा;
• परीक्षणों का दीर्घकालिक स्थिरीकरण;
• धावक संसाधनों का अकुशल उपयोग, अत्यंत कम उपयोग।

जेवीएम फोर्क्स पर परीक्षण

चूंकि हमने बेस फ्रेमवर्क को लागू करते समय थ्रेड-सुरक्षित कोड का ध्यान नहीं रखा था, इसलिए समानांतर में चलाने का सबसे स्पष्ट तरीका था ककड़ी-जेवीएम-समानांतर-प्लगइन मावेन के लिए. प्लगइन को कॉन्फ़िगर करना आसान है, लेकिन सही समानांतर संचालन के लिए, ऑटोटेस्ट को अलग ब्राउज़र में चलाया जाना चाहिए। करने को कुछ नहीं है, मुझे सेलेनॉइड का उपयोग करना पड़ा।

सेलेनॉइड सर्वर को 32 कोर और 24 जीबी रैम वाली मशीन पर लॉन्च किया गया था। सीमा 48 ब्राउज़रों पर निर्धारित की गई थी - 1,5 थ्रेड प्रति कोर और लगभग 400 एमबी रैम। परिणामस्वरूप, परीक्षण का समय तीन घंटे से घटाकर 40 मिनट कर दिया गया। रनों को तेज़ करने से स्थिरीकरण समस्या को हल करने में मदद मिली: अब हम 20-30 बार नए ऑटोटेस्ट चला सकते थे जब तक कि हमें यकीन नहीं हो गया कि वे विश्वसनीय रूप से चल रहे हैं।
समाधान का पहला दोष समानांतर धागों की कम संख्या के साथ धावक संसाधनों का उच्च उपयोग था: 4 कोर और 8 जीबी रैम पर, परीक्षण 6 से अधिक धागों में स्थिर रूप से नहीं चले। दूसरा नुकसान: प्लगइन प्रत्येक परिदृश्य के लिए रनर क्लासेस उत्पन्न करता है, चाहे उनमें से कितने भी लॉन्च किए गए हों।

महत्वपूर्ण! टैग के साथ एक वेरिएबल पास न करें argLine, उदाहरण के लिए, इस तरह:

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

यदि आप इस तरह से टैग पास करते हैं, तो प्लगइन सभी परीक्षणों के लिए रनर उत्पन्न करेगा, यानी, यह सभी परीक्षणों को चलाने का प्रयास करेगा, लॉन्च के तुरंत बाद उन्हें छोड़ देगा और कई जेवीएम फोर्क बनाएगा।

किसी वैरिएबल को टैग के साथ फेंकना सही है टैग प्लगइन सेटिंग्स में, नीचे उदाहरण देखें। हमारे द्वारा परीक्षण किए गए अन्य तरीकों में एल्योर प्लगइन को कनेक्ट करने में समस्याएँ हैं।

गलत सेटिंग्स के साथ 6 लघु परीक्षणों के लिए चलने के समय का उदाहरण:

[INFO] Total time: 03:17 min

यदि आप टैग को सीधे स्थानांतरित करते हैं तो परीक्षण चलाने के समय का उदाहरण एमवीएन... -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 के लिए धन्यवाद परीक्षण स्थिरीकरण का त्वरण। 

विपक्ष:

• एकाधिक ओएस/कंटेनर की आवश्यकता;
• प्रत्येक कांटे के लिए उच्च संसाधन खपत;
• प्लगइन पुराना हो चुका है और अब समर्थित नहीं है। 

अस्थिरता को कैसे दूर करें 

टेस्ट बेंच आदर्श नहीं हैं, बिल्कुल ऑटोटेस्ट की तरह। इसमें कोई आश्चर्य की बात नहीं है कि हमारे पास कई कमजोर परीक्षण हैं। बचाव के लिए आया मेवेन अचूक प्लगइन, जो बॉक्स से बाहर विफल परीक्षणों को पुनः आरंभ करने का समर्थन करता है। आपको प्लगइन संस्करण को कम से कम 2.21 में अपडेट करना होगा और पोम फ़ाइल में पुनरारंभ की संख्या के साथ एक पंक्ति लिखनी होगी या इसे मेवेन के तर्क के रूप में पास करना होगा।

ऑटोटेस्ट स्थापित करने का उदाहरण:

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

या स्टार्टअप पर: एमवीएन … -Dsurefire.rerunFailingTestsCount=2 …
एक विकल्प के रूप में, पॉवरशेल स्क्रिप्ट (PS1) के लिए मावेन विकल्प सेट करें:

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

पेशेवरों:

• किसी अस्थिर परीक्षण के क्रैश होने पर उसका विश्लेषण करने में समय बर्बाद करने की कोई आवश्यकता नहीं है;
• परीक्षण बेंच स्थिरता समस्याओं को कम किया जा सकता है।

विपक्ष:

• फ़्लोटिंग दोष छूट सकते हैं;
• रन टाइम बढ़ जाता है.

ककड़ी 4 लाइब्रेरी के साथ समानांतर परीक्षण

हर दिन परीक्षणों की संख्या बढ़ती गई। हमने फिर से रनों की गति बढ़ाने के बारे में सोचा।' इसके अलावा, मैं एप्लिकेशन असेंबली पाइपलाइन में यथासंभव अधिक से अधिक परीक्षणों को एकीकृत करना चाहता था। महत्वपूर्ण कारक यह था कि मेवेन प्लगइन का उपयोग करके समानांतर में दौड़ने पर धावकों की पीढ़ी को बहुत अधिक समय लगा।

उस समय, ककड़ी 4 पहले ही जारी किया जा चुका था, इसलिए हमने इस संस्करण के लिए कर्नेल को फिर से लिखने का निर्णय लिया। रिलीज़ नोट्स में हमें थ्रेड स्तर पर समानांतर लॉन्च का वादा किया गया था। सैद्धांतिक रूप से यह होना चाहिए था:

• थ्रेड्स की संख्या बढ़ाकर ऑटोटेस्ट चलाने में काफी तेजी लाएँ;
• प्रत्येक ऑटोटेस्ट के लिए रनर तैयार करने में लगने वाले समय की हानि को समाप्त करें।

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

ऑटोटेस्ट स्थापित करने का उदाहरण:

 
<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 पेज। यह एक अंतर्निहित सुविधा है जो GitLab के सभी हाल के संस्करणों में बॉक्स से बाहर उपलब्ध है। आपको अपने सर्वर पर स्थिर साइटों को तैनात करने और सीधे लिंक के माध्यम से उन तक पहुंचने की अनुमति देता है।

एल्योर रिपोर्ट के सभी स्क्रीनशॉट 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