Ελεγχος, Αξιοπιστία και Διασφάλιση Ποιότητας Λογισµικού: Αυτοµατοπιηµένος Έλεγχος Λογισµικού Τµήµα Διοίκησης Επιχειρήσεων Τει Δυτικής Ελλάδας Μεσολόγγι Δρ. Α. Στεφανή Διάλεξη 7
2 Ποιότητες που ενδιαφέρουν Συντηρητής Καλή τεκµηρίωση Κατανοητός κώδικας Καλή σχεδίαση Επαναχρησιµοποίηση Λειτουργικότητα Ευκολία χρήσης Ευκολία εκµάθησης Χρήστης Αξιοπιστία Ορθότητα Αποδοτικότητα Χαµηλό κόστος Μεταφέρσιµο Αυξάνει την παραγωγικότητα Πελάτης
Κωδικοποίηση λογισµικού
2009 ΟΠΑ -Τεχνολογία Λογισµικού Εµµ. Γιακουµάκης 4 Διαχείριση εκδόσεων Ενα σύστηµα διαχείρισης εκδόσεων προσφέρει: Την παροχή της αναίρεσης στην οµάδα ανάπτυξης µε την έννοια που την έχουµε σε ένα επεξεργαστή κειµένου. Διατήρηση διαφορετικών εκδόσεων ενός αρχείου του πηγαίου κώδικα. Ελεγχόµενη πρόσβαση στον πηγαίο κώδικα του λογισµικού. Παράλληλη εργασία των προγραµµατιστών στην ίδια βάση κώδικα (code base). Επειδή το σύστηµα κρατάει όλες τις αλλαγές στον κώδικα, η οµάδα είναι σε θέση να εντοπίσει εύκολα ποιος έχει κάνει αλλαγές στον κώδικα και γιατί.
2009 ΟΠΑ -Τεχνολογία Λογισµικού Εµµ. Γιακουµάκης 5 Διαχείριση εκδόσεων Το σύστηµα διαχείρισης εκδόσεων επιτρέπει την παραγωγή πολλών κυκλοφοριών (releases) του λογισµικού, ενώ ταυτόχρονα η οµάδα ανάπτυξης εργάζεται στη βασική γραµµή ανάπτυξης. Ένα σύστηµα διαχείρισης εκδόσεων λειτουργεί ως µία χρονοµηχανή που είναι σε θέση να µας δώσει την ακριβή εικόνα του έργου σε µία συγκεκριµένη ηµεροµηνία.
2009 ΟΠΑ -Τεχνολογία Λογισµικού Εµµ. Γιακουµάκης 6 Αποθετήριο
Έλεγχος λογισµικού Ο έλεγχος αποτελείται πάντα από την παρατήρηση ενός δείγµατος εκτελέσεων, και την παραγωγή µιας τελικής απόφασης για αυτές. Η Έλεγχος Λογισµικού (Software Testing) αφόρα τη ενδελεχή επικύρωση ότι το λογισµικό ανταποκρίνεται στις απαιτήσεις των σχεδιαστών και κατ' επέκταση χρηστών. Πολλές εταιρείες αφιερώνουν περισσότερο από 50% του χρόνου τους στον έλεγχο, π.χ., Επαγγελµατικές Κατευθύνσεις Microsoft Software Engineering: Build Software Engineering: Test Software Engineering: User Experience
Προγραµµατιστής (Programmer) Προγραµµατιστής (Programmer) Αναπτύσσει & βλέπει τον πηγαίο κώδικα Αποσφαλµατώνει Επικυρώνει την ορθότητα των µονάδων White box tester.
Δοκιµαστής (Tester) Δεν Βλέπει τον κώδικα. Επικυρώνει ότι το πρόγραµµα (συνολικά) ανταποκρίνεται στις απαιτήσεις. Black-box Tester
Βασικές αρχές Ελέγχου Λογισµικού
Οι έλεγχοι λογισµικού περιλαµβάνουν τα εξής:
Έλεγχος ορθότητας µονάδων λογισµικού αλγοριθµικά σφάλµατα υπολογιστικά λάθη και λάθη ακρίβειας σφάλµατα υπερφόρτωσης σφάλµατα ορίων ή χωρητικότητας σφάλµατα χρονισµού ή σφάλµατα συντονισµού σφάλµατα απόδοσης σφάλµατα ανάκαµψης σφάλµατα υλικού και λογισµικού συστήµατος σφάλµατα τεκµηρίωσης
Στάδια ελέγχου
Έλεγχος κλειστού κουτιού Με τον έλεγχο κλειστού κουτιού δεν έχουµε γνώση της εσωτερικής δοµής και λογικής του αντικειµένου ελέγχου. Θα πρέπει όµως µε κάποιο τρόπο να επιλέξουµε εκείνες τις δοκιµασίες ελέγχου οι οποίες έχουν τη µεγαλύτερη πιθανότητα ανακάλυψης κάποιου σφάλµατος. Θα εξετάσουµε δύο τεχνικές οι οποίες, αν και δεν εγγυώνται την ανακάλυψη όλων των σφαλµάτων, αυξάνουν την πιθανότητα εντοπισµού τους.
Έλεγχος κλειστού κουτιού Ας δούµε πρώτα ένα απλό παράδειγµα. Έστω η συνάρτηση calculatesalary(int month), της κλάσης Employee. Η συνάρτηση υπολογίζει τη µισθοδοσία ενός υπαλλήλου για κάποιο µήνα του χρόνου. Η είσοδος σε αυτή τη συνάρτηση είναι ένας ακέραιος ο οποίος αναπαριστά τον µήνα για τον οποίο υπολογίζεται η µισθοδοσία. Είναι προφανές ότι δεν µπορούµε να ελέγξουµε τη µέθοδο µε όλους τους δυνατούς ακέραιους, αλλά δε θα πρέπει και πάλι να ελέγχουµε «στην τύχη».
Διαµερισµός ισοδυναµίας Μία τεχνική η οποία χρησιµοποιείται πολύ συχνά για τον έλεγχο κλειστού κουτιού είναι ο διαµερισµός ισοδυναµίας (equivalence partitioning). Σύµφωνα µε αυτή την τεχνική θα πρέπει να χωρίσουµε το χώρο των δυνατών εισόδων σε κλάσεις ισοδυναµίας (equivalence classes), έτσι ώστε η επιλογή µίας δοκιµασίας ελέγχου από κάθε διαφορετική κλάση να θεωρείται ως αντιπροσωπευτική για όλη την κλάση. Με αυτό τον τρόπο περιορίζουµε τον αριθµό των δοκιµασιών ελέγχου, έχοντας ταυτόχρονα αυξήσει την πιθανότητα να ανακαλύψουµε κάποιο σφάλµα.
Διαµερισµός ισοδυναµίας Στο παράδειγµα της συνάρτησης calculatesalary µπορούµε να χωρίσουµε το χώρο της εισόδου της µεθόδους σε τρεις κλάσεις. 1. Η πρώτη κλάση περιλαµβάνει µία δοκιµασία ελέγχου για month µικρότερο του 1, 2. η δεύτερη κλάση περιλαµβάνει µία δοκιµασία ελέγχου για month µεταξύ 1 και 12 3. η τρίτη κλάση για month µεγαλύτερο του 12.
Διαµερισµός ισοδυναµίας Οι κλάσεις αυτές θα πρέπει να ικανοποιούν τα ακόλουθα κριτήρια: Κάθε πιθανή είσοδος ανήκει σε µια από τις κλάσεις Κανένα σύνολο δεδοµένων εισόδου δεν ανήκει σε περισσότερες από µια κλάσεις Αν η εκτέλεση του προγράµµατος δείχνει την ύπαρξη ενός σφάλµατος, όταν ένα συγκεκριµένο µέλος µιας κλάσης χρησιµοποιείται ως είσοδος, τότε το ίδιο σφάλµα µπορεί να προκύψει και µε τη χρησιµοποίηση κάθε άλλου µέλους της κλάσης ως εισόδου
Ανάλυση συνοριακών τιµών Μία δεύτερη τεχνική είναι η ανάλυση των συνοριακών τιµών (boundary value analysis). Η εµπειρία στον έλεγχο του λογισµικού έχει δείξει ότι η πιθανότητα ανακάλυψης σφαλµάτων αυξάνεται, όταν οι δοκιµασίες ελέγχου σχετίζονται µε τις συνοριακές συνθήκες (boundary conditions). Αν επανέλθουµε στο παράδειγµα της συνάρτησης calculatesalary, οι συνοριακές τιµές οι οποίες θα πρέπει να συµπεριληφθούν στις δοκιµασίες ελέγχου είναι οι τιµές 0, 1, 12, 13.
Ανάλυση συνοριακών τιµών Βλέπουµε ότι οι συνοριακές τιµές που επιλέξαµε είναι οι συνοριακές τιµές των κλάσεων ισοδυναµίας στις οποίες χωρίσαµε το χώρο των εισόδων της calculatesalary. Η ανάλυση συνοριακών τιµών συµπληρώνει το διαµερισµό ισοδυναµίας, αναλύοντας τις συνοριακές συνθήκες όχι µόνο στην είσοδο αλλά και στην έξοδο.
Πλεονεκτήµατα - Μειονεκτήµατα Υπάρχουν πλεονεκτήµατα και µειονεκτήµατα στο έλεγχο κλειστού κουτιού. Ένα προφανές πλεονέκτηµα είναι ότι ο έλεγχος ενός κλειστού κουτιού είναι ελεύθερος περιορισµών που επιβάλλει η εσωτερική δοµή και λογική του αντικειµένου που ελέγχεται. Το µειονέκτηµα του ελέγχου κλειστού κουτιού είναι ότι για ορισµένα αντικείµενα ελέγχου η παραγωγή του συνόλου των αντιπροσωπευτικών δοκιµασιών ελέγχου που να επιδεικνύει τη σωστή λειτουργικότητα σε όλες τις περιπτώσεις είναι αδύνατη.
Έλεγχος ανοικτού κουτιού Με τον έλεγχο ανοιχτού κουτιού είµαστε ενήµεροι για την εσωτερική δοµή και λογική του αντικειµένου ελέγχου. Η επιδίωξη του ελέγχου ανοιχτού κουτιού είναι να επιλέξουµε δοκιµασίες ελέγχου οι οποίες εκτελούν όλες τις εντολές ή όλες τις πιθανές διαδροµές της ροής ελέγχου µέσα στη µονάδα προγράµµατος ή στις µονάδες προγράµµατος.
Έλεγχος ανοικτού κουτιού Για να επιλέξουµε δοκιµασίες ελέγχου βασιζόµαστε στην κάλυψη του κώδικα που παρέχει ο έλεγχος. Υπάρχουν τρεις διαφορετικές κατηγορίες καλύψεων, έτσι ώστε να αξιολογήσουµε την κάλυψη του κώδικα για τις δοκιµασίες ελέγχου που επιλέγουµε. Κάλυψη εντολών (statement coverage): Κάθε εντολή της µονάδας εκτελείται τουλάχιστον µία φορά. Κάλυψη διακλαδώσεων (branch coverage): Για κάθε σηµείο απόφασης στη µονάδα επιλέγεται κάθε διακλάδωση τουλάχιστον µία φορά. Κάλυψη διαδροµών (path coverage): Κάθε διακριτή διαδροµή του προγράµµατος εκτελείται τουλάχιστον µια φορά.
Έλεγχος ανοικτού κουτιού σε γενικές γραµµές η πλήρης κάλυψη εντολών απαιτεί λιγότερες δοκιµασίες ελέγχου από την κάλυψη διακλαδώσεων, που µε τη σειρά της απαιτεί λιγότερες σε σύγκριση µε την κάλυψη διαδροµών. Όσο πιο πολύπλοκη είναι µία µονάδα, τόσο περισσότερες δοκιµασίες ελέγχου διαδροµών απαιτεί. Συνήθως ο έλεγχος διαδροµών είναι περισσότερο επιθυµητός, αφού εξετάζει το πρόγραµµα πιο ολοκληρωµένα, από τους άλλους δυο τύπους ελέγχου παρ' όλα αυτά, για πολύπλοκα προγράµµατα ο έλεγχος διαδροµών µπορεί να αποβεί υπερβολικά χρονοβόρος.
Συµπεράσµατα τόσο οι έλεγχοι κλειστού κουτιού όσο και οι έλεγχοι ανοιχτού κουτιού δεν µπορεί να είναι εξαντλητικοί. Στους ελέγχους κλειστού κουτιού δεν µπορούµε πάντα να εξαντλήσουµε το χώρο δεδοµένων εισόδου. Από την άλλη µεριά στον έλεγχο ανοιχτού κουτιού δεν µπορούµε να εξαντλήσουµε όλες τις πιθανές διαδροµές εκτέλεσης της λογικής του λογισµικού. Ο έλεγχος κλειστού κουτιού πάσχει από αβεβαιότητα για το αν οι δοκιµασίες ελέγχου που επιλέχθηκαν θα ανακαλύψουν ένα συγκεκριµένο σφάλµα. Ο έλεγχος ανοιχτού κουτιού είναι ανοιχτός στον κίνδυνο να δοθεί περισσότερη προσοχή από όση θα έπρεπε στην εσωτερική δοµή του κώδικα.
Συµπεράσµατα Υπάρχει επίσης ο κίνδυνος να καταλήξουµε σε έναν έλεγχο του τι κάνει το πρόγραµµα και όχι του τι θα έπρεπε να κάνει. Όταν ελέγχουµε το λογισµικό, δε χρειάζεται να επιλέξουµε αποκλειστικά µεταξύ του ανοικτού και του κλειστού κουτιού. Μπορούµε να θεωρήσουµε αυτούς τους δύο τρόπους ελέγχου ως τα δύο άκρα µιας νοητής συνεχούς γραµµής ελέγχου. Κάθε προσέγγιση ελέγχου µπορεί να βρίσκεται κάπου ενδιάµεσα. Το ποια προσέγγιση θα διαλέξουµε εξαρτάται από ένα σύνολο παραγόντων στους οποίους συµπεριλαµβάνονται οι ακόλουθοι: ο αριθµός των πιθανών λογικών διαδροµών, η φύση των δεδοµένων εισόδου, η έκταση και n ποσότητα των υπολογισµών που απαιτούνται και η πολυπλοκότητα των αλγορίθµων
Αυτόµατοι έλεγχοι Το σκεπτικό των αυτόµατων ελέγχων µονάδας είναι ότι αντί να γράψουµε µία δοκιµασία ελέγχου στο σηµειωµατάριό µας, γράφουµε κώδικα που την υλοποιεί. Ο κώδικας ελέγχου αποτελείται από οδηγούς µονάδας (module drivers) οι οποίοι εκτελούν και τους ελέγχους µονάδας. Με την κωδικοποίηση των δοκιµασιών ελέγχου χωρίζουµε τον κώδικα σε δύο βασικές κατηγορίες: στον κώδικα παραγωγής (production code) και στον κώδικα ελέγχου (testing code). Ο κώδικας παραγωγής παράγει το τελικό προϊόν λογισµικού που παραδίδεται στον πελάτη, ενώ ο κώδικας ελέγχου συντηρείται για την εκτέλεση των ελέγχων µονάδας.
Ιδιότητες αυτόµατων ελέγχων Αυτόµατοι. Όλοι οι έλεγχοι θα πρέπει να είναι πλήρως αυτοµατοποιηµένοι. Διεξοδικοί. Όλοι οι έλεγχοι θα πρέπει να ελέγχουν ό,τι µπορεί να χαλάσει. Επαναλήψιµοι. Κάθε δοκιµασία ελέγχου θα πρέπει να εκτελείται συνέχεια και να παράγει τα ίδια αποτελέσµατα. Ανεξάρτητοι. Όλες οι δοκιµασίες ελέγχου θα πρέπει να εκτελούνται ανεξάρτητα. Επαγγελµατικοί. Όλες οι δοκιµασίες ελέγχου έχουν µόνιµο χαρακτήρα.
Εργαλεία Ταξινόµηση εργαλείων Μπορούµε να διαχωρίσουµε τα εργαλεία λογισµικού στις παρακάτω κατηγορίες: Εργαλεία ανάλυσης και ελέγχου του αρχικού κώδικα (source program analysis and testing tools). Εργαλεία διαχείρισης, ελέγχου και συντήρησης (software management, control and maintenance tools). Εργαλεία προδιαγραφών και ανάλυσης απαιτήσεων (Requirements, design, specification, and analysis tools).
Εργαλεία Εργαλεία κατασκευής και γέννησης προγραµµάτων (program construction and generation tools). Εργαλεία εξοµοίωσης και µοντελοποίησης (software modeling and simulation tools). Εργαλεία υποστήριξης / περιβάλλοντα προγραµµατισµού (software support systems / programming environment tools).
Διορθωτές Ένας καλός διορθωτής (editor) προγραµµάτων υποστηρίζει τις παρακάτω δυνατότητες: Εύρεση και αλλαγή µε κανονικές εκφράσεις (regular expressions) Αυτόµατη στοίχιση (indentation) Ταίριαγµα παρενθέσεων, αγκυλών, κ.λπ. Χρωµατισµός σύµφωνα µε τη σύνταξη της γλώσσας Αναίρεση πολλαπλών επιπέδων, Σύνδεση µε πρόγραµµα βοήθειας Σύνδεση µε περιβάλλον µεταγλώττισης Ταυτόχρονη διόρθωση σε πολλαπλά παράθυρα και αρχεία Ιεραρχική απόκρυψη περιοχών Αναγνώριση της σύνταξης της γλώσσας και αυτόµατος σχηµατισµός του προγράµµατος Συµπλήρωση ή επιλογή όρων της γλώσσας
Διερµηνευτές και µεταγλωττιστές Εκτός από τη συµβολή τους στην εκτέλεση του πηγαίου κώδικα οι διερµηνευτές και µεταγλωττιστές παρέχουν συχνά και τις παρακάτω ευκολίες: Εύρεση σηµασιολογικών λαθών (semantic errors). Δηµιουργία βάσης δεδοµένων του προγράµµατος Βελτιστοποίηση Μεταγλώττιση για άλλα περιβάλλοντα εκτέλεσης (cross compiling)
Γεννήτριες κώδικα Μια σειρά από εργαλεία και τεχνικές βασίζονται στην αυτόµατη δηµιουργία κώδικα. Παραδείγµατα: Γεννήτριες εφαρµογών (application generators) (ονοµάζονται και wizards). Γεννήτριες εκθέσεων (report generators)
Αποσφαλµατωτές Ο αποσφαλµατωτής επιτρέπει: Την εκτέλεση του προγράµµατος βήµα προς βήµα Την εκτέλεση ολόκληρης κλήσης συνάρτησης ή µεθόδου σε ένα βήµα Τον προσδιορισµό σηµείων διακοπής (breakpoints) στην εκτέλεση του κώδικα Τον προσδιορισµό σηµείων διακοπής δεδοµένων (data breakpoints) Την εµφάνιση τιµών των µεταβλητών Την εκτέλεση µέχρι ένα σηµείο Την εµφάνιση της αλληλουχίας κλήσεων των συναρτήσεων η µεθόδων Την εύρεση του σηµείου του προγράµµατος όπου σηµειώθηκε κάποιο πρόβληµα
Αναλυτές κατανοµής Ένας αναλυτής κατανοµής εκτέλεσης (execution profiler) επιτρέπει: Την εύρεση των τµηµάτων του προγράµµατος που καταναλώνεται ο περισσότερος χρόνος. Την εµφάνιση του δυναµικού δέντρου κλήσης (dynamic call graph). Την ανάλυση του ποσοστού κάλυψης της εκτέλεσης (execution coverage).
Software Integration Testing Πρόκειται για το επίπεδο ελέγχου λογισµικού στο οποίο οι ατοµικές µονάδες του συστήµατος συνδυάζονται και ελέγχονται ως οµάδα. Σκοπός του Integration ή Incremental Testing να ελέγξει και να παρουσιάσει τα σφάλµατα των αλληλεπιδράσεων και των διεπαφών µεταξύ των ενοτήτων κώδικα(modules)/ συστατικών του συστήµατος και να βεβαιώσει ότι η αρχιτεκτονική του συστήµατος έχει σχεδιαστεί σωστά κατά την φάση σχεδίασης. Το Integration Testing εκτός του ότι επιτρέπει την διεξαγωγή ελέγχου των µονάδων(unit tests) του συστήµατος µπορεί παράλληλα να εξετάζει και την συνολική ενσωµάτωση του συστήµατος στα όρια των ενοτήτων κώδικα.
Μέθοδοι προσέγγισης Integration Testing Big bang Αποτελεί τον συνδυασµό/ενσωµάτωση όλων των κοµµατιών του συστήµατος ταυτοχρόνως. Βασικό πλεονέκτηµα την εν λόγω στρατηγικής είναι η απλότητά της ως προς την εφαρµογή της (ενδείκνυται κυρίως για µικρά συστήµατα). Στον αντίποδα όµως, παρουσιάζει σηµαντικά µειονεκτήµατα, ως προς την διαδικασία αποσφαλµάτωσης (debugging), την διαδικασία αποµόνωσης σφαλµάτων και την διαδικασία επικύρωσης των αποτελεσµάτων ελέγχου.
Bottom Up Ο Bottom Up έλεγχος ξεκινάει µε τον έλεγχο των µονάδων για τις ενότητες κώδικα εκείνες που βρίσκονται στην βάση του γράφου εξαρτήσεων του συστήµατος. Εδώ οι υποψήφιες ενότητες κώδικα για ένταξη στην επόµενη παρτίδα ελέγχου εξαρτώνται καθαρά από τον γράφο εξαρτήσεων.
Bottom Up
Top Down Ο Top Down έλεγχος ξεκινάει από την ανώτερη ιεραρχικά ενότητα κώδικα και προχωράει προς τα κάτω επίπεδα ιεραρχίας αναλόγως της δοµής του γραφήµατος εξαρτήσεων του συστήµατος. Κατά την διαδικασία αυτή µπορεί να απαιτηθεί η αντικατάσταση ενοτήτων (modules) χαµηλότερων επιπέδων του γραφήµατος µε επιτυχή επίπεδα stub ενοτήτων κώδικα.
System Integration Testing To System Integration Testing(SIT) είναι µια υψηλού επιπέδου ελεγκτική διαδικασία λογισµικού µέσω της οποίας οι µηχανικοί ελέγχου λογισµικού µπορούν να εξακριβώσουν αν όλα τα συσχετιζόµενα συστήµατα διατηρούν την ακεραιότητα των δεδοµένων τους και µπορούν να λειτουργήσουν σε συντονισµό µε άλλα συστήµατα µέσα στο ίδιο περιβάλλον. Η διεργασία αυτή ελέγχου διαβεβαιώνει ότι όλα τα επιµέρους συστατικά µέρη του συστήµατος έχουν ενσωµατωθεί καταλλήλως στο συνολικό σύστηµα και µπορούν να παρέχουν τα αναµενόµενα αποτελέσµατα.
System Integration Testing Ο System Integration έλεγχος επαληθεύει την ακεραιότητα των δεδοµένων µεταξύ των διαφορετικών εξαρτηµάτων που απαρτίζουν ένα συγκεκριµένο και ενοποιηµένο σύστηµα. Από την µεριά εφαρµογής του, ο System Integration έλεγχος εστιάζει την προσοχή του, πρώτον στην αρχικοποίηση της συνδεσιµότητας των συστατικών µερών του συστήµατος και δεύτερον στην δυνατότητα πρόσβασης στα πραγµατικά δεδοµένα που διέρχονται µεταξύ των συστατικών µερών.
System Integration Testing Οι περιπτώσεις δοκιµής για τον SIT έλεγχο αναπτύσσονται χρησιµοποιώντας τεχνικές σχεδιασµού όπως: Δοκιµές Περιπτώσεων Χρήσης Use Case Testing Δοκιµές Εναλλαγής Καταστάσεως State Transition Testing Δοκιµές Φόρτωσης Load Testing Δοκιµές Ευχρηστίας Usability Testing Δοκιµές Όγκου Volume Testing Δοκιµές βασισµένες σε γράφηµα Graph-based Testing Δοκιµές Πίνακα Αποφάσεως Decision Table Testing
System Validation Testing Σκοπός του System Validation Testing είναι να επικυρώσει ότι το σύστηµα καλύπτει όλες τις απαιτούµενες προδιαγραφές και απαιτήσεις όπως αυτές έχουν οριστεί. Αυτές είναι: Απαιτήσεις Απόδοσης Απαιτήσεις Εξωτερικών Παραγόντων Απαιτήσεις Μάρκετινγκ Λειτουργικές Απαιτήσεις Μη-Λειτουργικές Απαιτήσεις Ηλεκτροµηχανολογικές Απαιτήσεις
Τρέχουσα τάση στο λογισµικό