Μεθοδολογίες δοκιμής λογισμικού: Μοντέλα QA
⚡ Έξυπνη Σύνοψη
Η Μεθοδολογία Δοκιμών Λογισμικού ορίζει τις στρατηγικές και τους τύπους δοκιμών που χρησιμοποιούνται για να πιστοποιήσουν ότι μια εφαρμογή ανταποκρίνεται στις προσδοκίες των πελατών. Ο προγραμματισμός Waterfall, ο επαναληπτικός, ο ευέλικτος και ο ακραίος προγραμματισμός διαμορφώνουν κάθε φορά πότε ξεκινά η δοκιμή και πώς επιστρέφει η ανατροφοδότηση.

Τι είναι η Μεθοδολογία Δοκιμών Λογισμικού;
Η Μεθοδολογία Δοκιμών Λογισμικού ορίζεται ως στρατηγικές και τύποι δοκιμών που χρησιμοποιούνται για να πιστοποιηθεί ότι η εφαρμογή υπό δοκιμή ανταποκρίνεται στις προσδοκίες του πελάτη. Οι μεθοδολογίες δοκιμής περιλαμβάνουν λειτουργικές και μη λειτουργικές δοκιμές για την επικύρωση του AUT. Παραδείγματα Μεθοδολογιών Δοκιμών είναι Δοκιμή μονάδας, Δοκιμή ολοκλήρωσης, Δοκιμή συστήματος, Δοκιμές Απόδοσης κ.λπ. Κάθε μεθοδολογία δοκιμών έχει καθορισμένο στόχο δοκιμής, στρατηγική δοκιμής και παραδοτέα.
Σημείωση: Δεδομένου ότι η Δοκιμή Λογισμικού αποτελεί αναπόσπαστο μέρος οποιασδήποτε Μεθοδολογίας Ανάπτυξης, πολλές εταιρείες χρησιμοποιούν τον όρο Μεθοδολογίες Ανάπτυξης & Μεθοδολογίες Δοκιμών στην καθομιλουμένη. Ως εκ τούτου, οι Μεθοδολογίες Δοκιμών θα μπορούσαν επίσης να αναφέρονται σε μοντέλα Waterfall, Agile και άλλα μοντέλα QA σε αντίθεση με τον παραπάνω ορισμό των Μεθοδολογιών Δοκιμών. Η συζήτηση για διάφορους τύπους δοκιμών δεν προσθέτει αξία στους αναγνώστες. Ως εκ τούτου, θα συζητήσουμε τα διαφορετικά μοντέλα ανάπτυξης.
Μεθοδολογία Δοκιμών vs Τύπος Δοκιμών vs Στρατηγική Δοκιμών
Η παραπάνω σημείωση υποδηλώνει μια πραγματική ασάφεια στον κλάδο. Τρεις όροι χρησιμοποιούνται εναλλακτικά στη συζήτηση, αλλά σημαίνουν διαφορετικά πράγματα σε ένα έγγραφο έργου και η σύγχυσή τους παράγει σχέδια δοκιμών που απαντούν σε λάθος ερώτηση.
| Όρος | Ερώτηση που απαντά | Αποφασίστηκε από | Παραδείγματα |
|---|---|---|---|
| Μεθοδολογία δοκιμών | Πότε και πώς εντάσσονται οι δοκιμές στον κύκλο ανάπτυξης; | Το μοντέλο ανάπτυξης που χρησιμοποιείται | Καταρράκτης, επαναληπτικός, ευέλικτος, ακραίος προγραμματισμός |
| Τύπος δοκιμής | Ποια πτυχή του προϊόντος επαληθεύεται; | Κάλυψη κινδύνου και απαιτήσεων | Μονάδα, ολοκλήρωση, σύστημα, απόδοση, ασφάλεια |
| Επίπεδο δοκιμών | Σε ποιο βάθος εξετάζεται το λογισμικό; | Θέση στην ιεραρχία κατασκευής | Στοιχείο, ενσωμάτωση, σύστημα, αποδοχή |
| Στρατηγική δοκιμής | Ποια είναι η οργανωτική μας προσέγγιση στην ποιότητα; | Ηγεσία στη διασφάλιση ποιότητας, εφαρμόζεται σε όλα τα έργα | Βασισμένος στον κίνδυνο, αυτοματοποίηση πρώτα, στροφή αριστερά |
| Σχέδιο δοκιμής | Τι ακριβώς θα ελέγξει αυτό το έργο, πότε και από ποιον; | Διευθυντής δοκιμών, ειδικός για το έργο | Πεδίο εφαρμογής, χρονοδιάγραμμα, πόροι, κριτήρια εισόδου και εξόδου |
Ένας χρήσιμος εμπειρικός κανόνας: η μεθοδολογία ορίζει τον ρυθμό, ο τύπος τον στόχο και το σχέδιο δοκιμών καταγράφει τη δέσμευση. Οι παρακάτω ενότητες εξετάζουν τις μεθοδολογίες.
Μοντέλο καταρράκτη
Τι είναι;
Στο μοντέλο καταρράκτη, πρόοδος ανάπτυξης λογισμικού μέσω διαφόρων φάσεων όπως Ανάλυση Απαιτήσεων, Σχεδιασμός κ.λπ. διαδοχικά.
Σε αυτό το μοντέλο, η επόμενη φάση ξεκινά μόνο όταν ολοκληρωθεί η προηγούμενη φάση.
Ποια είναι η προσέγγιση δοκιμής;
Η πρώτη φάση στο μοντέλο καταρράκτη είναι η φάση των απαιτήσεων κατά την οποία όλες οι απαιτήσεις του έργου καθορίζονται πλήρως πριν από την έναρξη της δοκιμής. Κατά τη διάρκεια αυτής της φάσης, η ομάδα δοκιμών εξετάζει το εύρος των δοκιμών, τη στρατηγική δοκιμών και συντάσσει ένα λεπτομερές σχέδιο δοκιμής.
Μόνο όταν ολοκληρωθεί ο σχεδιασμός του λογισμικού, η ομάδα θα προχωρήσει στην εκτέλεση των δοκιμαστικών περιπτώσεων για να διασφαλίσει ότι το αναπτυγμένο λογισμικό συμπεριφέρεται όπως περίμενε.
Σε αυτή τη μεθοδολογία, η ομάδα δοκιμών προχωρά στην επόμενη φάση μόνο όταν ολοκληρωθεί η προηγούμενη φάση.
| Πλεονεκτήματα | Μειονεκτήματα |
|---|---|
| Αυτό το μοντέλο Μηχανικής Λογισμικού είναι πολύ απλό στον σχεδιασμό και τη διαχείριση. Ως εκ τούτου, τα έργα, όπου οι απαιτήσεις είναι σαφώς καθορισμένες και δηλωμένες εκ των προτέρων, μπορούν εύκολα να δοκιμαστούν χρησιμοποιώντας ένα μοντέλο καταρράκτη. | Στο μοντέλο καταρράκτη, μπορείτε να ξεκινήσετε με την επόμενη φάση μόνο αφού ολοκληρωθεί η προηγούμενη φάση. Ως εκ τούτου, αυτό το μοντέλο δεν μπορεί να φιλοξενήσει απρογραμμάτιστα γεγονότα και αβεβαιότητα. |
| Αυτή η μεθοδολογία δεν είναι κατάλληλη για έργα όπου οι απαιτήσεις αλλάζουν συχνά. |
Επαναληπτική ανάπτυξη
Τι είναι;
Σε αυτό το μοντέλο, ένα μεγάλο έργο χωρίζεται σε μικρά μέρη και κάθε μέρος υποβάλλεται σε πολλαπλές επαναλήψεις του μοντέλου καταρράκτη. Στο τέλος μιας επανάληψης, αναπτύσσεται μια νέα ενότητα ή βελτιώνεται μια υπάρχουσα ενότητα. Αυτή η ενότητα ενσωματώνεται στην αρχιτεκτονική λογισμικού και ολόκληρο το σύστημα δοκιμάζεται συνολικά.
Ποια είναι η δοκιμαστική προσέγγιση;
Μόλις ολοκληρωθεί η επανάληψη, ολόκληρο το σύστημα υποβάλλεται σε δοκιμή. Τα σχόλια από τις δοκιμές είναι άμεσα διαθέσιμα και ενσωματώνονται στον επόμενο κύκλο. Ο χρόνος δοκιμής που απαιτείται σε διαδοχικές επαναλήψεις μπορεί να μειωθεί με βάση την εμπειρία που αποκτήθηκε από προηγούμενες επαναλήψεις.
| Πλεονεκτήματα | Μειονεκτήματα |
|---|---|
| Το κύριο πλεονέκτημα της επαναληπτικής ανάπτυξης είναι ότι η ανατροφοδότηση δοκιμής είναι άμεσα διαθέσιμη στο τέλος κάθε κύκλου. | Αυτό το μοντέλο αυξάνει σημαντικά τα γενικά έξοδα επικοινωνίας αφού, στο τέλος κάθε κύκλου, πρέπει να δίνεται ανατροφοδότηση σχετικά με τα παραδοτέα, την προσπάθεια κ.λπ. |
Εύκαμπτη μεθοδολογία
Τι είναι;
Οι παραδοσιακές μεθοδολογίες ανάπτυξης λογισμικού λειτουργούν με την προϋπόθεση ότι οι απαιτήσεις λογισμικού παραμένουν σταθερές σε όλο το έργο. Αλλά με την αύξηση της πολυπλοκότητας, οι απαιτήσεις υφίστανται πολυάριθμες αλλαγές και εξελίσσονται συνεχώς. Μερικές φορές, ο ίδιος ο πελάτης δεν είναι σίγουρος τι θέλει. Αν και το επαναληπτικό μοντέλο αντιμετωπίζει αυτό το ζήτημα, εξακολουθεί να βασίζεται στο μοντέλο καταρράκτη.
Στη μεθοδολογία Agile, το λογισμικό αναπτύσσεται σε αυξητικούς, γρήγορους κύκλους. Οι αλληλεπιδράσεις μεταξύ πελατών, προγραμματιστών και πελατών δίνονται έμφαση και όχι σε διαδικασίες και εργαλεία. Η ευέλικτη μεθοδολογία επικεντρώνεται στην ανταπόκριση στην αλλαγή και όχι στον εκτεταμένο σχεδιασμό.
Ποια είναι η προσέγγιση δοκιμής;
Η αυξητική δοκιμή χρησιμοποιείται σε ευέλικτες μεθόδους ανάπτυξης και ως εκ τούτου, κάθε έκδοση του έργου ελέγχεται διεξοδικά. Αυτό διασφαλίζει ότι τυχόν σφάλματα στο σύστημα διορθώνονται πριν από την επόμενη έκδοση.
| Πλεονεκτήματα | Μειονεκτήματα |
|---|---|
| Είναι δυνατή η πραγματοποίηση αλλαγών στο έργο ανά πάσα στιγμή για συμμόρφωση με τις απαιτήσεις. | Η συνεχής αλληλεπίδραση με τον πελάτη σημαίνει πρόσθετη πίεση χρόνου σε όλα τα ενδιαφερόμενα μέρη, συμπεριλαμβανομένου του ίδιου του πελάτη, της ανάπτυξης λογισμικού και των ομάδων δοκιμών. |
| Αυτή η σταδιακή δοκιμή ελαχιστοποιεί τους κινδύνους. |
Ακραίος προγραμματισμός
Τι είναι;
Ο ακραίος προγραμματισμός είναι ένας τύπος ευέλικτης μεθοδολογίας που πιστεύει σε σύντομους κύκλους ανάπτυξης. Ένα έργο χωρίζεται σε απλές εργασίες μηχανικής. Οι προγραμματιστές κωδικοποιούν ένα απλό κομμάτι λογισμικού και επιστρέφουν στον πελάτη για ανατροφοδότηση. Review πόντοι από τον πελάτη ενσωματώνονται και οι προγραμματιστές προχωρούν στην επόμενη εργασία.
Στους ακραίους προγραμματιστές, οι προγραμματιστές συνήθως εργάζονται σε ζευγάρια.
Ακραίος προγραμματισμός χρησιμοποιείται σε μέρη όπου οι απαιτήσεις των πελατών αλλάζουν συνεχώς.
Ποια είναι η προσέγγιση δοκιμής;
Ο ακραίος προγραμματισμός ακολουθεί μια ανάπτυξη με γνώμονα τη δοκιμή η οποία περιγράφεται ως εξής:
- Προσθέστε μια Δοκιμαστική θήκη στη σουίτα δοκιμών για να επαληθεύσετε τη νέα λειτουργικότητα που δεν έχει ακόμη αναπτυχθεί
- Εκτελέστε όλες τις δοκιμές και προφανώς η νέα δοκιμαστική περίπτωση που προστέθηκε πρέπει να αποτύχει, καθώς η λειτουργικότητα δεν έχει κωδικοποιηθεί ακόμα
- Γράψτε κάποιο κώδικα για την υλοποίηση της δυνατότητας/λειτουργικότητας
- Εκτελέστε ξανά τη δοκιμαστική σουίτα. Αυτή τη φορά, η νέα δοκιμαστική περίπτωση θα πρέπει να περάσει αφού το λειτουργικά έχει κωδικοποιηθεί
| Πλεονεκτήματα | Μειονεκτήματα |
|---|---|
| Οι πελάτες που έχουν κατά νου ένα ασαφές σχέδιο λογισμικού θα μπορούσαν να χρησιμοποιήσουν ακραίο προγραμματισμό | Οι συναντήσεις μεταξύ της ομάδας ανάπτυξης λογισμικού και των πελατών αυξάνουν τις απαιτήσεις χρόνου. |
| Οι συνεχείς δοκιμές και η συνεχής ενσωμάτωση μικρών εκδόσεων διασφαλίζουν ότι ο κώδικας λογισμικού που παραδίδεται είναι υψηλής ποιότητας |
Μοντέλο V και Σπειροειδές Μοντέλο
Δύο επιπλέον μοντέλα εμφανίζονται στα περισσότερα έργα και συμπληρώνουν την εικόνα, επειδή το καθένα απαντά σε μια αδυναμία της προσέγγισης του καταρράκτη με διαφορετικό τρόπο.
V-Μοντέλο. Συχνά αποκαλούμενο επαλήθευση και επικύρωση, το V-Model συνδυάζει κάθε φάση ανάπτυξης με μια αντίστοιχη φάση δοκιμής, που σχεδιάζονται ως τα δύο σκέλη ενός V. Οι απαιτήσεις συνδυάζονται με δοκιμές αποδοχής, ο σχεδιασμός υψηλού επιπέδου με δοκιμές συστήματος, ο σχεδιασμός χαμηλού επιπέδου με δοκιμές ολοκλήρωσης και ο κωδικοποίηση με δοκιμές μονάδας. Η αξία έγκειται στο ότι ο σχεδιασμός δοκιμών ξεκινά παράλληλα με κάθε φάση ανάπτυξης και όχι μετά τον κωδικοποίηση, επομένως οι ασαφείς απαιτήσεις εντοπίζονται από το άτομο που γράφει τις δοκιμές αποδοχής μήνες πριν από την κατασκευή ενός ελαττώματος. Η αδυναμία του κληρονομείται από το waterfall: το μοντέλο εξακολουθεί να υποθέτει ότι οι απαιτήσεις είναι σταθερές.
Σπειροειδές μοντέλο. Η σπείρα περιβάλλει την επανάληψη γύρω από σαφή ανάλυση κινδύνου. Κάθε βρόχος περιέχει τέσσερις δραστηριότητες: προσδιορισμό στόχων, εντοπισμό και επίλυση κινδύνων, ανάπτυξη και δοκιμή και, στη συνέχεια, σχεδιασμό της επόμενης επανάληψης. Επομένως, οι δοκιμές επικεντρώνονται εκεί που ο κίνδυνος είναι υψηλότερος αντί να κατανέμονται ομοιόμορφα. Κατάλληλο για μεγάλα, ακριβά, μακροχρόνια προγράμματα όπως η αεροδιαστημική ή τα τραπεζικά βασικά συστήματα, όπου το κόστος μιας καθυστερημένης ανακάλυψης είναι υψηλό. Για ένα μικρό διαδικτυακό έργο, η επιβάρυνση της επίσημης ανάλυσης κινδύνου σε κάθε βρόχο σπάνια δικαιολογείται.
Και τα δύο μοντέλα βρίσκονται ανάμεσα στην πειθαρχία του waterfall και την ευέλικτη απόκριση. Όπου η συχνότητα κυκλοφορίας έχει μεγαλύτερη σημασία από τα δύο, ένα DevOps Ο αγωγός ωθεί τις δοκιμές σε συνεχή ενσωμάτωση, έτσι ώστε κάθε υποβολή να επαληθεύεται αυτόματα.
Ποια Μεθοδολογία Λογισμικού να επιλέξετε;
Υπάρχουν πολλές διαθέσιμες μεθοδολογίες για την ανάπτυξη λογισμικού και τις αντίστοιχες δοκιμές του. Κάθε τεχνική και μεθοδολογία δοκιμών έχει σχεδιαστεί για συγκεκριμένο σκοπό και έχει τα σχετικά πλεονεκτήματα και μειονεκτήματα.
Η επιλογή μιας συγκεκριμένης μεθοδολογίας εξαρτάται από πολλούς παράγοντες όπως η φύση ενός έργου, οι απαιτήσεις του πελάτη, το χρονοδιάγραμμα του έργου κ.λπ.
Από την οπτική γωνία των δοκιμών, ορισμένες μεθοδολογίες πιέζουν για τη δοκιμή εισροών νωρίς στον κύκλο ζωής της ανάπτυξης, ενώ άλλες περιμένουν μέχρι να είναι έτοιμο ένα λειτουργικό μοντέλο του συστήματος.
Πώς να ρυθμίσετε μεθοδολογίες δοκιμής λογισμικού;
Οι μεθοδολογίες δοκιμής λογισμικού δεν θα πρέπει να ρυθμίζονται μόνο για χάρη της δοκιμής κώδικα λογισμικού. Θα πρέπει να ληφθεί υπόψη η μεγάλη εικόνα και ο πρωταρχικός στόχος του έργου θα πρέπει να ικανοποιηθεί με τη μεθοδολογία δοκιμών. Ανατρέξτε σε αυτήν τη λίστα αξιόπιστων παρόχους υπηρεσιών δοκιμής λογισμικού που μπορεί να σας βοηθήσει να δημιουργήσετε αποτελεσματικές στρατηγικές δοκιμών προσαρμοσμένες στους στόχους του έργου σας.
Χρονοδρομολόγηση
Ο ρεαλιστικός προγραμματισμός είναι το κλειδί για την εφαρμογή της επιτυχημένης μεθοδολογίας δοκιμών και το χρονοδιάγραμμα θα πρέπει να καλύπτει τις ανάγκες κάθε μέλους της ομάδας.
Καθορισμένα παραδοτέα
Για να παραμείνουν όλα τα μέλη της ομάδας στην ίδια σελίδα, θα πρέπει να παρέχονται καλά καθορισμένα παραδοτέα. Τα παραδοτέα θα πρέπει να περιέχουν άμεσο περιεχόμενο χωρίς καμία ασάφεια.
Δοκιμαστική προσέγγιση
Μόλις ολοκληρωθεί ο προγραμματισμός και καταστούν διαθέσιμα καθορισμένα παραδοτέα, η ομάδα δοκιμών θα πρέπει να είναι σε θέση να διαμορφώσει τη σωστή προσέγγιση δοκιμής. Τα έγγραφα ορισμού και οι συναντήσεις προγραμματιστών θα πρέπει να υποδεικνύουν την ομάδα σχετικά με την καλύτερη δοκιμαστική προσέγγιση που μπορεί να χρησιμοποιηθεί για το έργο.
Αναφορά
Η διαφανής αναφορά είναι πολύ δύσκολο να επιτευχθεί, αλλά αυτό το βήμα καθορίζει την αποτελεσματικότητα της προσέγγισης δοκιμών που χρησιμοποιείται στο έργο.




