നടപ്പിലാക്കുക, സ്കെയിൽ: VTB-യിൽ ഓട്ടോമേറ്റഡ് ടെസ്റ്റുകൾ ഉപയോഗിച്ചതിന്റെ അനുഭവം

പ്രൊഡക്ഷൻ പരിതസ്ഥിതിയിലേക്ക് ആപ്ലിക്കേഷനുകളുടെ പുതിയ പതിപ്പുകൾ സമാരംഭിക്കുന്നതിന് ഞങ്ങളുടെ ഡിവിഷൻ പൂർണ്ണമായും ഓട്ടോമാറ്റിക് പൈപ്പ്ലൈനുകൾ സൃഷ്ടിക്കുന്നു. തീർച്ചയായും, ഇതിന് ഓട്ടോമേറ്റഡ് ഫങ്ഷണൽ ടെസ്റ്റുകൾ ആവശ്യമാണ്. ഒരു ലോക്കൽ മെഷീനിലെ സിംഗിൾ-ത്രെഡ് ടെസ്റ്റിംഗിൽ തുടങ്ങി, GitLab പേജുകളിലെ ഒരു Allure റിപ്പോർട്ട് ഉപയോഗിച്ച്, ബിൽഡ് പൈപ്പ്‌ലൈനിൽ സെലിനോയ്ഡിൽ പ്രവർത്തിക്കുന്ന മൾട്ടി-ത്രെഡ് ഓട്ടോടെസ്റ്റ് എന്ന ഘട്ടത്തിലേക്ക് ഞങ്ങൾ എത്തിച്ചേരുകയും ഒടുവിൽ ഒരു കൂൾ ഓട്ടോമേഷൻ ടൂൾ എങ്ങനെ നേടുകയും ചെയ്തു എന്നതിനെക്കുറിച്ചുള്ള ഒരു കഥയാണ് കട്ടിന് താഴെയുള്ളത്. ഭാവിയിലെ ആളുകൾക്ക് ടീമുകളെ ഉപയോഗിക്കാൻ കഴിയും.

നമ്മൾ എവിടെയാണ് തുടങ്ങിയത്?

ഓട്ടോടെസ്റ്റുകൾ നടപ്പിലാക്കുന്നതിനും പൈപ്പ്ലൈനിലേക്ക് സംയോജിപ്പിക്കുന്നതിനും, ഞങ്ങളുടെ ആവശ്യങ്ങൾക്ക് അനുയോജ്യമായ രീതിയിൽ മാറ്റാൻ കഴിയുന്ന ഒരു ഓട്ടോമേഷൻ ചട്ടക്കൂട് ആവശ്യമാണ്. മികച്ച രീതിയിൽ, ഓട്ടോടെസ്റ്റിംഗ് എഞ്ചിനുള്ള ഒരൊറ്റ സ്റ്റാൻഡേർഡ് ലഭിക്കാൻ ഞാൻ ആഗ്രഹിച്ചു, അത് പൈപ്പ്ലൈനിലേക്ക് ഓട്ടോടെസ്റ്റുകൾ ഉൾച്ചേർക്കുന്നതിന് അനുയോജ്യമാണ്. നടപ്പിലാക്കുന്നതിനായി ഞങ്ങൾ ഇനിപ്പറയുന്ന സാങ്കേതികവിദ്യകൾ തിരഞ്ഞെടുത്തു:

• ജാവ,
• മാവൻ,
• സെലിനിയം,
• കുക്കുമ്പർ+ജൂണിറ്റ് 4,
• വശീകരിക്കുക,
• GitLab.

എന്തുകൊണ്ടാണ് ഈ പ്രത്യേക സെറ്റ്? ഓട്ടോമേറ്റഡ് ടെസ്റ്റുകൾക്കായുള്ള ഏറ്റവും ജനപ്രിയമായ ഭാഷകളിലൊന്നാണ് ജാവ, എല്ലാ ടീം അംഗങ്ങളും ഇത് സംസാരിക്കുന്നു. സെലിനിയം ഒരു വ്യക്തമായ പരിഹാരമാണ്. കുക്കുമ്പർ, മറ്റ് കാര്യങ്ങൾക്കൊപ്പം, മാനുവൽ ടെസ്റ്റിംഗിൽ ഏർപ്പെട്ടിരിക്കുന്ന വകുപ്പുകളുടെ ഭാഗത്തുനിന്ന് ഓട്ടോമേറ്റഡ് ടെസ്റ്റുകളുടെ ഫലങ്ങളിൽ ആത്മവിശ്വാസം വർദ്ധിപ്പിക്കേണ്ടതായിരുന്നു.

ഒറ്റ ത്രെഡ് ടെസ്റ്റുകൾ

ചക്രം പുനർനിർമ്മിക്കാതിരിക്കാൻ, ഞങ്ങൾ GitHub-ലെ വിവിധ ശേഖരണങ്ങളിൽ നിന്നുള്ള സംഭവവികാസങ്ങൾ ചട്ടക്കൂടിന്റെ അടിസ്ഥാനമായി എടുക്കുകയും അവ സ്വയം പൊരുത്തപ്പെടുത്തുകയും ചെയ്തു. ഓട്ടോടെസ്റ്റ് ചട്ടക്കൂടിന്റെ കോർ ഉപയോഗിച്ച് പ്രധാന ലൈബ്രറിക്കായി ഞങ്ങൾ ഒരു ശേഖരണവും ഞങ്ങളുടെ കാമ്പിൽ ഓട്ടോടെസ്റ്റുകൾ നടപ്പിലാക്കുന്നതിനുള്ള ഒരു സ്വർണ്ണ ഉദാഹരണമുള്ള ഒരു ശേഖരണവും സൃഷ്ടിച്ചു. ഓരോ ടീമും ഗോൾഡ് ഇമേജ് എടുത്ത് അതിൽ ടെസ്റ്റുകൾ വികസിപ്പിക്കുകയും അത് അവരുടെ പ്രോജക്റ്റിന് അനുയോജ്യമാക്കുകയും വേണം. ഞങ്ങൾ അത് കോൺഫിഗർ ചെയ്ത 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 ത്രെഡ്)
 
ഒറ്റ-ത്രെഡ് ടെസ്റ്റുകളുടെ ഗുണങ്ങൾ:

• സജ്ജീകരിക്കാനും പ്രവർത്തിപ്പിക്കാനും എളുപ്പമാണ്;
• CI ലെ ലോഞ്ചുകൾ പ്രായോഗികമായി പ്രാദേശിക ലോഞ്ചുകളിൽ നിന്ന് വ്യത്യസ്തമല്ല;
• പരിശോധനകൾ പരസ്പരം ബാധിക്കില്ല;
• റണ്ണർ വിഭവങ്ങൾക്കുള്ള ഏറ്റവും കുറഞ്ഞ ആവശ്യകതകൾ.

ഒറ്റ-ത്രെഡ് ടെസ്റ്റുകളുടെ പോരായ്മകൾ:

• പൂർത്തിയാക്കാൻ വളരെ സമയമെടുക്കും;
• ടെസ്റ്റുകളുടെ നീണ്ട സ്ഥിരത;
• റണ്ണർ വിഭവങ്ങളുടെ കാര്യക്ഷമമല്ലാത്ത ഉപയോഗം, വളരെ കുറഞ്ഞ ഉപയോഗം.

ജെവിഎം ഫോർക്കുകളിലെ പരിശോധനകൾ

അടിസ്ഥാന ചട്ടക്കൂട് നടപ്പിലാക്കുമ്പോൾ ത്രെഡ്-സേഫ് കോഡ് ഞങ്ങൾ ശ്രദ്ധിക്കാത്തതിനാൽ, സമാന്തരമായി പ്രവർത്തിക്കാനുള്ള ഏറ്റവും വ്യക്തമായ മാർഗം cucumber-jvm-parallel-plugin മാവന് വേണ്ടി. പ്ലഗിൻ ക്രമീകരിക്കാൻ എളുപ്പമാണ്, എന്നാൽ ശരിയായ സമാന്തര പ്രവർത്തനത്തിന്, ഓട്ടോടെസ്റ്റുകൾ പ്രത്യേക ബ്രൗസറുകളിൽ പ്രവർത്തിപ്പിക്കേണ്ടതുണ്ട്. ഒന്നും ചെയ്യാനില്ല, എനിക്ക് Selenoid ഉപയോഗിക്കേണ്ടി വന്നു.

സെലിനോയിഡ് സെർവർ 32 കോറുകളും 24 ജിബി റാമും ഉള്ള ഒരു മെഷീനിൽ സമാരംഭിച്ചു. പരിധി 48 ബ്രൗസറുകളായി സജ്ജീകരിച്ചിരിക്കുന്നു - ഒരു കോറിന് 1,5 ത്രെഡുകൾ, ഏകദേശം 400 MB റാമുകൾ. ഇതിന്റെ ഫലമായി പരിശോധനാ സമയം മൂന്ന് മണിക്കൂറിൽ നിന്ന് 40 മിനിറ്റായി കുറച്ചു. റണ്ണുകൾ വേഗത്തിലാക്കുന്നത് സ്റ്റെബിലൈസേഷൻ പ്രശ്നം പരിഹരിക്കാൻ സഹായിച്ചു: ഇപ്പോൾ നമുക്ക് പുതിയ ഓട്ടോടെസ്റ്റുകൾ 20-30 തവണ വേഗത്തിൽ പ്രവർത്തിപ്പിക്കാൻ കഴിയും, അവ വിശ്വസനീയമായി പ്രവർത്തിക്കുന്നുവെന്ന് ഞങ്ങൾക്ക് ഉറപ്പുവരും.
ചെറിയ എണ്ണം സമാന്തര ത്രെഡുകളുള്ള റണ്ണർ റിസോഴ്‌സുകളുടെ ഉയർന്ന ഉപയോഗമാണ് പരിഹാരത്തിന്റെ ആദ്യത്തെ പോരായ്മ: 4 കോറുകളിലും 8 ജിബി റാമിലും, ടെസ്റ്റുകൾ 6 ത്രെഡുകളിൽ കൂടാതെ സ്ഥിരമായി പ്രവർത്തിച്ചു. രണ്ടാമത്തെ പോരായ്മ: പ്ലഗിൻ ഓരോ സാഹചര്യത്തിനും റണ്ണർ ക്ലാസുകൾ സൃഷ്ടിക്കുന്നു, അവയിൽ എത്ര എണ്ണം സമാരംഭിച്ചാലും.

പ്രധാനപ്പെട്ടത്! ലേക്കുള്ള ടാഗുകളുള്ള ഒരു വേരിയബിൾ കൈമാറരുത് argLine, ഉദാഹരണത്തിന്, ഇതുപോലെ:

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

നിങ്ങൾ ഈ രീതിയിൽ ടാഗ് പാസ്സാക്കുകയാണെങ്കിൽ, പ്ലഗിൻ എല്ലാ ടെസ്റ്റുകൾക്കും റണ്ണർമാരെ സൃഷ്ടിക്കും, അതായത്, എല്ലാ ടെസ്റ്റുകളും പ്രവർത്തിപ്പിക്കാൻ ശ്രമിക്കും, ലോഞ്ച് ചെയ്ത ഉടൻ തന്നെ അവ ഒഴിവാക്കുകയും നിരവധി ജെവിഎം ഫോർക്കുകൾ സൃഷ്ടിക്കുകയും ചെയ്യും.

ഒരു ടാഗ് ഉള്ള ഒരു വേരിയബിൾ എറിയുന്നത് ശരിയാണ് ടാഗുകൾ പ്ലഗിൻ ക്രമീകരണങ്ങളിൽ, ചുവടെയുള്ള ഉദാഹരണം കാണുക. ഞങ്ങൾ പരീക്ഷിച്ച മറ്റ് രീതികൾക്ക് 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 surefire പ്ലഗിൻ, പരാജയപ്പെട്ട ടെസ്റ്റുകൾ പുനരാരംഭിക്കുന്നതിനെ ബോക്സിന് പുറത്ത് പിന്തുണയ്ക്കുന്നത്. നിങ്ങൾ പ്ലഗിൻ പതിപ്പ് കുറഞ്ഞത് 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>

അല്ലെങ്കിൽ ആരംഭത്തിൽ: mvn … -Dsurefire.rerunFailingTestsCount=2 …
ഒരു ഓപ്ഷനായി, PowerShell സ്ക്രിപ്റ്റിനായി (PS1) Maven ഓപ്ഷനുകൾ സജ്ജമാക്കുക:

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

പ്രോസ്:

• അസ്ഥിരമായ ഒരു ടെസ്റ്റ് തകരാറിലാകുമ്പോൾ അത് വിശകലനം ചെയ്ത് സമയം പാഴാക്കേണ്ടതില്ല;
• ടെസ്റ്റ് ബെഞ്ച് സ്ഥിരത പ്രശ്നങ്ങൾ ലഘൂകരിക്കാനാകും.

പരിഗണന:

• ഫ്ലോട്ടിംഗ് വൈകല്യങ്ങൾ നഷ്ടപ്പെടാം;
• റൺ ടൈം കൂടുന്നു.

കുക്കുമ്പർ 4 ലൈബ്രറിയുമായുള്ള സമാന്തര പരിശോധനകൾ

ഓരോ ദിവസവും പരിശോധനകളുടെ എണ്ണം വർദ്ധിച്ചു. റണ്ണുകൾ വേഗത്തിലാക്കുന്നതിനെക്കുറിച്ച് ഞങ്ങൾ വീണ്ടും ചിന്തിച്ചു. കൂടാതെ, ആപ്ലിക്കേഷൻ അസംബ്ലി പൈപ്പ്ലൈനിലേക്ക് കഴിയുന്നത്ര ടെസ്റ്റുകൾ സംയോജിപ്പിക്കാൻ ഞാൻ ആഗ്രഹിച്ചു. Maven പ്ലഗിൻ ഉപയോഗിച്ച് സമാന്തരമായി ഓടുമ്പോൾ റണ്ണേഴ്‌സിന്റെ ജനറേഷൻ വളരെയധികം സമയമെടുത്തു എന്നതാണ് നിർണായക ഘടകം.

ആ സമയത്ത്, കുക്കുമ്പർ 4 ഇതിനകം പുറത്തിറങ്ങി, അതിനാൽ ഈ പതിപ്പിനായി കേർണൽ വീണ്ടും എഴുതാൻ ഞങ്ങൾ തീരുമാനിച്ചു. റിലീസ് കുറിപ്പുകളിൽ, ത്രെഡ് തലത്തിൽ സമാന്തര ലോഞ്ച് ഞങ്ങൾ വാഗ്ദാനം ചെയ്തിരുന്നു. സൈദ്ധാന്തികമായി ഇത് ഇതായിരിക്കണം:

• ത്രെഡുകളുടെ എണ്ണം വർദ്ധിപ്പിച്ച് ഓട്ടോടെസ്റ്റുകളുടെ പ്രവർത്തനം ഗണ്യമായി വേഗത്തിലാക്കുക;
• ഓരോ ഓട്ടോടെസ്റ്റിനും റണ്ണർമാരെ സൃഷ്ടിക്കുന്നതിനുള്ള സമയനഷ്ടം ഇല്ലാതാക്കുക.

മൾട്ടി-ത്രെഡ് ഓട്ടോടെസ്റ്റുകൾക്കായി ചട്ടക്കൂട് ഒപ്റ്റിമൈസ് ചെയ്യുന്നത് അത്ര ബുദ്ധിമുട്ടുള്ള കാര്യമല്ല. കുക്കുമ്പർ 4 ഓരോ വ്യക്തിഗത പരിശോധനയും തുടക്കം മുതൽ അവസാനം വരെ ഒരു സമർപ്പിത ത്രെഡിൽ പ്രവർത്തിപ്പിക്കുന്നു, അതിനാൽ ചില സാധാരണ സ്റ്റാറ്റിക് കാര്യങ്ങൾ ത്രെഡ്‌ലോക്കൽ വേരിയബിളുകളിലേക്ക് പരിവർത്തനം ചെയ്തു. 
ഐഡിയ റീഫാക്‌ടറിംഗ് ടൂളുകൾ ഉപയോഗിച്ച് പരിവർത്തനം ചെയ്യുമ്പോൾ പ്രധാന കാര്യം വേരിയബിൾ താരതമ്യം ചെയ്ത സ്ഥലങ്ങൾ പരിശോധിക്കുക എന്നതാണ് (ഉദാഹരണത്തിന്, നൾ പരിശോധിക്കുന്നു). കൂടാതെ, ജൂണിറ്റ് റണ്ണർ ക്ലാസ് വ്യാഖ്യാനത്തിലേക്ക് നിങ്ങൾ 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 ജിബി റാം, 24 ത്രെഡുകൾ)

പ്രോസ്:

• കുറഞ്ഞ വിഭവ ഉപഭോഗം;
• കുക്കുമ്പറിൽ നിന്നുള്ള പ്രാദേശിക പിന്തുണ - അധിക ഉപകരണങ്ങൾ ആവശ്യമില്ല;
• ഓരോ പ്രോസസർ കോറിനും 6 ത്രെഡുകളിൽ കൂടുതൽ പ്രവർത്തിപ്പിക്കാനുള്ള കഴിവ്.

പരിഗണന:

• കോഡ് മൾട്ടി-ത്രെഡ് എക്സിക്യൂഷനെ പിന്തുണയ്ക്കുന്നുവെന്ന് നിങ്ങൾ ഉറപ്പാക്കേണ്ടതുണ്ട്;
• പ്രവേശന പരിധി വർദ്ധിക്കുന്നു.

GitLab പേജുകളിലെ Allure റിപ്പോർട്ടുകൾ

മൾട്ടി-ത്രെഡ് എക്സിക്യൂഷൻ അവതരിപ്പിച്ച ശേഷം, റിപ്പോർട്ടുകൾ വിശകലനം ചെയ്യാൻ ഞങ്ങൾ കൂടുതൽ സമയം ചെലവഴിക്കാൻ തുടങ്ങി. ആ സമയത്ത്, ഞങ്ങൾക്ക് ഓരോ റിപ്പോർട്ടും ഒരു ആർട്ടിഫാക്റ്റായി 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