Τι είναι το HP TestRunner Testing Tool; Αρχιτεκτονική, συστατικά

Τι είναι το LoadRunner;

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

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

Σε αυτό το σεμινάριο, θα μάθετε-

• Γιατί LoadRunner;
• Γιατί χρειάζεστε Δοκιμή απόδοσης;
• Τι είναι η Αρχιτεκτονική LoadRunner;
• Χάρτης πορείας δοκιμής απόδοσης: Λεπτομερή βήματα
• Συχνές ερωτήσεις

Γιατί LoadRunner;

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

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

Αυτό που είναι πιο πειστικό να επιλέξετε το 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 Services, το 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 $ ανά δευτερόλεπτο λόγω πρόσφατης διακοπής της υπηρεσίας Web στο Amazon.

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

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

Τι είναι η Αρχιτεκτονική LoadRunner;

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

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

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

VUGen:

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

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

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

Ελεγκτής

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

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

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

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

2) 750 χρήστες βρίσκονται στο Ταμείο

3) 500 χρήστες εκτελούν επεξεργασία πληρωμών

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

Ακόμα πιο πολύπλοκα σενάρια είναι δυνατά

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

Πράκτορες Μηχανή / Γεννήτριες φορτίων / Μπεκ

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

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

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

Ανάλυση:

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

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

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

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

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

Χάρτης πορείας δοκιμής απόδοσης: Λεπτομερή βήματα

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

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

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

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

Προγραμματισμός για τη δοκιμή φορτίου

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

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

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

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

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

Εμπειρογνώμονας / Αναλυτής Επιχειρήσεων:

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

Ειδικός δοκιμής απόδοσης:

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

Αρχιτέκτονας συστήματος:

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

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

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

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

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

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

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

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

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

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

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

Ορίστε τις Διαδικασίες Διαχείρισης Δεδομένων Δοκιμής

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

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

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

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

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

Οθόνες περιλήψεων

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

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

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

Δημιουργία σεναρίων VUGen

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

Δημιουργία σεναρίου

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

Εκτέλεση σεναρίου

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

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

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

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

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

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

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

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

Ποιες εφαρμογές πρέπει να δοκιμάσουμε την απόδοση;

Η Δοκιμή απόδοσης πραγματοποιείται πάντα μόνο για συστήματα που βασίζονται σε διακομιστή-πελάτη. Αυτό σημαίνει, κάθε εφαρμογή που δεν είναι αρχιτεκτονική που βασίζεται σε διακομιστή-πελάτη, δεν πρέπει να απαιτεί Performance Testing.

Για παράδειγμα, το Microsoft Calculator δεν βασίζεται σε διακομιστή-πελάτη ούτε εκτελεί πολλούς χρήστες. Ως εκ τούτου, δεν είναι υποψήφιος για Δοκιμή απόδοσης.

Ποια είναι η διαφορά μεταξύ του Performance Testing & Performance Engineering

Είναι σημαντικό να κατανοήσουμε τη διαφορά μεταξύ του Performance Testing και του Performance Engineering. Μία κατανόηση κοινοποιείται παρακάτω:

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

Η απόδοση μηχανικής είναι η διαδικασία με την οποία το λογισμικό δοκιμάζεται και συντονίζεται με σκοπό την πραγματοποίηση της απαιτούμενης απόδοσης. Αυτή η διαδικασία στοχεύει στη βελτιστοποίηση του πιο σημαντικού χαρακτηριστικού απόδοσης της εφαρμογής, δηλαδή της εμπειρίας χρήστη.

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