Μενού

7 Αρχές δοκιμής λογισμικού: Σύμπλεγμα ελαττωμάτων και Αρχή Pareto

  • Κύριος
  • Αλλα
  • 7 Αρχές δοκιμής λογισμικού: Σύμπλεγμα ελαττωμάτων και Αρχή Pareto

7 principles software testing

Δοκιμάστε Το Όργανο Μας Για Την Εξάλειψη Των Προβλημάτων

Επτά αρχές ελέγχου λογισμικού: Συμπεριλαμβανομένων περισσότερων λεπτομερειών σχετικά με τη συσσώρευση ελαττωμάτων, το Pareto Principle και το Pesticide Paradox.

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

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

7 αρχές δοκιμής λογισμικού

Τι θα μάθετε:

Επτά αρχές ελέγχου λογισμικού

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

Ας εξερευνήσουμε !!

# 1) Ο έλεγχος δείχνει την παρουσία ελαττωμάτων

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

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

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

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

Παράδειγμα 1 :

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

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

Παράδειγμα 2:

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

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

# 2) Πρώιμη δοκιμή

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

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

πρόωρες δοκιμές - κόστος διόρθωσης ελαττωμάτων

(εικόνα πηγή )

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

Τώρα το ερώτημα είναι πόσο νωρίς πρέπει να ξεκινήσει η δοκιμή ;

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

# 3) Δεν είναι δυνατή η εξαντλητική δοκιμή

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

Οι εξαντλητικοί έλεγχοι θα απαιτήσουν απεριόριστες προσπάθειες και οι περισσότερες από αυτές είναι αναποτελεσματικές. Επίσης, τα χρονοδιαγράμματα του έργου δεν θα επιτρέπουν τη δοκιμή τόσο πολλών συνδυασμών. Ως εκ τούτου, συνιστάται να δοκιμάσετε δεδομένα εισόδου χρησιμοποιώντας διαφορετικές μεθόδους όπως το Equivalence Partitioning και το Boundary Value Analysis.

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

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

# 4) Ο έλεγχος εξαρτάται από το περιβάλλον

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

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

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

# 5) Συγκέντρωση ελαττωμάτων

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

Αυτή είναι η αρχή Pareto της δοκιμής λογισμικού όπου το 80% των προβλημάτων εντοπίζονται στο 20% των ενοτήτων. Θα μάθουμε περισσότερα σχετικά με τη συσσώρευση ελαττωμάτων και την αρχή Pareto σε αυτό το άρθρο.

# 6) Παράδοξο φυτοφαρμάκων

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

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

# 7) Απουσία σφάλματος

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

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

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

Τώρα ας εξερευνήσουμε Σύμπλεγμα ελαττωμάτων, Αρχή Pareto και παράδοξο παρασιτοκτόνων στο λεπτομέρεια .

Συγκέντρωση ελαττωμάτων

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

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

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

Το Defect Clustering βασίζεται στο ' Αρχή του Pareto Που είναι επίσης γνωστό ως 80-20 κανόνας . Αυτό σημαίνει ότι το 80% των ελαττωμάτων που εντοπίζονται οφείλονται στο 20% των ενοτήτων της εφαρμογής. Η έννοια του Pareto Principle καθορίστηκε αρχικά από έναν Ιταλό οικονομολόγο - Vilfrodo Pareto .

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

Για παράδειγμα ,ας εξετάσουμε την παρακάτω εικόνα που έχει δοκιμαστεί για μία από τις τραπεζικές εφαρμογές και δείχνει ότι τα περισσότερα ελαττώματα σχετίζονται με τη λειτουργία 'Overdraft'. Οι υπόλοιπες λειτουργίες όπως Περίληψη λογαριασμού, Μεταφορά χρημάτων, Μόνιμη οδηγία κ.λπ., έχουν περιορισμένο αριθμό ελαττωμάτων.

Συγκέντρωση ελαττωμάτων

(εικόνα πηγή )

Η παραπάνω εικόνα αναφέρει ότι υπάρχουν 18 ελαττώματα γύρω από τη λειτουργία Overdraft από τα συνολικά 32 ελαττώματα, πράγμα που σημαίνει ότι το 60% των ελαττωμάτων εντοπίζονται στη μονάδα 'Overdraft'.

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

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

Παράδοξο παρασιτοκτόνων

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

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

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

Ωστόσο, κατά καιρούς μπορεί να συμβεί ότι ενώ είστε ιδιαίτερα προσεκτικοί κατά την κωδικοποίηση σε μια συγκεκριμένη ενότητα (εδώ στην περίπτωσή μας το “ Πίστωση 'Module), ο προγραμματιστής ενδέχεται να παραμελήσει τις άλλες λειτουργικές μονάδες για να τον κωδικοποιήσει σωστά ή οι αλλαγές που έγιναν στη συγκεκριμένη ενότητα ενδέχεται να έχουν αρνητικό αντίκτυπο στις άλλες λειτουργίες, όπως Περίληψη λογαριασμού, Μεταφορά χρημάτων και Μόνιμες οδηγίες.

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

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

Προληπτικές Μέθοδοι Παράδοξου Παρασιτοκτόνου

Υπάρχουν δύο επιλογές μέσω των οποίων μπορούμε να αποτρέψουμε το Pesticide Paradox όπως φαίνεται παρακάτω:

προς το) Γράψτε ένα νέο σετ δοκιμαστικών περιπτώσεων που θα επικεντρωθεί σε διαφορετική περιοχή ή μονάδες (εκτός από την προηγούμενη μονάδα με τάση για ελαττώματα - Παράδειγμα: 'Υπερανάληψη') του λογισμικού.

σι) Προετοιμάστε νέες δοκιμαστικές θήκες και προσθέστε στις υπάρχουσες δοκιμαστικές θήκες.

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

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

Αλλά ενδέχεται οι υπεύθυνοι δοκιμών να παραμελήσουν την προηγούμενη ενότητα ( Παράδειγμα: 'Overdraft') όπου τα περισσότερα από τα ελαττώματα εντοπίστηκαν στην προηγούμενη επανάληψη και αυτό θα μπορούσε να είναι ένας κίνδυνος καθώς αυτή η ενότητα (Overdraft) θα μπορούσε να έχει εγχυθεί με τα νέα ελαττώματα μετά την κωδικοποίηση των άλλων ενοτήτων.

Στο ' μέθοδος Β Προετοιμάζονται νέες δοκιμαστικές θήκες έτσι ώστε να εντοπίζονται νέα πιθανά ελαττώματα στις υπόλοιπες ενότητες.

Εδώ στο παράδειγμά μας, οι νέες δοκιμαστικές περιπτώσεις θα μπορούν να βοηθήσουν στον εντοπισμό ελαττωμάτων στις ενότητες όπως Περίληψη λογαριασμού, Μεταφορά χρημάτων και Μόνιμη οδηγία. Ωστόσο, οι υπεύθυνοι δοκιμών δεν μπορούν να αγνοήσουν τις προηγούμενες λειτουργικές μονάδες με επιρρεπείς βλάβες ( Παράδειγμα: 'Overdraft') καθώς αυτές οι νέες περιπτώσεις δοκιμών συγχωνεύονται με τις υπάρχουσες περιπτώσεις δοκιμών.

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

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

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

Είναι απαραίτητο να ελέγξετε ποιες δοκιμαστικές περιπτώσεις απέτυχαν για να εντοπίσετε τα ελαττώματα στις 5 τελευταίες επαναλήψεις (ας υποθέσουμε 5 επαναλήψεις) και ποιες δοκιμαστικές περιπτώσεις δεν είναι πολύ σημαντικές. Μπορεί επίσης να συμβαίνει ότι η μονή ροή που καλύπτεται σε μερικές περιπτώσεις δοκιμής μπορεί να καλυφθεί σε άλλες περιπτώσεις δοκιμής από άκρο σε άκρο και αυτές οι περιπτώσεις δοκιμής με μονή ροή μπορούν να αφαιρεθούν.

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

Για παράδειγμα ,έχουμε 50 περιπτώσεις δοκιμών για να καλύψουμε μια συγκεκριμένη ενότητα και έχουμε δει ότι από αυτές τις 50 περιπτώσεις δοκιμής 20 περιπτώσεις δοκιμής δεν κατάφεραν να εντοπίσουν ένα νέο ελάττωμα στις τελευταίες επαναληπτικές δοκιμές (ας υποθέσουμε 5 επαναλήψεις). Επομένως, αυτές οι 20 δοκιμαστικές περιπτώσεις πρέπει να αναθεωρηθούν διεξοδικά και πρέπει να ελέγξουμε πόσο σημαντικές είναι αυτές οι δοκιμαστικές περιπτώσεις και μπορεί να ληφθεί σχετική απόφαση ως προς το εάν θα διατηρηθούν οι 20 δοκιμαστικές περιπτώσεις ή εάν θα αφαιρεθούν.

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

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

συμπέρασμα

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

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

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

κύριες διαφορές μεταξύ c και c ++

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

Καλή ανάγνωση !!

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

^