Δοκιμές απόδοσης SAP: φορτίο, ταυτοχρονισμός και εργαλεία

Οι δοκιμές απόδοσης SAP αποδεικνύουν, πριν από το go-live, ότι οι κρίσιμες συναλλαγές, οι εργασίες παρασκηνίου και οι διεπαφές πετυχαίνουν τους συμφωνημένους χρόνους απόκρισης όταν πολλοί χρήστες και εργασίες τρέχουν ταυτόχρονα. Κατά την εμπειρία μου οι δοκιμές ταυτοχρονισμού είναι αυτές που μετράνε, σε δεδομένα με απόκρυψη σε όγκο παραγωγής, με κριτήρια επιτυχίας και αποτυχίας που συμφώνησε η επιχείρηση πριν από την πρώτη εκτέλεση.

Αυτός ο οδηγός απευθύνεται σε CIOs, διευθυντές προγραμμάτων και υπευθύνους δοκιμών σε προγράμματα S/4HANA, μεταξύ αυτών και RISE with SAP. Καλύπτει τι να δοκιμάσετε, τα δεδομένα που χρειάζεστε, πώς γράφονται κριτήρια αποδοχής, ποια εργαλεία κάνουν τη δουλειά και ποιος έχει την ευθύνη για τι. Για το πού βρίσκεται η απόδοση ανάμεσα στους άλλους τύπους δοκιμών, ξεκινήστε από την επισκόπησή μου για τις δοκιμές SAP με απλά λόγια.

Τα προβλήματα απόδοσης στα προγράμματα SAP σπάνια είναι έκπληξη.

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

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

Οι δοκιμές απόδοσης στις φάσεις του SAP Activate

1. 01

   Explore

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

2. 02

   Realize

   Εκτελέστε δοκιμές όγκου και φορτίου καθώς σταθεροποιείται η παραμετροποίηση. Η μερική παραμετροποίηση δίνει παραπλανητικά αποτελέσματα.

3. 03

   Πριν από το UAT

   Ολοκληρώστε τον πλήρη κύκλο απόδοσης πριν από το UAT, όχι ως μέρος του.

4. 04

   Μετάβαση

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

5. 05

   Hypercare

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

Σε ένα σύστημα ECC πάνω σε παραδοσιακή βάση δεδομένων, οι δοκιμές απόδοσης σήμαιναν δοκιμές φορτίου στον application server και στη βάση δεδομένων: χρόνος εκτέλεσης ABAP, απόδοση SQL και χρονοπρογραμματισμός εργασιών. Το front end ήταν το SAP GUI, που σπάνια εξέπληττε κανέναν.

Στο S/4HANA, με front ends Fiori, επεκτάσεις στο SAP BTP και ενοποίηση μέσω του SAP Cloud Integration, η απόδοση εξαρτάται από πολλά επίπεδα ταυτόχρονα. Ένα αργό tile του Fiori μπορεί να είναι μια μακροσκελής κλήση ABAP, ένα χρονικό όριο στο gateway, μια υπηρεσία OData που δεν σχεδιάστηκε για ταυτόχρονα αιτήματα ή καθυστέρηση δικτύου σε ένα υβριδικό περιβάλλον. Αν δοκιμάσετε μόνο το back end, δεν θα το βρείτε.

1. 01Άνοιγμα tileΚύματα συνδέσεων στην αρχή της βάρδιας
2. 02Κλήση ODataΧρονικά όρια στο gateway, υπηρεσίες που δεν φτιάχτηκαν για ταυτοχρονισμό
3. 03Επεξεργασία ABAPΜακροσκελείς κλήσεις ABAP
4. 04Ανάγνωση βάσης δεδομένωνΕπιλογές χωρίς όριο σε μεγάλους πίνακες
5. 05Απόδοση οθόνηςΣυν την καθυστέρηση δικτύου για απομακρυσμένες τοποθεσίες

Ένας χρόνος απόκρισης, μετρημένος από άκρη σε άκρη

Οι δοκιμές απόδοσης στο SAP HANA έχουν τη δική τους ιδιαιτερότητα σε μια μετατροπή. Σταθερός κώδικας ECC συμπεριφέρεται διαφορετικά σε μια in-memory βάση δεδομένων. Πολλά προγράμματα γίνονται πολύ ταχύτερα, ενώ κάποια παρουσιάζουν απρόσμενη συμπεριφορά σε συγκεκριμένα μοτίβα δεδομένων, οπότε η παλινδρόμηση του βαρύ προσαρμοσμένου κώδικα ειδικά για τη μετατροπή δεν είναι προαιρετική.

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

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

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

Ο πίνακας δείχνει τι αποδεικνύει κάθε τύπος δοκιμής και πότε να τον εκτελέσετε:

Δοκιμή	Τι αποδεικνύει	Πότε εκτελείται	Τι βρίσκει συνήθως
Ταυτοχρονισμού	Πολλοί χρήστες και εργασίες μπορούν να δουλεύουν στα ίδια αντικείμενα ταυτόχρονα	Realize, μόλις σταθεροποιηθεί η παραμετροποίηση, και ξανά πριν από το UAT	Αναμονές κλειδωμάτων, κύματα συνδέσεων, σημεία συμφόρησης στο gateway
Φορτίου	Το σύστημα πετυχαίνει τους χρόνους απόκρισης στον αναμενόμενο όγκο αιχμής	Realize, αφού δουλέψουν τα scripts ταυτοχρονισμού	Αργές υπηρεσίες OData, βαριές προσαρμοσμένες αναφορές
Καταπόνησης	Πού σπάει το σύστημα πάνω από τα όρια σχεδιασμού	Πριν από το UAT, αν αναμένεται ανάπτυξη	Κενά στη διαστασιολόγηση, όρια ουρών
Αντοχής (soak)	Το σύστημα κρατά σταθερό φορτίο για ώρες	Πριν από το UAT, ιδανικά σε ένα προσομοιωμένο κλείσιμο	Αύξηση μνήμης, ανταγωνισμός αλυσίδων εργασιών σε επαναλαμβανόμενες εκτελέσεις
Από άκρη σε άκρη	Η πλήρης διαδρομή που περιμένει ο χρήστης πετυχαίνει τον στόχο	Παράλληλα με τις δοκιμές φορτίου	Προβλήματα αόρατα όταν κάθε επίπεδο δοκιμάζεται μόνο του

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

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

Γράψτε πρώτα scripts για αυτά. Καλύπτουν τις περισσότερες αποτυχίες που φτάνουν στην παραγωγή.

1. Αλλαγή βάρδιας και αιχμή συνδέσεων. Όταν μερικές εκατοντάδες χρήστες ανοίγουν ταυτόχρονα το Fiori launchpad, η αυθεντικοποίηση και η φόρτωση του launchpad εκτινάσσονται. Ένα σύστημα που είναι εντάξει εκτός αιχμής μπορεί να είναι άχρηστο σε εκείνο το παράθυρο αν οι ταυτόχρονες συνδέσεις δεν δοκιμάστηκαν ποτέ.
2. Κλείσιμο μήνα και κλείσιμο χρήσης. Καταχωρήσεις μεγάλου όγκου, αλυσίδες εργασιών με αυστηρή σειρά και μια ομάδα Οικονομικών που τρέχει πίσω από μια σταθερή προθεσμία. Εκτελέστε τις αλυσίδες εργασιών του κλεισίματος από άκρη σε άκρη με όγκους περιόδου κλεισίματος, όχι με μέσους ημερήσιους όρους.
3. Επικαλυπτόμενες εργασίες παρασκηνίου. Οι εργασίες batch συνήθως δοκιμάζονται μία μία, κάτι που δεν αντιστοιχεί στην πραγματικότητα. Μια κακώς βελτιστοποιημένη εργασία μπορεί να μπλοκάρει αρκετές άλλες, και το κλείσιμο ξεπερνά το παράθυρό του.
4. Προσαρμοσμένες αναφορές χωρίς όριο επιλογής. Μια αναφορά που επιστρέφει αμέσως σε δεδομένα δοκιμών μπορεί να τρέχει λεπτά σε μια ολόκληρη χρήση. Δοκιμάστε τυπικές επιλογές και επιλογές χειρότερης περίπτωσης, και μπλοκάρετε τις επιλογές χωρίς όριο.
5. Χρήστες σε πολλές περιοχές. Η καθυστέρηση δικτύου επηρεάζει κάθε συναλλαγή. Το RISE μεταφέρει τη φιλοξενία στη SAP, αλλά η καθυστέρηση εξαρτάται ακόμη από την περιοχή που επιλέγετε και από τη δρομολόγηση προς τους χρήστες σας, οπότε δοκιμάστε από τις πιο απομακρυσμένες τοποθεσίες.

Ο οδηγός μου για τη μετάπτωση από ECC σε S/4HANA εξηγεί πού μπαίνουν οι δοκιμές της μετατροπής στο ευρύτερο σχέδιο.

Δεδομένα δοκιμών σε επίπεδο παραγωγής

Τα δεδομένα κρίνουν αν οτιδήποτε από αυτά σημαίνει κάτι. Επιμένω σε δεδομένα με απόκρυψη σε επίπεδο παραγωγής: όγκος και ρεαλισμός παραγωγής, με τα προσωπικά και ευαίσθητα πεδία κρυμμένα.

Ένας πελάτης με 200.000 ανοιχτές γραμμές παραγγελιών συμπεριφέρεται διαφορετικά από έναν με 5.000. Φίλτρα που επιστρέφουν αμέσως σε ένα αραιό client δοκιμών λήγουν λόγω χρονικού ορίου στην παραγωγή. Γεμίστε με όγκο τις περιοχές υψηλού κινδύνου, χρησιμοποιήστε αντιπροσωπευτικό μείγμα συναλλαγών και κάντε πραγματικές κλήσεις διεπαφών όπου μπορείτε.

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

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

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

Στοιχείο	Συνθήκη φορτίου	Όριο επιτυχίας	Υπεύθυνος
Δημιουργία παραγγελίας πώλησης (VA01 ή εφαρμογή Fiori)	150 ταυτόχρονοι χρήστες καταχώρησης παραγγελιών	Κάτω από 3 δευτερόλεπτα για το 95% των συναλλαγών	Υπεύθυνος διαδικασίας order-to-cash
Πρώτη φόρτωση του Fiori launchpad στην αρχή της βάρδιας	Ταυτόχρονες συνδέσεις αιχμής για τη μεγαλύτερη βάρδια	Κάτω από 5 δευτερόλεπτα για το 95% των χρηστών	Επικεφαλής λειτουργιών IT
Αλυσίδα εργασιών κλεισίματος μήνα	Όγκοι περιόδου κλεισίματος, πλήρης αλληλουχία	Ολοκληρώνεται μέσα στο συμφωνημένο παράθυρο κλεισίματος χωρίς διακοπές	Οικονομικός ελεγκτής (financial controller)
Διεπαφή εισερχόμενων παραγγελιών	Ωριαίος όγκος μηνυμάτων αιχμής	Καμία καθυστέρηση στην ουρά παλαιότερη από 15 λεπτά	Επικεφαλής ενοποίησης
Προσαρμοσμένη αναφορά μεγάλου όγκου	Πλήρης όγκος δεδομένων παραγωγής, τυπική επιλογή	Κάτω από 60 δευτερόλεπτα. Οι επιλογές χωρίς όριο μπλοκάρονται	Υπεύθυνος αναφοράς

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

Αν το σύστημα πέρασε επειδή οι χρήστες του UAT είπαν ότι το ένιωθαν γρήγορο, έχετε μια γνώμη, όχι κριτήριο αποδοχής. Κάντε τα αποτελέσματα επίσημη πύλη πριν από τη μετάβαση, όπως περιγράφει ο οδηγός μου για τις πύλες ποιότητας στο SAP. Το συνολικό σχέδιο κύκλων, με κριτήρια εισόδου και εξόδου για κάθε φάση δοκιμών, ανήκει στη στρατηγική δοκιμών S/4HANA σας.

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

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

Οι βασικές επιλογές το 2026:

Εργαλείο	Ρόλος	Τι πρέπει να ξέρετε
OpenText Professional Performance Engineering	Παραγωγή φορτίου	Το προϊόν που παλαιότερα λεγόταν LoadRunner Professional. Τα πακέτα πρωτοκόλλων του καλύπτουν SAP, SAP GUI και SAP Web
Tricentis NeoLoad	Παραγωγή φορτίου	Η Tricentis αναφέρει υποστήριξη για SAP GUI, Fiori, RFC και IDoc, και μπορεί να επαναχρησιμοποιεί στοιχεία του Tricentis Tosca
Apache JMeter	Παραγωγή φορτίου	Ανοιχτού κώδικα. Παράγει κίνηση HTTP, όπως κλήσεις Fiori και OData
SAP Cloud ALM	Διαχείριση δοκιμών	Προετοιμάζει και εκτελεί χειροκίνητες και αυτοματοποιημένες περιπτώσεις δοκιμών και παρακολουθεί σφάλματα. Δεν παράγει το ίδιο φορτίο
SAP Solution Manager	Διαχείριση δοκιμών	Η κύρια συντήρηση λήγει στις 31 Δεκεμβρίου 2027, οπότε σχεδιάστε τη νέα δουλειά στο Cloud ALM

Για ευρύτερη εικόνα των λειτουργικών εργαλείων και των εργαλείων αυτοματοποίησης, δείτε τη σύγκρισή μου για τα εργαλεία δοκιμών και επικύρωσης SAP. Το εργαλείο μετράει λιγότερο από τα scripts, τα δεδομένα και τα κριτήρια.

Το RISE with SAP μοιράζει την ευθύνη

Στο RISE with SAP, η SAP έχει την υποδομή: διαστασιολόγηση, περιοχή hyperscaler, δίκτυο και διαθεσιμότητα πλατφόρμας. Ο πελάτης και ο συνεργάτης έχουν το επίπεδο της εφαρμογής.

Το έγγραφο ρόλων και ευθυνών του RISE της SAP είναι σαφές. Η εκτέλεση δοκιμών φορτίου και η βελτιστοποίηση ακριβών εντολών SQL είναι SAP Cloud Application Services με πρόσθετη χρέωση. Αν δεν τις αγοράσετε, τη δουλειά την κάνει ο πελάτης.

Μια συνηθισμένη αποτυχία στα προγράμματα RISE είναι η υπόθεση ότι η SAP θα πιάσει τα προβλήματα απόδοσης επειδή λειτουργεί την υποδομή. Θα πιάσει τα προβλήματα υποδομής. Γράψτε τον καταμερισμό στον καταστατικό χάρτη του έργου και στο σχέδιο δοκιμών:

1. SAP: διαθεσιμότητα υποδομής και απόκριση σε επίπεδο πλατφόρμας
2. Συνεργάτης: απόδοση της εφαρμογής υπό το καθορισμένο φορτίο, μαζί με επεκτάσεις και ροές ενοποίησης
3. Πελάτης: αποτελέσματα σε επίπεδο διαδικασίας, όπως ο χρόνος κλεισίματος και η ροή παραγγελιών, και η απόφαση αποδοχής

Το public cloud στενεύει το εύρος

Στο public edition του cloud ERP της SAP, το σύστημα τρέχει σε κοινόχρηστη πλατφόρμα που λειτουργεί η SAP. Πριν σχεδιάσετε οποιαδήποτε δοκιμή φορτίου σε ένα tenant, ρωτήστε γραπτώς τη SAP αν επιτρέπεται και πόση προειδοποίηση χρειάζεται.

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

Συνηθισμένα λάθη

1. Να θεωρείτε τις λειτουργικές δοκιμές δοκιμές απόδοσης. Οι λειτουργικές δοκιμές αποδεικνύουν ότι μια συναλλαγή δίνει το σωστό αποτέλεσμα. Δεν λένε τίποτα για 150 ανθρώπους που την εκτελούν ταυτόχρονα.
2. Να αφήνετε την απόδοση στο Basis. Το Basis έχει τη διαστασιολόγηση και τον χρονοπρογραμματισμό εργασιών. Δεν έχει τον σχεδιασμό των αναφορών, την αρχιτεκτονική των υπηρεσιών OData ή τον σχεδιασμό των ροών ενοποίησης, και αυτά καθορίζουν την απόδοση της εφαρμογής.
3. Να δίνετε την ευθύνη μόνο στο QA. Το QA εκτελεί δοκιμές και αναφέρει αποτελέσματα, αλλά οι αποφάσεις που προκαλούν προβλήματα απόδοσης παίρνονται στον σχεδιασμό. Ένας υπεύθυνος δοκιμών ή αρχιτέκτονας σε επίπεδο προγράμματος χρειάζεται την εξουσία να τις αμφισβητεί νωρίς, και ο πίνακας RACI πρέπει να λέει ποιος μπορεί να μπλοκάρει το go-live για λόγους απόδοσης.
4. Να αποδέχεστε κενά ως γνωστά θέματα. Τα περισσότερα προγράμματα με προβλήματα απόδοσης στην παραγωγή δεν παρέλειψαν τις δοκιμές. Δοκίμασαν χωρίς συμφωνημένα κριτήρια ή δοκίμασαν και έπειτα αποδέχτηκαν τις αποτυχίες υπό την πίεση του χρονοδιαγράμματος.

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

Έπειτα ελέγξτε δύο πράγματα: ότι στο σχέδιο υπάρχει ανανέωση δεδομένων σε όγκο παραγωγής με απόκρυψη, και ότι ο κύκλος ταυτοχρονισμού ολοκληρώνεται πριν ξεκινήσει το UAT.

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

Τι είναι οι δοκιμές απόδοσης SAP;

Ελέγχουν πώς συμπεριφέρεται το SAP υπό ρεαλιστικό φορτίο: χρόνους απόκρισης για τις συναλλαγές των χρηστών, χρόνους εκτέλεσης για τις εργασίες παρασκηνίου, ρυθμό διεκπεραίωσης για τις διεπαφές και χρήση πόρων όταν πολλοί άνθρωποι δουλεύουν ταυτόχρονα. Πρέπει να γίνουν πριν από το go-live.

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

Πότε πρέπει να ξεκινούν οι δοκιμές απόδοσης σε ένα πρόγραμμα SAP;

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

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

Ποια είναι η διαφορά ανάμεσα στις δοκιμές φορτίου και στις δοκιμές ταυτοχρονισμού στο SAP;

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

Κατά την εμπειρία μου οι δοκιμές ταυτοχρονισμού είναι οι σημαντικές. Εκτελέστε τες πρώτες και έπειτα χτίστε την πλήρη δοκιμή φορτίου πάνω τους.

Ποια δεδομένα δοκιμών πρέπει να χρησιμοποιούν οι δοκιμές απόδοσης SAP;

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

Ποια εργαλεία χρησιμοποιούνται για τις δοκιμές απόδοσης SAP;

Γεννήτριες φορτίου όπως το OpenText Professional Performance Engineering (παλαιότερα LoadRunner Professional), το Tricentis NeoLoad και το Apache JMeter παράγουν το φορτίο. Το SAP Cloud ALM ή το SAP Solution Manager διαχειρίζονται τις περιπτώσεις δοκιμών και τα αποτελέσματα, και η παρακολούθηση από την πλευρά της SAP δείχνει τι έκανε το σύστημα υπό φορτίο.

Ποιος έχει την ευθύνη των δοκιμών απόδοσης στο RISE with SAP;

Η SAP έχει την υποδομή: διαστασιολόγηση, περιοχή, δίκτυο και διαθεσιμότητα πλατφόρμας. Το έγγραφο ρόλων και ευθυνών του RISE αφήνει την εκτέλεση των δοκιμών φορτίου και τη βελτιστοποίηση ακριβών εντολών SQL στον πελάτη, εκτός αν αγοραστούν SAP Cloud Application Services με πρόσθετη χρέωση.

Ο πελάτης και ο συνεργάτης έχουν την απόδοση της εφαρμογής και την απόφαση αποδοχής. Γράψτε τον καταμερισμό στα κριτήρια αποδοχής, ώστε κάθε όριο να έχει υπεύθυνο.