Αυτό το σεμινάριο εισάγει τις επτά βασικές αρχές δοκιμής λογισμικού που πρέπει να γνωρίζουν κάθε δοκιμαστής λογισμικού και επαγγελματίας QA.
7 Αρχές δοκιμής λογισμικού
- Ο έλεγχος δείχνει την παρουσία ελαττωμάτων
- Δεν είναι δυνατή η εξαντλητική δοκιμή
- Πρόωρες δοκιμές
- Συγκέντρωση ελαττωμάτων
- Παράδοξο φυτοφαρμάκων
- Η δοκιμή εξαρτάται από το περιβάλλον
- Απουσία λαθών
Ας μάθουμε τις αρχές δοκιμής με το ακόλουθο παράδειγμα βίντεο-
Κάντε κλικ εδώ εάν το βίντεο δεν είναι προσβάσιμο
Ιστορικό
Είναι σημαντικό να επιτύχετε τα βέλτιστα αποτελέσματα δοκιμών κατά τη διεξαγωγή δοκιμών λογισμικού χωρίς να αποκλίνει από τον στόχο. Αλλά πώς καθορίζετε ότι ακολουθείτε τη σωστή στρατηγική για δοκιμές; Για αυτό, πρέπει να ακολουθήσετε ορισμένες βασικές αρχές δοκιμών. Εδώ είναι οι κοινές επτά αρχές δοκιμών που εφαρμόζονται ευρέως στη βιομηχανία λογισμικού.
Για να το καταλάβετε, σκεφτείτε ένα σενάριο όπου μετακινείτε ένα αρχείο από το φάκελο Α στον φάκελο Β.
Σκεφτείτε όλους τους πιθανούς τρόπους με τους οποίους μπορείτε να το δοκιμάσετε.
Εκτός από τα συνηθισμένα σενάρια, μπορείτε επίσης να δοκιμάσετε τις ακόλουθες συνθήκες
- Προσπαθώντας να μετακινήσετε το αρχείο όταν είναι ανοιχτό
- Δεν έχετε τα δικαιώματα ασφαλείας για να επικολλήσετε το αρχείο στο φάκελο B
- Ο φάκελος B βρίσκεται σε κοινόχρηστη μονάδα δίσκου και η χωρητικότητα αποθήκευσης είναι πλήρης.
- Ο φάκελος B έχει ήδη ένα αρχείο με το ίδιο όνομα, στην πραγματικότητα, η λίστα είναι ατελείωτη
- Ή ας υποθέσουμε ότι έχετε 15 πεδία εισαγωγής για δοκιμή, το καθένα με 5 πιθανές τιμές, ο αριθμός των συνδυασμών που θα δοκιμαστούν θα ήταν 5 15
Αν επρόκειτο να δοκιμάσετε ολόκληρους τους πιθανούς συνδυασμούς έργου ΧΡΟΝΟΣ ΕΚΤΕΛΕΣΗΣ & ΚΟΣΤ θα αυξηθούν εκθετικά. Χρειαζόμαστε ορισμένες αρχές και στρατηγικές για τη βελτιστοποίηση της προσπάθειας δοκιμών
Εδώ είναι οι 7 αρχές:
1) Δεν είναι δυνατή η εξαντλητική δοκιμή
Ναί! Δεν είναι δυνατή η εξαντλητική δοκιμή. Αντ 'αυτού, χρειαζόμαστε το βέλτιστο ποσό δοκιμών βάσει της εκτίμησης κινδύνου της εφαρμογής.
Και η ερώτηση εκατομμυρίων δολαρίων είναι, πώς προσδιορίζετε αυτόν τον κίνδυνο;
Για να απαντήσουμε σε αυτό ας κάνουμε μια άσκηση
Κατά τη γνώμη σας, Ποια λειτουργία είναι πιο πιθανό να προκαλέσει αποτυχία του Λειτουργικού σας συστήματος;
Είμαι σίγουρος ότι οι περισσότεροι από εσάς θα μαντέψατε, ανοίγοντας ταυτόχρονα 10 διαφορετικές εφαρμογές.
Επομένως, εάν δοκιμάσατε αυτό το λειτουργικό σύστημα, θα συνειδητοποιήσετε ότι τα ελαττώματα είναι πιθανό να εντοπιστούν σε δραστηριότητα πολλαπλών εργασιών και πρέπει να δοκιμαστούν διεξοδικά, γεγονός που μας φέρνει στην επόμενη αρχή Defect Clustering
2) Συγκέντρωση ελαττωμάτων
Defect Clustering που δηλώνει ότι ένας μικρός αριθμός ενοτήτων περιέχει τα περισσότερα από τα ελαττώματα που εντοπίστηκαν. Αυτή είναι η εφαρμογή της Αρχής Pareto στις δοκιμές λογισμικού: περίπου το 80% των προβλημάτων εντοπίζονται στο 20% των ενοτήτων.
Από εμπειρία, μπορείτε να προσδιορίσετε τέτοιες επικίνδυνες ενότητες. Αλλά αυτή η προσέγγιση έχει τα δικά της προβλήματα
Εάν οι ίδιες δοκιμές επαναλαμβάνονται ξανά και ξανά, τελικά οι ίδιες δοκιμαστικές περιπτώσεις δεν θα βρίσκουν πλέον νέα σφάλματα.
3) Παράδοξο φυτοφαρμάκων
Η επαναλαμβανόμενη χρήση του ίδιου μείγματος φυτοφαρμάκων για την εξάλειψη των εντόμων κατά τη διάρκεια της καλλιέργειας θα οδηγήσει με την πάροδο του χρόνου στα έντομα να αναπτύξουν αντίσταση στο φυτοφάρμακο Επομένως αναποτελεσματικά των φυτοφαρμάκων στα έντομα. Το ίδιο ισχύει και για τις δοκιμές λογισμικού. Εάν πραγματοποιηθεί το ίδιο σύνολο επαναλαμβανόμενων δοκιμών, η μέθοδος θα είναι άχρηστη για την ανακάλυψη νέων ελαττωμάτων.
Για να ξεπεραστεί αυτό, οι δοκιμαστικές περιπτώσεις πρέπει να επανεξετάζονται και να αναθεωρούνται τακτικά, προσθέτοντας νέες & διαφορετικές δοκιμαστικές θήκες για να βρείτε περισσότερα ελαττώματα.
Οι δοκιμαστές δεν μπορούν απλώς να εξαρτώνται από τις υπάρχουσες τεχνικές δοκιμών. Πρέπει να κοιτάζει συνεχώς για να βελτιώσει τις υπάρχουσες μεθόδους για να κάνει τις δοκιμές πιο αποτελεσματικές. Αλλά ακόμη και μετά από αυτόν τον ιδρώτα και τη σκληρή δουλειά στις δοκιμές, δεν μπορείτε ποτέ να ισχυριστείτε ότι το προϊόν σας δεν περιέχει σφάλματα. Για να φτάσουμε στο σπίτι αυτό το σημείο, ας δούμε αυτό το βίντεο της δημόσιας εκκίνησης των Windows 98
Πιστεύετε ότι μια εταιρεία όπως η MICROSOFT δεν θα είχε δοκιμάσει πλήρως το λειτουργικό τους σύστημα και θα διακινδύνευε τη φήμη τους απλώς για να δει το λειτουργικό τους σύστημα να καταρρεύσει κατά τη δημόσια κυκλοφορία του!
4) Ο έλεγχος δείχνει την παρουσία ελαττωμάτων
Ως εκ τούτου, η αρχή της δοκιμής δηλώνει ότι - Ο έλεγχος μιλά για την παρουσία ελαττωμάτων και δεν μιλά για την απουσία ελαττωμάτων. δηλ. Δοκιμή λογισμικού μειώνει την πιθανότητα παραμένουν ανεκάλυπτα ελαττώματα στο λογισμικό, αλλά ακόμη και αν δεν εντοπιστούν ελαττώματα, δεν αποτελεί απόδειξη ορθότητας.
Τι γίνεται όμως, εάν εργάζεστε πολύ σκληρά, λαμβάνοντας όλες τις προφυλάξεις και κάνετε το προϊόν λογισμικού σας 99% χωρίς σφάλματα. Και το λογισμικό δεν ανταποκρίνεται στις ανάγκες και τις απαιτήσεις των πελατών.
Αυτό μας οδηγεί στην επόμενη αρχή μας, η οποία δηλώνει ότι - Απουσία σφάλματος
5) Απουσία σφάλματος - πλάνη
Είναι πιθανό ότι το λογισμικό που είναι 99% χωρίς σφάλματα εξακολουθεί να είναι αχρησιμοποίητο. Αυτό μπορεί να συμβεί εάν το σύστημα έχει ελεγχθεί διεξοδικά για λάθος απαίτηση. Η δοκιμή λογισμικού δεν είναι απλώς η εύρεση ελαττωμάτων, αλλά και ο έλεγχος ότι το λογισμικό καλύπτει τις ανάγκες της επιχείρησης. Η απουσία σφάλματος είναι μια πλάνη, δηλαδή η εύρεση και η διόρθωση ελαττωμάτων δεν βοηθά εάν η κατασκευή του συστήματος είναι άχρηστη και δεν πληροί τις ανάγκες και τις απαιτήσεις του χρήστη.
Για την επίλυση αυτού του προβλήματος, η επόμενη αρχή των δοκιμών δηλώνει ότι το Early Testing
6) Πρώιμη δοκιμή
Πρώιμη δοκιμή - Οι δοκιμές πρέπει να ξεκινήσουν όσο το δυνατόν νωρίτερα στον Κύκλο ζωής ανάπτυξης λογισμικού. Για να εντοπιστούν τυχόν ελαττώματα στις απαιτήσεις ή στη φάση σχεδιασμού σε αρχικά στάδια. Είναι πολύ φθηνότερο να διορθώσετε ένα ελάττωμα στα πρώτα στάδια της δοκιμής. Αλλά πόσο νωρίς πρέπει να ξεκινήσει η δοκιμή; Συνιστάται να αρχίσετε να βρίσκετε το σφάλμα τη στιγμή που καθορίζονται οι απαιτήσεις. Περισσότερα σχετικά με αυτήν την αρχή σε μεταγενέστερο εκπαιδευτικό σεμινάριο.
7) Ο έλεγχος εξαρτάται από το περιβάλλον
Η δοκιμή εξαρτάται από το περιβάλλον που ουσιαστικά σημαίνει ότι ο τρόπος με τον οποίο δοκιμάζετε έναν ιστότοπο ηλεκτρονικού εμπορίου θα είναι διαφορετικός από τον τρόπο με τον οποίο δοκιμάζετε μια διαφήμιση από την εφαρμογή ράφι. Όλα τα ανεπτυγμένα λογισμικά δεν είναι πανομοιότυπα. Μπορείτε να χρησιμοποιήσετε μια διαφορετική προσέγγιση, μεθοδολογίες, τεχνικές και τύπους δοκιμών ανάλογα με τον τύπο της εφαρμογής. Για παράδειγμα δοκιμές, οποιοδήποτε σύστημα POS σε ένα κατάστημα λιανικής θα είναι διαφορετικό από τη δοκιμή ενός μηχανήματος ATM.
Μύθος: "Οι αρχές είναι απλώς για αναφορά. Δεν θα τις χρησιμοποιήσω στην πράξη."
Αυτό είναι πολύ αναληθές. Οι αρχές δοκιμής θα σας βοηθήσουν να δημιουργήσετε μια αποτελεσματική στρατηγική δοκιμών και να σχεδιάσετε λάθη που θα πιάσουν δοκιμαστικές περιπτώσεις.
Αλλά η εκμάθηση των αρχών δοκιμών είναι σαν να μαθαίνεις να οδηγείς για πρώτη φορά.
Αρχικά, ενώ μαθαίνεις να οδηγείς, δίνεις προσοχή σε όλα, όπως αλλαγή ταχυτήτων, ταχύτητα, χειρισμός συμπλέκτη κ.λπ. Με τέτοιο τρόπο που πραγματοποιείτε ακόμη συνομιλίες με άλλους επιβάτες στο αυτοκίνητο.
Το ίδιο ισχύει και για τις αρχές δοκιμής. Οι έμπειροι δοκιμαστές έχουν ενσωματώσει αυτές τις αρχές σε επίπεδο που τις εφαρμόζουν ακόμη και χωρίς σκέψη. Εξ ου και ο μύθος ότι οι αρχές δεν χρησιμοποιούνται στην πράξη δεν είναι αληθινός.