Get your 6-month No-Cost Opt-Out offer for Unlimited Software Automation?

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

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

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

 

Πίνακας Περιεχομένων

Τι είναι η δοκιμή μαύρου κουτιού;

λίστα ελέγχου uat, εργαλεία ελέγχου εφαρμογών ιστού, αυτοματοποίηση και άλλα

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

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

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

 

1. Πότε και γιατί πρέπει να κάνετε δοκιμές μαύρου κουτιού στις δοκιμές λογισμικού;

Οφέλη από τη δημιουργία ενός Κέντρου Αριστείας Δοκιμών. Διαφέρει η δοκιμή επιδόσεων από τη λειτουργική δοκιμή;

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

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

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

 

2. Όταν δεν χρειάζεται να κάνετε δοκιμές μαύρου κουτιού

Οφέλη από τη δημιουργία ενός Κέντρου Αριστείας Δοκιμών. Διαφέρει η δοκιμή επιδόσεων από τη λειτουργική δοκιμή;

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

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

 

3. Ποιος εμπλέκεται στη δοκιμή μαύρου κουτιού;

Οφέλη από τη δημιουργία ενός Κέντρου Αριστείας Δοκιμών. Διαφέρει η δοκιμή επιδόσεων από τη λειτουργική δοκιμή;

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

 

Οι σημαντικοί ρόλοι με συμμετοχή στη διαδικασία δοκιμών μαύρου κουτιού περιλαμβάνουν:

 

– Δοκιμαστής

 

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

 

– Αναλυτής QA

 

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

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

 

– Προγραμματιστής

 

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

 

– Διευθυντής QA

 

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

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

 

– Επικεφαλής έργου

 

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

 

Οφέλη των δοκιμών Black Box

Υπολογιστής ROI

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

 

Μερικά από τα κύρια οφέλη της χρήσης δοκιμών μαύρου κουτιού στη διασφάλιση ποιότητας περιλαμβάνουν:

 

1. Δεν απαιτούνται τεχνικές γνώσεις

 

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

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

 

2. Ακριβής μοντελοποίηση του χρήστη

 

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

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

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

 

3. Δυνατότητα δοκιμής από το πλήθος

 

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

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

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

 

Προκλήσεις των δοκιμών Black Box

προκλήσεις δοκιμές φορτίου

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

 

Ορισμένες από αυτές τις προκλήσεις περιλαμβάνουν:

 

1. Δύσκολο να βρεθούν οι αιτίες του προβλήματος

 

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

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

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

 

2. Η αυτοματοποίηση είναι πιο δύσκολη

 

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

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

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

 

3. Δυσκολίες με δοκιμές υψηλής κλίμακας

 

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

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

 

Χαρακτηριστικά των δοκιμών Black Box

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

 

Τα χαρακτηριστικά αυτά περιλαμβάνουν:

 

1. Καμία προηγούμενη εσωτερική γνώση

 

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

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

 

2. Διαχωρίστε τους δοκιμαστές και τους προγραμματιστές

 

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

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

 

3. Δοκιμές σε προχωρημένο στάδιο

 

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

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

 

Τι δοκιμάζουμε στις δοκιμές μαύρου κουτιού

λίστα ελέγχου uat, εργαλεία ελέγχου εφαρμογών ιστού, αυτοματοποίηση και άλλα

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

 

Μερικά από τα κύρια μέρη ενός πακέτου λογισμικού που εξετάζουν οι ελεγκτές σε μια δοκιμή “μαύρου κουτιού” περιλαμβάνουν:

 

1. Λειτουργικότητα

 

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

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

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

 

2. Διεπαφή χρήστη

 

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

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

Η δοκιμή “μαύρου κουτιού” παρουσιάζει στους ελεγκτές μόνο τα χαρακτηριστικά του λογισμικού στο τέλος του χρήστη, δίνοντας μεγαλύτερη προσοχή στο UI από ό,τι στα περισσότερα άλλα στάδια της δοκιμής.

 

3. Απόδοση

 

Εκτός από την κανονική λειτουργία και την καλή εμφάνιση, ο τρόπος με τον οποίο λειτουργεί μια εφαρμογή είναι απαραίτητος για να ικανοποιήσει τους πελάτες.

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

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

 

Ξεκαθαρίζοντας κάποια σύγχυση:

Δοκιμές Black box vs White box vs Greybox

Σύγκριση των δοκιμών UAT με τις δοκιμές παλινδρόμησης και άλλες

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

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

 

1. Τι είναι το White Box Testing;

Οφέλη από τη δημιουργία ενός Κέντρου Αριστείας Δοκιμών. Διαφέρει η δοκιμή επιδόσεων από τη λειτουργική δοκιμή;

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

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

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

 

Ποιες είναι οι διαφορές μεταξύ white box και black box Testing;

 

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

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

 

2. Τι είναι η δοκιμή γκρίζου κουτιού;

Οφέλη από τη δημιουργία ενός Κέντρου Αριστείας Δοκιμών. Διαφέρει η δοκιμή επιδόσεων από τη λειτουργική δοκιμή;

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

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

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

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

 

Ποιες είναι οι διαφορές μεταξύ Black box και Grey box Testing;

 

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

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

 

3. Συμπέρασμα: Δοκιμές Black Box vs. White Box vs. Grey Box

 

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

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

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

 

Τύποι δοκιμών Black Box

δοκιμές αυτοματοποίησης εφαρμογών ιστού

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

 

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

 

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

Η δοκιμή της λειτουργικότητας είναι μία από τις πιο σημαντικές πτυχές της διαδικασίας και περιλαμβάνει τόσο την τοπική λειτουργικότητα της εφαρμογής όσο και τον τρόπο με τον οποίο αλληλεπιδρά με εξωτερικά εργαλεία και προγράμματα, όπως υπηρεσίες που βασίζονται στο cloud ή εργαλεία Single Sign On.

 

2. Μη λειτουργικές δοκιμές

 

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

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

 

3. Δοκιμή παλινδρόμησης

 

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

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

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

 

Τεχνικές δοκιμών μαύρου κουτιού

Κύκλος ζωής UAT

Όταν περνάτε από τη διαδικασία δοκιμών μαύρου κουτιού, υπάρχει ένα ευρύ φάσμα τεχνικών που μπορείτε να εφαρμόσετε για να βελτιώσετε το επίπεδο της εργασίας σας. Ορισμένες από τις σημαντικότερες τεχνικές δοκιμών “μαύρου κουτιού” που χρησιμοποιείτε σε ένα περιβάλλον διασφάλισης ποιότητας περιλαμβάνουν:

 

1. Δοκιμές ανά ζεύγη

 

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

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

 

2. Ανάλυση οριακών τιμών

 

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

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

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

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

 

3. Δοκιμή μετάβασης κατάστασης

 

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

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

 

Δοκιμές “μαύρου κουτιού” στον κύκλο ζωής της μηχανικής λογισμικού

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

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

 

Χειροκίνητες ή αυτοματοποιημένες δοκιμές μαύρου κουτιού;

όραση υπολογιστή για δοκιμές λογισμικού

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

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

 

1. Χειροκίνητη δοκιμή μαύρου κουτιού – Οφέλη, προκλήσεις, διαδικασία

 

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

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

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

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

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

 

2. Black box Test Automation – Οφέλη, Προκλήσεις, Διαδικασία

 

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

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

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

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

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

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

 

3. Συμπέρασμα: Χειροκίνητη ή αυτοματοποιημένη δοκιμή μαύρου κουτιού;

Οφέλη από τη δημιουργία ενός Κέντρου Αριστείας Δοκιμών. Διαφέρει η δοκιμή επιδόσεων από τη λειτουργική δοκιμή;

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

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

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

 

Τι χρειάζεστε για να ξεκινήσετε τις δοκιμές Black Box;

Τι είναι ο έλεγχος μονάδας

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

 

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

 

1. Απαιτήσεις λογισμικού

 

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

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

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

 

2. Μεταγλωττισμένο λογισμικό

 

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

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

 

3. Στόχοι δοκιμών

 

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

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

 

Διαδικασία δοκιμών Black Box

τύποι δοκιμών επιδόσεων

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

 

1. Σχεδιασμός δοκιμών

 

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

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

 

2. Συγγραφή περιπτώσεων δοκιμής

 

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

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

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

 

3. Εκτέλεση περιπτώσεων δοκιμής

 

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

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

 

4. Τελική αναφορά

 

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

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

 

Βέλτιστες πρακτικές για δοκιμές Black Box

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

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

 

Ορισμένες από αυτές τις πρακτικές που βοηθούν μια εταιρεία να βελτιώσει την ποιότητα των δοκιμών “μαύρου κουτιού” περιλαμβάνουν:

 

1. Έμφαση στην ανάπτυξη δεξιοτήτων

 

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

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

 

2. Ισορροπία φόρτων εργασίας

 

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

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

 

3. Δημιουργία συνεπών διαδικασιών

 

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

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

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

 

7 λάθη και παγίδες στην εφαρμογή δοκιμών Black Box

Σύγκριση των δοκιμών UAT με τις δοκιμές παλινδρόμησης και άλλες

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

 

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

 

1. Έλλειψη καθορισμένου πεδίου δοκιμών

 

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

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

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

 

2. Βιαστικές διαδικασίες δοκιμών

 

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

 

3. Αυτοματοποίηση χωρίς διαδικασία επαλήθευσης

 

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

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

 

4. Μη χρήση υβριδικών δοκιμών

 

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

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

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

 

5. Μη ολοκλήρωση των δοκιμών παλινδρόμησης

 

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

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

 

6. Ενεργό κυνήγι για σφάλματα

 

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

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

 

7. Αγνοώντας τη διαίσθησή σας

 

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

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

 

Τύποι εξόδων από δοκιμές Black Box

πλεονεκτήματα της δημιουργίας ενός κέντρου αριστείας δοκιμών (TCoE)

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

 

Μερικοί από τους κύριους τύπους αποτελεσμάτων των δοκιμών “μαύρου κουτιού” περιλαμβάνουν:

 

1. Ποιοτικά δεδομένα

 

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

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

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

 

2. Ποσοτικά δεδομένα

 

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

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

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

 

3. Μηνύματα σφάλματος

 

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

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

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

 

Παραδείγματα δοκιμών Black box

Τι είναι η δοκιμή λογισμικού;

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

 

Ορισμένα παραδείγματα μεθόδων δοκιμών “μαύρου κουτιού”, συμπεριλαμβανομένων πολλαπλών τύπων δοκιμών και διαφορετικών βαθμών επιτυχίας, περιλαμβάνουν:

 

1. Αναποτελεσματική δοκιμή αποδοχής χρηστών

 

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

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

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

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

 

2. Επιτυχής δοκιμή από άκρο σε άκρο

 

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

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

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

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

 

3. Αυτοματοποιημένες δοκιμές παλινδρόμησης

 

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

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

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

 

Τύποι σφαλμάτων και σφαλμάτων που ανιχνεύονται μέσω Black box Testing

zaptest-runtime-error.png

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

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

 

Μερικοί από τους κύριους τύπους σφαλμάτων και σφαλμάτων που μπορούν να εντοπιστούν μέσω δοκιμών μαύρου κουτιού περιλαμβάνουν:

 

1. Σφάλματα ευχρηστίας

 

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

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

 

2. Λειτουργικά σφάλματα

 

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

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

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

 

3. Συντριβές

 

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

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

 

Κοινές μετρήσεις δοκιμών Black Box

δοκιμή φορτίου

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

 

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

 

1. Ποσοστό σφάλματος

 

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

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

 

2. Χρόνος απόκρισης

 

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

 

3. Ικανοποίηση των χρηστών

 

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

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

 

Καλύτερα εργαλεία δοκιμών Black Box

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

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

 

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

 

5 Καλύτερα δωρεάν εργαλεία δοκιμών Black Box

 

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

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

 

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

 

1. ZAPTEST ΔΩΡΕΆΝ ΈΚΔΟΣΗ

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

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

Η δωρεάν έκδοση του ZAPTEST διαθέτει ένα τεράστιο πλήθος λειτουργιών για την υποστήριξη της αυτοματοποίησης οποιασδήποτε εφαρμογής… 1SCRIPT εφαρμογή cross browser, cross device, cross application και παράλληλη εκτέλεση είναι ένα από τα διαθέσιμα χαρακτηριστικά.

 

2. JIRA

 

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

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

 

3. Selenium IDE

 

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

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

 

4. AutoHotkey

 

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

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

 

5. Appium

 

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

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

 

5 Καλύτερα εργαλεία δοκιμών Black Box για επιχειρήσεις

 

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

 

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

 

1. ZAPTEST ENTERPRISE EDITION

Η έκδοση Enterprise του ZAPTEST είναι ένα από τα σημαντικότερα εργαλεία αυτοματοποίησης στην αγορά και μπορεί να προσφέρει έως και 10πλάσια απόδοση της επένδυσης για το προϊόν σας.

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

 

2. TestRail

 

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

 

3. Opkey

 

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

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

 

4. Perfecto

 

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

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

 

5. JIRA Enterprise

 

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

 

Πότε πρέπει να χρησιμοποιείτε

Enterprise vs. Freemium Black Box εργαλεία;

Οφέλη από τη δημιουργία ενός Κέντρου Αριστείας Δοκιμών. Διαφέρει η δοκιμή επιδόσεων από τη λειτουργική δοκιμή;

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

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

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

 

Λίστα ελέγχου, συμβουλές και κόλπα για δοκιμές μαύρου κουτιού

Κατάλογος ελέγχου δοκιμών λογισμικού

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

 

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

 

– Κατανόηση της εντολής

 

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

 

– Επιδιόρθωση της περίπτωσης δοκιμής

 

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

 

– Οργανώστε μια λίστα με τα πράγματα που πρέπει να γίνουν

 

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

 

– Καταγράψτε αμέσως τα αποτελέσματα

 

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

 

– Επικοινωνία με προγραμματιστές

 

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

 

– Δεδομένα που μπορούν να αναλάβουν δράση

 

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

 

– Κατανοήστε τις προτεραιότητές σας

 

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

 

– Γνωρίστε την ιεραρχία

 

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

 

– Διατηρήστε συνεπή τεκμηρίωση

 

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

 

Συμπέρασμα

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

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

 

Συχνές ερωτήσεις & πόροι

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

 

1. Καλύτερα μαθήματα για τον αυτοματισμό δοκιμών Black box

 

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

 

Μερικά από τα πιο αναγνωρισμένα μαθήματα δοκιμών μαύρου κουτιού που είναι διαθέσιμα περιλαμβάνουν:

 

– “Black-box and White-box Testing” από το Coursera

– “Η σειρά Black-Box Software Testing” από την BBST

– “Εισαγωγή στις τεχνικές δοκιμών λογισμικού Black Box” από το Udemy

– “Δοκιμές αυτοματισμού λογισμικού” από το London School of Emerging Technology

– “Τρεις βασικές τεχνικές δοκιμών μαύρου κουτιού” από το Udemy

 

2. Ποιες είναι οι 5 κορυφαίες ερωτήσεις συνέντευξης για το Black box Testing;

 

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

 

– Τι εμπειρία έχετε σε δοκιμές μαύρου κουτιού;

– Ποιες είναι οι κύριες διαφορές μεταξύ των δοκιμών “μαύρου κουτιού” και “λευκού κουτιού”;

– Έχετε κάποια εμπειρία με την αυτοματοποίηση λογισμικού σε προηγούμενους ρόλους σας;

– Μπορείτε να μας πείτε μια φορά που αντιμετωπίσατε προκλήσεις στον εργασιακό χώρο και πώς τις ξεπεράσατε;

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

 

3. Καλύτερα σεμινάρια στο Youtube για Black Box Testing

 

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

 

Μερικά από τα καλύτερα σεμινάρια που μπορείτε να παρακολουθήσετε όταν μαθαίνετε δοκιμές μαύρου κουτιού είναι τα εξής:

 

– “Black and White Box Testing Introduction – Georgia Tech – Διαδικασία ανάπτυξης λογισμικού” από το Udacity

– “Black Box and Glass Box Testing” από το MIT OpenCourseWare

– “7 Black Box Testing Techniques That Every QA Should Know” από την The Testing Academy

– “Black Box Testing | Τι είναι το Black Box Testing | Μάθετε Black Box Testing” από την Intellipaat

– “Τι είναι το White vs. Grey vs. Black Box Testing;” από το ITProTV

 

4. Πώς να διατηρήσετε δοκιμές Black Box;

 

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

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

 

5. Καλύτερα βιβλία για δοκιμές μαύρου κουτιού

 

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

 

Μερικά από τα καλύτερα βιβλία σχετικά με τις δοκιμές μαύρου κουτιού περιλαμβάνουν:

 

– “Δοκιμές μαύρου κουτιού: Beizer” του Boris Beizer

– “Δοκιμές λογισμικού: Gopalaswamy Ramesh” των Srinivasan Desikan, Gopalaswamy Ramesh

– “Essentials of Software Testing” των Ralf Bierig, Stephen Brown, Edgar Galván

– “Εισαγωγή στις δοκιμές λογισμικού” των Paul Ammann, Jeff Offutt

Download post as PDF

Alex Zap Chernyak

Alex Zap Chernyak

Founder and CEO of ZAPTEST, with 20 years of experience in Software Automation for Testing + RPA processes, and application development. Read Alex Zap Chernyak's full executive profile on Forbes.

Get PDF-file of this post