Μενού

Τι είναι ο αυξητικός έλεγχος: Λεπτομερής επεξήγηση με παραδείγματα

what is incremental testing

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

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

Μέχρι το τέλος αυτής της ενότητας, το κοινό θα έχει δίκαιη γνώση ότι ακολουθεί:

  • Τι είναι ο αυξητικός έλεγχος;
  • Ο στόχος του
  • Μεθοδολογίες
  • Πλεονεκτήματα
  • Μειονεκτήματα

Τι θα μάθετε:

Τι είναι ο αυξητικός έλεγχος

Το Incremental Testing, επίσης γνωστό ως Incremental Integration Testing, είναι μια από τις προσεγγίσεις του Integration Testing και ενσωματώνει τις θεμελιώδεις έννοιες του.

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

Αυξητικός έλεγχος

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

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

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

Παράδειγμα

Ας κατανοήσουμε αυτήν την έννοια με ένα παράδειγμα:

Η εφαρμογή συστήματος ή λογισμικού αποτελείται από τις ακόλουθες ενότητες:

Εφαρμογή λογισμικού

Προσθετική προσέγγιση δοκιμής ολοκλήρωσης

  • Κάθε Ενότητα, δηλαδή M1, M2, M3, κ.λπ. δοκιμάζεται ξεχωριστά ως μέρος της δοκιμής μονάδας
  • Οι ενότητες συνδυάζονται σταδιακά, δηλαδή ένα προς ένα και δοκιμάζονται για επιτυχή αλληλεπίδραση
  • Στο Σχ. 2, η Ενότητα M1 & η Ενότητα M2 συνδυάζονται και δοκιμάζονται
  • Στο Σχ.3, προστίθεται και δοκιμάζεται η Ενότητα Μ3
  • Στο Σχ. 4, προστίθεται η Ενότητα M4 και πραγματοποιούνται δοκιμές για να διασφαλιστεί ότι όλα λειτουργούν μαζί με επιτυχία
  • Οι υπόλοιπες ενότητες προστίθενται επίσης σταδιακά σε κάθε βήμα και δοκιμάζονται για επιτυχημένη ενσωμάτωση

Εικ. 2

Συνδυασμένες δύο ενότητες

Εικ. 3

Συνδυασμένες 3 Ενότητες

πώς να ρυθμίσετε το junit σε έκλειψη

Εικ. 4

Συνδυασμένες τέσσερις ενότητες

Στόχος της σταδιακής δοκιμής

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

Μεθοδολογίες δοκιμαστικής ενσωμάτωσης

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

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

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

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

Μια ερώτηση που μπορεί να προκύψει σε μερικούς από εμάς είναι γιατί να μην περιμένετε έως ότου αναπτυχθούν όλες οι λειτουργικές μονάδες αντί να χρησιμοποιήσετε stub / driver πριν ξεκινήσετε τη δοκιμή;

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

Τώρα που έχουμε καλύψει Stubs και προγράμματα οδήγησης, ας προχωρήσουμε διαφορετικές μεθοδολογίες αυξητικής δοκιμής:

# 1) Πάνω προς τα κάτω

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

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

Ας το καταλάβουμε με ένα παράδειγμα:

  • Μονάδα μέτρησης : Σύνδεση ιστότοπου aka L
  • Μονάδα μέτρησης : Παραγγελία aka O
    • Σύνοψη παραγγελίας ενότητας aka OS (Δεν έχει ακόμη αναπτυχθεί)
  • Μονάδα μέτρησης : Πληρωμή aka P
    • Ενότητα Πληρωμή μετρητών aka CP
    • Ενότητα Χρεωστική / Πιστωτική Πληρωμή γνωστή ως DP (Δεν έχει ακόμη αναπτυχθεί)
    • Module Wallet Payment aka WP (Δεν έχει ακόμη αναπτυχθεί)
  • Μονάδα μέτρησης: Αναφορά aka R (Δεν έχει ακόμη αναπτυχθεί)

Προσέγγιση από πάνω προς τα κάτω

Προσέγγιση δοκιμαστικής ενσωμάτωσης από πάνω προς τα κάτω

Θα προκύψουν οι ακόλουθες δοκιμαστικές περιπτώσεις:

Περίπτωση δοκιμής 1: Οι μονάδες L και Module O θα ενσωματωθούν και θα δοκιμαστούν
Περίπτωση δοκιμής 2: Οι ενότητες L, O και P θα ενσωματωθούν και θα δοκιμαστούν
Περίπτωση δοκιμής 3: Οι ενότητες L, O, P και R θα ενσωματωθούν και θα δοκιμαστούν.

Και ούτω καθεξής προκύπτουν και άλλες δοκιμαστικές περιπτώσεις.

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

Οι ακόλουθες δοκιμαστικές περιπτώσεις θα προκύψουν για το «βάθος-πρώτο»:

Περίπτωση δοκιμής 1: Οι μονάδες L και Module O θα ενσωματωθούν και θα δοκιμαστούν
Περίπτωση δοκιμής 2: Οι μονάδες L, O και OS θα ενσωματωθούν και θα δοκιμαστούν
Περίπτωση δοκιμής 3: Οι ενότητες L, O, OS, P θα ενσωματωθούν και θα δοκιμαστούν
Περίπτωση δοκιμής 4: Οι ενότητες L, O, OS, P, CP θα ενσωματωθούν και θα δοκιμαστούν

Και ούτω καθεξής προκύπτουν και άλλες δοκιμαστικές περιπτώσεις.

Τα πλεονεκτήματα της μεθοδολογίας από πάνω προς τα κάτω

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

Μειονεκτήματα της μεθοδολογίας από πάνω προς τα κάτω

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

# 2) Από κάτω προς τα πάνω

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

Ας δούμε ένα παρακάτω παράδειγμα για καλύτερη κατανόηση:

Οι ενότητες Κατάταξη, Βαθμοί, Ποσοστό και Αθλητικός Βαθμός δεν έχουν αναπτυχθεί ακόμη και θα αντικατασταθούν με σχετικό Πρόγραμμα οδήγησης:

Προσέγγιση από κάτω προς τα πάνω

Προσέγγιση δοκιμαστικής ολοκλήρωσης από κάτω προς τα πάνω

Θα προκύψουν οι ακόλουθες δοκιμαστικές περιπτώσεις:

char στη συμβολοσειρά c ++

Περίπτωση δοκιμής 1: Μονάδα δοκιμής ενότητας Πρακτική και Θεωρία
Περίπτωση δοκιμής 2: Ενσωμάτωση και δοκιμή ενότητας Marks-Practical-θεωρία
Περίπτωση δοκιμής : Ενσωμάτωση και δοκιμή ενότητας Ποσοστά-Σημεία-Πρακτική-Θεωρία
Περίπτωση δοκιμής 4: Μονάδα δοκιμής Module Sports Grade
Περίπτωση δοκιμής 5: Ενσωμάτωση και δοκιμή ενότητας Rank-Sports Grade-Percentage-Marks-Practical-Theory

Τα πλεονεκτήματα της μεθοδολογίας από κάτω προς τα πάνω

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

Μειονεκτήματα της μεθοδολογίας από κάτω προς τα πάνω

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

# 3) Δοκιμή σάντουιτς

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

Προσέγγιση δοκιμών

  • Προσδιορίζεται ένα μεσαίο στρώμα από το οποίο πραγματοποιούνται δοκιμές από πάνω προς τα πάνω και από πάνω προς τα κάτω. Αυτό το μεσαίο στρώμα είναι επίσης γνωστό ως στρώμα στόχος
  • Το επίπεδο στόχου προσδιορίζεται σύμφωνα με τη Heuristic προσέγγιση, δηλαδή επιλέξτε ένα επίπεδο που επιτρέπει την ελάχιστη χρήση των Stubs και των προγραμμάτων οδήγησης
  • Η δοκιμή από πάνω προς τα κάτω ξεκινά από το μεσαίο στρώμα και κινείται προς τα κάτω προς τις μονάδες χαμηλότερου επιπέδου. Αυτό το στρώμα κάτω από το μεσαίο στρώμα είναι γνωστό ως κάτω στρώμα
  • Οι δοκιμές από κάτω προς τα πάνω ξεκινούν επίσης από το μεσαίο στρώμα και ανεβαίνουν προς τα πάνω σε μονάδες ανώτερου επιπέδου. Αυτό το στρώμα πάνω από το μεσαίο στρώμα είναι γνωστό ως Top layer
  • Με τη χρήση stubs και προγραμμάτων οδήγησης, το περιβάλλον εργασίας χρήστη και οι λειτουργίες των μονάδων χαμηλότερου επιπέδου δοκιμάζονται αντίστοιχα
  • Στο τέλος, απομένει μόνο το μεσαίο στρώμα για την εκτέλεση του τελικού τεστ

Παράδειγμα:

Παράδειγμα δοκιμής σάντουιτς

Οι ακόλουθες περιπτώσεις δοκιμής μπορούν να προκύψουν με τη στρατηγική δοκιμής σάντουιτς:

Περίπτωση δοκιμής 1: Δοκιμή A, X, Y και Z ξεχωριστά - όπου η δοκιμή A εμπίπτει στη δοκιμή ανώτερου επιπέδου και η δοκιμή X, Y και Z υπόκειται σε δοκιμές κατώτατου επιπέδου
Περίπτωση δοκιμής 2: Δοκιμή A, G, H και I
Περίπτωση δοκιμής 3: Δοκιμή G, X και Y
Περίπτωση δοκιμής 4: Δοκιμή χεριού Z
Περίπτωση δοκιμής 5: Δοκιμή A, G, H, I, X, Y και Z

Αξίες της μεθοδολογίας δοκιμής σάντουιτς

  • Είναι πολύ ευεργετικό για ένα μεγάλο έργο που έχει διάφορα επιμέρους έργα
  • Η μεθοδολογία δοκιμών από πάνω προς τα κάτω και από κάτω προς τα πάνω μπορεί να εκτελεστεί δίπλα-δίπλα

Μειονεκτήματα της μεθοδολογίας δοκιμής σάντουιτς

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

συμπέρασμα

Το Incremental Testing εμπίπτει στην κουβέρτα του Integration testing. Σε αυτήν την προσέγγιση δοκιμών, ο έλεγχος ολοκλήρωσης γίνεται σε μεμονωμένη ενότητα ως μέρος της δοκιμής μονάδας και στην επόμενη φάση, οι ενότητες ή τα συστατικά της εφαρμογής ενσωματώνονται σταδιακά και ο έλεγχος πραγματοποιείται σε συνδυασμένες ενότητες ως ομάδα.

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

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

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

Αξίες:

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

Οφέλη:

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

Για το συντάκτης: Αυτό το χρήσιμο σεμινάριο είναι γραμμένο από τη Neha B. Είναι πιστοποιημένη με τον ISTQB Αναλυτή Ποιότητας με 8+ χρόνια εμπειρίας.

Ενημερώστε μας εάν έχετε οποιεσδήποτε ερωτήσεις / προτάσεις.

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

^