Επαλήθευση και Επικύρωση

ΧΑΡΟΚΟΠΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΚΑΙ ΤΗΛΕΜΑΤΙΚΗΣ Επαλήθευση και Επικύρωση Μάρα Νικολαϊδου

Διαφορά µεταξύ επαλήθευσης και επικύρωσης Επαλήθευση: "Φτιάχνουµε σωστά το προϊόν;" Το λογισµικό πρέπει να συµµορφώνεται µε τις προδιαγραφές του. Επικύρωση: "Φτιάχνουµε το σωστό προϊόν;" Το λογισµικό πρέπει να κάνει αυτό που απαιτεί πραγµατικά ο χρήστης.

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

Στόχοι της διαδικασίας επαλήθευσης και επικύρωσης Η διαδικασία επαλήθευσης και επικύρωσης πρέπει να αποδεικνύει ότι το λογισµικό είναι κατάλληλο για το σκοπό για τον οποίο χρησιµοποιείται. Αυτό ΔΕΝ σηµαίνει ότι δεν έχει ατέλειες. Όµως πρέπει να είναι αρκετά καλό για τη χρήση για την οποία προορίζεται - από τον τύπο χρήσης εξαρτάται και ο βαθµός εµπιστοσύνης που απαιτείται.

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

Στατική και δυναµική επαλήθευση Επιθεωρήσεις λογισµικού. Αναφέρονται στην ανάλυση της αναπαράστασης του στατικού συστήµατος µε σκοπό τον εντοπισµό προβληµάτων (στατική επαλήθευση) Συµπληρώνονται από αναλύσεις του πηγαίου κώδικα ενός συστήµατος ή των σχετικών εγγράφων µε βοηθητικά εργαλεία Δοκιµές λογισµικού. Αναφέρονται στην άσκηση και την παρατήρηση της συµπεριφοράς ενός προϊόντος (δυναµική επαλήθευση) Το σύστηµα τίθεται σε λειτουργία µε δοκιµαστικά δεδοµένα και εξετάζεται η λειτουργική του συµπεριφορά

Στατική και δυναµική επαλήθευση και επικύρωση

Δοκιµές προγραµµάτων Αποκαλύπτουν την ύπαρξη σφαλµάτων, ΟΧΙ την απουσία τους. Αποτελούν τη µοναδική τεχνική επικύρωσης αφού το λογισµικό πρέπει να εκτελεστεί για να διαπιστωθεί η συµπεριφορά του. Πρέπει να χρησιµοποιούνται σε συνδυασµό µε τη στατική επαλήθευση για πλήρη κάλυψη.

Τύποι δοκιµών Δοκιµές για ατέλειες Δοκιµές που στοχεύουν στον εντοπισµό ατελειών του συστήµατος. Επιτυχηµένη δοκιµή ατελειών θεωρείται µια δοκιµή που αποκαλύπτει την ύπαρξη ατελειών σε ένα σύστηµα. Εξετάζεται στο Κεφάλαιο 23. Δοκιµές επικύρωσης Επιδιώκουν να δείξουν ότι το λογισµικό ικανοποιεί τις απαιτήσεις του πελάτη. Επιτυχηµένη δοκιµή είναι εκείνη που αποδεικνύει τη σωστή υλοποίηση µιας απαίτησης.

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

Η διαδικασία αποσφαλµάτωσης

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

Το µοντέλο V

Η δοµή ενός σχεδίου δοκιµών λογισµικού Η διαδικασία δοκιµών Ανιχνευσιµότητα απαιτήσεων Στοιχεία προς δοκιµή Χρονοδιάγραµµα δοκιµών Διαδικασίες καταγραφής δοκιµών Απαιτήσεις υλικού και λογισµικού Περιορισµοί

Η δοµή ενός σχεδίου δοκιµών λογισµικού Η διαδικασία δοκιμών Μια περιγραφή των κύριων φάσεων της διαδικασίας δοκιμών. Αυτές οι φάσεις θα μπορούσαν να συμφωνούν με την περιγραφή μας νωρίτερα στο παρόν κεφάλαιο. Ανιχνευσιμότητα απαιτήσεων Οι χρήστες ενδιαφέρονται κυρίως για το αν το σύστημα ικανοποιεί τις απαιτήσεις του, και οι δοκιμές πρέπει να σχεδιαστούν ώστε να ελέγχουν κάθε απαίτηση ξεχωριστά. Στοιχεία προς δοκιμή Εδώ καθορίζονται τα προϊόντα της διαδικασίας παραγωγής λογισμικού που πρόκειται να δοκιμαστούν. Χρονοδιάγραμμα δοκιμών Το συνολικό χρονοδιάγραμμα των δοκιμών, και η κατανομή πόρων για αυτό το χρονοδιάγραμμα. Αυτά τα στοιχεία προφανώς συνδέονται με το γενικότερο χρονοδιάγραμμα ανάπτυξης του έργου. Διαδικασίες καταγραφής δοκιμών Μόνο η εκτέλεση των δοκιμών δεν αρκεί τα αποτελέσματα πρέπει να καταγραφούν συστηματικά. Θα πρέπει να είναι δυνατή η εξέταση της διαδικασίας των δοκιμών, ώστε να εξασφαλιστεί ότι έχει εκτελεστεί σωστά. Απαιτήσεις υλικού και λογισμικού Αυτή η ενότητα περιγράφει τα εργαλεία λογισμικού που απαιτούνται, καθώς και την εκτιμώμενη χρήση του υλικού. Περιορισμοί Στη συγκεκριμένη ενότητα πρέπει να αναφέρονται περιορισμοί οι οποίοι θα μπορούσαν να επηρεάσουν τη διαδικασία δοκιμών, όπως η έλλειψη προσωπικού.

Επιθεωρήσεις λογισµικού Προβλέπουν την εξέταση της πηγαίας αναπαράστασης από το προσωπικό µε στόχο την ανακάλυψη ανωµαλιών και ατελειών. Οι επιθεωρήσεις δεν απαιτούν εκτέλεση του συστήµατος, οπότε µπορούν να γίνουν πριν από την υλοποίηση. Μπορούν να εφαρµοστούν σε οποιαδήποτε αναπαράσταση του συστήµατος (απαιτήσεις, σχεδιασµός, δεδοµένα διευθέτησης, δοκιµαστικά δεδοµένα, κ.λπ.). Αποδεδειγµένα αποτελούν µια αποτελεσµατική τεχνική ανακάλυψης σφαλµάτων στα προγράµµατα.

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

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

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

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

Η διαδικασία επιθεώρησης

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

Ρόλοι στη διαδικασία επιθεώρησης Δηµιουργός ή κάτοχος Επιθεωρητής Εκφωνητής Γραµµατέας Επικεφαλής ή συντονιστής Κύριος συντονιστής Ο προγραµµατιστής ή ο σχεδιαστής που είναι υπεύθυνος για τη δηµιουργία του προγράµµατος ή του εγγράφου. Το άτοµο αυτό είναι υπεύθυνο για τη διόρθωση των ατελειών που θα εντοπιστούν κατά τη διαδικασία της επιθεώρησης. Εντοπίζει λάθη, παραλείψεις, και ασυνέπειες στα προγράµµατα και τα έγγραφα. Μπορεί επίσης να επισηµαίνει ευρύτερα ζητήµατα τα οποία είναι έξω από τη σφαίρα αρµοδιοτήτων της οµάδας επιθεώρησης. Παρουσιάζει τον κώδικα ή το έγγραφο σε µια συνάντηση επιθεώρησης. Καταγράφει τα αποτελέσµατα της συνάντησης της οµάδας επιθεώρησης. Καθοδηγεί τη διαδικασία και διευκολύνει την επιθεώρηση. Αναφέρει τα αποτελέσµατα της διαδικασίας στον κύριο συντονιστή. Υπεύθυνος για βελτιώσεις επάνω στη διαδικασία επιθεώρησης, την ενηµέρωση της λίστας ελέγχου, την ανάπτυξη προτύπων κ.λπ.

Λίστα ελέγχων επιθεώρησης Για την καθοδήγηση της επιθεώρησης πρέπει να χρησιµοποιείται µια λίστα ελέγχων µε συνήθη σφάλµατα. Οι λίστες ελέγχων εξαρτώνται από την εκάστοτε γλώσσα προγραµµατισµού και αποτυπώνουν χαρακτηριστικά σφάλµατα που είναι πιθανό να ανακύψουν στη γλώσσα αυτή. Σε γενικές γραµµές, όσο πιο "χαλαρός" ο έλεγχος τύπων της γλώσσας, τόσο µεγαλύτερη η λίστα ελέγχων. Παραδείγµατα: απόδοση αρχικών τιµών, ονοµατολογία σταθερών ποσοτήτων, τερµατισµός βρόχων, όρια πινάκων, κ.λπ.

Έλεγχοι επιθεώρησης (1) Σφάλµατα δεδοµένων Σφάλµατα ελέγχου Σφάλµατα εισόδου/εξόδου Παίρνουν κατάλληλη αρχική τιµή όλες οι µεταβλητές του προγράµµατος πριν τη χρήση των τιµών τους; Έχουν ονοµαστεί όλες οι σταθερές; Ποιο πρέπει να είναι το άνω όριο των πινάκων, ίσο µε το µέγεθος του πίνακα ή µικρότερο κατά ένα; Αν χρησιµοποιούνται αλφαριθµητικά χαρακτήρων, εκχωρείται ρητά κάποια ένδειξη τέλους; Υπάρχει πιθανότητα υπερχείλισης χώρων προσωρινής αποθήκευσης; Είναι σωστές οι συνθήκες των εντολών υπό συνθήκη; Είναι σίγουρο ότι κάθε βρόχος τερµατίζεται; Είναι οι σύνθετες εντολές σωστά οµαδοποιηµένες; Στις εντολές case, περιλαµβάνονται όλες οι δυνατές περιπτώσεις; Αν απαιτείται διακοπή (break) µετά από κάθε περίπτωση στις εντολές case, έχει συµπεριληφθεί; Χρησιµοποιούνται όλες οι µεταβλητές εισόδου; Εκχωρείται τιµή σε όλες τις µεταβλητές εξόδου πριν από την έξοδό τους; Υπάρχουν µη αναµενόµενες είσοδοι οι οποίες θα µπορούσαν να προκαλέσουν αλλοίωση;

Έλεγχοι επιθεώρησης (2) Σφάλµατα διασύνδεσης Σφάλµατα διαχείρισης αποθήκευσης Σφάλµατα διαχείρισης εξαιρέσεων Έχουν όλες οι κλήσεις συναρτήσεων και µεθόδων το σωστό πλήθος παραµέτρων; Ταιριάζουν οι τυπικές µε τις πραγµατικές παραµέτρους; Παρατίθενται οι παράµετροι στη σωστή σειρά; Αν υπάρχουν συστατικά στοιχεία τα οποία προσπελάζουν κοινόχρηστη µνήµη, διαθέτουν το ίδιο µοντέλο για τη δοµή της µνήµης αυτής; Κατά την τροποποίηση συνδεδεµένων δοµών, γίνεται σωστά η επανεκχώρηση σε όλους τους συνδέσµους; Αν χρησιµοποιείται δυναµική αποθήκευση, έχει κατανεµηθεί σωστά ο χώρος; Γίνεται ρητά η αποδέσµευση του χώρου ο οποίος πλέον δεν χρειάζεται; Έχουν ληφθεί υπόψη όλες οι πιθανές συνθήκες σφάλµατος;

Ρυθµός επιθεώρησης 500 εντολές/ώρα κατά την επισκόπηση 125 εντολές πηγαίου κώδικα/ώρα κατά την ατοµική προετοιµασία 90-125 εντολές/ώρα επιθεωρούνται σε µια συνάντηση επιθεώρησης Συνεπώς η επιθεώρηση είναι µια διαδικασία που κοστίζει πολύ. Η επιθεώρηση 500 γραµµών κώδικα χρειάζεται περίπου 40 εργατοώρες - περίπου 2800 λίρες (ή 3100 ) µε τις αµοιβές που ισχύουν στο Ηνωµένο Βασίλειο.

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

Έλεγχοι στατικής ανάλυσης Κατηγορία σφάλµατος Σφάλµατα δεδοµένων Σφάλµατα ελέγχου Σφάλµατα εισόδου/εξόδου Σφάλµατα διασύνδεσης Σφάλµατα διαχείρισης αποθήκευσης Έλεγχος στατικής ανάλυσης Μεταβλητές που χρησιµοποιούνται πριν την ανάθεση αρχικής τιµής Μεταβλητές που δηλώνονται αλλά δεν χρησιµοποιούνται ποτέ Μεταβλητές στις οποίες ανατίθεται τιµή δύο φορές χωρίς να χρησιµοποιηθούν στο ενδιάµεσο Πιθανές παραβιάσεις των ορίων πινάκων Μεταβλητές που δεν έχουν δηλωθεί Μη προσεγγίσιµος κώδικας Διακλαδώσεις χωρίς συνθήκες στο εσωτερικό βρόχων Διπλή έξοδος µεταβλητών χωρίς ενδιάµεση ανάθεση τιµής Ασυµφωνίες τύπων παραµέτρων Ασυµφωνίες πλήθους παραµέτρων Αποτελέσµατα συναρτήσεων που δεν χρησιµοποιούνται Συναρτήσεις και διαδικασίες που δεν καλούνται Δείκτες χωρίς ανάθεση τιµής Αριθµητική δεικτών

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

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

Στατική ανάλυση του LINT 138% more lint_ex.c #include <stdio.h> printarray (Anarray) int Anarray; { printf( %d,anarray); } main () { int Anarray[5]; int i; char c; printarray (Anarray, i, c); printarray (Anarray) ; } 139% cc lint_ex.c 140% lint lint_ex.c lint_ex.c(10): warning: c may be used before set lint_ex.c(10): warning: i may be used before set printarray: variable # of args. lint_ex.c(4) :: lint_ex.c(10) printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(10) printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(11) printf returns value which is always ignored

Χρήση στατικής ανάλυσης Ιδιαίτερα χρήσιµη σε γλώσσες προγραµµατισµού, όπως η C, οι οποίες δεν έχουν αυστηρή έκφραση τύπων και έτσι πολλά σφάλµατα δεν εντοπίζονται από το µεταγλωττιστή Λιγότερο αποτελεσµατική για γλώσσες όπως η Java, οι οποίες έχουν ισχυρό έλεγχο τύπων και έτσι µπορούν να εντοπίζουν πολλά σφάλµατα κατά τη µεταγλώττιση.

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

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

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

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

Η διαδικασία ανάπτυξης "καθαρής αίθουσας"

Χαρακτηριστικά της διαδικασίας ανάπτυξης "καθαρής αίθουσας" Τυπική προδιαγραφή µε χρήση ενός µοντέλου µεταβολών καταστάσεων. Βαθµιαία ανάπτυξη στην οποία ο πελάτης καθορίζει την προτεραιότητα των επαυξήσεων. Δοµηµένος προγραµµατισµός - χρησιµοποιείται περιορισµένο πλήθος δοµών ελέγχου και αφηρηµένων τύπων δεδοµένων. Στατική επαλήθευση µε τη χρήση σχολαστικών επιθεωρήσεων Στατιστικές δοκιµές του συστήµατος

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

Οµάδες που µετέχουν στη διαδικασία ανάπτυξης "καθαρής αίθουσας" Η οµάδα προδιαγραφών. Υπεύθυνη για την ανάπτυξη και τη συντήρηση των προδιαγραφών του συστήµατος. Η οµάδα ανάπτυξης. Υπεύθυνη για την ανάπτυξη και την επαλήθευση του λογισµικού. Το λογισµικό ΔΕΝ εκτελείται, ούτε καν µεταγλωττίζεται, κατά τη διαδικασία της ανάπτυξης. Η οµάδα πιστοποίησης. Υπεύθυνη για την ανάπτυξη ενός συνόλου στατιστικών δοκιµών µε σκοπό τον έλεγχο του λογισµικού µετά την κατασκευή του. Χρησιµοποιούνται µοντέλα ανάπτυξης αξιοπιστίας για να προσδιοριστεί πότε το σύστηµα είναι αρκετά αξιόπιστο.

Αξιολόγηση της διαδικασίας ανάπτυξης "καθαρής αίθουσας" Τα αποτελέσµατα της χρήσης της διαδικασίας ανάπτυξης "καθαρής αίθουσας" είναι πολύ εντυπωσιακά αφού στα παραδοτέα συστήµατα έχουν ανακαλυφθεί λίγα ελαττώµατα. Μια ανεξάρτητη αξιολόγηση αποδεικνύει ότι η διαδικασία αυτή δεν κοστίζει πιο ακριβά από άλλες προσεγγίσεις. Υπήρχαν λιγότερα σφάλµατα απ' ότι σε µια "παραδοσιακή" διαδικασία ανάπτυξης. Ωστόσο δεν είναι γενικευµένη η χρήση της διαδικασίας αυτής. Δεν είναι σαφής ο τρόπος µε τον οποίο η προσέγγιση αυτή µπορεί να µεταφερθεί σε ένα περιβάλλον µε λιγότερο ικανούς ή λιγότερο αφοσιωµένους µηχανικούς λογισµικού.

ΧΑΡΟΚΟΠΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΚΑΙ ΤΗΛΕΜΑΤΙΚΗΣ Δοκιµές Λογισµικού Μάρα Νικολαϊδου

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

Φάσεις δοκιµών

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

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

Η διαδικασία δοκιµών λογισµικού

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

Δοκιµές συστήµατος Αφορούν την ενοποίηση δύο ή περισσοτέρων συστατικών στοιχείων µε σκοπό τη δηµιουργία ενός συστήµατος ή υποσυστήµατος. Μπορεί να αφορούν τη δοκιµή µιας επαύξησης που πρόκειται να παραδοθεί στον πελάτη. Δύο φάσεις: Δοκιµές ενοποίησης - η οµάδα δοκιµών έχει πρόσβαση στον πηγαίο κώδικα του συστήµατος. Γίνεται δοκιµή του συστήµατος κατά την ενοποίηση των συστατικών στοιχείων. Δοκιµές τελικής έκδοσης - η οµάδα δοκιµών δοκιµάζει ολόκληρο το σύστηµα που πρόκειται να παραδοθεί µε δοκιµές "µαύρου κουτιού".

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

Βαθµιαίες δοκιµές ενοποίησης

Προσεγγίσεις δοκιµών Επικύρωση της αρχιτεκτονικής Οι δοκιµές µε αναλυτική ενοποίηση είναι πιο αποτελεσµατικές στην ανακάλυψη σφαλµάτων στην αρχιτεκτονική των συστηµάτων. Επίδειξη συστήµατος Με τις δοκιµές αναλυτικής ενοποίησης µπορεί να γίνει µια περιορισµένη επίδειξη των λειτουργιών του συστήµατος σε κάποιο πρώιµο στάδιο της ανάπτυξής του. Υλοποίηση δοκιµών Συχνά είναι πιο εύκολες οι δοκιµές συνθετικής ενοποίησης. Παρατήρηση δοκιµών Προβλήµατα και µε τις δύο προσεγγίσεις. Για την παρατήρηση των δοκιµών µπορεί να απαιτείται επιπλέον κώδικας.

Δοκιµές τελικής έκδοσης Η διαδικασία της δοκιµής µιας έκδοσης του συστήµατος η οποία θα διανεµηθεί στους πελάτες. Κύριος στόχος είναι να αυξήσει το επίπεδο εµπιστοσύνης του προµηθευτή στο ότι το σύστηµα ικανοποιεί τις απαιτήσεις του. Οι δοκιµές τελικής έκδοσης αποτελούν συνήθως µια διαδικασία δοκιµών "µαύρου κουτιού" (black-box testing) ή λειτουργικών δοκιµών Βασίζονται µόνο στις προδιαγραφές του συστήµατος Τα µέλη της οµάδας δοκιµών δεν γνωρίζουν την υλοποίηση του συστήµατος.

Δοκιµή µαύρου κουτιού

Οδηγίες δοκιµών Οι οδηγίες δοκιµών αποτελούν συµβουλές για την οµάδα δοκιµών οι οποίες θα βοηθήσουν τα µέλη της να επιλέξουν κατάλληλες δοκιµές ώστε να αποκαλύψουν ατέλειες στο σύστηµα Επιλογή εισόδων οι οποίες αναγκάζουν το σύστηµα να παράγει κάθε είδους µήνυµα σφάλµατος Σχεδιασµός εισόδων που προκαλούν υπερχείλιση των χώρων προσωρινής αποθήκευσης Επανάληψη της ίδιας εισόδου ή µιας σειράς εισόδων πολλές φορές Πρόκληση µη έγκυρων εξόδων Παραγωγή αποτελεσµάτων υπολογισµών τα οποία είναι πολύ µεγάλα ή πολύ µικρά

Σενάριο δοκιµής Ζητήθηκε από µια φοιτήτρια στη Σκωτία η οποία µελετά την Αµερικανική ιστορία να γράψει µια έκθεση σχετικά µε «Τον επεκτατισµό στην Αµερικανική Δύση από το 1840 µέχρι το 1880». Για να το κάνει, πρέπει να βρει πηγές από διάφορες βιβλιοθήκες. Συνδέεται µε το σύστηµα LIBSYS και χρησιµοποιεί τη λειτουργία αναζήτησης για να διαπιστώσει αν µπορεί να προσπελάσει πρωτότυπα έγγραφα εκείνης της εποχής. Εντοπίζει πηγές σε διάφορες πανεπιστηµιακές βιβλιοθήκες των ΗΠΑ και κατεβάζει αντίγραφα από κάποιες από αυτές. Ωστόσο, για ένα έγγραφο, πρέπει να διαθέτει βεβαίωση από το πανεπιστήµιό της ότι είναι πράγµατι φοιτήτρια και ότι η χρήση του εγγράφου δεν προορίζεται για εµπορικούς σκοπούς. Η φοιτήτρια χρησιµοποιεί τη λειτουργία του LIBSYS µε την οποία µπορεί να ζητήσει τέτοια άδεια και καταχωρίζει το αίτηµά της. Αν γίνει αποδεκτό, το έγγραφο θα µεταφερθεί στον καταχωρισµένο διακοµιστή της βιβλιοθήκης και θα τυπωθεί για λογαριασµό της. Λαµβάνει ένα µήνυµα από το LIBSYS τον οποίο την πληροφορεί ότι θα λάβει ένα µήνυµα ηλεκτρονικού ταχυδροµείου µόλις το τυπωµένο έγγραφο γίνει διαθέσιµο.

Δοκιµές συστήµατος Δοκιµή του µηχανισµού σύνδεσης (login) µε χρήση σωστών και λανθασµένων διαπιστευτηρίων ώστε να ελεγχθεί αν οι έγκυροι χρήστες γίνονται αποδεκτοί και οι µη έγκυροι απορρίπτονται. Δοκιµή της λειτουργίας αναζήτησης µε τη χρήση ερωτηµάτων σε γνωστές πηγές ώστε να ελεγχθεί αν ο µηχανισµός αναζήτησης εντοπίζει όντως έγγραφα. Δοκιµή των λειτουργιών παρουσίασης του συστήµατος ώστε να ελεγχθεί αν οι πληροφορίες σχετικά µε τα έγγραφα εµφανίζονται σωστά. Δοκιµή του µηχανισµού αίτησης άδειας για λήψη. Δοκιµή της αυτόµατης απάντησης ηλεκτρονικού ταχυδροµείου ότι το έγγραφο είναι διαθέσιµο.

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

Διάγραµµα ακολουθίας για τη συλλογή µετεωρολογικών δεδοµένων

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

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

Δοκιµές συστατικών στοιχείων Οι δοκιµές συστατικών στοιχείων αφορούν τη διαδικασία δοκιµής µεµονωµένων συστατικών στοιχείων του συστήµατος. Είναι µια διαδικασία δοκιµών για ατέλειες. Τα συστατικά στοιχεία µπορεί να είναι: Μεµονωµένες συναρτήσεις ή µέθοδοι στο εσωτερικό ενός αντικειµένου Κλάσεις αντικειµένων µε πολλά γνωρίσµατα και µεθόδους Σύνθετα συστατικά στοιχεία που διαθέτουν καθορισµένες διασυνδέσεις οι οποίες χρησιµοποιούνται για πρόσβαση στις λειτουργικές δυνατότητές τους

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

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

Δοκιµές διασυνδέσεων

Τύποι διασυνδέσεων Παραµετρικές διασυνδέσεις Μεταβιβάζονται δεδοµένα από τη µία διεργασία στην άλλη Διασυνδέσεις κοινόχρηστης µνήµης Κάποιο µπλοκ της µνήµης διατίθεται για κοινή χρήση µεταξύ διεργασιών ή λειτουργιών. Διαδικασιακές διασυνδέσεις Ένα υποσύστηµα ενθυλακώνει ένα σύνολο διεργασιών τις οποίες θα καλέσουν άλλα υποσυστήµατα. Διασυνδέσεις µεταβίβασης µηνυµάτων Κάποια υποσυστήµατα αιτούνται υπηρεσιών από άλλα υποσυστήµατα.

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

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

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

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

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

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

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

Διαµερίσεις ισοδυναµίας

Διαµερίσεις ισοδυναµίας

Προδιαγραφή ρουτίνας αναζήτησης procedure Search (Key : ELEM ; T: SEQ of ELEM; Found : in out BOOLEAN; L: in out ELEM_INDEX) ; Προσυνθήκη -- η ακολουθία έχει τουλάχιστον ένα στοιχείο T FIRST <= T LAST Μετασυνθήκη -- το στοιχείο υπάρχει και αναφέρεται από το L ( Found and T (L) = Key) ή -- το στοιχείο δεν περιέχεται στην ακολουθία ( not Found and not (exists i, T FIRST >= i <= T LAST, T (i) = Key ))

Ρουτίνα αναζήτησης διαµερίσεις εισόδου Είσοδοι που συνάδουν µε τις προσυνθήκες Είσοδοι στις οποίες κάποια προσυνθήκη δεν ισχύει Είσοδοι όπου το στοιχείο-κλειδί είναι µέρος της ακολουθίας Είσοδοι όπου το στοιχείο-κλειδί δεν είναι µέρος της ακολουθίας

Οδηγίες δοκιµών (ακολουθίες) Δοκιµάζουµε το λογισµικό µε ακολουθίες οι οποίες έχουν µία µόνο τιµή. Σε κάθε δοκιµή χρησιµοποιούµε ακολουθίες διαφορετικού µεγέθους. Δηµιουργούµε δοκιµές οι οποίες θα προσπελάζουν το πρώτο, το µεσαίο και το τελευταίο στοιχείο κάθε ακολουθίας. Πραγµατοποιούµε δοκιµές µε ακολουθίες µηδενικού µήκους.

Ρουτίνα αναζήτησης διαµερίσεις εισόδου Ακολουθία Μία τιµή Μία τιµή Περισσότερες από 1 τιµές Περισσότερες από 1 τιµές Περισσότερες από 1 τιµές Περισσότερες από 1 τιµές Στοιχείο Στην ακολουθία Δεν περιέχεται στην ακολουθία Το πρώτο στοιχείο της ακολουθίας Το τελευταίο στοιχείο της ακολουθίας Το µεσαίο στοιχείο της ακολουθίας Δεν περιέχεται στην ακολουθία Ακολουθία εισόδου (T) Κλειδί (Key) Έξοδος (Found, L) 17 17 αληθές, 1 17 0 ψευδές, ;; 17, 29, 21, 23 17 αληθές, 1 41, 18, 9, 31, 30, 16, 45 45 αληθές, 7 17, 18, 21, 23, 29, 41, 38 23 αληθές, 4 21, 23, 29, 33, 38 25 ψευδές, ;;

Δοκιµές δοµής Μερικές φορές ονοµάζεται και δοκιµή "λευκού κουτιού". Δηµιουργούνται περιπτώσεις δοκιµών ανάλογα µε τη δοµή του προγράµµατος. Για τον προσδιορισµό επιπλέον περιπτώσεων δοκιµών χρησιµοποιείται η γνώση και η κατανόηση του προγράµµατος. Ο αντικειµενικός στόχος είναι ο έλεγχος όλων των εντολών του προγράµµατος (όχι όλων των συνδυασµών διαδροµών).

Δοκιµές δοµής

Δυαδική αναζήτηση ισοδυν. διαµερίσεις Ικανοποιούνται οι προσυνθήκες, το στοιχείο-κλειδί ανήκει στον πίνακα. Ικανοποιούνται οι προσυνθήκες, το στοιχείο-κλειδί δεν ανήκει στον πίνακα. Δεν ικανοποιούνται οι προσυνθήκες, το στοιχείοκλειδί ανήκει στον πίνακα. Δεν ικανοποιούνται οι προσυνθήκες, το στοιχείοκλειδί δεν ανήκει στον πίνακα. Ο πίνακας εισόδου έχει µία µόνο τιµή. Ο πίνακας εισόδου έχει ζυγό πλήθος τιµών. Ο πίνακας εισόδου έχει µονό πλήθος τιµών.

Δυαδική αναζήτηση ισοδυν. διαµερίσεις

Δυαδική αναζήτηση - περιπτώσεις δοκιµών Πίνακας εισόδου (Τ) Κλειδί Έξοδος (Found, L) (Key) 17 17 αληθές, 1 17 0 ψευδές, ;; 17, 21, 23, 29 17 αληθές, 1 9, 16, 18, 30, 31, 41, 45 45 αληθές, 7 17, 18, 21, 23, 29, 38, 41 23 αληθές, 4 17, 18, 21, 23, 29, 33, 38 21 αληθές, 3 12, 18, 21, 23, 32 23 αληθές, 4 21, 23, 29, 33, 38 25 ψευδές, ;;

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

Γράφηµα ροής δυαδικής αναζήτησης

Ανεξάρτητες διαδροµές 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14 1, 2, 3, 4, 5, 14 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, 1, 2, 3, 4, 6, 7, 2, 11, 13, 5, Πρέπει να παραχθούν περιπτώσεις δοκιµών ώστε να εκτελεστεί καθεµιά από αυτές τις διαδροµές Για να ελέγξουµε αν έχουν εκτελεστεί όλες οι διαδροµές, µπορούµε να χρησιµοποιήσουµε ένα δυναµικό αναλυτή προγραµµάτων.

Αυτοµατοποίηση δοκιµών Οι δοκιµές είναι µια πολυδάπανη φάση της διαδικασίας παραγωγής λογισµικού. Για τη µείωση του απαιτούµενου χρόνου και του συνολικού κόστους των δοκιµών υπάρχουν κατάλληλα εργαλεία. Συστήµατα όπως το Junit υποστηρίζουν αυτόµατη εκτέλεση δοκιµών. Τα περισσότερα εργαλεία δοκιµών έχουν ανοιχτή δοµή επειδή οι ανάγκες των δοκιµών εξαρτώνται από την εκάστοτε εταιρεία. Μερικές φορές είναι δύσκολη η ενσωµάτωση εργαλείων σχεδιασµού και ανάλυσης τα οποία έχουν κλειστή δοµή.

Ένα εργαστήριο δοκιµών

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

Ενδεικτικά Ζητήµατα Επαλήθευση και Επικύρωση Ορισµός εννοιών Που και γιατί χρησιµοποιείται η κάθε έννοια Διαφορές µεταξύ τους Πως (µέθοδοι/τεχνικές) υλοποιείται η κάθε µία από αυτές Τεχνικές Στατικής Επαλήθευσης Στόχος Αυτοµατοποίηση/Εργαλεία Μπορούν να βρουν όλα τα σφάλµατα?? Ποια δεν µπορούν να εντοπίσουν?? Διαδικασία Επιθεώρησης Προγράµµατος Διαδικασία Δοκιµών Που αποσκοπεί? Οργάνωση διαδικασίας δοκιµών Ποιοι συµµετέχουν Διαδικασία ανάπτυξης "καθαρής αίθουσας" Που αποσκοπεί Βασίζεται στη βαθµιαία ανάπτυξη, τη στατική επαλήθευση και τις στατιστικές δοκιµές του λογισµικού Ποιο το όφελος και οι δυσκολίες

Ενδεικτικά Ζητήµατα Στόχος Δοκιµών Κατηγοριοποίηση Δοκιµών Δοκιµή Συστατικού Στοιχείου VS Δοκιµή Συστήµατος Ποιοι είναι «υπεύθυνοι» για τη διεξαγωγή κάθε µιας από αυτές Δοκιµές Ενοποίησης Συσχετίσεις ανάµεσα στις διαφορές κατηγορίες δοκιµών (Υπάρχει προτεινόµενη σειρά εκτέλεσης?) Αν η λειτουργία των συστατικών στοιχείων είναι ορθή, αυτό εξασφλίζει και την ορθή λειτουργία του συστήµατος? Επαλήθευση απαιτήσειεων Πως ελέγχεται η ορθή λειτουργία του συστήµατος? Πως περιλαµβάνονται οι µη λειτουργικές απαιτήσεις στις δοκιµές? Δοκιµές για ατέλειες Δοκιµές διασύνδεσης Δοκιµές δοµής Περιπτώσεις δοκιµής Στόχος Δηµιουργία διαµερίσεων ισοδυναµίας Αυτοµατοποίηση Δοκιµών Σε ποιο βαθµό είναι εφικτή

Ενδεικτική Βιβλιογραφία Κεφάλαιο 22 ο «Επαλήθευση και Επικύρωση» του βιβλίου «Βασικές Αρχές Τεχνολογίας Λογισµικού» του Ian Sommerville Κεφάλαιο 23 ο «Δοκιµές Λογισµικού» του βιβλίου «Βασικές Αρχές Τεχνολογίας Λογισµικού» του Ian Sommerville Κεφάλαιο 8 ο Προχωρώντας προς το σχεδιασµό (σελ. 368-399) του βιβλίου «Ανάλυση και Σχεδιασµός Συστηµάτων µε τη UML 2.0 των Davis, Wixon, Tegarden Κεφάλαιο 13 ο Κατασκευή (σελ. 663-683) του βιβλίου «Ανάλυση και Σχεδιασµός Συστηµάτων µε τη UML 2.0 των Davis, Wixon, Tegarden