Μενού

Τι είναι ο Έλεγχος Ενσωμάτωσης (Tutorial with Integration Test παράδειγμα)

what is integration testing

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

Τι είναι ο έλεγχος ενοποίησης: Μάθετε με παραδείγματα δοκιμών ενοποίησης

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

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

Λίστα μαθημάτων που καλύπτονται σε αυτήν τη σειρά:

Εκμάθηση # 1: Τι είναι ο έλεγχος ολοκλήρωσης; (Αυτό το σεμινάριο)
Εκμάθηση # 2: Τι είναι ο αυξητικός έλεγχος
Εκμάθηση # 3: Τι είναι ο έλεγχος συστατικών
Εκμάθηση # 4: Συνεχής ενσωμάτωση
Εκμάθηση # 5 Διαφορά μεταξύ δοκιμής μονάδας και ολοκλήρωσης
Εκμάθηση # 6: Κορυφαία 10 εργαλεία δοκιμής ενοποίησης

τι είναι ο έλεγχος ολοκλήρωσης

Τι θα μάθετε:

Τι είναι ο έλεγχος ενοποίησης;

Η έννοια της δοκιμής ενοποίησης είναι αρκετά απλή- Ενσωματώστε / συνδυάστε τη μονάδα που δοκιμάστηκε μία προς μία και δοκιμάστε τη συμπεριφορά ως συνδυασμένη μονάδα.

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

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

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

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

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

Γιατί δοκιμή ολοκλήρωσης;

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

Ακολουθούν ορισμένοι λόγοι:

  1. Στον πραγματικό κόσμο, όταν αναπτύσσονται εφαρμογές, χωρίζεται σε μικρότερες ενότητες και στους μεμονωμένους προγραμματιστές εκχωρείται 1 ενότητα. Η λογική που υλοποιείται από έναν προγραμματιστή είναι αρκετά διαφορετική από μια άλλη προγραμματιστή, οπότε καθίσταται σημαντικό να ελέγξετε αν η λογική που εφαρμόζεται από έναν προγραμματιστή είναι σύμφωνα με τις προσδοκίες και να αποδίδει τη σωστή τιμή σύμφωνα με τα καθορισμένα πρότυπα.
  2. Πολλές φορές το πρόσωπο ή η δομή των δεδομένων αλλάζει όταν μετακινείται από τη μία ενότητα στην άλλη. Ορισμένες τιμές προσαρτώνται ή καταργούνται, γεγονός που προκαλεί προβλήματα στις μεταγενέστερες ενότητες.
  3. Οι ενότητες αλληλεπιδρούν επίσης με ορισμένα εργαλεία τρίτων ή API, τα οποία πρέπει επίσης να δοκιμαστούν ότι τα δεδομένα που γίνονται αποδεκτά από αυτό το API / εργαλείο είναι σωστά και ότι η απόκριση που δημιουργείται είναι επίσης όπως αναμένεται.
  4. Ένα πολύ κοινό πρόβλημα στις δοκιμές - Συχνή αλλαγή απαιτήσεων! :) Πολλές φορές ο προγραμματιστής αναπτύσσει τις αλλαγές χωρίς να το δοκιμάσει η μονάδα. Ο έλεγχος ολοκλήρωσης καθίσταται σημαντικός εκείνη τη στιγμή.

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

Υπάρχουν πολλά πλεονεκτήματα αυτής της δοκιμής και μερικά από αυτά αναφέρονται παρακάτω.

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

Προκλήσεις

Παρακάτω αναφέρονται μερικές προκλήσεις που εμπλέκονται στο τεστ ολοκλήρωσης.

# 1) Έλεγχος ολοκλήρωσης σημαίνει δοκιμή δύο ή περισσότερων ολοκληρωμένων συστημάτων προκειμένου να διασφαλιστεί ότι το σύστημα λειτουργεί σωστά. Όχι μόνο οι σύνδεσμοι ενοποίησης πρέπει να δοκιμαστούν, αλλά πρέπει να γίνει διεξοδική δοκιμή λαμβάνοντας υπόψη το περιβάλλον για να διασφαλιστεί ότι το ολοκληρωμένο σύστημα λειτουργεί σωστά.

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

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

# 3) Ενώ ενσωματώνει οποιοδήποτε νέο σύστημα στο παλαιό σύστημα, απαιτεί πολλές αλλαγές και δοκιμές. Το ίδιο ισχύει κατά την ενσωμάτωση δύο παλαιών συστημάτων.

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

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

Τύποι δοκιμών ολοκλήρωσης

Δίνεται παρακάτω ένας τύπος Test Integration μαζί με τα πλεονεκτήματα και τα μειονεκτήματά του.

Προσέγγιση Big Bang:

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

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

Προσέγγιση Big Bang

Πλεονεκτήματα της προσέγγισης Big Bang:

  • Είναι μια καλή προσέγγιση για μικρά συστήματα.

Μειονεκτήματα της προσέγγισης Big Bang:

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

Βήματα δοκιμής ολοκλήρωσης:

  1. Προετοιμάστε την ολοκλήρωση Σχέδιο δοκιμής.
  2. Προετοιμάστε σενάρια δοκιμής ενοποίησης και δοκιμαστικές περιπτώσεις.
  3. Προετοιμάστε σενάρια αυτοματισμού δοκιμής.
  4. Εκτελέστε δοκιμαστικές περιπτώσεις.
  5. Αναφέρετε τα ελαττώματα.
  6. Παρακολουθήστε και ελέγξτε ξανά τα ελαττώματα.
  7. Η εκ νέου δοκιμή και οι δοκιμές συνεχίζονται έως ότου ολοκληρωθεί ο έλεγχος ενοποίησης.

Προσεγγίσεις ολοκλήρωσης δοκιμής

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

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

Ας εξετάσουμε το παρακάτω σχήμα για να δοκιμάσουμε τις προσεγγίσεις:

Ενσωμάτωση 1

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

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

Σε αυτήν την περίπτωση, οι μονάδες B1C1, B1C2 & B2C1, B2C2 είναι η χαμηλότερη μονάδα που ελέγχεται από τη μονάδα. Οι ενότητες B1 & B2 δεν έχουν ακόμη αναπτυχθεί. Η λειτουργικότητα των Module B1 και B2 είναι ότι καλεί τις ενότητες B1C1, B1C2 & B2C1, B2C2. Δεδομένου ότι τα B1 και B2 δεν έχουν ακόμη αναπτυχθεί, θα χρειαζόμασταν κάποιο πρόγραμμα ή ένα 'διεγερτικό' που θα καλέσει τις μονάδες B1C1, B1C2 & B2C1, B2C2. Αυτά τα προγράμματα διέγερσης ονομάζονται ΟΔΗΓΟΙ .

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

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

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

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

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

time () συνάρτηση c ++

Στο πλαίσιο της εικόνας μας, οι δοκιμές ξεκινούν από την Ενότητα Α και οι κατώτερες ενότητες Β1 και Β2 είναι ενσωματωμένες μία προς μία. Τώρα εδώ οι κατώτερες ενότητες B1 και B2 δεν είναι πραγματικά διαθέσιμες για ενσωμάτωση. Έτσι, για να δοκιμάσουμε τις κορυφαίες ενότητες Α, αναπτύσσουμε ' ΚΑΤΑΣΤΗΜΑΤΑ '.

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

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

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

Ας συμπεράνουμε κάποια διαφορά μεταξύ Stubs και πρόγραμμα οδήγησης :

ΣτέλεχοιΟδηγός
Χρησιμοποιείται στην προσέγγιση Top downΧρησιμοποιείται στην προσέγγιση κάτω προς τα πάνω
Πρώτα δοκιμάζεται η πρώτη ενότηταΟι χαμηλότερες ενότητες δοκιμάζονται πρώτα.
Διεγείρει το χαμηλότερο επίπεδο συστατικώνΔιεγείρει το υψηλότερο επίπεδο συστατικών
Ψεύτικο πρόγραμμα εξαρτημάτων χαμηλότερου επιπέδουDummy πρόγραμμα για συστατικό υψηλότερου επιπέδου

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

Η ολοκλήρωση ξεκινά με το μεσαίο στρώμα και κινείται ταυτόχρονα προς τα πάνω και προς τα κάτω. Στην περίπτωση του σχήματος μας, οι δοκιμές μας θα ξεκινήσουν από τα B1 και B2, όπου ένας βραχίονας θα δοκιμάσει το άνω τμήμα A και ένας άλλος βραχίονας θα δοκιμάσει τα κάτω στοιχεία B1C1, B1C2 & B2C1, B2C2.

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

Δοκιμή ολοκλήρωσης εφαρμογής GUI

Τώρα ας μιλήσουμε για το πώς μπορούμε να υπονοούμε δοκιμές ενσωμάτωσης στην τεχνική Black Box.

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

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

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

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

Λογισμικό GenNext ανέπτυξε αυτό το προϊόν για μένα και παρακάτω ήταν η αρχιτεκτονική:

Ενσωμάτωση 2

ΚΡΕΜΜΥΔΙ - Ενότητα διεπαφής χρήστη, η οποία είναι ορατή στον τελικό χρήστη, όπου δίδονται όλες οι εισόδους.
BL - Είναι η ενότητα Business Logic, η οποία έχει όλους τους υπολογισμούς και τις συγκεκριμένες επιχειρηματικές μεθόδους.
ΦΠΑ - Είναι η μονάδα επικύρωσης, η οποία έχει όλες τις επικυρώσεις της ορθότητας της εισαγωγής.
CNT - Είναι η ενότητα περιεχομένου που έχει όλα τα στατικά περιεχόμενα, ειδικά για τις εισόδους που εισάγει ο χρήστης. Αυτά τα περιεχόμενα εμφανίζονται στις αναφορές.
ΣΕ - Είναι η μονάδα κινητήρα, αυτή η ενότητα διαβάζει όλα τα δεδομένα που προέρχονται από τη μονάδα BL, VAL και CNT και εξάγει το ερώτημα SQL και το ενεργοποιεί στη βάση δεδομένων.
Χρονοδιάγραμμα - Είναι μια ενότητα που προγραμματίζει όλες τις αναφορές με βάση την επιλογή χρήστη (μηνιαία, τριμηνιαία, εξαμηνιαία & ετήσια)
DB - Είναι η βάση δεδομένων.

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

Οι ερωτήσεις εδώ είναι:

  1. Πώς το BL, το VAL και το CNT module θα διαβάσουν και θα ερμηνεύσουν τα δεδομένα που εισήχθησαν στη μονάδα UI;
  2. Η μονάδα BL, VAL και CNT λαμβάνει τα σωστά δεδομένα από τη διεπαφή χρήστη;
  3. Σε ποια μορφή τα δεδομένα από BL, VAL και CNT μεταφέρονται στη μονάδα EQ;
  4. Πώς θα διαβάσει το EQ τα δεδομένα και θα εξαγάγει το ερώτημα;
  5. Έχει εξαχθεί σωστά το ερώτημα;
  6. Ο προγραμματιστής λαμβάνει τα σωστά δεδομένα για αναφορές;
  7. Είναι το σύνολο αποτελεσμάτων που λαμβάνεται από το EN, από τη βάση δεδομένων είναι σωστό και όπως αναμένεται;
  8. Μπορεί το EN να στείλει την απάντηση πίσω στη μονάδα BL, VAL και CNT;
  9. Είναι η μονάδα UI ικανή να διαβάσει τα δεδομένα και να τα εμφανίσει κατάλληλα στη διεπαφή;

Στον πραγματικό κόσμο, η επικοινωνία των δεδομένων γίνεται σε μορφή XML. Έτσι, όποια δεδομένα εισάγει ο χρήστης στη διεπαφή χρήστη, μετατρέπεται σε μορφή XML.

Στο σενάριό μας, τα δεδομένα που εισάγονται στη λειτουργική μονάδα UI μετατρέπονται σε αρχείο XML το οποίο ερμηνεύεται από τις 3 ενότητες BL, VAL και CNT. Η ενότητα EN διαβάζει το προκύπτον αρχείο XML που δημιουργήθηκε από τις 3 ενότητες και εξάγει το SQL από αυτό και ζητά στη βάση δεδομένων. Η μονάδα EN λαμβάνει επίσης το σύνολο αποτελεσμάτων και το μετατρέπει σε ένα αρχείο XML και το επιστρέφει στη λειτουργική μονάδα UI που μετατρέπει τα αποτελέσματα σε μορφή αναγνώσιμη από τον χρήστη και το εμφανίζει.

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

Λοιπόν, όπου η δοκιμή ενοποίησης έρχεται στην εικόνα;

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

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

Λίγες άλλες συνθήκες δοκιμής δείγματος μπορεί να είναι οι εξής:

  • Οι επιλογές μενού δημιουργούν το σωστό παράθυρο;
  • Μπορούν τα παράθυρα να επικαλεστούν το υπό δοκιμή παράθυρο;
  • Για κάθε παράθυρο, προσδιορίστε τις κλήσεις λειτουργίας για το παράθυρο που πρέπει να επιτρέπει η εφαρμογή.
  • Προσδιορίστε όλες τις κλήσεις από το παράθυρο σε άλλες δυνατότητες που η εφαρμογή πρέπει να επιτρέπει
  • Προσδιορίστε τις αναστρέψιμες κλήσεις: το κλείσιμο ενός παρακαλούμενου παραθύρου θα πρέπει να επιστρέψει στο παράθυρο κλήσεων.
  • Προσδιορίστε τις μη αναστρέψιμες κλήσεις: τα παράθυρα κλήσης κλείνουν πριν εμφανιστεί το παράθυρο κλήσης.
  • Δοκιμάστε τους διαφορετικούς τρόπους εκτέλεσης κλήσεων σε άλλο παράθυρο π.χ. - μενού, κουμπιά, λέξεις-κλειδιά.

Βήματα για την έναρξη των δοκιμών ολοκλήρωσης

  1. Κατανοήστε την αρχιτεκτονική της εφαρμογής σας.
  2. Προσδιορίστε τις ενότητες
  3. Κατανοήστε τι κάνει κάθε ενότητα
  4. Κατανοήστε πώς μεταφέρονται τα δεδομένα από τη μία ενότητα στην άλλη.
  5. Κατανόηση του τρόπου εισαγωγής και λήψης των δεδομένων στο σύστημα (σημείο εισόδου και εξόδου της εφαρμογής)
  6. Διαχωρίστε την εφαρμογή για να ταιριάζει στις δοκιμαστικές σας ανάγκες.
  7. Προσδιορίστε και δημιουργήστε τις συνθήκες δοκιμής
  8. Πάρτε μια κατάσταση κάθε φορά και γράψτε τις δοκιμαστικές θήκες.

Κριτήρια εισόδου / εξόδου για δοκιμές ενοποίησης

Κριτήρια εισόδου:

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

Κριτήρια εξόδου:

  • Έχουν εκτελεστεί όλες οι περιπτώσεις δοκιμής ενοποίησης.
  • Δεν ανοίγονται κρίσιμα και ελαττώματα προτεραιότητας P1 & P2.
  • Η έκθεση δοκιμής ετοιμάστηκε.

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

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

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

Για παράδειγμα, οι περιπτώσεις δοκιμών ενοποίησης για την εφαρμογή Linkedin θα περιλαμβάνουν:

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

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

Είναι η ολοκλήρωση μια τεχνική λευκού κουτιού ή μαύρου κουτιού;

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

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

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

Εργαλεία δοκιμών ενοποίησης

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

Δίνεται παρακάτω μια λίστα εργαλείων:

  • Τεστ ορθολογικής ολοκλήρωσης
  • Μοιρογνωμόνιο
  • Ατμός
  • TESSY

Για περισσότερες λεπτομέρειες σχετικά με τα παραπάνω εργαλεία, ελέγξτε αυτό το σεμινάριο:

Κορυφαία 10 εργαλεία δοκιμών ενοποίησης για τη σύνταξη δοκιμών ενοποίησης

Δοκιμή ενοποίησης συστήματος

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

Οι ενότητες ή τα εξαρτήματα δοκιμάζονται μεμονωμένα σε δοκιμές μονάδας πριν από την ολοκλήρωση των εξαρτημάτων.

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

Διαφορά μεταξύ δοκιμών ενοποίησης και δοκιμών συστήματος

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

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

συμπέρασμα

Όλα αυτά αφορούν τον έλεγχο ολοκλήρωσης και την εφαρμογή του τόσο στην τεχνική White box όσο και στην Black Box. Ελπίζω να το εξηγήσαμε καθαρά με σχετικά παραδείγματα.

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

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

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

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

^