Μενού

Κλειδί για επιτυχημένη δοκιμή μονάδας - Πώς δοκιμάζουν οι προγραμματιστές τον δικό τους κώδικα;

key successful unit testing how developers test their own code

Δοκιμάστε Το Όργανο Μας Για Την Εξάλειψη Των Προβλημάτων

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

Αλλά ως περιέργεια ή Εκτός σκέψης σκέφτεται , αναρωτηθήκατε ποτέ πώς δοκιμάζουν οι προγραμματιστές τον κώδικά τους; Ποια μέθοδος χρησιμοποιούν για να δοκιμάσουν πριν κυκλοφορήσουν κώδικα για δοκιμές; Πώς είναι σημαντικό το dev-testing σε μια ευέλικτη διαδικασία; Η απάντηση σε όλα αυτά είναι Unit Testing. Θέλω να σας ενημερώσω για τη σημασία της δοκιμής μονάδας, έτσι ώστε οι ομάδες ανάπτυξης και δοκιμών να μπορούν να συνεργαστούν περισσότερο για να σχεδιάσουν, να δοκιμάσουν και να κυκλοφορήσουν μια εξαιρετική εφαρμογή.

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

Δοκιμή μονάδας

Τι θα μάθετε:

Τι είναι η δοκιμή μονάδας;

Το Unit Testing δεν είναι μια νέα ιδέα. Ήταν εκεί από τις πρώτες μέρες του προγραμματισμού. Συνήθως, προγραμματιστές και μερικές φορές Δοκιμαστές λευκού κουτιού εγγραφή Μονάδες δοκιμών για τη βελτίωση της ποιότητας του κώδικα επαληθεύοντας κάθε μονάδα του κώδικα που χρησιμοποιείται για την εφαρμογή λειτουργικών απαιτήσεων (γνωστός και ως δοκιμαστική ανάπτυξη TDD ή δοκιμή-ανάπτυξη πρώτη).

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

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

Δοκιμή μονάδας σε SDLC

Δοκιμή μονάδας σε SDLC

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

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

Σημασία της γραφής μονάδων δοκιμών

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

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

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

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

Μέθοδοι δοκιμής μονάδας

Μπορεί να εκτελεστεί με 2 τρόπους:

  1. Μη αυτόματη δοκιμή
  2. Αυτοματοποιημένες δοκιμές

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

Είναι γεγονός ότι το 100% του Αυτοματισμού δεν είναι δυνατό και έτσι θα υπάρχει πάντα κάποιο επίπεδο χειροκίνητης δοκιμής.

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

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

Τεχνικές εντός δοκιμής μονάδας

# 1) Δοκιμή λευκού κουτιού:

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

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

δοκιμή λευκού κουτιού

# 2) Δοκιμή μαύρου κουτιού:

Κατά τη δοκιμή black-box, ο ελεγκτής δεν γνωρίζει ούτε τις εσωτερικές δομές ούτε τον κώδικα του λογισμικού.

δοκιμή μαύρου κουτιού

# 3) Δοκιμή γκρι κουτιού:

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

Δοκιμή γκρι κουτιού

Η δοκιμή γκρι κουτιού καλύπτει τους ακόλουθους τύπους δοκιμών:

  • Δοκιμή μήτρας.
  • Δοκιμή μοτίβου.
  • Δοκιμή ορθογώνιου μοτίβου.
  • Δοκιμή παλινδρόμησης.

Οφέλη της δοκιμής μονάδας

  1. Η διαδικασία γίνεται ευκίνητη: Για την προσθήκη νέων λειτουργιών ή λειτουργιών στο υπάρχον λογισμικό πρέπει να κάνουμε αλλαγές στον παλιό κώδικα. Αλλά η αλλαγή των πραγμάτων στον ήδη δοκιμασμένο κώδικα μπορεί να είναι επικίνδυνη και δαπανηρή.
  2. Η ποιότητα κώδικα βελτιώνεται: Η ποιότητα του κώδικα βελτιώνεται αυτόματα όταν πραγματοποιείται δοκιμή μονάδας. Τα σφάλματα που εντοπίστηκαν κατά τη διάρκεια αυτής της δοκιμής διορθώθηκαν πριν αποσταλεί για τη φάση δοκιμής ενοποίησης. Αποτέλεσμα σε στιβαρό σχεδιασμό και ανάπτυξη καθώς οι προγραμματιστές γράφουν δοκιμαστικές θήκες κατανοώντας πρώτα τις προδιαγραφές.
  3. Ανιχνεύει σφάλματα νωρίς: Καθώς οι προγραμματιστές εκτελούν δοκιμές μονάδας, εντοπίζουν σφάλματα στον αρχικό κύκλο ζωής ανάπτυξης λογισμικού και τα επιλύουν. Αυτό περιλαμβάνει ελαττώματα ή μέρη που λείπουν στην προδιαγραφή, καθώς και σφάλματα στην εφαρμογή του προγραμματιστή.
  4. Ευκολότερες αλλαγές και απλοποιημένες ενσωματώσεις: Η πραγματοποίηση δοκιμών μονάδας διευκολύνει τον προγραμματιστή να αναδιαρθρώσει τον κώδικα, να κάνει αλλαγές και να διατηρήσει τον κώδικα. Διευκολύνει επίσης τον έλεγχο του κώδικα μετά την ενσωμάτωση. Η επίλυση ενός προβλήματος στη δοκιμή μονάδας μπορεί να διορθώσει πολλά άλλα ζητήματα που εμφανίζονται σε μεταγενέστερα στάδια ανάπτυξης και δοκιμών
  5. Διαθεσιμότητα τεκμηρίωσης: Οι προγραμματιστές που εξετάζουν τη λειτουργικότητα σε μεταγενέστερο στάδιο μπορούν να ανατρέξουν στην τεκμηρίωση δοκιμών μονάδας και μπορούν εύκολα να βρουν τη διεπαφή δοκιμής μονάδας και να διορθώσουν ή να εργαστούν γρήγορα και εύκολα.
  6. Εύκολη διαδικασία εντοπισμού σφαλμάτων: Βοηθά στην απλοποίηση της διαδικασίας εντοπισμού σφαλμάτων. Εάν η δοκιμή αποτύχει σε οποιοδήποτε στάδιο, ο κωδικός πρέπει να διορθωθεί ή αλλιώς η διαδικασία μπορεί να συνεχιστεί χωρίς εμπόδια.
  7. Χαμηλότερο κόστος: Όταν εντοπιστούν σφάλματα και επιλυθούν κατά τη διάρκεια της δοκιμής μονάδας, το κόστος και ο χρόνος ανάπτυξης μειώνεται. Χωρίς αυτόν τον έλεγχο, εάν τα ίδια σφάλματα εντοπιστούν σε μεταγενέστερο στάδιο μετά την ενσωμάτωση του κώδικα, γίνεται πιο δύσκολο να εντοπιστεί και να επιλυθεί, καθιστώντας το πιο ακριβό και αυξάνοντας τον χρόνο ανάπτυξης.
  8. Η πληρότητα του κώδικα μπορεί να αποδειχθεί χρησιμοποιώντας δοκιμές μονάδας: Αυτό είναι πιο χρήσιμο στην ευέλικτη διαδικασία. Οι υπεύθυνοι δοκιμών δεν μπορούν να δοκιμάσουν τις λειτουργικές εκδόσεις έως ότου ολοκληρωθεί η ενσωμάτωση. Η συμπλήρωση κώδικα δεν μπορεί να δικαιολογηθεί δείχνοντας ότι έχετε γράψει και ελέγξει τον κωδικό. Ωστόσο, η εκτέλεση δοκιμών μονάδας μπορεί να αποδείξει την πληρότητα του κώδικα.
  9. Εξοικονομεί χρόνο ανάπτυξης: Η ολοκλήρωση κώδικα μπορεί να διαρκέσει περισσότερο χρόνο, αλλά λόγω λιγότερων σφαλμάτων στη δοκιμή συστήματος και αποδοχής, ο συνολικός χρόνος ανάπτυξης μπορεί να εξοικονομηθεί.
  10. Κάλυψη κώδικα μπορεί να μετρηθεί

Κύκλος δοκιμής μονάδας

Κύκλος δοκιμών μονάδας

(εικόνα πηγή )

Τι κάνει ένα καλό τεστ μονάδας;

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

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

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

Πλαίσια δοκιμής μονάδας

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

Λίστα δημοφιλών Εργαλεία δοκιμής μονάδας για διαφορετικές γλώσσες προγραμματισμού:

  1. Πλαίσιο Java - JUnit
  2. Πλαίσιο PHP - PHPUnit
  3. Πλαίσια C ++ - UnitTest ++ και Google C ++
  4. .Πλαίσιο δικτύου - NUnit
  5. Πλαίσιο Python - δοκιμή

Παρανοήσεις και Αλήθειες

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

Πώς να αποδεχτείτε τη δοκιμή μονάδας;

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

  1. Γράψτε τον κωδικό δοκιμής μονάδας
  2. Εκτελέστε τον κωδικό δοκιμής μονάδας για να ελέγξετε εάν πληροί τις απαιτήσεις συστήματος
  3. Εκτελέστε τον κωδικό λογισμικού για να ελέγξετε για τυχόν ελαττώματα και εάν ο κώδικας πληροί τις απαιτήσεις συστήματος.

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

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

Η καλύτερη εξάσκηση

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

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

Άλλα σημεία που πρέπει να ληφθούν υπόψη είναι τα εξής:

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

συμπέρασμα

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

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

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

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

^