ປະຕິບັດ, ຂະຫນາດ: ປະສົບການຂອງການນໍາໃຊ້ການທົດສອບອັດຕະໂນມັດຢູ່ VTB

ພະແນກຂອງພວກເຮົາສ້າງທໍ່ອັດຕະໂນມັດຢ່າງເຕັມທີ່ສໍາລັບການເປີດຕົວໃຫມ່ຂອງຄໍາຮ້ອງສະຫມັກເຂົ້າໄປໃນສະພາບແວດລ້ອມການຜະລິດ. ແນ່ນອນ, ນີ້ຮຽກຮ້ອງໃຫ້ມີການທົດສອບອັດຕະໂນມັດ. ຂ້າງລຸ່ມນີ້ການຕັດແມ່ນເລື່ອງກ່ຽວກັບວິທີການ, ເລີ່ມຕົ້ນດ້ວຍການທົດສອບເສັ້ນດຽວໃນເຄື່ອງຈັກທ້ອງຖິ່ນ, ພວກເຮົາໄດ້ມາຮອດຈຸດຂອງ multi-threaded autotest ແລ່ນໃນ Selenoid ໃນທໍ່ກໍ່ສ້າງດ້ວຍບົດລາຍງານ Allure ໃນຫນ້າ GitLab ແລະໃນທີ່ສຸດກໍ່ໄດ້ຮັບເຄື່ອງມືອັດຕະໂນມັດທີ່ເຢັນ. ທີ່ຄົນໃນອະນາຄົດສາມາດໃຊ້ທີມໄດ້.

ພວກເຮົາເລີ່ມຕົ້ນບ່ອນໃດ?

ເພື່ອປະຕິບັດ autotests ແລະປະສົມປະສານເຂົ້າໄປໃນທໍ່, ພວກເຮົາຕ້ອງການກອບອັດຕະໂນມັດທີ່ສາມາດປ່ຽນແປງໄດ້ຢ່າງຍືດຫຍຸ່ນເພື່ອໃຫ້ເຫມາະສົມກັບຄວາມຕ້ອງການຂອງພວກເຮົາ. ໂດຍຫລັກການແລ້ວ, ຂ້າພະເຈົ້າຕ້ອງການທີ່ຈະໄດ້ຮັບມາດຕະຖານດຽວສໍາລັບເຄື່ອງຈັກ autotesting, ດັດແປງສໍາລັບການຝັງ autotests ເຂົ້າໄປໃນທໍ່. ສໍາລັບການປະຕິບັດພວກເຮົາເລືອກເຕັກໂນໂລຢີຕໍ່ໄປນີ້:

• Java,
• Maven,
• ເຊເລນຽມ,
• ໝາກແຕງ+ໝາກເຜັດ 4,
• ດຶງດູດ,
• GitLab.

ເປັນຫຍັງຊຸດນີ້ໂດຍສະເພາະ? Java ແມ່ນຫນຶ່ງໃນພາສາທີ່ນິຍົມທີ່ສຸດສໍາລັບການທົດສອບອັດຕະໂນມັດ, ແລະສະມາຊິກທີມງານທັງຫມົດເວົ້າມັນ. Selenium ແມ່ນການແກ້ໄຂທີ່ຊັດເຈນ. ແຕງ, ໃນບັນດາສິ່ງອື່ນໆ, ຄວນເພີ່ມຄວາມຫມັ້ນໃຈໃນຜົນໄດ້ຮັບຂອງການທົດສອບອັດຕະໂນມັດໃນພາກສ່ວນຂອງພະແນກທີ່ກ່ຽວຂ້ອງກັບການທົດສອບຄູ່ມື.

ການທົດສອບເສັ້ນດ່ຽວ

ໃນຄໍາສັ່ງທີ່ຈະບໍ່ reinvent ລໍ້, ພວກເຮົາໄດ້ເອົາການພັດທະນາຈາກ repositories ຕ່າງໆໃນ GitHub ເປັນພື້ນຖານສໍາລັບກອບແລະປັບໃຫ້ເຂົາເຈົ້າສໍາລັບຕົວເຮົາເອງ. ພວກເຮົາໄດ້ສ້າງບ່ອນເກັບມ້ຽນສໍາລັບຫ້ອງສະຫມຸດຫຼັກທີ່ມີຫຼັກຂອງກອບການທົດສອບອັດຕະໂນມັດແລະບ່ອນເກັບມ້ຽນທີ່ມີຕົວຢ່າງຄໍາຂອງການປະຕິບັດການທົດສອບອັດຕະໂນມັດຢູ່ໃນຫຼັກຂອງພວກເຮົາ. ແຕ່ລະທີມຕ້ອງໄດ້ເອົາຮູບພາບຄໍາແລະພັດທະນາການທົດສອບໃນມັນ, ປັບມັນເຂົ້າກັບໂຄງການຂອງພວກເຂົາ. ພວກ​ເຮົາ​ໄດ້​ນໍາ​ໃຊ້​ມັນ​ກັບ​ທະ​ນາ​ຄານ GitLab-CI​, ທີ່​ພວກ​ເຮົາ​ກໍາ​ນົດ​ຄ່າ​:

• ແລ່ນປະຈໍາວັນຂອງການທົດສອບລາຍລັກອັກສອນທັງຫມົດສໍາລັບແຕ່ລະໂຄງການ;
• ເປີດຕົວໃນທໍ່ກໍ່ສ້າງ.

ໃນຕອນທໍາອິດມີການທົດສອບບໍ່ຫຼາຍປານໃດ, ແລະເຂົາເຈົ້າໄດ້ຖືກດໍາເນີນຢູ່ໃນສາຍນ້ໍາຫນຶ່ງ. ກະທູ້ດຽວທີ່ແລ່ນຢູ່ໃນ GitLab Windows runner ເຫມາະສົມກັບພວກເຮົາຂ້ອນຂ້າງດີ: ການທົດສອບໄດ້ໂຫຼດ bench ການທົດສອບເບົາຫຼາຍແລະການນໍາໃຊ້ເກືອບບໍ່ມີຊັບພະຍາກອນ.

ເມື່ອເວລາຜ່ານໄປ, ຈໍານວນການທົດສອບອັດຕະໂນມັດນັບມື້ນັບຫຼາຍຂື້ນ, ແລະພວກເຮົາຄິດກ່ຽວກັບການແລ່ນພວກມັນແບບຂະຫນານ, ເມື່ອການແລ່ນເຕັມເວລາເລີ່ມຕົ້ນປະມານສາມຊົ່ວໂມງ. ບັນຫາອື່ນໆຍັງປາກົດ:

• ພວກເຮົາບໍ່ສາມາດກວດສອບໄດ້ວ່າການທົດສອບມີຄວາມໝັ້ນຄົງ;
• ການທົດສອບທີ່ດໍາເນີນການຫຼາຍຄັ້ງຕິດຕໍ່ກັນໃນເຄື່ອງທ້ອງຖິ່ນບາງຄັ້ງ crashed ໃນ CI.

ຕົວຢ່າງຂອງການຕັ້ງຄ່າ autotests:

<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>

 
ຕົວຢ່າງບົດລາຍງານ Allure

 
ການໂຫຼດຕົວແລ່ນໃນລະຫວ່າງການທົດສອບ (8 cores, 8 GB RAM, 1 thread)
 
ຂໍ້ດີຂອງການທົດສອບເສັ້ນດ່ຽວ:

• ງ່າຍທີ່ຈະຕັ້ງຄ່າແລະດໍາເນີນການ;
• ການເປີດຕົວໃນ CI ແມ່ນບໍ່ແຕກຕ່າງຈາກການເປີດຕົວໃນທ້ອງຖິ່ນ;
• ການທົດສອບບໍ່ມີຜົນກະທົບເຊິ່ງກັນແລະກັນ;
• ຄວາມຕ້ອງການຂັ້ນຕ່ໍາສໍາລັບຊັບພະຍາກອນນັກແລ່ນ.

ຂໍ້​ເສຍ​ຂອງ​ການ​ທົດ​ສອບ​ກະ​ທູ້​ດຽວ​:

• ໃຊ້ ເວ ລາ ດົນ ນານ ທີ່ ຈະ ສໍາ ເລັດ;
• ສະຖຽນລະພາບຍາວຂອງການທົດສອບ;
• ການ​ນໍາ​ໃຊ້​ຊັບ​ພະ​ຍາ​ກອນ​ນັກ​ແລ່ນ​ບໍ່​ໄດ້​ປະ​ສິດ​ທິ​ຜົນ​, ການ​ນໍາ​ໃຊ້​ຕ​່​ໍ​າ​ທີ່​ສຸດ​.

ການທົດສອບກ່ຽວກັບສ້ອມ JVM

ເນື່ອງຈາກພວກເຮົາບໍ່ໄດ້ດູແລລະຫັດຄວາມປອດໄພກະທູ້ໃນເວລາທີ່ປະຕິບັດກອບພື້ນຖານ, ວິທີທີ່ຈະແຈ້ງທີ່ສຸດທີ່ຈະດໍາເນີນການຂະຫນານແມ່ນ. cucumber-jvm-parallel-plugin ສໍາລັບ Maven. ປັ໊ກອິນແມ່ນງ່າຍທີ່ຈະຕັ້ງຄ່າ, ແຕ່ສໍາລັບການປະຕິບັດຂະຫນານທີ່ຖືກຕ້ອງ, ການທົດສອບອັດຕະໂນມັດຕ້ອງດໍາເນີນການຢູ່ໃນຕົວທ່ອງເວັບແຍກຕ່າງຫາກ. ບໍ່ມີຫຍັງເຮັດ, ຂ້ອຍຕ້ອງໃຊ້ Selenoid.

ເຊີບເວີ Selenoid ໄດ້ຖືກເປີດຕົວໃນເຄື່ອງທີ່ມີ 32 cores ແລະ 24 GB ຂອງ RAM. ຂອບເຂດຈໍາກັດໄດ້ຖືກກໍານົດຢູ່ທີ່ 48 ຕົວທ່ອງເວັບ - 1,5 threads ຕໍ່ຫຼັກແລະປະມານ 400 MB ຂອງ RAM. ດັ່ງນັ້ນ, ເວລາການທົດສອບໄດ້ຖືກຫຼຸດລົງຈາກສາມຊົ່ວໂມງເປັນ 40 ນາທີ. ການເລັ່ງການແລ່ນໄດ້ຊ່ວຍແກ້ໄຂບັນຫາສະຖຽນລະພາບ: ຕອນນີ້ພວກເຮົາສາມາດແລ່ນການທົດສອບອັດຕະໂນມັດໃໝ່ໄດ້ໄວ 20-30 ເທື່ອຈົນກວ່າພວກເຮົາແນ່ໃຈວ່າພວກມັນແລ່ນໄດ້ຢ່າງໝັ້ນໃຈ.
ຂໍ້ບົກຜ່ອງທໍາອິດຂອງການແກ້ໄຂແມ່ນການນໍາໃຊ້ຊັບພະຍາກອນຂອງນັກແລ່ນທີ່ມີຈໍານວນຂະຫນາດນ້ອຍຂອງກະທູ້ຂະຫນານ: ໃນ 4 cores ແລະ 8 GB ຂອງ RAM, ການທົດສອບແລ່ນຢ່າງຫມັ້ນຄົງໃນບໍ່ເກີນ 6 threads. ຂໍ້ເສຍທີສອງ: plugin ສ້າງຫ້ອງຮຽນນັກແລ່ນສໍາລັບແຕ່ລະສະຖານະການ, ບໍ່ວ່າພວກເຂົາຖືກເປີດຕົວຫຼາຍປານໃດ.

ສໍາຄັນ! ບໍ່ຜ່ານຕົວແປທີ່ມີ tags ກັບ argLineຕົວຢ່າງເຊັ່ນນີ້:

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

ຖ້າທ່ານຜ່ານແທັກດ້ວຍວິທີນີ້, plugin ຈະສ້າງ runners ສໍາລັບການທົດສອບທັງຫມົດ, ນັ້ນແມ່ນ, ມັນຈະພະຍາຍາມດໍາເນີນການທົດສອບທັງຫມົດ, ຂ້າມພວກມັນທັນທີຫຼັງຈາກການເປີດຕົວແລະສ້າງ JVM fork ຫຼາຍ.

ມັນຖືກຕ້ອງທີ່ຈະຖິ້ມຕົວແປທີ່ມີແທັກໃສ່ tags ໃນການຕັ້ງຄ່າ plugin, ເບິ່ງຕົວຢ່າງຂ້າງລຸ່ມນີ້. ວິທີການອື່ນທີ່ພວກເຮົາທົດສອບມີບັນຫາໃນການເຊື່ອມຕໍ່ plugin Allure.

ຕົວຢ່າງເວລາແລ່ນສໍາລັບ 6 ການທົດສອບສັ້ນທີ່ມີການຕັ້ງຄ່າທີ່ບໍ່ຖືກຕ້ອງ:

[INFO] Total time: 03:17 min

ຕົວຢ່າງຂອງເວລາທົດສອບຖ້າທ່ານໂອນແທັກໂດຍກົງໄປຫາ mvn... –Dcucumber.options:

[INFO] Total time: 44.467 s

ຕົວຢ່າງຂອງການຕັ້ງຄ່າ autotests:

<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 reruns)

ການໂຫຼດຕົວແລ່ນໃນລະຫວ່າງການທົດສອບ (8 cores, 8 GB RAM, 12 threads)
 
Pros:

• ການຕິດຕັ້ງງ່າຍ - ທ່ານພຽງແຕ່ຕ້ອງການເພີ່ມ plugin;
• ຄວາມ​ສາ​ມາດ​ໃນ​ການ​ພ້ອມ​ກັນ​ປະ​ຕິ​ບັດ​ຈໍາ​ນວນ​ຫຼາຍ​ຂອງ​ການ​ທົດ​ສອບ​;
• ການເລັ່ງຄວາມຄົງຕົວຂອງການທົດສອບຂໍຂອບໃຈກັບຂັ້ນຕອນທີ 1. 

Cons:

• ຕ້ອງການຫຼາຍ OS/containers;
• ການບໍລິໂພກຊັບພະຍາກອນສູງສໍາລັບແຕ່ລະສ້ອມ;
• ປັ໊ກອິນແມ່ນເກົ່າແລ້ວແລະບໍ່ຮອງຮັບອີກຕໍ່ໄປ. 

ວິທີການເອົາຊະນະຄວາມບໍ່ສະຖຽນລະພາບ 

ບ່ອນນັ່ງທົດສອບແມ່ນບໍ່ເຫມາະສົມ, ຄືກັນກັບການທົດສອບອັດຕະໂນມັດ. ມັນບໍ່ແປກໃຈທີ່ພວກເຮົາມີຈໍານວນການທົດສອບ flacky. ມາຮອດກູ້ໄພ maven surefire plugin, ເຊິ່ງອອກຈາກກ່ອງສະຫນັບສະຫນູນການເລີ່ມຕົ້ນການທົດສອບທີ່ລົ້ມເຫລວຄືນໃຫມ່. ທ່ານຈໍາເປັນຕ້ອງໄດ້ປັບປຸງສະບັບ plugin ເປັນຢ່າງຫນ້ອຍ 2.21 ແລະຂຽນຫນຶ່ງແຖວທີ່ມີຈໍານວນການເລີ່ມຕົ້ນໃຫມ່ໃນ pom file ຫຼືຜ່ານມັນເປັນການໂຕ້ຖຽງກັບ Maven.

ຕົວຢ່າງຂອງການຕັ້ງຄ່າ autotests:

   	
<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"

Pros:

• ບໍ່ຈໍາເປັນຕ້ອງເສຍເວລາໃນການວິເຄາະການທົດສອບທີ່ບໍ່ຫມັ້ນຄົງໃນເວລາທີ່ມັນຂັດຂ້ອງ;
• ບັນຫາຄວາມຫມັ້ນຄົງຂອງ bench ການທົດສອບສາມາດໄດ້ຮັບການຫຼຸດຜ່ອນ.

Cons:

• ຂໍ້ບົກພ່ອງລອຍສາມາດພາດໄດ້;
• ເວລາແລ່ນເພີ່ມຂຶ້ນ.

ການທົດສອບຂະຫນານກັບ Cucumber 4 ຫໍສະຫມຸດ

ຈໍານວນການທົດສອບເພີ່ມຂຶ້ນທຸກໆມື້. ພວກເຮົາຄິດກ່ຽວກັບການເລັ່ງການແລ່ນອີກຄັ້ງ. ນອກຈາກນັ້ນ, ຂ້າພະເຈົ້າຕ້ອງການປະສົມປະສານການທົດສອບຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້ເຂົ້າໄປໃນທໍ່ການປະກອບຄໍາຮ້ອງສະຫມັກ. ປັດໃຈສໍາຄັນແມ່ນວ່າການຜະລິດຂອງນັກແລ່ນໃຊ້ເວລາດົນເກີນໄປໃນເວລາທີ່ແລ່ນຂະຫນານໂດຍໃຊ້ plugin Maven.

ໃນ​ເວ​ລາ​ນັ້ນ, Cucumber 4 ໄດ້​ຖືກ​ປ່ອຍ​ອອກ​ມາ​ແລ້ວ, ສະ​ນັ້ນ​ພວກ​ເຮົາ​ໄດ້​ຕັດ​ສິນ​ໃຈ​ທີ່​ຈະ​ຂຽນ​ໃຫມ່ kernel ສໍາ​ລັບ​ການ​ສະ​ບັບ​ນີ້. ໃນບັນທຶກການປ່ອຍພວກເຮົາໄດ້ຖືກສັນຍາວ່າເປີດຕົວຂະຫນານຢູ່ໃນລະດັບກະທູ້. ໃນທາງທິດສະດີ, ນີ້ຄວນຈະເປັນ:

• ເລັ່ງການເຮັດວຽກຂອງ autotests ຢ່າງຫຼວງຫຼາຍໂດຍການເພີ່ມຈໍານວນຂອງກະທູ້;
• ລົບລ້າງການສູນເສຍເວລາໃນການສ້າງນັກແລ່ນສໍາລັບແຕ່ລະ autotest.

ການເພີ່ມປະສິດທິພາບກອບສໍາລັບການທົດສອບອັດຕະໂນມັດຫຼາຍກະທູ້ໄດ້ກາຍເປັນເລື່ອງທີ່ບໍ່ມີຄວາມຫຍຸ້ງຍາກ. Cucumber 4 ດໍາເນີນການທົດສອບແຕ່ລະຄົນໃນຫົວຂໍ້ທີ່ອຸທິດຕົນຕັ້ງແຕ່ຕົ້ນຈົນຈົບ, ດັ່ງນັ້ນບາງສິ່ງທີ່ຄົງທີ່ທົ່ວໄປໄດ້ຖືກປ່ຽນເປັນຕົວແປ ThreadLocal. 
ສິ່ງທີ່ສໍາຄັນໃນເວລາທີ່ການແປງໂດຍໃຊ້ Idea refactoring tools ແມ່ນເພື່ອກວດເບິ່ງສະຖານທີ່ທີ່ຕົວແປໄດ້ຖືກປຽບທຽບ (ຕົວຢ່າງ, ກວດເບິ່ງສໍາລັບ null). ນອກຈາກນັ້ນ, ທ່ານຈໍາເປັນຕ້ອງເພີ່ມ plugin Allure ກັບຄໍາບັນຍາຍຂອງ Junit Runner class.

ຕົວຢ່າງຂອງການຕັ້ງຄ່າ autotests:

 
<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 reruns)

ການໂຫຼດຕົວແລ່ນໃນລະຫວ່າງການທົດສອບ (8 cores, 8 GB RAM, 24 threads)

Pros:

• ການບໍລິໂພກຊັບພະຍາກອນຕໍ່າ;
• ສະຫນັບສະຫນູນພື້ນເມືອງຈາກແຕງ - ບໍ່ມີເຄື່ອງມືເພີ່ມເຕີມທີ່ຕ້ອງການ;
• ຄວາມສາມາດໃນການແລ່ນຫຼາຍກວ່າ 6 threads ຕໍ່ຫຼັກຂອງໂປເຊດເຊີ.

Cons:

• ທ່ານຈໍາເປັນຕ້ອງໃຫ້ແນ່ໃຈວ່າລະຫັດສະຫນັບສະຫນູນການປະຕິບັດຫຼາຍກະທູ້;
• ເກນເຂົ້າເພີ່ມຂຶ້ນ.

ລາຍງານ Allure ໃນຫນ້າ GitLab

ຫຼັງຈາກແນະນໍາການປະຕິບັດຫຼາຍກະທູ້, ພວກເຮົາເລີ່ມໃຊ້ເວລາຫຼາຍໃນການວິເຄາະບົດລາຍງານ. ໃນເວລານັ້ນ, ພວກເຮົາຕ້ອງອັບໂຫລດແຕ່ລະບົດລາຍງານເປັນສິ່ງປະດິດໃສ່ GitLab, ຫຼັງຈາກນັ້ນດາວໂຫລດມັນແລະຖອດມັນອອກ. ມັນບໍ່ສະດວກຫຼາຍແລະໃຊ້ເວລາດົນ. ແລະຖ້າຜູ້ອື່ນຕ້ອງການເບິ່ງບົດລາຍງານສໍາລັບຕົນເອງ, ຫຼັງຈາກນັ້ນເຂົາເຈົ້າຈະຕ້ອງດໍາເນີນການດຽວກັນ. ພວກເຮົາຕ້ອງການໄດ້ຮັບຄໍາຄຶດຄໍາເຫັນໄວຂຶ້ນ, ແລະພວກເຮົາໄດ້ພົບການແກ້ໄຂ - ຫນ້າ GitLab . ນີ້ແມ່ນຄຸນສົມບັດໃນຕົວທີ່ສາມາດໃຊ້ໄດ້ອອກຈາກກ່ອງໃນທຸກລຸ້ນຫຼ້າສຸດຂອງ GitLab. ອະນຸຍາດໃຫ້ທ່ານປັບໃຊ້ສະຖານທີ່ສະຖິດຢູ່ໃນເຊີບເວີຂອງທ່ານແລະເຂົ້າຫາພວກມັນຜ່ານທາງເຊື່ອມຕໍ່ໂດຍກົງ.

ພາບໜ້າຈໍທັງໝົດຂອງບົດລາຍງານ Allure ໄດ້ຖືກຖ່າຍຢູ່ໃນໜ້າ GitLab. ສະຄຣິບເພື່ອນຳໃຊ້ບົດລາຍງານໄປໃສ່ໜ້າ GitLab - ໃນ Windows PowerShell (ກ່ອນນີ້, ທ່ານຕ້ອງດໍາເນີນການ autotests):

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

ເສັ້ນທາງລຸ່ມແມ່ນຫຍັງ 

ດັ່ງນັ້ນ, ຖ້າທ່ານຄິດກ່ຽວກັບວ່າທ່ານຕ້ອງການລະຫັດຄວາມປອດໄພຂອງ Thread ໃນກອບ autotest ແຕງ, ໃນປັດຈຸບັນຄໍາຕອບແມ່ນຈະແຈ້ງ - ດ້ວຍ Cucumber 4 ມັນງ່າຍທີ່ຈະປະຕິບັດມັນ, ດັ່ງນັ້ນການເພີ່ມຈໍານວນກະທູ້ທີ່ເປີດຕົວພ້ອມກັນຢ່າງຫຼວງຫຼາຍ. ດ້ວຍວິທີການແລ່ນການທົດສອບນີ້, ຄໍາຖາມໃນປັດຈຸບັນກາຍເປັນກ່ຽວກັບການປະຕິບັດຂອງເຄື່ອງຈັກທີ່ມີ Selenoid ແລະ bench ທົດສອບ.

ການປະຕິບັດໄດ້ສະແດງໃຫ້ເຫັນວ່າການແລ່ນ autotests ໃນກະທູ້ຊ່ວຍໃຫ້ທ່ານສາມາດຫຼຸດຜ່ອນການບໍລິໂພກຊັບພະຍາກອນໃຫ້ຫນ້ອຍທີ່ສຸດດ້ວຍການປະຕິບັດທີ່ດີທີ່ສຸດ. ດັ່ງທີ່ເຫັນໄດ້ຈາກກາຟ, ຫົວຂໍ້ສອງເທົ່າບໍ່ໄດ້ນໍາໄປສູ່ການເລັ່ງທີ່ຄ້າຍຄືກັນໃນການທົດສອບການປະຕິບັດ. ຢ່າງໃດກໍຕາມ, ພວກເຮົາສາມາດເພີ່ມຫຼາຍກວ່າ 2 ການທົດສອບອັດຕະໂນມັດໃນການກໍ່ສ້າງຄໍາຮ້ອງສະຫມັກ, ເຊິ່ງເຖິງແມ່ນວ່າຈະມີ 200 reruns ໃນປະມານ 5 ນາທີ. ນີ້ອະນຸຍາດໃຫ້ທ່ານໄດ້ຮັບຄໍາຄຶດຄໍາເຫັນຢ່າງໄວວາຈາກພວກເຂົາ, ແລະ, ຖ້າຈໍາເປັນ, ປ່ຽນແປງແລະເຮັດຊ້ໍາຂັ້ນຕອນອີກເທື່ອຫນຶ່ງ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com