top 20 practical software testing tips you should read before testing any application
Εύχομαι σε όλους τους υπεύθυνους δοκιμών να διαβάσουν τις πρακτικές ελέγχου λογισμικού που ενημερώθηκαν σε αυτό το άρθρο . Διαβάστε προσεκτικά κάθε σημείο και προσπαθήστε να τα εφαρμόσετε στις καθημερινές σας δραστηριότητες δοκιμών. Αυτό περιμένω από τους αναγνώστες μέσω αυτού του άρθρου. Εάν δεν καταλαβαίνετε καμία πρακτική δοκιμών, ζητήστε περισσότερες διευκρινίσεις στην παρακάτω ενότητα σχολίων.
Ωστόσο, θα μάθετε όλες αυτές τις πρακτικές δοκιμών από εμπειρία. Αλλά γιατί δεν μαθαίνετε όλα αυτά πριν κάνετε κάποιο λάθος;
Ελάτε να ρίξουμε μια ματιά τους!
Εδώ είναι μερικές από τις καλύτερες πρακτικές δοκιμών που έμαθα από την εμπειρία:
απαριθμήστε τυχόν λειτουργικά συστήματα με τα οποία είστε εξοικειωμένοι
# 1) Μάθετε να αναλύετε διεξοδικά τα αποτελέσματα των δοκιμών σας. Μην αγνοείτε τα αποτελέσματα των δοκιμών. Το τελικό αποτέλεσμα της δοκιμής μπορεί να είναι «επιτυχία» ή «αποτυχία», αλλά η αντιμετώπιση προβλημάτων της βασικής αιτίας του «αποτυχία» θα σας δώσει τη λύση στο πρόβλημα. Οι δοκιμαστές θα γίνονται σεβαστοί εάν όχι μόνο καταγράφουν το Σφάλματα αλλά επίσης παρέχει λύσεις.
#δύο) Μάθετε να μεγιστοποιείτε το Κάλυψη δοκιμής κάθε φορά που δοκιμάζετε οποιαδήποτε εφαρμογή. Η δοκιμαστική κάλυψη 100% μπορεί να μην είναι δυνατή, ωστόσο, μπορείτε πάντα να προσπαθήσετε να την πλησιάσετε.
# 3) Προκειμένου να διασφαλιστεί η μέγιστη κάλυψη δοκιμών, σπάστε την εφαρμογή σας υπό δοκιμή (AUT), σε μικρότερες λειτουργικές ενότητες. Γράψτε δοκιμαστικές θήκες σε τέτοιες μεμονωμένες ενότητες μονάδων. Επίσης, εάν είναι δυνατόν, χωρίστε αυτές τις ενότητες σε μικρότερα μέρη.
Για παράδειγμα, ας υποθέσουμε ότι έχετε διαιρέσει την εφαρμογή του ιστότοπού σας σε ενότητες και ότι η «αποδοχή πληροφοριών χρήστη» είναι μία από τις ενότητες. Μπορείτε να διαχωρίσετε αυτήν την οθόνη 'Πληροφορίες χρήστη' σε μικρότερα μέρη για τη σύνταξη δοκιμαστικών περιπτώσεων: Μέρη όπως δοκιμή UI, Δοκιμή ασφαλείας , Λειτουργική δοκιμή της φόρμας «Πληροφορίες χρήστη» κ.λπ.
Εφαρμόστε όλες τις δοκιμές τύπου και μεγέθους πεδίου φόρμας, αρνητικές και δοκιμές επικύρωσης στα πεδία εισαγωγής και γράψτε όλες αυτές τις περιπτώσεις δοκιμών για μέγιστη κάλυψη.
# 4) Ενώ Γράψιμο δοκιμαστικών περιπτώσεων , γράψτε πρώτα δοκιμαστικές περιπτώσεις για την προβλεπόμενη λειτουργικότητα, δηλαδή για έγκυρες συνθήκες σύμφωνα με τις απαιτήσεις. Στη συνέχεια, γράψτε δοκιμαστικές περιπτώσεις για μη έγκυρες συνθήκες. Αυτό θα καλύψει την αναμενόμενη καθώς και την απροσδόκητη συμπεριφορά της υπό δοκιμή εφαρμογής.
# 5) Σκεφτείτε θετικά. Ξεκινήστε να δοκιμάζετε την εφαρμογή με σκοπό την εύρεση σφαλμάτων / σφαλμάτων. Μην νομίζετε εκ των προτέρων ότι δεν θα υπάρχουν σφάλματα στην εφαρμογή. Εάν δοκιμάσετε την εφαρμογή με σκοπό να βρείτε σφάλματα, σίγουρα θα καταφέρετε να τα βρείτε Λεπτά σφάλματα επίσης.
# 6) Γράψτε τις δοκιμαστικές σας περιπτώσεις στην ίδια τη φάση ανάλυσης και σχεδιασμού απαιτήσεων. Με αυτόν τον τρόπο μπορείτε να διασφαλίσετε ότι όλες οι απαιτήσεις είναι ελεγχόμενες.
# 7) Φτιάξτε το δικό σας δοκιμαστικές περιπτώσεις διαθέσιμες στους προγραμματιστές πριν από την κωδικοποίηση. Μην κρατάτε τις δοκιμαστικές σας υποθέσεις περιμένοντας να λάβετε την τελική έκδοση της αίτησης για δοκιμή, πιστεύοντας ότι μπορείτε να καταγράψετε περισσότερα σφάλματα. Αφήστε τους προγραμματιστές να αναλύσουν διεξοδικά τις δοκιμαστικές σας περιπτώσεις για να αναπτύξουν μια εφαρμογή ποιότητας. Αυτό θα εξοικονομήσει επίσης το χρόνο επανεργασίας.
# 8) Εάν είναι δυνατόν, προσδιορίστε και ομαδοποιήστε τις δοκιμαστικές σας περιπτώσεις Δοκιμή παλινδρόμησης . Αυτό θα εξασφαλίσει γρήγορη και αποτελεσματική χειροκίνητη δοκιμή παλινδρόμησης.
# 9) Οι εφαρμογές που απαιτούν κρίσιμο χρόνο απόκρισης πρέπει να ελέγχονται διεξοδικά για την απόδοση. Δοκιμή απόδοσης είναι ένα κρίσιμο μέρος πολλών εφαρμογών. Σε Εγχειρίδιο Δοκιμή, αυτό είναι το πιο αγνοημένο μέρος των υπευθύνων δοκιμών λόγω της έλλειψης απαιτούμενου μεγάλου όγκου δεδομένων στη δοκιμή απόδοσης.
Μάθετε πώς μπορείτε να δοκιμάσετε την απόδοση της εφαρμογής σας. Εάν δεν είναι δυνατή η μη αυτόματη δημιουργία δεδομένων δοκιμής, τότε γράψτε μερικά βασικά σενάρια για να δημιουργήσετε δεδομένα δοκιμών για δοκιμές απόδοσης ή ζητήστε από τους προγραμματιστές να γράψουν ένα για εσάς.
# 10) Οι προγραμματιστές δεν πρέπει να δοκιμάσουν τον δικό τους κωδικό. Όπως συζητήθηκε στο μας προηγούμενη ανάρτηση , ο βασικός έλεγχος μονάδας των ανεπτυγμένων εφαρμογών θα πρέπει να είναι αρκετός για τους προγραμματιστές να αποδεσμεύουν την εφαρμογή για δοκιμαστές. Αλλά εσείς (δοκιμαστής) δεν πρέπει να αναγκάσετε τους προγραμματιστές να αποδεσμεύσουν το προϊόν για δοκιμή.
Αφήστε τους να πάρουν το δικό τους χρόνο. Όλοι από τον προπονητή έως τον διαχειριστή γνωρίζουν πότε κυκλοφορεί η ενότητα / ενημέρωση για δοκιμή και μπορούν να εκτιμήσουν ανάλογα τον χρόνο δοκιμής. Αυτή είναι μια τυπική κατάσταση σε ένα Ευκίνητος περιβάλλον έργου.
# 11) Πηγαίνετε πέρα από τον έλεγχο απαιτήσεων. Δοκιμάστε την εφαρμογή για το τι δεν πρέπει να κάνει.
πού είναι το κλειδί ασφαλείας δικτύου στο δρομολογητή μου
# 12) Ενώ κάνετε δοκιμές παλινδρόμησης χρησιμοποιήστε το προηγούμενο γράφημα σφαλμάτων (Γράφημα σφαλμάτων - αριθμός σφαλμάτων που βρέθηκαν σε σχέση με το χρόνο για διαφορετικές ενότητες). Αυτό το γράφημα σφαλμάτων βάσει λειτουργικής μονάδας μπορεί να είναι χρήσιμο για την πρόβλεψη του πιο πιθανού τμήματος σφάλματος της εφαρμογής.
# 13) Σημειώστε τους νέους όρους, τις έννοιες που μαθαίνετε κατά τη δοκιμή. Διατηρήστε ένα αρχείο κειμένου ανοιχτό κατά τη δοκιμή οποιασδήποτε εφαρμογής. Σημειώστε την πρόοδο και τις παρατηρήσεις της δοκιμής μέσα σε αυτό. Χρησιμοποιήστε αυτές τις παρατηρήσεις του σημειωματάριου κατά την προετοιμασία της τελικής έκθεσης δοκιμής. Αυτή η καλή συνήθεια θα σας βοηθήσει να παράσχετε μια πλήρη σαφή αναφορά δοκιμής και λεπτομέρειες έκδοσης.
# 14) Πολλές φορές οι δοκιμαστές ή οι προγραμματιστές κάνουν αλλαγές στη βάση κώδικα για εφαρμογή υπό δοκιμή. Αυτό είναι ένα απαιτούμενο βήμα στην ανάπτυξη ή το περιβάλλον δοκιμών για να αποφευχθεί η εκτέλεση της ζωντανής επεξεργασίας συναλλαγών όπως σε τραπεζικά έργα.
Σημειώστε όλες αυτές τις αλλαγές κώδικα που έγιναν για σκοπούς δοκιμής και κατά τη στιγμή της τελικής έκδοσης βεβαιωθείτε ότι έχετε καταργήσει όλες αυτές τις αλλαγές από τους πόρους του αρχείου ανάπτυξης του τελικού πελάτη.
# 15) Κρατήστε τους προγραμματιστές μακριά από το περιβάλλον δοκιμών. Απαιτείται ένα βήμα για τον εντοπισμό τυχόν αλλαγών διαμόρφωσης που λείπουν στο έγγραφο έκδοσης ή ανάπτυξης. Μερικές φορές οι προγραμματιστές κάνουν κάποιες αλλαγές στη διαμόρφωση του συστήματος ή της εφαρμογής, αλλά ξεχνούν να τις αναφέρουν στα βήματα ανάπτυξης.
Εάν οι προγραμματιστές δεν έχουν πρόσβαση στο περιβάλλον δοκιμών, δεν θα πραγματοποιήσουν τέτοιες αλλαγές κατά λάθος στο περιβάλλον δοκιμής και αυτά τα στοιχεία που λείπουν μπορούν να καταγραφούν στο σωστό μέρος.
# 16) Είναι καλή πρακτική εμπλέκουν υπεύθυνους δοκιμών από την ίδια τη φάση Απαίτηση και Σχεδιασμός Λογισμικού. Με αυτόν τον τρόπο οι υπεύθυνοι δοκιμών μπορούν να αποκτήσουν γνώση της αξιοπιστίας της εφαρμογής με αποτέλεσμα τη λεπτομερή κάλυψη των δοκιμών. Εάν δεν σας ζητείται να συμμετέχετε σε αυτόν τον κύκλο ανάπτυξης, τότε μπορείτε να υποβάλετε αίτημα στον προϊστάμενό σας ή στον διευθυντή σας για συμμετοχή της ομάδας δοκιμών σε όλες τις διαδικασίες λήψης αποφάσεων ή τις συναντήσεις.
# 17) Οι ομάδες δοκιμών πρέπει μοιραστείτε τις βέλτιστες πρακτικές δοκιμών , εμπειρία με τις άλλες ομάδες του οργανισμού τους.
# 18) Αυξήστε τη συνομιλία σας με τους προγραμματιστές για να μάθετε περισσότερα για το προϊόν. Όποτε είναι δυνατόν, επικοινωνήστε πρόσωπο με πρόσωπο για γρήγορη επίλυση των διαφορών και για να αποφύγετε τυχόν παρεξηγήσεις.
Αλλά επίσης όταν καταλαβαίνετε την απαίτηση ή επιλύετε οποιαδήποτε διαφορά - φροντίστε να κοινοποιήσετε τους ίδιους αντικατασταθέντες τρόπους επικοινωνίας όπως τα μηνύματα ηλεκτρονικού ταχυδρομείου. Μην κρατάτε τίποτα λεκτικά.
# 19) Μην τρέχετε Τέλος χρόνου να κάνουμε δοκιμές υψηλής προτεραιότητας. Δώστε προτεραιότητα στη δοκιμαστική σας εργασία από υψηλή έως χαμηλή προτεραιότητα και σχεδιάστε την εργασία σας ανάλογα. Αναλύστε όλους τους σχετικούς κινδύνους για να δώσετε προτεραιότητα στην εργασία σας.
# 20) Γράψτε μια σαφή, περιγραφική, ξεκάθαρη Αναφορά σφαλμάτων . Μην παρέχετε μόνο τα συμπτώματα του σφάλματος, αλλά επίσης παρέχετε το αποτέλεσμα του σφάλματος και όλες τις πιθανές λύσεις.
Μην ξεχνάτε ότι η δοκιμή είναι μια δημιουργική και προκλητική εργασία. Τέλος, όλα εξαρτώνται από την ικανότητα και την εμπειρία σας ως προς τον τρόπο με τον οποίο χειρίζεστε αυτήν την πρόκληση.
Σε εσάς:
Η κοινή χρήση της δικής σας εμπειρίας δοκιμών, συμβουλών ή μυστικών δοκιμών στα παρακάτω σχόλια θα κάνει σίγουρα αυτό το άρθρο πιο ενδιαφέρον και χρήσιμο !!
Πείτε μας τις σκέψεις σας / προτάσεις σχετικά με αυτό το άρθρο.
Συνιστώμενη ανάγνωση
- Τα καλύτερα εργαλεία δοκιμής λογισμικού 2021 (QA Test Automation Tools)
- Δοκιμή λογισμικού QA Assistant Job
- Είναι η δοκιμή λογισμικού μια συναισθηματική εργασία;
- Μάθημα δοκιμών λογισμικού: Σε ποιο Ινστιτούτο Δοκιμών Λογισμικού πρέπει να εγγραφώ;
- Επιλέγοντας Δοκιμή λογισμικού ως καριέρα σας
- Δοκιμή λογισμικού Τεχνικό περιεχόμενο Συγγραφέας Freelancer Job
- Τι είναι το Monkey Testing στο λογισμικό Testing;
- Δοκιμή εφαρμογών - Στα βασικά του ελέγχου λογισμικού!