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

Τι είναι η διαδικασία διαχείρισης ελαττωμάτων;
The Διαδικασία διαχείρισης ελαττωμάτων είναι μια συστηματική προσέγγιση που χρησιμοποιείται στις δοκιμές λογισμικού για τον εντοπισμό, την ταξινόμηση, τη διόρθωση και την επαλήθευση σφαλμάτων πριν από την κυκλοφορία του λογισμικού. Ο κύκλος ζωής περιλαμβάνει έξι βασικά στάδια: 1) Ανακάλυψη του ελαττώματος, 2) Κατηγοριοποίηση, 3) Επίλυση από τους προγραμματιστές, 4) Επαλήθευση από τους δοκιμαστές, 5) Κλείσιμο και 6) Αναφορά ελαττωμάτων στο τέλος του έργου.
Αυτό το άρθρο εξηγεί πώς να εφαρμόσετε τη Διαδικασία Διαχείρισης Ελαττωμάτων χρησιμοποιώντας το Guru99 Παράδειγμα ιστότοπου τράπεζας, ώστε οι αρχάριοι και οι ενδιάμεσοι δοκιμαστές να μπορούν να κατανοήσουν κάθε βήμα σε ένα πραγματικό πλαίσιο έργου.
Γιατί χρειάζεστε τη διαδικασία διαχείρισης ελαττωμάτων;
Φανταστείτε ότι η ομάδα σας έχει βρει αρκετά σφάλματα κατά τη δοκιμή του Guru99 Τραπεζικό έργο. Χωρίς μια δομημένη διαδικασία, η επικοινωνία μεταξύ των δοκιμαστών και των προγραμματιστών γίνεται προφορικά ή μέσω διάσπαρτων μηνυμάτων.
Μια εβδομάδα αργότερα, ο προγραμματιστής απαντά με μια διαφορετική κατανόηση του προβλήματος.
Την επόμενη εβδομάδα, ο δοκιμαστής απαντά ξανά, δημιουργώντας ακόμη μεγαλύτερη σύγχυση.
Όταν η επικοινωνία για τα ελαττώματα γίνεται προφορικά ή ανεπίσημα, τα πράγματα περιπλέκονται πολύ γρήγορα. Για τον έλεγχο και την αποτελεσματική διαχείριση σφαλμάτων, χρειάζεστε έναν καθορισμένο κύκλο ζωής ελαττωμάτων που να τυποποιεί τον τρόπο με τον οποίο οι ομάδες αναφέρουν, track, και κλείσιμο ζητημάτων.
Βήμα 1) Ανακάλυψη
Στο Ανακάλυψη Στη φάση αυτή, η ομάδα του έργου πρέπει να εντοπίσει όσο το δυνατόν περισσότερα ελαττώματα πριν τα συναντήσει ο τελικός πελάτης. Ένα ελάττωμα θεωρείται «ανακαλυφθέν» μόλις αναγνωριστεί και γίνει αποδεκτό από την ομάδα ανάπτυξης, οπότε και η κατάστασή του αλλάζει σε Αποδεκτό.
Στο παράδειγμα, οι δοκιμαστές ανακάλυψαν 84 ελαττώματα στο GuruΙστότοπος 99 Τράπεζας.
Ωστόσο, οι δοκιμαστές και οι προγραμματιστές δεν συμφωνούν πάντα. Δείτε την ακόλουθη περίπτωση, στην οποία η ομάδα δοκιμών εντοπίζει προβλήματα στο Guru99 ιστοσελίδα της Τράπεζας και τα αναφέρει, αλλά η ομάδα ανάπτυξης αμφισβητεί εάν πρόκειται για ελαττώματα:
Σε μια τέτοια περίπτωση, ως Διαχειριστής Δοκιμών, τι πρέπει να κάνετε;
Α) Συμφωνώ με την ομάδα δοκιμών ότι πρόκειται για ελάττωμα.
Β) Αναλάβετε τον ρόλο του κριτή και αποφασίστε εάν το πρόβλημα είναι ελάττωμα ή όχι.
Γ) Συμφωνώ με την ομάδα ανάπτυξης ότι δεν πρόκειται για ελάττωμα.
Η σωστή προσέγγιση είναι η επιλογή Β. Θα πρέπει να εφαρμοστεί μια διαδικασία επίλυσης για την επίλυση της σύγκρουσης και ο Διαχειριστής Δοκιμών θα πρέπει να αξιολογήσει το ζήτημα αμερόληπτα πριν αποφασίσει εάν χαρακτηρίζεται ως ελάττωμα.
Βήμα 2) Κατηγοριοποίηση
Η κατηγοριοποίηση ελαττωμάτων βοηθά τους προγραμματιστές να ιεραρχήσουν την εργασία τους, έτσι ώστε να διορθώνονται πρώτα τα πιο κρίσιμα για την επιχείρηση ζητήματα. Η κατηγοριοποίηση συνήθως εκτελείται από τον Διαχειριστή Δοκιμών και βασίζεται στη σοβαρότητα και τον αντίκτυπο στην επιχείρηση.
Τα ελαττώματα συνήθως ομαδοποιούνται σε τέσσερα επίπεδα προτεραιότητας: Κρίσιμη, Υψηλή, Μέτρια και ΧαμηλήΔοκιμάστε να αντιστοιχίσετε τη σωστή προτεραιότητα σε καθένα από τα ακόλουθα ελαττώματα:
- Η απόδοση του ιστότοπου είναι πολύ αργή.
- Η λειτουργία σύνδεσης στον ιστότοπο δεν λειτουργεί σωστά.
- Το γραφικό περιβάλλον χρήστη (GUI) του ιστότοπου δεν εμφανίζεται σωστά κινητό συσκευές.
- Ο ιστότοπος δεν μπορεί να θυμηθεί την περίοδο σύνδεσης χρήστη.
- Ορισμένοι σύνδεσμοι δεν λειτουργούν.
Ακολουθούν οι προτεινόμενες απαντήσεις:
| Όχι. | Περιγραφή | Προτεραιότητα | εξήγηση |
|---|---|---|---|
| 1 | Η απόδοση του ιστότοπου είναι πολύ αργή | Ψηλά | Τα προβλήματα απόδοσης προκαλούν σημαντική ταλαιπωρία στους τελικούς χρήστες. |
| 2 | Η λειτουργία σύνδεσης δεν λειτουργεί σωστά | Κρίσιμος | Η σύνδεση είναι μια βασική λειτουργία ενός τραπεζικού ιστότοπου. Εάν αποτύχει, ολόκληρη η διαδρομή του χρήστη αποκλείεται. |
| 3 | Το γραφικό περιβάλλον χρήστη (GUI) δεν εμφανίζεται σωστά σε κινητές συσκευές | Μέτριας Δυσκολίας | Το ελάττωμα επηρεάζει τους χρήστες που προβάλλουν τον ιστότοπο σε smartphones. |
| 4 | Ο ιστότοπος δεν μπορεί να θυμηθεί την περίοδο σύνδεσης χρήστη | Ψηλά | Οι χρήστες μπορούν να συνδεθούν, αλλά δεν μπορούν να πραγματοποιήσουν περαιτέρω συναλλαγές. |
| 5 | Ορισμένοι σύνδεσμοι δεν λειτουργούν | Χαμηλός | Μια εύκολη λύση για τους προγραμματιστές, καθώς οι χρήστες εξακολουθούν να έχουν πρόσβαση στον υπόλοιπο ιστότοπο. |
Βήμα 3) Επίλυση ελαττώματος
Επίλυση ελαττώματος Στις δοκιμές λογισμικού, η διόρθωση των ελαττωμάτων γίνεται βήμα προς βήμα. Η διαδικασία επίλυσης ξεκινά με την ανάθεση ελαττωμάτων στους προγραμματιστές, οι οποίοι στη συνέχεια προγραμματίζουν τις διορθώσεις με βάση την προτεραιότητα, εφαρμόζουν τις διορθώσεις και τέλος στέλνουν μια αναφορά επίλυσης πίσω στον Διαχειριστή Δοκιμών. Αυτή η ακολουθία καθιστά το ελάττωμα... tracβασιλιάς διαφανής και υπόλογος.
Μπορείτε να ακολουθήσετε τα παρακάτω βήματα για να διορθώσετε ένα ελάττωμα:
- ΑΝΑΘΕΣΗ ΕΡΓΑΣΙΑΣ: Το ελάττωμα ανατίθεται σε έναν προγραμματιστή ή τεχνικό και η κατάστασή του αλλάζει σε Απάντηση.
- Καθορισμός χρονοδιαγράμματος: Η ομάδα ανάπτυξης αναλαμβάνει και δημιουργεί ένα πρόγραμμα επιδιόρθωσης με βάση την προτεραιότητα των ελαττωμάτων.
- Διορθώστε το ελάττωμα: Ενώ οι προγραμματιστές διορθώνουν τα ελαττώματα, ο Διαχειριστής Δοκιμών tracks πρόοδος έναντι του προγραμματισμένου χρονοδιαγράμματος.
- Αναφέρετε την απόφαση: Οι προγραμματιστές στέλνουν μια αναφορά που επιβεβαιώνει ποια ελαττώματα έχουν διορθωθεί και πώς.
Βήμα 4) Επαλήθευση
Αφού η ομάδα ανάπτυξης έχει καθορίζεται αναφερθεί τα ελαττώματα, η ομάδα δοκιμών που ελέγχθηκαν ότι τα ζητήματα έχουν επιλυθεί.
Για παράδειγμα, όταν η ομάδα ανάπτυξης αναφέρει ότι έχουν διορθωθεί 61 ελαττώματα, η ομάδα δοκιμών επανεξετάζει το καθένα για να επιβεβαιώσει εάν οι διορθώσεις λειτουργούν σωστά υπό τις ίδιες συνθήκες που προκάλεσαν την αρχική αποτυχία.
Βήμα 5) Κλείσιμο
Μόλις διορθωθεί και επαληθευτεί ένα ελάττωμα, η κατάστασή του αλλάζει σε ΚλειστόΕάν το ελάττωμα δεν επιλυθεί σωστά κατά την επαλήθευση, πρέπει να στείλετε μια ειδοποίηση πίσω στην ομάδα ανάπτυξης για να το διερευνήσει ξανά. Το κλείσιμο υποδεικνύει ότι το ελάττωμα δεν είναι πλέον ενεργό στο σύστημα.
Βήμα 6) Αναφορά ελαττωμάτων
Αναφορά ελαττωμάτων Στις δοκιμές λογισμικού, οι Υπεύθυνοι Δοκιμών προετοιμάζουν και κοινοποιούν την κατάσταση ελαττωμάτων στην ομάδα διαχείρισης. Η ομάδα διαχείρισης εξετάζει την αναφορά και παρέχει σχόλια ή πρόσθετη υποστήριξη, εάν απαιτείται. Η αναφορά ελαττωμάτων βελτιώνει την επικοινωνία, tracβασιλιάς και ορατότητα γύρω από ελαττώματα.
Η ηγεσία έχει το δικαίωμα να κατανοεί την κατάσταση των ελαττωμάτων για να υποστηρίζει αποτελεσματικά το έργο. Επομένως, πρέπει να υποβάλλετε τακτικά αναφορές για την τρέχουσα κατάσταση ελαττωμάτων, ώστε να μπορούν να παρέχουν καθοδήγηση και πόρους.
Σημαντικές μετρήσεις ελαττωμάτων
Επιστρέφοντας στο αρχικό σενάριο, οι ομάδες προγραμματιστών και δοκιμών εξετάζουν τα ελαττώματα μαζί. Τα συνδυασμένα αποτελέσματα φαίνονται παρακάτω.
Πώς μπορείτε να μετρήσετε και να αξιολογήσετε την ποιότητα εκτέλεσης των δοκιμών;
Αυτό είναι ένα κρίσιμο ερώτημα κάθε Υπεύθυνος δοκιμών θέλει να απαντήσει. Συνήθως χρησιμοποιούνται δύο βασικές παράμετροι:
Στο παραπάνω σενάριο, το Αναλογία Απόρριψης Ελαττωμάτων (DRR) υπολογίζεται ως 20/84 = 0.238 (23.8%).
Ως ένα άλλο παράδειγμα, ας υποθέσουμε ότι GuruΟ ιστότοπος της 99 Bank έχει συνολικά 64 ελαττώματα, αλλά η ομάδα δοκιμών εντοπίζει μόνο 44 — έννοια 20 τα ελαττώματα δεν είχαν εντοπιστεί. Λόγος Διαρροής Ελαττωμάτων (DLR) υπολογίζεται ως 20/64 = 0.312 (31.2%).
Συνοπτικά, η ποιότητα εκτέλεσης των δοκιμών αξιολογείται χρησιμοποιώντας τις δύο παρακάτω παραμέτρους:
Όσο μικρότερες είναι οι τιμές DRR και DLR, τόσο καλύτερη είναι η ποιότητα εκτέλεσης της δοκιμής. Το αποδεκτό εύρος ορίζεται γενικά από τους στόχους του έργου ή συγκρίνεται με παρόμοια έργα. Σε αυτό το παράδειγμα, το συνιστώμενο αποδεκτό εύρος είναι 5% σε 10%Η τρέχουσα εκτέλεση εμπίπτει εκτός αυτού του εύρους, γεγονός που υποδηλώνει ότι η ποιότητα των δοκιμών θα πρέπει να βελτιωθεί μέσω των ακόλουθων μέτρων:
- Βελτίωση τις δεξιότητες δοκιμών των μελών της ομάδας.
- Περνώ περισσότερο χρόνο στην εκτέλεση των δοκιμών, ιδίως κατά την αναθεώρηση των αποτελεσμάτων εκτέλεσης.
Καλυτερα Πρακτικές Αποτελεσματικής Διαχείρισης Βλαβών
Η τήρηση δομημένων βέλτιστων πρακτικών είναι αυτό που διαχωρίζει μια ώριμη διαδικασία διαχείρισης ελαττωμάτων από μια χαοτική. Ο στόχος δεν είναι απλώς η διόρθωση σφαλμάτων, αλλά η δημιουργία ενός συστήματος που τα εμποδίζει να διαρρεύσουν στην παραγωγή και ελαχιστοποιεί τις διακοπές επικοινωνίας μεταξύ των υπευθύνων δοκιμών και των προγραμματιστών.
Ακολουθούν οι βέλτιστες πρακτικές που θα πρέπει να υιοθετήσουν αμέσως οι αρχάριοι και οι ενδιάμεσοι δοκιμαστές:
- Τυποποιήστε το πρότυπο ελαττώματος: Χρησιμοποιήστε ένα πρότυπο αναφοράς διορθωμένου ελαττώματος που περιέχει πεδία όπως Αναγνωριστικό ελαττώματος, Descriptιόν, Βήματα αναπαραγωγής, Σοβαρότητα, Προτεραιότητα, Περιβάλλον και Συνημμένα. Η συνέπεια μειώνει τις ανταλλαγές μεταξύ των υπευθύνων δοκιμών και των προγραμματιστών.
- Δώστε προτεραιότητα πριν από την ανάθεση: Να κατηγοριοποιείτε πάντα τα ελαττώματα κατά σοβαρότητα και προτεραιότητα πριν τα στείλετε στους προγραμματιστές. Αυτό διασφαλίζει ότι τα κρίσιμα προβλήματα δεν θα κολλήσουν πίσω από τα αισθητικά.
- Αναπαραγωγή πριν από την αναφορά: Αναπαράγετε το ελάττωμα τουλάχιστον δύο φορές σε καθαρό περιβάλλον πριν το εντοπίσετε. Τα αναπαραγώγιμα ελαττώματα κλείνουν πιο γρήγορα και μειώνουν το ποσοστό απόρριψης.
- Υιοθέτηση ενός ελαττώματος tracεργαλείο βασιλιά: Χρησιμοποιήστε εργαλεία όπως π.χ ΖΗΡΑ, BugzillaΤο HIFU, ή Υψηλής Έντασης Εστιασμένος Υπέρηχος, στοχεύει επίσης στο πρόσωπο και τον λαιμό. Προσφέρει θεραπεία σε γρήγορες εκπομπές, γεγονός που κάνει τις συνεδρίες θεραπείας συντομότερες. Αλογάκι της παναγίας να συγκεντρώσω tracβασιλιάς, ιστορία και ρεπορτάζ.
- Διεξαγωγή συναντήσεων διαλογής: Διεξαγωγή σύντομων, στοχευμένων συναντήσεων διαλογής ελαττωμάτων για την ευθυγράμμιση των προτεραιοτήτων μεταξύ των ομάδων διασφάλισης ποιότητας, ανάπτυξης και προϊόντων.
- Μετρήστε τη διαρροή και την απόρριψη: Track DLR και DRR σε κάθε σπριντ ή κύκλο. Ένα αυξανόμενο ποσοστό διαρροής αποτελεί έγκαιρη προειδοποίηση ότι η κάλυψη των δοκιμών είναι ελλιπής.
- Εκτελέστε ανάλυση της βασικής αιτίας: Για επαναλαμβανόμενα ή υψηλής σοβαρότητας ελαττώματα, εκτελέστε μια ανάλυση βασικής αιτίας, ώστε να μην επιστρέψει η ίδια κατηγορία σφάλματος σε μελλοντικές εκδόσεις.
- Κλείστε τον κύκλο με την αναφορά: Κοινοποιήστε εβδομαδιαίους πίνακες ελέγχου ελαττωμάτων στα ενδιαφερόμενα μέρη, ώστε τα προβλήματα να παραμένουν ορατά και εφαρμόσιμα.
Εφαρμόζονται με συνέπεια, αυτές οι πρακτικές σταθεροποιούν τον κύκλο ζωής των ελαττωμάτων και βελτιώνουν τη συνολική ποιότητα κάθε έκδοσης.
Πόροι:
Κάντε λήψη ενός δείγματος προτύπου αναφοράς ελαττωμάτων











