Ένα από τα προβλήματα που αντιμετωπίζουν συχνά οι πωλητές λογισμικού πολλών προϊόντων είναι η επικάλυψη των ικανοτήτων μηχανικών - προγραμματιστών, ελεγκτών και διαχειριστών υποδομής - σχεδόν σε κάθε ομάδα. Αυτό ισχύει και για ακριβούς μηχανικούς - ειδικούς στον τομέα των δοκιμών φορτίου.
Αντί να εκτελούν τα άμεσα καθήκοντά τους και να χρησιμοποιούν τη μοναδική τους εμπειρία για τη δημιουργία μιας διαδικασίας δοκιμής φορτίου, να επιλέγουν μια μεθοδολογία, βέλτιστες μετρήσεις και να γράφουν αυτόματες δοκιμές σύμφωνα με τα προφίλ φορτίου, οι μηχανικοί συχνά πρέπει να αναπτύξουν υποδομές δοκιμών από την αρχή, να διαμορφώσουν εργαλεία φόρτωσης και να τα ενσωματώσουν σε συστήματα CI, ρυθμίζουν την παρακολούθηση και τη δημοσίευση εκθέσεων.
Μπορείτε να βρείτε λύσεις σε ορισμένα οργανωτικά προβλήματα στις δοκιμές που χρησιμοποιούμε στη Positive Technologies in . Και σε αυτό, θα μιλήσω για τη δυνατότητα ενσωμάτωσης δοκιμών φορτίου σε έναν κοινό αγωγό CI χρησιμοποιώντας την έννοια της «δοκιμής φορτίου ως υπηρεσία» (δοκιμή φορτίου ως υπηρεσία). Θα μάθετε πώς και ποιες εικόνες docker πηγών φορτίου μπορούν να χρησιμοποιηθούν στον αγωγό CI. πώς να συνδέσετε πηγές φορτίου στο έργο CI χρησιμοποιώντας ένα πρότυπο κατασκευής. πώς φαίνεται ο αγωγός επίδειξης για την εκτέλεση δοκιμών φόρτωσης και τη δημοσίευση των αποτελεσμάτων. Το άρθρο μπορεί να είναι χρήσιμο για μηχανικούς δοκιμών λογισμικού και μηχανικούς αυτοματισμού στο CI που σκέφτονται την αρχιτεκτονική του συστήματος φορτίου τους.
Η ουσία της έννοιας
Η έννοια της δοκιμής φόρτωσης ως υπηρεσίας συνεπάγεται τη δυνατότητα ενσωμάτωσης των εργαλείων φόρτωσης Apache JMeter, Yandex.Tank και των δικών σας πλαισίων σε ένα αυθαίρετο σύστημα συνεχούς ενοποίησης. Η επίδειξη θα είναι για το GitLab CI, αλλά οι αρχές είναι κοινές σε όλα τα συστήματα CI.
Η δοκιμή φορτίου ως υπηρεσία είναι μια κεντρική υπηρεσία για τη δοκιμή φορτίου. Οι δοκιμές φόρτωσης εκτελούνται σε αποκλειστικές ομάδες πρακτόρων, τα αποτελέσματα δημοσιεύονται αυτόματα στις σελίδες GitLab, Influx DB και Grafana ή σε συστήματα αναφοράς δοκιμών (TestRail, ReportPortal κ.λπ.). Ο αυτοματισμός και η κλιμάκωση υλοποιούνται όσο το δυνατόν πιο απλά - προσθέτοντας και παραμετροποιώντας το συνηθισμένο πρότυπο gitlab-ci.yml στο έργο GitLab CI.
Το πλεονέκτημα αυτής της προσέγγισης είναι ότι ολόκληρη η υποδομή CI, οι πράκτορες φορτίου, οι εικόνες docker των πηγών φορτίου, οι αγωγοί δοκιμών και οι αναφορές δημοσίευσης διατηρούνται από ένα κεντρικό τμήμα αυτοματισμού (μηχανικοί DevOps), ενώ οι μηχανικοί δοκιμών φορτίου μπορούν να επικεντρώσουν τις προσπάθειές τους στην ανάπτυξη δοκιμών και ανάλυση των αποτελεσμάτων τους, χωρίς να ασχολούνται με θέματα υποδομής.
Για απλότητα της περιγραφής, θα υποθέσουμε ότι η εφαρμογή-στόχος ή ο διακομιστής που βρίσκεται υπό δοκιμή έχει ήδη αναπτυχθεί και ρυθμιστεί εκ των προτέρων (μπορούν να χρησιμοποιηθούν αυτοματοποιημένα σενάρια σε Python, SaltStack, Ansible, κ.λπ. για αυτό). Στη συνέχεια, ολόκληρη η έννοια της δοκιμής φορτίου ως υπηρεσία χωρίζεται σε τρία στάδια: προετοιμασία, δοκιμή, δημοσίευση εκθέσεων. Περισσότερες λεπτομέρειες στο διάγραμμα (όλες οι εικόνες μπορούν να κάνουν κλικ):
Βασικές έννοιες και ορισμοί στη δοκιμή φορτίου
Κατά τη διενέργεια δοκιμών φορτίου, προσπαθούμε να τηρούμε , χρησιμοποιήστε την κατάλληλη ορολογία και προτεινόμενες μετρήσεις. Θα δώσω μια σύντομη λίστα με τις κύριες έννοιες και τους ορισμούς στη δοκιμή φορτίου.
Πράκτορας φόρτωσης - μια εικονική μηχανή στην οποία θα εκκινηθεί η εφαρμογή - η πηγή φόρτωσης (Apache JMeter, Yandex.Tank ή μια αυτο-γραμμένη μονάδα φόρτωσης).
Στόχος δοκιμής (στόχος) - διακομιστής ή εφαρμογή εγκατεστημένη στον διακομιστή που θα υποβληθεί σε φόρτωση.
Σενάριο δοκιμής (δοκιμαστική περίπτωση) - ένα σύνολο παραμετροποιημένων βημάτων: ενέργειες χρήστη και αναμενόμενες αντιδράσεις σε αυτές τις ενέργειες, με σταθερά αιτήματα δικτύου και αποκρίσεις, ανάλογα με τις καθορισμένες παραμέτρους.
Προφίλ ή σχέδιο φόρτωσης (προφίλ) - στις (Ενότητα 4.2.4, σελ. 43) τα προφίλ φορτίου ορίζουν μετρήσεις που είναι κρίσιμες για μια συγκεκριμένη δοκιμή και επιλογές για την αλλαγή των παραμέτρων φορτίου κατά τη διάρκεια της δοκιμής. Μπορείτε να δείτε παραδείγματα προφίλ στο σχήμα.
Δοκιμή — ένα σενάριο με ένα προκαθορισμένο σύνολο παραμέτρων.
Πρόγραμμα δοκιμής (δοκιμαστικό σχέδιο) - ένα σύνολο δοκιμών και ένα προφίλ φορτίου.
Testran (testrun) - μια επανάληψη εκτέλεσης μιας δοκιμής με ένα πλήρως εκτελεσμένο σενάριο φόρτωσης και τη ληφθείσα αναφορά.
Αίτημα δικτύου (αίτημα) — Ένα αίτημα HTTP που αποστέλλεται από έναν πράκτορα σε έναν στόχο.
Απόκριση δικτύου (απόκριση) — Μια απάντηση HTTP που αποστέλλεται από τον στόχο στον πράκτορα.
Κωδικός απόκρισης HTTP (κατάσταση αποκρίσεων HTTP) - τυπικός κωδικός απόκρισης από τον διακομιστή εφαρμογής.
Μια συναλλαγή είναι ένας πλήρης κύκλος αιτήματος-απόκρισης. Μια συναλλαγή υπολογίζεται από την έναρξη της αποστολής ενός αιτήματος (αίτημα) έως την ολοκλήρωση της λήψης μιας απάντησης (απάντηση).
Κατάσταση συναλλαγής - εάν ήταν δυνατή η επιτυχής ολοκλήρωση του κύκλου αιτήματος-απόκρισης. Εάν υπήρξε κάποιο σφάλμα σε αυτόν τον κύκλο, τότε ολόκληρη η συναλλαγή θεωρείται ανεπιτυχής.
Χρόνος απόκρισης (λανθάνουσα κατάσταση) - ο χρόνος από το τέλος της αποστολής ενός αιτήματος (αίτημα) έως την έναρξη της λήψης απάντησης (απάντηση).
Φόρτωση μετρήσεων — τα χαρακτηριστικά της φορτωμένης υπηρεσίας και του παράγοντα φόρτωσης που προσδιορίζονται κατά τη διαδικασία της δοκιμής φορτίου.
Βασικές μετρήσεις για τη μέτρηση των παραμέτρων φορτίου
Μερικά από τα πιο συχνά χρησιμοποιούμενα και προτεινόμενα στη μεθοδολογία (σελ. 36, 52) οι μετρήσεις φαίνονται στον παρακάτω πίνακα. Παρόμοιες μετρήσεις για παράγοντα και στόχο παρατίθενται στην ίδια γραμμή.
Μετρήσεις για τον παράγοντα φόρτωσης
Μετρήσεις του συστήματος ή της εφαρμογής-στόχου που δοκιμάζεται υπό φορτίο
ΠΟΣΟΤΗΤΑ vCPU και μνήμη RAM,
Disk - χαρακτηριστικά «σιδήρου» του παράγοντα φόρτωσης
CPU, Μνήμη, χρήση δίσκου - δυναμική της CPU, της μνήμης και της φόρτωσης δίσκου
στη διαδικασία της δοκιμής. Συνήθως μετριέται ως ποσοστό του
μέγιστες διαθέσιμες τιμές
διακίνηση δικτύου (on load agent) - απόδοση
διεπαφή δικτύου στον διακομιστή,
όπου είναι εγκατεστημένο το load agent.
Συνήθως μετράται σε byte ανά δευτερόλεπτο (bps)
διακίνηση δικτύου(στον στόχο) - εύρος ζώνης διεπαφής δικτύου
στον διακομιστή προορισμού. Συνήθως μετράται σε byte ανά δευτερόλεπτο (bps)
Εικονικοί χρήστες- τον αριθμό των εικονικών χρηστών,
υλοποίηση σεναρίων φόρτωσης και
μίμηση πραγματικών ενεργειών χρήστη
Κατάσταση εικονικών χρηστών, Επιτυχία/Αποτυχία/Σύνολο — αριθμός επιτυχών και
ανεπιτυχείς καταστάσεις εικονικών χρηστών
για σενάρια φόρτωσης, καθώς και τον συνολικό αριθμό τους.
Γενικά αναμένεται ότι όλοι οι χρήστες μπόρεσαν να ολοκληρώσουν
όλες οι εργασίες σας που καθορίζονται στο προφίλ φόρτωσης.
Οποιοδήποτε σφάλμα θα σημαίνει ότι ένας πραγματικός χρήστης δεν θα μπορεί να το κάνει
λύστε το πρόβλημά σας όταν εργάζεστε με το σύστημα
Αιτήματα ανά δευτερόλεπτο (λεπτό)- τον αριθμό των αιτημάτων δικτύου ανά δευτερόλεπτο (ή λεπτό).
Ένα σημαντικό χαρακτηριστικό ενός load agent είναι πόσα αιτήματα μπορεί να δημιουργήσει.
Στην πραγματικότητα, πρόκειται για απομίμηση της πρόσβασης στην εφαρμογή από εικονικούς χρήστες
Απαντήσεις ανά δευτερόλεπτο (λεπτό)
- ο αριθμός των αποκρίσεων δικτύου ανά δευτερόλεπτο (ή λεπτό).
Ένα σημαντικό χαρακτηριστικό της υπηρεσίας στόχου: πόσο
δημιουργία και αποστολή απαντήσεων σε ερωτήματα με
πράκτορας φόρτωσης
Κατάσταση απόκρισης HTTP— αριθμός διαφορετικών κωδικών απόκρισης
από τον διακομιστή εφαρμογών που ελήφθη από τον παράγοντα φόρτωσης.
Για παράδειγμα, 200 OK σημαίνει μια επιτυχημένη κλήση,
και 404 - ότι ο πόρος δεν βρέθηκε
Αφάνεια (χρόνος απόκρισης) - χρόνος από το τέλος
αποστολή αιτήματος (αίτημα) πριν αρχίσει να λαμβάνει απάντηση (απάντηση).
Συνήθως μετριέται σε χιλιοστά του δευτερολέπτου (ms)
Χρόνος απόκρισης συναλλαγής— χρόνος μιας πλήρους συναλλαγής,
ολοκλήρωση του κύκλου αιτήματος-απόκρισης.
Αυτός είναι ο χρόνος από την έναρξη της αποστολής του αιτήματος (αίτημα)
μέχρι την ολοκλήρωση της λήψης απάντησης (απάντηση).
Ο χρόνος συναλλαγής μπορεί να μετρηθεί σε δευτερόλεπτα (ή λεπτά)
με διάφορους τρόπους: εξετάστε το ελάχιστο,
μέγιστο, μέσο όρο και, για παράδειγμα, το 90ο εκατοστημόριο.
Οι ελάχιστες και μέγιστες ενδείξεις είναι ακραίες
κατάσταση απόδοσης συστήματος.
Το ενενηκοστό εκατοστημόριο είναι το πιο συχνά χρησιμοποιούμενο,
όπως δείχνει στους περισσότερους χρήστες,
λειτουργούν άνετα στο κατώφλι της απόδοσης του συστήματος
Συναλλαγές ανά δευτερόλεπτο (λεπτό) - ο αριθμός των πλήρων
συναλλαγές ανά δευτερόλεπτο (λεπτό),
δηλαδή πόσο μπόρεσε να δεχτεί η αίτηση και
επεξεργασία αιτημάτων και έκδοση απαντήσεων.
Στην πραγματικότητα, αυτή είναι η απόδοση του συστήματος
Κατάσταση συναλλαγής , Επιτυχία / Αποτυχία / Σύνολο - αριθμός
επιτυχείς, ανεπιτυχείς και ο συνολικός αριθμός των συναλλαγών.
Για πραγματικούς χρήστες ανεπιτυχές
η συναλλαγή θα σημαίνει πραγματικά
αδυναμία εργασίας με το σύστημα υπό φορτίο
Σχηματικό διάγραμμα δοκιμής φορτίου
Η έννοια της δοκιμής φορτίου είναι πολύ απλή και αποτελείται από τρία κύρια στάδια, τα οποία έχω ήδη αναφέρει: Προετοιμασία-Δοκιμή-Αναφορά, δηλαδή προετοιμασία στόχων δοκιμής και ρύθμιση παραμέτρων για πηγές φορτίου, στη συνέχεια εκτέλεση δοκιμών φορτίου και, στο τέλος, δημιουργία και δημοσίευση μιας αναφοράς δοκιμής.
Σχηματικές σημειώσεις:
- Ο QA.Tester είναι ειδικός στις δοκιμές φορτίου,
- Το Target είναι η εφαρμογή στόχος για την οποία θέλετε να μάθετε τη συμπεριφορά της υπό φόρτωση.
Ταξινομητής οντοτήτων, σταδίων και βημάτων στο διάγραμμα
Στάδια και βήματα
Τι συμβαίνει
Τι υπάρχει στην είσοδο
Ποια είναι η έξοδος
Προετοιμασία: στάδιο προετοιμασίας για δοκιμή
LoadParameters
Ρύθμιση και αρχικοποίηση
χρήστης
παράμετροι φορτίου,
επιλογή μετρήσεων και
προετοιμασία σχεδίου δοκιμής
(φόρτωση προφίλ)
Προσαρμοσμένες επιλογές για
αρχικοποίηση παράγοντα φόρτωσης
Σχέδιο δοκιμής
Σκοπός της δοκιμής
VM
Ανάπτυξη cloud
εικονική μηχανή με
απαιτούμενα χαρακτηριστικά
Ρυθμίσεις VM για load agent
Σενάρια αυτοματισμού για
Δημιουργία VM
VM διαμορφώθηκε σε
σύννεφο
Env
Ρύθμιση και προετοιμασία λειτουργικού συστήματος
περιβάλλον για
εργασία αντιπροσώπου φόρτωσης
Ρυθμίσεις περιβάλλοντος για
πράκτορας φόρτωσης
Σενάρια αυτοματισμού για
ρυθμίσεις περιβάλλοντος
Προετοιμασμένο περιβάλλον:
ΛΣ, υπηρεσίες και εφαρμογές,
απαραίτητο για εργασία
πράκτορας φόρτωσης
LoadAgents
Εγκατάσταση, διαμόρφωση και παραμετροποίηση
πράκτορας φόρτωσης.
Ή λήψη μιας εικόνας docker από
προδιαμορφωμένη πηγή φόρτωσης
Φόρτωση εικόνας βάσης βάσης πηγής
(YAT, JM ή αυτογραφικό πλαίσιο)
Ρυθμίσεις
πράκτορας φόρτωσης
Ρύθμιση και έτοιμο
στον πράκτορα φόρτου εργασίας
Δοκιμή: στάδιο εκτέλεσης δοκιμών φορτίου. Οι πηγές είναι πράκτορες φόρτωσης που αναπτύσσονται σε αποκλειστικές ομάδες πρακτόρων για το GitLab CI
Φορτίο
Εκκίνηση του Load Agent
με επιλεγμένο σχέδιο δοκιμής
και τις παραμέτρους φορτίου
Επιλογές χρήστη
για αρχικοποίηση
πράκτορας φόρτωσης
Σχέδιο δοκιμής
Σκοπός της δοκιμής
Μητρώα εκτέλεσης
δοκιμές φορτίου
Αρχεία καταγραφής συστήματος
Δυναμική των αλλαγών στις μετρήσεις στόχου και τον παράγοντα φόρτωσης
Εκτελέστε τους πράκτορες
Εκτέλεση πράκτορα
πλήθος δοκιμαστικών σεναρίων
συμφωνώς προς
προφίλ φόρτωσης
Αλληλεπίδραση παράγοντα φόρτωσης
για σκοπούς δοκιμής
Σχέδιο δοκιμής
Σκοπός της δοκιμής
Logs
Συλλογή «ακατέργαστων» κορμών
κατά τη διάρκεια της δοκιμής φορτίου:
φόρτωση αρχείων δραστηριότητας πράκτορα,
κατάσταση του στόχου δοκιμής
και το VM που τρέχει τον πράκτορα
Μητρώα εκτέλεσης
δοκιμές φορτίου
Αρχεία καταγραφής συστήματος
Metrics
Συλλογή "ακατέργαστων" μετρήσεων κατά τη διάρκεια της δοκιμής
Δυναμική αλλαγών στις μετρήσεις στόχων
και πράκτορας φόρτωσης
Έκθεση: στάδιο προετοιμασίας της έκθεσης δοκιμής
Γεννήτρια
Συλλέγεται επεξεργασία
σύστημα φόρτωσης και
σύστημα παρακολούθησης "ακατέργαστο"
μετρήσεις και αρχεία καταγραφής
Σχηματισμός έκθεσης σε
αναγνώσιμη μορφή από τον άνθρωπο
δυνατό με στοιχεία
αναλυτές
Μητρώα εκτέλεσης
δοκιμές φορτίου
Αρχεία καταγραφής συστήματος
Δυναμική αλλαγών στις μετρήσεις
στόχος και παράγοντας φόρτωσης
Επεξεργασμένα «ακατέργαστα» κούτσουρα
σε μορφή κατάλληλη για
μεταφορτώσεις σε εξωτερικό χώρο αποθήκευσης
Αναφορά στατικού φορτίου,
αναγνώσιμη από τον άνθρωπο
Δημοσίευση
Δημοσίευση της έκθεσης
σχετικά με το φορτίο
δοκιμή σε εξωτερικό
υπηρεσία
Επεξεργασμένο "ωμό"
αρχεία καταγραφής σε κατάλληλη μορφή
για εκφόρτωση σε εξωτερικό
αποθετήρια
Αποθηκεύτηκε σε εξωτερικό
αναφορές αποθήκευσης στις
φορτίο, κατάλληλο
για ανθρώπινη ανάλυση
Σύνδεση πηγών φορτίου σε πρότυπο CI
Ας περάσουμε στο πρακτικό κομμάτι. Θέλω να δείξω πώς σε ορισμένα έργα στην εταιρεία έχουμε εφαρμόσει την έννοια της δοκιμής φορτίου ως υπηρεσία.
Αρχικά, με τη βοήθεια των μηχανικών μας DevOps, δημιουργήσαμε μια ειδική ομάδα πρακτόρων στο GitLab CI για την εκτέλεση δοκιμών φόρτωσης. Για να μην τα συγχέουμε σε πρότυπα με άλλα, όπως πισίνες συναρμολόγησης, προσθέσαμε ετικέτες σε αυτούς τους πράκτορες, : φορτώνω. Μπορείτε να χρησιμοποιήσετε οποιεσδήποτε άλλες κατανοητές ετικέτες. Ρωτούν GitLab CI Runners.
Πώς να μάθετε την απαιτούμενη ισχύ από το υλικό; Τα χαρακτηριστικά των πρακτόρων φόρτωσης - επαρκής αριθμός vCPU, RAM και δίσκος - μπορούν να υπολογιστούν με βάση το γεγονός ότι το Docker, η Python (για Yandex.Tank), ο παράγοντας GitLab CI, η Java (για Apache JMeter) θα πρέπει να εκτελούνται στον πράκτορα . Για Java κάτω από το JMeter, συνιστάται επίσης η χρήση τουλάχιστον 512 MB μνήμης RAM και, ως ανώτατο όριο, .
Έτσι, με βάση την εμπειρία μας, συνιστούμε τη χρήση τουλάχιστον 4 vCPU, 4 GB RAM, 60 GB SSD για παράγοντες φόρτωσης. Η απόδοση της κάρτας δικτύου προσδιορίζεται με βάση τις απαιτήσεις του προφίλ φορτίου.
Χρησιμοποιούμε κυρίως δύο πηγές φόρτωσης - εικόνες Apache JMeter και Yandex.Tank docker.
είναι ένα εργαλείο ανοιχτού κώδικα από το Yandex για δοκιμή φόρτωσης. Η αρθρωτή αρχιτεκτονική του βασίζεται στην υψηλής απόδοσης ασύγχρονη δημιουργία αιτημάτων HTTP βασισμένη σε επιτυχίες της Phantom. Η δεξαμενή έχει ενσωματωμένη παρακολούθηση των πόρων του υπό δοκιμή διακομιστή μέσω του πρωτοκόλλου SSH, μπορεί να σταματήσει αυτόματα τη δοκιμή υπό καθορισμένες συνθήκες, μπορεί να εμφανίσει τα αποτελέσματα τόσο στην κονσόλα όσο και σε μορφή γραφημάτων, μπορείτε να συνδέσετε τις μονάδες σας με για επέκταση της λειτουργικότητας. Παρεμπιπτόντως, χρησιμοποιήσαμε το Tank όταν δεν ήταν ακόμα mainstream. Στο άρθρο "» μπορείτε να διαβάσετε την ιστορία του τρόπου με τον οποίο πραγματοποιήσαμε δοκιμές φόρτωσης με αυτό το 2013 είναι ένα από τα προϊόντα της εταιρείας μας.
είναι ένα εργαλείο δοκιμής φόρτωσης ανοιχτού κώδικα από τον Apache. Μπορεί να χρησιμοποιηθεί εξίσου καλά για τη δοκιμή τόσο στατικών όσο και δυναμικών εφαρμογών web. Το JMeter υποστηρίζει έναν τεράστιο αριθμό πρωτοκόλλων και τρόπων αλληλεπίδρασης με εφαρμογές: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, κ.λπ.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) και IMAP(S), βάσεις δεδομένων μέσω JDBC, μπορούν να εκτελέσουν εντολές φλοιού και να εργαστούν με αντικείμενα Java. Το JMeter διαθέτει ένα IDE για τη δημιουργία, τον εντοπισμό σφαλμάτων και την εκτέλεση δοκιμαστικών σχεδίων. Υπάρχει επίσης ένα CLI για λειτουργία γραμμής εντολών σε οποιοδήποτε λειτουργικό σύστημα συμβατό με Java (Linux, Windows, Mac OS X). Το εργαλείο μπορεί να δημιουργήσει δυναμικά μια αναφορά δοκιμής HTML.
Για ευκολία στη χρήση εντός της εταιρείας μας, για τη δυνατότητα των ίδιων των ελεγκτών να αλλάζουν και να προσθέτουν το περιβάλλον, φτιάξαμε builds εικόνων docker πηγών φόρτωσης στο GitLab CI με δημοσίευση στο εσωτερικό . Αυτό καθιστά ταχύτερη και ευκολότερη τη σύνδεσή τους σε αγωγούς για δοκιμές φορτίου. Πώς να κάνετε docker push to registry μέσω GitLab CI - βλ .
Πήραμε αυτό το βασικό αρχείο docker για το Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Και για το Apache JMeter αυτό:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Μπορείτε να διαβάσετε πώς λειτουργεί το σύστημα συνεχούς ενσωμάτωσης στο άρθρο "».
Πρότυπο και αγωγός
Ένα παράδειγμα προτύπου για τη διεξαγωγή δοκιμών φορτίου είναι διαθέσιμο στο έργο . Σε Μπορείτε να διαβάσετε τις οδηγίες χρήσης του προτύπου. Στο ίδιο το πρότυπο (αρχείο ) υπάρχουν σημειώσεις για το τι είναι υπεύθυνο κάθε βήμα.
Το πρότυπο είναι πολύ απλό και δείχνει τα τρία στάδια της δοκιμής φορτίου που περιγράφονται στο παραπάνω διάγραμμα: προετοιμασία, δοκιμή και δημοσίευση αναφορών. Υπεύθυνος για αυτό : Προετοιμασία, δοκιμή και αναφορά.
- Στάδιο θα πρέπει να χρησιμοποιείται για την προρύθμιση των δοκιμαστικών στόχων ή τον έλεγχο της διαθεσιμότητάς τους. Το περιβάλλον για τις πηγές φορτίου δεν χρειάζεται να διαμορφωθεί, είναι προκατασκευασμένες ως εικόνες docker και δημοσιεύονται στο μητρώο του docker: απλώς καθορίστε την επιθυμητή έκδοση στο στάδιο Test. Αλλά μπορείτε να τα ξαναφτιάξετε και να φτιάξετε τις δικές σας τροποποιημένες εικόνες.
- Στάδιο χρησιμοποιείται για τον καθορισμό της πηγής φόρτωσης, την εκτέλεση δοκιμών και την αποθήκευση τεχνικών δοκιμών. Μπορείτε να επιλέξετε οποιαδήποτε πηγή φόρτωσης: Yandex.Tank, Apache JMeter, δική σας ή όλα μαζί. Για να απενεργοποιήσετε τις περιττές πηγές, απλώς σχολιάστε ή διαγράψτε την εργασία. Σημεία εισόδου για πηγές φορτίου:
- Οι παράμετροι εκκίνησης για το Yandex.Tank καθορίζονται στο .,
- Οι παράμετροι εκκίνησης του Apache JMeter καθορίζονται στο αρχείο .
Σημείωση: Το πρότυπο διαμόρφωσης του συγκροτήματος χρησιμοποιείται για τη ρύθμιση της αλληλεπίδρασης με το σύστημα CI και δεν συνεπάγεται την τοποθέτηση λογικής δοκιμής σε αυτό. Για δοκιμές, καθορίζεται το σημείο εισόδου, όπου βρίσκεται η δέσμη ενεργειών bash ελέγχου. Η μέθοδος εκτέλεσης των δοκιμών, η δημιουργία αναφορών και τα ίδια τα σενάρια δοκιμών πρέπει να υλοποιούνται από μηχανικούς QA. Στην επίδειξη, και για τις δύο πηγές φόρτωσης, το αίτημα κύριας σελίδας Yandex χρησιμοποιείται ως η απλούστερη δοκιμή. Τα σενάρια και οι παράμετροι δοκιμής βρίσκονται στον κατάλογο .
- Στη σκηνή πρέπει να περιγράψετε τον τρόπο δημοσίευσης των αποτελεσμάτων των δοκιμών που λήφθηκαν στο στάδιο της δοκιμής σε εξωτερικούς αποθηκευτικούς χώρους, για παράδειγμα, σε σελίδες GitLab ή σε ειδικά συστήματα αναφοράς. Το GitLab Pages απαιτεί ο κατάλογος ./public να μην είναι κενός και να περιέχει τουλάχιστον ένα αρχείο index.html μετά την ολοκλήρωση των δοκιμών. Μπορείτε να διαβάσετε για τις αποχρώσεις της υπηρεσίας GitLab Pages. .
Παραδείγματα για τον τρόπο εξαγωγής δεδομένων:
- από JMeter έως ,
- από το Yandex.Tank στο .
Οδηγίες ρύθμισης ανάρτησης:
- Στατικά HTML μέσα ,
- στο InfluxDB και μετά στο .
Στο παράδειγμα επίδειξης, ο αγωγός με δοκιμές φορτίου και δύο πηγές φορτίου (μπορείτε να απενεργοποιήσετε την περιττή) μοιάζει με αυτό:
Το Apache JMeter μπορεί να δημιουργήσει το ίδιο μια αναφορά HTML, επομένως είναι πιο κερδοφόρο να την αποθηκεύσετε στις Σελίδες GitLab χρησιμοποιώντας τυπικά εργαλεία. Έτσι φαίνεται η αναφορά του Apache JMeter:
Στο παράδειγμα επίδειξης για το Yandex.Tank, θα δείτε μόνο στην ενότητα για Σελίδες GitLab. Κατά τη διάρκεια της δοκιμής, το Tank μπορεί να αποθηκεύσει τα αποτελέσματα στη βάση δεδομένων InfluxDB και από εκεί μπορούν να εμφανιστούν, για παράδειγμα, στο Grafana (η ρύθμιση παραμέτρων γίνεται στο αρχείο ). Έτσι φαίνεται η αναφορά του Tank στο Grafana:
Περίληψη
Στο άρθρο, μίλησα για την έννοια του "load testing as a service" (load testing as a service). Η κύρια ιδέα είναι να χρησιμοποιηθεί η υποδομή προδιαμορφωμένων ομάδων πρακτόρων φόρτωσης, εικόνων docker πηγών φορτίου, συστημάτων αναφοράς και μιας διοχέτευσης που τα συνδυάζει στο GitLab CI με βάση ένα απλό πρότυπο .gitlab-ci.yml (παράδειγμα ). Όλα αυτά υποστηρίζονται από μια μικρή ομάδα μηχανικών αυτοματισμού και αναπαράγονται κατόπιν αιτήματος των ομάδων προϊόντων. Ελπίζω ότι αυτό θα σας βοηθήσει να προετοιμάσετε και να εφαρμόσετε ένα παρόμοιο σχέδιο στην εταιρεία σας. Ευχαριστώ για την προσοχή!
Υ.Γ. Θέλω να πω ένα μεγάλο ευχαριστώ στους συναδέλφους μου, Sergey Kurbanov και Nikolai Yusev, για την τεχνική βοήθεια με την εφαρμογή της έννοιας της δοκιμής φορτίου ως υπηρεσία στην εταιρεία μας.
Συγγραφέας: - Αναπληρωτής Επικεφαλής Τεχνολογιών και Διαδικασιών Ανάπτυξης (DevOps) στην Positive Technologies
Πηγή: www.habr.com