Εργαλείο δοκιμής LoadRunner: ArchiΔιάγραμμα δομής και στοιχεία

Τι είναι το LoadRunner;

Το LoadRunner είναι ένα Δοκιμές Απόδοσης εργαλείο το οποίο πρωτοστάτησε ο Mercury Interactive το 1999. Η LoadRunner εξαγοράστηκε αργότερα από την HP το 2006 και η επιχείρηση λογισμικού της HP συγχωνεύτηκε με την Micro Focus σε μια συμφωνία που ανακοινώθηκε το 2016 και ολοκληρώθηκε το 2017.

Σημείωση μάρκας: OpenText ολοκλήρωσε την εξαγορά της Micro Focus τον Ιανουάριο του 2023Το εργαλείο δεν πωλείται πλέον ως HP ή Micro Focus LoadRunner: Το LoadRunner Professional είναι τώρα OpenText Επαγγελματική Μηχανική Απόδοσης, η LoadRunner Enterprise είναι OpenText Η Μηχανική Επιχειρηματικής Απόδοσης και το LoadRunner Cloud είναι OpenText Βασική Μηχανική Απόδοσης. Τα ονόματα των παρακάτω στοιχείων — VuGen, Ελεγκτής, γεννήτριες φορτίου και Ανάλυση — παραμένουν αμετάβλητα.

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

Βίντεο LoadRunner

Παρακολουθήστε το παρακάτω βίντεο για μια γρήγορη εισαγωγή στο LoadRunner πριν επεξεργαστείτε τα στοιχεία.

Γιατί LoadRunner;

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

Η κάλυψη πρωτοκόλλου είναι ο σαφέστερος λόγος που οι ομάδες το επιλέγουν, όπως δείχνει ο χάρτης στοιχείων παρακάτω.

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

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

Το λογισμικό LoadRunner είναι άρτια ενσωματωμένο με τα αντίστοιχα εργαλεία στην ίδια σουίτα — Ενοποιημένοι Λειτουργικοί Έλεγχοι (το πρώτο QTP, τώρα πωλείται ως OpenText Λειτουργικές Δοκιμές) και ALM (Διαχείριση Κύκλου Ζωής Εφαρμογών, τώρα OpenText ALM/Κέντρο Ποιότητας) — το οποίο σας δίνει τη δυνατότητα να εκτελείτε τις ολοκληρωμένες διαδικασίες δοκιμών σας.

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

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

Οι παρακάτω εκτιμήσεις του κλάδου αναφέρονται ευρέως και χρονολογούνται από τις αρχές της δεκαετίας του 2010, αλλά το μοτίβο που περιγράφουν δεν έχει αλλάξει: οι αργές σελίδες κοστίζουν χρήματα.

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

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

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

Μόνο 5 λεπτά χρόνος διακοπής GoogleΤο .com τον Αύγουστο του 2013 εκτιμάται ότι κόστισε στον γίγαντα της αναζήτησης έως και 545,000 δολάρια.

Υπολογίζεται ότι οι εταιρείες έχασαν πωλήσεις αξίας 1,100 δολαρίων ανά δευτερόλεπτο κατά τη διάρκεια του παρελθόντος... Amazon Διακοπή λειτουργίας των υπηρεσιών ιστού.

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

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

Δεν είναι, ωστόσο, κάθε αίτηση υποψήφια. Δοκιμές φορτίου Στοχεύει σε συστήματα client-server, πολλαπλών χρηστών, επομένως ένα βοηθητικό πρόγραμμα επιφάνειας εργασίας για έναν χρήστη όπως αυτό που ακολουθεί δεν αξίζει να δοκιμαστεί για απόδοση.

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

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

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

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

VuGen

VuGen ή Εικονικός Χρήστης Generator είναι ένα IDE (Ολοκληρωμένο Περιβάλλον Ανάπτυξης) ή ένας εμπλουτισμένος επεξεργαστής κώδικα. Το VuGen χρησιμοποιείται για την αναπαραγωγή της συμπεριφοράς System Under Load (SUL). Το VuGen παρέχει μια λειτουργία «εγγραφής» που καταγράφει την επικοινωνία από και προς τον πελάτη και τον διακομιστή με τη μορφή κωδικοποιημένου σεναρίου - που ονομάζεται επίσης Σενάριο VUser.

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

• Περιήγηση στη σελίδα προϊόντων του Amazon.com
• Μετάβαση στο ταμείο
• Επεξεργασία πληρωμής
• Έλεγχος της σελίδας Ο λογαριασμός μου

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

ελεγκτής

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

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

Λαμβάνοντας υπόψη το παράδειγμά μας, ο Ελεγκτής θα προσθέσει τις ακόλουθες παραμέτρους στο σενάριο VuGen:

1. 3500 χρήστες περιηγούνται στη σελίδα προϊόντων του Amazon.com
2. 750 χρήστες βρίσκονται στο Ταμείο
3. 500 χρήστες εκτελούν επεξεργασία πληρωμών
4. 250 χρήστες ελέγχουν τη σελίδα "Ο λογαριασμός μου" ΜΟΝΟ αφού 500 χρήστες έχουν ολοκληρώσει την επεξεργασία πληρωμής

Είναι πιθανά ακόμη πιο σύνθετα σενάρια:

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

Agents Machine/Load Generators/Injectors

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

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

Παίρνοντας την αναλογία από το δικό μας Amazon Για παράδειγμα, η έξοδος αυτού του στοιχείου είναι οι 5000 χρήστες VUsers, χωρισμένοι σε δύο εγχυτήρες: 2500 χρήστες VUsers που δημιουργούνται στο Μηχανή Α και 2500 στο Μηχανή Β.

Ανάλυση

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

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

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

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

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

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

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

1. Σχεδιασμός για Δοκιμή Φορτίου
2. Δημιουργία σεναρίων VuGen
3. Δημιουργία Σεναρίου
4. Εκτέλεση Σεναρίου
5. Ανάλυση αποτελεσμάτων (ακολουθούμενη από προσαρμογή συστήματος)

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

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

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

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

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

• Υπεύθυνος Έργου: Ορίστε τον διαχειριστή έργου που θα είναι ιδιοκτήτης αυτής της δραστηριότητας και θα χρησιμεύσει ως άτομο για την κλιμάκωση.
• Ειδικός Λειτουργιών / Αναλυτής Επιχειρήσεων: Παρέχει Ανάλυση Χρήσης του SUL και εμπειρογνωμοσύνη σχετικά με την επιχειρηματική λειτουργικότητα του ιστότοπου ή του SUL.
• Εμπειρογνώμονας δοκιμών απόδοσης: Δημιουργεί τις αυτοματοποιημένες δοκιμές απόδοσης και εκτελεί σενάρια φόρτωσης.
• σύστημα Architec: Παρέχει το σχέδιο του SUL.
• Προγραμματιστής Ιστού και ΜΜΕ: Συντηρεί τον ιστότοπο, παρέχει υπηρεσίες παρακολούθησης, αναπτύσσει τον ιστότοπο και διορθώνει σφάλματα.
• Διαχειριστής συστήματος: Διατηρεί τους εμπλεκόμενους διακομιστές καθ' όλη τη διάρκεια ενός έργου δοκιμών.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Το επόμενο βήμα είναι να δημιουργήσετε το Σενάριο Φόρτωσης στον Ελεγκτή, επιλέγοντας μεταξύ ενός χειροκίνητου και ενός σεναρίου με στόχο.

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

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

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

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

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

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

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

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

Συχνές Ερωτήσεις