Τι είναι το SIT; Δοκιμή Ολοκλήρωσης Συστημάτων με Παράδειγμα

Τι είναι η δοκιμή ενοποίησης συστήματος;

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

Οι Δοκιμές Ολοκλήρωσης Συστήματος (SIT) εκτελούνται για την επαλήθευση των αλληλεπιδράσεων μεταξύ των ενοτήτων ενός συστήματος λογισμικού. Ασχολείται με την επαλήθευση των απαιτήσεων λογισμικού υψηλού και χαμηλού επιπέδου που καθορίζονται στις Προδιαγραφές/Δεδομένα Απαιτήσεων Λογισμικού και στο Έγγραφο Σχεδιασμού Λογισμικού.

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

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

Γιατί να κάνετε δοκιμές ενοποίησης συστήματος;

Στη Μηχανική Λογισμικού, ο Έλεγχος ολοκλήρωσης συστήματος γίνεται επειδή:

• Βοηθά στην ανίχνευση Ελάττωμα νωρίς
• Θα είναι διαθέσιμα νωρίτερα σχόλια σχετικά με την αποδοχή της μεμονωμένης ενότητας
• Ο προγραμματισμός των επιδιορθώσεων ελαττωμάτων είναι ευέλικτος και μπορεί να επικαλύπτεται με την ανάπτυξη
• Σωστή ροή δεδομένων
• Σωστή ροή ελέγχου
• Σωστός συγχρονισμός
• Σωστή χρήση μνήμης
• Διορθώστε τις απαιτήσεις λογισμικού

Δοκιμή Ενσωμάτωσης Συστήματος vs Δοκιμή Συστήματος vs Δοκιμή Αποδοχής Χρήστη

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

Παράμετρος	Δοκιμή ολοκλήρωσης συστήματος	Δοκιμή συστήματος	Δοκιμή αποδοχής χρήστη
Πρωτεύουσα εστίαση	Διεπαφές και ροή δεδομένων μεταξύ ενσωματωμένων ενοτήτων	Συμπεριφορά της συναρμολογημένης κατασκευής ως σύνολο	Επιχειρηματική καταλληλότητα για πραγματική χρήση
Επίπεδο δοκιμών	Επίπεδο δύο	Επίπεδο τρία	Τελικό επίπεδο πριν την έναρξη λειτουργίας
Τεχνική	Μαύρο κουτί	Μαύρο κουτί, λευκό κουτί ή γκρι κουτί	Μαύρο κουτί
Εκτελεσμένο από	Δοκιμαστές και προγραμματιστές ενσωμάτωσης	Ανεξάρτητη ομάδα δοκιμών	Πελάτης ή τελικοί χρήστες
Τυπικά ελαττώματα	Διεπαφή, χρονισμός, μνήμη και χάρτης δεδομένωνping σφάλματα	Λειτουργικά και μη λειτουργικά σφάλματα συστήματος	Χρησιμότητα και αναντιστοιχίες απαιτήσεων
Εκτελείται όταν	Μετά το Δοκιμή μονάδας	Μετά το SIT	Μετά τη δοκιμή συστήματος

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

Πώς να κάνετε τη δοκιμή ενοποίησης συστήματος

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

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

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

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

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

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

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

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

Σημείωση: Εάν δοκιμάζεται μόνο το λογισμικό, τότε ονομάζεται Έλεγχος Ενοποίησης Λογισμικού Λογισμικού [SSIT] και εάν δοκιμάζονται τόσο το υλικό όσο και το λογισμικό, τότε ονομάζεται Δοκιμή ενοποίησης λογισμικού υλικού [HSIT].

Αυξητική Προσέγγιση

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

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

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

Υπάρχουν δύο τύποι σταδιακών δοκιμών

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

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

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

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

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

1. Η κύρια μονάδα ελέγχου χρησιμοποιείται ως οδηγός δοκιμής και τα στελέχη αντικαθιστούν όλες τις μονάδες που είναι άμεσα υποδεέστερες της κύριας μονάδας ελέγχου.
2. Τα δευτερεύοντα στελέχη αντικαθίστανται ένα-ένα με πραγματικές μονάδες ανάλογα με την επιλεγμένη προσέγγιση (πρώτα το πλάτος ή πρώτα το βάθος).
3. Οι δοκιμές εκτελούνται καθώς κάθε ενότητα είναι ενσωματωμένη.
4. Με την ολοκλήρωση κάθε συνόλου δοκιμών, ένα άλλο στέλεχος αντικαθίσταται με μια πραγματική ενότητα μετά την ολοκλήρωση κάθε συνόλου δοκιμών
5. Για να βεβαιωθείτε ότι δεν έχουν εισαχθεί νέα σφάλματα Δοκιμή παλινδρόμησης μπορεί να εκτελεστεί.

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

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

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

Προκλήσεις που μπορεί να αντιμετωπίσει ο δοκιμαστής:

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

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

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

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

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

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

Αυτή η διαδικασία δοκιμής ολοκλήρωσης εκτελείται σε μια σειρά τεσσάρων βημάτων

1. Οι μονάδες χαμηλού επιπέδου συνδυάζονται σε συμπλέγματα που εκτελούν μια συγκεκριμένη υπολειτουργία λογισμικού.
2. Ένα πρόγραμμα οδήγησης είναι γραμμένο για να συντονίζει την είσοδο και την έξοδο δοκιμαστικής περίπτωσης.
3. Το σύμπλεγμα ή η κατασκευή ελέγχεται.
4. Τα προγράμματα οδήγησης αφαιρούνται και τα συμπλέγματα συνδυάζονται και κινούνται προς τα πάνω στη δομή του προγράμματος.

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

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

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

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

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

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

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

Δοκιμή ενσωμάτωσης λογισμικού υλικού

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

Δοκιμή ενσωμάτωσης υλικού-λογισμικού βάσει απαιτήσεων

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

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

Το Hardware Software Integration ασχολείται με την επαλήθευση των απαιτήσεων υψηλού επιπέδου. Όλες οι δοκιμές σε αυτό το επίπεδο πραγματοποιούνται στο υλικό-στόχο.

• Η δοκιμή μαύρου κουτιού είναι η κύρια μεθοδολογία δοκιμών που χρησιμοποιείται σε αυτό το επίπεδο δοκιμών.
• Καθορίζω περιπτώσεις δοκιμής μόνο από τις απαιτήσεις υψηλού επιπέδου
• Πρέπει να εκτελεστεί μια δοκιμή σε τυπικό υλικό παραγωγής (στο στόχο)

Πράγματα που πρέπει να λάβετε υπόψη κατά το σχεδιασμό δοκιμών για την ενσωμάτωση HW/SW

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

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

Δοκιμή ενσωμάτωσης λογισμικού σε λογισμικό

Πρόκειται για τη δοκιμή του Στοιχείου Λογισμικού Υπολογιστή που λειτουργεί στο περιβάλλον του κεντρικού υπολογιστή/στόχου, ενώ παράλληλα προσομοιώνει ολόκληρο το σύστημα [άλλα CSC] και τη λειτουργικότητα υψηλού επιπέδου.

Εστιάζει στη συμπεριφορά ενός CSC σε ένα προσομοιωμένο περιβάλλον κεντρικού υπολογιστή/στόχου. Η προσέγγιση που χρησιμοποιείται για την Ενοποίηση Λογισμικού μπορεί να είναι μια σταδιακή προσέγγιση (από πάνω προς τα κάτω, από κάτω προς τα πάνω ή συνδυασμός και των δύο, που ονομάζεται επίσης προσέγγιση σάντουιτς ή υβριδική προσέγγιση).

Κριτήρια εισόδου και εξόδου για τη δοκιμή ενσωμάτωσης

Μόλις διευθετηθεί η προσέγγιση και οι δύο παραλλαγές ενσωμάτωσης, το ερώτημα που απομένει είναι πότε μπορεί να ξεκινήσει μια ομάδα και πότε μπορεί να σταματήσει. Συνήθως, κατά την εκτέλεση Δοκιμών Ενσωμάτωσης, χρησιμοποιείται η στρατηγική ETVX (Κριτήρια Εισόδου, Εργασίας, Επικύρωσης και Κριτήρια Εξόδου).

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

• Ολοκλήρωση του Δοκιμή μονάδας

Είσοδοι:

• Δεδομένα Απαιτήσεων Λογισμικού
• Έγγραφο σχεδίασης λογισμικού
• Σχέδιο επαλήθευσης λογισμικού
• Έγγραφα ενσωμάτωσης λογισμικού

Δραστηριότητες:

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

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

• Επιτυχής ολοκλήρωση της ενσωμάτωσης της ενότητας Λογισμικού στο Υλικό-στόχου
• Σωστή απόδοση του λογισμικού σύμφωνα με τις απαιτήσεις που καθορίζονται

Έξοδοι

• Εκθέσεις δοκιμών ολοκλήρωσης
• Υποθέσεις και διαδικασίες δοκιμής λογισμικού [SVCP].

Κοινές προκλήσεις στις δοκιμές ολοκλήρωσης συστημάτων

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

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

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

καλυτερα Practices for System Integration Testing

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

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

⚠ Συμβουλή: Πάγωμα των προδιαγραφών διεπαφής πριν ξεκινήσει η ενσωμάτωση. Μια καθυστερημένη αλλαγή σε μια μορφή μηνύματος ακυρώνει τις δοκιμαστικές περιπτώσεις και στις δύο πλευρές της διεπαφής και είναι η πιο συνηθισμένη αιτία επανεπεξεργασίας SIT.

Συχνές Ερωτήσεις