7 Αρχές Δοκιμής Λογισμικού με Παραδείγματα

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

Ας μάθουμε τις αρχές δοκιμών με τα παρακάτω παράδειγμα βίντεο-

Πατήστε εδώ εάν το βίντεο δεν είναι προσβάσιμο

Ιστορικό

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

Για να το κατανοήσετε αυτό, εξετάστε ένα σενάριο όπου μετακινείτε ένα αρχείο από το φάκελο Α στον φάκελο Β.

Σκεφτείτε όλους τους πιθανούς τρόπους με τους οποίους μπορείτε να το δοκιμάσετε.

Εκτός από τα συνηθισμένα σενάρια, μπορείτε επίσης να δοκιμάσετε τις ακόλουθες συνθήκες

• Προσπάθεια μετακίνησης του αρχείου όταν είναι Ανοιχτό
• Δεν έχετε τα δικαιώματα ασφαλείας για να επικολλήσετε το αρχείο στον Φάκελο Β
• Ο φάκελος Β βρίσκεται σε ένα κοινό Drive και η χωρητικότητα αποθήκευσης είναι πλήρης.
• Ο φάκελος Β έχει ήδη ένα αρχείο με το ίδιο όνομα, στην πραγματικότητα, η λίστα είναι ατελείωτη
• Ή ας υποθέσουμε ότι έχετε 15 πεδία εισαγωγής προς δοκιμή, το καθένα έχει 5 πιθανές τιμές, ο αριθμός των συνδυασμών που θα ελεγχθούν θα είναι 5^15

Εάν επρόκειτο να δοκιμάσετε ολόκληρους τους πιθανούς συνδυασμούς του έργου, ο ΧΡΟΝΟΣ ΕΚΤΕΛΕΣΗΣ & ΚΟΣΤΟΣ θα αυξανόταν εκθετικά. Χρειαζόμαστε ορισμένες αρχές και στρατηγικές για τη βελτιστοποίηση της προσπάθειας δοκιμών

Εδώ είναι οι 7 Αρχές:

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

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

Και το ερώτημα εκατομμυρίων δολαρίων είναι, πώς προσδιορίζετε αυτόν τον κίνδυνο;

Για να απαντήσουμε σε αυτό ας κάνουμε μια άσκηση

Κατά τη γνώμη σας, ποια επέμβαση είναι πιο πιθανό να σας προκαλέσει Operaνα αποτύχει το σύστημα;

Είμαι βέβαιος ότι οι περισσότεροι από εσάς θα είχατε μαντέψει, Ανοίγοντας 10 διαφορετικές εφαρμογές ταυτόχρονα.

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

2) Ελάττωμα ClusterING

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

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

Εάν οι ίδιες δοκιμές επαναλαμβάνονται ξανά και ξανά, τελικά οι ίδιες περιπτώσεις δοκιμών δεν θα βρίσκουν πλέον νέα σφάλματα.

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

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

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

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

Νομίζετε ότι μια εταιρεία όπως η MICROSOFT δεν θα είχε δοκιμάσει το λειτουργικό της σύστημα διεξοδικά και θα διακινδύνευε τη φήμη της μόνο και μόνο για να δει το λειτουργικό της σύστημα να καταρρέει κατά τη δημόσια κυκλοφορία του!

4) Η δοκιμή δείχνει παρουσία ελαττωμάτων

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

Τι γίνεται όμως αν, εργάζεστε πολύ σκληρά, λαμβάνοντας όλες τις προφυλάξεις και κάνετε το προϊόν λογισμικού σας 99% χωρίς σφάλματα. Και το λογισμικό δεν ανταποκρίνεται στις ανάγκες & απαιτήσεις των πελατών.

Αυτό μας οδηγεί στην επόμενη αρχή μας, η οποία λέει ότι - Απουσία Σφάλματος

5) Απουσία Σφάλματος – Πλάνη

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

Για την επίλυση αυτού του προβλήματος, η επόμενη αρχή των δοκιμών αναφέρει ότι το Early Testing

6) Πρώιμος έλεγχος

Έγκαιρη δοκιμή – Οι δοκιμές πρέπει να ξεκινούν όσο το δυνατόν νωρίτερα στον Κύκλο Ζωής Ανάπτυξης Λογισμικού. Έτσι ώστε τυχόν ελαττώματα στις απαιτήσεις ή τη φάση σχεδιασμού να αποτυπώνονται σε πρώιμα στάδια. Είναι πολύ φθηνότερο να διορθώσετε ένα ελάττωμα στα αρχικά στάδια της δοκιμής. Πόσο νωρίς όμως πρέπει να ξεκινήσει κανείς τις δοκιμές; Συνιστάται να αρχίσετε να βρίσκετε το σφάλμα τη στιγμή που ορίζονται οι απαιτήσεις. Περισσότερα για αυτήν την αρχή σε επόμενο εκπαιδευτικό σεμινάριο.

7) Η δοκιμή εξαρτάται από το πλαίσιο

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

Μύθος: «Οι αρχές είναι απλώς για αναφορά. Δεν θα τα χρησιμοποιήσω στην πράξη».

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

Αλλά η εκμάθηση των αρχών δοκιμών είναι ακριβώς σαν να μαθαίνεις να οδηγείς για πρώτη φορά.

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

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