load testing complete guide
Ένας πλήρης οδηγός δοκιμής φορτίου για αρχάριους:
Σε αυτό το σεμινάριο, θα μάθουμε γιατί εκτελούμε δοκιμές φόρτωσης, τι επιτυγχάνεται από αυτό, αρχιτεκτονική, ποια είναι η προσέγγιση που πρέπει να ακολουθηθεί για την επιτυχή εκτέλεση δοκιμής φόρτωσης, πώς να ρυθμίσετε ένα περιβάλλον δοκιμής φόρτωσης, βέλτιστες πρακτικές, καθώς και τα καλύτερα εργαλεία δοκιμής φόρτωσης που διατίθενται στην αγορά.
Έχουμε ακούσει τόσο για λειτουργικούς όσο και για μη λειτουργικούς τύπους δοκιμών. Σε μη λειτουργικές δοκιμές, έχουμε διαφορετικούς τύπους δοκιμών, όπως Δοκιμή απόδοσης, Δοκιμή ασφαλείας, Δοκιμή διεπαφής χρήστη κ.λπ.
Ως εκ τούτου, το Load Testing είναι ένας μη λειτουργικός τύπος δοκιμών που είναι ένα υποσύνολο του Performance Testing.
Έτσι, όταν λέμε ότι δοκιμάζουμε μια εφαρμογή για απόδοση, τι δοκιμάζουμε εδώ; Δοκιμάζουμε την εφαρμογή για φορτίο, όγκο, χωρητικότητα, πίεση κ.λπ.
Τι θα μάθετε:
- Τι είναι η δοκιμή φορτίου;
- Φόρτωση αρχιτεκτονικής δοκιμής
- Γιατί δοκιμή φόρτωσης;
- περιβάλλον
- Πλησιάζω
- Βέλτιστες πρακτικές
- συμπέρασμα
- Συνιστώμενη ανάγνωση
Τι είναι η δοκιμή φορτίου;
Load Testing είναι ένα υποσύνολο του Performance Testing, όπου δοκιμάζουμε την απόκριση του συστήματος υπό διαφορετικές συνθήκες φόρτωσης, προσομοιώνοντας πολλούς χρήστες που έχουν πρόσβαση στην εφαρμογή ταυτόχρονα. Αυτός ο έλεγχος μετρά συνήθως την ταχύτητα και την χωρητικότητα της εφαρμογής.
Έτσι, κάθε φορά που τροποποιούμε το φορτίο, παρακολουθούμε τη συμπεριφορά του συστήματος υπό διάφορες συνθήκες.
Παράδειγμα :Ας υποθέσουμε ότι η απαίτηση πελάτη μας για μια σελίδα σύνδεσης είναι 2-5 δευτερόλεπτα και αυτά τα 2-5 δευτερόλεπτα πρέπει να είναι συνεπή καθ 'όλη τη διάρκεια έως ότου η φόρτωση είναι 5000 χρήστες. Λοιπόν, τι πρέπει να παρατηρήσουμε να ακούσουμε; Είναι απλώς η ικανότητα χειρισμού φορτίου του συστήματος ή είναι απλώς η απαίτηση χρόνου απόκρισης;
Η απάντηση είναι και τα δύο. Θέλουμε το σύστημα που μπορεί να χειριστεί ένα φορτίο 5000 χρηστών με χρόνο απόκρισης 2-5 δευτερολέπτων για όλους τους ταυτόχρονους χρήστες.
Τι σημαίνει λοιπόν ένας ταυτόχρονος χρήστης και ένας εικονικός χρήστης;
Οι ταυτόχρονοι χρήστες είναι αυτοί που συνδέονται στην εφαρμογή και ταυτόχρονα, εκτελούν ένα σύνολο δραστηριοτήτων μαζί και αποσυνδέουν την εφαρμογή ταυτόχρονα. Από την άλλη πλευρά, οι εικονικοί χρήστες απλά μετακινούνται και απομακρύνονται από το σύστημα ανεξάρτητα από τις άλλες δραστηριότητες των χρηστών.
Φόρτωση αρχιτεκτονικής δοκιμής
Στο παρακάτω διάγραμμα μπορούμε να δούμε πώς οι διαφορετικοί χρήστες έχουν πρόσβαση στην εφαρμογή. Εδώ κάθε χρήστης υποβάλλει ένα αίτημα μέσω του Διαδικτύου, το οποίο αργότερα διαβιβάζεται μέσω ενός τείχους προστασίας.
Μετά το τείχος προστασίας, έχουμε ένα εξισορροπητή φόρτωσης που διανέμει το φορτίο σε οποιονδήποτε από τους διακομιστές ιστού και στη συνέχεια περνά στον διακομιστή εφαρμογών και αργότερα στον διακομιστή βάσης δεδομένων όπου λαμβάνει τις απαραίτητες πληροφορίες βάσει του αιτήματος χρήστη.
Ο έλεγχος φορτίου μπορεί να γίνει χειροκίνητα καθώς και με τη χρήση ενός εργαλείου. Ωστόσο, δεν συνιστάται η μη αυτόματη δοκιμή φόρτωσης, καθώς δεν ελέγχουμε την εφαρμογή για μικρότερο φορτίο.
Παράδειγμα: Ας υποθέσουμε ότι θέλουμε να δοκιμάσουμε μια διαδικτυακή εφαρμογή αγορών για να δούμε τον χρόνο απόκρισης της εφαρμογής για κάθε κλικ χρήστη, π.χ. Βήμα 1 - Εκκίνηση διεύθυνσης URL, χρόνος απόκρισης, Σύνδεση στην εφαρμογή και σημείωση του χρόνου απόκρισης και ούτω καθεξής, όπως η επιλογή ενός προϊόν, προσθήκη στο καλάθι, πληρωμή και αποσύνδεση. Όλα αυτά πρέπει να γίνουν για 10 χρήστες.
Έτσι, τώρα που πρέπει να δοκιμάσουμε το φορτίο εφαρμογής για 10 χρήστες, τότε μπορούμε να το επιτύχουμε τοποθετώντας χειροκίνητα φορτίο από 10 φυσικούς χρήστες από διαφορετικά μηχανήματα αντί να χρησιμοποιήσουμε ένα εργαλείο. Σε αυτό το σενάριο, συνιστάται να κάνετε μια δοκιμή μη αυτόματης φόρτωσης αντί να επενδύσετε σε ένα εργαλείο και να δημιουργήσετε ένα περιβάλλον για το εργαλείο.
Ενώ φανταστείτε εάν πρέπει να φορτώσουμε τη δοκιμή για 1500 χρήστες, τότε πρέπει να αυτοματοποιήσουμε τη δοκιμή φόρτωσης χρησιμοποιώντας οποιοδήποτε από τα διαθέσιμα εργαλεία με βάση τις τεχνολογίες στις οποίες έχει κατασκευαστεί η εφαρμογή και επίσης βάσει του προϋπολογισμού που έχουμε για το έργο.
Εάν έχουμε προϋπολογισμό, τότε μπορούμε να χρησιμοποιήσουμε εμπορικά εργαλεία όπως Load runner, αλλά αν δεν έχουμε πολύ προϋπολογισμό, τότε μπορούμε να χρησιμοποιήσουμε εργαλεία ανοιχτού κώδικα όπως JMeter κ.λπ.
Ποια είναι η διαφορά μεταξύ διασφάλισης ποιότητας και ελέγχου ποιότητας;
Είτε πρόκειται για ένα εμπορικό εργαλείο είτε ένα εργαλείο ανοιχτού κώδικα, οι λεπτομέρειες πρέπει να κοινοποιηθούν στον πελάτη προτού ολοκληρώσουμε το εργαλείο. Συνήθως, προετοιμάζεται μια απόδειξη της έννοιας, όπου δημιουργούμε ένα δείγμα σεναρίου χρησιμοποιώντας το εργαλείο και παρουσιάζουμε τα δείγματα αναφορών στον πελάτη για έγκριση του εργαλείου πριν το οριστικοποιήσουμε.
Στην αυτοματοποιημένη δοκιμή φόρτωσης, αντικαθιστούμε τους χρήστες με τη βοήθεια ενός εργαλείου αυτοματισμού, το οποίο μιμείται τις ενέργειες των χρηστών σε πραγματικό χρόνο. Με την αυτοματοποίηση του φορτίου μπορούμε να εξοικονομήσουμε πόρους καθώς και το χρόνο.
Ακολουθεί το διάγραμμα που απεικονίζει τον τρόπο αντικατάστασης των χρηστών χρησιμοποιώντας ένα εργαλείο.
Γιατί δοκιμή φόρτωσης;
Ας υποθέσουμε ότι υπάρχει ένας διαδικτυακός ιστότοπος αγορών που λειτουργεί αρκετά καλά κατά τις κανονικές εργάσιμες ημέρες, δηλαδή οι χρήστες μπορούν να συνδεθούν στην εφαρμογή, να περιηγηθούν στις διάφορες κατηγορίες προϊόντων, να επιλέξουν προϊόντα, να προσθέσουν στοιχεία στο καλάθι, να κάνουν check out και να αποσυνδεθούν εντός ένα αποδεκτό εύρος και δεν υπάρχουν σφάλματα σελίδας ή τεράστιοι χρόνοι απόκρισης.
Εν τω μεταξύ, έρχεται μια ημέρα αιχμής δηλαδή ας πούμε την ημέρα των Ευχαριστιών και υπάρχουν χιλιάδες χρήστες που είναι συνδεδεμένοι στο σύστημα, το σύστημα συντρίβεται ξαφνικά και οι χρήστες βιώνουν μια πολύ αργή απόκριση, μερικοί δεν μπορούσαν καν συνδεθείτε στον ιστότοπο, μερικοί απέτυχαν να προσθέσουν στο καλάθι και κάποιοι απέτυχαν να κάνουν check out.
Ως εκ τούτου, σε αυτή τη μεγάλη μέρα, η εταιρεία έπρεπε να αντιμετωπίσει μια τεράστια απώλεια καθώς έχασε πολλούς πελάτες και πολλές επιχειρήσεις. Όλα αυτά συνέβησαν μόνο και μόνο επειδή δεν προέβλεπαν τη φόρτωση του χρήστη για τις ημέρες αιχμής, ακόμη και αν θα είχαν προβλέψει ότι δεν έγινε δοκιμή φόρτωσης στον ιστότοπο της εταιρείας, επομένως δεν γνωρίζουν πόση φόρτωση θα μπορεί να χειριστεί η εφαρμογή τις μέρες αιχμής.
Επομένως, για να χειριστείτε τέτοιες καταστάσεις και για να ξεπεράσετε τα τεράστια έσοδα, συνιστάται να πραγματοποιήσετε δοκιμή φόρτωσης για τέτοιου είδους εφαρμογές.
- Το Load Testing βοηθά στη δημιουργία ισχυρών και αξιόπιστων συστημάτων.
- Το σημείο συμφόρησης στο σύστημα εντοπίζεται πολύ νωρίτερα πριν τεθεί σε εφαρμογή η εφαρμογή.
- Βοηθά στον προσδιορισμό της χωρητικότητας της εφαρμογής.
Τι επιτυγχάνεται κατά τη διάρκεια δοκιμής φορτίου;
Με τη σωστή δοκιμή φόρτωσης, μπορούμε να έχουμε την ακριβή κατανόηση των εξής:
- Ο αριθμός των χρηστών που μπορεί να χειριστεί το σύστημα ή μπορεί να κλιμακώσει.
- Ο χρόνος απόκρισης κάθε συναλλαγής.
- Πώς συμπεριφέρεται κάθε στοιχείο ολόκληρου του συστήματος στην ενότητα Φόρτωση, δηλαδή στοιχεία διακομιστή εφαρμογών, στοιχεία διακομιστή ιστού, στοιχεία βάσης δεδομένων κ.λπ.
- Ποια διαμόρφωση διακομιστή είναι καλύτερη για τη διαχείριση του φορτίου;
- Εάν το υπάρχον υλικό είναι αρκετό ή υπάρχει ανάγκη για επιπλέον υλικό.
- Εντοπίζονται σημεία συμφόρησης όπως χρήση CPU, Χρήση μνήμης, καθυστερήσεις δικτύου κ.λπ.
περιβάλλον
Χρειαζόμαστε ένα ειδικό περιβάλλον δοκιμής φορτίου για τη διεξαγωγή των δοκιμών μας. Επειδή τις περισσότερες φορές το περιβάλλον δοκιμής φόρτωσης θα είναι το ίδιο με το περιβάλλον παραγωγής και επίσης τα διαθέσιμα δεδομένα στο περιβάλλον δοκιμής φορτίου θα είναι ίδια με την παραγωγή αν και δεν είναι τα ίδια δεδομένα.
Θα υπάρξουν πολλαπλά περιβάλλοντα δοκιμών όπως περιβάλλον SIT, περιβάλλον QA κ.λπ., αυτά τα περιβάλλοντα δεν είναι η ίδια παραγωγή, επειδή σε αντίθεση με τη δοκιμή φορτίου δεν χρειάζονται πολλούς διακομιστές ή τόσο πολλά δεδομένα δοκιμών για τη διεξαγωγή λειτουργικών δοκιμών ή δοκιμών ενοποίησης.
Παράδειγμα:
Σε ένα περιβάλλον παραγωγής, έχουμε 3 διακομιστές εφαρμογών, 2 διακομιστές Web και 2 διακομιστές βάσεων δεδομένων. Στο QA, έχουμε μόνο 1 διακομιστή εφαρμογών, 1 διακομιστή Web και 1 διακομιστή βάσης δεδομένων. Επομένως, εάν διεξάγουμε μια δοκιμή φόρτωσης σε περιβάλλον QA που δεν είναι ίσο με την παραγωγή, τότε οι δοκιμές μας δεν είναι έγκυρες και είναι επίσης λανθασμένες και ως εκ τούτου δεν μπορούμε να ακολουθήσουμε αυτά τα αποτελέσματα.
Συνεπώς, προσπαθήστε πάντα να έχετε ένα ειδικό περιβάλλον για δοκιμές φορτίου που είναι παρόμοιο με αυτό ενός περιβάλλοντος παραγωγής.
Επίσης, μερικές φορές έχουμε εφαρμογές τρίτων με τις οποίες θα καλεί το σύστημά μας, επομένως σε τέτοιες περιπτώσεις, μπορούμε να χρησιμοποιήσουμε stubs καθώς δεν μπορούμε πάντα να συνεργαζόμαστε με τους τρίτους προμηθευτές για ανανέωση δεδομένων ή άλλα ζητήματα ή υποστήριξη.
Προσπαθήστε να τραβήξετε ένα στιγμιότυπο του περιβάλλοντος μόλις είναι έτοιμο, έτσι ώστε, όποτε θέλετε να αναδημιουργήσετε το περιβάλλον, μπορείτε να χρησιμοποιήσετε αυτό το στιγμιότυπο, το οποίο θα βοηθούσε στη διαχείριση του χρόνου. Υπάρχουν μερικά εργαλεία που είναι διαθέσιμα στην αγορά για τη ρύθμιση του περιβάλλοντος, όπως Puppet, Docker κ.λπ.
Πλησιάζω
Πριν ξεκινήσουμε τη δοκιμή φόρτωσης, πρέπει να καταλάβουμε εάν έχει ήδη γίνει δοκιμή φόρτωσης στο σύστημα ή όχι. Εάν υπήρχε κάποια δοκιμή φόρτωσης νωρίτερα, τότε πρέπει να γνωρίζουμε ποιος ήταν ο χρόνος απόκρισης, οι μετρήσεις πελάτη και διακομιστή, πόση ήταν η χωρητικότητα φόρτωσης του χρήστη κ.λπ.
Επίσης, χρειαζόμαστε πληροφορίες σχετικά με το πόσο είναι η τρέχουσα ικανότητα χειρισμού εφαρμογών. Εάν πρόκειται για μια νέα εφαρμογή, πρέπει να κατανοήσουμε τις απαιτήσεις, ποιο είναι το στοχευμένο φορτίο, ποιος είναι ο αναμενόμενος χρόνος απόκρισης και εάν είναι πραγματικά εφικτός ή όχι.
Εάν πρόκειται για υπάρχουσα εφαρμογή, μπορείτε να λάβετε τις απαιτήσεις φόρτωσης και τα μοτίβα πρόσβασης χρήστη από τα αρχεία καταγραφής διακομιστή. Αν όμως πρόκειται για μια νέα εφαρμογή, τότε πρέπει να επικοινωνήσετε με την ομάδα επιχειρήσεων για να λάβετε όλες τις πληροφορίες.
Μόλις έχουμε τις απαιτήσεις, πρέπει να προσδιορίσουμε πώς θα εκτελέσουμε τη δοκιμή φορτίου. Γίνεται χειροκίνητα ή χρησιμοποιώντας εργαλεία; Η χειροκίνητη δοκιμή φορτίου χρειάζεται πολλούς πόρους και είναι πολύ ακριβή. Η επανάληψη του τεστ, ξανά και ξανά, θα είναι επίσης δύσκολη.
Ως εκ τούτου, για να ξεπεραστεί αυτό μπορούμε είτε να χρησιμοποιήσουμε εργαλεία ανοιχτού κώδικα είτε εμπορικά εργαλεία. Τα εργαλεία ανοιχτού κώδικα είναι διαθέσιμα δωρεάν, αυτά τα εργαλεία μπορεί να μην έχουν όλες τις δυνατότητες όπως τα άλλα εμπορικά εργαλεία, αλλά εάν το έργο έχει περιορισμό προϋπολογισμού, τότε μπορούμε να αναζητήσουμε εργαλεία ανοιχτού κώδικα.
Ενώ τα εμπορικά εργαλεία έχουν πολλά χαρακτηριστικά, υποστηρίζουν πολλά πρωτόκολλα και είναι πολύ φιλικά προς τον χρήστη.
Η προσέγγιση δοκιμής φορτίου θα έχει ως εξής:
# 1) Προσδιορίστε τα κριτήρια αποδοχής της δοκιμής φόρτωσης
Για παράδειγμα:
- Ο χρόνος απόκρισης της σελίδας σύνδεσης δεν πρέπει να υπερβαίνει τα 5 δευτερόλεπτα ακόμη και κατά τη διάρκεια των συνθηκών μέγιστης φόρτωσης.
- Η χρήση της CPU δεν πρέπει να υπερβαίνει το 80%.
- Η απόδοση του συστήματος πρέπει να είναι 100 συναλλαγές ανά δευτερόλεπτο.
# 2) Προσδιορίστε τα επιχειρηματικά σενάρια που πρέπει να δοκιμαστούν.
Μην δοκιμάσετε όλες τις ροές, προσπαθήστε να κατανοήσετε τις κύριες επιχειρηματικές ροές που αναμένεται να συμβούν στην παραγωγή. Εάν πρόκειται για υπάρχουσα εφαρμογή, μπορούμε να λάβουμε τις πληροφορίες του από τα αρχεία καταγραφής διακομιστών του περιβάλλοντος παραγωγής.
Εάν πρόκειται για μια νέα εφαρμογή, τότε πρέπει να συνεργαστούμε με τις επιχειρηματικές ομάδες για να κατανοήσουμε τα μοτίβα ροής, τη χρήση εφαρμογών κ.λπ. Μερικές φορές η ομάδα του έργου θα πραγματοποιήσει εργαστήρια για να δώσει μια επισκόπηση ή λεπτομέρειες σχετικά με κάθε στοιχείο της εφαρμογής.
Πρέπει να παρακολουθήσουμε το εργαστήριο εφαρμογής και να σημειώσουμε όλες τις απαιτούμενες πληροφορίες για τη διεξαγωγή του ελέγχου φορτίου.
# 3) Μοντελοποίηση φορτίου εργασίας
Μόλις έχουμε τις λεπτομέρειες σχετικά με τις ροές των επιχειρήσεων, τα μοτίβα πρόσβασης των χρηστών και τον αριθμό των χρηστών, πρέπει να σχεδιάσουμε το φόρτο εργασίας με τέτοιο τρόπο ώστε να μιμείται την πραγματική πλοήγηση των χρηστών στην παραγωγή ή όπως αναμένεται να είναι στο μέλλον μετά την εφαρμογή θα είναι σε παραγωγή.
Τα βασικά σημεία που πρέπει να θυμάστε κατά το σχεδιασμό ενός μοντέλου φόρτου εργασίας είναι να δείτε πόσο χρόνο θα χρειαστεί μια συγκεκριμένη επιχειρηματική ροή για να ολοκληρωθεί. Εδώ πρέπει να αντιστοιχίσουμε το χρόνο σκέψης με τέτοιο τρόπο ώστε, ο χρήστης να πλοηγείται στην εφαρμογή με πιο ρεαλιστικό τρόπο.
Το μοτίβο φόρτου εργασίας θα είναι συνήθως με ράμπα προς τα πάνω, ράμπα προς τα κάτω και σε σταθερή κατάσταση. Πρέπει να φορτώσουμε σιγά-σιγά το σύστημα και έτσι χρησιμοποιούμε ράμπα και ράμπα προς τα κάτω. Η σταθερή κατάσταση θα είναι συνήθως μια δοκιμή φόρτωσης μίας ώρας με Ramp up 15 min και Ram κάτω 15 min.
Ας πάρουμε ένα παράδειγμα του μοντέλου φόρτου εργασίας:
Επισκόπηση της εφαρμογής - Ας υποθέσουμε ότι ψωνίζουμε στο διαδίκτυο, όπου οι χρήστες θα συνδεθούν στην εφαρμογή και θα έχουν μεγάλη ποικιλία φορέματα για ψώνια και μπορούν να περιηγηθούν σε κάθε προϊόν.
Για να δείτε τις λεπτομέρειες για κάθε προϊόν, πρέπει να κάνουν κλικ στο προϊόν. Αν τους αρέσει το κόστος και η μάρκα του προϊόντος, τότε μπορούν να προσθέσουν στο καλάθι και να αγοράσουν το προϊόν κάνοντας check out και πραγματοποιώντας την πληρωμή.
Παρακάτω αναφέρονται μια λίστα σεναρίων:
- Ξεφυλλίζω - Εδώ, ο χρήστης ξεκινά την εφαρμογή, συνδέεται στην εφαρμογή, περιηγείται σε διαφορετικές κατηγορίες και αποσυνδέεται από την εφαρμογή.
- Αναζήτηση, Προβολή προϊόντος, Προσθήκη στο Καλάθι - Εδώ, ο χρήστης συνδέεται στην εφαρμογή, Περιηγείται σε διαφορετικές κατηγορίες, βλέπει τις λεπτομέρειες του προϊόντος, προσθέτει το προϊόν στο καλάθι και αποσυνδέεται.
- Περιήγηση, προβολή προϊόντος, προσθήκη στο καλάθι και αναχώρηση - Σε αυτό το σενάριο, ο χρήστης συνδέεται στην εφαρμογή, Περιηγείται σε διαφορετικές κατηγορίες, βλέπει τις λεπτομέρειες του προϊόντος, προσθέτει το προϊόν στο καλάθι, κάνει check out και αποσυνδέεται.
- Περιήγηση, προβολή προϊόντος, Προσθήκη στο καλάθι Αναχώρηση και πραγματοποίηση πληρωμής - Εδώ, ο χρήστης συνδέεται στην εφαρμογή, Περιηγείται σε διαφορετικές κατηγορίες, βλέπει τις λεπτομέρειες του προϊόντος, προσθέτει το προϊόν στο καλάθι, κάνει check out, πραγματοποιεί πληρωμές και αποσυνδέεται.
ΝΟ | Επιχειρηματική ροή | Αριθμός συναλλαγών | Εικονικό φορτίο χρήστη | Χρόνος απόκρισης (δευτ.) | Επιτρέπεται ποσοστό αποτυχίας | Συναλλαγές ανά ώρα |
---|---|---|---|---|---|---|
1 | Ξεφυλλίζω | 17 | 1600 | 3 | Λιγότερο από 2% | 96000 |
δύο | Αναζήτηση, Προβολή προϊόντος, Προσθήκη στο Καλάθι | 17 | 200 | 3 | Λιγότερο από 2% | 12000 |
3 | Περιήγηση, προβολή προϊόντος, προσθήκη στο καλάθι και αναχώρηση | 18 | 120 | 3 | Λιγότερο από 2% | 7200 |
4 | Περιήγηση, προβολή προϊόντος, Προσθήκη στο καλάθι Αναχώρηση και πραγματοποίηση πληρωμής | είκοσι | 80 | 3 | Λιγότερο από 2% | 4800 |
Οι παραπάνω τιμές προέκυψαν με βάση τους ακόλουθους υπολογισμούς:
- Συναλλαγές ανά ώρα = Αριθμός χρηστών * Συναλλαγές που πραγματοποιούνται από έναν χρήστη σε μία ώρα.
- Ο αριθμός των χρηστών = 1600.
- Ο συνολικός αριθμός συναλλαγών στο σενάριο Browse = 17.
- Χρόνος απόκρισης για κάθε συναλλαγή = 3.
- Συνολικός χρόνος για έναν μόνο χρήστη να ολοκληρώσει 17 συναλλαγές = 17 * 3 = 51 στρογγυλοποιημένο σε 60 δευτερόλεπτα (1 λεπτό).
- Συναλλαγές ανά ώρα = 1600 * 60 = 96000 Συναλλαγές.
# 4) Σχεδιάστε τις δοκιμές φόρτωσης- Η δοκιμή φόρτωσης πρέπει να σχεδιαστεί με τα δεδομένα που έχουμε συλλέξει μέχρι στιγμής, δηλαδή τις ροές επιχειρήσεων, τον αριθμό χρηστών, τα πρότυπα χρηστών, τις μετρήσεις που πρέπει να συλλεχθούν και να αναλυθούν. Επιπλέον, οι δοκιμές πρέπει να σχεδιάζονται με πολύ ρεαλιστικό τρόπο.
# 5) Εκτελέστε δοκιμή φόρτωσης - Πριν εκτελέσουμε τη δοκιμή φόρτωσης, βεβαιωθείτε ότι η εφαρμογή είναι σε λειτουργία. Το περιβάλλον δοκιμής φόρτωσης είναι έτοιμο. Η εφαρμογή ελέγχεται λειτουργικά και είναι σταθερή.
Ελέγξτε τις ρυθμίσεις διαμόρφωσης του περιβάλλοντος δοκιμής φόρτωσης. Θα πρέπει να είναι το ίδιο με το περιβάλλον παραγωγής. Βεβαιωθείτε ότι όλα τα δεδομένα δοκιμής είναι διαθέσιμα. Βεβαιωθείτε ότι έχετε προσθέσει τους απαραίτητους μετρητές για την παρακολούθηση της απόδοσης του συστήματος κατά την εκτέλεση της δοκιμής.
Ξεκινήστε πάντα με χαμηλό φορτίο και αυξήστε σταδιακά το φορτίο. Ποτέ μην ξεκινήσετε με το πλήρες φορτίο και σπάστε το σύστημα.
# 6) Αναλύστε τα αποτελέσματα της δοκιμής φόρτωσης - Κάντε μια δοκιμή βάσης για να συγκρίνετε πάντα με τις άλλες δοκιμές. Συγκεντρώστε τις μετρήσεις και τα αρχεία καταγραφής διακομιστή μετά τη δοκιμαστική εκτέλεση για να βρείτε τα σημεία συμφόρησης.
Ορισμένα έργα χρησιμοποιούν Εργαλεία Παρακολούθησης Απόδοσης Εφαρμογής για την παρακολούθηση του συστήματος κατά τη διάρκεια της δοκιμής, αυτά τα εργαλεία APM βοηθούν στον εντοπισμό της βασικής αιτίας πιο εύκολα και εξοικονομεί πολύ χρόνο. Αυτά τα εργαλεία είναι πολύ εύκολο να βρείτε τη βασική αιτία του σημείου συμφόρησης, καθώς έχουν ευρεία άποψη για να εντοπίσετε πού βρίσκεται το ζήτημα.
Μερικά από τα εργαλεία APM στην αγορά περιλαμβάνουν τα DynaTrace, Wily Introscope, App Dynamics κ.λπ.
# 7) Αναφορά - Μόλις ολοκληρωθεί η δοκιμαστική εκτέλεση, συγκεντρώστε όλες τις μετρήσεις και στείλτε τη συνοπτική έκθεση δοκιμής στην ενδιαφερόμενη ομάδα με τις παρατηρήσεις και τις συστάσεις σας.
Βέλτιστες πρακτικές
Παρακάτω αναφέρονται μερικές από τις βέλτιστες πρακτικές του Test Test:
# 1) Πάντα να ελέγχετε τη σταθερότητα της εφαρμογής πριν ξεκινήσετε τη δοκιμή φόρτωσης. Η εφαρμογή θα πρέπει να υπογραφεί λειτουργικά σταθερή από τη λειτουργική ομάδα δοκιμών και όλα τα μεγάλα ελαττώματα πρέπει να διορθωθούν και να δοκιμαστούν πριν αντιγραφεί η έκδοση στο περιβάλλον δοκιμής φόρτωσης.
#δύο) Βεβαιωθείτε ότι το περιβάλλον δοκιμής φόρτωσης είναι αντίγραφο ή βρίσκεται κοντά στο περιβάλλον παραγωγής, συμπεριλαμβανομένου του αριθμού διακομιστών, εξισορρόπησης φορτίου, διαμορφώσεων διακομιστή και τείχους προστασίας.
# 3) Ελέγξτε εάν τα δεδομένα δοκιμής είναι μοναδικά και έχουμε αντιγράψει όλα τα δεδομένα δοκιμής στο περιβάλλον φόρτωσης πριν από τη διεξαγωγή δοκιμής φόρτωσης.
# 4) Σχεδιάστε τα σενάρια δοκιμής με τέτοιο τρόπο ώστε να μιμούνται τη δράση των χρηστών σε πραγματικό χρόνο που συμβαίνει στην παραγωγή.
# 5) Σχεδιάστε το φόρτο εργασίας με βάση τα φορτία του χρήστη παραγωγής και τις επιχειρηματικές ροές και σε περίπτωση παλαιάς εφαρμογής, δείτε αν πρόκειται για μια νέα συζήτηση με την επιχειρηματική ομάδα σχετικά με τις επιχειρηματικές ροές και το φορτίο του χρήστη.
# 6) Συλλέξτε όλες τις σημαντικές μετρήσεις, όπως Χρόνος απόκρισης, επισκέψεις ανά δευτερόλεπτο, Throughput, Cpu, Memory, Network και Running Vusers.
Συνιστώμενη ανάγνωση => Λίστα εργαλείων δοκιμής απόδοσης που διατίθενται στην αγορά για τη διεξαγωγή αποκλειστικών δοκιμών φορτίου.
συμπέρασμα
Σε αυτό το σεμινάριο, μάθαμε πώς ο έλεγχος φόρτωσης παίζει σημαντικό ρόλο στη δοκιμή απόδοσης μιας εφαρμογής, πώς βοηθά στην κατανόηση της αποτελεσματικότητας και της ικανότητας της εφαρμογής κ.λπ.
Γνωρίσαμε επίσης πώς βοηθά να προβλέψουμε εάν απαιτείται πρόσθετο υλικό, λογισμικό ή συντονισμός σε μια εφαρμογή.
Καλή ανάγνωση !!
Συνιστώμενη ανάγνωση
- Φόρτωση δοκιμής με HP LoadRunner Tutorials
- Δοκιμή άλφα και δοκιμή beta (ένας πλήρης οδηγός)
- Οδηγός δοκιμών ασφάλειας εφαρμογών Ιστού
- Οδηγός για το στρες για αρχάριους
- Οδηγός για αρχάριους για δοκιμές διείσδυσης εφαρμογών ιστού
- Ένας πλήρης μη λειτουργικός οδηγός δοκιμών για αρχάριους
- Πλήρης οδηγός δοκιμής επαλήθευσης έκδοσης (Δοκιμή BVT)
- Δοκιμή απόδοσης έναντι δοκιμής φορτίου έναντι δοκιμής πίεσης (διαφορά)