Τρόπος σύνταξης δοκιμαστικών περιπτώσεων: Ο απόλυτος οδηγός με παραδείγματα

how write test cases

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

Τι είναι μια υπόθεση δοκιμής;

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

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

Λίστα μαθημάτων που καλύπτονται σε αυτήν τη σειρά γραφής υπόθεση δοκιμής:

Πως να γράψεις:

Εκμάθηση # 1: Τι είναι μια δοκιμαστική θήκη και πώς να γράφετε δοκιμαστικές περιπτώσεις (αυτό το σεμινάριο)
Εκμάθηση # 2: Δείγμα προτύπου υπόθεσης δοκιμής με παραδείγματα (Λήψη) (πρέπει να διαβάσετε)
Εκμάθηση # 3: Γράψιμο δοκιμαστικών περιπτώσεων από έγγραφο SRS
Εκμάθηση # 4: Πώς να γράψετε δοκιμαστικές περιπτώσεις για ένα δεδομένο σενάριο
Εκμάθηση # 5: Πώς να προετοιμαστείτε για τη σύνταξη δοκιμαστικών περιπτώσεων
Εκμάθηση # 6: Πώς να γράψετε αρνητικές δοκιμαστικές περιπτώσεις

Παραδείγματα:

Εκμάθηση # 7: 180+ Δείγμα δοκιμαστικών περιπτώσεων για εφαρμογές Web και Desktop
Εκμάθηση # 8: 100+ Σενάρια δοκιμής έτοιμων προς εκτέλεση (Λίστα ελέγχου)

Τεχνικές γραφής:

Εκμάθηση # 9: Γράφημα αιτιών και εφέ - Τεχνική δυναμικής γραφής υπόθεσης δοκιμής
Εκμάθηση # 10: Τεχνική δοκιμής μετάβασης κατάστασης
Εκμάθηση # 11: Τεχνική ορθογωνικής σειράς δοκιμών
Εκμάθηση # 12: Τεχνική εκτίμησης σφαλμάτων
Εκμάθηση # 13: Τεχνική σχεδίασης δοκιμής πίνακα επικύρωσης πεδίου (FVT)

ο καλύτερος δωρεάν μετατροπέας βίντεο για mac

Σενάρια δοκιμής Vs Test:

Εκμάθηση # 14: Σενάρια δοκιμής Vs Test
Εκμάθηση # 15: Διαφορά μεταξύ του σχεδίου δοκιμής, της στρατηγικής δοκιμής και της υπόθεσης δοκιμής

Αυτοματοποίηση:

Εκμάθηση # 16: Πώς να επιλέξετε σωστές περιπτώσεις δοκιμών για έλεγχο αυτοματισμού
Εκμάθηση # 17: Πώς να μεταφράσετε χειροκίνητες δοκιμαστικές περιπτώσεις σε σενάρια αυτοματισμού

Εργαλεία διαχείρισης δοκιμών:

Εκμάθηση # 18: Τα καλύτερα εργαλεία διαχείρισης δοκιμών
Εκμάθηση # 19: TestLink για διαχείριση υπόθεσης δοκιμής
Εκμάθηση # 20: Δημιουργία και διαχείριση δοκιμαστικών περιπτώσεων με χρήση του HP Quality Center
Εκμάθηση # 21: Εκτέλεση δοκιμαστικών περιπτώσεων με χρήση ALM / QC

Ειδικές περιπτώσεις τομέα:

Εκμάθηση # 22: Δοκιμαστικές περιπτώσεις για εφαρμογή ERP
Εκμάθηση # 23: Θήκες δοκιμής εφαρμογής JAVA
Εκμάθηση # 24: Ανάλυση οριακής τιμής και κατανομή ισοδυναμίας

Ας συνεχίσουμε με το πρώτο σεμινάριο αυτής της σειράς.

Προτεινόμενα εργαλεία:

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

# 1) TestRail

=> Λήψη TestRail Test Case Management Tool

# 2) TestMonitor

Διαδικτυακή διαχείριση δοκιμών ανώτατου επιπέδου. Επαναστατικό εύκολο.

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

=> Επισκεφτείτε τον ιστότοπο TestMonitor

Τι θα μάθετε:

• Τι είναι μια δοκιμαστική θήκη και πώς να γράφετε δοκιμαστικές περιπτώσεις;
  • Γιατί γράφουμε δοκιμές;
  • Πώς να γράψετε δοκιμαστικές περιπτώσεις;
  • Βασική μορφή δήλωσης υπόθεσης δοκιμής
• Συμβουλές για τη συγγραφή δοκιμών
  • • # 1) Κρατήστε το απλό αλλά όχι πολύ απλό. Κάντε το πολύπλοκο αλλά όχι πολύ περίπλοκο:
    • # 2) Μετά την τεκμηρίωση των δοκιμαστικών περιπτώσεων, ελέγξτε μία φορά ως Tester:
    • # 3) Δεσμευμένος και διευκολύνει τους δοκιμαστές:
    • # 4) Γίνετε συνεργάτης:
    • # 5) Μην ξεχνάτε ποτέ τον τελικό χρήστη:
• Πώς να επιτύχετε την τελειότητα στην τεκμηρίωση δοκιμαστικών περιπτώσεων
  • Χρήσιμες συμβουλές και κόλπα
    • # 1) Είναι το έγγραφο δοκιμής σας σε καλή κατάσταση;
    • # 2) Μην ξεχάσετε να καλύψετε τις αρνητικές περιπτώσεις
    • # 3) Κάντε ατομικά βήματα δοκιμής
    • # 4) Δώστε προτεραιότητα στις δοκιμές
    • # 5) Θέματα ακολουθίας
    • # 6) Προσθέστε τη χρονική σήμανση και το όνομα του ελεγκτή στα σχόλια
    • # 7) Συμπερίληψη λεπτομερειών προγράμματος περιήγησης
    • # 8) Κρατήστε δύο ξεχωριστά φύλλα - «Σφάλματα» και «Περίληψη» στο Έγγραφο
• Πώς ΔΕΝ γράφετε δοκιμές
  • 3 Πιο κοινά προβλήματα σε δοκιμαστικές περιπτώσεις
    • # 1) Σύνθετα βήματα
    • # 2) Η συμπεριφορά της εφαρμογής λαμβάνεται ως αναμενόμενη συμπεριφορά
    • # 3) Πολλαπλές συνθήκες σε μία περίπτωση
• Πώς να βελτιώσετε την αποτελεσματικότητα της δοκιμαστικής περίπτωσης
  • Συλλογή εγγράφων για δοκιμαστική συγγραφή
  • Πραγματικό παράδειγμα
  • Έγγραφο δοκιμαστικής υπόθεσης
  • Συλλογή δεδομένων δοκιμής
• Σημασία της τυποποίησης των δοκιμαστικών περιπτώσεων
  • Λόγοι επαναχρησιμοποίησης δοκιμαστικών περιπτώσεων
  • Τι είναι μια τυπική δοκιμή στο Web Testing;
  • συμπέρασμα
  • Συνιστώμενη ανάγνωση

Τι είναι μια δοκιμαστική θήκη και πώς να γράφετε δοκιμαστικές περιπτώσεις;

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

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

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

Επίπεδα της διαδικασίας γραφής δοκιμής:

• Επίπεδο 1: Σε αυτό το επίπεδο, θα γράψετε το βασικές περιπτώσεις από τις διαθέσιμες προδιαγραφές και τεκμηρίωση χρήστη.
• Επίπεδο 2: Αυτό είναι το πρακτικό στάδιο στην οποία οι περιπτώσεις γραφής εξαρτώνται από την πραγματική λειτουργική και ροή συστήματος της εφαρμογής.
• Επίπεδο 3: Αυτό είναι το στάδιο στο οποίο θα ομαδοποιήσετε ορισμένες περιπτώσεις και γράψτε μια διαδικασία δοκιμής . Η διαδικασία δοκιμής δεν είναι παρά μια ομάδα μικρών περιπτώσεων, ίσως το πολύ 10.
• Επίπεδο 4: Αυτοματοποίηση του έργου. Αυτό θα ελαχιστοποιήσει την ανθρώπινη αλληλεπίδραση με το σύστημα και έτσι το QA μπορεί να επικεντρωθεί στις τρέχουσες ενημερωμένες λειτουργίες για δοκιμή παρά να παραμείνει απασχολημένος με τον έλεγχο παλινδρόμησης.

Γιατί γράφουμε δοκιμές;

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

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

Πώς να γράψετε δοκιμαστικές περιπτώσεις;

Πεδία:

• Αναγνωριστικό περίπτωσης δοκιμής
• Μονάδα προς δοκιμή: Τι πρέπει να επαληθευτεί;
• Υποθέσεις
• Δεδομένα δοκιμής: Μεταβλητές και οι τιμές τους
• Βήματα προς εκτέλεση
• Αναμενόμενο Αποτέλεσμα
• Πραγματικό αποτέλεσμα
• Πέρασμα / αποτυχία
• Σχόλια

Βασική μορφή δήλωσης υπόθεσης δοκιμής

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

Επαληθεύω: Χρησιμοποιείται ως η πρώτη λέξη της δήλωσης δοκιμής.
Χρησιμοποιώντας: Για να προσδιορίσετε τι δοκιμάζεται. Μπορείτε να χρησιμοποιήσετε το «enter» ή το «select» εδώ αντί να το χρησιμοποιήσετε ανάλογα με την κατάσταση.

Για οποιαδήποτε εφαρμογή, πρέπει να καλύψετε όλους τους τύπους δοκιμών όπως:

• Λειτουργικές θήκες
• Αρνητικές περιπτώσεις
• Περιπτώσεις οριακής αξίας

Ενώ γράφετε όλα αυτά Τα TC πρέπει να είναι απλά και εύκολα κατανοητά .

************************************************

Συμβουλές για τη συγγραφή δοκιμών

Μία από τις πιο συχνές και σημαντικές δραστηριότητες ενός Τεστ λογισμικού (άτομο SQA / SQC) είναι η σύνταξη δοκιμαστικών σεναρίων και περιπτώσεων.

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

Σημαντικοί παράγοντες που εμπλέκονται Διαδικασία γραφής:

α) Τα TC είναι επιρρεπή σε τακτική αναθεώρηση και ενημέρωση:

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

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

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

β) Τα TC είναι επιρρεπή στη διανομή μεταξύ των υπεύθυνων δοκιμών που θα τα εκτελέσουν:

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

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

γ) Τα TC είναι επιρρεπή σε ομαδοποίηση και δέσμευση:

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

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

δ) Τα TC έχουν μια τάση αλληλεξάρτησης:

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

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

ε) Τα TC είναι επιρρεπή στη διανομή μεταξύ των προγραμματιστών (ειδικά σε περιβάλλον ανάπτυξης βάσει δοκιμών):

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

Συμβουλές για να γράψετε αποτελεσματικές δοκιμές:

Λαμβάνοντας υπόψη τους παραπάνω 5 παράγοντες, Ακολουθούν μερικές συμβουλές για τη σύνταξη αποτελεσματικών TC.

Ας αρχίσουμε!!!

# 1) Κρατήστε το απλό αλλά όχι πολύ απλό. Κάντε το πολύπλοκο αλλά όχι πολύ περίπλοκο:

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

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

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

# 2) Μετά την τεκμηρίωση των δοκιμαστικών περιπτώσεων, ελέγξτε μία φορά ως Tester:

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

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

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

# 3) Δεσμευμένος και διευκολύνει τους δοκιμαστές:

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

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

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

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

# 4) Γίνετε συνεργάτης:

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

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

Όντας QA, μην δοκιμάζετε μόνο, αλλά κάντε τη διαφορά!

# 5) Μην ξεχνάτε ποτέ τον τελικό χρήστη:

Ο σημαντικότερος ενδιαφερόμενος είναι ο «Τελικός χρήστης» που θα χρησιμοποιήσει επιτέλους την εφαρμογή. Επομένως, μην τον ξεχάσετε ποτέ σε οποιοδήποτε στάδιο της γραφής των TC. Στην πραγματικότητα, ο Τελικός Χρήστης δεν πρέπει να αγνοείται σε κανένα στάδιο καθ 'όλη τη διάρκεια του SDLC. Ωστόσο, η έμφαση μου μέχρι τώρα σχετίζεται μόνο με το θέμα μου.

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

************************************************

Πώς να επιτύχετε την τελειότητα στην τεκμηρίωση δοκιμαστικών περιπτώσεων

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

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

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

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

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

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

Χρήσιμες συμβουλές και κόλπα

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

# 1) Είναι το έγγραφο δοκιμής σας σε καλή κατάσταση;

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

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

# 2) Μην ξεχάσετε να καλύψετε τις αρνητικές περιπτώσεις

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

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

# 3) Κάντε ατομικά βήματα δοκιμής

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

# 4) Δώστε προτεραιότητα στις δοκιμές

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

Μπορείτε να χρησιμοποιήσετε οποιαδήποτε κωδικοποίηση για τον καθορισμό της προτεραιότητας μιας δοκιμής. Είναι γενικά καλύτερο να χρησιμοποιήσετε οποιοδήποτε από τα 3 επίπεδα, υψηλή, μεσαία και χαμηλή , ή 1, 50 και 100. Επομένως, όταν έχετε ένα αυστηρό χρονοδιάγραμμα, θα πρέπει πρώτα να ολοκληρώσετε όλες τις δοκιμές υψηλής προτεραιότητας και μετά να προχωρήσετε στις δοκιμές μέσης και χαμηλής προτεραιότητας.

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

# 5) Θέματα ακολουθίας

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

# 6) Προσθέστε τη χρονική σήμανση και το όνομα του ελεγκτή στα σχόλια

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

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

# 7) Συμπερίληψη λεπτομερειών προγράμματος περιήγησης

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

# 8) Κρατήστε δύο ξεχωριστά φύλλα - «Σφάλματα» και «Περίληψη» στο Έγγραφο

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

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

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

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

************************************************

Πώς ΔΕΝ γράφετε δοκιμές

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

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

Ας διαβάσετε και λάβετε υπόψη ότι αυτές οι συμβουλές αφορούν τόσο τους νέους όσο και τους έμπειρους δοκιμαστές.

3 Πιο κοινά προβλήματα σε δοκιμαστικές περιπτώσεις

1. Σύνθετα βήματα
2. Η συμπεριφορά της εφαρμογής λαμβάνεται ως αναμενόμενη συμπεριφορά
3. Πολλαπλές συνθήκες σε μία περίπτωση

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

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

Ας φτάσουμε σε αυτό και να συζητήσουμε καθένα λεπτομερώς:

# 1) Σύνθετα βήματα

Πρώτα απ 'όλα, τι είναι ένα σύνθετο βήμα;

Για παράδειγμα, δίνετε οδηγίες από το σημείο Α έως το σημείο Β: εάν λέτε ότι 'Πηγαίνετε στο μέρος XYZ και μετά στο ABC' αυτό δεν θα έχει πολύ νόημα, γιατί εδώ πιστεύουμε - 'Πώς μπορώ φτάστε στην πρώτη θέση στο XYZ '- αντί να ξεκινήσετε με' Στρίψτε αριστερά από εδώ και πάμε 1 μίλι και μετά στρίψτε δεξιά στην Rd. Νο 11 για να φτάσετε στο XYZ »μπορεί να επιτύχει καλύτερα αποτελέσματα.

Οι ακριβείς ίδιοι κανόνες ισχύουν και για τις δοκιμές και τα βήματα.

Για παράδειγμα Γράφω ένα τεστ για το Amazon.com - κάντε μια παραγγελία για οποιοδήποτε προϊόν.

Τα παρακάτω είναι τα βήματα δοκιμής μου (Σημείωση: Γράφω μόνο τα βήματα και όχι όλα τα άλλα μέρη του τεστ όπως το αναμενόμενο αποτέλεσμα κ.λπ.)

προς την . Εκκινήστε το Amazon.com
σι . Αναζητήστε ένα προϊόν εισάγοντας τη λέξη-κλειδί / όνομα προϊόντος στο πεδίο «Αναζήτηση» στο πάνω μέρος της οθόνης.
ντο . Από τα αποτελέσματα αναζήτησης που εμφανίζονται, επιλέξτε το πρώτο.
ρε . Κάντε κλικ στο Προσθήκη στο καλάθι στη σελίδα λεπτομερειών του προϊόντος.
είναι . Ταμείο και πληρωμή.
φά . Ελέγξτε τη σελίδα επιβεβαίωσης παραγγελίας.

Τώρα, μπορείτε να προσδιορίσετε ποιο από αυτά είναι ένα σύνθετο βήμα; Δεξί βήμα (ε)

Θυμηθείτε, οι δοκιμές αφορούν πάντα το 'Πώς' να δοκιμάσετε, οπότε είναι σημαντικό να γράψετε τα ακριβή βήματα του 'Πώς να κάνετε check out και να πληρώσετε' στη δοκιμή σας.

Επομένως, η παραπάνω υπόθεση είναι πιο αποτελεσματική όταν γράφεται ως εξής:

προς την . Εκκινήστε το Amazon.com
σι . Αναζητήστε ένα προϊόν εισάγοντας τη λέξη-κλειδί / όνομα προϊόντος στο πεδίο «Αναζήτηση» στο πάνω μέρος της οθόνης.
ντο . Από τα αποτελέσματα αναζήτησης που εμφανίζονται, επιλέξτε το πρώτο.
ρε . Κάντε κλικ στο Προσθήκη στο καλάθι στη σελίδα λεπτομερειών του προϊόντος.
είναι . Κάντε κλικ στο Checkout στη σελίδα του καλαθιού αγορών.
φά . Εισαγάγετε τα στοιχεία CC, τα στοιχεία αποστολής και χρέωσης.
σολ . Κάντε κλικ στο Ταμείο.
η . Ελέγξτε τη σελίδα επιβεβαίωσης παραγγελίας.

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

# 2) Η συμπεριφορά της εφαρμογής λαμβάνεται ως αναμενόμενη συμπεριφορά

Όλο και περισσότερα έργα πρέπει να αντιμετωπίσουν αυτήν την κατάσταση αυτές τις μέρες.

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

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

Εάν ακολουθεί η σελίδα που γράφετε / σχεδιάζετε τα βήματα δοκιμής για:

Περίπτωση 1:

Εάν τα βήματα της δοκιμαστικής μου υπόθεσης είναι τα παρακάτω:

1. Ξεκινήστε τον ιστότοπο αγορών.
2. Κάντε κλικ στο Αποστολή και επιστροφή - Αναμενόμενο αποτέλεσμα: Η σελίδα αποστολής και επιστροφών εμφανίζεται με το κουμπί 'Βάλτε τα στοιχεία σας εδώ' και ένα κουμπί 'Συνέχεια'.

Τότε, αυτό είναι λάθος.

Περίπτωση 2:

1. Ξεκινήστε τον ιστότοπο αγορών.
2. Κάντε κλικ στο Αποστολή και επιστροφή.
3. Στο πλαίσιο κειμένου «Εισαγάγετε τον αριθμό παραγγελίας» που υπάρχει σε αυτήν την οθόνη, εισαγάγετε τον αριθμό παραγγελίας.
4. Κάντε κλικ στο Συνέχεια - Αναμενόμενο αποτέλεσμα: Εμφανίζονται οι λεπτομέρειες της παραγγελίας που σχετίζονται με την αποστολή και τις επιστροφές.

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

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

# 3) Πολλαπλές συνθήκες σε μία περίπτωση

Για άλλη μια φορά, ας μάθουμε από Παράδειγμα .

Ρίξτε μια ματιά στα παρακάτω βήματα δοκιμής: Τα παρακάτω είναι τα βήματα δοκιμής σε μία δοκιμή για μια λειτουργία σύνδεσης.

ένα. Εισαγάγετε έγκυρα στοιχεία και κάντε κλικ στο Υποβολή.
σι. Αφήστε το πεδίο Όνομα χρήστη κενό. Κάντε κλικ στο Υποβολή.
ντο. Αφήστε το πεδίο κωδικού πρόσβασης κενό και κάντε κλικ στο Υποβολή.
ρε. Επιλέξτε ήδη όνομα χρήστη / κωδικό πρόσβασης και κάντε κλικ στο Υποβολή.

Αυτό που έπρεπε να είναι 4 διαφορετικές περιπτώσεις συνδυάζεται σε μία. Ίσως σκέφτεστε - Τι συμβαίνει με αυτό; Αποθηκεύει πολλά έγγραφα και τι μπορώ να κάνω στο 4, το κάνω στο 1 - δεν είναι τόσο καλό; Λοιπόν, όχι αρκετά. Αιτιολογικό?

Συνέχισε να διαβάζεις:

• Τι γίνεται αν μία από τις προϋποθέσεις αποτύχει - πρέπει να επισημάνουμε ολόκληρο το τεστ ως «αποτυχημένο». Αν επισημάνουμε ολόκληρη την υπόθεση ως 'απέτυχε', αυτό σημαίνει ότι και οι 4 συνθήκες δεν λειτουργούν, κάτι που δεν είναι αλήθεια.
• Οι δοκιμές πρέπει να έχουν ροή. Από την προϋπόθεση έως το βήμα 1 και όλα τα βήματα. Εάν ακολουθήσω αυτήν την υπόθεση, στο βήμα (α), εάν είναι επιτυχής, θα συνδεθώ στη σελίδα, όπου η επιλογή 'σύνδεση' δεν είναι πλέον διαθέσιμη. Έτσι, όταν φτάσω στο βήμα (β) - πού θα εισαγάγει ο υπεύθυνος δοκιμών το όνομα χρήστη; Βλέπετε, η ροή είναι σπασμένη.

Ως εκ τούτου, γράψτε αρθρωτές δοκιμές . Ακούγεται σαν πολλή δουλειά, αλλά το μόνο που χρειάζεται για εσάς είναι να διαχωρίσετε τα πράγματα και να χρησιμοποιήσετε τους καλύτερους φίλους μας Ctrl + C και Ctrl + V για να δουλέψετε για εμάς. :)

************************************************

Πώς να βελτιώσετε την αποτελεσματικότητα της δοκιμαστικής περίπτωσης

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

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

Συλλογή εγγράφων για δοκιμαστική συγγραφή

# 1) Έγγραφο απαιτήσεων χρήστη

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

# 2) Έγγραφο περίπτωσης επαγγελματικής χρήσης

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

# 3) Έγγραφο λειτουργικών απαιτήσεων

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

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

ποιοι είναι οι καλύτεροι ιστότοποι anime

# 4) Πρόγραμμα έργου λογισμικού (προαιρετικό)

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

# 5) Σχέδιο QA / δοκιμής

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

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

Πραγματικό παράδειγμα

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

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

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

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

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

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

• Δοκιμές UI :Τα στοιχεία ελέγχου / πεδία που είναι ορατά στον χρήστη. Υπάρχουν στατικοί έλεγχοι και δυναμικά στοιχεία ελέγχου για τη δυνατότητα δοκιμής. Για παράδειγμα, Στην παραπάνω οθόνη σύνδεσης, τα κείμενα «Όνομα χρήστη και κωδικός πρόσβασης» είναι στατικά πεδία που δεν απαιτούν αλληλεπίδραση χρήστη, μόνο για την εμφάνιση του κειμένου μόνο.

• Λειτουργικές θήκες :Από την άλλη πλευρά, το κουμπί σύνδεσης και οι υπερσυνδέσεις (Forgot Password? & Registration) είναι δυναμικά πεδία που απαιτούν αλληλεπίδραση χρήστη κάνοντας κλικ στα στοιχεία ελέγχου, τα οποία θα κάνουν κάποια ενέργεια αργότερα.

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

• Διαδικασίες δοκιμών :Αυτό σχετίζεται με τη διαδικασία (όχι τις ενέργειες που σχετίζονται με τα ορατά στοιχεία ελέγχου που είναι διαθέσιμα στην οθόνη) που σχετίζονται με τη λειτουργία και τη λειτουργικότητα. Για παράδειγμα, Κάνοντας κλικ στο σύνδεσμο Ξεχάσατε τον κωδικό πρόσβασης στην παραπάνω οθόνη δείγματος ενδέχεται να στείλετε ένα email στον χρήστη. Λοιπόν, ίσως ένα email πρέπει να δοκιμαστεί για τη σωστή διαδικασία και επιβεβαίωση.

4) Τέλος, κρατήστε το « ΜΑΝΤΑ ΜΠΑΡΑ ', που σημαίνει i) Βασική ροή ii) Εναλλακτική ροή iii) Επιλογές και iv) Εξαιρέσεις για την πλήρη κάλυψη της λειτουργικής ροής και του χαρακτηριστικού που θα δοκιμαστεί. Κάθε ιδέα πρέπει να εφαρμόζεται σε θετικά και αρνητικά τεστ.

Για παράδειγμα, ας δούμε την απλή προσέγγιση BAOE για την παραπάνω οθόνη σύνδεσης δείγματος.

• Βασική ροή: Εισαγάγετε τη διαδρομή URL της σύνδεσης σε οποιοδήποτε πρόγραμμα περιήγησης και εισαγάγετε τις απαιτούμενες πληροφορίες και συνδεθείτε στην εφαρμογή.
• Εναλλακτική ροή: Εγκαταστήστε την εφαρμογή σε κινητή συσκευή και εισαγάγετε τις απαιτούμενες πληροφορίες και συνδεθείτε στην εφαρμογή.
• Επιλογές: Ποιες είναι οι διαθέσιμες επιλογές για την ίδια οθόνη σύνδεσης; Για παράδειγμα, μετά τη σύνδεση στην εφαρμογή, κάνοντας κλικ στην επιλογή «Αποσύνδεση» ενδέχεται να εμφανιστεί η ίδια οθόνη ή εάν το χρονικό όριο περιόδου λειτουργίας ή η περίοδος σύνδεσης έληξε, ο χρήστης μπορεί να έρθει στην οθόνη σύνδεσης.
• Εξαιρέσεις: Ποιες είναι οι εξαιρέσεις εάν οι δοκιμές μου είναι αρνητικές; Για παράδειγμα, Εάν εισαχθούν λανθασμένα διαπιστευτήρια στην οθόνη σύνδεσης, εάν ο χρήστης θα λάβει ένα μήνυμα σφάλματος ή δεν θα συνδεθεί κάποια ενέργεια.

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

Διαβάστε επίσης=> 180+ δείγματα έτοιμα προς χρήση δοκιμαστικές θήκες για εφαρμογές ιστού και επιτραπέζιου υπολογιστή.

Έγγραφο δοκιμαστικής υπόθεσης

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

Διαβάστε επίσης=> Δείγμα προτύπου υπόθεσης δοκιμής με παραδείγματα.

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

Σημείωση : Προσθήκη στήλης Πραγματικής συμπεριφοράς στο τέλος αυτού του προτύπου.

Συλλογή δεδομένων δοκιμής

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

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

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

************************************************

Σημασία της τυποποίησης των δοκιμαστικών περιπτώσεων

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

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

Το ερώτημα που με ενοχλεί πάντα είναι ότι: «Εάν οι περισσότερες εφαρμογές είναι παρόμοιες, για παράδειγμα: όπως ιστότοποι λιανικής, οι οποίοι έχουν δοκιμαστεί χίλιες φορές πριν,« Γιατί πρέπει να γράψουμε δοκιμαστικές θήκες για ακόμη έναν ιστότοπο λιανικής από το μηδέν; ' Δεν θα εξοικονομήσετε τόνο χρόνο τραβώντας τα υπάρχοντα δοκιμαστικά σενάρια που χρησιμοποιήθηκαν για τη δοκιμή ενός προηγούμενου ιστότοπου λιανικής;

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

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

Λόγοι επαναχρησιμοποίησης δοκιμαστικών περιπτώσεων

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

#δύο) Τα περισσότερα από τα έργα είναι απλώς βελτιώσεις ή αλλαγές στην υπάρχουσα λειτουργικότητα.

# 3) Τα συστήματα διαχείρισης περιεχομένου που ορίζουν τις υποδοχές για μεταφορτώσεις εικόνων με στατικούς και δυναμικούς τρόπους είναι επίσης κοινά για όλους τους ιστότοπους.

# 4) Οι ιστότοποι λιανικής έχουν CSR (Εξυπηρέτηση πελατών) επίσης.

# 5) Το σύστημα Backend και η εφαρμογή αποθήκης που χρησιμοποιούν JDA χρησιμοποιούνται επίσης από όλους τους ιστότοπους.

# 6) Η έννοια των cookie, το χρονικό όριο και η ασφάλεια είναι επίσης κοινά.

# 7) Τα έργα που βασίζονται στο Διαδίκτυο είναι συχνά επιρρεπή σε αλλαγές απαιτήσεων.

# 8) ο τύποι δοκιμών απαιτούνται είναι κοινά όπως το πρόγραμμα περιήγησης δοκιμή συμβατότητας , δοκιμή απόδοσης , δοκιμή ασφαλείας

Βλέπετε, υπάρχουν πολλά που είναι κοινά και παρόμοια.

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

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

Τι είναι μια τυπική δοκιμή στο Web Testing;

• Δημιουργήστε δοκιμαστικές περιπτώσεις που είναι πλήρεις - βήματα, δεδομένα, μεταβλητές κ.λπ. Αυτό θα διασφαλίσει ότι τα μη παρόμοια δεδομένα / μεταβλητή μπορούν απλά να αντικατασταθούν όταν απαιτείται παρόμοια δοκιμαστική θήκη.
• Τα κριτήρια εισόδου και εξόδου πρέπει να καθοριστούν σωστά.
• Τα τροποποιήσιμα βήματα ή η δήλωση στα βήματα πρέπει να επισημαίνονται με διαφορετικό χρώμα για γρήγορη εύρεση και αντικατάσταση.
• Η γλώσσα που χρησιμοποιείται για την τυπική δημιουργία δοκιμαστικών περιπτώσεων πρέπει να είναι γενική.
• Όλες οι δυνατότητες κάθε ιστότοπου πρέπει να καλύπτονται στις δοκιμαστικές περιπτώσεις.
• Το όνομα των δοκιμαστικών περιπτώσεων πρέπει να είναι το όνομα της λειτουργικότητας ή της δυνατότητας που καλύπτει η δοκιμαστική θήκη. Αυτό θα διευκολύνει την εύρεση της δοκιμαστικής θήκης από το σετ.
• Εάν υπάρχει κάποιο βασικό ή τυπικό δείγμα ή αρχείο GUI ή στιγμιότυπο οθόνης της δυνατότητας, τότε θα πρέπει να επισυναφθεί με τα σχετικά βήματα.

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

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

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

συμπέρασμα

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

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

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

Επόμενο σεμινάριο

Συνιστώμενη ανάγνωση

• Λειτουργική δοκιμή εναντίον μη λειτουργική δοκιμή
• Οδηγός δοκιμής φορητότητας με πρακτικά παραδείγματα
• Τύποι δοκιμών λογισμικού: Διαφορετικοί τύποι δοκιμών με λεπτομέρειες
• Τα καλύτερα εργαλεία δοκιμής λογισμικού 2021 (QA Test Automation Tools)
• Δοκιμή άλφα και δοκιμή beta (Ένας πλήρης οδηγός)
• Τι είναι το System Testing - Ένας απόλυτος οδηγός για αρχάριους
• ISTQB Testing Certification Δείγμα ερωτημάτων με απαντήσεις
• Τρόπος σύνταξης εβδομαδιαίας αναφοράς κατάστασης δοκιμών λογισμικού