Μενού

Tutorial Structural Testing - Τι είναι η δομική δοκιμή

structural testing tutorial what is structural testing

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

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

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

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

Δομικές δοκιμές

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

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

Αυτό το σεμινάριο εξηγεί επίσης τους τύπους δομικών δοκιμών. Μάθετε πώς μπορείτε να κάνετε το Mutation Testing, το Slice Based Test, το Data Flow Testing λεπτομερώς με παραδείγματα και εξηγήσεις.

Τι θα μάθετε:

Γιατί είναι σημαντική η δοκιμή λογισμικού

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

Παρατίθενται παρακάτω είναι μερικοί λόγοι:

# 1) Για να διασφαλιστεί ότι πληρούνται οι προβλεπόμενες απαιτήσεις πριν αρχίσετε να χτίζετε ένα έργο. Τα ενδιαφερόμενα μέρη (για παράδειγμα, προγραμματιστές και πελάτες) πρέπει να συμφωνήσουν για όλες τις πτυχές της λύσης / προϊόντος / λογισμικού που απαιτούνται για την κατασκευή ενός έργου.

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

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

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

# 4) Βοηθά στην επίτευξη καλύτερης εμπειρίας χρήστη. Οι χρήστες δεν θα απολαύσουν τη χρήση λογισμικού που παρουσιάζει δυσλειτουργία, με λάθη ή 'πολύ αργό'. Οι χρήστες πιθανότατα θα είναι ανυπόμονοι και θα εγκαταλείψουν τη χρήση του λογισμικού. Η δοκιμή μας δίνει μια καλύτερη εικόνα για να διασφαλίσουμε ότι οι χρήστες μπορούν να χρησιμοποιούν εύκολα τα προϊόντα μας.

# 5) Ελέγχει για δυνατότητα κλιμάκωσης. Ένας προγραμματιστής πρέπει να στοχεύει στη δημιουργία λογισμικού που μπορεί να κλιμακωθεί.

# 6) Ελέγχει για ευπάθειες στον κώδικα. Η δοκιμή μας δίνει την ευκαιρία να αναζητήσουμε ευπάθειες ασφαλείας, Για παράδειγμα, κώδικα που μπορεί να θέσει σε κίνδυνο PII (Προσωπικά αναγνωρίσιμες πληροφορίες) που αποτελεί υψηλή προτεραιότητα για τον GDPR.

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

Δομικές δοκιμές εναντίον άλλων τύπων δοκιμών

Υπάρχουν πολλοί τύποι δοκιμών λογισμικού. Ωστόσο, το ΝΑ ΣΤΑΜΑΤΗΣΕΙ (International Software Testing Qualifications Board), ορίζει 4 βασικούς τύπους δοκιμών λογισμικού, δηλαδή

  • Λειτουργικός
  • Μη λειτουργικο
  • Κατασκευαστικός
  • Βάσει αλλαγών

Οι διαφορές μπορούν να εξηγηθούν ως εξής:

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

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

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

Ας υποθέσουμε ότι πρέπει να ελέγξουμε εάν έχουμε ορίσει τον κωδικό που διαφοροποιεί τους ζυγούς αριθμούς από τους περίεργους αριθμούς. Ενδέχεται να έχουμε μια υπό όρους δήλωση εδώ, όπως, εάν ένα στοιχείο πίνακα διαιρείται με δύο χωρίς υπόλοιπο, εάν (arr (i)% 2 === 0) τότε ο αριθμός μπορεί να λεχθεί ως ζυγός αριθμός.

Οι δομικές δοκιμές πραγματοποιούνται από τους ίδιους ανθρώπους που γράφουν τον κώδικα όπως τον καταλαβαίνουν καλύτερα.

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

Τι δεν είναι η δομική δοκιμή

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

Τι είναι η δομική δοκιμή

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

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

Τρόπος διεξαγωγής δομικών δοκιμών

Για να δοκιμάσουμε διαφορετικές πτυχές του κώδικα, πρέπει πρώτα να κατανοήσουμε τις ροές ελέγχου.

Έλεγχος ροής ελέγχου

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

Διαδικασία ελέγχου ροής ελέγχου:

Γράφημα ροής ελέγχου

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

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

Ας δούμε αυτά τα στοιχεία παρακάτω:

Κόμβοι και άκρα

# 1) Μπλοκ διαδικασίας

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

Παράδειγμα μπλοκ διαδικασίας:

Διαδικασία μπλοκ

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

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

# 2) Σημεία απόφασης

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

Η απόφαση που λαμβάνεται εδώ θα μπορούσε να είναι δηλώσεις υπό όρους, όπως δηλώσεις if-else (που έχουν δύο πιθανές εξόδους) και δηλώσεις περιπτώσεων (που μπορούν να έχουν περισσότερες από δύο εξόδους).

CFG

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

Στο παραπάνω διάγραμμα, υπάρχει ένα σημείο απόφασης (από την υπό όρους «ηλικία = 18») που ακολουθείται από τις επιλογές «ναι» ή «όχι».

# 3) Σημεία διασταύρωσης

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

Βέλτιστες πρακτικές γραφημάτων ροής ελέγχου:

Υπάρχουν μερικά πράγματα που πρέπει να σημειωθούν κατά την κατασκευή γραφημάτων ροής ελέγχου:

  • Δοκιμάστε όσο το δυνατόν περισσότερο για να διατηρήσετε το CFG απλό. Μπορούμε να το κάνουμε αυτό συνδυάζοντας μέρη που μπορεί να θεωρηθούν «λιγότερο σημαντικά», για παράδειγμα, μπλοκ διαδικασίας.
  • Βεβαιωθείτε ότι στα σημεία απόφασης λαμβάνεται μόνο μία απόφαση. Σε πιο πολύπλοκες CFG, υπάρχουν «συνέπειες» που προκύπτουν μετά τη λήψη της απόφασης. Στο παραπάνω παράδειγμά μας, θα μπορούσαμε επίσης να προσθέσουμε ότι εάν ένα άτομο είναι 18 ετών και άνω, τότε είναι επιλέξιμο και πρέπει να πληρώσει για ένα εισιτήριο. Εάν δεν είναι, τότε η είσοδος είναι δωρεάν. Η απόφαση «αλλού» πρέπει να «παραλείψει» μερικούς κόμβους και όλα αυτά τα βήματα πρέπει να εμφανίζονται στο CFG μας.

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

Καθορισμός της δοκιμής:

Πόσο από τον πηγαίο κώδικα πρέπει να δοκιμαστεί; Πρέπει να δοκιμάσουμε κάθε πιθανό μονοπάτι; Η προσπάθεια κάλυψης όλων των διαδρομών στις δοκιμές μας είναι πρακτικά αδύνατη. Πρέπει να βρούμε ένα μέσο για να καθορίσουμε πόσες δοκιμές μπορούμε να κάνουμε.

πώς να εκτελέσετε αρχεία .bin

Εάν λέμε ότι στοχεύουμε στη δοκιμή του 50% του κώδικα μας, τότε αυτό θα μπορούσε να σημαίνει ότι θα ορίσουμε όλες τις εκτελέσιμες δηλώσεις κώδικα και θα στοχεύσουμε στη δοκιμή τουλάχιστον των μισών από αυτές. Ωστόσο, το ερώτημα που προκύπτει εδώ είναι «πρέπει λοιπόν να καθορίσουμε όλες τις πιθανές εκτελέσιμες διαδρομές;»

Αυτό και πάλι μπορεί να είναι πρακτικά αδύνατο. Μια καλύτερη προσέγγιση μπορεί να στοχεύει στη δοκιμή του 50% των διαδρομών που μπορούμε να προσδιορίσουμε σε κάθε ενότητα του κώδικα.

Υπάρχουν διαφορετικά επίπεδα κάλυψης, δηλαδή κάλυψη δήλωσης, κλάδου και διαδρομής. Θα τα εξετάσουμε εν συντομία αργότερα.

Δημιουργία δοκιμαστικών περιπτώσεων:

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

  • Οι εκτελέσιμες δηλώσεις.
  • Οι «αποφάσεις» που πρέπει να ληφθούν.
  • Οι πιθανές διαδρομές που μπορούν να ακολουθηθούν.
  • Οι προϋποθέσεις που πρέπει να πληρούνται (αυτές μπορεί να είναι πολλαπλές ή δυαδικές).

Οι παραπάνω παράγοντες μας δίνουν μια ιδέα για τους τύπους δοκιμαστικών περιπτώσεων που πρέπει να δημιουργήσουμε. Μπορούμε επίσης να χρησιμοποιήσουμε ένα εργαλείο δημιουργίας δομικών δοκιμών. Εάν ο κώδικάς μας είναι στη γλώσσα προγραμματισμού C, μπορούμε να χρησιμοποιήσουμε το PathCrawler για να δημιουργήσουμε δοκιμαστικό κώδικα. Ένα άλλο εργαλείο που μπορούμε να χρησιμοποιήσουμε είναι το fMBT.

Εκτέλεση των δοκιμαστικών περιπτώσεων:

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

Ανάλυση των αποτελεσμάτων:

Σε αυτό το μέρος, το μόνο που κάνουμε είναι να ελέγξουμε εάν έχουμε τα σωστά αποτελέσματα μετά την εκτέλεση. Για παράδειγμα, εάν εισαγάγουμε έναν πίνακα όπου όλες οι τιμές είναι πάνω από 18, τότε θα πρέπει να έχουμε όλα τα σημεία απόφασης με αποτέλεσμα «επιλέξιμο».

Έλεγχος Παραδοχών Ροής

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

  • Τα μόνα σφάλματα που υπάρχουν είναι αυτά που μπορούν να επηρεάσουν τη ροή ελέγχου.
  • Όλες οι μεταβλητές, οι συναρτήσεις και τα στοιχεία ορίζονται με ακρίβεια.

Επίπεδα κάλυψης στις ροές ελέγχου

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

Ας τα δούμε εν συντομία.

# 1) Κάλυψη δήλωσης

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

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

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

# 2) Κάλυψη υποκαταστήματος

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

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

# 3) Κάλυψη διαδρομής

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

Τύποι δομικών δοκιμών

Τύποι δομικών δοκιμών
(εικόνα πηγή )

Δοκιμή μετάλλαξης

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

>> Ανατρέξτε σε αυτό το σεμινάριο για μια αναλυτική ματιά Δοκιμή μετάλλαξης.

Δοκιμή βασισμένη σε φέτες

Το Slice Based Testing (SBT) μπορεί να οριστεί ως μια τεχνική δοκιμής λογισμικού που βασίζεται φέτες - εκτελέσιμα μέρη του προγράμματος ή ομάδες δηλώσεων που επηρεάζουν ορισμένες τιμές σε συγκεκριμένα σημεία ενδιαφέροντος του προγράμματος, για παράδειγμα, μέρη όπου ορίζονται μεταβλητές ή η έξοδος μιας ομάδας δηλώσεων.

Πώς να κάνετε φέτες

Παράδειγμα τεμαχισμού στο SBT: Κωδικός για εκτύπωση ομοιόμορφων και μονών αριθμών (Python)

num_list = range(1,12) even_nums = () odd_nums = () for var in num_list: if var%2==0: even_nums.append(var) print(f'Even numbers: {even_nums}') elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')

Δοκιμή βασισμένη σε φέτες

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

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

Στα κριτήρια τεμαχισμού που δίνονται από τον Mark Weiser (ο οποίος εισήγαγε το SBT), ένα slice ορίζεται χρησιμοποιώντας αυτόν τον τύπο: S (v, n) , που, β αναφέρεται στην εν λόγω μεταβλητή ( για παράδειγμα, όπου ορίζεται μια μεταβλητή), και ν είναι η δήλωση ενδιαφέροντος ( για παράδειγμα, όπου δίνεται η έξοδος), και μικρό σημαίνει τη φέτα.

Στο παραπάνω παράδειγμα, για να πάρουμε το slice, ξεκινάμε από την παραγωγή μας στη γραμμή 10, η οποία γίνεται δική μας ν . Η μεταβλητή μας είναι που .

Έτσι, τα κριτήρια κοπής μας είναι:

S(v,n) = S(var,10)

Η ανησυχία μας είναι οι δηλώσεις που μας οδηγούν στο αποτέλεσμα.

Αυτά είναι:
10,9,8,4,3,1

Έτσι, το κομμάτι μας σε αυτόν τον κώδικα είναι:

num_list = range(1,12) odd_nums = () for var in num_list: elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')

SBTSlice

Τύποι δοκιμών βάσει φετών

Υπάρχουν δύο τύποι SBT: Στατικός και δυναμικός

# 1) Δυναμική δοκιμή βασισμένη σε φέτες

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

Εκτελούμε τον κώδικα και χρησιμοποιούμε δεδομένα δοκιμών για να διασφαλίσουμε ότι λειτουργεί όπως θα έπρεπε. Θα μπορούσαμε να αυξήσουμε το εύρος στο εύρος (1,50), για παράδειγμα, για να δείτε αν εξακολουθεί να παράγει μόνο περίεργους αριθμούς. Το Dynamic SBT είναι επίσης γνωστό ως δοκιμή επικύρωσης.

# 2) ΣτατικόςΔοκιμή βασισμένη σε φέτες

Σε αντίθεση με το Dynamic SBT, η εστίαση των στατικών δοκιμών είναι σε μια συγκεκριμένη μεταβλητή. Εάν σκεφτούμε την παραγωγή μας στο παραπάνω παράδειγμα ως που , μπορούμε να εντοπίσουμε τη φέτα που την επηρεάζει 10,9,8,7,6,5,4,3,2,1

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

Είναι σημαντικό να σημειωθεί ότι το δυναμικό SBT είναι «μικρότερο» σε σύγκριση με το στατικό αντίστοιχό του. Είναι επίσης πιο συγκεκριμένο.

Βέλτιστες πρακτικές / οδηγίες δοκιμής με βάση το Slice

Τα κριτήρια τεμαχισμού πρέπει να καθορίζονται από:

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

Τα πλεονεκτήματα των δοκιμών που βασίζονται σε φέτες περιλαμβάνουν:

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

Τα μειονεκτήματα των δοκιμών που βασίζονται σε φέτες περιλαμβάνουν:

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

Δοκιμή ροής δεδομένων

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

Ανωμαλίες ροής δεδομένων

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

Ας δούμε παρακάτω:

Τύπος 1: Μια μεταβλητή ορίζεται και μια τιμή εκχωρείται σε αυτήν δύο φορές.

Παράδειγμα κώδικα: Python

lst_1 = (1,2,3,4) lst_1 = (5,6,7,8) for var in lst_1: print(var)

Τύπος1

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

Τύπος 2: Η τιμή μιας μεταβλητής χρησιμοποιείται ή αναφέρεται πριν οριστεί.

Παράδειγμα κώδικα: Python

for var in lst_1: print(var)

Τύπος 2

Ο παραπάνω βρόχος δεν έχει τιμές για επανάληψη. Οι ανωμαλίες τύπου 2 προκαλούν την αποτυχία του προγράμματος.

Τύπος 3: Α Η τιμή δεδομένων δημιουργείται, αλλά δεν χρησιμοποιείται ποτέ.

Παράδειγμα κώδικα: Python

lst_1 = (1,2,3,4) lst_2 = (5,6,7,8) for var in lst_1: print(var)

Τύπος 3

Η μεταβλητή lst_2 δεν έχει αναφερθεί. Οι ανωμαλίες τύπου 3 ενδέχεται να μην προκαλέσουν αποτυχία του προγράμματος.

Διαδικασία δοκιμής ροής δεδομένων

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

Βήμα 1) Σχεδιάστε ένα γράφημα ροής ελέγχου

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

Παράδειγμα κώδικα: Python

cost = 20 y = int(input('How many visitor seats did you reserve? ')) x = int(input('How many member seats did you reserve? ')) if y>x: bill = cost -1 else: bill = cost print(bill)

Δοκιμή ροής δεδομένων

Στο παραπάνω παράδειγμα κώδικα, ένα μέλος θα πρέπει να λάβει έκπτωση εάν προσκαλέσει έναν επισκέπτη.

Γράφημα ροής ελέγχου (CFG):

Γράφημα ροής ελέγχου

Βήμα 2) Εξερευνήστε τον ορισμό και τη χρήση μεταβλητών και τιμών δεδομένων.

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

Εάν λάβουμε υπόψη το μεταβλητό κόστος σε CFG, αυτοί είναι οι κόμβοι καθορισμού και χρήσης:

ΚόμβοςΤύποςΚώδικας
1 Καθορισμός κόμβουκόστος = 20
5 Κόμβος χρήσηςλογαριασμός = κόστος -1
7 Κόμβος χρήσηςλογαριασμός = κόστος

Βήμα # 3) Ορίστε διαδρομές ορισμού-χρήσης.

Υπάρχουν δύο τύποι διαδρομών ορισμού-χρήσης: du paths και dc paths. du paths είναι διαδρομές ορισμού που ξεκινούν με έναν κόμβο ορισμού και τελειώνουν με έναν κόμβο χρήσης. Αυτό ισχύει για τη διαδρομή σε σχέση με το παραπάνω μεταβλητό κόστος.

Ένα παράδειγμα μιας διαδρομής dc, μιας διαδρομής σαφής απόφασης, είναι η διαδρομή όσον αφορά τη μεταβλητή λογαριασμού όπως παρακάτω:

ΚόμβοςΤύποςΚώδικας
5 Καθορισμός κόμβουλογαριασμός = κόστος -1
7 Καθορισμός κόμβουλογαριασμός = κόστος
8 Κόμβος χρήσηςεκτύπωση (λογαριασμός)

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

Βήμα # 4) Δημιουργήστε τη δοκιμαστική σουίτα.

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

Τύποι δοκιμής ροής δεδομένων

Υπάρχουν δύο τύποι - Στατικό και δυναμικό .

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

Πλεονεκτήματα και μειονεκτήματα της δοκιμής ροής δεδομένων:

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

Πλεονεκτήματα και μειονεκτήματα των δομικών δοκιμών

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

Πλεονεκτήματα:

  • Επιτρέπει διεξοδική δοκιμή κώδικα, με αποτέλεσμα ελάχιστα σφάλματα. Οι δοκιμές βάσει δομής παρέχουν χώρο για έλεγχο του λογισμικού. Τα διαφορετικά επίπεδα κάλυψης - δήλωση με δήλωση, κάθε σημείο απόφασης και διαδρομή στοχεύουν στην επίτευξη κάλυψης 100%, η οποία μειώνει σημαντικά τις πιθανότητες σφαλμάτων να μην εντοπιστούν.
  • Η ικανότητα αυτοματοποίησης . Υπάρχουν πολλά εργαλεία που μπορούμε να χρησιμοποιήσουμε για την αυτοματοποίηση των δοκιμών. Αυτό θα μας βοηθήσει να επιτύχουμε τη μέγιστη κάλυψη κώδικα και σε μικρότερο χρονικό διάστημα σε σύγκριση με τη μη αυτόματη δοκιμή.
  • Καταλήγει σε κώδικα υψηλότερης ποιότητας . Οι προγραμματιστές έχουν την ευκαιρία να μελετήσουν τη δομή και την εφαρμογή του κώδικα και να διορθώσουν τυχόν σφάλματα, καθώς και να βελτιώσουν αυτές τις πτυχές. Μας επιτρέπει να έχουμε κατά νου τη μεγάλη δομή καθώς γράφουμε επόμενα μέρη κώδικα ή εφαρμόζουμε τις υπόλοιπες λειτουργίες.
  • Μπορεί να γίνει σε κάθε φάση του SDLC - Οι δομικές δοκιμές μπορούν να γίνουν σε κάθε φάση του SDLC χωρίς να περιμένετε να ολοκληρωθεί η ανάπτυξη 100%. Αυτό καθιστά εύκολο τον εντοπισμό σφαλμάτων σε πρώιμη φάση και έτσι εξοικονομείτε πολύ χρόνο σε σύγκριση με τις δοκιμές μετά την ολοκλήρωση της ανάπτυξης.
  • Βοηθά να απαλλαγούμε από τον νεκρό κώδικα . Αυτό μπορεί να θεωρηθεί ως «επιπλέον» ή περιττός κωδικός, για παράδειγμα, κωδικός που θα υπολογίσει ένα αποτέλεσμα αλλά δεν θα το χρησιμοποιήσει ποτέ σε κανέναν από τους παρακάτω υπολογισμούς.
  • Αποδοτικότητα - Δεδομένου ότι οι προγραμματιστές που γράφουν τον κώδικα είναι οι ίδιοι που τον δοκιμάζουν, δεν χρειάζεται να εμπλέκονται άλλα άτομα όπως τα QA.

Μειονεκτήματα:

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

Βέλτιστες πρακτικές δομικών δοκιμών

Μερικοί από τους παράγοντες που απαιτούν προσοχή κατά τη διεξαγωγή δοκιμών βάσει δομής είναι οι εξής:

  • Σαφή ετικέτα και ονομάστε τις δοκιμές . Εάν κάποιος άλλος πρέπει να εκτελέσει τις δοκιμές, πρέπει να είναι σε θέση να τους εντοπίσει εύκολα.
  • Πριν βελτιώσετε τον κώδικα, δηλαδή με την αναδιαμόρφωση του και τη βελτιστοποίηση για χρήση σε διαφορετικά περιβάλλοντα, βεβαιωθείτε ότι η δομή και η ροή του είναι ιδανικές.
  • Εκτελέστε τις δοκιμές ξεχωριστά . Με αυτόν τον τρόπο, είναι εύκολο να εντοπίσετε σφάλματα και να τα διορθώσετε. Από την άλλη πλευρά, είναι λιγότερο πιθανό να χάσουμε σφάλματα ή διαδρομές ως αποτέλεσμα επικαλύψεων σε ενότητες κώδικα, μπλοκ ή διαδρομές.
  • Δημιουργήστε δοκιμές πριν κάνετε αλλαγές . Οι δοκιμές πρέπει να εκτελεστούν όπως αναμενόταν. Με αυτόν τον τρόπο, εάν κάτι σπάσει, τότε είναι εύκολο να εντοπιστεί και να διορθωθεί το πρόβλημα.
  • Κρατήστε ξεχωριστά τις δοκιμές για κάθε ενότητα ή μπλοκ κώδικα . Με αυτόν τον τρόπο, εάν υπάρχουν αλλαγές στη γραμμή, δεν χρειάζεται να αλλάξουμε πολλές δοκιμές.
  • Διορθώστε σφάλματα πριν προχωρήσετε με δοκιμές . Εάν εντοπίσουμε σφάλματα, καλύτερα να τα διορθώσουμε πριν προχωρήσουμε στη δοκιμή της επόμενης ενότητας ή του μπλοκ κώδικα.
  • Ποτέ μην παραλείπετε τις δομικές δοκιμές με την υπόθεση ότι ένα QA «θα κάνει ακόμα δοκιμές ούτως ή άλλως». Ακόμα κι αν τα σφάλματα ενδέχεται να φαίνονται ασήμαντα στην αρχή, αθροιστικά, μπορούν να οδηγήσουν σε κώδικα λάθη που δεν μπορεί ποτέ να επιτύχει τον επιδιωκόμενο σκοπό του.

Συχνές ερωτήσεις για δοκιμές βάσει δομής

Εδώ θα διερευνήσουμε τις συχνές ερωτήσεις όσον αφορά τις δοκιμές βάσει δομών.

Q # 1) Ποια είναι η διαφορά μεταξύ λειτουργικών δοκιμών και δομικών δοκιμών;

Απάντηση: Η λειτουργική δοκιμή είναι ένας τύπος δοκιμών λογισμικού που βασίζεται σε καθορισμένες απαιτήσεις στο SRS (Προδιαγραφές Απαιτήσεων Λογισμικού). Συνήθως γίνεται σε μια προσπάθεια να βρεθούν διαφορές μεταξύ των προδιαγραφών στο SRS και του τρόπου λειτουργίας του κώδικα. Οι δομικές δοκιμές βασίζονται στην εσωτερική δομή του κώδικα και στην εφαρμογή του. Απαιτείται διεξοδική κατανόηση του κώδικα.

Q # 2) Ποιοι είναι οι τύποι δομικών δοκιμών;

Απάντα το οι τύποι περιλαμβάνουν:

  • Δοκιμή ροής δεδομένων
  • Δοκιμή μετάλλαξης
  • Έλεγχος ροής ελέγχου
  • Δοκιμή βασισμένη σε φέτες

Q # 3) Τι είναι ένα δομικό παράδειγμα δοκιμών;

Απάντηση: Εδώ είναι ένα παράδειγμα που δείχνει κάλυψη δήλωσης:

const addNums = (num) => { let sum = num.reduce ((a,b) => a+b); if (sum > 0) { alert(sum); } else { alert(‘please enter positive numbers’); } }; addNums();

Το ποσό κάλυψης που λαμβάνουμε εξαρτάται από τα δεδομένα δοκιμής που παρέχουμε ως είσοδος (εάν πληροί το άθροισμα> 0 προϋποθέσεις).

Q # 4) Ποια είναι η διαφορά μεταξύ δοκιμής ροής δεδομένων και ελέγχου ροής ελέγχου;

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

Ε # 5) Σε τι χρησιμοποιείται η δοκιμή ροής δεδομένων;

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

Q # 6) Ποια είναι η διαφορά μεταξύ του τεμαχισμού και του τεμαχισμού στις δοκιμές λογισμικού;

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

Q # 7) Ποια είναι η διαφορά μεταξύ δοκιμών μετάλλαξης και κάλυψης κώδικα;

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

συμπέρασμα

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

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

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

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

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

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

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

^