test coverage software testing
Πλήρης οδηγός κάλυψης δοκιμών δοκιμής λογισμικού: Πώς να δοκιμάσετε περισσότερα, να εξοικονομήσετε χρόνο και να επιτύχετε καλύτερα αποτελέσματα δοκιμών:
Η δοκιμή λογισμικού είναι μια ουσιαστική δραστηριότητα στους κύκλους ζωής ανάπτυξης και συντήρησης λογισμικού. Είναι μια πρακτική που χρησιμοποιείται συχνά για να αποφασίζει και να βελτιώνει την ποιότητα του λογισμικού.
Η ανάπτυξη είναι πιο συστηματική στις μέρες μας και οι οργανισμοί αναζητούν μέτρα δοκιμής πληρότητας και αποτελεσματικότητας για να δείξουν τα κριτήρια ολοκλήρωσης των δοκιμών. Από όλα αυτά, η κάλυψη θεωρείται ιδιαίτερα πολύτιμη.
Τι θα μάθετε:
- Τι είναι η δοκιμαστική κάλυψη;
- Κάλυψη δοκιμής και κάλυψη κώδικα
- Η εμπειρία μου
- Έννοια κάλυψης δοκιμής
- Πώς να υιοθετήσετε μια σωστή μέθοδο δοκιμαστικής κάλυψης;
- Πώς να βεβαιωθείτε ότι όλα έχουν δοκιμαστεί;
- Κρίσιμοι τομείς και μέθοδοι για αποτελεσματική δοκιμή
- Πλεονεκτήματα της ευαισθητοποίησης δοκιμής κάλυψης για έναν Tester:
- συμπέρασμα
- Συνιστώμενη ανάγνωση
Τι είναι η δοκιμαστική κάλυψη;
Με απλά λόγια, η κάλυψη είναι 'Τι δοκιμάζουμε και πόσο δοκιμάζουμε;'
Η κάλυψη δοκιμών βοηθά στην παρακολούθηση της ποιότητας των δοκιμών και βοηθά τους δοκιμαστές να δημιουργήσουν δοκιμές που καλύπτουν περιοχές που λείπουν ή δεν έχουν επικυρωθεί.
Οι περισσότερες ομάδες βασίζουν τους υπολογισμούς κάλυψης μόνο σε λειτουργικές απαιτήσεις. Είναι επίσης δίκαιο, διότι πρώτα απ 'όλα μια εφαρμογή πρέπει να κάνει ό, τι πρέπει να κάνει. Εάν όχι, η ταχύτητα ή η ασφάλειά του ή η ευκολία χρήσης - κανένα από αυτά δεν έχει σημασία.
Ωστόσο, εάν είναι αφιερωμένο και ανεξάρτητο μη λειτουργικές δοκιμές Οι ομάδες εργάζονται σε επιδόσεις, ασφάλεια, δοκιμές χρηστικότητας κ.λπ., τότε θα πρέπει να παρακολουθούν τις απαιτήσεις τους μέχρι την εκτέλεση μέσω των δοκιμαστικών αναλυτικών στοιχείων κάλυψης.
Κάλυψη δοκιμής και κάλυψη κώδικα
Η κάλυψη δοκιμών συχνά συγχέεται με την Κάλυψη κώδικα. Παρόλο που οι βασικές αρχές είναι ίδιες, είναι δύο διαφορετικά πράγματα.
Κάλυψη κώδικα πραγματικά μιλά για πρακτικές δοκιμών μονάδας που πρέπει να στοχεύουν σε όλες τις περιοχές του κώδικα τουλάχιστον μία φορά και να γίνονται από προγραμματιστές.
Η κάλυψη δοκιμής, από την άλλη πλευρά, είναι δοκιμή κάθε απαίτησης τουλάχιστον μία φορά και είναι προφανώς μια δραστηριότητα ομάδας QA.
Αυτό που πραγματικά πληροί τις προϋποθέσεις για να καλυφθεί εξαρτάται από την ερμηνεία κάθε ομάδας.
Για παράδειγμα , Ορισμένες ομάδες καλούν μια απαίτηση που καλύπτεται εάν υπάρχει τουλάχιστον μία δοκιμαστική υπόθεση εναντίον της. Μερικές φορές, καλύπτεται εάν έχει ανατεθεί τουλάχιστον ένα μέλος της ομάδας. Ή, εάν εκτελούνται όλες οι δοκιμαστικές περιπτώσεις που σχετίζονται με αυτήν.
- Εάν έχουν δημιουργηθεί 10 απαιτήσεις και 100 δοκιμές - όταν αυτές οι 100 δοκιμές στοχεύουν και τις 10 απαιτήσεις και δεν τις αφήσουμε - ονομάζουμε αυτήν την επαρκή κάλυψη δοκιμών σε επίπεδο σχεδίασης.
- Όταν εκτελούνται μόνο 80 από τις δοκιμές που έχουν δημιουργηθεί και στοχεύουν μόνο 6 από τις απαιτήσεις. Λέμε ότι δεν καλύπτονται 4 απαιτήσεις, παρόλο που το 80% των δοκιμών έχει ολοκληρωθεί. Πρόκειται για στατιστικά κάλυψης σε επίπεδο εκτέλεσης.
- Όταν μόνο 90 δοκιμές που σχετίζονται με 8 απαιτήσεις έχουν εκχωρήσει δοκιμαστές και οι υπόλοιπες δεν είναι, λέμε ότι η κάλυψη ανάθεσης δοκιμής είναι 80% (8 στις 10 απαιτήσεις).
Είναι επίσης σημαντικό για το πότε να υπολογίσετε την κάλυψη.
Εάν το κάνετε πολύ νωρίς στη διαδικασία, θα δείτε πολλά κενά επειδή τα πράγματα εξακολουθούν να είναι ελλιπή. Συνιστάται λοιπόν να περιμένετε μέχρι την τελευταία κατασκευή δηλ. Final Regression Build. Αυτό θα δώσει τη σωστή κάλυψη των δοκιμών που πραγματοποιήθηκαν για τις δεδομένες απαιτήσεις.
Διαβάστε επίσης => Διαδικασία διαχείρισης απελευθέρωσης και ανάπτυξης
Η εμπειρία μου
Σκηνή πριν από 8 χρόνια: Όταν είχα 2 χρόνια εμπειρίας στη βιομηχανία δοκιμών λογισμικού, σκεφτόμουν ότι ήταν εντάξει αν δεν γνωρίζω κάποια βασικά στοιχεία για τη δοκιμή λογισμικού ως κάτι που κάποιος μπορεί να μάθει με εμπειρία και εγώ κι εγώ θα το κάνω.
Έκανα σωστό - και λάθος επίσης.
Ακριβώς επειδή με την εμπειρία, μαθαίνετε να βλέπετε μια μεγαλύτερη εικόνα, καταλαβαίνετε την πραγματική έννοια της «Κρίσιμης Κατάστασης» και κατανοείτε περισσότερο τον τελικό χρήστη.
Λάθος γιατί κανένα από τα αναφερόμενα πράγματα δεν απαιτεί εμπειρία, αλλά πρώιμη μάθηση, την οποία κατάλαβα πολύ αργά. Αυτός είναι ο ενθαρρυντικός παράγοντας για τη σύνταξη αυτής της ανάρτησης.
Εδώ είναι η εμπειρία μου από μία από τις συνεντεύξεις εκείνη την εποχή:
Πώς βεβαιώνεστε ότι η δοκιμαστική κάλυψη είναι πλήρης ή μέγιστη; Μου ζητήθηκε.
Ummmm …… Βεβαιώνω ότι δοκιμάζω κάθε λειτουργικότητα , Είπα.
μικρό o λέτε ότι μόλις δοκιμάσετε όλες τις λειτουργίες, πιστεύετε ότι έχετε καλύψει το μέγιστο της εφαρμογής / προϊόντος, όσον αφορά τη δοκιμή , ο ερευνητής απολύθηκε.
Ummm… καλά… .ummm…. Ναι, γιατί όταν δοκιμάζετε όλες τις λειτουργίες, είστε σίγουροι για τη συμπεριφορά της εφαρμογής / του προϊόντος, Υποστήριξα την απάντησή μου .
Συμφωνώ, αλλά η ερώτησή μου είναι - θα σας δώσει εμπιστοσύνη ότι η δοκιμαστική σας κάλυψη είναι μέγιστη ή πλήρης; ο ερευνητής δεν είχε διάθεση να με αφήσει.
Τώρα, γινόμουν ανυπόμονος, άγνωστος για το γεγονός ότι επρόκειτο να μάθω ένα από τα πιο σημαντικά θέματα σχετικά με τη δοκιμή λογισμικού - ' Δοκιμαστική κάλυψη ' .
Αντί να αναπαράγω τα αποσπάσματα της συνέντευξης, συνοψίζω εδώ, τι έμαθα για το Testing Coverage, εκείνη την ημέρα. Αλλά πριν από αυτό είναι σαφές σε ένα σημείο - η κάλυψη δοκιμών δεν σημαίνει ποτέ να γνωρίζετε εάν δοκιμάζετε αρκετά ή όχι, ούτε σημαίνει ότι δοκιμάζετε τέλεια ή όχι.
Έννοια κάλυψης δοκιμής
Η κάλυψη δοκιμών μπορεί να έχει διαφορετική σημασία σε διαφορετικό πλαίσιο. Ας ανακαλύψουμε αυτά τα περιβάλλοντα ένα προς ένα:
Κάλυψη προϊόντων - Ποιες πτυχές του προϊόντος εξετάσατε;
Ναι, όταν η κάλυψη δοκιμών μετράται από την άποψη του προϊόντος, ο κύριος τομέας στον οποίο πρέπει να εστιάσετε είναι - σε ποιους τομείς του προϊόντος έχετε δοκιμάσει και ποιος παραμένει μη δοκιμασμένος;
Παράδειγμα # 1:
Εάν το 'μαχαίρι' είναι προϊόν, δοκιμάζετε. απλώς μην επικεντρωθείτε στον έλεγχο αν κόβει σωστά τα λαχανικά / φρούτα. Υπάρχουν άλλες πτυχές που πρέπει να αναζητηθούν όπως - ο χρήστης θα πρέπει να μπορεί να το χειρίζεται άνετα.
Παράδειγμα # 2:
Εάν το 'σημειωματάριο' είναι μια εφαρμογή, δοκιμάζετε, ο έλεγχος σχετικών λειτουργιών είναι απαραίτητο.
Αλλά άλλες πτυχές που πρέπει να προσέξετε είναι - η εφαρμογή ανταποκρίνεται σωστά ενώ ταυτόχρονα χρησιμοποιεί άλλες εφαρμογές, η εφαρμογή δεν διακόπτεται όταν ο χρήστης προσπαθεί να κάνει κάτι ασυνήθιστο , παρέχεται στον χρήστη κατάλληλα μηνύματα προειδοποίησης / σφάλματος, ο χρήστης είναι σε θέση να κατανοήσει και να χρησιμοποιήσει την εφαρμογή εύκολα, το περιεχόμενο βοήθειας είναι διαθέσιμο όταν απαιτείται.
Εάν δεν εξετάσετε τα αναφερόμενα σενάρια, δεν μπορείτε να ισχυριστείτε ότι η δοκιμαστική κάλυψη για την εφαρμογή είναι πλήρης.
Κάλυψη κινδύνων - Για ποιους κινδύνους έχετε δοκιμάσει;
Η κάλυψη κινδύνων είναι μια άλλη πτυχή της πλήρους κάλυψης δοκιμών. Δεν μπορείτε να επισημάνετε το προϊόν ή την εφαρμογή ως 'δοκιμασμένο' μέχρι να δοκιμάσετε και τους σχετικούς κινδύνους. Η κάλυψη των σχετικών κινδύνων είναι ένας σημαντικός παράγοντας στη συνολική κάλυψη δοκιμών.
Παράδειγμα # 1:
Κατά τη δοκιμή ενός αεροπλάνου, εάν ένας δοκιμαστής σας πει ότι έχει δοκιμάσει πλήρως το εσωτερικό σύστημα του αεροπλάνου και λειτουργεί καλά, αλλά μόνο η ικανότητα πτήσης του αεροπλάνου δεν καλύφθηκε κατά τη δοκιμή - ποια θα ήταν η αντίδρασή σας;
Λοιπόν, αυτό σημαίνει η κάλυψη κινδύνου. Ο προσδιορισμός του κινδύνου σύμφωνα με την εφαρμογή / προϊόν και ο έλεγχος του είναι πάντα καλή πρακτική.
μετατροπέας youtube σε mp3 που λειτουργεί
Παράδειγμα # 2:
Κατά τη δοκιμή ενός ιστότοπου ηλεκτρονικού εμπορίου, ο υπεύθυνος δοκιμών εξέτασε κάθε αποτελεσματικό παράγοντα, αλλά δεν έλαβε υπόψη τον κίνδυνο αριθμού χρηστών να έχουν πρόσβαση στον ιστότοπο ταυτόχρονα και την ημέρα της ΠΡΟΣΦΟΡΑΣ, ο μη θεωρούμενος κίνδυνος αποδείχθηκε τεράστιο λάθος.
Συνιστώμενη ανάγνωση =>
Κάλυψη απαιτήσεων - Για ποιες απαιτήσεις έχετε δοκιμάσει;
Εάν ένα προϊόν ή μια εφαρμογή έχει αναπτυχθεί πολύ καλά, αλλά αν δεν ταιριάζει με τις απαιτήσεις του πελάτη, τότε δεν είναι χρήσιμο. Η κάλυψη απαιτήσεων κατά τη δοκιμή είναι εξίσου σημαντική με την κάλυψη προϊόντων.
Παράδειγμα # 1:
Ενθουσιασμένος για την οικογενειακή λειτουργία, ζητήσατε από τον ράφτη να ράψει το φόρεμά σας και να φορέσει αυτά τα μπλε κουμπιά παγώνι στο ντεκολτέ.
Ενώ ράβει το φόρεμα, ο ράφτης πίστευε ότι η τοποθέτηση αυτών των κουμπιών στο ντεκολτέ δεν θα φανεί καλή, οπότε έβαλε ένα χρυσό περίγραμμα. Την ημέρα της δοκιμής, σίγουρα, ο δυσαρεστημένος πελάτης φώναξε στον ράφτη για να μην τηρήσει τις απαιτήσεις.
Παράδειγμα # 2:
Κατά τη δοκιμή μιας εφαρμογής συνομιλίας, ο ελεγκτής φρόντισε για όλα τα σημαντικά σημεία, όπως πολλοί χρήστες που συνομιλούν σε μια ομάδα, δύο χρήστες που συζητούν ανεξάρτητα, όλοι οι τύποι emoticons που διατίθενται, ενημερώσεις που αποστέλλονται στον χρήστη αμέσως κ.λπ. ανέφερε ότι όταν δύο χρήστες συνομιλούν ανεξάρτητα, η επιλογή βιντεοκλήσης θα πρέπει να είναι ενεργοποιημένη.
Ο πελάτης εμπορεύτηκε την εφαρμογή συνομιλίας ισχυριζόμενος ότι θα επέτρεπε την κλήση, ενώ δύο χρήστες συνομιλούν ανεξάρτητα. Μπορείτε να φανταστείτε τι θα συνέβαινε στην εφαρμογή συνομιλίας.
Επίσης ανάγνωση => Πώς να δημιουργήσετε Απαιτήσεις Ιχνηλασιμότητα Matrix
Πώς να υιοθετήσετε μια σωστή μέθοδο δοκιμαστικής κάλυψης;
Η ευαισθητοποίηση είναι τα πάντα:
Πρώτα πράγματα πρώτα, η ομάδα QA πρέπει να γνωρίζει πόση δουλειά ασχολείται και πού βρίσκονται οι εργασίες σχεδιασμού. Με αυτόν τον τρόπο, θα γνωρίζουν εάν πρόκειται να προστεθούν περισσότερες δοκιμές. Για να το κάνετε αυτό, θα μπορούσατε να χρησιμοποιήσετε ένα RTM όπως είναι η τυπική πρακτική.
=> Ελέγξτε αυτό το άρθρο για να μάθετε περισσότερα σχετικά με αυτό και πώς να το χρησιμοποιήσετε: Τρόπος δημιουργίας απαιτήσεων Πίνακας ιχνηλασιμότητας - Ακριβής διαδικασία με πρότυπο δείγματος
Δεύτερον, ελέγξτε την ανάθεση πόρων και διαδικασία εκτέλεσης δοκιμής να δούμε αν όλα ελέγχονται με τον πιο αποτελεσματικό τρόπο.
Ένας πίνακας όπως παρακάτω μπορεί να είναι χρήσιμος:
Τύπος δοκιμής | Σύνολο περιπτώσεων | Εκτελεσθείσες υποθέσεις | Κατάσταση | Σχόλια |
---|---|---|---|---|
Λειτουργικός | 100 | 80 | 50 πέρασμα, 30 αποτυγχάνουν | |
Συμβατότητα | 100 | πενήντα | 45 πέρασμα, 5 απέτυχαν | |
Ευχρηστία | 100 | 100 | 98 πέρασμα, 2 αποτυγχάνουν | |
Τελική παλινδρόμηση | 100 | 100 | 99 πάσο, 1 απέτυχε |
Πώς να βεβαιωθείτε ότι όλα έχουν δοκιμαστεί;
- Κάθε εξεταστής πρέπει να γνωρίζει τις απαιτήσεις και τις μεθόδους δοκιμών
- Δώστε προτεραιότητα στις απαιτήσεις σας και εστιάστε την ενέργειά σας εκεί όπου χρειάζεται περισσότερο
- Ενημερωθείτε για το πώς μια συγκεκριμένη κυκλοφορία διαφέρει από την προηγούμενη, ώστε να μπορείτε να προσδιορίσετε τις κρίσιμες απαιτήσεις με μεγαλύτερη ακρίβεια και να εστιάσετε στη μέγιστη θετική κάλυψη
- Προσαρμογή αυτοματισμού δοκιμής
- Χρησιμοποιήστε εργαλεία διαχείρισης δοκιμών για να μείνετε πάντα ενημερωμένοι
- Έξυπνη ανάθεση εργασίας - Διοχετεύστε τους καλύτερους πόρους σας για κρίσιμες εργασίες και αφήστε τους νέους υπεύθυνους δοκιμών να εξερευνήσουν περισσότερα για μια νέα προοπτική
- Διατήρηση α λίστα ελέγχου για όλες τις εργασίες και διάφορες δραστηριότητες
- Αλληλεπιδράστε περισσότερο με τις ομάδες Dev / Scrum / BA για να λάβετε πληροφορίες σχετικά με τη συμπεριφορά της εφαρμογής
- Παρακολουθήστε όλους τους κύκλους και τις διορθώσεις σας
- Προσδιορίστε τα περισσότερα επιβλητικά προβλήματα στην αρχική έκδοση (όταν είναι δυνατόν), ώστε τα επόμενα να μπορούν να λειτουργήσουν για καλύτερη σταθερότητα και να φτάσουν σε περιοχές που έχουν αποκλειστεί από προηγούμενα προβλήματα
Κρίσιμοι τομείς και μέθοδοι για αποτελεσματική δοκιμή
# 1)Ανακάτευση πόρων: Ανταλλάξτε εργασίες μεταξύ των μελών της ομάδας σας. Αυτό βοηθά στη βελτίωση της εμπλοκής και στην αποτροπή της συγκέντρωσης γνώσεων.
#δύο)Κάλυψη συμβατότητας: Βεβαιωθείτε ότι γνωρίζετε και συμπεριλαμβάνετε το διαφορετικά προγράμματα περιήγησης και πλατφόρμες για να ελέγξετε την αίτησή σας.
# 3)Ιδιοκτησία: Κάντε τους υπεύθυνους υπευθυνότητας και δώστε τους έναν ελεύθερο έλεγχο (με παρακολούθηση και υποστήριξη φυσικά) για την ενότητα / εργασία στην οποία εργάζονται. Αυτό βοηθά στην οικοδόμηση της ευθύνης και τους επιτρέπει να δοκιμάσουν δημιουργικούς τρόπους αντί να ακολουθούν τον περασμένο δρόμο.
# 4)Προθεσμίες: Η γνώση των προθεσμιών κυκλοφορίας πριν από την έναρξη της φάσης δοκιμών βοηθά στον αποτελεσματικό σχεδιασμό
# 5)Επικοινωνία : Μείνετε σε επαφή με τους προγραμματιστές και άλλες ομάδες μεταξύ των κύκλων κυκλοφορίας για να μάθετε τι συμβαίνει.
# 6)Διατηρήστε ένα RTM: Λειτουργεί ως καλό παράγωγο του Ενδιαφερόμενοι ή Πελάτες , βάσει του οποίου μπορεί να επιβεβαιωθεί το πρόγραμμα κυκλοφορίας
Πλεονεκτήματα της ευαισθητοποίησης δοκιμής κάλυψης για έναν Tester:
- Βοηθά πρωτίστως στην προτεραιότητα της δοκιμής
- Βοηθά στην επίτευξη 100% κάλυψης απαιτήσεων ή με άλλα λόγια, αποτρέπει τη διαρροή απαιτήσεων
- Ανάλυση επιπτώσεων γίνεται ευκολότερο
- Χρήσιμο για τον προσδιορισμό του Κριτήρια EXIT
- Ενεργοποιεί ένα δοκιμαστικό καλώδιο για να προετοιμάσει μια διαγραφή έκθεση κλεισίματος δοκιμής
συμπέρασμα
Η δοκιμαστική κάλυψη δεν τελειώνει με τα αναφερόμενα περιβάλλοντα. Υπάρχουν πολλά άλλα σημεία που πρέπει να ληφθούν υπόψη όταν πρόκειται για δοκιμαστική κάλυψη.
Δεν είναι πάντα αλήθεια ότι όταν δοκιμάζετε περισσότερα, τα αποτελέσματα είναι καλύτερα. Στην πραγματικότητα, όταν δοκιμάζετε περισσότερα χωρίς προφανή στρατηγική, πιθανότατα θα καταλήξετε να επενδύετε πολύ χρόνο.
Με μια πιο δομημένη προσέγγιση, έναν στόχο 100% κάλυψης απαιτήσεων και αποτελεσματικές μεθόδους δοκιμών, δεν θα συμβιβαστείτε στην ποιότητα.
Ελπίζουμε ότι οι τεχνικές που περιγράφονται σε αυτό το άρθρο θα σας δώσουν κάποιους δείκτες.
Ρίξτε τα σχόλια και τις απόψεις σας σχετικά με την ανάρτηση. Ως συνήθως, μας αρέσει να ακούμε από εσάς.
Συνιστώμενη ανάγνωση
- Τα καλύτερα εργαλεία δοκιμής λογισμικού 2021 [QA Test Automation Tools]
- Δοκιμή λογισμικού QA Assistant Job
- Μάθημα δοκιμών λογισμικού: Σε ποιο Ινστιτούτο Δοκιμών Λογισμικού πρέπει να εγγραφώ;
- Επιλέγοντας Δοκιμή λογισμικού ως καριέρα σας
- Δοκιμή λογισμικού Τεχνικό περιεχόμενο Συγγραφέας Freelancer Job
- Είναι η δοκιμή λογισμικού μια συναισθηματική εργασία;
- Μερικές ενδιαφέρουσες ερωτήσεις συνέντευξης δοκιμών λογισμικού
- Σχόλια και σχόλια μαθήματος δοκιμών λογισμικού