Δοκιμές μονάδων σε ένα DBMS - πώς το κάνουμε στο Sportmaster, μέρος δεύτερο

Πρώτο μέρος - εδώ.

Δοκιμές μονάδων σε ένα DBMS - πώς το κάνουμε στο Sportmaster, μέρος δεύτερο

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

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

  1. Επαναφορά παλαιών δοκιμών μονάδας. Ανάκτηση σημαίνει προσαρμογή των δοκιμών στην υπάρχουσα κατάσταση του συστήματος πιστότητας και προσαρμογή των δοκιμών στα πρότυπα utPLSQL.
  2. Επίλυση του προβλήματος με κατανόηση, και ποιες ακριβώς, ποιες μεθόδους και διαδικασίες, καλύψαμε με αυτόματες δοκιμές. Πρέπει είτε να κρατήσετε αυτές τις πληροφορίες στο μυαλό σας, είτε να βγάλετε συμπεράσματα με βάση απευθείας τον κώδικα των αυτόματων δοκιμών. Ως εκ τούτου, αποφασίσαμε να δημιουργήσουμε έναν κατάλογο. Εκχωρήσαμε έναν μοναδικό μνημονικό κώδικα σε κάθε αυτόματη δοκιμή, δημιουργήσαμε μια περιγραφή και διορθώσαμε τις ρυθμίσεις (για παράδειγμα, υπό ποιες συνθήκες θα έπρεπε να εκτελεστεί ή τι θα συμβεί εάν η δοκιμαστική εκτέλεση αποτύχει). Ουσιαστικά, συμπληρώσαμε τα μεταδεδομένα σχετικά με τις αυτόματες δοκιμές και τοποθετήσαμε αυτά τα μεταδεδομένα στους τυπικούς πίνακες του σχήματος utPLSQL.
  3. Ορισμός στρατηγικής επέκτασης, δηλ. επιλογή λειτουργικότητας που υπόκειται σε επαλήθευση από αυτόματες δοκιμές. Αποφασίσαμε να δώσουμε προσοχή σε τρία πράγματα: νέες βελτιώσεις στο σύστημα, περιστατικά από την παραγωγή και βασικές διαδικασίες του συστήματος. Έτσι, αναπτύσσουμε παράλληλα με την απελευθέρωση, διασφαλίζοντας την υψηλότερη ποιότητά του, διευρύνοντας ταυτόχρονα το εύρος της παλινδρόμησης και διασφαλίζοντας την αξιοπιστία του συστήματος σε κρίσιμα σημεία. Το πρώτο τέτοιο σημείο συμφόρησης ήταν η διαδικασία διανομής εκπτώσεων και μπόνους με επιταγή.
  4. Φυσικά, αρχίσαμε να αναπτύσσουμε νέα αυτόματα τεστ. Μία από τις πρώτες εργασίες έκδοσης ήταν η αξιολόγηση της απόδοσης προκαθορισμένων δειγμάτων του συστήματος πιστότητας. Το έργο μας έχει ένα μπλοκ από άκαμπτα καθορισμένα ερωτήματα sql που επιλέγουν πελάτες σύμφωνα με τις συνθήκες. Για παράδειγμα, λάβετε μια λίστα με όλους τους πελάτες των οποίων η τελευταία αγορά ήταν σε μια συγκεκριμένη πόλη ή μια λίστα πελατών των οποίων το μέσο ποσό αγοράς είναι πάνω από μια συγκεκριμένη τιμή. Έχοντας γραπτές αυτόματες δοκιμές, ελέγξαμε προκαθορισμένα δείγματα, σταθεροποιήσαμε παραμέτρους απόδοσης συγκριτικής αξιολόγησης και επιπλέον λάβαμε δοκιμές φορτίου.
  5. Η εργασία με αυτόματες δοκιμές θα πρέπει να είναι βολική. Οι δύο πιο συνηθισμένες ενέργειες είναι η εκτέλεση αυτόματων δοκιμών και η δημιουργία δεδομένων δοκιμής. Έτσι εμφανίστηκαν δύο βοηθητικές μονάδες στο σύστημά μας: η μονάδα εκκίνησης και η μονάδα παραγωγής δεδομένων.

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

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

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

    Αλλά έπρεπε να εργαστούμε για τη βελτιστοποίηση της ταχύτητας της εργασίας. Το σύστημα πιστότητας παραγωγής ενημερώνεται τη νύχτα. Ως μέρος μιας από τις κυκλοφορίες, έπρεπε να κάνουμε επειγόντως αλλαγές τη νύχτα. Μια μισή ώρα αναμονής για τα αποτελέσματα των αυτόματων δοκιμών στις τρεις το πρωί δεν έκανε τον υπεύθυνο για την απελευθέρωση χαρούμενος (θερμοί χαιρετισμοί στον Alexei Vasyukov!), Και το επόμενο πρωί ειπώθηκαν πολλά θερμά λόγια προς το σύστημά μας. Ως αποτέλεσμα, όμως, ορίστηκε ένα πρότυπο 5 λεπτών για την εργασία.

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

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

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

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

Δοκιμές μονάδων σε ένα DBMS - πώς το κάνουμε στο Sportmaster, μέρος δεύτερο

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

  1. Φυσικά, πρώτα από όλα, είμαστε πεπεισμένοι ότι ξεκινήσαμε να αναπτύσσουμε καλύτερο λογισμικό. Οι αυτόματες δοκιμές εκτελούνται καθημερινά και βρίσκουν δεκάδες σφάλματα σε κάθε κυκλοφορία. Επιπλέον, ορισμένα από αυτά τα σφάλματα σχετίζονται μόνο έμμεσα με τη λειτουργικότητα που θέλαμε πραγματικά να αλλάξουμε. Υπάρχουν έντονες αμφιβολίες ότι αυτά τα σφάλματα εντοπίστηκαν με μη αυτόματο έλεγχο.
  2. Η ομάδα απέκτησε σιγουριά ότι η συγκεκριμένη λειτουργικότητα λειτουργεί σωστά... Πρώτα απ 'όλα, αυτό αφορά τις κρίσιμες διαδικασίες μας. Για παράδειγμα, τους τελευταίους έξι μήνες, δεν είχαμε προβλήματα με τη διανομή εκπτώσεων και μπόνους με επιταγή, παρά τις αλλαγές που έγιναν σε κάθε κυκλοφορία, αν και σε προηγούμενες περιόδους εμφανίστηκαν σφάλματα με κάποια συχνότητα
  3. Καταφέραμε να μειώσουμε τον αριθμό των επαναλήψεων δοκιμών. Λόγω του γεγονότος ότι οι αυτόματες δοκιμές έχουν γραφτεί για νέες λειτουργίες, οι αναλυτές και οι ελεγκτές μερικής απασχόλησης λαμβάνουν έναν κωδικό υψηλότερης ποιότητας, επειδή έχει ήδη επαληθευτεί.
  4. Μέρος των εξελίξεων των αυτοματοποιημένων δοκιμών χρησιμοποιείται από προγραμματιστές. Για παράδειγμα, τα δεδομένα δοκιμής σε κοντέινερ δημιουργούνται χρησιμοποιώντας τη μονάδα δημιουργίας αντικειμένων.
  5. Είναι σημαντικό ότι έχουμε αναπτύξει μια «αποδοχή» του αυτοματοποιημένου συστήματος δοκιμών από τους προγραμματιστές. Υπάρχει κατανόηση ότι αυτό είναι σημαντικό και χρήσιμο. Και από τη δική μου εμπειρία, μπορώ να πω ότι αυτό απέχει πολύ από την περίπτωση. Οι αυτόματες δοκιμές πρέπει να γράφονται, πρέπει να διατηρούνται και να αναπτύσσονται, να αναλύονται τα αποτελέσματα και συχνά αυτό το κόστος χρόνου απλά δεν αξίζει τον κόπο. Είναι πολύ πιο εύκολο να πας στην παραγωγή και να αντιμετωπίσεις προβλήματα εκεί. Στη χώρα μας οι προγραμματιστές κάνουν ουρά και ζητούν να καλύψουν τη λειτουργικότητά τους με autotests.

Ποιο είναι το επόμενο

Δοκιμές μονάδων σε ένα DBMS - πώς το κάνουμε στο Sportmaster, μέρος δεύτερο

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

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

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

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

  1. Τώρα οι αυτόματες δοκιμές διαχειρίζονται σε επίπεδο DBMS, π.χ. απαιτείται γνώση PL/SQL για επιτυχημένη εργασία. Εάν είναι απαραίτητο, η διαχείριση του συστήματος (για παράδειγμα, εκκίνηση ή δημιουργία μεταδεδομένων) μπορεί να αφαιρεθεί από κάποιο είδος πίνακα διαχείρισης χρησιμοποιώντας το Jenkins ή κάτι παρόμοιο.
  2. Όλοι αγαπούν τους ποσοτικούς και ποιοτικούς δείκτες. Για την αυτόματη δοκιμή, ένας τέτοιος καθολικός δείκτης είναι η κάλυψη κώδικα ή η μέτρηση κάλυψης κώδικα. Χρησιμοποιώντας αυτόν τον δείκτη, μπορούμε να προσδιορίσουμε ποιο ποσοστό του κώδικα του υπό δοκιμή συστήματος μας καλύπτεται από αυτόματες δοκιμές. Ξεκινώντας από την έκδοση 12.2, η Oracle παρέχει τη δυνατότητα υπολογισμού αυτής της μέτρησης και προτείνει τη χρήση του τυπικού πακέτου DBMS_PLSQL_CODE_COVERAGE.

    Το σύστημα αυτόματου ελέγχου μας είναι λίγο περισσότερο από ένα έτος και ίσως είναι καιρός να αξιολογήσουμε την κάλυψη. Στο τελευταίο μου έργο (ένα έργο όχι του Sportmaster), αυτό συνέβη. Ένα χρόνο μετά την εργασία σε αυτόματες δοκιμές, η διοίκηση έθεσε το καθήκον να αξιολογήσει το ποσοστό του κώδικα που καλύψαμε. Με κάλυψη άνω του 1%, η διοίκηση θα ήταν ευχαριστημένη. Εμείς, οι προγραμματιστές, περιμέναμε ένα αποτέλεσμα περίπου 10%. Μπαλώσαμε την κάλυψη κωδικού, τη μετρήσαμε, πήραμε 20%. Για να το γιορτάσουμε, πήγαμε για το βραβείο, αλλά το πώς το καταφέραμε και πού πήγαμε αργότερα είναι μια εντελώς διαφορετική ιστορία.

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

Ευρήματα

Ας ανακεφαλαιώσουμε. Στο έργο του συστήματος πιστότητας στο Sportmaster, καταφέραμε να εφαρμόσουμε ένα αυτοματοποιημένο σύστημα δοκιμών. Η βάση του είναι η λύση utPLSQL από τον Stephen Feuerstein. Γύρω από το utPLSQL βρίσκεται ο κώδικας για αυτόματες δοκιμές και βοηθητικές αυτογραφικές ενότητες: εκκινητής, μονάδα παραγωγής δεδομένων και άλλα. Οι αυτόματες δοκιμές εκτελούνται καθημερινά και, το πιο σημαντικό, λειτουργούν και ωφελούνται. Είμαστε πεπεισμένοι ότι έχουμε αρχίσει να κυκλοφορούμε λογισμικό υψηλότερης ποιότητας. Ταυτόχρονα, η λύση που προκύπτει είναι καθολική και μπορεί να εφαρμοστεί ελεύθερα σε οποιοδήποτε έργο όπου είναι απαραίτητο να οργανωθεί αυτοματοποιημένη δοκιμή στο Oracle DBMS.

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

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

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

Να γράψουμε περισσότερα για αυτό;

  • Ναι φυσικά

  • Οχι ευχαριστώ

Ψήφισαν 12 χρήστες. 4 χρήστες απείχαν.

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο