Προγραμματισμός

Δοκιμάστε την πρώτη ανάπτυξη με το FitNesse

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

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

  • Γράφτηκαν (είτε από τον πελάτη είτε από τον εργολάβο) και έλαβαν κάποιο είδος επίσημης αποδοχής
  • Οι δοκιμαστές προσπάθησαν να εργαστούν με τις απαιτήσεις και τους βρήκαν λίγο πολύ ανεπαρκείς
  • Το έργο εισήλθε σε μια φάση δοκιμής αποδοχής και ο πελάτης θυμήθηκε ξαφνικά όλα τα είδη πραγμάτων που το λογισμικό έπρεπε να κάνει επιπλέον / διαφορετικά

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

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

Εισαγάγετε το FitNesse

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

Χρησιμοποιώντας το FitNesse, η διαδικασία ανάπτυξης θα μπορούσε να έχει την εξής μορφή: Ο μηχανικός απαιτήσεων γράφει τις απαιτήσεις στο FitNesse (αντί του Word). Προσπαθεί να εμπλέξει τον πελάτη όσο το δυνατόν περισσότερο, αλλά αυτό συνήθως δεν μπορεί να επιτευχθεί σε καθημερινή βάση. Ο εξεταστής κοιτάζει επανειλημμένα το έγγραφο και θέτει δύσκολες ερωτήσεις από την πρώτη μέρα. Επειδή ο εξεταστής σκέφτεται διαφορετικά, δεν σκέφτεται: "Τι θα κάνει το λογισμικό;" αλλά "Τι μπορεί να πάει στραβά; Πώς μπορώ να το σπάσω;" Ο προγραμματιστής σκέφτεται περισσότερο σαν τον μηχανικό απαιτήσεων. θέλει να μάθει, "Τι πρέπει να κάνει το λογισμικό;"

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

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

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

Εφαρμογή πρώτης δοκιμής

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

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

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

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

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

Ξεκινήστε το FitNesse εκτελώντας το run.bat (run.sh σε Linux) σενάριο σε C: \ fitnesse. Από προεπιλογή, το FitNesse εκτελεί έναν διακομιστή Web στη θύρα 80, αλλά μπορείτε να καθορίσετε μια διαφορετική θύρα, ας πούμε 81, προσθέτοντας -π 81 στην πρώτη γραμμή στο αρχείο δέσμης. Αυτό είναι το μόνο που υπάρχει. μπορείτε πλέον να έχετε πρόσβαση στο FitNesse στο // localhost: 81.

Σε αυτό το άρθρο, χρησιμοποιώ την έκδοση Java του FitNesse στα Windows. Ωστόσο, τα παραδείγματα μπορούν να χρησιμοποιηθούν και για άλλες εκδόσεις (Python, .Net) και πλατφόρμες.

Μερικές δοκιμές

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

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

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

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

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

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

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

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

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

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

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

Σενάρια

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

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

  • Η Μαρία είναι ανύπαντρη μητέρα. Έχει δύο γιους (Bob, 2 και Peter, 15) και εργάζεται με μερική απασχόληση (20 ώρες την εβδομάδα) ως γραμματέας.
  • Η Μαρία χάνει τη δουλειά της. Αργότερα, εργάζεται 10 ώρες την εβδομάδα ως βοηθός καταστήματος και άλλες 5 ώρες ως μπέιμπι σίτερ.
  • Ο Παύλος και η Λάρα έχουν μια κόρη (Λίζα, 17) που έχει σωματική αναπηρία και έναν γιο (Φρανκ, 18 ετών) που είναι ακόμα πανεπιστήμιο.

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

Δοκιμές βάσει λέξεων-κλειδιών

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

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

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

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

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

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

Εδώ είναι ο κωδικός που εκτελείται αυτόματα από το FitNesse:

πακέτο stephanwiesner.javaworld;

εισαγωγή fit.ColumnFixture;

δημόσια τάξη ChildAllowanceFixture επεκτείνει το ColumnFixture {public void personButton () {System.out.println ("πατώντας το κουμπί του ατόμου"); } public void securityNumber (int number) {System.out.println ("εισαγωγή securityNumber" + αριθμός); } public int childAllowance () {System.out.println ("υπολογισμός επιδόματος παιδιών"); επιστροφή 190; } [...]}

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

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

Δοκιμή βάσει δεδομένων

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

$config[zx-auto] not found$config[zx-overlay] not found