test plan tutorial guide write software test plan document from scratch
Έγγραφο για τον τελικό οδηγό για το πρόγραμμα δοκιμών λογισμικού:
Αυτό το σεμινάριο θα σας εξηγήσει όλα σχετικά με το Έγγραφο προγράμματος δοκιμής λογισμικού και θα σας καθοδηγήσει με τους τρόπους για να γράψετε / δημιουργήσετε ένα λεπτομερές σχέδιο δοκιμής λογισμικού από το μηδέν μαζί με το διαφορές μεταξύ προγραμματισμού δοκιμών και εκτέλεσης δοκιμών.
Live Project QA Training Day 3 - Μετά την εισαγωγή των αναγνωστών μας στη ζωντανή εφαρμογή του Δωρεάν online Εκπαίδευση δοκιμών λογισμικού , μάθαμε πώς να αναθεωρήσετε το SRS και να γράψετε δοκιμαστικά σενάρια . Και τώρα είναι η κατάλληλη στιγμή να βυθιστείτε πιο βαθιά στο πιο σημαντικό μέρος του κύκλου ζωής δοκιμών λογισμικού - δηλ. Σχεδιασμός δοκιμών .
πώς να μετατρέψετε ένα βίντεο στο YouTube σε αρχείο wav
Λίστα όλων των εκπαιδευτικών σε αυτήν τη σειρά:
Έγγραφο προγραμματισμού δοκιμών:
Εκμάθηση # 1: Πώς να συντάξετε ένα έγγραφο δοκιμαστικού σχεδίου (Αυτό το σεμινάριο)
Εκμάθηση # 2: Περιεχόμενα προτύπου απλού σχεδίου δοκιμών
Εκμάθηση # 3: Παράδειγμα προγράμματος δοκιμής λογισμικού
Εκμάθηση # 4: Διαφορά μεταξύ του σχεδίου δοκιμών και της στρατηγικής δοκιμής
Εκμάθηση # 5: Πώς να γράψετε ένα έγγραφο στρατηγικής δοκιμής
Συμβουλές σχεδιασμού δοκιμών:
Εκμάθηση # 6: Διαχείριση κινδύνων κατά τον προγραμματισμό δοκιμών
Εκμάθηση # 7: Τι να κάνετε όταν δεν υπάρχει αρκετός χρόνος για δοκιμή
Εκμάθηση # 8: Πώς να σχεδιάσετε και να διαχειριστείτε αποτελεσματικά τις δοκιμές έργων
Σχεδιασμός δοκιμών σε διαφορετικά στάδια του STLC:
Εκμάθηση # 9: Σχεδιασμός δοκιμών παλινδρόμησης
Εκμάθηση # 10: Πρόγραμμα δοκιμών UAT
Εκμάθηση # 11: Σχέδιο δοκιμής αποδοχής
Σχεδιασμός αυτοματισμού δοκιμής:
Εκμάθηση # 12: Πρόγραμμα δοκιμών αυτοματισμού
Εκμάθηση # 13: Σχεδιασμός δοκιμών εφαρμογής ERP
Εκμάθηση # 14: Σχεδιασμός δοκιμών HP ALM
Εκμάθηση # 15: Σχεδιασμός δοκιμών νοημοσύνης
Εκμάθηση # 16: Πρόγραμμα δοκιμών JMeter και WorkBench
Τι θα μάθετε:
- Δημιουργία δοκιμαστικού σχεδίου - Η πιο σημαντική φάση των δοκιμών
- Δοκιμή σχεδιασμού εναντίον εκτέλεσης δοκιμής
Δημιουργία δοκιμαστικού σχεδίου - Η πιο σημαντική φάση των δοκιμών
Αυτό το ενημερωτικό σεμινάριο θα σας εξηγήσει τους τρόπους και τις διαδικασίες που συνεπάγεται η σύνταξη ενός εγγράφου δοκιμαστικού σχεδίου.
Στο τέλος αυτού του σεμιναρίου, έχουμε μοιραστεί ένα Συνολικό έγγραφο δοκιμαστικού σχεδίου 19 σελίδων που δημιουργήθηκε ειδικά για το ζωντανό έργο OrangeHRM, το οποίο χρησιμοποιούμε δωρεάν Σειρά προπόνησης QA
Τι είναι ένα σχέδιο δοκιμής;
Το Test Plan είναι ένα δυναμικό έγγραφο . Η επιτυχία ενός έργου δοκιμών εξαρτάται από ένα καλογραμμένο έγγραφο δοκιμαστικού σχεδίου που είναι ενημερωμένο ανά πάσα στιγμή. Το σχέδιο δοκιμών είναι λίγο πολύ σαν ένα προσχέδιο για το πώς εξελίσσεται η δοκιμαστική δραστηριότητα να πραγματοποιηθεί σε ένα έργο.
Παρακάτω δίνονται μερικοί δείκτες σε ένα Σχέδιο Δοκιμών:
# 1) Το Πρόγραμμα δοκιμών είναι ένα έγγραφο που λειτουργεί ως σημείο αναφοράς και βασίζεται μόνο στο ότι οι δοκιμές πραγματοποιούνται εντός της ομάδας QA.
#δύο) Είναι επίσης ένα έγγραφο που μοιραζόμαστε με τους Business Analysts, Project Managers, την ομάδα Dev και τις άλλες ομάδες. Αυτό βοηθά στην ενίσχυση του επιπέδου διαφάνειας της εργασίας της ομάδας QA στις εξωτερικές ομάδες.
# 3) Τεκμηριώνεται από τον υπεύθυνο QA / επικεφαλής QA με βάση τις πληροφορίες από τα μέλη της ομάδας QA.
# 4) Ο προγραμματισμός δοκιμών κατανέμεται συνήθως με 1/3rdτου χρόνου που απαιτείται για ολόκληρη την αφοσίωση QA. Το άλλο 1/3rdείναι για δοκιμή σχεδιασμού και το υπόλοιπο για δοκιμή εκτέλεσης.
# 5) Αυτό το πρόγραμμα δεν είναι στατικό και ενημερώνεται κατ 'απαίτηση.
# 6) Όσο πιο λεπτομερές και περιεκτικό είναι το σχέδιο, τόσο πιο επιτυχημένη θα είναι η δοκιμαστική δραστηριότητα.
Διαδικασία STLC
Είμαστε τώρα στη μέση της ζωντανής σειράς έργων μας. Επομένως, ας κάνουμε ένα βήμα πίσω από την εφαρμογή και ρίξτε μια ματιά στη διαδικασία Software Testing Life Cycle (STLC).
Το STLC μπορεί να χωριστεί περίπου σε 3 μέρη:
- Σχεδιασμός δοκιμών
- Σχεδιασμός δοκιμής
- Εκτέλεση δοκιμής
Στο προηγούμενο σεμινάριό μας, καταλάβαμε ότι σε ένα πρακτικό έργο QA, ξεκινήσαμε με το SRS review και το Test Scenario Writing - το οποίο είναι στην πραγματικότητα το 2ο Βήμα στη διαδικασία STLC. Ο σχεδιασμός δοκιμών περιλαμβάνει τις λεπτομέρειες σχετικά με το τι πρέπει να δοκιμάσετε και τον τρόπο δοκιμής.
Γιατί δεν ξεκινήσαμε με τον προγραμματισμό δοκιμών;
Ο προγραμματισμός είναι πράγματι η πρώτη και κύρια δραστηριότητα που συμβαίνει σε οποιοδήποτε έργο δοκιμών.
Δοκιμή προγραμματισμού σε φάσεις SDLC
| Φάση SDLC | Δραστηριότητα σχεδιασμού δοκιμών |
|---|---|
| Προγράμματα => | Προετοιμασία σεναρίου δοκιμής |
| Μυημένος | Στην ιδανική περίπτωση, η ομάδα QA θα πρέπει να εμπλακεί ενώ το πεδίο του έργου συγκεντρώνεται από τον πελάτη / πελάτη με τη μορφή επιχειρηματικών απαιτήσεων. Αλλά στον πραγματικό κόσμο, αυτό δεν συμβαίνει. Από πρακτική άποψη, η συμμετοχή της ομάδας QA είναι μηδενική. Στο τέλος αυτής της φάσης, το BRD οριστικοποιείται και δημιουργείται ένα βασικό Σχέδιο Έργου. |
| Καθορίζω | Το SRS δημιουργείται από το BRD. Δημιουργείται το αρχικό σχέδιο δοκιμαστικού σχεδίου. Σε αυτό το σημείο, δεδομένου ότι η ομάδα QA δεν έχει ολοκληρωθεί με την αξιολόγηση SRS, το πεδίο των δοκιμών δεν είναι σαφές. Επομένως, το TP σε αυτήν τη φάση θα περιέχει μόνο πληροφορίες σχετικά με το πότε θα πραγματοποιηθεί η δοκιμή, πληροφορίες για το έργο και τις πληροφορίες της ομάδας (εάν τις έχουμε). |
| Σχέδιο | Η επανεξέταση SRS διενεργείται και προσδιορίζεται το πεδίο των δοκιμών. Έχουμε πολύ περισσότερες πληροφορίες σχετικά με το τι θα δοκιμάσουμε και μια καλή εκτίμηση του αριθμού των δοκιμαστικών περιπτώσεων που θα μπορούσαμε να πάρουμε κ.λπ. Δημιουργείται μια δεύτερη έκδοση του σχεδίου δοκιμών που περιλαμβάνει όλες αυτές τις πληροφορίες. |
Από τον παραπάνω πίνακα, είναι πολύ σαφές ότι ένα σχέδιο δοκιμών δεν είναι απλώς ένα έγγραφο που μπορείτε να δημιουργήσετε ταυτόχρονα και να το χρησιμοποιήσετε από τότε.
Στοιχεία ενός εγγράφου σχεδίου
| Στοιχεία σε πρότυπο δοκιμαστικού σχεδίου | Τι περιέχουν; |
|---|---|
| Πεδίο εφαρμογής => | Σενάρια δοκιμής / Στόχοι δοκιμής που θα επικυρωθούν. |
| Εκτός εύρους => | Βελτιωμένη σαφήνεια για το τι δεν πρόκειται να καλύψουμε |
| Υποθέσεις => | Όλες οι προϋποθέσεις που πρέπει να ισχύουν για να μπορέσουμε να προχωρήσουμε με επιτυχία |
| Τεκμηρίωση δοκιμής - περιπτώσεις δοκιμών / δεδομένα δοκιμής / περιβάλλον ρύθμισης | |
| Εκτέλεση δοκιμής | |
| Δοκιμή κύκλου - πόσος κύκλος | |
| Ημερομηνία έναρξης και λήξης για κύκλους | |
| Ρόλοι και ευθύνες => | Τα μέλη της ομάδας αναφέρονται |
| Ποιος θα κάνει τι | |
| αναφέρονται οι κάτοχοι λειτουργικών μονάδων και τα στοιχεία επικοινωνίας τους | |
| Παραδοτέα => | Ποια έγγραφα (δοκιμαστικά αντικείμενα) πρόκειται να παράγουν σε ποια χρονικά διαστήματα; |
| Τι μπορεί να αναμένεται από κάθε έγγραφο; | |
| Περιβάλλον => | Τι είδους περιβαλλοντικές απαιτήσεις υπάρχουν; |
| Ποιος θα είναι υπεύθυνος; | |
| Τι να κάνετε σε περίπτωση προβλημάτων; | |
| Εργαλεία => | Για παράδειγμα, JIRA για παρακολούθηση σφαλμάτων |
| Σύνδεση | |
| Πώς να χρησιμοποιήσετε το JIRA; | |
| Διαχείριση ελαττωμάτων => | Σε ποιον πρόκειται να αναφέρουμε τα ελαττώματα; |
| Πώς θα αναφέρουμε; | |
| Τι αναμένεται - παρέχουμε στιγμιότυπο οθόνης; | |
| Κίνδυνοι και διαχείριση κινδύνων => | Παρατίθενται κίνδυνοι |
| Οι κίνδυνοι αναλύονται - η πιθανότητα και ο αντίκτυπος τεκμηριώνονται | |
| Σχεδιάζονται σχέδια μετριασμού των κινδύνων | |
| Κριτήρια εξόδου => | Πότε να σταματήσετε τις δοκιμές; |
Καθώς όλες οι προαναφερθείσες πληροφορίες είναι οι πιο κρίσιμες για το καθημερινή εργασία ενός έργου QA , είναι σημαντικό να ενημερώνετε το έγγραφο του προγράμματος κάθε τόσο.
Δείγμα εγγράφου σχεδίου δοκιμής για ένα ζωντανό έργο
Ένα δείγμα εγγράφου προτύπου δοκιμαστικού σχεδίου δημιουργήθηκε για το ' ORANGEHRM VERSION 3.0 - ΜΟΝΑΔΑ ΠΛΗΡΟΦΟΡΙΩΝ ΜΟΥ » Έργο και επισυνάπτεται παρακάτω. Ρίξτε μια ματιά. Πρόσθετα σχόλια έχουν προστεθεί στο έγγραφο με κόκκινο χρώμα για να εξηγήσουν τις ενότητες.
Αυτό το σχέδιο δοκιμών είναι τόσο για τις λειτουργικές όσο και για τις φάσεις UAT. Εξηγεί επίσης τη διαδικασία Test Test χρησιμοποιώντας το εργαλείο HP ALM.
Λήψη δείγματος σχεδίου δοκιμής:
Μορφή εγγράφου => Κάντε κλικ εδώ για λήψη του δοκιμαστικού σχεδίου σε μορφή εγγράφου αυτό είναι που δημιουργήσαμε για το OragngeHRM live Project και το χρησιμοποιούμε και για το πρόγραμμα δοκιμών σφαλμάτων δοκιμής λογισμικού.
Μορφή PDF => Κάντε κλικ εδώ για να κατεβάσετε το δοκιμαστικό σχέδιο σε μορφή αρχείου pdf .
Αρχεία φύλλου εργασίας (.xls) που αναφέρονται στις παραπάνω εκδόσεις doc / pdf => Κατεβάστε το Αναφερόμενα αρχεία XLS στο παραπάνω Πρόγραμμα δοκιμών
Το παραπάνω πρότυπο είναι πολύ περιεκτικό και αναλυτικό. Ως εκ τούτου, παρακαλώ δώστε μια λεπτομερή ανάγνωση για τα καλύτερα αποτελέσματα.
Καθώς το σχέδιο δημιουργείται και εξηγείται επίσης, ας προχωρήσουμε στην επόμενη φάση τόσο σε SDLC όσο και σε STLC.
Κωδικός SDLC:
Ενώ το υπόλοιπο του έργου αφιερώνει το χρόνο του στη δημιουργία TDD, εμείς οι QA έχουν προσδιορίσει το πεδίο δοκιμών (σενάρια δοκιμής) και δημιουργήσαμε το πρώτο αξιόπιστο σχέδιο σχεδίου δοκιμών. Η επόμενη φάση του SDLC είναι να ελέγξετε πότε πραγματοποιείται η κωδικοποίηση.
Οι προγραμματιστές είναι το κύριο σημείο εστίασης για ολόκληρη την ομάδα σε αυτήν τη φάση. Η ομάδα QA επιδίδεται επίσης στο πιο σημαντικό έργο που δεν είναι παρά 'Δημιουργία δοκιμαστικής θήκης' .
Εάν τα σενάρια δοκιμής ήταν «Τι να δοκιμάσετε», τότε οι δοκιμαστικές περιπτώσεις αφορούν το «Πώς να δοκιμάσετε». Η δημιουργία δοκιμαστικών περιπτώσεων αποτελεί κυρίαρχο μέρος της φάσης σχεδιασμού δοκιμής του STLC. Η είσοδος για τη δραστηριότητα δημιουργίας δοκιμαστικής υπόθεσης είναι τα σενάρια δοκιμής και το έγγραφο SRS.
Για δοκιμαστές σαν εμάς, Θήκες δοκιμής είναι η πραγματική συμφωνία - είναι τα πράγματα που περνάμε τον περισσότερο χρόνο μας. Τους δημιουργούμε, τους ελέγχουμε, τους εκτελούμε, τους συντηρούμε, τους αυτοματοποιούμε- και λοιπόν, παίρνετε την εικόνα. Ανεξάρτητα από το πόσο έμπειροι είμαστε και τι ρόλο διαδραματίζουμε σε ένα έργο - θα εξακολουθούσαμε να δουλεύουμε με τις δοκιμαστικές περιπτώσεις.
Δοκιμή σχεδιασμού εναντίον εκτέλεσης δοκιμής
Ο προγραμματισμός δοκιμών λογισμικού διατηρεί ένα πολύ καλύτερο πεδίο συγκριτικά στο Φάση STLC . Η παράδοση ποιοτικού λογισμικού εξασφαλίζεται από την ομάδα δοκιμών. Και αυτό που πρέπει να γίνει στη δοκιμή αποφασίζεται στην φάση προγραμματισμού δοκιμών.
Αυτή η ενότητα θα παρέχει μια πλήρη επισκόπηση και θα περιλαμβάνει απεικονίσεις σχετικά με τη σημασία του σχεδιασμού δοκιμών και του φάση εκτέλεσης . Αφού το διαβάσετε, θα καταλάβετε τη σημαντική σημασία της φάσης σχεδιασμού σε σύγκριση με τη φάση εκτέλεσης με περισσότερα ζωντανά παραδείγματα και μελέτες περιπτώσεων για εικόνες .
Σχεδιασμός δοκιμών
Παρακάτω αναφέρονται ορισμένα βασικά πράγματα που πρέπει να σημειωθούν κατά τον προγραμματισμό:
Ο σχεδιασμός μιας δοκιμής είναι το βασικό σημαντικό τμήμα του κύκλου δοκιμών. Το αποτέλεσμα της φάσης δοκιμής θα καθοριστεί από την ποιότητα και το εύρος του σχεδιασμού που έχει γίνει για τη δοκιμή.
Ο προγραμματισμός της δοκιμής πραγματοποιείται συνήθως κατά τη φάση ανάπτυξης προκειμένου να εξοικονομηθεί ο χρόνος εκτέλεσης της δοκιμής κατόπιν αμοιβαίας συμφωνίας από όλα τα εμπλεκόμενα μέρη.
Μερικά σημαντικά γεγονότα που πρέπει να σημειωθούν περιλαμβάνουν:
- Ο προγραμματισμός πρέπει να ξεκινήσει παράλληλα με την ανάπτυξη, υπό τον όρο ότι οι απαιτήσεις έχουν παγώσει.
- Όλοι οι ενδιαφερόμενοι όπως σχεδιαστές, προγραμματιστές, πελάτες και δοκιμαστές πρέπει να συμμετέχουν κατά την ολοκλήρωση του σχεδίου.
- Ο προγραμματισμός δεν μπορεί να επιλυθεί για μη επιβεβαιωμένες ή μη εγκεκριμένες επιχειρηματικές ανάγκες.
- Παρόμοια σχέδια δοκιμών θα εφαρμοστούν στις νέες απαιτήσεις που θα απαιτήσει η επιχείρηση.
Παράδειγμα # 1
Η ομάδα ανάπτυξης εργάζεται σε ένα λογισμικό XYZ αφού λάβει μερικές απαιτήσεις από τους πελάτες. Η ομάδα δοκιμών έχει σχεδόν ξεκινήσει την προετοιμασία της για τη φάση καθορισμού ή προγραμματισμού του τεστ. Ο σχεδιασμός δοκιμών πρέπει να σχεδιαστεί για να ανταποκρίνεται στις αρχικές απαιτήσεις που αναφέρονται από τους πελάτες. Αυτό έγινε από την ομάδα δοκιμών.
Κανένας από τους άλλους ενδιαφερόμενους δεν συμμετείχε σε αυτή τη φάση και ο προγραμματισμός έχει παγώσει.
Η ομάδα ανάπτυξης έχει πλέον πραγματοποιήσει ορισμένες αλλαγές στη ροή της επιχείρησης, προκειμένου να αντιμετωπίσει μερικά ζητήματα στη δουλειά τους με την έγκριση του πελάτη. Τώρα το λογισμικό ήρθε στην ομάδα δοκιμών για μια δοκιμή. Με το σχέδιο δοκιμών σύμφωνα με την παλιά επιχειρηματική ροή, η ομάδα δοκιμών ξεκίνησε τον κύκλο δοκιμών. Αυτό επηρέασε τα παραδοτέα δοκιμών με πολλές καθυστερήσεις καθώς η τροποποιημένη επιχειρηματική ροή δεν κοινοποιήθηκε στην ομάδα δοκιμών.
Παρατήρηση από το Παράδειγμα 1:
Υπάρχουν ορισμένες παρατηρήσεις από το παραπάνω παράδειγμα.
Αυτοί είναι:
- Η κατανόηση της νέας επιχειρηματικής ροής καταναλώνει πολύ χρόνο.
- Καθυστερήσεις στα παραδοτέα του έργου.
- Επανάληψη του σχεδιασμού και των άλλων εργασιών στη φάση.
Όλες αυτές οι παρατηρήσεις πρέπει να μετατραπούν σε βασικές ανάγκες για αποτελεσματικό παραδοτέο δοκιμών.
Κύρια στοιχεία στη φάση προγραμματισμού
Παρακάτω αναφέρονται τα κύρια συστατικά που εμπλέκονται στη φάση σχεδιασμού.
- Στρατηγική δοκιμής: Αυτή είναι μια από τις πιο σημαντικές ενότητες που μπορούν να εξηγήσουν τη στρατηγική που θα χρησιμοποιηθεί κατά τη δοκιμή.
- Κάλυψη δοκιμής: Αυτό είναι ουσιαστικά απαραίτητο και θα κάνει τη χαρτογράφηση συμμόρφωσης των επιχειρηματικών αναγκών και των δοκιμαστικών περιπτώσεων, ώστε να μπορεί κανείς να διασφαλίσει εάν ολόκληρο το λογισμικό έχει δοκιμαστεί ή όχι.
- Κύκλοι δοκιμής και διάρκεια: Αυτό μπορεί να γίνει πολύ κρίσιμο ανάλογα με τους γύρους ανάπτυξης και τον χρόνο τους για την ολοκλήρωση κάθε γύρου.
- Κριτήρια επιτυχίας / αποτυχίας: Απαιτείται πάρα πολύ ένα στο οποίο καθορίζονται τα κριτήρια επιτυχίας και αποτυχίας. Μερικές φορές αυτό θα καθοριστεί επίσης από τους πελάτες.
- Επιχειρηματικές και τεχνικές απαιτήσεις: Πρέπει να έχετε το λογισμικό και οι σκοποί που εξυπηρετούν θα καθοριστούν με σαφήνεια μαζί με τις εξηγήσεις χαμηλού επιπέδου.
Περιορισμοί
Υπάρχουν λίγα πράγματα που μπορούν πραγματικά να ελέγξουν τη φάση δοκιμής λογισμικού, ιδίως τη φάση προγραμματισμού.
Παρακάτω είναι τόσο λίγες περιοχές:
- Χαρακτηριστικά που πρέπει να δοκιμάζονται και όχι: Αυτό θα δείξει σαφώς τι πρέπει να δοκιμαστεί και τι δεν πρέπει να είναι.
- Κριτήρια αναστολής και απαιτήσεις επανάληψης: Αυτός είναι ο υπεύθυνος λήψης αποφάσεων σχετικά με το λογισμικό που έχει αναπτυχθεί και τα κριτήρια καθορίζονται προκειμένου να ανασταλεί η δοκιμή ή να συνεχιστεί ο έλεγχος.
- Ευθύνες: Ένας υπεύθυνος δοκιμών θα έχει πολλαπλές ευθύνες για τη διασφάλιση των προβλημάτων, των σφαλμάτων και των ελαττωμάτων στο υπό δοκιμή λογισμικό. Επιπλέον, τα σφάλματα πρέπει να επικυρωθούν από τους προγραμματιστές για να τα διορθώσουν.
- Κίνδυνοι και απρόβλεπτα: Οι κίνδυνοι που συνδέονται κατά τη διάρκεια της δοκιμής θα πρέπει να αναφέρονται με σαφήνεια και τα κατάλληλα ενδεχόμενα κατά τη διάρκεια του χρόνου πρέπει να προσδιορίζονται πολύ καθαρά.
Μελέτη περίπτωσης # 1
Η ομάδα ανάπτυξης από Παράδειγμα # 1 σχεδιάζει να κυκλοφορήσει το λογισμικό XYZ σε 2 φάσεις. Η Φάση 1 έχει πολλά χαρακτηριστικά που πρέπει να δοκιμαστούν και λίγα που δεν πρέπει να δοκιμαστούν. Και πάλι το λογισμικό κυκλοφόρησε για δοκιμή χωρίς να ενημερώνει την ομάδα δοκιμών σχετικά με τις δυνατότητες που δεν έχουν ακόμη αναπτυχθεί.
Τώρα η ομάδα δοκιμών ξεκινά την εκτέλεση της με βάση τα σχέδια δοκιμών που έχουν ήδη επεξεργαστεί. Έρχονται με μεγάλο αριθμό σφαλμάτων. Και μετά την επικύρωση από την ομάδα ανάπτυξης, τα περισσότερα από αυτά είναι άκυρα.
Παρατηρήσεις από την παραπάνω μελέτη περίπτωσης:
- Ομάδα ανάπτυξης για την κυκλοφορία του λογισμικού στην ομάδα δοκιμών με σημειώσεις έκδοσης και σημειώσεις κάλυψης απαιτήσεων (σημειώσεις έκδοσης).
- Οι δυνατότητες που πρέπει να δοκιμαστούν και δεν πρέπει να δοκιμαστούν πρέπει να ληφθούν υπόψη βάσει του λογισμικού που κυκλοφόρησε πριν από τη δοκιμή.
- Τα κριτήρια αναστολής και επανάληψης για τη δοκιμή πρέπει να καθοριστούν σωστά.
- Ο κίνδυνος και τα σχέδια έκτακτης ανάγκης για τη μη διαθεσιμότητα του λογισμικού πρέπει να απεικονίζονται τέλεια.
Διαβάστε επίσης=> Πώς να διαχειριστείτε τους κινδύνους κατά τη φάση προγραμματισμού δοκιμών
Σχέδιο εκτέλεσης δοκιμής
Η εκτέλεση δοκιμαστικών περιπτώσεων είναι ένα από τα βήματα της φάσης STLC. Αυτό θα πρέπει να πραγματοποιηθεί σύμφωνα με τα σχέδια που εκπονήθηκαν νωρίτερα. Ως εκ τούτου, ο σχεδιασμός συνεχίζει να κυριαρχεί στο σύνολο της φάσης δοκιμών. Ακολουθεί ένα παράδειγμα όπου η ομάδα δοκιμών επηρεάζεται από τις αλλαγές στα σχέδια δοκιμών.
Παράδειγμα # 2
Ο έλεγχος του λογισμικού Α ξεκίνησε με βάση το σχέδιο 1 που επεξεργάστηκε η ομάδα. Αργότερα, λόγω των επιχειρηματικών αναγκών και των αλλαγών, το σχέδιο δοκιμών έπρεπε να υποστεί κάποιες αλλαγές. Αυτό, με τη σειρά του, ανάγκασε τις δοκιμαστικές περιπτώσεις ή την εκτέλεση να αλλάξει.
Παρατηρήσεις:
- Το σχέδιο δοκιμών θα καθορίσει την εκτέλεση της υπόθεσης.
- Το μέρος εκτέλεσης ποικίλλει ανάλογα με το πρόγραμμα.
- Όσο το πρόγραμμα και οι απαιτήσεις είναι έγκυρες, οι δοκιμαστικές περιπτώσεις ισχύουν επίσης.
Τρόποι αντιμετώπισης προβλημάτων κατά την εκτέλεση
Οι δοκιμαστές θα συναντήσουν συχνότερα διάφορα σενάρια ενώ εκτελούν την εκτέλεση της δοκιμής. Αυτό είναι όταν οι υπεύθυνοι δοκιμών θα πρέπει να κατανοήσουν και να γνωρίζουν τους τρόπους επίλυσης του προβλήματος ή τουλάχιστον να βρουν μια λύση για το ζήτημα.
Παράδειγμα # 3
Κατά την εκτέλεση της δοκιμαστικής περίπτωσης του λογισμικού Β, η ομάδα δοκιμών αντιμετωπίζει πολλά ζητήματα. Λίγοι από αυτούς είναι πώματα εκπομπών. Απαιτούν από τους προγραμματιστές να τους βοηθήσουν να ξεπεράσουν το ζήτημα. Αυτό έχει συμβεί πολλές φορές και το αποτέλεσμα είναι μια καθυστέρηση στον έλεγχο των παραδοτέων.
Παρατηρήσεις:
- Υπάρχει μια εξάρτηση για την υπέρβαση περιβαλλοντικών προβλημάτων και ζητημάτων.
- Απαιτείται σωστή κατανόηση του περιβάλλοντος για τους υπεύθυνους δοκιμών.
- Τα συχνά εμφανιζόμενα και γνωστά ζητήματα πρέπει να τεκμηριώνονται για να τα ξεπεράσουν στο μέλλον.
Έλεγχος και διαχείριση έκδοσης
Έλεγχος έκδοσης και η διαχείριση των σχεδίων δοκιμών και των δοκιμαστικών περιπτώσεων είναι πραγματικά σημαντικές για να δείξουν τα έγκαιρα παραδοτέα. Αυτό είναι πιο σημαντικό και συχνά γίνεται με τη βοήθεια ενός εργαλείου ελέγχου έκδοσης.
Ένα εργαλείο ελέγχου έκδοσης όχι μόνο τους βοηθά να ελέγχουν τα σχέδια δοκιμών αλλά και βοηθά στη διαχείριση ελαττωμάτων. Όταν υπάρχουν δοκιμαστικά έργα με πολλαπλούς κύκλους και εκδόσεις, αυτά τα εργαλεία μπορούν πραγματικά να βοηθήσουν πολύ στη μείωση των μετρήσεων για την υποστήριξη των παραδοτέων δοκιμών.
Επίσης, διαβάστε=> Διαχείριση κινδύνων στη φάση εκτέλεσης δοκιμών
Διαφορά μεταξύ προγραμματισμού δοκιμών και εκτέλεσης δοκιμών
Τα παρακάτω είναι μερικοί σημαντικοί τομείς που θα επισημάνουν πώς ο σχεδιασμός θα διαφέρει από τη φάση εκτέλεσης δοκιμής.
πώς να αρχικοποιήσετε μια σειρά αντικειμένων στην Java
| Περιοχή σύγκρισης | Σχεδιασμός δοκιμών | Εκτέλεση δοκιμής |
|---|---|---|
| Παραδοτέα τοποθέτηση | Το σχέδιο δοκιμών θα θεωρηθεί ως ένα σημαντικό παραδοτέο για τη δραστηριότητα δοκιμών. Αυτό θα γίνει ως το πρώτο βήμα στη διαδικασία δοκιμών. | Αυτό θα έρθει ως τελευταίο μέλος του πάγκου στη φάση δοκιμών. Μετά την εκτέλεση, η κατάσταση ελαττωμάτων / σφαλμάτων μαζί με την κατάσταση εκτέλεσης της δοκιμαστικής υπόθεσης θα κοινοποιηθεί ως ένα από τα παραδοτέα δοκιμών |
| Υπεύθυνος | Ο διαχειριστής δοκιμών θα προετοιμάσει το σχέδιο δοκιμών και θα μοιραστεί με όλους τους ενδιαφερόμενους για την αναθεώρησή τους. | Αυτό θα γίνει κανονικά από τον υπεύθυνο δοκιμών λαμβάνοντας υπόψη ότι οι δοκιμαστικές θήκες που έχουν προετοιμαστεί έχει εγκριθεί και υπογραφεί. |
| Κύρια εστίαση | Οι τομείς εστίασης του σχεδίου δοκιμών είναι ο τρόπος διεξαγωγής των δοκιμών, τι πρέπει να ληφθεί υπόψη και τι όχι, περιβάλλον που μπορεί να χρησιμοποιηθεί, προγράμματα δοκιμών κ.λπ. | Η δοκιμή εκτέλεσης επικεντρώνεται κυρίως στην εκτέλεση των δοκιμαστικών περιπτώσεων που παρέχονται για δοκιμή στο λογισμικό. |
| Επαναλαμβανόμενη ή επαναληπτική λειτουργία | Αυτή είναι μια δραστηριότητα μίας φοράς. Τούτου λεχθέντος ότι μπορεί ή όχι να απαιτούνται τροποποιήσεις για τις μελλοντικές εκδόσεις του λογισμικού. | Υπάρχουν 3 μέρη σε αυτόν τον τομέα όταν μιλάμε για επανάληψη. 1. Λειτουργικές δοκιμές. 2. Δοκιμές παλινδρόμησης. 3. Επανεξέταση. |
| Είσοδοι | Οι πληροφορίες για τη δημιουργία ενός δοκιμαστικού σχεδίου είναι πραγματικά απαραίτητες και πρέπει να παρέχονται από επιχειρηματικούς αναλυτές, αρχιτέκτονες, πελάτες κ.λπ., | Το έγγραφο δοκιμαστικής υπόθεσης είναι η κύρια εισαγωγή. |
| Περίοδος κατά την οποία μπορεί να ξεκινήσει | Πρέπει να ξεκινήσει μαζί με τον κύκλο ανάπτυξης για αποτελεσματικό αποτέλεσμα και για εξοικονόμηση χρόνου. Ωστόσο, υπάρχουν λίγα μοντέλα όπως το μοντέλο πτώσης νερού όπου η φάση δοκιμής θα ξεκινήσει μόνο μετά την ολοκλήρωση της φάσης ανάπτυξης. | Η εκτέλεση πρέπει να ξεκινήσει αυστηρά μετά την ανάπτυξη του λογισμικού. |
| Περίοδος κλεισίματος | Το πρόγραμμα δοκιμών δεν θα έχει τέτοια περίοδο κλεισίματος. Σε γενικές γραμμές θα παρέχεται μια εγγραφή από όλα τα ενδιαφερόμενα μέρη για το λογισμικό. | Η εκτέλεση για μια συγκεκριμένη έκδοση ή κύκλο θεωρείται ότι έχει κλείσει όταν όλες οι δοκιμαστικές περιπτώσεις έχουν εκτελεστεί έναντι του λογισμικού. |
| Χρήση εργαλείων | Δεν θα χρησιμοποιηθούν πολλά εργαλεία καθώς η δραστηριότητα σχεδιασμού θα είναι περισσότερο συζήτηση και τεκμηρίωση. Για να παρακολουθείτε τυχόν αλλαγές στο σχέδιο, οι διαχειριστές δοκιμών θα χρησιμοποιούν κανονικά οποιοδήποτε εργαλείο ελέγχου έκδοσης όπως το VSS ή κάτι άλλο. | Θα εξαρτηθεί από τον τρόπο εκτέλεσης. Σε περίπτωση εγχειριδίου δεν θα χρησιμοποιηθεί εργαλείο για εκτέλεση. Αλλά για την καταγραφή των ελαττωμάτων και τη διαχείριση, θα χρησιμοποιηθούν ορισμένα εργαλεία. Σε περίπτωση δοκιμών αυτοματισμού, η εκτέλεση θα γίνει με τη βοήθεια εργαλείων όπως QTP, SELENIUM κ.λπ. |
| Επιπτώσεις στα παραδοτέα | Αυτό θα επηρεάσει όλες τις φάσεις δοκιμής με μεγαλύτερο τρόπο | Αυτό θα επηρεάσει τον επόμενο κύκλο ή την απελευθέρωση που θα δοκιμαστεί. |
Οι παραπάνω απεικονίσεις θα μπορούσαν να έχουν εξηγηθεί σε καλύτερη μορφή σχετικά με τη σημασία των δραστηριοτήτων σχεδιασμού δοκιμών από αυτήν της εκτέλεσης δοκιμών. Με κάποιο τρόπο, η φάση εκτέλεσης είναι ένα είδος υποσυνόλου του σχεδίου δοκιμών.
Με βάση τη στρατηγική δοκιμών, την προσέγγιση και τα άλλα πράγματα, το σχέδιο δοκιμών έχει μεγαλύτερη πιθανότητα να τροποποιηθεί για να δώσει χώρο στις αλλαγές. Είναι σαφές ότι η εκτέλεση της δοκιμής εξαρτάται από τις δοκιμαστικές περιπτώσεις. Οι περιπτώσεις δοκιμής βασίζονται στα σχέδια. Ως εκ τούτου, οι αλλαγές στα σχέδια θα διασφαλίσουν αλλαγές στις δοκιμαστικές περιπτώσεις.
Αντίθετα, οι αλλαγές στις δοκιμαστικές περιπτώσεις δεν χρειάζεται υποχρεωτικά να αναζητούν αλλαγές. Αυτός είναι ένας από τους κύριους λόγους για τους οποίους ο προγραμματισμός συνεχίζεται σε σύγκριση με τη φάση εκτέλεσης δοκιμής.
Το επερχόμενο σεμινάριό μας θα σας εξηγήσει περισσότερα σχετικά με τον τρόπο δημιουργίας δοκιμαστικών περιπτώσεων; Τι είναι? Και πώς μπορούμε να τα κάνουμε να λειτουργήσουν για εμάς μαζί με τις διάφορες άλλες πτυχές που σχετίζονται με τις δοκιμαστικές περιπτώσεις.
ΕΠΟΜΕΝΟ Φροντιστήριο=> Ημέρα εκπαίδευσης QA-4: Γράψιμο δοκιμαστικών περιπτώσεων από έγγραφο SRS
Είστε ειδικός στη σύνταξη ενός εγγράφου δοκιμαστικού σχεδίου; Στη συνέχεια, αυτό είναι το σωστό μέρος για να μοιραστείτε τις πολύτιμες συμβουλές σας για βελτίωση για τους επερχόμενους δοκιμαστές. Μη διστάσετε να εκφράσετε τις σκέψεις σας μαζί μας στην παρακάτω ενότητα σχολίων !!
Συνιστώμενη ανάγνωση
- Δείγμα προτύπου προγράμματος δοκιμής λογισμικού με μορφή και περιεχόμενο
- Οδηγός τεκμηρίωσης δοκιμών λογισμικού (Γιατί είναι σημαντικό)
- Πόροι και λήψεις δοκιμών λογισμικού QA
- Δείγμα εγγράφου σχεδίου δοκιμής (παράδειγμα σχεδίου δοκιμής με λεπτομέρειες κάθε πεδίου)
- Δοκιμή εκτέλεσης σε δοκιμές λογισμικού: Ακριβής διαδικασία και σχέδιο με παράδειγμα
- Τρόπος σύνταξης εγγράφου στρατηγικής δοκιμής (με δείγμα προτύπου στρατηγικής δοκιμής)
- Σύνταξη δοκιμαστικών περιπτώσεων από έγγραφο SRS (ΛΗΨΗ Ζωντανών δειγμάτων δοκιμαστικών περιπτώσεων)
- Αναλυτικό πρόγραμμα μαθημάτων δοκιμής λογισμικού - Διαδικτυακό λεπτομερές πρόγραμμα εκπαίδευσης