ክፍላችን አዳዲስ ስሪቶችን ወደ ምርት አካባቢ ለማስጀመር ሙሉ በሙሉ አውቶማቲክ የቧንቧ መስመሮችን ይፈጥራል። በእርግጥ ይህ አውቶማቲክ የተግባር ሙከራዎችን ይፈልጋል። ከመቁረጡ በታች በሀገር ውስጥ ማሽን በነጠላ-ክር ሙከራ በመጀመር በ GitLab ገጾች ላይ ካለው የ Alure ዘገባ ጋር በ Selenoid ላይ ወደሚሰሩ ባለብዙ-ክር አውቶሞተሮች ሄድን የወደፊት ሰዎች ቡድኖችን መጠቀም ይችላሉ.
ከየት ጀመርን።
አውቶሜትቶችን ለመተግበር እና ወደ ቧንቧው ለማዋሃድ፣ ፍላጎታችንን ለማሟላት በተለዋዋጭነት የሚቀየር አውቶሜሽን ማዕቀፍ እንፈልጋለን። በሐሳብ ደረጃ፣ አውቶሞተሮችን ወደ ቧንቧው ለመክተት የተስተካከለ፣ ለአውቶሞቲቭ ሞተር አንድ ነጠላ መስፈርት ማግኘት ፈልጌ ነበር። ለትግበራ የሚከተሉትን ቴክኖሎጂዎች መርጠናል-
- ጃቫ ፣
- ማቨን ፣
- ሴሊኒየም,
- ዱባ+ጁኒት 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 ጊባ ራም፣ 1 ክር)
የአንድ-ክር ሙከራዎች ጥቅሞች:
- ለማዋቀር እና ለማሄድ ቀላል;
- በ CI ውስጥ ማስጀመሪያዎች ከአካባቢያዊ ማስጀመሪያዎች ምንም የተለዩ አይደሉም;
- ፈተናዎች እርስ በርሳቸው አይነኩም;
- ለሯጭ ሀብቶች ዝቅተኛ መስፈርቶች.
ነጠላ-ክር ሙከራዎች ጉዳቶች
- ለማጠናቀቅ በጣም ረጅም ጊዜ ይውሰዱ;
- የፈተናዎች ረጅም መረጋጋት;
- ውጤታማ ያልሆነ የሩጫ ሀብቶች አጠቃቀም ፣ እጅግ በጣም ዝቅተኛ አጠቃቀም።
በJVM ሹካዎች ላይ ሙከራዎች
የመሠረት ማዕቀፉን በምንተገበርበት ጊዜ ለክር-አስተማማኝ ኮድ እንክብካቤ ስላልሰጠን ፣ በትይዩ ለማስኬድ በጣም ግልፅ የሆነው መንገድ ነበር ። ለ Maven. ፕለጊኑ ለማዋቀር ቀላል ነው፣ ነገር ግን ለትክክለኛው ትይዩ ኦፕሬሽን፣ አውቶሜትሪዎች በተለየ አሳሾች ውስጥ መካሄድ አለባቸው። ምንም የሚሠራ ነገር የለም, Selenoid መጠቀም ነበረብኝ.
የ Selenoid አገልጋይ 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"
መለያውን በዚህ መንገድ ካሳለፉት ፕለጊኑ ለሁሉም ፈተናዎች ሯጮችን ያመነጫል ማለትም ሁሉንም ፈተናዎች ለማሄድ ይሞክራል ፣ ከተጀመረ በኋላ ወዲያውኑ መዝለል እና ብዙ የ JVM ሹካዎችን ይፈጥራል።
መለያ ያለበት ተለዋዋጭ ወደ ውስጥ መጣል ትክክል ነው። መለያዎች በፕለጊን መቼቶች ውስጥ, ከታች ያለውን ምሳሌ ይመልከቱ. ሌሎች የሞከርናቸው ዘዴዎች የAllure ፕለጊን በማገናኘት ላይ ችግር አለባቸው።
ትክክል ካልሆኑ ቅንብሮች ጋር ለ6 አጭር ሙከራዎች የማስኬጃ ጊዜ ምሳሌ፡-
[INFO] Total time: 03:17 min
መለያውን በቀጥታ ካስተላለፉት የፍተሻ አሂድ ጊዜ ምሳሌ mvn... -ዱካምበር.አማራጮች:
[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>
የAllure ሪፖርት ምሳሌ (በጣም ያልተረጋጋ ፈተና፣ 4 ተደጋጋሚ ሙከራዎች)
በሙከራ ጊዜ የሯጭ ጭነት (8 ኮር፣ 8 ጂቢ RAM፣ 12 ክሮች)
ምርቶች
- ቀላል ማዋቀር - ፕለጊን ማከል ብቻ ያስፈልግዎታል;
- ብዙ ሙከራዎችን በአንድ ጊዜ የማከናወን ችሎታ;
- ለደረጃ 1 ለሙከራ ማረጋጊያ ማፋጠን።
Cons:
- በርካታ ስርዓተ ክወናዎች / ኮንቴይነሮች ያስፈልጋሉ;
- ለእያንዳንዱ ሹካ ከፍተኛ የሃብት ፍጆታ;
- ተሰኪው ጊዜው አልፎበታል እና ከአሁን በኋላ አይደገፍም።
አለመረጋጋትን እንዴት ማሸነፍ እንደሚቻል
የሙከራ ወንበሮች ተስማሚ አይደሉም፣ ልክ እንደ አውቶሞተሮች እራሳቸው። በርካታ ብልጭ ድርግም የሚሉ ፈተናዎች ቢኖሩን አያስደንቅም። ለማዳን መጣያልተሳኩ ሙከራዎችን እንደገና ማስጀመርን ከሳጥኑ ውስጥ የሚደግፍ። የተሰኪውን ስሪት ቢያንስ ወደ 2.21 ማዘመን እና በፖም ፋይሉ ውስጥ ካለው ዳግም ማስጀመር ቁጥር ጋር አንድ መስመር ይፃፉ ወይም እንደ ክርክር ወደ Maven ያስተላልፉት።
አውቶሞተሮችን የማዋቀር ምሳሌ፡-
<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 …
እንደ አማራጭ የMaven አማራጮችን ለPowerShell ስክሪፕት (PS1) ያዘጋጁ፡-
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"ምርቶች
- ያልተረጋጋ ፈተና ሲበላሽ ለመተንተን ጊዜ ማባከን አያስፈልግም;
- የሙከራ ቤንች መረጋጋት ችግሮችን መቀነስ ይቻላል.
Cons:
- ተንሳፋፊ ጉድለቶች ሊታለፉ ይችላሉ;
- የሩጫ ጊዜ ይጨምራል።
ከ Cucumber 4 ቤተ-መጽሐፍት ጋር ትይዩ ሙከራዎች
የፈተናዎች ቁጥር በየቀኑ እየጨመረ ነበር። ሩጫውን ስለማፋጠን እንደገና አሰብን። በተጨማሪም, በተቻለ መጠን ብዙ ሙከራዎችን ወደ አፕሊኬሽኑ የመሰብሰቢያ ቱቦ ውስጥ ማዋሃድ ፈልጌ ነበር. ወሳኙ ነገር የ Maven ፕለጊን በመጠቀም በትይዩ ሲሮጡ ሯጮች ማመንጨት በጣም ረጅም ጊዜ ወስዷል።
በዛን ጊዜ, Cucumber 4 ቀድሞውኑ ተለቋል, ስለዚህ ለዚህ እትም ከርነል እንደገና ለመጻፍ ወሰንን. በተለቀቁት ማስታወሻዎች በክር ደረጃ ትይዩ ማስጀመር ቃል ተገብቶልናል። በንድፈ ሀሳብ ይህ መሆን የነበረበት፡-
- የክሮች ብዛት በመጨመር የአውቶሞተሮችን ስራ በከፍተኛ ሁኔታ ያፋጥናል;
- ለእያንዳንዱ ራስ-ሙከራ ሯጮችን በማመንጨት ጊዜ ማጣትን ያስወግዱ።
ባለብዙ-ክር አውቶሞቲኮችን ማዕቀፍ ማመቻቸት ያን ያህል አስቸጋሪ ሆኖ አልተገኘም። Cucumber 4 እያንዳንዱን ነጠላ ሙከራ ከመጀመሪያው እስከ መጨረሻው በተዘጋጀ ክር ላይ ይሰራል፣ ስለዚህ አንዳንድ የተለመዱ የማይንቀሳቀሱ ነገሮች በቀላሉ ወደ ThreadLocal ተለዋዋጮች ተለውጠዋል።
የ Idea refactoring tools በመጠቀም ሲቀይሩ ዋናው ነገር ተለዋዋጭው የተነፃፀረባቸውን ቦታዎች ማረጋገጥ ነው (ለምሳሌ ባዶ መሆኑን ማረጋገጥ)። በተጨማሪም፣ የ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>
የAllure ሪፖርት ምሳሌ (በጣም ያልተረጋጋ ፈተና፣ 5 ድጋሚ ሙከራዎች)
በሙከራ ጊዜ የሯጭ ጭነት (8 ኮር፣ 8 ጂቢ RAM፣ 24 ክሮች)
ምርቶች
- ዝቅተኛ የሃብት ፍጆታ;
- ከኩምበር ቤተኛ ድጋፍ - ምንም ተጨማሪ መሳሪያዎች አያስፈልጉም;
- በአንድ ፕሮሰሰር ኮር ከ 6 ክሮች በላይ የማሄድ ችሎታ።
Cons:
- ኮዱ ባለብዙ-ክር አፈፃፀምን እንደሚደግፍ ማረጋገጥ ያስፈልግዎታል ፣
- የመግቢያው ገደብ ይጨምራል.
Alure በ 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 autotest ማእቀፍ ውስጥ የ Thread safe code ያስፈልግዎት እንደሆነ እያሰቡ ከሆነ ፣ አሁን መልሱ ግልፅ ነው - በ Cucumber 4 እሱን መተግበር ቀላል ነው ፣ በዚህም በተመሳሳይ ጊዜ የሚጀመሩትን ክሮች ቁጥር በከፍተኛ ሁኔታ ይጨምራል። በዚህ የማሄድ ሙከራዎች ዘዴ, ጥያቄው አሁን ስለ ማሽኑ አፈፃፀም በ Selenoid እና በሙከራ አግዳሚ ወንበር ላይ ይሆናል.
ልምምድ እንደሚያሳየው በክር ላይ አውቶማቲክ ሙከራዎችን ማካሄድ በጣም ጥሩ በሆነ አፈፃፀም የንብረት ፍጆታን በትንሹ እንዲቀንሱ ያስችልዎታል። ከግራፎቹ ላይ እንደሚታየው, ድርብ ክሮች በአፈፃፀም ሙከራዎች ውስጥ ወደ ተመሳሳይ ፍጥነት አይመሩም. ነገር ግን፣ ከ2 በላይ አውቶሜትድ ሙከራዎችን ወደ አፕሊኬሽኑ ግንባታ ማከል ችለናል፣ ይህም በ200 ደቂቃ ውስጥ 5 ድጋሚ ሲደረግ ነው። ይህ ከእነሱ ፈጣን ግብረመልስ እንዲቀበሉ ያስችልዎታል, እና አስፈላጊ ከሆነ, ለውጦችን ያድርጉ እና ሂደቱን እንደገና ይድገሙት.
ምንጭ: hab.com