slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Εβδομάδα 10 : Έλεγχος ορθότητας και αποσφαλμάτωση PowerPoint Presentation
Download Presentation
Εβδομάδα 10 : Έλεγχος ορθότητας και αποσφαλμάτωση

Loading in 2 Seconds...

play fullscreen
1 / 23

Εβδομάδα 10 : Έλεγχος ορθότητας και αποσφαλμάτωση - PowerPoint PPT Presentation


  • 98 Views
  • Uploaded on

Εβδομάδα 10 : Έλεγχος ορθότητας και αποσφαλμάτωση. Έλεγχος ορθότητας (testing). Διαδοχικές δοκιμαστικές εκτελέσεις του προγράμματος, με ένα συστηματικό τρόπο, που αποσκοπούν στην ανακάλυψη σφαλμάτων. Τι είναι ο έλεγχος ορθότητας;. Αποσφαλμάτωση ( debugging).

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Εβδομάδα 10 : Έλεγχος ορθότητας και αποσφαλμάτωση


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Εβδομάδα 10:

Έλεγχος ορθότητας και

αποσφαλμάτωση

testing
Έλεγχος ορθότητας(testing)
  • Διαδοχικές δοκιμαστικές εκτελέσεις του προγράμματος, με ένα συστηματικό τρόπο, που αποσκοπούν στην ανακάλυψη σφαλμάτων.

Τι είναι ο έλεγχος ορθότητας;

debugging
Αποσφαλμάτωση (debugging)
  • Εύρεση και διόρθωση λαθών σε ένα πρόγραμμα.

Τι είναι η αποσφαλμάτωση;

slide4
Γιατί χρειάζεται ο έλεγχος ορθότητας;
  • Σπάνια γράφουμε σωστό κώδικα με την πρώτη προσπάθεια!!!
  • Η ορθότητα του κώδικα ενός προγράμματος είναι πολύ δύσκολο να αποδειχθεί.
  • Η απόδειξη της ορθότητας ενός προγράμματος είναι τόσο δύσκολη ώστε θεωρείται ανέφικτη για πολύ μεγάλα συστήματα.
murphy venera 14
Ο νόμος του Murphy, το Venera-14 συμβάν
  • Ο έλεγχος ορθότητας αποτελεί μια πιστοποίηση του νόμου του Murphy. (Ονομασία προς τιμή του Captain Edward A. Murphy Jnr.):
    • «Εάν ένα άτομο μπορεί να εκτελέσει μια εργασία με δυο ή περισσότερους τρόπους ενας εκ των οποίων οδηγεί σε καταστροφή, τότε θα διαλέξει να την εκτελέσει με τον τρόπο αυτό»
  • Παράδειγμα: Το συμβάν του Venera 14.
  • Το Venera 14 ήταν ένα Σοβιετικό διαστημικό εξερευνητικό όχημα το οποίο προσγειώθηκε στην Αφροδίτη το 1982.
  • Δείτε:http://www.abc.net.au/science/k2/moments/gmis9907.htm
slide6
Το συμβάν των μαχητικών F-16
  • Το λογισμικό των μαχητικών αεροσκαφών F-16 περιείχε ένα λάθος το οποίο τα ανάγκαζε να αναποδογυρίζουν κάθε φορά που περνούσαν πάνω από τον ισημερινό. (Το λάθος ανακαλύφθηκε μέσω προσομοιωτή και όχι στη διάρκεια κανονικής πτήσης.)
slide7
Το συμβάν του διαστημικού λεωφορείου
  • Σε ένα πείραμα που απαιτούσε την ανάκλαση μίας ακτίνας laser από τον ερευνητικό σταθμό του Mona Kea μέσω κάτοπτρου που βρίσκονταν σε δορυφόρο, το διαστημικό λεωφορείο "Discovery" τοποθετήθηκε αναποδογυρισμένο; Το κάτοπτρο σκόπευε προς το πάνω και όχι προς τα κάτω όπως έπρεπε.
  • Ο προγραμματιστής είχε εισάγει τις συντεταγμένες σε «πόδια» αντί για «μίλια». (10,023 μίλια από το επίπεδο της θάλασσας)
  • (Software Engineering Notes, Vol 10 No 3)
therac 25
Το συμβάν Therac-25
  • Από το 1985 έως το 1987, το Therac-25, ένα ελεγχόμενο από υπολογιστή μηχάνημα ακτινοβολίας που χρησιμοποιούνταν σε νοσοκομεία, παρείχε σε ασθενείς μεγαλύτερες από τις κανονικές δόσεις ακτινοβολίας λόγω λάθους στο λογισμικό του. Πολλοί ασθενείς πέθαναν και αρκετοί έπαθαν σοβαρά εγκαύματα.

Αναφορές:

Nancy G. Leveson and Clark S. Turner: "An Investigation of the Therac-25 Accidents", IEEE Computer, July 1993, pp. 18-41http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html

Troy Gallagher: "THERAC-25: Computerized Radiation Therapy", http://www.uoguelph.ca/~tgallagh/

ariane 5
Το συμβάν του Ariane 5
  • Στις 4 Ιουνίου 1996, ο Ευρωπαϊκός διαστημικός πύραυλος Ariane 5 εξερράγη 40’’ μετά την εκτόξευση στην παρθενική του πτήση. Η έκρηξη προεκλίθη από λάθος λογισμικού (Κόστος: περίπου 0.6 δισ. ευρώ)
  • Αναφορές:

"ARIANE 5 - Flight 501 Failure", Report by the Inquiry Board,

http://www.esa.int/htdocs/tidc/Press/Press96/ariane5rep.html

Peter B. Ladkin: "The Ariane 5 Accident: A Programming Problem?", http://www.rvs.uni-bielefeld.de/publications/Reports/ariane.html

ariane 51
Ariane 5: Ένα αποσπασμα…

"The failure of the Ariane 501 was caused by the complete loss of guidance and attitude information 37 seconds after start of the main engine ignition sequence (30 seconds after lift- off). This loss of information was due to specification and design errors in the software of the inertial reference system. The extensive reviews and tests carried out during the Ariane 5 development programme did not include adequate analysis and testing of the inertial reference system or of the complete flight control system, which could have detected the potential failure."

from: "ARIANE 5 - Flight 501 Failure", Report by the Inquiry Board,

http://www.esa.int/htdocs/tidc/Press/Press96/ariane5rep.html

slide11
Προβλήματα με τον έλεγχο ορθότητας
  • Τεχνικά:
    • Ο έλεγχος ορθότητας είναι δύσκολος
    • Ο έλεγχος ορθότητας απαιτεί χρόνο
    • Ο έλεγχος ορθότητας απαιτεί μεγάλη προεργασία
  • Ψυχολογικά:
    • Ο προγραμματιστής ελέγχει μόνο τις περιπτώσεις που έχει καλύψει στο σχεδιασμό του
    • Γίνεται μόνο «positive testing»
    • Στον έλεγχος ορθότητας επιδρά η εμπειρία από την υλοποίηση.
slide12
Θέματα ελέγχου ορθότητας
  • Θετικός και αρνητικός έλεγχος ορθότητας [positive and negative testing]
  • Οριακές περιπτώσεις [boundary case]
  • white box vs black box testing
  • Πότε γίνεται ο έλεγχος ορθότητας (κατά τη διάρκεια της υλοποίησης ή μετά);
  • Ποιος εκτελεί τον έλεγχο ορθότητας;
slide13
Θετικός και αρνητικός έλεγχος ορθότητας
  • Ο έλεγχος ορθότητας πρέπει να καλύπτει όλο το φάσμα των λειτουργιών ενός προγράμματος
  • Ο έλεγχος ορθότητας πρέπει να καλύπτει όλο το φάσμα των τιμών εισόδου
  • Θετικός: Ο έλεγχος ορθότητας καλύπτει όλο το φάσμα των «νόμιμων» τιμών εισόδου και καταδεικνύει την σωστή λειτουργία του προγράμματος για αυτές τις αναμενόμενες περιπτώσεις
  • Αρνητικός: Ο έλεγχος ορθότητας καλύπτει «μη-νόμιμες» τιμές εισόδου με σκοπό να καταδείξει ότι το προγραμμα συμπεριφέρεται λογικά σε περιπτώσεις λάθους από το χρήστη του
  • Οριακές περιπτώσεις
black box white box
Black box / white box
  • Έλεγχος ορθότητας τύπου «Black box»:χρησιμοποιείται μόνο το πρόγραμμα και το εγχειρίδιο χρήσης [manual]. Δεν λαμβάνεται υπ’ όψιν ο πηγαίος κώδικας.
  • Έλεγχος ορθότητας τύπου «White box»:Η στρατηγική του ελέγχου ορθότητας βασίζεται στον πηγαίο κώδικα.
black box
Έλεγχος ορθότητας τύπου «Black box»
  • Όλες οι σημαντικά διαφοροποιήσιμες περιπτώσεις ελέγχου πρέπει να καλυφθούν.
  • Ποιες περιπτώσεις έλεγχου κατατάσσονται ως «σημαντικά διαφοροποιήσιμες»;
  • Το σύνολο των τεστ ορθότητας πρέπει να γράφει πριν από την υλοποίηση του προγράμματος.
  • Ο ελεγκτής ορθότητας πρέπει να μην είναι ο ίδιος ο προγραμματιστής
white box
Έλεγχος ορθότητας τύπου «White box»
  • Κάθε τμήμα του πηγαίου κώδικα πρέπει να εκτελεστεί

(κάθε μέθοδος πρέπει να κληθεί, σε κάθε εντολή-if, το if τμήμα και το else τμήμα πρέπει να ελεγχθεί, …)

slide17
Τεκμηρίωση ελέγχων ορθότητας
  • Η στρατηγική του ελέγχου ορθότητας πρέπει να γραφεί πριν από την υλοποίηση του προγράμματος.
  • Η στρατηγική αποτελείται από ένα σύνολο τεστ και από τα αναμενόμενα αποτελέσματα τους.
  • Κατά τη διάρκεια του έλεγχου ορθότητας τα τεστ (και τα αποτελέσματα τους) πρέπει να καταγράφονται.
  • Τα πραγματικά αποτελέσματα των τεστ πρέπει να συγκρίνονται με τα αναμενόμενα αποτελέσματα.
  • Τα λάθη και οι αποκλίσεις από τα αναμενόμενα αποτελέσματα πρέπει να αναφέρονται στον προγραμματιστή.
slide18
Έλεγχος ορθότητας «μονάδας»
  • Κάθε μονάδα προγράμματος πρέπει να ελέγχεται ξεχωριστά πριν την ενσωμάτωση της με τις άλλες μονάδες του προγράμματος.
  • Κάθε μέθοδος πρέπει να ελέγχεται, κάθε κλάση πρέπει να ελέγχεται, …
  • Μετά από κάθε βήμα ενσωμάτωσης μονάδων, η νέα ολοκληρωμένη μονάδα πρέπει να ελεγχθεί.
slide19
Έλεγχος ορθότητας εφαρμογής
  • Μετά την ενσωμάτωση όλων των συστατικών μονάδων μίας εφαρμογής, η πλήρης εφαρμογή πρέπει να ελεγχθεί.
  • Μετά κάθε αλλαγή, ο έλεγχος ορθότητας πρέπει να επαναληφθεί. [regression testing]

Regress = επιστροφή σε προγενέστερη (ανεπιθύμητη) κατάσταση, οπισθοδρόμηση

slide20
Τι αποδεικνύει ο έλεγχος ορθότητας;
  • Ο έλεγχος ορθότητας μπορεί να αποδείξει μόνο την παρουσία σφαλμάτων, ποτέ την απουσία τους!
slide21
Κριτική/ανασκόπηση πηγαίου κώδικα
  • Εναλλακτική /επιπρόσθετη μέθοδος: «ανασκόπηση κώδικα» [code review]
  • Μια ομάδα-σχεδιασμού εξετάζει τον πηγαίο κώδικα μαζί με τον προγραμματιστή που τον ανέπτυξε.
  • Η ομάδα κάνει παρατηρήσεις και προτάσεις στον προγραμματιστή.
  • Απαιτεί ωριμότητα και «μη-ατομικιστικό προγραμματισμό».
  • Πολύ καλά αποτελέσματα στην πράξη.
debugging1
Αποσφαλμάτωση (Debugging)
  • Η αποσφαλμάτωση εκτελείται μετά τον έλεγχο ορθότητας: Όταν ένα λάθος εντοπιστεί, τα αίτια του λάθους πρέπει να βρεθούν και η σωστή λειτουργία του κώδικα να αποκατασταθεί.
slide23
Τεχνικές αποσφαλμάτωσης
  • παρατήρηση
  • ανάγνωση πηγαίου κώδικα
  • εκτέλεση προγράμματος σε «χαρτί»
  • εντολές εξόδου για αποσφαλμάτωση
  • ισχυρισμοί [assertions]
  • χρήση αποσφαλματωτή