Ποιότητα Λογισμικού Έλεγχος λογισμικού Χ. Σκουρλάς, cskourlas@teiath.gr       Α θ ή ν α 2015-16

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

Κύριος στόχος του μαθήματος είναι να εφοδιάσει τους φοιτητές µε γνώσεις έτσι ώστε να κατανοήσουν βασικά θέματα ελέγχου λογισμικού.

“Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence” (Dijkstra)

περίγραμμα - Μη-Πειραματικός Έλεγχος (Non-execution-based testing) Έλεγχος βασισμένος σε πειράματα (Execution-based testing) V&V testing Πώς να αναφέρετε ένα σφάλμα σε μικρές επιχειρήσεις; Παράδειγμα τεκμηρίωσης - Τι θα πρέπει να ελεγχθεί; - Ποιος πρέπει να διεξαγάγει έλεγχο βασισμένο σε πειράματα; Πότε τελειώνει ο έλεγχος Παραδείγματα

Μη-Πειραματικός Έλεγχος Non-Execution-Based Testing βασικές αρχές (Underlying principles) Δεν πρέπει να επανεξετάζουμε (επιθεωρούμε) την δική μας δουλεία Σύμπραξη (συνεργασία) ομάδας

Walkthroughs Μια ομάδα walkthrough συνίσταται από τέσσερα έως έξι άτομα Περιλαμβάνει αντιπροσώπους από Την ομάδα που είναι υπεύθυνη για την παρούσα δραστηριότητα Την ομάδα που θα διεξάγει την επόμενη δραστηριότητα Την ομάδα SQA Χρειάζεται προετοιμασία πριν την διεξαγωγή του walkthrough Λίστα από θέματα/στοιχεία Θέματα/στοιχεία που δεν έχουν κατανοηθεί Θέματα/στοιχεία που φαίνεται να μην είναι ορθά

ΔιοίκησηWalkthroughs Ο πρόεδρος της ομάδας walkthrough είναι ένας εκπρόσωπος της ομάδας SQA Σε ένα walkthrough εντοπίζουμε λάθη. Δεν τα διορθώνουμε Μια διόρθωση που θα προταθεί από την επιτροπή είναι πιθανό να είναι χαμηλής ποιότητας Το κόστος του να προτείνει μια τέτοια επιτροπή διορθώσεις είναι υψηλό Δεν είναι όλα τα θέματα/στοιχεία που εντοπίζονται σαν προβληματικά πραγματικά λάθη Ένα walkthrough δεν πρέπει να διαρκεί περισσότερο από 2 ώρες Δεν υπάρχει χρόνος σε αυτό το διάστημα για να διορθωθούν τα λάθη

Ένα walkthrough πρέπει να καθοδηγείται από έγγραφα (document-driven), παρά από τους συμμετέχοντες (participant) Διατυπώσεις απαιτήσεων οδηγούν σε εύρεση λαθών Ένα walkthrough δεν πρέπει ποτέ να χρησιμοποιηθεί για αξιολόγηση απόδοσης

Επιθεωρήσεις Inspections Οι επιθεωρήσεις είναι πιο επίσημες από walkthroughs πέντε κλασικά βήματα Γενική Επισκόπηση (Overview) Προετοιμασία βοηθούμενη από στατιστικές διάφορων τύπων λαθών (aided by statistics of fault types) Εξέταση (Inspection) Διορθώσεις και συνέχεια του έργου (Rework) Παρακολούθηση της προόδου (Follow-up)

Η ομάδα επιθεώρησης έχει τέσσερα μέλη Moderator Ένα μέλος της ομάδας εργασίας στην παρούσα δραστηριότητα Ένα μέλος της ομάδας που θα διεξάγει την επόμενη δραστηριότητα Ένα μέλος της ομάδας SQA Ειδικοί ρόλοι Reader Recorder

Στατιστικές για Λάθη Fault Statistics Τα λάθη καταγράφονται με βάση την σοβαρότητα τους (Faults are recorded by severity) Παραδείγματα: Μείζονος σημασίας (σημαντικά, major), ή Ελάσσονος σημασίας (μικρά –minor) Τα λάθη καταγράφονται με βάση τον τύπο τους (Faults are recorded by fault type) Παραδείγματα λαθών σχεδιασμού: Δεν έχουν καταγραφεί όλες οι προδιαγραφές

Μετατοπίζουμε την προσπάθεια εύρεσης λαθών στην επόμενη δραστηριότητα Για μια δεδομένη δραστηριότητα, συγκρίνουμε την αναλογία (ποσοστό) λαθών με εκείνες των προηγούμενων έργων Λαμβάνουμε μέτρα αν δεν είναι ανάλογος ο αριθμός λαθών σε ένα συστατικό μέρος (artifact) Το να το ξανασχεδιάσουμε (ή υλοποιήσουμε) από την αρχή είναι συχνά μια καλή εναλλακτική λύση Μετατοπίζουμε την προσπάθεια εύρεσης λαθών στην επόμενη δραστηριότητα Ίσως να μην τα καταφέραμε να εντοπίσουμε όλα τα λάθη στην παρούσα επιθεώρηση

Στατιστικές στις επιθεωρήσεις Οι στατιστικές για σφάλματα δεν πρέπει ποτέ να χρησιμοποιηθούν για αξιολόγηση απόδοσης

Σύγκριση Inspections and Walkthroughs Προετοιμασίας Ανάλυσης Επιθεώρηση: Τυπική διαδικασία πέντε βημάτων Γενική Επισκόπηση Προετοιμασία Εξέταση Διορθώσεις Παρακολούθηση προόδου

Πλεονεκτήματα και Μειονεκτήματα των Αξιολογήσεων Strengths and Weaknesses of Reviews Οι αξιολογήσεις μπορεί να είναι αποδοτικές/αποτελεσματικές Τα λάθη μπορούν να εντοπιστούν νωρίς στην διαδικασία ανάπτυξης λογισμικού Οι αξιολογήσεις είναι λιγότερο αποτελεσματικές όταν η διαδικασία είναι ανεπαρκής (μη ικανοποιητική) Λογισμικά μεγάλης κλίμακας (Large-scale software) πρέπει να αποτελούνται από μικρότερα αρκετά ανεξάρτητα κομμάτια Τα έγγραφα της προηγούμενης δραστηριότητας πρέπει να είναι ολοκληρωμένα και διαθέσιμα online

Μετρικές για Επιθεωρήσεις Metrics for Inspections Ρυθμός επιθεώρησης (Inspection rate) π.χ., ο αριθμός σελίδων σε ένα έγγραφο σχεδιασμού που εξετάζονται κάθε ώρα. Πυκνότητα λαθών (Fault density), π.χ. αριθμός λαθών σε χίλιες γραμμές κώδικα (KLOC) που εξετάστηκαν Ρυθμός ανίχνευσης λαθών (Fault detection rate) π.χ., ο αριθμός λαθών που εντοπίζονται κάθε ώρα Αποδοτικότητα στην ανίχνευση λαθών (Fault detection efficiency) π.χ., ο αριθμός των σημαντικών και των μικρότερης σημασίας λαθών που εντοπίστηκαν κάθε ώρα

Έλεγχος βασισμένος σε πειράματα Execution-Based Testing Εταιρίες ξοδεύουν μέχρι και 50% του προϋπολογισμού σε έλεγχο Και όμως τα προϊόντα λογισμικού που παραδίνονται είναι πολλές φορές αναξιόπιστα

Τι πρέπει να ελεγχθεί ; What Should Be Tested? Χρειάζεται να ελέγξουμε την ορθότητα και: Χρησιμότητα/ωφελιμότητα (Utility) Αξιοπιστία (Reliability) Ευρωστία (Robustness) Απόδοση (Performance)

Χρησιμότητα / Ωφελιμότητα Utility Ο βαθμός στον οποίο το προϊόν ικανοποιεί τις απαιτήσεις του πελάτη Παραδείγματα: Ευκολία στη χρήση Λειτουργικό Οικονομικό

Αξιοπιστία Reliability Ένα μέτρο της συχνότητας και της σημαντικότητας αποτυχιών Μέσος χρόνος ανάμεσα σε αποτυχίες Μέσος χρόνος διόρθωσης Χρόνος (και κόστος) για διόρθωση μιας αποτυχίας

Η ευρωστία είναι συνάρτηση των πιο κάτω: Ευρωστία Robustness Η ευρωστία είναι συνάρτηση των πιο κάτω: Τη γκάμα των λειτουργικών μερών του λογισμικού. Την πιθανότητα λήψης μη-αποδεκτού αποτελέσματος δεδομένης έγκυρης εισόδου. Την επίπτωση/αποτέλεσμα που θα προκύψει από λανθασμένη (μη-έγκυρη) είσοδο.

Απόδοση Performance Κατά πόσο ικανοποιούνται περιορισμοί (απαιτήσεις) για το παραγόμενο λογισμικό αναφορικά με χρόνο (π.χ. χρόνο απόκρισης ή χρόνο διεκπεραίωσης) και χώρο (μνήμη που χρειάζεται για να μπορεί να εκτελεστεί). Λογισμικά Πραγματικού-χρόνου (Real-time) χαρακτηρίζονται από αυστηρούς χρονικούς περιορισμούς (hard real-time constraints)

Ένα προϊόν είναι ορθό όταν ικανοποιεί τις προδιαγραφές του. Ορθότητα Correctness Ένα προϊόν είναι ορθό όταν ικανοποιεί τις προδιαγραφές του.

Ποιος Πρέπει να διεξάγει τον Πειραματικό Έλεγχο; Οι προγραμματιστές διεξάγουν «ανεπίσημο» έλεγχο του κώδικά τους Η ομάδα SQA διεξάγει συστηματικό και επίσημο έλεγχο Οι προγραμματιστές διορθώνουν τα λάθη που εντοπίστηκαν Όλοι οι έλεγχοι πρέπει να Σχεδιαστούν από πριν και να γνωρίζουμε και τα αποτελέσματα τα οποία αναμένονται Για να μπορεί να επιβεβαιωθεί αν είναι σωστά τα αποτελέσματα που προκύπτουν από το λογισμικό μας Διατηρούνται και στη συνέχεια (Retained afterwards)

Πότε Σταματά ο έλεγχος; Μόνο όταν το προϊόν αποσυρθεί οριστικά

Ερωτήσεις