అమలు, స్థాయి: VTB వద్ద స్వయంచాలక పరీక్షలను ఉపయోగించిన అనుభవం

ఉత్పాదక వాతావరణంలోకి అప్లికేషన్ల యొక్క కొత్త వెర్షన్‌లను ప్రారంభించడం కోసం మా విభాగం పూర్తిగా ఆటోమేటిక్ పైప్‌లైన్‌లను సృష్టిస్తుంది. వాస్తవానికి, దీనికి ఆటోమేటెడ్ ఫంక్షనల్ పరీక్షలు అవసరం. లోకల్ మెషీన్‌లో సింగిల్-థ్రెడ్ టెస్టింగ్‌తో ప్రారంభించి, గిట్‌ల్యాబ్ పేజీలలోని అల్యూర్ రిపోర్ట్‌తో బిల్డ్ పైప్‌లైన్‌లో సెలీనోయిడ్‌లో నడుస్తున్న మల్టీ-థ్రెడ్ ఆటోటెస్ట్ స్థాయికి మేము ఎలా చేరుకున్నాము మరియు చివరికి కూల్ ఆటోమేషన్ టూల్‌ను ఎలా పొందాము అనే దాని గురించి కట్ క్రింద ఉంది. భవిష్యత్తులో ప్రజలు జట్లను ఉపయోగించవచ్చు.

మేము ఎక్కడ ప్రారంభించాము?

ఆటోటెస్ట్‌లను అమలు చేయడానికి మరియు వాటిని పైప్‌లైన్‌లో ఏకీకృతం చేయడానికి, మా అవసరాలకు అనుగుణంగా సరళంగా మార్చగలిగే ఆటోమేషన్ ఫ్రేమ్‌వర్క్ మాకు అవసరం. ఆదర్శవంతంగా, నేను ఆటోటెస్టింగ్ ఇంజిన్ కోసం ఒకే ప్రమాణాన్ని పొందాలనుకుంటున్నాను, పైప్‌లైన్‌లో ఆటోటెస్ట్‌లను పొందుపరచడానికి స్వీకరించబడింది. అమలు కోసం మేము ఈ క్రింది సాంకేతికతలను ఎంచుకున్నాము:

• జావా,
• మావెన్,
• సెలీనియం,
• దోసకాయ+JUNIT 4,
• ఆకర్షణ,
• గిట్‌ల్యాబ్.

ఈ ప్రత్యేక సెట్ ఎందుకు? స్వయంచాలక పరీక్షల కోసం జావా అత్యంత ప్రజాదరణ పొందిన భాషలలో ఒకటి మరియు బృంద సభ్యులందరూ దీనిని మాట్లాడతారు. సెలీనియం స్పష్టమైన పరిష్కారం. దోసకాయ, ఇతర విషయాలతోపాటు, మాన్యువల్ టెస్టింగ్‌లో పాల్గొన్న విభాగాలలో ఆటోమేటెడ్ పరీక్షల ఫలితాలపై విశ్వాసాన్ని పెంచుతుంది.

ఒకే థ్రెడ్ పరీక్షలు

చక్రాన్ని తిరిగి ఆవిష్కరించకుండా ఉండటానికి, మేము 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 మావెన్ కోసం. ప్లగ్ఇన్ కాన్ఫిగర్ చేయడం సులభం, కానీ సరైన సమాంతర ఆపరేషన్ కోసం, ఆటోటెస్ట్‌లను ప్రత్యేక బ్రౌజర్‌లలో అమలు చేయాలి. చేసేదేమీ లేదు, నేను సెలీనోయిడ్ ఉపయోగించాల్సి వచ్చింది.

Selenoid సర్వర్ 32 కోర్లు మరియు 24 GB RAM కలిగిన మెషీన్‌లో ప్రారంభించబడింది. పరిమితి 48 బ్రౌజర్‌లకు సెట్ చేయబడింది - ఒక్కో కోర్‌కి 1,5 థ్రెడ్‌లు మరియు దాదాపు 400 MB RAM. దీంతో పరీక్ష సమయం మూడు గంటల నుంచి 40 నిమిషాలకు తగ్గింది. పరుగులను వేగవంతం చేయడం స్థిరీకరణ సమస్యను పరిష్కరించడంలో సహాయపడింది: ఇప్పుడు మేము కొత్త ఆటోటెస్ట్‌లను 20-30 సార్లు త్వరగా అమలు చేయగలము, అవి విశ్వసనీయంగా నడుస్తున్నాయని మేము నిర్ధారించుకుంటాము.
పరిష్కారం యొక్క మొదటి లోపం తక్కువ సంఖ్యలో సమాంతర థ్రెడ్‌లతో రన్నర్ వనరులను ఎక్కువగా ఉపయోగించడం: 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కి ధన్యవాదాలు పరీక్ష స్థిరీకరణ త్వరణం. 

కాన్స్:

• బహుళ 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) కోసం మావెన్ ఎంపికలను సెట్ చేయండి:

  
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 GB RAM, 24 థ్రెడ్‌లు)

ప్రోస్:

• తక్కువ వనరుల వినియోగం;
• దోసకాయ నుండి స్థానిక మద్దతు - అదనపు ఉపకరణాలు అవసరం లేదు;
• ప్రాసెసర్ కోర్‌కి 6 కంటే ఎక్కువ థ్రెడ్‌లను అమలు చేయగల సామర్థ్యం.

కాన్స్:

• మీరు కోడ్ బహుళ-థ్రెడ్ అమలుకు మద్దతు ఇస్తుందని నిర్ధారించుకోవాలి;
• ప్రవేశ పరిమితి పెరుగుతుంది.

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

బాటమ్ లైన్ అంటే ఏమిటి 

కాబట్టి, మీకు దోసకాయ ఆటోటెస్ట్ ఫ్రేమ్‌వర్క్‌లో థ్రెడ్ సేఫ్ కోడ్ అవసరమా అని మీరు ఆలోచిస్తుంటే, ఇప్పుడు సమాధానం స్పష్టంగా ఉంది - దోసకాయ 4 తో దీన్ని అమలు చేయడం సులభం, తద్వారా ఒకేసారి ప్రారంభించిన థ్రెడ్‌ల సంఖ్య గణనీయంగా పెరుగుతుంది. పరీక్షలను అమలు చేసే ఈ పద్ధతితో, సెలీనోయిడ్ మరియు టెస్ట్ బెంచ్‌తో యంత్రం యొక్క పనితీరు గురించి ఇప్పుడు ప్రశ్న అవుతుంది.

థ్రెడ్‌లపై ఆటోటెస్ట్‌లను అమలు చేయడం ఉత్తమ పనితీరుతో వనరుల వినియోగాన్ని కనిష్టంగా తగ్గించడానికి మిమ్మల్ని అనుమతిస్తుంది అని ప్రాక్టీస్ చూపించింది. గ్రాఫ్‌ల నుండి చూడగలిగినట్లుగా, థ్రెడ్‌లను రెట్టింపు చేయడం పనితీరు పరీక్షలలో ఇదే విధమైన త్వరణానికి దారితీయదు. అయినప్పటికీ, మేము అప్లికేషన్ బిల్డ్‌కి 2 కంటే ఎక్కువ ఆటోమేటెడ్ పరీక్షలను జోడించగలిగాము, ఇది 200 రీరన్‌లతో కూడా దాదాపు 5 నిమిషాలలో నడుస్తుంది. ఇది వారి నుండి శీఘ్ర అభిప్రాయాన్ని స్వీకరించడానికి మిమ్మల్ని అనుమతిస్తుంది మరియు అవసరమైతే, మార్పులు చేసి, విధానాన్ని మళ్లీ పునరావృతం చేయండి.

మూలం: www.habr.com