Τι είναι το System Testing - Ένας απόλυτος οδηγός για αρχάριους

what is system testing ultimate beginner s guide

Τι είναι η δοκιμή συστήματος στη δοκιμή λογισμικού;

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

Ο έλεγχος συστήματος πραγματοποιείται μετά τον Έλεγχο ενοποίησης. Αυτό παίζει σημαντικό ρόλο στην παροχή ενός προϊόντος υψηλής ποιότητας.

Λίστα μαθημάτων:

• Τι είναι ο έλεγχος συστήματος
• Δοκιμή συστήματος από άκρο σε άκρο

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

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

Εάν μια εφαρμογή έχει τρεις ενότητες Α, Β και Γ, τότε ο έλεγχος πραγματοποιείται συνδυάζοντας τις ενότητες Α & Β ή την ενότητα Β & Γ ή την ενότητα Α & Γ είναι γνωστός ως Έλεγχος ενοποίησης. Η ολοκλήρωση και των τριών ενοτήτων και η δοκιμή του ως πλήρους συστήματος ονομάζεται Δοκιμή συστήματος.

Τι θα μάθετε:

• Η εμπειρία μου
  • Παράδειγμα δοκιμής συστήματος
• Πλησιάζω
• Γιατί δοκιμή συστήματος;
• Αυτή είναι μια δοκιμή λευκού ή μαύρου κουτιού;
• Πώς να εκτελέσετε τη δοκιμή συστήματος;
  • Τι να δοκιμάσετε;
• Πλεονεκτήματα
• Κριτήρια εισόδου / εξόδου
• Σχέδιο δοκιμής συστήματος
• Διαδικασία για την εγγραφή περιπτώσεων δοκιμής συστήματος
• Θήκες δοκιμής συστήματος
• Τύποι δοκιμών συστήματος
  • Περισσότεροι τύποι δοκιμών συστήματος
• Τι είναι ο έλεγχος ολοκλήρωσης συστήματος;
• Διαφορά μεταξύ δοκιμής συστήματος και αποδοχής
• Συμβουλές για την εκτέλεση της δοκιμής συστήματος
• συμπέρασμα
• Συνιστώμενη ανάγνωση

Η εμπειρία μου

Λοιπόν ... νομίζετε πραγματικά ότι θα χρειαστεί πολύς χρόνος για να δοκιμάσετε αυτό που καλείτε Δοκιμή συστήματος , ακόμη και αφού αφιερώσατε πολλή προσπάθεια στο Integration Testing;

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

Έπρεπε να συνδυάσω με ένα παράδειγμα:

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

Πυροβόλησε, απάντησε.

Παράδειγμα δοκιμής συστήματος

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

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

ποιο είναι το καλύτερο δωρεάν καθαριστικό μητρώου

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

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

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

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

Αφήγησα το παράδειγμα εδώ για να ενθαρρύνω τη σημασία αυτού του τεστ.

Πλησιάζω

Εκτελείται όταν ολοκληρωθεί ο Έλεγχος Ενσωμάτωσης.

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

Περιέχει λειτουργικούς και μη λειτουργικούς τομείς εφαρμογής / προϊόντος.

Κριτήρια εστίασης:

Επικεντρώνεται κυρίως στα ακόλουθα:

1. Εξωτερικές διεπαφές
2. Πολυπρόγραμμα και σύνθετες λειτουργίες
3. Ασφάλεια
4. Ανάκτηση
5. Εκτέλεση
6. Ομαλή αλληλεπίδραση χειριστή και χρήστη με το σύστημα
7. Εγκατάσταση
8. Τεκμηρίωση
9. Ευχρηστία
10. Φόρτωση / άγχος

Γιατί δοκιμή συστήματος;

# 1) Είναι πολύ σημαντικό να ολοκληρωθεί ένας πλήρης κύκλος δοκιμών και το ST είναι το στάδιο στο οποίο γίνεται.

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

# 3) Βοηθά στην ελαχιστοποίηση της αντιμετώπισης προβλημάτων μετά την ανάπτυξη και την υποστήριξη κλήσεων.

# 4 ) Σε αυτό το στάδιο STLC Εφαρμογή Αρχιτεκτονική και Επιχειρηματικές απαιτήσεις, και οι δύο δοκιμάζονται.

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

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

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

Παρακάτω είναι μόνο μερικά παραδείγματα για να δείξετε πώς θα επηρεάσει η Δοκιμή Συστήματος εάν δεν γίνει σωστά.

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

Αυτή είναι μια δοκιμή λευκού ή μαύρου κουτιού;

Η δοκιμή συστήματος μπορεί να θεωρηθεί ως τεχνική δοκιμής μαύρου κουτιού.

Δοκιμή μαύρου κουτιού Η τεχνική δεν απαιτεί εσωτερική γνώση του κώδικα, ενώ η τεχνική του λευκού κουτιού απαιτεί εσωτερική γνώση του κώδικα.

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

Τεχνική Black Box:

Πώς να εκτελέσετε τη δοκιμή συστήματος;

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

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

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

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

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

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

Αυτή η δοκιμή γίνεται με προγραμματισμένο και συστηματικό τρόπο.

Παρακάτω δίνονται τα διάφορα βήματα κατά την εκτέλεση αυτής της δοκιμής:

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

Τι να δοκιμάσετε;

Τα σημεία που αναφέρονται παρακάτω καλύπτονται σε αυτήν τη δοκιμή:

• Δοκιμή End to End η οποία περιλαμβάνει την επαλήθευση της αλληλεπίδρασης μεταξύ όλων των στοιχείων και μαζί με τα εξωτερικά περιφερειακά για να διασφαλιστεί εάν το σύστημα λειτουργεί καλά σε οποιοδήποτε από τα σενάρια καλύπτεται σε αυτόν τον έλεγχο.
• Επιβεβαιώνει ότι η είσοδος που παρέχεται στο σύστημα παρέχει το αναμενόμενο αποτέλεσμα.
• Επαληθεύει εάν έχουν δοκιμαστεί όλες οι λειτουργικές και μη λειτουργικές απαιτήσεις και εάν λειτουργούν όπως αναμένεται ή όχι.
• Σ 'αυτό και διερευνητικές δοκιμές μπορούν να πραγματοποιηθούν σε αυτήν τη δοκιμή μετά την ολοκλήρωση των δοκιμών με σενάριο. Διερευνητικές δοκιμές και οι δοκιμές ad-hoc βοηθούν να ξεδιπλωθούν τα σφάλματα που δεν μπορούν να βρεθούν σε δοκιμές με σενάριο, καθώς δίνει την ελευθερία στους δοκιμαστές να δοκιμάσουν, καθώς η επιθυμία τους βασίζεται στην εμπειρία και τη διαίσθησή τους.

Πλεονεκτήματα

Υπάρχουν πολλά πλεονεκτήματα:

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

Κριτήρια εισόδου / εξόδου

Ας ρίξουμε μια λεπτομερή ματιά στα κριτήρια εισόδου / εξόδου για τη δοκιμή συστήματος.

Κριτήρια εισόδου:

• Το σύστημα θα έπρεπε να έχει περάσει τα κριτήρια εξόδου της δοκιμής ενοποίησης, δηλαδή όλες οι δοκιμαστικές περιπτώσεις θα έπρεπε να είχαν εκτελεστεί και δεν θα πρέπει να υπάρχει κρίσιμο σφάλμα ή προτεραιότητα P1, σφάλμα P2 σε ανοιχτή κατάσταση.
• Σχέδιο δοκιμής για αυτόν τον έλεγχο θα πρέπει να εγκριθεί και να αποσυνδεθεί.
• Οι δοκιμαστικές περιπτώσεις / σενάρια πρέπει να είναι έτοιμες για εκτέλεση.
• Τα σενάρια δοκιμής πρέπει να είναι έτοιμα για εκτέλεση.
• Όλες οι μη λειτουργικές απαιτήσεις θα πρέπει να είναι διαθέσιμες και θα πρέπει να έχουν δημιουργηθεί περιπτώσεις δοκιμής για το ίδιο.
• Το περιβάλλον δοκιμών πρέπει να είναι έτοιμο.

Κριτήρια εξόδου:

• Όλες οι δοκιμαστικές περιπτώσεις πρέπει να εκτελεστούν.
• Κανένα κρίσιμο σφάλμα ή Προβλήματα που σχετίζονται με την ασφάλεια δεν πρέπει να βρίσκονται σε ανοιχτή κατάσταση.
• Εάν κάποια σφάλματα μέσης ή χαμηλής προτεραιότητας βρίσκονται σε ανοιχτή κατάσταση, τότε θα πρέπει να εφαρμοστεί με την αποδοχή του πελάτη.
• Η έκθεση εξόδου πρέπει να υποβληθεί.

Σχέδιο δοκιμής συστήματος

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

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

Το Σχέδιο δοκιμής συστήματος καλύπτει τα ακόλουθα σημεία:

• Ο σκοπός και ο στόχος ορίζονται για αυτό το τεστ.
• Πεδίο εφαρμογής (Λειτουργίες προς δοκιμή, Λειτουργίες που δεν θα δοκιμαστούν παρατίθενται).
• Κριτήρια αποδοχής δοκιμής (Κριτήρια επί των οποίων θα γίνει αποδεκτό το σύστημα, δηλαδή τα αναφερόμενα σημεία στα κριτήρια αποδοχής θα πρέπει να βρίσκονται σε κατάσταση επιτυχίας).
• Κριτήρια εισόδου / εξόδου (Καθορίζει τα κριτήρια πότε πρέπει να ξεκινήσει η δοκιμή συστήματος και πότε πρέπει να θεωρηθεί πλήρης).
• Πρόγραμμα δοκιμών (Εκτίμηση της δοκιμής που θα ολοκληρωθεί σε συγκεκριμένη ώρα).
• Στρατηγική δοκιμής (Περιλαμβάνει τεχνικές δοκιμών).
• Πόροι (Αριθμός πόρων που απαιτούνται για τη δοκιμή, τους ρόλους τους, τη διαθεσιμότητα πόρων κ.λπ.).
• Δοκιμή περιβάλλοντος (λειτουργικό σύστημα, πρόγραμμα περιήγησης, πλατφόρμα).
• Θήκες δοκιμής (Κατάλογος δοκιμαστικών περιπτώσεων προς εκτέλεση).
• Υποθέσεις (Εάν υπάρχουν παραδοχές, θα πρέπει να περιληφθούν στο Σχέδιο Δοκιμών).

Διαδικασία για την εγγραφή περιπτώσεων δοκιμής συστήματος

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

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

• Αναγνωριστικό περίπτωσης δοκιμής
• Όνομα δοκιμαστικής σουίτας
• Περιγραφή - Περιγράφει τη δοκιμαστική υπόθεση που θα εκτελεστεί.
• Βήματα - Βήμα προς βήμα διαδικασία για να περιγράψετε τον τρόπο εκτέλεσης των δοκιμών.
• Δεδομένα δοκιμής - Τα εικονικά δεδομένα προετοιμάζονται για τη δοκιμή της εφαρμογής.
• Αναμενόμενο αποτέλεσμα - Το αναμενόμενο αποτέλεσμα σύμφωνα με το έγγραφο απαίτησης παρέχεται σε αυτήν τη στήλη.
• Πραγματικό αποτέλεσμα - Αποτέλεσμα μετά την εκτέλεση της δοκιμαστικής υπόθεσης παρέχεται σε αυτήν τη στήλη.
• Pass / Fail - Η σύγκριση στο πραγματικό & αναμενόμενο αποτέλεσμα καθορίζει τα κριτήρια Pass / Fail.
• Παρατηρήσεις

Θήκες δοκιμής συστήματος

Ακολουθούν ορισμένα δείγματα σεναρίων δοκιμών για έναν ιστότοπο ηλεκτρονικού εμπορίου:

1. Εάν ο ιστότοπος ξεκινά σωστά με όλες τις σχετικές σελίδες, τα χαρακτηριστικά και το λογότυπο
2. Εάν ο χρήστης μπορεί να εγγραφεί / συνδεθεί στον ιστότοπο
3. Εάν ο χρήστης μπορεί να δει τα διαθέσιμα προϊόντα, μπορεί να προσθέσει προϊόντα στο καλάθι του μπορεί να κάνει πληρωμή και να λάβει την επιβεβαίωση μέσω e-mail ή SMS ή κλήσης.
4. Εάν η κύρια λειτουργικότητα όπως αναζήτηση, φιλτράρισμα, ταξινόμηση, προσθήκη, αλλαγή, λίστα επιθυμιών κ.λπ. λειτουργεί όπως αναμένεται
5. Εάν ο αριθμός των χρηστών (όπως ορίζεται στο έγγραφο απαίτησης) μπορεί να έχει πρόσβαση στον ιστότοπο ταυτόχρονα
6. Εάν ο ιστότοπος ξεκινά σωστά σε όλα τα μεγάλα προγράμματα περιήγησης και τις τελευταίες εκδόσεις τους
7. Εάν οι συναλλαγές γίνονται στον ιστότοπο μέσω συγκεκριμένου χρήστη, είναι αρκετά ασφαλείς
8. Εάν ο ιστότοπος ξεκινά σωστά σε όλες τις υποστηριζόμενες πλατφόρμες, όπως Windows, Linux, Mobile κ.λπ.
9. Εάν το εγχειρίδιο χρήσης / πολιτική επιστροφής οδηγού, η πολιτική απορρήτου και οι όροι χρήσης του ιστότοπου είναι διαθέσιμα ως ξεχωριστό έγγραφο και χρήσιμο για κάθε αρχάριο ή για πρώτη φορά χρήστη.
10. Εάν το περιεχόμενο των σελίδων είναι σωστά ευθυγραμμισμένο, καλή διαχείριση και χωρίς ορθογραφικά λάθη.
11. Εάν το χρονικό όριο περιόδου λειτουργίας εφαρμόζεται και λειτουργεί όπως αναμένεται
12. Εάν ένας χρήστης είναι ικανοποιημένος μετά τη χρήση του ιστότοπου ή με άλλα λόγια ο χρήστης δεν δυσκολεύεται να χρησιμοποιήσει τον ιστότοπο.

Τύποι δοκιμών συστήματος

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

Το συνολικό μπορεί να οριστεί ως εξής:

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

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

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

Δοκιμή απόδοσης: Για να βεβαιωθείτε ότι η απόδοση του συστήματος υπό τις διάφορες συνθήκες, όσον αφορά τα χαρακτηριστικά απόδοσης.

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

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

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

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

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

Δοκιμή χρηστικότητας : Για να βεβαιωθείτε ότι το σύστημα είναι εύκολο στη χρήση, μάθετε και λειτουργήστε.

Περισσότεροι τύποι δοκιμών συστήματος

# 1) Δοκιμή γραφικών διεπαφών χρήστη (GUI):

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

# 2) Δοκιμή συμβατότητας:

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

# 3) Χειρισμός εξαίρεσης:

Ο Έλεγχος Εξαίρεσης χειρισμού εκτελείται για να επαληθευτεί ότι ακόμη και αν προκύψει μη αναμενόμενο σφάλμα στο προϊόν, θα πρέπει να εμφανίζει το σωστό μήνυμα σφάλματος και να μην αφήσει την εφαρμογή να σταματήσει. Αντιμετωπίζει την εξαίρεση με τρόπο που εμφανίζεται το σφάλμα εν τω μεταξύ το προϊόν ανακτά και επιτρέπει στο σύστημα να επεξεργαστεί την εσφαλμένη συναλλαγή.

# 4) Έλεγχος έντασης:

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

# 5) Δοκιμή στρες:

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

# 6) Δοκιμή υγιεινής:

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

Σε περίπτωση που παρουσιαστεί οποιοδήποτε ζήτημα, τότε η έκδοση δεν γίνεται αποδεκτή για περαιτέρω δοκιμές.

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

# 7) Δοκιμή καπνού:

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

# 8) Διερευνητικές δοκιμές:

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

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

# 9) Δοκιμή Adhoc:

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

# 10) Δοκιμή εγκατάστασης:

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

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

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

• Κακή ταχύτητα δικτύου και διακοπή σύνδεσης.
• Τείχος προστασίας και ασφάλεια.
• Λαμβάνονται το μέγεθος και ο χρόνος κατά προσέγγιση.
• Ταυτόχρονη εγκατάσταση / λήψεις.
• Ελλειπης ΜΝΗΜΗ
• Ανεπαρκής χώρος
• Ματαιωμένη εγκατάσταση

# 11) Δοκιμή συντήρησης:

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

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

Τι είναι ο έλεγχος ολοκλήρωσης συστήματος;

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

Παράδειγμα δοκιμής ενοποίησης συστήματος:

Ας πάρουμε το παράδειγμα ενός γνωστού ιστότοπου κρατήσεων εισιτηρίων στο διαδίκτυο - http://irctc.co.in.

Αυτή είναι μια δυνατότητα κράτησης εισιτηρίων. μια διαδικτυακή εγκατάσταση αγορών αλληλεπιδρά με το PayPal. Συνολικά μπορείτε να το θεωρήσετε ως A * B * C = R.

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

Λοιπόν, πού έρχονται οι δοκιμές ολοκλήρωσης συστήματος στην εικόνα;

Η διαδικτυακή πύλη http://Irctc.co.in είναι ένας συνδυασμός συστημάτων. Μπορείτε να εκτελέσετε δοκιμές στο ίδιο επίπεδο (μεμονωμένο σύστημα, σύστημα συστημάτων), αλλά σε κάθε επίπεδο, μπορεί να θέλετε να εστιάσετε σε διαφορετικούς κινδύνους (προβλήματα ενσωμάτωσης, ανεξάρτητη λειτουργικότητα).

• Κατά τη δοκιμή της δυνατότητας κράτησης εισιτηρίων στο Διαδίκτυο, μπορείτε να επαληθεύσετε εάν μπορείτε να κάνετε κράτηση εισιτηρίων στο διαδίκτυο. Μπορείτε επίσης να εξετάσετε προβλήματα ενσωμάτωσης Για παράδειγμα, Η δυνατότητα κράτησης εισιτηρίων ενσωματώνει back-end με front-end (UI). Για παράδειγμα, πώς συμπεριφέρεται το front-end όταν ο διακομιστής βάσης δεδομένων είναι αργός να ανταποκριθεί;
• Δοκιμή διαδικτυακής δυνατότητας κράτησης εισιτηρίων με διαδικτυακή εγκατάσταση αγορών. Μπορείτε να επαληθεύσετε ότι η ηλεκτρονική εγκατάσταση αγορών είναι διαθέσιμη για τους χρήστες που έχουν συνδεθεί στο σύστημα για να κάνουν κράτηση εισιτηρίων online. Μπορείτε επίσης να εξετάσετε την επαλήθευση της ενσωμάτωσης στο διαδικτυακό κατάστημα αγορών. Για παράδειγμα, εάν ο χρήστης μπορεί να επιλέξει και να αγοράσει ένα προϊόν χωρίς ταλαιπωρία.
• Δοκιμή της ενσωμάτωσης της ηλεκτρονικής δυνατότητας κράτησης εισιτηρίων με το PayPal. Μπορείτε να επαληθεύσετε εάν, μετά την κράτηση εισιτηρίων, τα χρήματα μεταφέρθηκαν από τον λογαριασμό σας στο PayPal στον λογαριασμό Online Κρατήσεων Εισιτηρίων. Μπορείτε επίσης να εξετάσετε την επαλήθευση της ενσωμάτωσης στο PayPal. Για παράδειγμα, Τι γίνεται αν το σύστημα βάζει δύο καταχωρίσεις σε μια βάση δεδομένων μετά τη χρέωση χρημάτων μόνο για μία φορά;

Διαφοράμεταξύ δοκιμής συστήματος και δοκιμής ολοκλήρωσης συστήματος:

Η κύρια διαφορά είναι:

• Η δοκιμή συστήματος φροντίζει την ακεραιότητα ενός συστήματος με το σχετικό περιβάλλον
• Το System Integration Testing φροντίζει την ακεραιότητα πολλών συστημάτων μεταξύ τους, στο ίδιο περιβάλλον.

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

Διαφορά μεταξύ δοκιμής συστήματος και αποδοχής

Παρακάτω αναφέρονται οι κύριες διαφορές:

Συμβουλές για την εκτέλεση της δοκιμής συστήματος

1. Αντιγράψτε σενάρια σε πραγματικό χρόνο αντί να κάνετε ιδανικές δοκιμές, καθώς το σύστημα πρόκειται να χρησιμοποιηθεί από έναν τελικό χρήστη και όχι από τον εκπαιδευμένο ελεγκτή.
2. Επαληθεύστε την απόκριση του συστήματος με διάφορους όρους, καθώς ο άνθρωπος δεν θέλει να περιμένει ή να δει λάθος δεδομένα.
3. Εγκαταστήστε και διαμορφώστε το σύστημα σύμφωνα με την τεκμηρίωση, γιατί αυτό θα κάνει ο τελικός χρήστης.
4. Η συμμετοχή ατόμων από διαφορετικούς τομείς, όπως αναλυτές επιχειρήσεων, προγραμματιστές, δοκιμαστές, πελάτες μπορούν να στείλουν ένα καλύτερο σύστημα.
5. Ο τακτικός έλεγχος είναι ο μόνος τρόπος για να βεβαιωθείτε ότι η μικρότερη αλλαγή στον κώδικα για να διορθώσετε το σφάλμα δεν έχει εισαγάγει άλλο κρίσιμο σφάλμα στο σύστημα.

συμπέρασμα

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

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

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

Ελπίζω ότι αυτό το σεμινάριο ήταν πολύ χρήσιμο για την κατανόηση της έννοιας του System Testing.

Συνιστώμενη ανάγνωση

• Τύποι δοκιμών λογισμικού: Διαφορετικοί τύποι δοκιμών με λεπτομέρειες
• Δοκιμή άλφα και δοκιμή beta (Ένας πλήρης οδηγός)
• Τι είναι ο έλεγχος ενοποίησης συστήματος (SIT): Μάθετε με παραδείγματα
• Λειτουργική δοκιμή εναντίον μη λειτουργική δοκιμή
• Διαδικασία συνεχούς ενοποίησης: Πώς να βελτιώσετε την ποιότητα του λογισμικού και να μειώσετε τον κίνδυνο
• Κορυφαία 10 εργαλεία δοκιμών ενοποίησης για τη σύνταξη δοκιμών ενοποίησης
• Τι είναι ο Έλεγχος Ενσωμάτωσης (Tutorial with Integration Test παράδειγμα)
• Τι είναι η δοκιμή αντοχής στη δοκιμή λογισμικού (παραδείγματα)