🥇 कार्यान्वयन, मापन: VTB मा अटोटेस्ट प्रयोग गर्ने अनुभव

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

हामीले कहाँ सुरु गर्यौं?

स्वचालित परीक्षणहरू लागू गर्न र तिनीहरूलाई पाइपलाइनमा एकीकृत गर्न, हामीलाई हाम्रो आवश्यकताहरू अनुरूप लचिलो रूपमा परिवर्तन गर्न सकिने स्वचालन ढाँचा आवश्यक थियो। आदर्श रूपमा, म स्वत: परीक्षण इन्जिनको लागि एकल मानक प्राप्त गर्न चाहन्थें, पाइपलाइनमा स्वत: परीक्षणहरू इम्बेड गर्नका लागि अनुकूलित। कार्यान्वयनको लागि हामीले निम्न प्रविधिहरू छनौट गरेका छौं:

जाभा,
मावेन,
सेलेनियम,
काकडी + JUNIT 4,
लोभ,
GitLab

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

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

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

प्रत्येक परियोजनाको लागि सबै लिखित स्वत: परीक्षणहरूको दैनिक रन;
निर्माण पाइपलाइनमा प्रक्षेपण।

सुरुमा त्यहाँ थोरै परीक्षणहरू थिए, र तिनीहरू एउटै स्ट्रिममा गरिएका थिए। विन्डोज रनर 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>

लोभ रिपोर्ट उदाहरण

परीक्षणको समयमा रनर लोड (8 कोर, 8 GB RAM, 1 थ्रेड)

एकल-थ्रेडेड परीक्षणका फाइदाहरू:

सेट अप र चलाउन सजिलो;
CI मा प्रक्षेपणहरू व्यावहारिक रूपमा स्थानीय प्रक्षेपणहरू भन्दा फरक छैनन्;
परीक्षणहरूले एकअर्कालाई असर गर्दैन;
धावक स्रोतहरूको लागि न्यूनतम आवश्यकताहरू।

एकल-थ्रेडेड परीक्षणका बेफाइदाहरू:

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

JVM फोर्कहरूमा परीक्षणहरू

आधार फ्रेमवर्क लागू गर्दा हामीले थ्रेड-सेफ कोडको ख्याल नगरेको हुनाले, समानान्तरमा चल्ने सबैभन्दा स्पष्ट तरिका थियो। cucumber-jvm-parallel-plugin Maven को लागी। प्लगइन कन्फिगर गर्न सजिलो छ, तर सही समानान्तर सञ्चालनको लागि, स्वत: परीक्षणहरू अलग ब्राउजरहरूमा चलाउनु पर्छ। त्यहाँ गर्न केहि छैन, मैले सेलेनोइड प्रयोग गर्नुपर्‍यो।

सेलेनोइड सर्भर ३२ कोर र २४ जीबी र्याम भएको मेसिनमा सुरु गरिएको थियो। सीमा 32 ब्राउजरहरूमा सेट गरिएको थियो - 24 थ्रेड प्रति कोर र लगभग 48 MB RAM। फलस्वरूप, परीक्षण समय तीन घण्टाबाट 1,5 मिनेटमा घटाइयो। दौडको गति बढाउनाले स्थिरीकरण समस्या समाधान गर्न मद्दत गर्‍यो: अब हामी चाँडै २०-३० पटक नयाँ अटोटेस्टहरू चलाउन सक्छौं जबसम्म हामी तिनीहरू भरपर्दो रूपमा दौडिएनन् भन्ने निश्चित हुँदैनौं।
समाधानको पहिलो कमजोरी समानान्तर थ्रेडहरूको सानो संख्याको साथ धावक स्रोतहरूको उच्च उपयोग थियो: 4 कोर र 8 GB RAM मा, परीक्षणहरूले 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 GB RAM, 12 थ्रेडहरू)

प्रो:

सजिलो सेटअप - तपाईलाई प्लगइन थप्न आवश्यक छ;
एकै साथ ठूलो संख्यामा परीक्षण गर्ने क्षमता;
चरण 1 को लागि धन्यवाद परीक्षण स्थिरीकरण को गति।

Cons:

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

अस्थिरता कसरी हटाउने

परीक्षण बेन्चहरू आदर्श होइनन्, जस्तै आफैले परीक्षण गर्दछ। यो अचम्मको कुरा होइन कि हामीसँग धेरै फ्ल्याकी परीक्षणहरू छन्। उद्धारमा आए maven surefire प्लगइन, जसले असफल परीक्षणहरू पुन: सुरु गर्न समर्थन गर्दछ। तपाईंले प्लगइन संस्करणलाई कम्तिमा 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 …
विकल्पको रूपमा, PowerShell स्क्रिप्ट (PS1) को लागि Maven विकल्पहरू सेट गर्नुहोस्:

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

प्रो:

यो दुर्घटना हुँदा एक अस्थिर परीक्षण विश्लेषण समय बर्बाद गर्न आवश्यक छैन;
परीक्षण बेंच स्थिरता समस्याहरू कम गर्न सकिन्छ।

Cons:

फ्लोटिंग दोषहरू छुटाउन सकिन्छ;
चल्ने समय बढ्छ।

Cucumber 4 पुस्तकालय संग समानान्तर परीक्षण

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

त्यस समयमा, ककम्बर 4 पहिले नै जारी गरिएको थियो, त्यसैले हामीले यो संस्करणको लागि कर्नेल पुन: लेख्ने निर्णय गर्यौं। रिलीज नोटहरूमा हामीलाई थ्रेड स्तरमा समानान्तर प्रक्षेपण गर्ने वाचा गरिएको थियो। सैद्धान्तिक रूपमा यो हुनुपर्छ:

थ्रेडहरूको संख्या बढाएर अटोटेस्टहरूको चलिरहेको गतिलाई उल्लेखनीय रूपमा बढाउनुहोस्;
प्रत्येक स्वत: परीक्षणको लागि धावकहरू उत्पन्न गर्नमा समयको हानि हटाउनुहोस्।

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

स्वत: परीक्षणहरू सेटअप गर्ने उदाहरण:

 
<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 GB RAM, 24 थ्रेडहरू)

प्रो:

कम स्रोत खपत;
काकडीबाट नेटिभ समर्थन - कुनै अतिरिक्त उपकरणहरू आवश्यक पर्दैन;
प्रति प्रोसेसर कोर 6 भन्दा बढी थ्रेडहरू चलाउने क्षमता।

Cons:

तपाईले यो सुनिश्चित गर्न आवश्यक छ कि कोडले बहु-थ्रेडेड कार्यान्वयनलाई समर्थन गर्दछ;
प्रवेश थ्रेसहोल्ड बढ्छ।

GitLab पृष्ठहरूमा एलुर रिपोर्टहरू

बहु-थ्रेडेड कार्यान्वयन पेश गरेपछि, हामीले रिपोर्टहरू विश्लेषण गर्न धेरै समय खर्च गर्न थाल्यौं। त्यस समयमा, हामीले प्रत्येक रिपोर्टलाई आर्टिफ्याक्टको रूपमा GitLab मा अपलोड गर्नुपर्ने थियो, त्यसपछि यसलाई डाउनलोड गर्नुहोस् र यसलाई अनप्याक गर्नुहोस्। यो धेरै सुविधाजनक छैन र धेरै समय लाग्छ। र यदि अरू कसैले आफ्नो लागि प्रतिवेदन हेर्न चाहन्छ भने, त्यसपछि तिनीहरूले समान कार्यहरू गर्न आवश्यक हुनेछ। हामी छिटो प्रतिक्रिया प्राप्त गर्न चाहन्थ्यौं, र हामीले एक समाधान फेला पार्‍यौं - GitLab पृष्ठहरू। यो एक निर्मित सुविधा हो जुन GitLab को सबै भर्खरका संस्करणहरूमा बक्स बाहिर उपलब्ध छ। तपाइँलाई तपाइँको सर्भरमा स्थिर साइटहरू डिप्लोय गर्न र प्रत्यक्ष लिङ्क मार्फत पहुँच गर्न अनुमति दिन्छ।

Allure रिपोर्टहरूको सबै स्क्रिनसट GitLab पृष्ठहरूमा लिइएको थियो। विन्डोज पावरशेलमा - GitLab पृष्ठहरूमा रिपोर्ट डिप्लोइ गर्ने स्क्रिप्ट (यस अघि तपाईंले स्वत: परीक्षणहरू चलाउन आवश्यक छ):

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

के अन्तमा

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

अभ्यासले देखाएको छ कि थ्रेडहरूमा अटोटेस्टहरू चलाउँदा तपाईंलाई उत्कृष्ट कार्यसम्पादनको साथ न्यूनतममा स्रोत खपत कम गर्न अनुमति दिन्छ। ग्राफहरूबाट देख्न सकिन्छ, थ्रेडहरू दोब्बर गर्नाले प्रदर्शन परीक्षणहरूमा समान प्रवेगको नेतृत्व गर्दैन। यद्यपि, हामीले एप्लिकेसन निर्माणमा 2 भन्दा बढी स्वचालित परीक्षणहरू थप्न सक्षम भयौं, जुन 200 मिनेटमा 5 पुन: चलाउँदा पनि। यसले तपाईंलाई तिनीहरूबाट द्रुत प्रतिक्रिया प्राप्त गर्न अनुमति दिन्छ, र आवश्यक भएमा, परिवर्तनहरू गर्नुहोस् र प्रक्रिया फेरि दोहोर्याउनुहोस्।

स्रोत: www.habr.com

लागू गर्नुहोस्, स्केल: VTB मा स्वचालित परीक्षणहरू प्रयोग गर्ने अनुभव

हामीले कहाँ सुरु गर्यौं?

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

JVM फोर्कहरूमा परीक्षणहरू

अस्थिरता कसरी हटाउने

Cucumber 4 पुस्तकालय संग समानान्तर परीक्षण

GitLab पृष्ठहरूमा एलुर रिपोर्टहरू

के अन्तमा

एक टिप्पणी थप्न Отменить ответ