Εργαλείο δοκιμής LoadRunner – Στοιχεία & Archiδομή

Τι είναι το LoadRunner;

LoadRunner είναι ένα εργαλείο δοκιμών απόδοσης το οποίο πρωτοστάτησε Mercury το 1999. Το LoadRunner εξαγοράστηκε αργότερα από την HPE το 2006. Το 2016, το LoadRunner εξαγοράστηκε από τη MicroFocus.

Το LoadRunner υποστηρίζει διάφορα εργαλεία ανάπτυξης, τεχνολογίες και πρωτόκολλα επικοινωνίας. Στην πραγματικότητα, αυτό είναι το μόνο εργαλείο στην αγορά που υποστηρίζει τόσο μεγάλο αριθμό πρωτοκόλλων για διεξαγωγή Δοκιμές Απόδοσης. Τα αποτελέσματα δοκιμής απόδοσης που παράγονται από το λογισμικό LoadRunner χρησιμοποιούνται ως σημείο αναφοράς έναντι άλλων εργαλείων

Βίντεο LoadRunner

Γιατί LoadRunner;

LoadRunner δεν είναι μόνο πρωτοποριακό εργαλείο στο Performance Testing, αλλά εξακολουθεί να είναι ηγέτης της αγοράς στο παράδειγμα Performance Testing. Σε μια πρόσφατη αξιολόγηση, το LoadRunner έχει περίπου 85% μερίδιο αγοράς στον κλάδο των δοκιμών απόδοσης.

Γενικά, το εργαλείο LoadRunner υποστηρίζει RIA (Rich Internet Applications), Web 2.0 (HTTP/HTML, Ajax, Flex και Silverlight κ.λπ.), Mobile, SAP, Oracle, ΚΥΡΙΑ SQL Διακομιστής, Citrix, RTE, Mail και πανω απ'ολα, Windows Πρίζα. Δεν υπάρχει ανταγωνιστικό εργαλείο στην αγορά που θα μπορούσε να προσφέρει τόσο μεγάλη ποικιλία πρωτοκόλλων με ένα μόνο εργαλείο.

Αυτό που είναι πιο πειστικό για να επιλέξετε το LoadRunner στη δοκιμή λογισμικού είναι η αξιοπιστία αυτού του εργαλείου. Το εργαλείο LoadRunner έχει καθιερώσει εδώ και καιρό μια φήμη όπως συχνά θα βρείτε πελάτες διασταυρώνοντας την επαλήθευση των κριτηρίων απόδοσης χρησιμοποιώντας το LoadRunner. Θα βρείτε ανακούφιση εάν χρησιμοποιείτε ήδη το LoadRunner για τις ανάγκες δοκιμών απόδοσης.

Το λογισμικό LoadRunner είναι στενά ενσωματωμένο με άλλα Εργαλεία HP, όπως το Unified Functional Test (QTP) και το ALM (Application Lifecycle Management) δίνοντάς σας τη δυνατότητα να εκτελείτε τις διαδικασίες δοκιμών από άκρη σε άκρη.

Το LoadRunner λειτουργεί με βάση την αρχή της προσομοίωσης εικονικών χρηστών στη θεματική εφαρμογή. Αυτοί οι Εικονικοί Χρήστες ονομάζονται επίσης VUsers, αναπαράγουν τα αιτήματα του πελάτη και αναμένουν μια αντίστοιχη απόκριση στη μεταβίβαση μιας συναλλαγής.

Γιατί χρειάζεστε Δοκιμές Απόδοσης;

Εκτιμάται απώλεια εσόδων 4.4 δισ καταγράφεται ετησίως λόγω κακής απόδοσης ιστού.

Στη σημερινή εποχή του Web 2.0, οι χρήστες κάνουν κλικ μακριά εάν ένας ιστότοπος δεν ανταποκριθεί εντός 8 δευτερολέπτων. Φανταστείτε τον εαυτό σας να περιμένει για 5 δευτερόλεπτα όταν ψάχνει για Google ή κάνει ένα αίτημα φιλίας στο Facebook. Οι επιπτώσεις του χρόνου διακοπής της απόδοσης είναι συχνά πιο καταστροφικές από ποτέ. Έχουμε παραδείγματα όπως αυτά που πρόσφατα έπληξαν το Bank of America Online Banking, Amazon Υπηρεσίες Web, Intuit ή Blackberry.

Σύμφωνα με την Dunn & Bradstreet, το 59% των εταιρειών του Fortune 500 υφίστανται περίπου 1.6 ώρες διακοπής λειτουργίας κάθε εβδομάδα. Λαμβάνοντας υπόψη ότι η μέση εταιρεία Fortune 500 με ελάχιστους 10,000 υπαλλήλους πληρώνει 56 $ την ώρα, το εργατικό μέρος του κόστους διακοπής λειτουργίας για έναν τέτοιο οργανισμό θα ήταν 896,000 $ εβδομαδιαία, μεταφραζόμενο σε περισσότερα από 46 εκατομμύρια $ ετησίως.

Μόνο 5 λεπτά διακοπής λειτουργίας του Google.com (19-Αυγ-13) εκτιμάται ότι θα κοστίσει στον γίγαντα της αναζήτησης έως και 545,000 $.

Υπολογίζεται ότι οι εταιρείες έχασαν πωλήσεις αξίας 1100 $ ανά δευτερόλεπτο λόγω πρόσφατου Amazon Διακοπή υπηρεσίας Web.

Όταν ένα σύστημα λογισμικού αναπτύσσεται από έναν οργανισμό, μπορεί να αντιμετωπίσει πολλά σενάρια που πιθανώς να οδηγήσουν σε καθυστέρηση απόδοσης. Διάφοροι παράγοντες προκαλούν επιβράδυνση της απόδοσης, μερικά παραδείγματα μπορεί να περιλαμβάνουν:

• Αυξημένος αριθμός εγγραφών που υπάρχουν στη βάση δεδομένων
• Αυξήθηκε ο αριθμός των ταυτόχρονων αιτημάτων στο σύστημα
• μεγαλύτερος αριθμός χρηστών που έχουν πρόσβαση στο σύστημα κάθε φορά σε σύγκριση με το παρελθόν

Τι είναι το LoadRunner Archiδομή;

Σε γενικές γραμμές, η αρχιτεκτονική του HP LoadRunner είναι πολύπλοκη, αλλά εύκολη στην κατανόηση.

Ας υποθέσουμε ότι σας έχει ανατεθεί να ελέγξετε την απόδοση του Amazon.com για 5000 χρήστες

Σε μια πραγματική κατάσταση, όλοι αυτοί οι 5000 χρήστες δεν θα βρίσκονται στην αρχική σελίδα αλλά σε διαφορετική ενότητα των ιστότοπων. Πώς μπορούμε να προσομοιώσουμε διαφορετικά.

VUGen

VUGen ή εικονικός χρήστης Generator είναι ένα IDE (Integrated Development Environment) ή ένας πλούσιος επεξεργαστής κωδικοποίησης. Το VUGen χρησιμοποιείται για την αναπαραγωγή της συμπεριφοράς System Under Load (SUL). Το VUGen παρέχει μια δυνατότητα «εγγραφής» που καταγράφει την επικοινωνία προς και από τον πελάτη και τον διακομιστή με τη μορφή κωδικοποιημένης δέσμης ενεργειών - που ονομάζεται επίσης δέσμη ενεργειών VUser.

Λαμβάνοντας λοιπόν υπόψη το παραπάνω παράδειγμα, το VUGen μπορεί να κάνει εγγραφή για να προσομοιώσει τις ακόλουθες επιχειρηματικές διαδικασίες:

1. Περιήγηση στη σελίδα προϊόντων του Amazon.com
2. Ολοκλήρωση Αγοράς
3. Επεξεργασία πληρωμής
4. Έλεγχος της σελίδας Ο λογαριασμός μου

ελεγκτής

Μόλις οριστικοποιηθεί ένα σενάριο VUser, το Controller είναι ένα από τα κύρια στοιχεία LoadRunner που ελέγχει την προσομοίωση Load διαχειριζόμενος, για παράδειγμα:

• Πόσοι VUsers να προσομοιωθούν σε κάθε επιχειρηματική διαδικασία ή ομάδα VUser
• Συμπεριφορά χρηστών VU (ράμπα προς τα πάνω, ράμπα κάτω, ταυτόχρονη ή ταυτόχρονη φύση κ.λπ.)
• Σενάριο Φύσης Φορτίου π.χ. Πραγματική ζωή ή Στόχο Προσανατολισμός ή επαλήθευση SLA
• Ποια μπεκ ψεκασμού να χρησιμοποιήσετε, πόσοι VUsers σε κάθε εγχυτήρα
• Συλλογή αποτελεσμάτων περιοδικά
• Παραπλάνηση IP
• Αναφορά σφαλμάτων
• Αναφορά συναλλαγών κ.λπ.

Λαμβάνοντας μια αναλογία από τον ελεγκτή του παραδείγματος θα προσθέσει την ακόλουθη παράμετρο στο VUGen Script

1) 3500 χρήστες είναι Περιήγηση στη σελίδα προϊόντων του Amazon.com

2) Συμμετέχουν 750 χρήστες Ολοκλήρωση Αγοράς

3) 500 χρήστες είναι εκτέλεση Επεξεργασίας Πληρωμών

4) 250 χρήστες είναι Έλεγχος της σελίδας "Ο λογαριασμός μου" ΜΟΝΟ αφού 500 χρήστες έχουν ολοκληρώσει την επεξεργασία πληρωμών

Ακόμη πιο περίπλοκα σενάρια είναι πιθανά

1. Εκκινήστε 5 VUsers κάθε 2 δευτερόλεπτα μέχρι να φορτώσετε 3500 VUsers (σερφ Amazon σελίδα προϊόντος) επιτυγχάνεται.
2. Επαναλάβετε για 30 λεπτά
3. Αναστολή επανάληψης για 25 χρήστες VUs
4. Επανεκκινήστε 20 VUSers
5. Ξεκινήστε 2 χρήστες (στο Ταμείο, Επεξεργασία πληρωμών, Σελίδα Οι λογαριασμοί μου) κάθε δευτερόλεπτο.
6. 2500 VUsers θα δημιουργηθούν στη Μηχανή Α
7. Θα δημιουργηθούν 2500 VUsers στη Μηχανή Β

Agents Machine/Load Generators/Injectors

Το HP LoadRunner Controller είναι υπεύθυνο για την προσομοίωση χιλιάδων χρηστών VU – αυτοί οι χρήστες VU καταναλώνουν πόρους υλικού για παράδειγμα επεξεργαστή και μνήμη – θέτοντας έτσι ένα όριο στο μηχάνημα που τους προσομοιώνει. Επιπλέον, το Controller προσομοιώνει αυτούς τους VUsers από το ίδιο μηχάνημα (όπου βρίσκεται ο Controller) και ως εκ τούτου τα αποτελέσματα μπορεί να μην είναι ακριβή. Για να αντιμετωπιστεί αυτή η ανησυχία, όλοι οι χρήστες VU είναι κατανεμημένοι σε διάφορα μηχανήματα, που ονομάζονται Φορτίο Generators ή μπεκ φορτίου.

Κατά γενική πρακτική, ο ελεγκτής βρίσκεται σε διαφορετικό μηχάνημα και το φορτίο προσομοιώνεται από άλλα μηχανήματα. Ανάλογα με το πρωτόκολλο των σεναρίων VUser και τις προδιαγραφές του μηχανήματος, ενδέχεται να απαιτείται ένας αριθμός Load Injectors για την πλήρη προσομοίωση. Για παράδειγμα, οι VUs για ένα σενάριο HTTP θα απαιτούν 2-4 MB ανά VUser για προσομοίωση, επομένως 4 μηχανές με 4 GB RAM το καθένα θα απαιτούνται για την προσομοίωση φορτίου 10,000 VUsers.

Λαμβάνοντας Αναλογία από μας Amazon Για παράδειγμα, η έξοδος αυτού του στοιχείου θα είναι

Ανάλυση

Μόλις εκτελεστούν τα σενάρια φόρτωσης, ο ρόλος του "ΑνάλυσηΤα στοιχεία του LoadRunner μπαίνουν.

Κατά την εκτέλεση, ο Controller δημιουργεί μια ένδειξη αποτελεσμάτων σε ακατέργαστη μορφή και περιέχει πληροφορίες όπως ποια έκδοση του LoadRunner δημιούργησε αυτήν την ένδειξη αποτελεσμάτων και ποιες ήταν οι διαμορφώσεις.

Όλα τα σφάλματα και οι εξαιρέσεις καταγράφονται α Microsoft πρόσβαση στη βάση δεδομένων, με όνομα, output.mdb. Το στοιχείο "Analysis" διαβάζει αυτό το αρχείο βάσης δεδομένων για να εκτελέσει διάφορους τύπους ανάλυσης και δημιουργεί γραφήματα.

Αυτά τα γραφήματα δείχνουν διάφορες τάσεις για την κατανόηση του συλλογισμού πίσω από τα σφάλματα και τις αστοχίες υπό φορτίο. βοηθήστε έτσι να υπολογίσετε εάν απαιτείται βελτιστοποίηση σε SUL, Server (π.χ. JBoss, Oracle) ή υποδομής.

Παρακάτω είναι ένα παράδειγμα όπου το εύρος ζώνης θα μπορούσε να δημιουργήσει ένα σημείο συμφόρησης. Ας υποθέσουμε ότι ο διακομιστής Ιστού έχει χωρητικότητα 1 GBps, ενώ η κίνηση δεδομένων υπερβαίνει αυτή τη χωρητικότητα, προκαλώντας ταλαιπωρία στους επόμενους χρήστες. Για να προσδιορίσει το σύστημα ανταποκρίνεται σε τέτοιες ανάγκες, ο Performance Engineer πρέπει να αναλύσει τη συμπεριφορά της εφαρμογής με μη φυσιολογικό φορτίο. Παρακάτω είναι ένα γράφημα που δημιουργεί το LoadRunner για να προκαλέσει εύρος ζώνης.

Πώς να κάνετε δοκιμές απόδοσης

Ο οδικός χάρτης δοκιμών απόδοσης μπορεί γενικά να χωριστεί σε 5 βήματα:

• Σχεδιασμός για Δοκιμή Φορτίου
• Δημιουργήστε σενάρια VUGen
• Δημιουργία Σεναρίου
• Εκτέλεση Σεναρίου
• Ανάλυση αποτελεσμάτων (ακολουθούμενη από προσαρμογή συστήματος)

Τώρα που εγκαταστήσατε το LoadRunner, ας κατανοήσουμε τα βήματα που περιλαμβάνονται στη διαδικασία ένα προς ένα.

Βήματα που εμπλέκονται στη διαδικασία δοκιμής απόδοσης

Βήμα 1) Σχεδιασμός για τη δοκιμή φορτίου

Ο προγραμματισμός για τη δοκιμή απόδοσης είναι διαφορετικός από τον προγραμματισμό α SIT (Δοκιμή ενοποίησης συστήματος) or UAT (Δοκιμή αποδοχής χρήστη). Ο προγραμματισμός μπορεί περαιτέρω να χωριστεί σε μικρά στάδια όπως περιγράφεται παρακάτω:

Συγκεντρώστε την ομάδα σας

Όταν ξεκινάτε με το LoadRunner Testing, είναι καλύτερο να τεκμηριώσετε ποιος θα συμμετέχει στη δραστηριότητα από κάθε ομάδα που συμμετέχει στη διαδικασία.

Υπεύθυνος Έργου:

Ορίστε τον διαχειριστή έργου που θα είναι ιδιοκτήτης αυτής της δραστηριότητας και θα χρησιμεύσει ως άτομο για την κλιμάκωση.

Function Expert/ Business Analyst:

Παρέχετε ανάλυση χρήσης του SUL & παρέχει τεχνογνωσία σχετικά με την επιχειρηματική λειτουργικότητα του ιστότοπου/SUL

Εμπειρογνώμονας δοκιμών απόδοσης:

Δημιουργεί τις αυτοματοποιημένες δοκιμές απόδοσης και εκτελεί σενάρια φόρτωσης

σύστημα Architec:

Παρέχει σχέδιο του SUL

Προγραμματιστής Ιστού και ΜΜΕ:

• Διατηρεί τον ιστότοπο και παρέχει πτυχές παρακολούθησης
• Αναπτύσσει ιστότοπο και διορθώνει σφάλματα

Διαχειριστής συστήματος:

• Διατηρεί εμπλεκόμενους διακομιστές σε ένα δοκιμαστικό έργο

Περιγράψτε τις εφαρμογές και τις επιχειρηματικές διαδικασίες που εμπλέκονται:

Επιτυχής Δοκιμές φορτίου απαιτεί να σκοπεύετε να πραγματοποιήσετε μια συγκεκριμένη επιχειρηματική διαδικασία. Μια Επιχειρηματική Διαδικασία αποτελείται από σαφώς καθορισμένα βήματα σε συμμόρφωση με τις επιθυμητές επιχειρηματικές συναλλαγές – έτσι ώστε να επιτευχθούν οι στόχοι δοκιμών φορτίου.

Μια μέτρηση απαιτήσεων μπορεί να προετοιμαστεί για να προκαλέσει φόρτο χρήστη στο σύστημα. Παρακάτω είναι ένα παράδειγμα συστήματος παρουσίας σε μια εταιρεία:

Στο παραπάνω παράδειγμα, οι αριθμοί αναφέρουν τον αριθμό των χρηστών που είναι συνδεδεμένοι στην εφαρμογή (SUL) τη δεδομένη ώρα. Μπορούμε να εξαγάγουμε τον μέγιστο αριθμό χρηστών που είναι συνδεδεμένοι σε μια επιχειρηματική διαδικασία οποιαδήποτε ώρα της ημέρας, ο οποίος υπολογίζεται στις δεξιότερες στήλες.

Ομοίως, μπορούμε να συμπεράνουμε τον συνολικό αριθμό των χρηστών που είναι συνδεδεμένοι στην εφαρμογή (SUL) οποιαδήποτε ώρα της ημέρας. Αυτό υπολογίζεται στην τελευταία σειρά.

Τα παραπάνω 2 στοιχεία σε συνδυασμό μας δίνουν τον συνολικό αριθμό των χρηστών με τους οποίους πρέπει να δοκιμάσουμε το σύστημα ως προς την απόδοση.

Καθορισμός Διαδικασιών Διαχείρισης Δεδομένων Δοκιμών

Τα στατιστικά στοιχεία και οι παρατηρήσεις που προέρχονται από το Performance Testing επηρεάζονται σε μεγάλο βαθμό από πολλούς παράγοντες, όπως αναφέρθηκε προηγουμένως. Είναι κρίσιμης σημασίας να προετοιμαστούν τα δεδομένα δοκιμής για τη δοκιμή απόδοσης. Μερικές φορές, μια συγκεκριμένη επιχειρηματική διαδικασία καταναλώνει ένα σύνολο δεδομένων και παράγει ένα διαφορετικό σύνολο δεδομένων. Πάρτε το παρακάτω παράδειγμα:

• Ένας χρήστης «Α» δημιουργεί ένα οικονομικό συμβόλαιο και το υποβάλλει για έλεγχο.
• Ένας άλλος χρήστης "Β" εγκρίνει 200 ​​συμβόλαια την ημέρα που δημιουργούνται από τον χρήστη "Α"
• Ένας άλλος χρήστης "C" πληρώνει περίπου 150 συμβόλαια την ημέρα που έχουν εγκριθεί από τον χρήστη "Β"

Σε αυτήν την περίπτωση, ο χρήστης Β πρέπει να έχει «δημιουργήσει» 200 συμβόλαια στο σύστημα. Επιπλέον, ο χρήστης C χρειάζεται 150 συμβόλαια ως «εγκεκριμένα» προκειμένου να προσομοιώσει ένα φορτίο 150 χρηστών.

Αυτό σημαίνει σιωπηρά ότι πρέπει να δημιουργήσετε τουλάχιστον 200+150= 350 συμβόλαια.

Μετά από αυτό, εγκρίνετε 150 συμβάσεις που θα χρησιμεύσουν ως δεδομένα δοκιμής για τον χρήστη C – οι υπόλοιπες 200 συμβάσεις θα χρησιμεύσουν ως δεδομένα δοκιμής για τον χρήστη Β.

Οθόνες περίγραμμα

Εικασίες για κάθε παράγοντα που θα μπορούσε ενδεχομένως να επηρεάσει την απόδοση ενός συστήματος. Για παράδειγμα, η μείωση του υλικού θα έχει πιθανό αντίκτυπο στην απόδοση του SUL (System Under Load).

Καταχωρίστε όλους τους παράγοντες και ρυθμίστε τις οθόνες για να μπορείτε να τους μετρήσετε. Ακολουθούν μερικά παραδείγματα:

• Επεξεργαστής (για διακομιστή Web, διακομιστή εφαρμογών, διακομιστή βάσης δεδομένων και συσκευές εισαγωγής)
• RAM (για διακομιστή Web, διακομιστή εφαρμογών, διακομιστή βάσεων δεδομένων και συσκευές εισαγωγής)
• Διακομιστής Web/App (για παράδειγμα IIS, JBoss, Jaguar Server, Tomcat κ.λπ.)
• Διακομιστής DB (μέγεθος PGA και SGA σε περίπτωση Oracle και MSSQL Server, SP κ.λπ.)
• Αξιοποίηση εύρους ζώνης δικτύου
• Εσωτερικό και εξωτερικό NIC σε περίπτωση ομαδοποίησης
• Load Balancer (και ότι κατανέμει το φορτίο ομοιόμορφα σε όλους τους κόμβους των συστάδων)
• Ροή δεδομένων (υπολογίστε πόσα δεδομένα μετακινούνται προς και από τον πελάτη και τον διακομιστή – στη συνέχεια υπολογίστε εάν η χωρητικότητα του NIC είναι επαρκής για την προσομοίωση του αριθμού X χρηστών)

Βήμα 2) Δημιουργήστε σενάρια VUGen

Το επόμενο βήμα μετά τον προγραμματισμό είναι η δημιουργία Σενάρια VUser.

Βήμα 3) Δημιουργία Σεναρίου

Το επόμενο βήμα είναι να δημιουργήσετε το σενάριο φόρτωσης

Βήμα 4) Εκτέλεση Σεναρίου

Η εκτέλεση σεναρίου είναι η εξομοίωση του φορτίου χρήστη στον διακομιστή δίνοντας εντολή σε πολλούς χρήστες VU να εκτελούν εργασίες ταυτόχρονα.

Μπορείτε να ορίσετε το επίπεδο ενός φορτίου αυξάνοντας και μειώνοντας τον αριθμό των VUs που εκτελούν εργασίες ταυτόχρονα.

Αυτή η εκτέλεση μπορεί να έχει ως αποτέλεσμα ο διακομιστής να βρίσκεται υπό πίεση και να συμπεριφέρεται ασυνήθιστα. Αυτός είναι ακριβώς ο σκοπός της δοκιμής απόδοσης. Τα αποτελέσματα που προκύπτουν χρησιμοποιούνται στη συνέχεια για λεπτομερή ανάλυση και προσδιορισμό της βασικής αιτίας.

Βήμα 5) Ανάλυση αποτελεσμάτων (ακολουθούμενη από προσαρμογή συστήματος)

Κατά την εκτέλεση του σεναρίου, το LoadRunner καταγράφει την απόδοση της εφαρμογής κάτω από διαφορετικά φορτία. Τα στατιστικά στοιχεία που προέρχονται από την εκτέλεση της δοκιμής αποθηκεύονται και πραγματοποιείται ανάλυση λεπτομερειών. Το εργαλείο «HP Analysis» δημιουργεί διάφορα γραφήματα που βοηθούν στον εντοπισμό των βασικών αιτιών πίσω από μια καθυστέρηση στην απόδοση του συστήματος, καθώς και μια αστοχία συστήματος.

Μερικά από τα γραφήματα που ελήφθησαν περιλαμβάνουν:

• Ώρα για το πρώτο buffer
• Χρόνος απόκρισης συναλλαγής
• Μέσος χρόνος απόκρισης συναλλαγής
• Επιτυχίες ανά δευτερόλεπτο
• Windows Υποστηρικτικό υλικό
• Στατιστικά σφαλμάτων
• Περίληψη συναλλαγών

ΣΥΧΝΕΣ ΕΡΩΤΗΣΕΙΣ