complete functional testing guide with its types
Ένα Εκπαιδευτικό Εκπαιδευτικό Εκπαιδευτικό Τεστ με Τύπους, Τεχνικές και Παραδείγματα:
Τι είναι η λειτουργική δοκιμή;
Η λειτουργική δοκιμή είναι ένα είδος δοκιμής μαύρου κουτιού που εκτελείται για να επιβεβαιώσει ότι η λειτουργικότητα μιας εφαρμογής ή συστήματος συμπεριφέρεται όπως αναμένεται.
Γίνεται για την επαλήθευση όλων των λειτουργιών μιας εφαρμογής.
ΚΑΤΑΛΟΓΟΣ των Σεμιναρίων που καλύπτονται σε αυτήν τη σειρά:
Εκμάθηση # 1: Τι είναι η λειτουργική δοκιμή (αυτό το σεμινάριο)
Εκμάθηση # 2: Ερωτήσεις συνέντευξης δοκιμής λειτουργικότητας
Εκμάθηση # 3: Κορυφαία λειτουργικά εργαλεία δοκιμής αυτοματισμού
Εκμάθηση # 4: Τι είναι η μη λειτουργική δοκιμή;
Εκμάθηση # 5: Διαφορά μεταξύ μονάδας, λειτουργικού και Ενσωμάτωση Δοκιμές
Εκμάθηση # 6 : Γιατί πρέπει να γίνει ταυτόχρονα η λειτουργία και η δοκιμή απόδοσης
Εργαλεία:
Εκμάθηση # 7: Λειτουργική δοκιμαστική αυτοματοποίηση με το Ranorex Studio
Εκμάθηση # 8: Νέες δυνατότητες λειτουργικού εργαλείου UFT
Εκμάθηση # 9: Λειτουργική αυτοματοποίηση Cross Browser χρησιμοποιώντας το Parrot QA Tool
Εκμάθηση # 10: Εκπαιδευτικό εργαλείο ανοιχτού κώδικα Jubula για δοκιμή λειτουργικότητας
Τι θα μάθετε:
- Εισαγωγή στη λειτουργική δοκιμή
Εισαγωγή στη λειτουργική δοκιμή
Πρέπει να υπάρχει κάτι που να καθορίζει τι είναι αποδεκτή συμπεριφορά και τι όχι.
Αυτό καθορίζεται σε μια λειτουργική ή προδιαγραφή απαίτησης. Είναι ένα έγγραφο που περιγράφει τι επιτρέπεται σε έναν χρήστη να το κάνει, ώστε να μπορεί να προσδιορίσει τη συμμόρφωση της εφαρμογής ή του συστήματος προς αυτήν. Επιπλέον, μερικές φορές αυτό θα μπορούσε επίσης να συνεπάγεται την επικύρωση των πραγματικών επιχειρηματικών σεναρίων.
Επομένως, ο έλεγχος λειτουργικότητας μπορεί να πραγματοποιηθεί μέσω δύο δημοφιλείς τεχνικές :
- Δοκιμή με βάση τις απαιτήσεις: Περιέχει όλες τις λειτουργικές προδιαγραφές που αποτελούν τη βάση για όλες τις δοκιμές που πρέπει να διεξαχθούν.
- Δοκιμή βάσει επιχειρηματικών σεναρίων: Περιέχει τις πληροφορίες σχετικά με το πώς το σύστημα θα γίνει αντιληπτό από μια προοπτική επιχειρηματικής διαδικασίας.
Οι δοκιμές και η διασφάλιση ποιότητας αποτελούν τεράστιο μέρος της διαδικασίας SDLC. Ως υπεύθυνος δοκιμών, πρέπει να είμαστε ενήμεροι για όλους τους τύπους δοκιμών, ακόμη και αν δεν ασχολούμαστε άμεσα μαζί τους καθημερινά.
Δεδομένου ότι οι δοκιμές είναι ωκεανός, το πεδίο εφαρμογής του είναι πράγματι τόσο μεγάλο, και έχουμε αφοσιωμένους δοκιμαστές που εκτελούν διαφορετικά είδη δοκιμών . Πιθανότατα όλοι μας πρέπει να είμαστε εξοικειωμένοι με τις περισσότερες από τις έννοιες, αλλά δεν θα βλάψει να τα οργανώσουμε όλα εδώ.
Λειτουργικοί τύποι δοκιμών
Η λειτουργική δοκιμή έχει πολλές κατηγορίες και αυτές μπορούν να χρησιμοποιηθούν με βάση το σενάριο.
Οι πιο εμφανείς τύποι συζητούνται εν συντομία παρακάτω:
Ο έλεγχος μονάδας πραγματοποιείται συνήθως από έναν προγραμματιστή που γράφει διαφορετικές μονάδες κώδικα που θα μπορούσαν να σχετίζονται ή να μην σχετίζονται με την επίτευξη μιας συγκεκριμένης λειτουργικότητας. Αυτό, συνήθως συνεπάγεται δοκιμές μονάδας γραφής που θα καλούσαν τις μεθόδους σε κάθε μονάδα και θα επικυρώσουν αυτές όταν περάσουν οι απαιτούμενες παράμετροι και η τιμή επιστροφής της είναι όπως αναμενόταν.
Η κάλυψη κώδικα είναι ένα σημαντικό μέρος της δοκιμής μονάδας όπου πρέπει να υπάρχουν οι δοκιμαστικές περιπτώσεις για να καλύψουν τα παρακάτω τρία:
i) Κάλυψη γραμμής
ii) Κάλυψη διαδρομής κώδικα
iii) Κάλυψη μεθόδου
Δοκιμή υγιεινής : Δοκιμή που γίνεται για να διασφαλιστεί ότι όλες οι βασικές και ζωτικές λειτουργίες της εφαρμογής / συστήματος λειτουργούν σωστά. Αυτό γίνεται γενικά μετά από μια δοκιμή καπνού.
Δοκιμή καπνού : Δοκιμές που γίνονται μετά από κάθε έκδοση απελευθερώνεται για να ελεγχθεί για να εξασφαλιστεί η σταθερότητα της κατασκευής. Ονομάζεται επίσης ως δοκιμή επαλήθευσης έκδοσης.
Δοκιμές παλινδρόμησης : Ο έλεγχος πραγματοποιήθηκε για να διασφαλιστεί ότι η προσθήκη νέου κώδικα, βελτιώσεων, διόρθωσης σφαλμάτων δεν σπάει την υπάρχουσα λειτουργικότητα ή προκαλεί αστάθεια και εξακολουθεί να λειτουργεί σύμφωνα με τις προδιαγραφές.
Οι δοκιμές παλινδρόμησης δεν πρέπει να είναι τόσο εκτεταμένες όσο οι πραγματικές λειτουργικές δοκιμές, αλλά πρέπει να διασφαλίζουν μόνο το μέγεθος της κάλυψης για να πιστοποιηθεί ότι η λειτουργικότητα είναι σταθερή.
Δοκιμές ολοκλήρωσης : Όταν το σύστημα βασίζεται σε πολλαπλές λειτουργικές μονάδες που μπορεί να λειτουργούν μεμονωμένα τέλεια, αλλά πρέπει να λειτουργούν με συνέπεια όταν συνδυάζονται μαζί για να επιτύχουν ένα σενάριο από άκρο σε άκρο, η επικύρωση τέτοιων σεναρίων ονομάζεται Δοκιμή ολοκλήρωσης.
Δοκιμή beta / χρηστικότητας : Το προϊόν εκτίθεται στον πραγματικό πελάτη σε μια παραγωγή σαν περιβάλλον και δοκιμάζει το προϊόν. Η άνεση του χρήστη προκύπτει από αυτό και τα σχόλια λαμβάνονται. Αυτό είναι παρόμοιο με αυτό της δοκιμής αποδοχής χρήστη.
Ας το παρουσιάσουμε σε ένα εύκολο διάγραμμα ροής:
Δοκιμή λειτουργικού συστήματος:
Δοκιμή συστήματος είναι μια δοκιμή που εκτελείται σε ένα πλήρες σύστημα για να επαληθεύσει εάν λειτουργεί όπως αναμένεται μόλις ενσωματωθούν όλες οι ενότητες ή τα στοιχεία.
Δοκιμή από άκρο σε άκρο εκτελείται για την επαλήθευση της λειτουργικότητας του προϊόντος. Αυτός ο έλεγχος πραγματοποιείται μόνο όταν ολοκληρωθεί ο έλεγχος ολοκλήρωσης συστήματος, συμπεριλαμβανομένων τόσο των λειτουργικών όσο και των μη λειτουργικών απαιτήσεων.
=> Διαφορά μεταξύ μονάδας, λειτουργικότητας και δοκιμής ολοκλήρωσης
Επεξεργάζομαι, διαδικασία
Αυτή η διαδικασία δοκιμής έχει τρία κύρια βήματα:
Προσέγγιση, τεχνικές και παραδείγματα
Η λειτουργική ή συμπεριφορική δοκιμή παράγει μια έξοδο με βάση τις δεδομένες εισόδους και καθορίζει εάν το Σύστημα λειτουργεί σωστά σύμφωνα με τις προδιαγραφές.
Ως εκ τούτου, η εικονική αναπαράσταση θα φαίνεται όπως φαίνεται παρακάτω:
Κριτήρια εισόδου / εξόδου
Κριτήρια εισόδου:
- Το έγγραφο προδιαγραφής απαιτήσεων ορίζεται και εγκρίνεται.
- Έχουν προετοιμαστεί δοκιμαστικές περιπτώσεις.
- Τα δεδομένα δοκιμής έχουν δημιουργηθεί.
- Το περιβάλλον για δοκιμές είναι έτοιμο, όλα τα εργαλεία που απαιτούνται είναι διαθέσιμα και έτοιμα.
- Η πλήρης ή μερική εφαρμογή αναπτύσσεται και ελέγχεται η μονάδα και είναι έτοιμη για δοκιμή.
Κριτήρια εξόδου:
- Η εκτέλεση όλων των λειτουργικών περιπτώσεων δοκιμής έχει ολοκληρωθεί.
- Δεν υπάρχουν κρίσιμα σφάλματα ή σφάλματα P1, P2.
- Αναφέρθηκαν σφάλματα που έχουν αναφερθεί.
Συμμετέχοντα βήματα
Τα διάφορα βήματα που εμπλέκονται σε αυτήν τη δοκιμή αναφέρονται παρακάτω:
- Το πρώτο πρώτο βήμα είναι ο προσδιορισμός της λειτουργικότητας του προϊόντος που πρέπει να δοκιμαστεί και περιλαμβάνει τον έλεγχο των κύριων λειτουργιών, της κατάστασης σφάλματος και των μηνυμάτων, δοκιμή χρηστικότητας, δηλαδή αν το προϊόν είναι φιλικό προς το χρήστη ή όχι κ.λπ.
- Το επόμενο βήμα είναι να δημιουργήσετε τα δεδομένα εισόδου για τη λειτουργικότητα που θα δοκιμαστεί σύμφωνα με τις προδιαγραφές των απαιτήσεων.
- Αργότερα, από την προδιαγραφή απαίτησης, η έξοδος καθορίζεται για τη λειτουργικότητα υπό δοκιμή.
- Εκτελούνται δοκιμαστικές περιπτώσεις.
- Η πραγματική έξοδος, δηλαδή η έξοδος μετά την εκτέλεση της δοκιμαστικής θήκης και η αναμενόμενη έξοδος (καθορίζεται από τις προδιαγραφές απαιτήσεων) συγκρίνονται για να διαπιστωθεί εάν η λειτουργικότητα λειτουργεί όπως αναμένεται ή όχι.
Πλησιάζω
Διαφορετικά είδη σεναρίων μπορούν να μελετηθούν και να δημιουργηθούν με τη μορφή «δοκιμαστικών περιπτώσεων». Ως άτομα της QA, όλοι γνωρίζουμε πώς φαίνεται ο σκελετός μιας δοκιμαστικής θήκης.
Έχει ως επί το πλείστον τέσσερα μέρη:
- Περίληψη δοκιμής
- Προαπαιτούμενα
- Βήματα δοκιμής και
- Αναμενόμενα αποτελέσματα.
Η προσπάθεια συγγραφής κάθε είδους δοκιμής δεν είναι μόνο αδύνατη, αλλά και χρονοβόρα και δαπανηρή.
Συνήθως, θα θέλαμε να αποκαλύψουμε τα μέγιστα σφάλματα χωρίς διαφυγές με υπάρχουσες δοκιμές. Επομένως, το QA πρέπει να χρησιμοποιήσει τεχνικές βελτιστοποίησης και να στρατηγικοποιήσει τον τρόπο με τον οποίο θα πλησίαζαν τη δοκιμή.
Ας το εξηγήσουμε με ένα παράδειγμα.
Παραδείγματα λειτουργικών δοκιμών χρήσης:
Πάρτε μια διαδικτυακή πύλη HRMS όπου ο υπάλληλος συνδέεται με τον λογαριασμό χρήστη και τον κωδικό πρόσβασης. Στη σελίδα σύνδεσης, υπάρχουν δύο πεδία κειμένου για το όνομα χρήστη και τον κωδικό πρόσβασης και δύο κουμπιά: Σύνδεση και Ακύρωση. Η επιτυχής σύνδεση οδηγεί τον χρήστη στην αρχική σελίδα του HRMS και η ακύρωση θα ακυρώσει τη σύνδεση.
Οι προδιαγραφές είναι όπως φαίνεται παρακάτω:
# 1) Το πεδίο αναγνωριστικού χρήστη διαρκεί τουλάχιστον 6 χαρακτήρες, το πολύ 10 χαρακτήρες, αριθμούς (0-9), γράμματα (a-z, A-z), ειδικούς χαρακτήρες (επιτρέπεται μόνο υπογράμμιση, τελεία, παύλα) και δεν μπορεί να παραμείνει κενό. Το αναγνωριστικό χρήστη πρέπει να ξεκινά με έναν χαρακτήρα ή έναν αριθμό και όχι με ειδικούς χαρακτήρες.
#δύο) Το πεδίο κωδικού πρόσβασης διαρκεί τουλάχιστον 6 χαρακτήρες, το πολύ 8 χαρακτήρες, αριθμούς (0-9), γράμματα (a-z, A-Z), ειδικούς χαρακτήρες (όλοι) και δεν μπορεί να είναι κενό.
Η βασική προσέγγιση για τη δοκιμή αυτού του σεναρίου μπορεί να ταξινομηθεί σε δύο ευρείες κατηγορίες:
- Θετικές δοκιμές και
- Αρνητικές δοκιμές
Φυσικά, κάθε μία από αυτές τις κατηγορίες έχει την υποενότητα δοκιμών που θα πραγματοποιηθούν.
Θετικές δοκιμές είναι ευτυχείς δοκιμές διαδρομής που γίνονται για να διασφαλιστεί ότι το προϊόν πληροί - τουλάχιστον τις βασικές απαιτήσεις που είναι ζωτικής σημασίας για τη χρήση των πελατών.
Αρνητικά σενάρια βεβαιωθείτε ότι το προϊόν συμπεριφέρεται σωστά ακόμα και όταν υποβάλλεται σε απροσδόκητα δεδομένα.
Προτεινόμενη ανάγνωση => Τι είναι ο αρνητικός έλεγχος και πώς να γράφετε αρνητικές δοκιμές
Τώρα, επιτρέψτε μου να δομήσω τις τεχνικές δοκιμής χρησιμοποιώντας ένα διάγραμμα ροής παρακάτω. Θα αναφερθούμε στις λεπτομέρειες κάθε μιας από αυτές τις δοκιμές.
Λειτουργικές τεχνικές δοκιμών
# 1) Δοκιμές συστήματος / τελικού χρήστη
Το υπό δοκιμή σύστημα μπορεί να έχει πολλά στοιχεία τα οποία όταν συνδυάζονται μαζί επιτυγχάνουν το σενάριο χρήστη.
Στο Παράδειγμα , ένα σενάριο πελάτη θα περιλαμβάνει εργασίες όπως φόρτωση εφαρμογής HRMS, εισαγωγή σωστών διαπιστευτηρίων, μετάβαση στην αρχική σελίδα, εκτέλεση ορισμένων ενεργειών και αποσύνδεση από το σύστημα. Αυτή η συγκεκριμένη ροή πρέπει να λειτουργεί χωρίς σφάλματα για ένα βασικό επιχειρηματικό σενάριο.
δωρεάν εφαρμογή ρολογιού χρόνου για υπολογιστή
Μερικά δείγματα δίνονται παρακάτω:
Sl Όχι | Περίληψη | Προαπαιτούμενο | Θήκη δοκιμής | Αναμενόμενα αποτελέσματα. |
---|---|---|---|---|
1. | Ο πλήρως προνομιούχος χρήστης μπορεί να κάνει αλλαγές λογαριασμού | 1) Ο λογαριασμός χρήστη πρέπει να υπάρχει 2) Ο χρήστης πρέπει να έχει τα απαιτούμενα δικαιώματα | 1) Ο χρήστης εισάγει το userid και τον κωδικό πρόσβασης 2) Ο χρήστης βλέπει δικαιώματα επεξεργασίας για την τροποποίηση του ίδιου του λογαριασμού 3) Ο χρήστης τροποποιεί τις πληροφορίες λογαριασμού και αποθηκεύει. 4) Ο χρήστης αποσυνδέεται. | 1) Ο χρήστης συνδέεται στην αρχική σελίδα 2) Η οθόνη επεξεργασίας εμφανίζεται στον χρήστη. 3) Οι πληροφορίες λογαριασμού αποθηκεύονται 4) Ο χρήστης επιστρέφει στη σελίδα σύνδεσης |
2. | Ένας άλλος έγκυρος χρήστης χωρίς πλήρη προνόμια | 1) Ο λογαριασμός χρήστη πρέπει να υπάρχει 2) Ο χρήστης πρέπει να έχει τα ελάχιστα δικαιώματα | 1) Ο χρήστης εισάγει το userid και τον κωδικό πρόσβασης 2) Ο χρήστης βλέπει δικαιώματα επεξεργασίας για τροποποίηση μόνο συγκεκριμένων πεδίων. 3) Ο χρήστης τροποποιεί μόνο αυτά τα πεδία και αποθηκεύει. 4) Ο χρήστης αποσυνδέεται. | 1) Ο χρήστης συνδέεται στην αρχική σελίδα 2) Η οθόνη επεξεργασίας εμφανίζεται στον χρήστη μόνο σε συγκεκριμένα πεδία. Τα πεδία λογαριασμού είναι γκριζαρισμένα. 3) Τα τροποποιημένα πεδία αποθηκεύονται 4) Ο χρήστης επιστρέφει στη σελίδα σύνδεσης |
Αυτό είναι ένα βασικό παράδειγμα για τον τρόπο σύνταξης των δοκιμαστικών περιπτώσεων για καταστάσεις. Η παραπάνω μορφή θα ισχύει και για όλες τις παρακάτω δοκιμές. Για λόγους ισχυρής εννοιολογικής γείωσης, έχω υποβάλει μόνο μερικές απλές δοκιμές πάνω και κάτω.
# 2) Δοκιμές ισοδυναμίας
Σε Διαχωρισμός ισοδυναμίας , τα δεδομένα δοκιμής διαχωρίζονται σε διάφορα διαμερίσματα που ονομάζονται κλάσεις δεδομένων ισοδυναμίας. Τα δεδομένα σε κάθε διαμέρισμα πρέπει να συμπεριφέρονται με τον ίδιο τρόπο, επομένως πρέπει να ελεγχθεί μόνο μία συνθήκη. Ομοίως, εάν μια συνθήκη σε ένα διαμέρισμα δεν λειτουργεί, τότε καμία από τις άλλες δεν θα λειτουργήσει.
Για παράδειγμα , στο παραπάνω σενάριο, το πεδίο αναγνωριστικού χρήστη μπορεί να έχει έως και 10 χαρακτήρες, επομένως η εισαγωγή δεδομένων> 10 θα πρέπει να συμπεριφέρεται με τον ίδιο τρόπο.
# 3) Δοκιμές οριακής αξίας
Οι οριακές δοκιμές συνεπάγονται όρια δεδομένων στην εφαρμογή και επικυρώνουν τον τρόπο συμπεριφοράς της.
Επομένως, εάν οι είσοδοι παρέχονται πέρα από τις οριακές τιμές, τότε θεωρείται αρνητικός έλεγχος. Έτσι, τουλάχιστον 6 χαρακτήρες για τον χρήστη ορίζει το όριο ορίου. Δοκιμές γραμμένες με αναγνωριστικό χρήστη<6 characters are boundary analysis tests.
# 4) Δοκιμές βάσει αποφάσεων
Οι δοκιμές βάσει αποφάσεων επικεντρώνονται στην ιδεολογία των πιθανών αποτελεσμάτων του συστήματος όταν πληρούται μια συγκεκριμένη προϋπόθεση.
Στο παραπάνω σενάριο που δίνεται, μπορούν να προκύψουν αμέσως οι ακόλουθες δοκιμές βάσει αποφάσεων:
- Εάν εισαχθούν λανθασμένα διαπιστευτήρια, θα πρέπει να το υποδείξετε στον χρήστη και να φορτώσετε ξανά τη σελίδα σύνδεσης.
- Εάν ο χρήστης εισαγάγει τα σωστά διαπιστευτήρια, θα πρέπει να μεταφέρει τον χρήστη στην επόμενη διεπαφή χρήστη.
- Εάν ο χρήστης εισαγάγει τα σωστά διαπιστευτήρια αλλά επιθυμεί να ακυρώσει τη σύνδεση, τότε δεν θα πρέπει να μεταφέρει τον χρήστη στο επόμενο περιβάλλον χρήστη και να φορτώσει ξανά τη σελίδα σύνδεσης.
# 5) Εναλλακτικές δοκιμές ροής
Εκτελούνται δοκιμές εναλλακτικής διαδρομής για την επικύρωση όλων των πιθανών τρόπων που υπάρχουν, εκτός από την κύρια ροή για την ολοκλήρωση μιας λειτουργίας.
# 6) Δοκιμές ad-hoc
Όταν τα περισσότερα από τα σφάλματα αποκαλυφθούν μέσω των παραπάνω τεχνικών, ad-hoc δοκιμές είναι ένας πολύ καλός τρόπος για να αποκαλύψετε τυχόν αποκλίσεις που δεν παρατηρήθηκαν νωρίτερα. Αυτά εκτελούνται με τη νοοτροπία να σπάσουν το σύστημα και να δουν αν ανταποκρίνεται χαριτωμένα.
Για παράδειγμα , μια δοκιμαστική περίπτωση θα ήταν:
- Ένας χρήστης είναι συνδεδεμένος, αλλά ο διαχειριστής διαγράφει τον λογαριασμό χρήστη ενώ εκτελεί ορισμένες λειτουργίες. Θα ήταν ενδιαφέρον να δούμε πώς η εφαρμογή το χειρίζεται με χαρά.
Λειτουργική vs μη λειτουργική δοκιμή:
Μη λειτουργικές δοκιμές επικεντρωθείτε στην ποιότητα της εφαρμογής / συστήματος στο σύνολό του. Ως εκ τούτου, προσπαθεί να συμπεράνει πόσο καλά αποδίδει το σύστημα σύμφωνα με τις απαιτήσεις του πελάτη σε αντίθεση με τη λειτουργία που εκτελεί.
=> Διαβάστε την ακριβή διαφορά εδώ
Λειτουργική αυτοματοποίηση δοκιμών
Μπορούμε να αυτοματοποιήσουμε τις λειτουργικές δοκιμές;
Με τη χειροκίνητη προσπάθεια Αυτοματισμού μπορεί να μειωθεί, να εξοικονομηθεί χρόνος, να αποφευχθεί η ολίσθηση σφαλμάτων και η αποδοτικότητα να αυξηθεί.
Ωστόσο, δεν είναι δυνατό να αυτοματοποιηθούν όλα και τα πάντα. Αυτός ο έλεγχος μπορεί να αυτοματοποιηθεί, αλλά ο χρήστης πρέπει να επεξεργαστεί τις δοκιμαστικές περιπτώσεις για να γίνει ο αυτοματισμός. Είναι σημαντικό να βρείτε τις σωστές δοκιμαστικές θήκες για αυτοματοποίηση μαζί με ένα κατάλληλο εργαλείο.
Η αυτοματοποίηση λειτουργικών περιπτώσεων μπορεί να έχει μειονεκτήματα, όπως εάν ο αριθμός των δοκιμαστικών περιπτώσεων είναι πολύ περισσότερος και υποχωρεί ξανά και ξανά (κάτι που πρέπει να γίνει), τότε ο προγραμματιστής ενδέχεται να αντιμετωπίσει πρόβλημα κατά την πραγματοποίηση αλλαγών στον κώδικα.
Πολλές φορές κατά την εκτέλεση ανάλυσης διαφυγής ελαττωμάτων, η εξέχουσα και πολυετής αιτία διαφυγής φαίνεται να έχει έλλειψη δοκιμαστικής κάλυψης σε μια συγκεκριμένη λειτουργία.
Και πάλι, υπάρχουν πολλές αιτίες για να συμβεί αυτό, όπως η έλλειψη περιβάλλοντος, η έλλειψη δοκιμαστών, η παράδοση πάρα πολλών λειτουργιών, ο λιγότερος χρόνος για την κάλυψη όλων των πτυχών της δοκιμής και μερικές φορές απλά η παραβίαση.
Ενώ οι ειδικές ομάδες δοκιμών μπορεί να κάνουν λεπτομερείς δοκιμές σε κάθε σπριντ ή σε κάθε κύκλο δοκιμών, τα ελαττώματα θα υπάρχουν πάντα και θα υπάρχουν πάντα ελαττώματα που μπορεί να χαθούν. Αυτή είναι μια από τις θεμελιώδεις ανάγκες για την εφαρμογή αυτοματοποιημένου ελέγχου, έχοντας έτσι σημαντική βελτίωση στην αποτελεσματικότητα της συνολικής διαδικασίας δοκιμής και κάλυψης δοκιμαστικών περιπτώσεων.
Παρόλο που οι αυτοματοποιημένες δοκιμές δεν μπορούν ποτέ να αντικαταστήσουν τις μη αυτόματες δοκιμές, η ύπαρξη ενός ιδανικού συνδυασμού και των δύο θα αποδειχθεί ζωτικής σημασίας για την επίτευξη της επιθυμητής ποιότητας στα έργα λογισμικού.
Θέματα αυτοματισμού:
# 1) Επιλέξτε το σωστό εργαλείο αυτοματισμού : Υπάρχουν πολλά διαθέσιμα εργαλεία στην αγορά, για να επιλέξετε ένα εργαλείο αυτοματισμού είναι ένα πραγματικά τρομακτικό έργο! Ωστόσο, θα μπορούσατε να δημιουργήσετε μια λίστα απαιτήσεων, βάσει της οποίας μπορείτε να επιλέξετε ποιο εργαλείο αυτοματισμού θα χρησιμοποιήσετε.
Ορισμένες βασικές πτυχές που πρέπει να σκεφτείτε περιλαμβάνουν:
- Επιλέξτε ένα εργαλείο που θα είναι εύκολο στη χρήση από όλα τα μέλη της ομάδας QA, εάν δεν έχουν ήδη τις απαιτούμενες δεξιότητες.
- Το εργαλείο μπορεί να χρησιμοποιηθεί σε διαφορετικά περιβάλλοντα. Για Παράδειγμα : Μπορούν τα σενάρια να δημιουργηθούν σε μία πλατφόρμα λειτουργικού συστήματος και να εκτελεστούν σε άλλη; Χρειάζεστε αυτοματοποίηση CLI, αυτοματισμό διεπαφής χρήστη, αυτοματισμό εφαρμογών για κινητά ή όλα;
- Το εργαλείο πρέπει να διαθέτει όλες τις δυνατότητες που χρειάζεστε. Για Παράδειγμα : Εάν ορισμένοι δοκιμαστές δεν είναι καλά εξοικειωμένοι με μια γλώσσα δέσμης ενεργειών, το εργαλείο θα πρέπει να διαθέτει μια λειτουργία εγγραφής και αναπαραγωγής και στη συνέχεια να υποστηρίζει τη μετατροπή του εγγεγραμμένου σεναρίου στην επιθυμητή γλώσσα δέσμης ενεργειών. Ομοίως, εάν χρειάζεστε επίσης το εργαλείο για την υποστήριξη αυτοματοποιημένων δοκιμών κατασκευής, συγκεκριμένων αναφορών και καταγραφής, τότε θα πρέπει να μπορεί να το κάνει επίσης.
- Το εργαλείο πρέπει να μπορεί να υποστηρίζει την επαναχρησιμοποίηση δοκιμαστικών περιπτώσεων σε περίπτωση αλλαγών του περιβάλλοντος εργασίας χρήστη.
Εργαλεία αυτοματισμού : Υπάρχουν αρκετά εργαλεία που είναι διαθέσιμα για λειτουργικό αυτοματισμό. Το σελήνιο είναι πιθανώς ένα καυτό φαβορί, αλλά υπάρχουν και άλλα εργαλεία ανοιχτού κώδικα, όπως το Sahi, το Watir, το Robotium, το AutoIt κ.λπ.
Διάφορα εργαλεία αυτοματισμού δοκιμής είναι διαθέσιμα στην αγορά. Αλλά η επιλογή του κατάλληλου εργαλείου είναι πολύ σημαντική για τον οργανισμό. Μπορεί να εξαρτάται από την απαίτηση, την ευκολία χρήσης και το κόστος παίζει σημαντικό ρόλο εδώ.
Παρακάτω δίνονται μερικά από τα κορυφαία λειτουργικά εργαλεία δοκιμής:
- Σελήνιο
- QTP
- Τζούνιτ
- Φορτωτής
- ΣΑΠΟΥΝΙ
- TestComplete
=> Ελέγξτε αυτήν την πλήρη λίστα με κορυφαία λειτουργικά εργαλεία αυτοματισμού
#δύο) Επιλέξτε τις σωστές δοκιμαστικές θήκες για αυτοματοποίηση : Εάν θέλετε να αξιοποιήσετε στο έπακρο τον αυτοματισμό, τότε είναι ζωτικής σημασίας να είστε έξυπνοι σχετικά με το είδος των δοκιμών που επιλέγετε για αυτοματοποίηση. Εάν υπάρχουν δοκιμές που απαιτούν κάποια ρύθμιση και διαμορφώσεις ενεργοποιημένες και απενεργοποιημένες κατά τη διάρκεια της εκτέλεσης της δοκιμής, τότε αυτές είναι καλύτερα να μην αυτοματοποιηθούν.
Επομένως, μπορείτε να αυτοματοποιήσετε τις δοκιμές που:
- Πρέπει να εκτελείται επανειλημμένα.
- Εκτελέστε με διαφορετικά είδη δεδομένων.
- Μερικές δοκιμές P1, P2 απαιτούν πολλή προσπάθεια και χρόνο.
- Δοκιμές που είναι επιρρεπείς σε σφάλματα.
- Σύνολο δοκιμών που πρέπει να εκτελούνται σε διαφορετικά περιβάλλοντα, προγράμματα περιήγησης κ.λπ.
# 3) Ειδική ομάδα αυτοματισμού : Αυτό πιθανότατα παραβλέπεται στους περισσότερους οργανισμούς και η αυτοματοποίηση επιβάλλεται σε όλα τα μέλη της ομάδας QA.
Κάθε μέλος της ομάδας έχει ποικίλα επίπεδα εμπειρίας, σύνολα δεξιοτήτων, επίπεδα ενδιαφέροντος, εύρος ζώνης για υποστήριξη αυτοματισμού κ.λπ.
Σε καταστάσεις όπως αυτή, είναι καλή πρακτική να κάνετε μια ανάλυση όλων των μελών της ομάδας και να έχετε ορισμένα μέλη αφιερωμένα στην πραγματοποίηση μόνο αυτοματισμού.
Η δραστηριότητα αυτοματισμού απαιτεί χρόνο, προσπάθεια, γνώση και μια αφοσιωμένη ομάδα που θα βοηθήσει στην επίτευξη των απαιτούμενων αποτελεσμάτων αντί να υπερφορτώσει όλα τα μέλη της ομάδας τόσο με χειροκίνητο όσο και με αυτοματοποιημένο έλεγχο.
# 4) Δοκιμές βάσει δεδομένων: Οι αυτοματοποιημένες περιπτώσεις δοκιμών που απαιτούν πολλαπλά σύνολα δεδομένων πρέπει να είναι καλά γραμμένες έτσι ώστε να μπορούν να επαναχρησιμοποιηθούν. Τα δεδομένα θα μπορούσαν να γραφτούν σε πηγές, όπως κείμενο ή αρχείο ιδιοτήτων, αρχεία XML ή να διαβαστούν από μια βάση δεδομένων.
Όποια και αν είναι η πηγή δεδομένων, η δημιουργία καλά δομημένων δεδομένων αυτοματισμού καθιστά το πλαίσιο ευκολότερο στη συντήρηση και κάνει τα υπάρχοντα δοκιμαστικά σενάρια που χρησιμοποιούνται στο μέγιστο των δυνατοτήτων τους.
# 5) Οι αλλαγές στη διεπαφή χρήστη δεν πρέπει να διακόπτουν τις δοκιμές: Οι δοκιμαστικές περιπτώσεις που δημιουργείτε χρησιμοποιώντας το επιλεγμένο εργαλείο πρέπει να είναι σε θέση να αντιμετωπίσουν τις πιθανές αλλαγές διεπαφής χρήστη. Για παράδειγμα, παλαιότερες εκδόσεις του σεληνίου χρησιμοποίησαν μια τοποθεσία για τον προσδιορισμό των στοιχείων της σελίδας.
Επομένως, εάν αλλάξει το περιβάλλον εργασίας χρήστη, αυτά τα στοιχεία δεν βρίσκονταν πλέον σε αυτές τις τοποθεσίες και, με τη σειρά τους, θα οδηγήσουν στη μαζική αποτυχία των δοκιμών.
Επομένως, είναι σημαντικό να κατανοήσετε εκ των προτέρων τις αδυναμίες του εργαλείου και να συντάξετε τις δοκιμαστικές περιπτώσεις, ώστε να απαιτούνται μόνο ελάχιστες αλλαγές σε περίπτωση αλλαγών του περιβάλλοντος εργασίας χρήστη.
# 6) Συχνές δοκιμές: Μόλις ετοιμάσετε έναν βασικό δοκιμαστικό κάδο αυτοματοποίησης, σχεδιάστε να έχετε συχνότερη εκτέλεση αυτού του κάδου. Αυτό έχει αμφίδρομο πλεονέκτημα: Το ένα είναι ότι μπορείτε να βελτιώσετε το πλαίσιο αυτοματισμού και να το κάνετε πιο ανθεκτικό και το δεύτερο είναι ότι θα εντοπίσετε περισσότερα σφάλματα στη διαδικασία.
Πλεονεκτήματα
Παρακάτω αναφέρονται τα διάφορα πλεονεκτήματα του Functional Testing:
- Αυτή η δοκιμή αναπαράγει ή είναι ένα αντίγραφο του πραγματικού συστήματος, δηλαδή είναι ένα αντίγραφο αυτού του προϊόντος στο ζωντανό περιβάλλον. Η δοκιμή εστιάζεται στις προδιαγραφές σύμφωνα με τη χρήση του πελάτη, δηλαδή τις προδιαγραφές συστήματος, το λειτουργικό σύστημα, τα προγράμματα περιήγησης κ.λπ.
- Δεν λειτουργεί για οποιαδήποτε, αλλά και υποθέσεις σχετικά με τη δομή του συστήματος.
- Αυτή η δοκιμή διασφαλίζει την παροχή ενός προϊόντος υψηλής ποιότητας που πληροί τις απαιτήσεις του πελάτη και διασφαλίζει ότι ο πελάτης είναι ικανοποιημένος με τα τελικά αποτελέσματα.
- Εξασφαλίζει την παράδοση ενός προϊόντος χωρίς σφάλματα που έχει όλες τις λειτουργίες που λειτουργούν σύμφωνα με τις απαιτήσεις του πελάτη.
- Ο έλεγχος βάσει κινδύνου γίνεται για να μειωθούν οι πιθανότητες οποιουδήποτε είδους κινδύνου στο προϊόν.
Περιορισμοί
Αυτός ο έλεγχος γίνεται για να βεβαιωθείτε ότι το προϊόν λειτουργεί όπως αναμενόταν και ότι ολόκληρη η απαίτηση έχει εφαρμοστεί και ότι το προϊόν είναι ακριβώς σύμφωνα με τις απαιτήσεις του πελάτη.
Ωστόσο, δεν λαμβάνει υπόψη τους άλλους παράγοντες όπως η απόδοση του προϊόντος, δηλαδή η απόκριση, ο χρόνος απόδοσης κ.λπ., οι οποίοι είναι σημαντικοί και απαιτούνται πολύ για να γίνουν μέρος της δοκιμής πριν από την κυκλοφορία του προϊόντος.
Μειονεκτήματα
- Υπάρχουν πολλές πιθανότητες εκτέλεσης περιττών δοκιμών.
- Λογικά σφάλματα μπορεί να παραλειφθούν στο προϊόν.
- Αυτός ο έλεγχος βασίζεται στην απαίτηση, εάν σε περίπτωση που η απαίτηση δεν είναι πλήρης ή είναι περίπλοκη ή δεν είναι σαφής, η εκτέλεση αυτής της δοκιμής σε ένα τέτοιο σενάριο καθίσταται δύσκολη και μπορεί επίσης να είναι χρονοβόρα.
Ως εκ τούτου, βασικά, χρειάζονται και οι δύο αυτοί τύποι δοκιμών για ένα ποιοτικό προϊόν.
συμπέρασμα
Αυτό το σεμινάριο έχει συζητήσει διεξοδικά όλα όσα πρέπει να γνωρίζετε για τις λειτουργικές δοκιμές, απευθείας από τα βασικά.
Η λειτουργική δοκιμή είναι μία από τις σημαντικές διαδικασίες δοκιμών καθώς επαληθεύει τη λειτουργικότητα ενός προϊόντος που είναι η πιο απαιτούμενη και μάλιστα η σημαντική πτυχή οποιουδήποτε προϊόντος ή εφαρμογής.
Σχετικά με τον Συγγραφέα: Sanjay Zalavadia - ως VP της υπηρεσίας πελατών για Ζέφυρος , φέρνει πάνω από 15 χρόνια ηγετικής εμπειρίας στις Υπηρεσίες Πληροφορικής και Τεχνικής Υποστήριξης.
Ελπίζω ότι μερικές από τις τεχνικές που προτείνουμε θα είναι χρήσιμες για όλους τους αναγνώστες. Ενημερώστε μας για τις σκέψεις σας στα παρακάτω σχόλια.
Προτεινόμενη ανάγνωση => Εγχειρίδιο δοκιμών χαρακτηριστικών
Συνιστώμενη ανάγνωση
- Λειτουργική δοκιμή Vs Μη λειτουργική δοκιμή
- Δοκιμή άλφα και δοκιμή beta (ένας πλήρης οδηγός)
- Τα καλύτερα εργαλεία δοκιμής λογισμικού 2021 [QA Test Automation Tools]
- Οι διαφορές μεταξύ δοκιμών μονάδας, δοκιμής ολοκλήρωσης και δοκιμής λειτουργίας
- Τύποι δοκιμών λογισμικού: Διαφορετικοί τύποι δοκιμών με λεπτομέρειες
- Spock για ενσωμάτωση και λειτουργική δοκιμή με σελήνιο
- Πλήρης οδηγός δοκιμής επαλήθευσης έκδοσης (Δοκιμή BVT)
- Ένας πλήρης μη λειτουργικός οδηγός δοκιμών για αρχάριους