Δοκιμές Τυπικός σχεδιασμός υπηρεσιών και πρωτοκόλλων 11 Ιουνίου 2012 1/45
Δοκιμές συμμόρφωσης Μη λειτουργικές δοκιμές 2/45
Σφάλματα & δοκιμές Οι δυο βασικές αρχές για τα σφάλματα είναι ότι θα συμβούν οπωσδήποτε και ότι όσο η διόρθωσή τους αναβάλλεται για επόμενη φάση σχεδιασμού και ανάπτυξης, τόσο πιο πολύ κοστίζουν. Με όρους κόστους ενός προϊόντος, ένα σημαντικό μέρος οφείλει να αναλωθεί για την πραγματοποίηση δοκιμών. Το 2007 σύμφωνα με τους Everett και McLeod μόνο 3 από 21 ερωτηθέντα πανεπιστήμια στις ΗΠΑ έδιναν εκπαίδευση σχετική με δοκιμές, ενώ καλύτερη ήταν η κατάσταση στην Ευρώπη όπου βρέθηκαν εφτά στα δέκα [1]. 3/45
I Να διαπιστωθεί ότι το προϊόν είναι σύμφωνο με το σχεδιασμό και λειτουργεί όπως αναμενόταν και να γίνουν οι απαραίτητες διορθώσεις εφόσον φανούν αποκλίσεις. Να διαπιστωθεί ότι είναι ικανό να εξυπηρετήσει τους σκοπούς χρήσης, για τους οποίους έχει σχεδιασθεί και μάλιστα σε μια ποικιλία πιθανών συνθηκών περιβάλλοντος. Να διαπιστωθεί ότι το σύστημα επιλύει το σωστό πρόβλημα λαμβάνοντας υπόψη τους υπάρχοντες περιορισμούς (π.χ. φυσικούς νόμους, επιχειρηματικούς κανόνες, υποθέσεις λειτουργίας). Να ελεγχθεί κατά πόσο ικανοποιεί απαιτήσεις σχετικές με πρότυπα και κανονισμούς (συμμόρφωσης, ασφάλειας κ.α.). 4/45
II Να διαπιστωθεί η αντοχή του και τα όρια της χρήσης του. Να γίνει μια αρχική εκτίμηση της επίδοσης του συστήματος. Να διαπιστωθεί κατά πόσο το προϊόν είναι πλέον έτοιμο για παραγωγή και εισαγωγή στην αγορά. Να γίνουν εκτιμήσεις για πιθανά μελλοντικά προβλήματα στη χρήση του και να εκτιμηθούν οι πιθανές ζημιές που θα προκληθούν απ αυτά (εκτίμηση του επιχειρηματικού κινδύνου). 5/45
Τι δείχνουν οι δοκιμές Οι δοκιμές δεν είναι δυνατό να εγγυηθούν πλήρως την ικανότητα ενός συστήματος να λειτουργήσει σωστά. Μια δοκιμή μπορεί να δείξει σφάλματα, αλλά δεν μπορεί να αποδείξει την ορθότητα. Για να αποδειχθεί π.χ. στο λογισμό του Hoare ότι ικανοποιείται μια συγκεκριμένη προδιαγραφή από μια διεργασία πρέπει να εξετασθεί η ισχύς της σε όλα τα ίχνη της διεργασίας Στη γλώσσα των πεπερασμένων αυτομάτων η διαπίστωση μιας ιδιότητας ή απουσία ενός σφάλματος μπορεί να διαπιστωθεί με βεβαιότητα μόνο μετά από την εξαντλητική έρευνα του χώρου των καταστάσεων. 6/45
Το κόστος των αστοχιών μέσα στον κύκλο ζωής I Όσο αργότερα ανακαλυφθεί ένα πρόβλημα, τόσο πιο μεγάλο είναι το κόστος διόρθωσής του. Εάν γίνει ένα σφάλμα στην αρχική καταγραφή απαιτήσεων και διορθωθεί αμέσως, η διόρθωση είναι σχεδόν ανέξοδη. Αν η λανθασμένη απαίτηση μπει στο τυπικό μοντέλο, η διαπίστωση του σφάλματος θα γίνει μόνο αν γίνουν αρκετοί έλεγχοι πάνω στο τυπικό μοντέλο και στη συνέχεια θα χρειαστεί διόρθωση του μοντέλου. Η διόρθωση θα συμπαρασύρει τον ανασχεδιασμό και άλλων τμημάτων του συνόλου. Αν φτάσει στην υλοποίηση, θα γίνει μια πιο ακριβή διόρθωση. Αν φτάσει και στην ολοκλήρωση, είναι πιθανό να χρειασθούν αλλαγές και σε άλλα συστήματα, με τα οποία το εν λόγω σύστημα έρχεται σε αλληλεπίδραση. 7/45
Το κόστος των αστοχιών μέσα στον κύκλο ζωής II Αν το λάθος περάσει στην παραγωγή, θα υπάρξει ένας ολόκληρος πληθυσμός αντιγράφων, μέσα στα οποία θα έχει πολλαπλασιασθεί. Ακόμη κι αν διαπιστωθεί πριν φτάσουν στην αγορά, πρέπει να γίνουν μεταβολές σε καθένα εξ αυτών ή να καταστραφούν. Αν ήδη έχουν φτάσει στην αγορά, πρέπει επιπροσθέτως να γίνει απόσυρση, ενώ είναι πιθανό να δημιουργηθούν απαιτήσεις αποζημίωσης. 8/45
Κόστος δοκιμών και κόστος σφαλμάτων Το κόστος αυξάνεται εκθετικά με κάθε καθυστέρηση στην αποκάλυψη του προβλήματος και με το πέρασμά του στην επόμενη φάση του κύκλου ζωής του προϊόντος. Βασική προϋπόθεση για όλα τα παραπάνω είναι ότι το κόστος των δοκιμών είναι μικρότερο από το αναμενόμενο κόστος που θα επιφέρουν τα σφάλματα. Η συνθήκη αυτή ισχύει συνήθως, αλλά όχι πάντοτε, όπως π.χ. στην περίπτωση των δοκιμών στον Κρόνο. Όμως οι ζημιές κατά κανόνα τείνουν να υποεκτιμηθούν. Με την έννοια αυτή οι δοκιμές είναι απαραίτητες σε μια επιχείρηση για να μειωθεί ο επιχειρηματικός κίνδυνος. Μπορούν οι δοκιμές να ανιχνεύσουν τα σφάλματα; Η τρέχουσα εμπειρία είναι ότι σχεδόν όλα τα σημαντικά λάθη ανιχνεύονται με βεβαιότητα 80 ως 90 %. 9/45
I Είναι σημαντικό να προϋπάρχει της δοκιμής η περιγραφή της, ώστε να είναι σαφές στο δοκιμαστή τι πρέπει να κάνει και να μπορεί να επαναληφθεί στο μέλλον. Αρχικά δίνεται ένα όνομα στη δοκιμή, ώστε να μπορεί να γίνει πιο εύκολα η διαχείρισή της μέσα στο σύνολο των δοκιμών. Στη συνέχεια περιγράφεται ο σκοπός της δοκιμής, μολονότι θεωρητικά αυτός δεν είναι ουσιώδες μέρος της, δηλαδή η δοκιμή μπορεί να γίνει από τον δοκιμαστή και χωρίς να γνωρίζει το σκοπό. Περιγράφονται οι αρχικές συνθήκες εκτέλεσης της δοκιμής. 10/45
II Η καρδιά της περιγραφής είναι το διαδικαστικό της μέρος, δηλαδή μια σειρά από ενέργειες, τις οποίες κάνει ο δοκιμαστής χρησιμοποιώντας κάποια διεπαφή (interface), μέσω της οποίας στέλνει εντολές και παίρνει πίσω απαντήσεις. Οι εντολές μπορεί να εξαρτώνται από τις μέχρι στιγμής απαντήσεις. Συγκρίνονται οι απαντήσεις με τις αναμενόμενες απαντήσεις όταν η λειτουργία του συστήματος είναι ορθή και δίνεται η ετυμηγορία, δηλαδή ένα δυαδικό αποτέλεσμα, pass/fail εφαρμόζοντας ένα σαφές κριτήριο. 11/45
Διαχείριση της διαδικασίας δοκιμών I H διεξαγωγή των δοκιμών είναι σκόπιμο να αποτελεί χωριστό έργο (project) μέσα στο συνολικό έργο, με δικό του χρονοδιάγραμμα και χωριστό προϋπολογισμό. Το έργο αυτό μπορεί να είναι δοσμένο σε διαφορετική ομάδα. Oργανώνουν πιο αποτελεσματικές δοκιμές αυτοί που έχουν εμπλακεί στο σχεδιασμό και την υλοποίηση ενός συστήματος ή άλλοι? Ο διαχωρισμός σε δυο ομάδες, φιλίων και αντιπάλων δυνάμεων, εκτός από απλώς χρήσιμος μπορεί να είναι επιβεβλημένος από συμβατικούς όρους εκτέλεσης του έργου. 12/45
Διαχείριση της διαδικασίας δοκιμών II Συνήθως οι δοκιμές είναι πολυπληθείς, οπότε αμέσως τίθεται το ζήτημα της ταξινόμησής τους, προκειμένου να μπορούν να ευρεθούν περαιτέρω και αξιοποιηθούν για τη διόρθωση, την περαιτέρω δοκιμή και την αξιολόγηση του συστήματος. Επίσης τίθεται το πρόβλημα της σειράς με την οποία θα γίνουν, του χρόνου που θα τους διατεθεί, των ανθρώπινων πόρων και των υποδομών που θα διατεθούν σ αυτές, των διορθώσεων που θα επακολουθήσουν και του προγραμματισμού επαναλήψεων των δοκιμών. 13/45
Δοκιμές με τη βοήθεια υπολογιστή Η διεξαγωγή δοκιμών μολονότι μπορεί να γίνει χειρωνακτικά, δηλαδή απ ευθείας από ανθρώπους δοκιμαστές, σήμερα βασίζεται σε αυτόματους δοκιμαστές, δηλαδή σε διατάξεις και εργαλεία που εκτελούν μαζικά δοκιμές με τη βοήθεια υπολογιστή. Στην περίπτωση των αυτοματοποιημένων δοκιμών τα διαχειριστικά θέματα της προηγούμενης παραγράφου αυτοματοποιούνται κι αυτά εν μέρει, δηλαδή χρειάζονται τα αντίστοιχα εργαλεία και οι διαδικασίες. 14/45
Κρίσιμα τμήματα ενός συστήματος Έχει διαπιστωθεί στατιστικά ότι σ ένα σύνθετο οργανισμό ισχύει η αρχή 80/20, που υποδηλώνει ότι μόνο το 20% των τμημάτων του είναι πραγματικά ουσιώδη και κρίσιμα στην παραγωγή του. Με την έννοια αυτή οι δοκιμές πρέπει να επικεντρώνονται στο κρίσιμο 20 %. Τα σφάλματα είναι κατά κανόνα συστηματικά με την έννοια ότι αποτελούν αποτέλεσμα κακής οργάνωσης και κακής διαδικαστικής πρακτικής, γεγονός που μπορεί να αποκαλύψει πού πρέπει να γίνουν οργανωτικές μεταβολές με μακροπρόθεσμη επίδραση στη μείωση των σφαλμάτων. 15/45
Επίπεδα δοκιμών Ένα σύστημα αναπτύσσεται συνήθως σε επίπεδα. Όταν τελειώσουμε τον έλεγχο κάθε συνιστώσας χωριστά πρέπει στη συνέχεια να ελέγξουμε πώς αυτές συνεργάζονται. Στη συνέχεια πρέπει να ελέγξουμε αν τα υποσυστήματα συνεργάζονται ορθά μεταξύ τους, οπότε έχουμε δοκιμές σε επίπεδο συνολικού συστήματος. 16/45
Μαντεία δοκιμών Όπως αναφέρθηκε παραπάνω για την εξαγωγή ετυμηγορίας στο τέλος της δοκιμής χρειάζεται η γνώση του ορθού εξαγόμενου, την οποία μπορεί να εξασφαλίσει ένα μαντείο. Τα αποτελέσματα του μαντείου μπορούν να εξασφαλισθούν με διάφορους τρόπους, όπως με την παρέμβαση ενός ανθρώπου που θα καθορίσει το ορθό αποτέλεσμα, χρησιμοποιώντας ένα χωριστό εργαλείο που κάνει τον ίδιο υπολογισμό, χρησιμοποιώντας ένα εξομοιωτή του συστήματος, έχοντας αποτελέσματα από προηγούμενη έκδοση του συστήματος ή έκδοση που λειτουργεί σε άλλες συνθήκες, έχοντας ένα κατάλογο από γνωστά αποτελέσματα υπό γνωστές συνθήκες κ.α. 17/45
Ταξινόμηση των δοκιμών ως προς τη γνώση του συστήματος I Το υπό δοκιμή σύστημα, γνωστό και ως System Under Test (SUT), μπορεί να είναι πλήρως γνωστό, εν μέρει γνωστό ή τελείως άγνωστο στον δοκιμαστή. Η ύπαρξη ή απουσία αυτής της γνώσης μπορεί να είναι επιβάλλεται από πραγματικές συνθήκες και απαιτήσεις, όπως (α) Ο δοκιμαστής να ανήκει σε ανεξάρτητο φορέα ή στον πελάτη, ενώ το σύστημα είναι μυστικό της κατασκευάστριας εταιρίας, (β) να υπάρχει όρος του συμβολαίου εκτέλεσης του συστήματος οι δοκιμές να γίνουν από ανεξάρτητο φορέα. Οπωσδήποτε οι αρχικές τουλάχιστον δοκιμές του ίδιου του κατασκευαστή γίνονται με γνώση του συστήματος. 18/45
Ταξινόμηση των δοκιμών ως προς τη γνώση του συστήματος II Σε ορισμένες όμως περιπτώσεις, μολονότι η γνώση αυτή είναι διαθέσιμη, π.χ. όταν οι δοκιμές θα γίνουν εσωτερικά στην κατασκευάστρια εταιρία, αλλά από διαφορετικό εξειδικευμένο τμήμα, μπορεί να θεωρηθεί πλεονέκτημα να γίνουν οι δοκιμές χωρίς να δοθεί η εν λόγω γνώση, επειδή συχνά αυτή οδηγεί σε δοκιμές προκατειλημμένες. Εκτός της γνώσης που μπορεί να διαθέτει ή να μη διαθέτει ο δοκιμαστής, μπορεί να ποικίλλει η δυνατότητά του να επέμβει στο σύστημα. Με τις παρατηρήσεις αυτές οι δοκιμές χαρακτηρίζονται συνήθως ως δοκιμές μαύρου, λευκού και γκρίζου κουτιού. 19/45
Δοκιμές λευκού κουτιού I Aποσκοπούν στην επαλήθευση της ορθότητας ενός μέρους του συστήματος δεδομένης της πλήρους γνώσης του. Μερικές από τις τεχνικές που χρησιμοποιούνται είναι οι εξής [1]: Κάλυψη των εντολών του κώδικα: Η κάλυψη υπολογίζεται ως ποσοστό των γραμμών του κώδικα που έχουν εκτελεσθεί. Όσες γραμμές δεν έχουν εκτελεσθεί κατά τις δοκιμές είναι πιθανές πηγές προβλημάτων σε επόμενη φάση. Κάλυψη των διακλαδώσεων (σημείων απόφασης) του κώδικα: Η κάλυψη υπολογίζεται ως ποσοστό των διακλαδώσεων που έχουν εκτελεσθεί. 20/45
Δοκιμές λευκού κουτιού II Κάλυψη σύνθετων συνθηκών: Οι διακλαδώσεις που εξαρτώνται από την έξοδο ενός σύνθετου λογικού ελέγχου μπορούν να πάρουν τις τιμές TRUE ή FALSE για διαφορετικούς συνδυασμούς τιμών των εισόδων. Στον προηγούμενο έλεγχο ένας συνδυασμός για κάθε μία από τις δύο τιμές εξόδου είναι αρκετός. Στον παρόντα έλεγχο εξετάζονται όλοι οι συνδυασμοί των εισόδων που θα βγάλουν την τελική τιμή εξόδου. Κάλυψη των μονοπατιών (paths) του κώδικα: Ως μονοπάτι θεωρείται κατά κανόνα μια ακολουθία εντολών που αρχίζει από την πρώτη εκτελέσιμη εντολή, περνάει από διάφορες διακλαδώσεις, εισαγωγές δεδομένων κ.λπ. και καταλήγει σε κάποια εντολή τερματισμού ή επιστροφής (return, stop, end, exit). 21/45
Δοκιμές λευκού κουτιού III Κάλυψη των βρόχων: Ένας βρόχος θεωρείται ότι έχει καλυφθεί εφόσον φτάσει και στην τελευταία του επανάληψη. 22/45
Δοκιμές μαύρου κουτιού I Οι δοκιμές μαύρου κουτιού γίνονται προκειμένου να διαπιστωθεί αν το σύστημα καλύπτει τις ανάγκες που προκύπτουν από τη χρήση του, είναι δηλαδή δοκιμές που αντανακλούν περισσότερο την οπτική γωνία του χρήστη και λιγότερο του σχεδιαστή-κατασκευαστή. Στις εν λόγω δοκιμές θεωρείται διαθέσιμο μόνο το εκτελέσιμο σύστημα, χωρίς να είναι διαθέσιμος ο κώδικας, αν πρόκειται για λογισμικό. Διαθέσιμες είναι φυσικά και οι προδιαγραφές του συστήματος, που μπορεί να περιλαμβάνουν use cases, περιγραφές του περιβάλλοντος όπου θα λειτουργήσει το σύστημα κ.λπ. Με βάση αυτά δημιουργούνται δεδομένα εισόδου, που θα διοχετευθούν στο σύστημα και καταγράφονται οι αντίστοιχες έξοδοι. 23/45
Δοκιμές μαύρου κουτιού II Η προστιθέμενη αξία από τις δοκιμές μαύρου κουτιού προκύπτει από το γεγονός ότι είναι πιο κοντά στις πραγματικές συνθήκες λειτουργίες και από το γεγονός ότι ιδανικά εκτελούνται από δοκιμαστές που δεν μετέχουν στην ομάδα υλοποίησης του συστήματος, άρα δεν είναι προκατειλημμένοι. 24/45
Η ανάγκη να χρησιμοποιηθούν πρότυπα για μια συγκεκριμένη σειρά δοκιμών μπορεί να δημιουργείται από διαφορετικές αιτίες, όπως είναι η πρακτική μιας εταιρίας να οργανώνει τις εργασίες της με συγκεκριμένα πρότυπα και να τα επικαλείται ως ένδειξη ποιοτικής προσέγγισης, η επιθυμία σχεδιασμού προϊόντων που συμμορφώνονται με δεδομένα πρότυπα, η υποχρέωση που απορρέει από ένα συγκεκριμένο συμβόλαιο ανάθεσης έργου κ.ο.κ. 25/45
Πρότυπα για λογισμικό γενικά Γνωστά πρότυπα στην περιοχή του λογισμικού είναι το ΙΕΕΕ 829 [3] για την τεκμηρίωση των δοκιμών (test documentation), το IEEE 1008 [4] για δοκιμές μονάδων (unit testing) και το BS 7925-2 [5] για τη δοκιμή συνιστωσών (software component testing). Τα πρότυπα αυτά πρόκειται να αντικατασταθούν από το υπό διαμόρφωση ολοκληρωμένο ISO/IEC 29119 Software Testing standard, 1 που αναμένεται να ολοκληρωθεί τον Οκτώβριο του 2012. Σχετικό επίσης είναι το IEEE 1012-2004 standard [6] που καθορίζει διαδικασίες για επαλήθευση και επικύρωση (verification & validation) λογισμικού. 1 http://softwaretestingstandard.org 26/45
Πρότυπα για δοκιμή κατανεμημένων συστημάτων I Οι ανάγκες αυτές καλύπτονται κυρίως από τις συστάσεις της ITU-T X.290, X.291 και X.292 [7, 8, 9]. Με την τελευταία εξ αυτών καθορίσθηκε η τυποποιημένη συγγραφή των δοκιμών, δηλαδή μια γλώσσα συγγραφής δοκιμών με μορφή πινάκων, που είναι γνωστή ως TTCN (Tree and Tabular Combined Notation) [9]. Η δεύτερη έκδοση αυτής της γλώσσας περιέχεται στο πρότυπο ISO/IEC 9646-3 (ή ITU-T Recommendation X.292) του 1998 [10]. 27/45
Πρότυπα για δοκιμή κατανεμημένων συστημάτων II Από τον Οκτώβριο του 2000 έχει αντικατασταθεί από την Testing and Test Control Notation, που είναι πλέον μια γλώσσα προγραμματισμού εξειδικευμένη στη συγγραφή δοκιμών και είναι γνωστή ως TTCN-3. Περιγράφεται στη σύσταση ETSI ES 201 873-1 [11] και ομοίως στην ITU-T Recommendation Z.140 [12], ενώ με την ITU-T Recommendation Z.141 δίνεται η δυνατότητα παρουσίασης του κώδικα με τη μορφή πινάκων, όπως δηλαδή στις παλιότερες TTCN. 28/45
Δοκιμές συμμόρφωσης Μη λειτουργικές δοκιμές Δοκιμές συμμόρφωσης Σύμφωνα με την σύσταση Χ.292 [7] διακρίνονται τέσσερα είδη δοκιμών, ως εξής: Βασικές δοκιμές διασύνδεσης, που δείχνουν ότι εκ πρώτης όψεως υπάρχει κάποια συμμόρφωση. Δοκιμές ικανότητας, που ελέγχουν αν οι παρατηρούμενες ικανότητες του συστήματος συμμορφώνονται με τις στατικές απαιτήσεις και απαιτούμενες ικανότητες. Δοκιμές συμπεριφοράς, που ελέγχουν όσο πιο εξαντλητικά είναι δυνατό την δυναμική συμπεριφορά. Δοκιμές επίλυσης ειδικών θεμάτων συμμόρφωσης, που αποφαίνονται αν το σύστημα σέβεται συγκεκριμένες απαιτήσεις και δίνουν μια τελική απάντηση. Οι δοκιμές αυτές στο βαθμό που είναι ειδικές δεν τυποποιούνται. 29/45
Δοκιμές συμμόρφωσης Μη λειτουργικές δοκιμές Διάταξη του εξοπλισμού της δοκιμής I Προκειμένου να γίνει μια δοκιμή πρέπει να συνδεθεί η υπό δοκιμή υλοποίηση (Implementation under test -IUT) με τις συσκευές, που εξυπηρετούν τους σκοπούς της δοκιμής (δοκιμαστές) και έχουν την αποστολή να τροφοδοτήσουν με δεδομένα την IUT και να καταγράψουν τις αντιδράσεις της. Επίσης ορίζονται σημεία αναφοράς ανάμεσα στις συσκευές. Οι αλληλεπιδράσεις που εκδηλώνονται κατά τη δοκιμή ελέγχονται και παρατηρούνται στα σημεία ελέγχου και παρατήρησης (Points of Control and Observation, PCOs). Στην περίπτωση που έχουμε δύο δοκιμαστές, ο ένας ονομάζεται ανώτερος δοκιμαστής και ο άλλος κατώτερος δοκιμαστής. Οι δοκιμαστές θεωρούνται εξοπλισμένοι με τις απαραίτητες λειτουργίες (functions). 30/45
Δοκιμές συμμόρφωσης Μη λειτουργικές δοκιμές Διάταξη του εξοπλισμού της δοκιμής II Ένα σύστημα δοκιμάζεται με μια σειρά δοκιμών (test suite). Οι δοκιμές μέσα στην ίδια σειρά μπορούν να οργανωθούν ιεραρχικά. Κάθε χωριστή δοκιμή ονομάζεται περίπτωση δοκιμής (test case), ενώ διαφορετικές περιπτώσεις μπορούν να ομαδοποιηθούν σε ομάδες δοκιμών (test groups) με κάποιο κοινό σκοπό. Τέλος, μια περίπτωση μπορεί να χωριστεί σε βήματα για λόγους αναφοράς σε αυτά. 31/45
Δοκιμές συμμόρφωσης Μη λειτουργικές δοκιμές Τι περιλαμβάνει μια περίπτωση δοκιμής Η κάθε δοκιμή (περίπτωση δοκιμής) καθορίζει τα εξής: 1. Όλες τις ακολουθίες γεγονότων, που προβλέπονται γαι την επίτευξη ενός σκοπού. 2. Τον τρόπο, με τον οποίο το σύστημα θα φτάσει στην επιθυμητή αρχική κατάσταση, εφόσον η συγκεκριμένη περίπτωση απαιτεί κάποια ειδική αρχική κατάσταση. 3. Τους κανόνες, με βάση τους οποίους θα συνεργασθούν οι δοκιμαστές και τα σημεία παρατήρησης. 4. Την ετυμηγορία, στην οποία καταλήγουμε μετά από κάθε δυνατό εξαγόμενο της δοκιμής. 32/45
Δοκιμές συμμόρφωσης Μη λειτουργικές δοκιμές Λειτουργικές και μη λειτουργικές ιδιότητες συστήματος Λειτουργικές λέγονται οι ιδιότητες που αφορούν στη συμπεριφορά του συστήματος (και περιγράφονται αρχικά από τις λειτουργικές του απαιτήσεις), έτσι ώστε το σύστημα να εξυπηρετεί τους σκοπούς για τους οποίους έχει κατασκευασθεί. Προσδιορίζονται μέσω της αντιστοιχίας δυνατών εισόδων και εξόδων του συστήματος. Όμως ένα σύστημα μπορεί να εκτελεί τις προβλεπόμενες λειτουργίες πιο γρήγορα ή πιο αργά, με μεγαλύτερη ή μικρότερη κατανάλωση ενέργειας, με συγκεκριμένο βαθμό ασφάλειας κ.λπ. Οι ιδιότητες αυτές που δεν σχετίζονται με τον κύριο σκοπό ύπαρξης του συστήματος λέγονται μη λειτουργικές. Τέλος, δομικές (structural) λέγονται ιδιότητες σχετικές με την εγκατάσταση και τη συντήρηση του συστήματος μέσα στο περιβάλλον όπου πρόκειται να λειτουργήσει. 33/45
Δοκιμές συμμόρφωσης Μη λειτουργικές δοκιμές Δοκιμές εγκατάστασης Οι δοκιμές εγκατάστασης αποκτούν τόσο περισσότερη σημασία όσο το σύστημα πλησιάζει να πάρει τη μορφή έτοιμου προϊόντος, το οποίο δεν θα εγκατασταθεί από τους αρχικούς κατασκευαστές του, αλλά από τον ίδιο τον πελάτη ή από τους τεχνικούς του. Επί πλέον πολλά προϊόντα προορίζονται για εγκατάσταση σε διαφορετικές πλατφόρμες, οπότε είναι απαραίτητη η δοκιμή σε καθεμιά ξεχωριστά. 34/45
Δοκιμές συμμόρφωσης Μη λειτουργικές δοκιμές Δοκιμή καπνού Η δοκιμή καπνού (smoke test) είναι μια αρχική δοκιμή μετά την πρώτη εγκατάσταση ενός συστήματος προκειμένου να διαπιστωθεί ότι λειτουργεί στοιχειωδώς. Η ονομασία προέρχεται από τη δοκιμή ηλεκτρικών συσκευών, όπου κατά την πρώτη σύνδεση με το ρεύμα μπορεί να αρχίσει να βγαίνει καπνός π.χ. από μια αντίσταση που έχει υπερθερμανθεί. Στην περίπτωση του λογισμικού γίνονται μερικές εγκαταστάσεις και παραμετροποιήσεις του συστήματος και διαπιστώνεται κατά πόσο φαίνονται να λειτουργούν. 35/45
Δοκιμές συμμόρφωσης Μη λειτουργικές δοκιμές Δοκιμές εφεδρικών αντιγράφων και ανάκαμψης Σε συστήματα βασισμένα σε λογισμικό είναι συνηθισμένο να γίνονται αντίγραφα του συστήματος, τα οποία μπορούν να βοηθήσουν στην ανάκαμψη από καταστροφές. Οι αντίστοιχες δοκιμές συνίστανται στο να γίνουν αντίγραφα υπό διαφορετικές συνθήκες, καθώς και ανώμαλες διακοπές της λειτουργίας του συστήματος και προσπάθειες ανάκαμψης χρησιμοποιώντας τα αντίγραφα. 36/45
Δοκιμές συμμόρφωσης Μη λειτουργικές δοκιμές Δοκιμές επίδοσης Κάθε σύστημα χαρακτηρίζεται με ορισμένους δείκτες επίδοσης. Οι δοκιμές επίδοσης εξετάζουν κατά πόσο το σύστημα ικανοποιεί τις σχετικες προδιαγραφές, συνήθως βάσει κατωφλίων. Οι επιδόσεις πρέπει να διαπιστωθούν τόσο κάτω από κανονικές φορτίσεις, όσο και από ακραίες. Οι τελευταίες τίθενται στις δοκιμές φόρτισης και καταπόνησης. 37/45
Δοκιμές συμμόρφωσης Μη λειτουργικές δοκιμές Δοκιμές φόρτισης Παρά τις προσπάθειες συστηματικού σχεδιασμού, για πολλά συστήματα ισχύει το ότι μαθαίνουμε απ τις δοκιμές τις πραγματικές τους ακραίες δυνατότητες. Στις δοκιμές φόρτισης (load testing) μελετώνται οι επιδόσεις ενός συστήματος σε συνθήκες διαφορετικής φόρτισης, με έμφαση στην υψηλή φόρτιση. Μεταξύ των σκοπών αυτών των δοκιμών είναι να διαπιστωθούν οι δείκτες επίδοσης σε διαφορετικά φορτία (να γίνει δηλαδή μια καμπύλη κάθε δείκτη επίδοσης συναρτήσει του φορτίου), να προδιορισθούν σημεία απόφραξης (bottleneck) και να διαπιστωθεί ποιες συνιστώσες του συστήματος είναι κρίσιμες. Οι πιο ακραίες απ αυτές τις δοκιμές λέγονται δοκιμές καταπόνησης (stress test). 38/45
Δοκιμές συμμόρφωσης Μη λειτουργικές δοκιμές Καταστροφικές δοκιμές Πρόκειται για μια γενική κατηγορία δοκιμών που εφαρμόζεται σε όλους τους κλάδους, αλλά κυρίως σε περιπτώσεις που πρόκειται να παραχθούν προϊόντα με μαζικό τρόπο ή εμπλέκονται σε πολύ κρίσιμες λειτουργίες. Το προϊόν οδηγείται σε συνθήκες που γίνονται όλο και πιο ακραίες μέχρι να καταστραφεί. Ο σκοπός αυτών των δοκιμών είναι να προσδιορισθούν τα όρια αντοχής του συστήματος, καθώς και να γίνει μια εκτίμηση των ζημιών όταν αυτά παραβιασθούν. 39/45
Δοκιμές συμμόρφωσης Μη λειτουργικές δοκιμές Δοκιμές παλινδρόμησης (regression testing) Οι δοκιμές αυτές γίνονται μετά από μια μείζονα μεταβολή σ ένα σύστημα κι έχουν στόχο να διαπιστωθεί ότι το σύστημα είναι ακόμη σε θέση να λειτουργήσει σωστά. Η συνηθισμένη προσέγγιση είναι να διατηρείται μια συλλογή δοκιμών που έχουν γίνει στο παρελθόν και να επαναλαμβάνονται ώστε να φανεί κατά πόσο το σύστημα θα ξαναπεράσει επιτυχώς τις δοκιμές που είχε περάσει παλιότερα. 40/45
Δοκιμές συμμόρφωσης Μη λειτουργικές δοκιμές Τελικές δοκιμές Δοκιμές αποδοχής (acceptance testing) Είναι δοκιμές που θα δώσουν συνήθως στον πελάτη να αποφασίσει αν θα αποδεχτεί ένα σύστημα που έχει παραγγείλει. Μπορεί να γίνουν είτε σε εργαστήρια δοκιμών του πελάτη είτε στο πραγματικό περιβάλλον λειτουργίας. Δοκιμές Άλφα (alpha testing) Πρόκειται για δοκιμές που εκτελούν πραγματικοί χρήστες ή μια ανεξάρτητη ομάδα δοκιμαστών σε πραγματικό ή προσομοιωμένο περιβάλλον. Δοκιμές Βήτα (beta testing) Ακολουθούν τις δοκιμές άλφα προκειμένου να διορθωθούν τα τελευταία λάθη. Συνήθως πρόκειται για εκδόσεις του προϊόντος που διοχετεύονται σε χρήστες πριν την κυκλοφορία του στην αγορά. 41/45
Δοκιμές συμμόρφωσης Μη λειτουργικές δοκιμές Βιβλιογραφία I G. D. Everett, R. McLeod, Software testing: testing across the entire software development life cycle, IEEE Press, Wiley, New Jersey, 2007. ETSI TR 101 873-3, Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 3: TTCN-3 Graphical presentation Format (GFT), V1.2.1, May 2002. IEEE Std 829-2008, IEEE Standard for Software and System Test Documentation (Revision of IEEE Std 829-1998), IEEE Computer Society, New York, 18 July 2008. ANSI/IEEE Std 1008-1987, IEEE Standard for Software Unit Testing, IEEE Computer Society, 11 Dec. 1986. 42/45
Δοκιμές συμμόρφωσης Μη λειτουργικές δοκιμές Βιβλιογραφία II BS 9725-2, Standard for Software Component Testing, British Computer Society, Aug. 1998. IEEE 1012-2004, IEEE Standard for Software Verification and Validation, IEEE Computer Society, April 2005. ITU-T Recommendation X.290: OSI conformance testing methodology and framework for protocol Recommendations for CCITT applications - General Concepts, ITU-T, Geneva, 1996. ITU-T Recommendation X.291: Data Networks and Open System Communications -Open Systems Interconnection -Conformance Testing, ITU-T, Geneva, 1996. 43/45
Δοκιμές συμμόρφωσης Μη λειτουργικές δοκιμές Βιβλιογραφία III ITU-T Recommendation X.292: OSI conformance testing methodology and framework for protocol Recommendations for ITU-T applications - The Tree and Tabular Combined Notation (TTCN), ITU-T, Geneva, 1992. ISO/IEC 9646-3:1998, Information technology Open Systems Interconnection Conformance testing methodology and framework Part 3: The Tree and Tabular Combined Notation (TTCN), ISO/IEC, 1998. ETSI ES 201 873-1, Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 1: TTCN-3 Core Language, V.2.4.1, ETSI, Sophia-Antipolis, France, July 2010. 44/45
Δοκιμές συμμόρφωσης Μη λειτουργικές δοκιμές Βιβλιογραφία IV ITU-T Recommendation Z.140, The Tree and Tabular Combined Notation version 3 (TTCN-3): Core Language, ITU-T, 2001. ITU-T Recommendation Z.141, The Tree and Tabular Combined Notation version 3 (TTCN-3): Tabular Presentation Format, 2001. 45/45