Το τμήμα μας δημιουργεί πλήρως αυτόματους αγωγούς για την εκτόξευση νέων εκδόσεων εφαρμογών στο περιβάλλον παραγωγής. Φυσικά, αυτό απαιτεί αυτοματοποιημένες λειτουργικές δοκιμές. Κάτω από την περικοπή υπάρχει μια ιστορία για το πώς, ξεκινώντας με τη δοκιμή ενός νήματος σε ένα τοπικό μηχάνημα, προχωρήσαμε σε αυτόματες δοκιμές πολλαπλών νημάτων που εκτελούνται στο Selenoid στη γραμμή κατασκευής με μια αναφορά Allure στις σελίδες του GitLab και τελικά αποκτήσαμε ένα υπέροχο εργαλείο αυτοματισμού που Οι μελλοντικοί άνθρωποι μπορούν να χρησιμοποιούν ομάδες.
Από πού ξεκινήσαμε;
Για να εφαρμόσουμε αυτόματες δοκιμές και να τις ενσωματώσουμε στη διοχέτευση, χρειαζόμασταν ένα πλαίσιο αυτοματισμού που θα μπορούσε να αλλάξει ευέλικτα για να ταιριάζει στις ανάγκες μας. Στην ιδανική περίπτωση, ήθελα να αποκτήσω ένα ενιαίο πρότυπο για τη μηχανή αυτόματης δοκιμής, προσαρμοσμένο για την ενσωμάτωση των αυτόματων δοκιμών στον αγωγό. Για την υλοποίηση επιλέξαμε τις παρακάτω τεχνολογίες:
- Ιάβα,
- Maven,
- Σελήνιο,
- Αγγούρι+JUNIT 4,
- Δελεάζω,
- GitLab.
Γιατί το συγκεκριμένο σετ; Η Java είναι μια από τις πιο δημοφιλείς γλώσσες για αυτοματοποιημένες δοκιμές και όλα τα μέλη της ομάδας τη μιλούν. Το σελήνιο είναι η προφανής λύση. Το αγγούρι, μεταξύ άλλων, υποτίθεται ότι θα αυξήσει την εμπιστοσύνη στα αποτελέσματα των αυτοματοποιημένων δοκιμών από την πλευρά των τμημάτων που εμπλέκονται σε χειροκίνητες δοκιμές.
Δοκιμές μονού νήματος
Για να μην επανεφεύρουμε τον τροχό, χρησιμοποιήσαμε τις εξελίξεις από διάφορα αποθετήρια στο GitHub ως βάση για το πλαίσιο και τις προσαρμόσαμε για εμάς. Δημιουργήσαμε ένα αποθετήριο για την κύρια βιβλιοθήκη με τον πυρήνα του πλαισίου αυτόματης δοκιμής και ένα αποθετήριο με ένα Gold παράδειγμα εφαρμογής αυτόματων δοκιμών στον πυρήνα μας. Κάθε ομάδα έπρεπε να πάρει την εικόνα του Gold και να αναπτύξει δοκιμές σε αυτήν, προσαρμόζοντάς την στο έργο της. Το αναπτύξαμε στην τράπεζα GitLab-CI, στην οποία ρυθμίσαμε:
- ημερήσιες εκτελέσεις όλων των γραπτών αυτόματων δοκιμών για κάθε έργο.
- εκτοξεύεται στον αγωγό κατασκευής.
Στην αρχή υπήρχαν λίγες δοκιμές και πραγματοποιήθηκαν σε ένα ρεύμα. Η εκτέλεση ενός νήματος στο πρόγραμμα εκτέλεσης των Windows 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>
Παράδειγμα αναφοράς Allure
Φόρτωση δρομέα κατά τη διάρκεια δοκιμών (8 πυρήνες, 8 GB RAM, 1 νήμα)
Πλεονεκτήματα των δοκιμών μονού νήματος:
- εύκολο να ρυθμιστεί και να τρέξει?
- Οι εκτοξεύσεις στο CI ουσιαστικά δεν διαφέρουν από τις τοπικές εκκινήσεις.
- οι δοκιμές δεν επηρεάζουν η μία την άλλη.
- ελάχιστες απαιτήσεις για πόρους δρομέα.
Μειονεκτήματα των δοκιμών μονού νήματος:
- χρειάζεται πολύς χρόνος για να ολοκληρωθεί.
- μακρά σταθεροποίηση των δοκιμών.
- αναποτελεσματική χρήση των πόρων του δρομέα, εξαιρετικά χαμηλή χρήση.
Δοκιμές σε πιρούνια JVM
Δεδομένου ότι δεν φροντίσαμε για τον ασφαλή κώδικα νημάτων κατά την υλοποίηση του βασικού πλαισίου, ο πιο προφανής τρόπος για παράλληλη εκτέλεση ήταν για τον Maven. Το plugin είναι εύκολο στη διαμόρφωση, αλλά για σωστή παράλληλη λειτουργία, οι αυτόματες δοκιμές πρέπει να εκτελούνται σε ξεχωριστά προγράμματα περιήγησης. Δεν υπάρχει τίποτα να κάνω, έπρεπε να χρησιμοποιήσω το Selenoid.
Ο διακομιστής Selenoid κυκλοφόρησε σε ένα μηχάνημα με 32 πυρήνες και 24 GB μνήμης RAM. Το όριο ορίστηκε σε 48 προγράμματα περιήγησης - 1,5 νήματα ανά πυρήνα και περίπου 400 MB μνήμης RAM. Ως αποτέλεσμα, ο χρόνος δοκιμής μειώθηκε από τρεις ώρες σε 40 λεπτά. Η επιτάχυνση των τρεξίματος βοήθησε στην επίλυση του προβλήματος σταθεροποίησης: τώρα μπορούσαμε να εκτελέσουμε γρήγορα νέες αυτόματες δοκιμές 20–30 φορές μέχρι να είμαστε σίγουροι ότι εκτελούνταν αξιόπιστα.
Το πρώτο μειονέκτημα της λύσης ήταν η υψηλή χρήση πόρων runner με μικρό αριθμό παράλληλων νημάτων: σε 4 πυρήνες και 8 GB μνήμης RAM, οι δοκιμές έτρεχαν σταθερά σε όχι περισσότερα από 6 νήματα. Το δεύτερο μειονέκτημα: το πρόσθετο δημιουργεί κατηγορίες δρομέων για κάθε σενάριο, ανεξάρτητα από το πόσες από αυτές εκκινούνται.
Σημαντικό! Μην μεταβιβάζετε μια μεταβλητή με ετικέτες σε argLine, για παράδειγμα, όπως αυτό:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Εάν περάσετε την ετικέτα με αυτόν τον τρόπο, το πρόσθετο θα δημιουργήσει runners για όλες τις δοκιμές, δηλαδή θα προσπαθήσει να εκτελέσει όλες τις δοκιμές, παρακάμπτοντάς τις αμέσως μετά την εκκίνηση και δημιουργώντας πολλά πιρούνια JVM.
Είναι σωστό να ρίχνουμε μια μεταβλητή με ετικέτα ετικέτες στις ρυθμίσεις της προσθήκης, δείτε το παρακάτω παράδειγμα. Άλλες μέθοδοι που δοκιμάσαμε αντιμετωπίζουν προβλήματα με τη σύνδεση της προσθήκης Allure.
Παράδειγμα χρόνου εκτέλεσης για 6 σύντομες δοκιμές με λανθασμένες ρυθμίσεις:
[INFO] Total time: 03:17 min
Παράδειγμα χρόνου δοκιμαστικής εκτέλεσης εάν μεταφέρετε απευθείας την ετικέτα σε mvn... –Dcucumber.επιλογές:
[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 GB RAM, 12 νήματα)
Πλεονεκτήματα:
- εύκολη εγκατάσταση - χρειάζεται απλώς να προσθέσετε ένα πρόσθετο.
- την ικανότητα ταυτόχρονης εκτέλεσης μεγάλου αριθμού δοκιμών.
- επιτάχυνση της σταθεροποίησης δοκιμής χάρη στο βήμα 1.
Μειονεκτήματα:
- Απαιτούνται πολλαπλά λειτουργικά συστήματα/κοντέινερ.
- υψηλή κατανάλωση πόρων για κάθε πιρούνι.
- Η προσθήκη είναι παλιά και δεν υποστηρίζεται πλέον.
Πώς να ξεπεράσετε την αστάθεια
Οι πάγκοι δοκιμών δεν είναι ιδανικοί, όπως και οι ίδιοι οι αυτοδοκιμές. Δεν αποτελεί έκπληξη το γεγονός ότι έχουμε μια σειρά από ασταθείς δοκιμές. Ήρθε στη διάσωση, το οποίο εκτός του πλαισίου υποστηρίζει επανεκκίνηση αποτυχημένων δοκιμών. Πρέπει να ενημερώσετε την έκδοση της προσθήκης σε τουλάχιστον 2.21 και να γράψετε μία γραμμή με τον αριθμό των επανεκκινήσεων στο αρχείο pom ή να τη μεταβιβάσετε ως όρισμα στο 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"Πλεονεκτήματα:
- Δεν χρειάζεται να χάνετε χρόνο για την ανάλυση μιας ασταθούς δοκιμής όταν συντρίβεται.
- Τα προβλήματα σταθερότητας του πάγκου δοκιμών μπορούν να μετριαστούν.
Μειονεκτήματα:
- Τα ελαττώματα που αιωρούνται μπορούν να χαθούν.
- ο χρόνος λειτουργίας αυξάνεται.
Παράλληλες δοκιμές με τη βιβλιοθήκη Cucumber 4
Ο αριθμός των τεστ αυξανόταν κάθε μέρα. Σκεφτήκαμε πάλι να επιταχύνουμε τις διαδρομές. Επιπλέον, ήθελα να ενσωματώσω όσο το δυνατόν περισσότερες δοκιμές στη γραμμή συναρμολόγησης εφαρμογών. Ο κρίσιμος παράγοντας ήταν ότι η δημιουργία δρομέων άργησε πολύ όταν εκτελούνταν παράλληλα χρησιμοποιώντας το πρόσθετο Maven.
Εκείνη την εποχή, το Cucumber 4 είχε ήδη κυκλοφορήσει, οπότε αποφασίσαμε να ξαναγράψουμε τον πυρήνα για αυτήν την έκδοση. Στις σημειώσεις έκδοσης μας υποσχέθηκαν παράλληλη εκτόξευση σε επίπεδο νήματος. Θεωρητικά αυτό θα έπρεπε να ήταν:
- επιταχύνει σημαντικά τη λειτουργία των αυτόματων δοκιμών αυξάνοντας τον αριθμό των νημάτων.
- εξαλείψτε την απώλεια χρόνου για τη δημιουργία δρομέων για κάθε αυτόματη δοκιμή.
Η βελτιστοποίηση του πλαισίου για αυτοδοκιμές πολλαπλών νημάτων αποδείχθηκε ότι δεν ήταν τόσο δύσκολη. Το Cucumber 4 εκτελεί κάθε μεμονωμένη δοκιμή σε ένα αποκλειστικό νήμα από την αρχή μέχρι το τέλος, επομένως ορισμένα κοινά στατικά πράγματα μετατράπηκαν απλώς σε μεταβλητές ThreadLocal.
Το κύριο πράγμα κατά τη μετατροπή με τη χρήση εργαλείων αναδιαμόρφωσης ιδεών είναι να ελέγξετε τα μέρη όπου συγκρίθηκε η μεταβλητή (για παράδειγμα, έλεγχος για μηδενική τιμή). Επιπλέον, πρέπει να προσθέσετε το πρόσθετο Allure στον σχολιασμό της κλάσης Junit Runner.
Παράδειγμα ρύθμισης αυτόματων δοκιμών:
<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 GB RAM, 24 νήματα)
Πλεονεκτήματα:
- χαμηλή κατανάλωση πόρων·
- εγγενής υποστήριξη από το Cucumber - δεν απαιτούνται πρόσθετα εργαλεία.
- τη δυνατότητα εκτέλεσης περισσότερων από 6 νημάτων ανά πυρήνα επεξεργαστή.
Μειονεκτήματα:
- πρέπει να βεβαιωθείτε ότι ο κώδικας υποστηρίζει εκτέλεση πολλαπλών νημάτων.
- το όριο εισόδου αυξάνεται.
Αναφορές Allure σε σελίδες 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
Με αποτέλεσμα η
Έτσι, εάν σκεφτόσασταν εάν χρειάζεστε ασφαλή κώδικα Thread στο πλαίσιο αυτόματης δοκιμής Cucumber, τώρα η απάντηση είναι προφανής - με το Cucumber 4 είναι εύκολο να το εφαρμόσετε, αυξάνοντας έτσι σημαντικά τον αριθμό των νημάτων που ξεκινούν ταυτόχρονα. Με αυτήν τη μέθοδο εκτέλεσης δοκιμών, το ερώτημα τώρα γίνεται για την απόδοση του μηχανήματος με το Selenoid και τον πάγκο δοκιμών.
Η πρακτική έχει δείξει ότι η εκτέλεση αυτόματων δοκιμών σε νήματα σάς επιτρέπει να μειώσετε την κατανάλωση πόρων στο ελάχιστο με την καλύτερη απόδοση. Όπως φαίνεται από τα γραφήματα, ο διπλασιασμός των νημάτων δεν οδηγεί σε παρόμοια επιτάχυνση στις δοκιμές απόδοσης. Ωστόσο, μπορέσαμε να προσθέσουμε περισσότερες από 2 αυτοματοποιημένες δοκιμές στο build της εφαρμογής, οι οποίες ακόμη και με 200 επαναλήψεις εκτελούνται σε περίπου 5 λεπτά. Αυτό σας επιτρέπει να λαμβάνετε γρήγορα σχόλια από αυτούς και, εάν είναι απαραίτητο, να κάνετε αλλαγές και να επαναλάβετε τη διαδικασία ξανά.
Πηγή: www.habr.com