Τεχνολογία Λογισμικού

Πανεπιστήμιο Πειραιά Τμήμα Ψηφιακών Συστημάτων Τεχνολογία Λογισμικού 18/12/2017 Δρ. Ανδριάνα Πρέντζα Αναπληρώτρια Καθηγήτρια aprentza@unipi.gr

Πανεπιστήμιο Πειραιά Τμήμα Ψηφιακών Συστημάτων Ελεγχος και διόρθωση σφαλμάτων

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

Εισαγωγή ΣΗΜΑΝΤΙΚΟ στάδιο στη διαδικασία ανάπτυξης λογισμικού ο έλεγχος της ορθής λειτουργίας λογισμικού! ΔΕΝ ΠΡΕΠΕΙ ΝΑ ΥΠΟΤΙΜΑΤΑΙ! ΔΕΝ ΥΠΑΡΧΕΙ ΛΟΓΙΣΜΙΚΟ ΧΩΡΙΣ ΣΦΑΛΜΑΤΑ!!!! Γιατί τότε έχουν πρόβλημα οι χρήστες του λογισμικού, οι οποίοι ανακαλύπτουν σφάλματα! Στόχος της Τεχνολογίας Λογισµικού στη φάση ελέγχου: Παροχή τεχνικών για το σχεδιασμό, την εκτέλεση και τη σωστή τεκμηρίωση του ελέγχου λογισµικού Μέχρι και 50% προϋπολογισμού ο έλεγχος & διόρθωση!!!

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

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

Γενικό πλαίσιο ελέγχου Έλεγχος λογισµικού είναι η διαδικασία κατά την οποία εξετάζεται το λογισµικό µε χρήση ειδικά σχεδιασµένων τεχνικών και µε σκοπό την εύρεση και διόρθωση σφαλµάτων στην υλοποίησή του. Τα σφάλµατα που αναζητούνται σε αυτό το στάδιο ανάπτυξης κατηγοριοποιούνται σε δύο οµάδες Επαλήθευση (verification): υλοποιούμε σωστά το λογισμικό? Επικύρωση (validation): υλοποιούμε το σωστό λογισμικό?

Επαλήθευση (verification) Yλοποιούμε σωστά το λογισμικό??? Είναι ο τρόπος ελέγχου του λογισμικού για να να διακρίνουµε σφάλµατα που παρουσιάζονται κατά την εκτέλεση συγκεκριµένων µονάδων του λογισµικού. ΕΔΩ έχουμε υλοποιήσει το σωστό λογισμικό ΑΛΛΑ η υλοποίησή του παρουσιάζει λάθη

Επικύρωση (validation) Υλοποιούμε το σωστό λογισμικό? Είναι ο τρόπος ελέγχου του λογισμικού για να να διακρίνουµε σφάλµατα που παρουσιάζονται λόγω αντίφασης των αποτελεσµάτων της λειτουργίας του λογισµικού µε συγκεκριµένες απαιτήσεις και προδιαγραφές του συστήµατος. ΕΔΩ η υλοποίηση του λογισμικού δεν παρουσιάζει λάθη ΑΛΛΑ το λογισμικό μας δεν ικανοποιεί τις απαιτήσεις, δεν κάνει δηλαδή αυτό που θέλαμε! Δίνει λάθος λύση στο πρόβλημά μας! Στην περίπτωση αυτή έχουν γίνει λάθη κατά τη µετάβαση από τις προδιαγραφές στη σχεδίαση του λογισµικού.

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

Προβλήματα λογισμικού Σφάλμα: Ανθρώπινο λάθος (σε προδιαγραφές, τεκμηρίωση κλπ) Ελάττωμα: «Κωδικοποίηση του σφάλματος» στο προϊόν λογισμικού Αστοχία: Απομάκρυνση απο την προδιαγεγραμμένη λειτουργία του συστήματος Η εμφάνιση του ελαττώματος Αίτια αστοχίας: Λανθασμένες ή ελλιπείς προδιαγραφές Μη ρεαλιστικές προδιαγραφές Ελαττώματα στη σχεδίαση του συστήματος / προγράμματος και στην υλοποίηση (κώδικας)

Έλεγχος λογισμικού Επιβεβαιώνει την ύπαρξη υποπτευόμενης αστοχίας...... ή μας βοηθά να προκαλέσουμε νέες αστοχίες!!! Πότε είναι επιτυχής? Όταν κατά τη διάρκειά του συμβαίνουν «άσχημα πράγματα»...... όταν δηλαδή μας επιβεβαιώνει ότι κάτι δεν κάναμε καλά Ανακαλύπτεται ελάττωμα Συμβαίνει αστοχία ως αποτέλεσμα της διαδικασίας ελέγχου Καλύτερα τώρα παρά αργότερα...

Έλεγχος λογισμικού Testing can only show the presence of bugs, not their absence (Dijkstra)

Βασικές αρχές ελέγχου Κάθε έλεγχος πρέπει να αφορά μια συγκεκριμένη απαίτηση του πελάτη Η προετοιμασία των ελέγχων αρχίζει πολύ πριν την εφαρμογή τους Σενάριο ελέγχου Αναμενόμενο αποτέλεσμα Ισχύει η αρχή Pareto: 80% των λαθών θα αφορούν 20% των τμημάτων λογισμικού The Pareto principle (80 20 rule, law of the vital few, and principle of factor sparsity): for many events, roughly 80% of the effects come from 20% of the causes Ο έλεγχος πρέπει να αρχίζει από τις μικρές δομικές μονάδες και να καταλήγει στο ολοκληρωμένο σύστημα από το ειδικότερο προς το γενικότερο! Δεν είναι δυνατό να ελεγχθεί ένα σύστημα πλήρως Ο αποτελεσματικός έλεγχος εκτελείται από «τρίτους»

Που μπορώ να βρω ελαττώματα? Παντού! Αλγόριθμοι Σύνταξη ( η πρώτη διαστημική αποστολή των ΗΠΑ για την Αφροδίτη απέτυχε επειδή έλειπε ένα κόμμα σε ένα βρόχο do της Fortran!) Σφάλματα υπολογισμού ή ακρίβειας (συνδιασμός ακεραίων και αριθμών κινητής υποδιαστολής) Σφάλματα τεκμηρίωσης (δεν κάνω αυτό που λέω) Σφάλματα πίεσης / υπερφόρτωσης λόγω φόρτωσης δεδομένων μεγέθους μεγαλύτερου από την καθορισμένη χωρητικότητα Σφάλματα χρονισμού / συγχρονισμού (δύσκολα εντοπίζονται!) Σφάλματα ανάκτησης / επανόρθωσης σε εσφαλμένες λειτουργίες Σφάλματα / Αποκλίσεις από πρότυπα ή διαδικασίες

Τα «κοινωνικά» ζητήματα του ελέγχου... Ποιος τον κάνει? Ομάδα ανάπτυξης Μονάδων και ολοκλήρωσης Ομάδα ελέγχου Τάσεις: Υπόλοιποι έλεγχοι (έλεγχοι συστήματος) Οι άπειροι προγραμματιστές δεν έχουν τη σωστή νοοτροπία για τον έλεγχο ως μέσο ανακάλυψης λαθών... Κανείς δεν δέχεται την ευθύνη για ένα σφάλμα Λύση: μη εγωϊστικός προγραμματισμός! Όλοι προσπαθούν να κάνουν τη δουλειά τους Οι ελεγκτές να δείξουν ότι βρίσκουν λάθη Η ομάδα ανάπτυξης να δείξει ότι δεν κάνει Συχνές διενέξεις...

Λογισμικό που μπορεί να ελεγχθεί Για να μπορέσει το λογισμικό να ελεγχθεί αποτελεσματικά πρέπει να πληροί τις παρακάτω προϋποθέσεις: Λειτουργικότητα Παρατηρησιμότητα Ελεγξιμότητα Αποσυνθεσιμότητα Απλότητα Ευστάθεια Τεκμηρίωση

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

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

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

Κατηγορίες ελέγχων Στατικές τεχνικές (δεν απαιτούν την εκτέλεση του προγράμματος) Στατική ανάλυση (π.χ. Java bytecode verification) Επιθεώρηση (review) περιήγηση (walkthrough) επισκόπηση (inspection) Δυναμικές τεχνικές (βασίζονται στην εκτέλεση του προγράμματος) Συμβολική εκτέλεση Δυναμικός έλεγχος έλεγχος μονάδας (unit testing) έλεγχος συνένωσης (integration testing) έλεγχος συστήματος (system testing) έλεγχος αποδοχής (acceptance testing)

Στάδια εκτέλεσης ελέγχου Κώδικας μονάδας προγράμματος Κώδικας μονάδας προγράμματος Έλεγχος μονάδος Έλεγχος μονάδος Ελεγμένη μονάδα Ελεγμένη μονάδα Αρχιτεκτονικό και λεπτομερές σχέδιο Έλεγχος συνένωσης Λειτουργικές απαιτήσεις Ολοκληρωμένο σύστημα Έλεγχος λειτουργίας Λειτουργικό σύστημα Κώδικας μονάδας προγράμματος Έλεγχος μονάδος Ελεγμένη μονάδα Άλλες απαιτήσεις λογισμικού Απαιτήσεις και ανάγκες του πελάτη Περιβάλλον χρήστη Λειτουργικό σύστημα Έλεγχος εκτέλεσης Επικυρωμένο επαληθευμένο σύστημα Έλεγχος αποδοχής Αποδεκτό σύστημα Έλεγχος εγκατάστασης Σύστημα σε χρήση

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

Εμφάνιση Σφαλμάτων Έλεγχος Μονάδας Προγράμματος και Συνένωσης Ατελής διαδικασία ελέγχου Εισαγωγή νέων σφαλμάτων κατά τη διόρθωση παλιών Έλεγχος Συστήματος Ατελής διαδικασία ελέγχου Λειτουργία - Συντήρηση Λανθασμένη τεκμηρίωση χρήσης Αδυναμία χρηστών Εισαγωγή νέων σφαλμάτων κατά τη διόρθωση παλιών Αλλαγές στις απαιτήσεις

Σχέδιο ελέγχου Θυμηθείτε τη βασική αρχή ελέγχου: Η προετοιμασία των ελέγχων αρχίζει πολύ πριν την εφαρμογή τους (αμέσως μετά την ολοκλήρωση συγγραφής των απαιτήσεων από το λογισμικό!) Σενάριο ελέγχου Αναμενόμενο αποτέλεσμα Ο προγραµµατισµός αυτός καταγράφεται σε ένα έγγραφο, το σχέδιο ελέγχου (test plan) Περιέχει πληροφορίες για το σκοπό του ελέγχου που θα εκτελεστεί, τη στρατηγική που θα χρησιµοποιηθεί και τους αναγκαίους πόρους για τη διεκπεραίωση του. Καλό είναι να ετοιμάζεται πριν την παραγωγή του πηγαίου κώδικα και να διατίθεται σε όλους όσους συμμετέχουν στην ανάπτυξη του λογισµικού Διευκόλυνση εκτέλεσης ελέγχου Ετοιµασία και διάθεση αναγκαίων για τον έλεγχο εγγράφων Δυνατότητα έναρξης διαδικασίας ελέγχου πριν την ολοκλήρωση της παραγωγής του πηγαίου κώδικα

Σχέδιο ελέγχου (IEEE standard Std 829-1991) 1. Ταυτότητα εγγράφου 2. Εισαγωγή 1. Στόχοι 2. Υποδομή 3. Έκταση ελέγχου 4. Παραπομπές 3. Στοιχεία προς έλεγχο 4. Χαρακτηριστικά που θα ελεγχθούν 5. Χαρακτηριστικά που δε θα ελεγχθούν 6. Μεθοδολογία 7. Κριτήρια αποδοχής

Σχέδιο ελέγχου (IEEE standard Std 829-1991) 8. Κριτήρια ακύρωσης και προδιαγραφές επανάληψης ελέγχου 1. Ακύρωση ελέγχου 2. Επανάληψη ελέγχου 9. Παραδοτέα έγγραφα 10. Εργασίες ελέγχου 11. Περιβάλλον ελέγχου 12. Κατανομή ευθυνών για την εκτέλεση ελέγχου 1. Ομάδα διοίκησης ελέγχου 2. Ομάδα ανάπτυξης 3. Ομάδα ελέγχου

Σχέδιο ελέγχου (IEEE standard Std 829-1991) 13. Ανάγκες στελέχωσης και εκπαίδευσης προσωπικού 1. Προσωπικό 2. Εκπαίδευση 14. Χρονοδιάγραμμα ελέγχου 15. Αντιμετώπιση προβλημάτων (κίνδυνοι και απρόοπτα) 16. Εγκρίσεις

Τεκμηρίωση πραγματοποίησης ελέγχων Προδιαγραφές σχεδίου ελέγχου Προδιαγραφές περίπτωσης ελέγχου Αναγνωριστικό Τμήματα που θα δοκιμαστούν Καθορισμός εισόδων Καθορισμός αναμενόμενων αποτελεσμάτων Ανάγκες περιβάλλοντος Διαδικαστικές απαιτήσεις Εξαρτήσεις Προδιαγραφές διαδικασίας διεκπεραίωσης ελέγχου Έκθεση διαβίβασης οντοτήτων προς έλεγχο Ημερολόγιο ελέγχου Περιληπτική έκθεση ελέγχου

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

Διαχείριση λαθών Η διαχείριση των λαθών πρέπει να γίνεται οργανωμένα. Απαραίτητη μια ΒΔ ή ειδικό πρόγραμμα. Για κάθε σφάλμα ή πρόβλημα είναι χρήσιμα τα παρακάτω στοιχεία: Κωδικό αριθμό Τίτλο Πρόσωπο που το διαπίστωσε Σοβαρότητα Είδος (λάθος, πρόταση βελτίωσης, μη συμμόρφωση με της προδιαγραφές, χρηστικότητα κ.λπ.) Περιβάλλον Αναλυτική περιγραφή Συνοδευτικά στοιχεία

Διαχείριση λαθών Υποσύστημα Ημερομηνία εισαγωγής στο σύστημα Υπεύθυνος αποκατάστασης Ημερομηνία ανάθεσης Ημερομηνία αποκατάστασης Προτεραιότητα Σημειώσεις Αλλα σχετικά λάθη Κατάσταση (ανοιχτό, κλειστό, υπό εξέταση, δε διαπιστώθηκε) Έκδοση του κώδικα που εμφανίστηκε Έκδοση του κώδικα που διορθώθηκε

Τεχνικές ελέγχου Αρχή ελέγχου µιας εφαρµογής λογισµικού: εκτελείται ένα τµήµα αυτής µε ένα σύνολο από δεδοµένα εισόδου για τα οποία τα αποτελέσµατα είναι γνωστά και, αν τα αποτελέσµατα που λαµβάνονται από την εκτέλεση ΔΕΝ είναι ίδια µε τα αναµενόµενα, τότε το τµήµα αυτό έχει σφάλµατα. Δοκιµή µονάδας Η εκτέλεση µιας µονάδας λογισμικού µε δεδοµένα εισόδου για τα οποία τα αποτελέσµατα εξόδου είναι γνωστά λέγεται «δοκιµή» (test) της µονάδας. Δοκιµές που γίνονται µε διαφορετικά δεδοµένα θεωρούνται διαφορετικές Τα δεδοµένα εισόδου και εξόδου που χρησιµοποιούνται κατά τις δοκιµές λέγονται δοκιµαστικά δεδοµένα (test data)

Τεχνικές ελέγχου Περίπτωση ελέγχου (test case) Σύνολο από: Δοκιµαστικά δεδοµένα Συνθήκες εκτέλεσης Αναµενόµενα αποτελέσματα που έχουν σχεδιαστεί µε ένα συγκεκριµένο σκοπό, όπως το να καλύψουν ένα µονοπάτι εκτέλεσης του λογισµικού ή να επικυρώσουν τη συµφωνία µε µια συγκεκριµένη απαίτηση από αυτό.

Ροή ελέγχου μονάδας λογισμικού Σχεδιασμός περιπτώσεων ελέγχου ορισμός δοκιµαστικών δεδοµένων, συνθηκών εκτέλεσης και αναµενόµενων αποτελεσμάτων εξόδου για κάθε δοκιµή Εκτέλεση λογισµικού µε τα δοκιµαστικά δεδοµένα κάθε περίπτωσης ελέγχου, λήψη και καταγραφή αποτελεσμάτων και σύγκριση με τα αναµενόµενα αποτελέσµατα των αντίστοιχων περιπτώσεων ελέγχου Σύνταξη απαραίτητων αναφορών ελέγχου Δεν είναι δυνατόν να δοκιµαστούν όλες οι περιπτώσεις ελέγχου Αν δεν αποκαλύπτεται σφάλμα, δε σημαίνει απαραίτητα ότι δεν υπάρχει! Σχεδιασμός περιπτώσεων ελέγχου Επιλογή δοκιμαστικών δεδομένων Εκτέλεση της οντότητας /στοιχείου Σύγκριση αποτελεσμάτων με αναμενόμενα Περιπτώσεις ελέγχου Δοκιμαστικά δεδομένα Αποτελέσματα Αναφορές ελέγχου

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

Στρατηγικές δυναμικού ελέγχου Στρατηγική μαύρου κουτιού (black box testing) Ελέγχουμε το λογισμικό ως ένα σύστημα με γνωστές προδιαγραφές αλλά άγνωστη υλοποίηση μαύρο κουτί! Στρατηγική άσπρου κουτιού (white box testing) ή γυάλινου κουτιού (glass box testing) Ελέγχουμε το λογισμικό με βάση την εσωτερική δομή του όλα διάφανα! Δεν μπορούμε όμως να βρούμε: Μη συμμόρφωση με τις προδιαγραφές Μονοπάτια που απουσιάζουν Λάθη που αποκαλύπτονται με ειδικές τιμές δεδομένων

Στρατηγικές δυναμικού ελέγχου Στρατηγική μαύρου κουτιού (black box testing) μπορούμε να βρούμε: Λειτουργικότητα που απoυσιάζει ή έχει υλοποιηθεί με λανθασμένο τρόπο Λάθη διεπαφών Λάθη σε δομές δεδομένων και πρόσβαση στην εξωτερική βάση δεδομένων Προβλήματα απόδοσης Λάθη κατά την εκκίνηση και τον τερματισμό Στρατηγική άσπρου κουτιού (white box) ή γυάλινου κουτιού (glass box) μπορούμε να βρούμε: Λογικά λάθη σε μέρη του προγράμματος που σπάνια εκτελούνται Λάθη σε λογικές διαδρομές του προγράμματος που θεωρούμε πως δεν θα έπρεπε να εκτελούνται Τυπογραφικά λάθη σε μέρη του προγράμματος που σπάνια εκτελούνται

Στρατηγικές δυναμικού ελέγχου Στρατηγική μαύρου κουτιού (black box testing) Για διάστημα τιμών δοκιμάζουμε την ελάχιστη επιτρεπτή και μέγιστη μη επιτρεπτή για το άνω και κάτω όριο τιμών Για πλήθος στοιχείων δοκιμάζουμε το μικρότερο και μεγαλύτερο πλήθος καθώς και ένα μικρότερο και ένα μεγαλύτερο από τον αριθμό αυτό Δημιουργούμε τιμές εισόδου που να παράγουν αντίστοιχες αντιπροσωπευτικές τιμές από τα τελικά αποτελέσματα Στρατηγική άσπρου κουτιού (white box) ή γυάλινου κουτιού (glass box) Κάθε εντολή να εκτελεστεί μια τουλάχιστο φορά Κάθε συνθήκη πρέπει να ελέγχεται για κάθε συνδυασμό αληθών και ψευδών τιμών Κάθε βρόχος πρέπει να εκτελείται 0, 1, 2, n-1, n, και n+1 φορές

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

Στρατηγική μαύρου κουτιού Έλεγχος με τα δοκιμαστικά δεδομένα που ανήκουν στο σύνολο Α και που προκαλούν ανώµαλη συµπεριφορά του συστήµατος ΟΜΩΣ πάρα πολλά δεδομένα! ΑΡΑ χρειάζεται επιλογή κάποιων test cases που έχουν µεγάλη πιθανότητα να αποκαλύψουν σφάλµατα στην ελεγχόµενη μονάδα Δοκιμαστικά δεδομένα εισόδου Παρατηρούμενα δεδομένα εξόδου Α Ελεγχόμενη μονάδα Β Δοκιμαστικά δεδομένα που προκαλούν ανώμαλη συμπεριφορά Αποτελέσματα εξόδου που αποκαλύπτουν ύπαρξη σφαλμάτων

Προσεγγίσεις επιλογής test cases Προσέγγιση ισοδύναμης διαμέρισης Προσέγγιση συνοριακών τιμών Προσέγγιση αιτίου-αποτελέσματος Προσέγγιση μαντέματος

Ισοδύναμη διαμέριση Τα δεδομένα εισόδου σε ένα σύστημα λογισμικού και τα αποτελέσματα εξόδου συνήθως κατηγοριοποιούνται σε διαφορετικές κλάσεις όπου όλα τα μέλη μιας κλάσης σχετίζονται μεταξύ τους έχουν κοινά χαρακτηριστικά (π.χ. θετικοί αριθμοί, συμβολοσειρές χωρίς κενά κτλ.) Κάθε μία από αυτές τις κλάσεις είναι μία κλάση ισοδύναμων τιμών (equivalence partition) όπου το λογισμικό συμπεριφέρεται με ισοδύναμο τρόπο για κάθε μέλος της κλάσης Ολόκληρο το σύνολο δεδομένων (η ένωση όλων των κλάσεων) υπηρετεί την πληρότητα και το μη πλεονασμό Τα test cases πρέπει να επιλέγονται από κάθε διαμέριση/κλάση μείωση πλήθους test cases στο πλήθος των κλάσεων ισοδύναμων τιμών! Αρκεί ένα δεδομένο μιας κλάσης!

Ισοδύναμη διαμέριση Διάκριση κλάσεων ισοδύναµων τιµών σε: «κλάσεις ισοδύναµων τιµών εισόδου» με δοκιμαστικά δεδομένα εισόδου Έγκυρες κλάσεις ισοδύναµων τιµών εισόδου προκαλούν οµαλή λειτουργία της μονάδας που ελέγχεται Άκυρες κλάσεις ισοδύναµων τιµών εισόδου δεν προκαλούν οµαλή λειτουργία της μονάδας που ελέγχεται «κλάσεις ισοδύναµων τιµών εξόδου» με παρατηρούμενα δεδομένα εξόδου (αποτελέσµατα εκτέλεσης) Ο προσδιορισµός των κλάσεων ισοδύναµων τιµών εισόδου βασίζεται στους περιορισµούς που υπάρχουν στα δεδοµένα εισόδου (συνθήκες εισόδου). Από τις συνθήκες εισόδου µπορούν να παραχθούν κλάσεις ισοδύναµων τιµών µε έναν ευριστικό (δηλαδή αυθαίρετο και πρακτικά σωστό) τρόπο

Ισοδύναμη διαμέριση Invalid inputs Valid inputs System Outputs

Οδηγίες για προσδιορισμό ισοδύναμων κλάσεων 1. Αν μία συνθήκη εισόδου προδιαγράφει εύρος τιμών, τότε απαιτούνται μία έγκυρη (το δεδομένο εισόδου ανήκει στο συγκεκριμένο διάστημα) και δύο άκυρες κλάσεις ισοδύναμων τιμών (το δεδομένο εισόδου δεν ανήκει στο συγκεκριμένο διάστημα) 2. Αν μία συνθήκη απαιτεί μία συγκεκριμένη τιμή, τότε απαιτούνται μία έγκυρη και δύο άκυρες κλάσεις ισοδύναμων τιμών 3. Αν µια συνθήκη εισόδου προδιαγράφει πλήθος και τη µέγιστη τιµή του, τότε απαιτούνται µια έγκυρη κλάση ισοδύναµων τιµών (το δεδοµένο εισόδου να είναι µεγαλύτερο του µηδενός και το πολύ ίσο µε τη µέγιστη τιµή του) και δυο άκυρες κλάσεις (το δεδοµένο εισόδου δεν ανήκει στο προηγούµενο διάστηµα) 4. Αν µια συνθήκη προδιαγράφει ένα σύνολο από τιµές για τις οποίες υπάρχει η υπόνοια ότι η προς έλεγχο οντότητα τις µεταχειρίζεται διαφορετικά τότε υπάρχουν τόσες έγκυρες κλάσεις ισοδύναµων τιµών όσες είναι οι τιµές του συνόλου και µια άκυρη κλάση µε µια µόνο τιµή τέτοια που να είναι διαφορετική από τις τιµές του συνόλου αυτού. 5. Αν μία συνθήκη εισόδου είναι δυαδική, τότε απαιτούνται μία έγκυρη και μία άκυρη κλάση ισοδύναμων τιμών

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

Παράδειγμα Έστω μία προδιαγραφή προγράμματος δηλώνει ότι το πρόγραμμα δέχεται από 4 μέχρι 10 εισόδους που είναι πενταψήφιοι ακέραιοι μεγαλύτεροι από 10.000 Ποιες είναι οι διαμερίσεις για αυτή την κατάσταση και οι δυνατές δοκιμαστικές τιμές εισόδου?

Προσέγγιση συνοριακών τιμών Συνοριακές τιµές (boundary values) σε µια κλάση ισοδύναµων τιµών είναι οι τιµές των άκρων της κλάσης Χρειάζεται προσοχή! Συνήθως κατά την ανάπτυξη εφαρµογής λογισµικού λαμβάνονται υπόψη μόνο οι τυπικές τιµές για τα δεδοµένα εισόδου και παραβλέπονται οι συνοριακές τιµές Αυτές όμως οδηγούν σε πολλά σφάλματα!!!! ΑΡΑ πρέπει να ελέγχονται! ΕΠΟΜΕΝΩΣ επιπλέον ορίζονται: Έγκυρες περιπτώσεις ελέγχου για τα άκρα του πεδίου ορισμού Άκυρες περιπτώσεις ελέγχου εκτός των άκρων

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

Προσέγγιση αιτίου-αποτελέσματος Χρήση γράφου που έχει: στους αρχικούς κόµβους αίτια στους ενδιάµεσους κόμβους περιορισµούς στους τελικούς κόμβους αποτελέσµατα Δημιουργία πίνακα απόφασης (decision table) από τον οποίο µπορούν µηχανιστικά να παραχθούν περιπτώσεις ελέγχου. Πλεονέκτηµα: θεωρεί συνδυασµούς συνθηκών εισόδου και οι παραγόµενες περιπτώσεις ελέγχου είναι πολύ αποτελεσµατικές ΑΛΛΑ κάποιες φορές πολύ µεγάλος γράφος και άβολος

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

Στρατηγική γυάλινου κουτιού Γνωστή και ορατή η δοµή και ο τρόπος λειτουργίας του λογισμικού Μπορούμε να επιλέξουμε χαρακτηριστικές περιπτώσεις ελέγχου Πάντως και πάλι δύσκολο να τις ελέγξουμε όλες... Η επιλογή των περιπτώσεων ελέγχου γίνεται µετά από µελέτη του κώδικα και της δοµής τής υπό έλεγχο οντότητας. Απαραίτητα για την εργασία αυτή είναι το λεπτοµερές σχέδιο της υπό έλεγχο μονάδας λογισμικού και ο πηγαίος της κώδικας Δοκιμαστικά δεδομένα Εκτέλεση ελέγχων Παραγωγή Ελεγχόμενος πηγαίος κώδικας Δοκιμαστικά δεδομένα

Επιλογή περιπτώσεων ελέγχου Κριτήρια κάλυψης για την επιλογή περιπτώσεων ελέγχου: Εκτέλεση τουλάχιστον μία φορά όλων των ανεξάρτητων µονοπατιών εκτέλεσης του ελεγχόµενου κώδικα Εκτέλεση τουλάχιστον μία φορά όλων των διακλαδώσεων ροής µε εντολές τύπου if, then, else και για την περίπτωση αληθούς συνθήκης και της ψευδούς. Εκτέλεση όλων των βρόχων επανάληψης και για οριακές τιµές επαναλήψεων, και για αριθµό επαναλήψεων εντός των ορίων. Παράδειγµα: ένας βρόγχος µε µέγιστο αριθµό επαναλήψεων ν θα πρέπει να εκτελεστεί για 0, 1, 2, µ (όπου µ < ν), ν-1, ν και ν + 1 επαναλήψεις.

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

Κώδικας παραδείγματος 1 2 3 4 5 6 7 8 9 10 11 12 Procedure TriangleSurface(a,b,c: real; var e:real; var flag: integer); Var t: real; Begin Flag:=0; e:=-1.0; If (a<=0) or (b<=0) or (c<=0) then Flag:=1 Else If (a>=b+c) or (b=>a+c) or (c=>a+b) then Flag:=1 Else Begin t:=(a+b+c)/2; e:=sqrt(t*(t-a)*(t-b)*(t-c)); End; End;

Πηγές, Acknowledgement Β. Βεσκούκης «Τεχνολογία Λογισμικού Ι», ΕΑΠ, ΠΑΤΡΑ, 2000 Χ. Αντωνόπουλος «Ανάπτυξη και Σχεδίαση Λογισμικού», Τμήμα Μηχ. Η/Υ, Τηελεπικοινωνιών και Δικτύων, Παν. Θεσσαλίας, 2007 S. L. Pfleeger, «Τεχνολογία Λογισμικού Θεωρία και πράξη», 2η έκδοση, Τόμοι Α και Β (μετάφραση, εκδ. Κλειδάριθμος) I. Sommerville, «Βασικές αρχές Τεχνολογίας Λογισμικού», 8 η αγγλική έκδοση (μετάφραση, εκδ. Κλειδάριθμος) Roger S. Pressman. Software Engineering - A Practitioner's Approach. McGraw-Hill, 6 th edition, 2005 Ε. Σκορδαλάκης, «Εισαγωγή στην Τεχνολογία Λογισμικού», Εκδόσεις Συμμετρία, 1991 Εμμ. Α. Γιακουμάκης, «Τεχνολογία Λογισμικού: Κωδικοποίηση, έλεγχος και συντήρηση λογισμικού», Εκδόσεις Α. Σταμούλης, 1993