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

Δοκιμή προϊόντων λογισμικού. Πώς να ελέγξετε τη λειτουργικότητα μιας συνάρτησης που χρησιμοποιεί άλλες συναρτήσεις εντός της; Αλλαγή σχετικών δοκιμών

Ακόμα κι αν είστε τόσο ανεκτικοί που μπορείτε να επανεκκινήσετε το πρόγραμμα 18 φορές μετά από ένα crash μέσα σε μισή ώρα και μόνο μετά να πετάξετε την οθόνη απευθείας στο παράθυρο, θα συμφωνήσετε ότι η εργασία με αυτό το πρόγραμμα θα ήταν πιο άνετη εάν δεν "κολλούσε ” .

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

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

Και αυτό το φάρμακο ονομάζεται ΔΟΚΙΜΑΣΙΑ προϊόν λογισμικού .

Σύμφωνα με σοφούς ανθρώπους, το Testing είναι ένας από τους πιο καθιερωμένους τρόπους για να διασφαλιστεί η ποιότητα της ανάπτυξης λογισμικόκαι περιλαμβάνεται στο σετ αποτελεσματικά μέσα σύγχρονο σύστημαδιασφαλίζοντας την ποιότητα του προϊόντος λογισμικού.

Η ποιότητα ενός προϊόντος λογισμικού χαρακτηρίζεται από ένα σύνολο ιδιοτήτων που καθορίζουν πόσο «καλό» είναι το προϊόν από την άποψη των ενδιαφερόμενων μερών, όπως ο πελάτης του προϊόντος, ο χορηγός, ο τελικός χρήστης, οι προγραμματιστές και οι δοκιμαστές προϊόντων, οι μηχανικοί υποστήριξης, το μάρκετινγκ , εκπαίδευση και προσωπικό πωλήσεων. Κάθε ένας από τους συμμετέχοντες μπορεί να έχει διαφορετική ιδέα για το προϊόν και πόσο καλό ή κακό είναι, δηλαδή πόσο υψηλή είναι η ποιότητα του προϊόντος. Έτσι, ο καθορισμός του προβλήματος της διασφάλισης της ποιότητας του προϊόντος έχει ως αποτέλεσμα τον εντοπισμό των ενδιαφερόμενων μερών, τα κριτήρια ποιότητάς τους και στη συνέχεια την εύρεση της βέλτιστης λύσης που ικανοποιεί αυτά τα κριτήρια.

Πότε και ποιος;

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

Ωστόσο, όλοι οι προγραμματιστές συμφωνούν ότι η δοκιμή ενός προϊόντος λογισμικού από την άποψη της ταξινόμησης κατά σκοπό πρέπει να χωριστεί σε δύο κατηγορίες:

Λειτουργική δοκιμή
Μη λειτουργική δοκιμή

Λειτουργική δοκιμή

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

Έτσι, τελικά αποφασίσατε να πραγματοποιήσετε λειτουργικές δοκιμές. Εξετάζετε τις τεχνικές προδιαγραφές, διαβάζετε τις λειτουργικές απαιτήσεις και συνειδητοποιείτε ότι τουλάχιστον δεν είναι με τη σειρά με την οποία μπορούν να γίνουν οι δοκιμές. Θα εκπλαγείτε που πριν από πολύ καιρό, άλλοι είχαν ήδη παρατηρήσει αυτήν την ασυμφωνία και κατάλαβαν πώς να την ξεπεράσουν.

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

Συνήθως, ο λειτουργικός έλεγχος πραγματοποιείται σε δύο επίπεδα:

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

Μη λειτουργική δοκιμή

Οι μη λειτουργικές δοκιμές αξιολογούν τις ιδιότητες ενός προϊόντος λογισμικού, όπως η εργονομία ή η απόδοση.

Νομίζω ότι η σημασία αυτού του τύπου δοκιμών είναι ξεκάθαρη και δεν απαιτεί αιτιολόγηση. Εξάλλου, όλοι καταλαβαίνουν ότι εάν, για παράδειγμα, η απόδοση του συστήματος δεν είναι επαρκής, τότε οι χρήστες θα πρέπει να περιμένουν μισή μέρα για απάντηση στις ενέργειές τους, κάτι που μπορεί να οδηγήσει σε μαζική αδρανοποίηση.

Όπως υποδηλώνει το όνομα, η μη λειτουργική δοκιμή επαληθεύει ότι ένα προϊόν λογισμικού πληροί τις μη λειτουργικές απαιτήσεις του όροι αναφοράςγια τη δημιουργία του. Και, όπως στην περίπτωση των λειτουργικών δοκιμών, αναπτύσσεται ένα πρόγραμμα δοκιμών και μεθοδολογία για μη λειτουργικές δοκιμές.

Έλεγχος ενσωματωμένου λογισμικού και συμμόρφωση στην Agile Era

Η συμμόρφωση με τα πρότυπα του κλάδου δεν είναι κάτι που μπορείτε να αμελήσετε ή να κάνετε αργότερα. αποτελεί αναπόσπαστο μέρος της διαδικασίας ανάπτυξης ενσωματωμένου λογισμικού (λογισμικού). Για ορισμένες βιομηχανίες - όπως η αεροηλεκτρονική, η αυτοκινητοβιομηχανία και η υγειονομική περίθαλψη - η αυστηρή τήρηση των προτύπων ποιότητας στην ανάπτυξη πολύπλοκων και χωρίς προβλήματα ενσωματωμένων συστημάτων είναι ζωτικής σημασίας για την κυκλοφορία ενός προϊόντος στην αγορά. Παραδοσιακά, οι δοκιμές έπαιξαν σημαντικό ρόλο στην ανάπτυξη ενσωματωμένων συστημάτων για βιομηχανίες που ρυθμίζονται από πρότυπα. Ωστόσο, τα τελευταία χρόνια, οι καθιερωμένες πρακτικές και διαδικασίες δοκιμών, η θέση και ο ρόλος τους σε τέτοια έργα, έχουν αλλάξει σημαντικά. Ήταν μια αλλαγή του παιχνιδιού, και όταν αλλάζουν οι κανόνες του παιχνιδιού, πρέπει να αλλάξεις μαζί τους για να κερδίσεις.

Με τη συνεχή ανάπτυξη νέων, τεχνολογιών αιχμής, οι εταιρείες πρέπει να προσφέρουν γρήγορα προϊόντα στην αγορά που είναι αξιόπιστα, ασφαλή, εύχρηστα και συμβατά με άλλα συστήματα - μόνο και μόνο για να μην χαθούν στον ταχέως μεταβαλλόμενο τεχνολογικό κόσμο. Σε μια τέτοια κατάσταση, το παραδοσιακό μοντέλο καταρράκτη, όπου η διαδικασία ανάπτυξης λογισμικού είναι αυστηρά διαδοχική και η δοκιμή εκτελείται στο τέλος, γίνεται παρελθόν. Οι μέθοδοι DevOps και Agile γίνονται όλο και πιο δημοφιλείς επειδή επιτρέπουν στους μηχανικούς να ολοκληρώνουν εργασίες που προηγουμένως ακολουθούσαν η μία την άλλη ταυτόχρονα.

Δοκιμή απόδοσης

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

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

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

Τεκμηρίωση για δοκιμή

Όπως αναφέρθηκε παραπάνω, η δοκιμή πραγματοποιείται σύμφωνα με το πρόγραμμα και τη μεθοδολογία δοκιμών, η οποία αναπτύσσεται σύμφωνα με το GOST 34.603-92.

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

Για τη διεξαγωγή όλων των τύπων δοκιμών απόδοσης, δημιουργείται συχνότερα μια λεγόμενη γεννήτρια δεδομένων, η οποία επιτρέπει αυτόματη λειτουργίαδημιουργούν επαρκή όγκο δεδομένων για την επίτευξη αντικειμενικού αποτελέσματος κατά την αξιολόγηση της απόδοσης.

Κατά τη διάρκεια της δοκιμής, συντάσσεται ένα πρωτόκολλο δοκιμών, το οποίο περιέχει πληροφορίες σχετικά με την ολοκλήρωση όλων των σταδίων και των βημάτων της δοκιμής και τα σχόλια που λαμβάνονται κατά τη διάρκεια της δοκιμής.

Εάν το αποτέλεσμα του τεστ είναι αρνητικό, οι ελλείψεις διορθώνονται και επανελέγχονται.

Διερευνητική δοκιμή

Διερευνητικές δοκιμές (οι δοκιμές ad hoc είναι υποτύπος λειτουργικών δοκιμών. Χρησιμοποιείται σε ταχέως αναπτυσσόμενα έργα με ευέλικτες μεθόδους ανάπτυξης, όπου δεν υπάρχει σαφής τεκμηρίωση και απαιτήσεις. Η διερευνητική δοκιμή είναι η υψηλότερη ακροβατική δοκιμή στη δοκιμή λογισμικού. Η ποιοτική δοκιμή είναι διαθέσιμη για ειδικούς υψηλής εξειδίκευσης και εξαρτάται σχεδόν εξ ολοκλήρου από τον ερμηνευτή, την εμπειρία, τις γνώσεις του (τόσο στον τομέα του θέματος όσο και στις μεθόδους δοκιμών) και την ικανότητα να φτάσει γρήγορα στην ουσία.

Stress Testing

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

1. Δημιουργία δοκιμαστικών σεναρίων

Για αποτελεσματική ανάλυση, τα σενάρια πρέπει να είναι όσο το δυνατόν πιο κοντά στις πραγματικές περιπτώσεις χρήσης. Είναι σημαντικό να κατανοήσουμε ότι οι εξαιρέσεις είναι πάντα δυνατές, και ακόμη και το πιο λεπτομερές σχέδιο δοκιμής μπορεί να μην καλύπτει ούτε μία περίπτωση.

2. Ανάπτυξη μιας δοκιμαστικής διαμόρφωσης

Έχοντας σενάρια δοκιμών, είναι σημαντικό να κατανεμηθεί η σειρά αύξησης του φορτίου. Για επιτυχή ανάλυση, είναι απαραίτητο να προσδιοριστούν κριτήρια αξιολόγησης απόδοσης (ταχύτητα απόκρισης, χρόνος επεξεργασίας αιτήματος κ.λπ.).

3. Διεξαγωγή δοκιμαστικής δοκιμής

Κατά τη διεξαγωγή δοκιμών, είναι σημαντικό να παρακολουθείτε έγκαιρα την εκτέλεση των σεναρίων και την απόκριση του υπό δοκιμή συστήματος. Η εξομοίωση υψηλών φορτίων απαιτεί σοβαρή υποδομή υλικού και λογισμικού. Σε ορισμένες περιπτώσεις, χρησιμοποιούνται μέθοδοι μαθηματικής μοντελοποίησης για τη μείωση του κόστους εργασίας. Τα δεδομένα που λαμβάνονται σε χαμηλά φορτία λαμβάνονται ως βάση και προσεγγίζονται. Όσο υψηλότερο είναι το επίπεδο του προσομοιωμένου φορτίου, τόσο μικρότερη είναι η ακρίβεια της εκτίμησης. Ωστόσο, αυτή η μέθοδος μειώνει σημαντικά το κόστος.

Δοκιμή αυτοματισμού

Το κύριο χαρακτηριστικό των αυτοματοποιημένων δοκιμών είναι η δυνατότητα γρήγορης διεξαγωγής δοκιμών παλινδρόμησης. Τα κύρια πλεονεκτήματα του αυτοματισμού (σύμφωνα με έκθεση της Worksoft) είναι η αυξημένη αποτελεσματικότητα του προσωπικού, η έγκαιρη ανίχνευση ελαττωμάτων και άλλα υψηλή ποιότηταεπιχειρηματικών διαδικασιών. Αυτά τα πλεονεκτήματα αντισταθμίζονται από ένα σημαντικό μειονέκτημα: υψηλό κόστος - λόγω του υψηλού κόστους εφαρμογής και υποστήριξης αυτοματισμού δοκιμών, περίπου το 50% των εταιρειών εξακολουθούν να χρησιμοποιούν κυρίως χειροκίνητες δοκιμές.

Δοκιμή χρηστικότητας

Οποιαδήποτε εφαρμογή δημιουργείται για να χρησιμοποιηθεί. Η ευκολία χρήσης είναι ένας σημαντικός δείκτης ποιότητας ενός προγράμματος. Η βιομηχανία πληροφορικής γνωρίζει πολλά παραδείγματα έργων που απογειώνονται μετά από μια επιτυχημένη επιδιόρθωση χρηστικότητας. Όσο μεγαλύτερο είναι το κοινό, τόσο πιο σημαντικός είναι ο παράγοντας χρηστικότητας. Η δοκιμή ευχρηστίας περιλαμβάνει λεπτομερή ανάλυση της συμπεριφοράς των χρηστών. Για την αξιολόγηση της εργονομίας, είναι σημαντικό να υπάρχουν δεδομένα όχι μόνο για την ταχύτητα ολοκλήρωσης μιας επαγγελματικής εργασίας, αλλά και για τα συναισθήματα, τις εκφράσεις του προσώπου και τη φωνή του χρήστη.

Δοκιμή διαμόρφωσης

Η δοκιμή διαμόρφωσης δίνει σιγουριά ότι η εφαρμογή θα λειτουργήσει σε διαφορετικές πλατφόρμες και επομένως για τον μέγιστο αριθμό χρηστών. Για εφαρμογές WEB, συνήθως επιλέγεται η δοκιμή μεταξύ προγραμμάτων περιήγησης. Για εφαρμογές Windows - δοκιμή σε διάφορα λειτουργικά συστήματακαι μεγέθη bit (x86, x64). Ένα σημαντικό στοιχείο των δοκιμών διαμόρφωσης είναι η υποδομή δοκιμών: για τη διεξαγωγή δοκιμών, πρέπει να διατηρείτε συνεχώς έναν στόλο δοκιμαστικών μηχανών. Ο αριθμός τους κυμαίνεται από 5 έως αρκετές δεκάδες.

Δοκιμή ενσωμάτωσης

Εάν το έργο σας έχει περισσότερα από ένα στοιχεία, χρειάζεται δοκιμή ενοποίησης. Με μια πολύπλοκη αρχιτεκτονική εφαρμογών, απαραίτητη προϋπόθεση για τη διασφάλιση της ποιότητας είναι ο έλεγχος της αλληλεπίδρασης των τμημάτων του προγράμματος. Η δοκιμή επιτυγχάνεται με την ανάπτυξη και τη διεξαγωγή περιπτώσεων «από άκρο σε άκρο». Η δοκιμή ενσωμάτωσης πραγματοποιείται μετά τη δοκιμή εξαρτημάτων. Επομένως, είναι πολύ σημαντικό να λαμβάνεται υπόψη η εμπειρία από τη δοκιμή εξαρτημάτων, με σεβασμό στον επιχειρηματικό προσανατολισμό των δοκιμαστικών περιπτώσεων.

Τεστ καταπόνησης

Κάθε σύστημα έχει ένα όριο κανονική λειτουργία. Όταν ξεπεραστεί το όριο, το σύστημα περνά σε κατάσταση άγχους και αλλάζει σημαντικά τη συμπεριφορά του. Η δοκιμή καταπόνησης ελέγχει τη λειτουργία μιας εφαρμογής υπό συνθήκες που υπερβαίνουν τα κανονικά όρια λειτουργίας. Αυτό είναι ιδιαίτερα σημαντικό για «κρίσιμα» προγράμματα: τραπεζικό λογισμικό, προγράμματα αεροπορικής βιομηχανίας, ιατρική. Το stress test πραγματοποιείται όχι μόνο στο στάδιο ανάπτυξης λογισμικού, αλλά και σε ολόκληρο τον κύκλο λειτουργίας, προκειμένου να ληφθούν και να επεξεργαστούν δεδομένα συμπεριφοράς του συστήματος για μεγάλο χρονικό διάστημα.

Ας υποθέσουμε ότι υπάρχει μια συνάρτηση λήψης δεδομένων, το οποίο επιστρέφει έναν χάρτη πληροφοριών σχετικά με το αναγνωριστικό χρήστη που πέρασε. Τώρα αυτή η συνάρτηση χρησιμοποιεί 3 συναρτήσεις source-a , source-b και source-c για την παραγωγή τριών διαφορετικών ειδών χαρτών. Τώρα θα συνδυάσουμε όλους αυτούς τους χάρτες σε έναν χάρτη και θα επιστρέψουμε από το get-data.

Όταν δοκιμάζω τα δεδομένα λήψηςπρέπει να ελέγξω για διαθεσιμότητα δεδομένων για κλειδιά; Έχει νόημα αυτή η συνάρτηση να αποτύχει στις δοκιμές μονάδας εάν αποτύχει μία από τις πηγές-a , πηγή-β και πηγή-γ; Αν η δουλειά αυτής της συνάρτησης είναι να ενώνει δεδομένα, και το κάνει, αυτό θα είναι αρκετό, σωστά;

2 απαντήσεις

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

Εξαιρετική. Τότε θα πρέπει να το ελέγξετε. Για ένα δεδομένο αναγνωριστικό, επιστρέφετε τα σωστά δεδομένα;

Τώρα αυτή η συνάρτηση χρησιμοποιεί 3 συναρτήσεις source-a, source-b και source-c για την παραγωγή τριών διαφορετικών ειδών χαρτών.

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

Ωστόσο, πιθανότατα θα πρέπει να κοροϊδέψετε τις πηγές δεδομένων, οπότε κάποια στιγμή η δοκιμή θα χρειαστεί πιθανώς να μάθει πώς λειτουργεί αυτός ο κώδικας. Πρέπει να εξισορροπήσετε τρεις ανταγωνιστικούς στόχους εδώ: να κάνετε το τεστ απομονωμένο (με χλευασμό των δεδομένων), ενώ το τεστ να εστιάζεται στις απαιτήσεις και στον πραγματισμό.

Μετά από όλα, αυτός είναι ένας σημαντικός κώδικας. Υπάρχουν δοκιμές για την υποστήριξη του πραγματικού κώδικα, ξοδεύοντας πολύ χρόνο και η ταλαιπωρία του ελέγχου γυαλίσματος δεν είναι τόσο χρήσιμη όσο οι δοκιμές κατασκευή .

Στη δοκιμή μονάδας θα πρέπει να δοκιμάσετε μόνο τη λειτουργικότητα μιας κλάσης, εάν οι μέθοδοι source-a, source-b και source-c καλούν άλλες κλάσεις, θα πρέπει να τις κοροϊδέψετε (θα πρέπει να δοκιμαστούν μονάδες στις κλάσεις τους).

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

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

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

Και αυτό το φάρμακο ονομάζεται ΔΟΚΙΜΗ του προϊόντος λογισμικού.

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

Πότε και ποιος;

Λειτουργική δοκιμή
Μη λειτουργική δοκιμή

Λειτουργική δοκιμή

Για τη διεξαγωγή λειτουργικών δοκιμών, το προσωπικό του τμήματος τεχνικού ελέγχου αναπτύσσει ένα πρόγραμμα εγγράφων και μεθοδολογία για τον έλεγχο της λειτουργικότητας της εφαρμογής (API). Το έγγραφο PMI περιέχει μια λίστα σεναρίων δοκιμών προϊόντων λογισμικού (δοκιμές) με λεπτομερή περιγραφή των βημάτων. Κάθε βήμα του σεναρίου δοκιμών χαρακτηρίζεται από τις ενέργειες του χρήστη (ειδικό δοκιμών) και τα αναμενόμενα αποτελέσματα - την ανταπόκριση του προγράμματος σε αυτές τις ενέργειες. Το πρόγραμμα δοκιμής και η μεθοδολογία πρέπει να προσομοιώνουν τη λειτουργία του προϊόντος λογισμικού σε πραγματικό τρόπο. Αυτό σημαίνει ότι το σενάριο δοκιμής θα πρέπει να βασίζεται σε ανάλυση των λειτουργιών που θα εκτελούν οι μελλοντικοί χρήστες του συστήματος και όχι να είναι μια τεχνητά μεταγλωττισμένη ακολουθία χειρισμών κατανοητή μόνο από τον προγραμματιστή.

Συνήθως, ο λειτουργικός έλεγχος πραγματοποιείται σε δύο επίπεδα:

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

Μη λειτουργική δοκιμή

Οι μη λειτουργικές δοκιμές αξιολογούν τις ιδιότητες ενός προϊόντος λογισμικού, όπως η εργονομία ή η απόδοση.

Όπως υποδηλώνει το όνομα, η μη λειτουργική δοκιμή ελέγχει τη συμμόρφωση ενός προϊόντος λογισμικού με μη λειτουργικές απαιτήσεις από τις τεχνικές προδιαγραφές για τη δημιουργία του. Και, όπως στην περίπτωση των λειτουργικών δοκιμών, αναπτύσσεται ένα πρόγραμμα δοκιμών και μεθοδολογία για μη λειτουργικές δοκιμές.

Έλεγχος ενσωματωμένου λογισμικού και συμμόρφωση στην Agile Era

Δοκιμή απόδοσης

Τεκμηρίωση για δοκιμή

Για τη διεξαγωγή όλων των τύπων δοκιμών απόδοσης, δημιουργείται συχνότερα μια λεγόμενη γεννήτρια δεδομένων, η οποία σας επιτρέπει να δημιουργείτε αυτόματα επαρκή ποσότητα δεδομένων για να επιτύχετε ένα αντικειμενικό αποτέλεσμα κατά την αξιολόγηση της απόδοσης.

Εάν το αποτέλεσμα του τεστ είναι αρνητικό, οι ελλείψεις διορθώνονται και επανελέγχονται.

Διερευνητική δοκιμή

Stress Testing

1. Δημιουργία δοκιμαστικών σεναρίων

2. Ανάπτυξη μιας δοκιμαστικής διαμόρφωσης

3. Διεξαγωγή δοκιμαστικής δοκιμής

Δοκιμή αυτοματισμού

Το κύριο χαρακτηριστικό των αυτοματοποιημένων δοκιμών είναι η δυνατότητα γρήγορης διεξαγωγής δοκιμών παλινδρόμησης. Τα κύρια πλεονεκτήματα του αυτοματισμού (σύμφωνα με έκθεση της Worksoft) είναι η αυξημένη αποτελεσματικότητα του προσωπικού, η έγκαιρη ανίχνευση ελαττωμάτων και η υψηλότερη ποιότητα των επιχειρηματικών διαδικασιών. Αυτά τα πλεονεκτήματα αντισταθμίζονται από ένα σημαντικό μειονέκτημα: υψηλό κόστος - λόγω του υψηλού κόστους εφαρμογής και υποστήριξης αυτοματισμού δοκιμών, περίπου το 50% των εταιρειών εξακολουθούν να χρησιμοποιούν κυρίως χειροκίνητες δοκιμές.

Δοκιμή χρηστικότητας

Δοκιμή διαμόρφωσης

Η δοκιμή διαμόρφωσης δίνει σιγουριά ότι η εφαρμογή θα λειτουργήσει σε διαφορετικές πλατφόρμες και επομένως για τον μέγιστο αριθμό χρηστών. Για εφαρμογές WEB, συνήθως επιλέγεται η δοκιμή μεταξύ προγραμμάτων περιήγησης. Για εφαρμογές Windows - δοκιμή σε διάφορα λειτουργικά συστήματα και ρυθμούς μετάδοσης bit (x86, x64). Ένα σημαντικό στοιχείο των δοκιμών διαμόρφωσης είναι η υποδομή δοκιμών: για τη διεξαγωγή δοκιμών, πρέπει να διατηρείτε συνεχώς έναν στόλο δοκιμαστικών μηχανών. Ο αριθμός τους κυμαίνεται από 5 έως αρκετές δεκάδες.

Δοκιμή ενσωμάτωσης

Τεστ καταπόνησης

Οποιοδήποτε σύστημα έχει ένα όριο στην κανονική του λειτουργία. Όταν ξεπεραστεί το όριο, το σύστημα περνά σε κατάσταση άγχους και αλλάζει σημαντικά τη συμπεριφορά του. Η δοκιμή καταπόνησης ελέγχει τη λειτουργία μιας εφαρμογής υπό συνθήκες που υπερβαίνουν τα κανονικά όρια λειτουργίας. Αυτό είναι ιδιαίτερα σημαντικό για «κρίσιμα» προγράμματα: τραπεζικό λογισμικό, προγράμματα αεροπορικής βιομηχανίας, ιατρική. Το stress test πραγματοποιείται όχι μόνο στο στάδιο ανάπτυξης λογισμικού, αλλά και σε ολόκληρο τον κύκλο λειτουργίας, προκειμένου να ληφθούν και να επεξεργαστούν δεδομένα συμπεριφοράς του συστήματος για μεγάλο χρονικό διάστημα.

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

Λειτουργική δοκιμή: πού να κατευθυνθούν οι κύριες προσπάθειες;

Για δοκιμή μονάδας και συστήματος.

Για να ελέγξετε το πλαίσιο "λευκό" ή "μαύρο".

Για χειροκίνητες δοκιμές και αυτοματισμό.

Για να δοκιμάσετε νέα λειτουργικότητα ή

Για «αρνητικά» ή «θετικά» τεστ.

Ανάμεσα σε όλους αυτούς τους τομείς δραστηριότητας, είναι σημαντικό να βρεθεί ο σωστός δρόμος, που θα είναι ο «μέσος», ώστε να εξισορροπηθούν οι προσπάθειες, αξιοποιώντας τα πλεονεκτήματα του καθενός από τους τομείς στο μέγιστο.

Πραγματοποιείται επαλήθευση λογισμικού διαφορετικοί τρόποι, ένα από τα οποία είναι δοκιμές μαύρου κουτιού ή δεδομένων.

Το πρόγραμμα σε αυτή την περίπτωση παρουσιάζεται από τη σκοπιά ενός «μαύρου κουτιού» και η δοκιμή πραγματοποιείται για να προσδιοριστούν οι συνθήκες υπό τις οποίες η συμπεριφορά του προγράμματος δεν θα συμμορφώνεται με τις προδιαγραφές. Όλα τα σφάλματα εντοπίζονται μέσω της διαχείρισης δεδομένων, η οποία πραγματοποιείται μέσω εξαντλητικών δοκιμών, δηλαδή χρησιμοποιώντας όλα τα δυνατά

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

Ο λειτουργικός έλεγχος περιλαμβάνει την επιλογή του σωστού τεστ. Ταυτόχρονα, είναι σύνηθες να γίνεται διάκριση μεταξύ των ακόλουθων μεθόδων για τη δημιουργία συνόλων για αυτούς:

Ανάλυση οριακής τιμής;

Ισοδύναμο διαμέρισμα.

Υπόθεση σφάλματος;

Ανάλυση των συνδέσεων μεταξύ αιτιών και αποτελεσμάτων.

Μπορείτε να εξετάσετε το καθένα ξεχωριστά.

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

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

Ανάλυση των σχέσεων αιτίου και αποτελέσματος. Το σύστημα μπορεί να επιλέξει δοκιμές με υψηλή απόδοση πραγματοποιώντας τέτοιους ελέγχους. Σε αυτήν την περίπτωση, μια ξεχωριστή συνθήκη εισόδου λαμβάνεται ως αιτία και η συνθήκη εξόδου θεωρείται ως αποτέλεσμα. Η μέθοδος βασίζεται στην ιδέα της απόδοσης όλων των τύπων αιτιών σε ορισμένες συνέπειες, δηλαδή στην αποσαφήνιση αυτών των ίδιων σχέσεων αιτίου-αποτελέσματος. Η δοκιμή ενός προϊόντος λογισμικού πραγματοποιείται σε διάφορα στάδια, με αποτέλεσμα μια λίστα με τις αιτίες και τις επακόλουθες συνέπειες.

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

Ας δούμε τη διαδικασία δοκιμής με βάση τις συστάσεις του προτύπου ISO/IEC 12207 και ας δώσουμε τους τύπους σφαλμάτων που εντοπίζονται σε κάθε διαδικασία κύκλου ζωής.

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

Τα τυπικά σφάλματα σε αυτή τη διαδικασία είναι:

ανεπάρκεια των προδιαγραφών απαιτήσεων για τους τελικούς χρήστες, - εσφαλμένη προδιαγραφή της αλληλεπίδρασης του λογισμικού με το λειτουργικό περιβάλλον ή με τους χρήστες.
μη συμμόρφωση με τις απαιτήσεις των πελατών για μεμονωμένες και γενικές ιδιότητες λογισμικού·
εσφαλμένη περιγραφή των λειτουργικών χαρακτηριστικών.
έλλειψη διαθεσιμότητας εργαλείων για όλες τις πτυχές της υλοποίησης των απαιτήσεων των πελατών, κ.λπ.

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

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

Στάδιο κωδικοποίησης.Σε αυτό το στάδιο προκύπτουν σφάλματα που είναι αποτέλεσμα ελαττωμάτων σχεδιασμού, σφαλμάτων προγραμματιστών και διαχειριστών κατά την ανάπτυξη και τον εντοπισμό σφαλμάτων του συστήματος. Οι αιτίες των σφαλμάτων είναι:

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

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

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

Όλα τα σφάλματα που εμφανίζονται σε προγράμματα χωρίζονται συνήθως στις ακόλουθες κλάσεις [7.12]:

Λογικά και λειτουργικά σφάλματα.
σφάλματα υπολογισμού και χρόνου εκτέλεσης.
σφάλματα εισόδου/εξόδου και χειρισμού δεδομένων.
σφάλματα διασύνδεσης?
σφάλματα όγκου δεδομένων κ.λπ.

Λογικά λάθηαποτελούν αιτία παραβίασης της λογικής του αλγορίθμου, εσωτερικής ασυνέπειας μεταβλητών και τελεστών, καθώς και κανόνων προγραμματισμού. Τα λειτουργικά σφάλματα είναι συνέπεια εσφαλμένων καθορισμένων λειτουργιών, παραβίασης της σειράς εφαρμογής τους ή έλλειψης πληρότητας εφαρμογής τους κ.λπ.

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

Σφάλματα εισόδου/εξόδουκαι ο χειρισμός δεδομένων είναι συνέπεια κακής ποιότητας προετοιμασίας δεδομένων για εκτέλεση προγράμματος, αποτυχιών κατά την εισαγωγή τους σε βάσεις δεδομένων ή κατά την ανάκτησή τους από αυτές.

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

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

Οι συγκεκριμένες κύριες κατηγορίες σφαλμάτων είναι χαρακτηριστικές διαφορετικών τύπων στοιχείων λογισμικού και εκδηλώνονται στα προγράμματα με διαφορετικούς τρόπους. Έτσι, όταν εργάζεστε με μια βάση δεδομένων, συμβαίνουν σφάλματα στην παρουσίαση και τον χειρισμό δεδομένων, λογικά λάθηστον καθορισμό εφαρμοζόμενων διαδικασιών επεξεργασίας δεδομένων κ.λπ. Στα υπολογιστικά προγράμματα κυριαρχούν τα υπολογιστικά σφάλματα και στα προγράμματα ελέγχου και επεξεργασίας τα λογικά και λειτουργικά σφάλματα. Το λογισμικό, το οποίο αποτελείται από πολλά διαφορετικά προγράμματα που υλοποιούν διαφορετικές λειτουργίες, ενδέχεται να περιέχει σφάλματα ΔΙΑΦΟΡΕΤΙΚΟΙ ΤΥΠΟΙ. Τα σφάλματα διασύνδεσης και οι παραβιάσεις του όγκου είναι τυπικά για κάθε τύπο συστήματος.

Η ανάλυση των τύπων σφαλμάτων στα προγράμματα είναι απαραίτητη προϋπόθεση για τη δημιουργία σχεδίων δοκιμών και μεθόδων δοκιμής για τη διασφάλιση της ορθότητας του λογισμικού.

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

Σχέση μεταξύ λάθους και αποτυχίας.Η παρουσία σφάλματος σε ένα πρόγραμμα, κατά κανόνα, οδηγεί σε αστοχία του λογισμικού κατά τη λειτουργία του. Για την ανάλυση των σχέσεων αιτίου-αποτελέσματος του «σφάλματος-αποτυχίας», εκτελούνται οι ακόλουθες ενέργειες:

εντοπισμός ελαττωμάτων στις τεχνολογίες σχεδιασμού και προγραμματισμού·
τη σχέση μεταξύ ελαττωμάτων στη διαδικασία σχεδιασμού και ανθρώπινων λαθών·
ταξινόμηση αστοχιών, ελαττωμάτων και πιθανών σφαλμάτων, καθώς και ελαττωμάτων σε κάθε στάδιο ανάπτυξης - σύγκριση ανθρώπινων λαθών που έγιναν σε μια συγκεκριμένη διαδικασία ανάπτυξης και ελαττωμάτων στο αντικείμενο, ως συνέπεια σφαλμάτων στις προδιαγραφές του έργου, στα μοντέλα προγραμμάτων.
επαλήθευση και προστασία σφαλμάτων σε όλα τα στάδια του κύκλου ζωής, καθώς και ανίχνευση ελαττωμάτων σε κάθε στάδιο ανάπτυξης.
σύγκριση ελαττωμάτων και αστοχιών λογισμικού για την ανάπτυξη συστήματος διασυνδέσεων και μεθόδων εντοπισμού, συλλογής και ανάλυσης πληροφοριών σχετικά με αστοχίες και ελαττώματα·
ανάπτυξη προσεγγίσεων στις διαδικασίες τεκμηρίωσης και δοκιμής λογισμικού.

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

Ακολουθεί η ακόλουθη ταξινόμηση των τύπων αστοχιών:

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

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

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

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

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

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

Δημοφιλή στην κατηγορία: