Γεια σου Χαμπρ!
Το όνομά μου είναι Maxim Ponomarenko και είμαι προγραμματιστής στο Sportmaster. Έχω 10 χρόνια εμπειρία στον χώρο της πληροφορικής. Ξεκίνησε την καριέρα του στις χειροκίνητες δοκιμές και στη συνέχεια μεταπήδησε στην ανάπτυξη βάσεων δεδομένων. Τα τελευταία 4 χρόνια, συσσωρεύοντας τη γνώση που αποκτήθηκε στις δοκιμές και την ανάπτυξη, αυτοματοποιώ τις δοκιμές σε επίπεδο DBMS.
Είμαι στην ομάδα του Sportmaster για λίγο περισσότερο από ένα χρόνο και αναπτύσσω αυτοματοποιημένες δοκιμές σε ένα από τα μεγάλα έργα. Τον Απρίλιο, τα παιδιά από το Sportmaster Lab και εγώ μιλήσαμε σε ένα συνέδριο στο Κρασνοντάρ, η έκθεσή μου ονομαζόταν «Δοκιμές μονάδων σε ένα DBMS» και τώρα θέλω να τη μοιραστώ μαζί σας. Θα υπάρχει πολύ κείμενο, γι' αυτό αποφάσισα να χωρίσω την αναφορά σε δύο αναρτήσεις. Στο πρώτο, θα μιλήσουμε για τις αυτόματες δοκιμές και τις δοκιμές γενικά, και στο δεύτερο, θα σταθώ λεπτομερέστερα στο σύστημα δοκιμών μονάδων μας και στα αποτελέσματα της εφαρμογής του.
Πρώτον, μια μικρή βαρετή θεωρία. Τι είναι η αυτοματοποιημένη δοκιμή; Πρόκειται για δοκιμές που πραγματοποιούνται με χρήση λογισμικού και στη σύγχρονη πληροφορική χρησιμοποιείται όλο και περισσότερο στην ανάπτυξη λογισμικού. Αυτό οφείλεται στο γεγονός ότι οι εταιρείες αναπτύσσονται, τα πληροφοριακά τους συστήματα αυξάνονται και, κατά συνέπεια, αυξάνεται ο όγκος της λειτουργικότητας που πρέπει να δοκιμαστεί. Η διεξαγωγή χειροκίνητων δοκιμών γίνεται όλο και πιο δαπανηρή.
Δούλευα σε μια μεγάλη εταιρεία της οποίας οι κυκλοφορίες βγαίνουν κάθε δύο μήνες. Ταυτόχρονα, ένας ολόκληρος μήνας δαπανήθηκε για να ελέγξουν χειροκίνητα μια ντουζίνα δοκιμαστές τη λειτουργικότητα. Χάρη στην εφαρμογή του αυτοματισμού από μια μικρή ομάδα προγραμματιστών, μπορέσαμε να μειώσουμε τον χρόνο δοκιμής σε 2 εβδομάδες σε ενάμιση χρόνο. Όχι μόνο αυξήσαμε την ταχύτητα των δοκιμών, αλλά βελτιώσαμε και την ποιότητά τους. Τα αυτοματοποιημένα τεστ ξεκινούν τακτικά και πραγματοποιούν πάντα όλη την πορεία των ελέγχων που περιλαμβάνονται σε αυτά, δηλαδή αποκλείουμε τον ανθρώπινο παράγοντα.
Το σύγχρονο IT χαρακτηρίζεται από το γεγονός ότι ένας προγραμματιστής μπορεί να χρειαστεί όχι μόνο να γράψει τον κωδικό προϊόντος, αλλά και να γράψει δοκιμές μονάδας που ελέγχουν αυτόν τον κωδικό.
Τι γίνεται όμως αν το σύστημά σας βασίζεται κυρίως στη λογική του διακομιστή; Δεν υπάρχει καθολική λύση ή βέλτιστες πρακτικές στην αγορά. Κατά κανόνα, οι εταιρείες λύνουν αυτό το πρόβλημα δημιουργώντας το δικό τους αυτογραφικό σύστημα δοκιμών. Αυτό είναι το δικό μας αυτοματοποιημένο σύστημα δοκιμών που δημιουργήθηκε για το έργο μας και θα μιλήσω γι' αυτό στην έκθεσή μου.
Δοκιμή πίστης
Αρχικά, ας μιλήσουμε για το έργο όπου αναπτύξαμε ένα αυτοματοποιημένο σύστημα δοκιμών. Το έργο μας είναι το σύστημα πιστότητας Sportmaster (παρεμπιπτόντως, έχουμε ήδη γράψει γι 'αυτό ).
Εάν η εταιρεία σας είναι αρκετά μεγάλη, τότε το σύστημα αφοσίωσης σας θα έχει τρεις τυπικές ιδιότητες:
- Το σύστημά σας θα είναι πολύ φορτωμένο
- Το σύστημά σας θα περιέχει πολύπλοκες υπολογιστικές διαδικασίες
- Το σύστημά σας θα βελτιωθεί ενεργά.
Πάμε με τη σειρά... Συνολικά, αν λάβουμε υπόψη όλες τις μάρκες Sportmaster, τότε έχουμε περισσότερα από 1000 καταστήματα σε Ρωσία, Ουκρανία, Κίνα, Καζακστάν και Λευκορωσία. Σε αυτά τα καταστήματα γίνονται καθημερινά περίπου 300 αγορές. Δηλαδή κάθε δευτερόλεπτο μπαίνουν στο σύστημά μας 000-3 έλεγχοι. Φυσικά, το σύστημα αφοσίωσης μας είναι πολύ φορτωμένο. Και δεδομένου ότι χρησιμοποιείται ενεργά, πρέπει να παρέχουμε τα υψηλότερα πρότυπα της ποιότητάς του, γιατί οποιοδήποτε σφάλμα στο λογισμικό σημαίνει μεγάλες χρηματικές απώλειες, ζημίες φήμης και άλλες.
Ταυτόχρονα, το Sportmaster πραγματοποιεί περισσότερες από εκατό διαφορετικές προσφορές. Υπάρχουν ποικίλες προσφορές: υπάρχουν προσφορές προϊόντων, υπάρχουν αυτές που είναι αφιερωμένες στην ημέρα της εβδομάδας, υπάρχουν αυτές που συνδέονται με ένα συγκεκριμένο κατάστημα, υπάρχουν προσφορές για το ποσό της απόδειξης, υπάρχουν για τον αριθμό των προϊόντων. Γενικά, όχι άσχημα. Οι πελάτες έχουν μπόνους και κωδικούς προσφοράς που χρησιμοποιούνται κατά την πραγματοποίηση αγορών. Όλα αυτά οδηγούν στο γεγονός ότι ο υπολογισμός οποιασδήποτε παραγγελίας είναι μια πολύ μη τετριμμένη εργασία.
Ο αλγόριθμος που υλοποιεί την επεξεργασία παραγγελιών είναι πραγματικά τρομερός και περίπλοκος. Και οποιεσδήποτε αλλαγές σε αυτόν τον αλγόριθμο είναι αρκετά επικίνδυνες. Φαινόταν ότι οι πιο φαινομενικά ασήμαντες αλλαγές θα μπορούσαν να οδηγήσουν σε αρκετά απρόβλεπτα αποτελέσματα. Αλλά είναι ακριβώς τέτοιες πολύπλοκες υπολογιστικές διαδικασίες, ειδικά αυτές που εφαρμόζουν κρίσιμη λειτουργικότητα, που είναι οι καλύτεροι υποψήφιοι για αυτοματισμό. Ο έλεγχος δεκάδων παρόμοιων περιπτώσεων με το χέρι είναι πολύ χρονοβόρος. Και δεδομένου ότι το σημείο εισόδου στη διαδικασία είναι αμετάβλητο, αφού το περιγράψατε μία φορά, μπορείτε να δημιουργήσετε γρήγορα αυτόματες δοκιμές και να είστε σίγουροι ότι η λειτουργικότητα θα λειτουργήσει.
Δεδομένου ότι το σύστημά μας χρησιμοποιείται ενεργά, η επιχείρηση θα θέλει κάτι νέο από εσάς, θα ζήσει με την εποχή και θα είναι προσανατολισμένη στον πελάτη. Στο σύστημα αφοσίωσης, οι εκδόσεις κυκλοφορούν κάθε δύο μήνες. Αυτό σημαίνει ότι κάθε δύο μήνες πρέπει να πραγματοποιούμε μια πλήρη παλινδρόμηση ολόκληρου του συστήματος. Ταυτόχρονα, φυσικά, όπως σε κάθε σύγχρονο IT, η ανάπτυξη δεν περνά αμέσως από τον προγραμματιστή στην παραγωγή. Προέρχεται από το κύκλωμα του προγραμματιστή, μετά περνά διαδοχικά από τον πάγκο δοκιμών, απελευθερώνεται, αποδέχεται και μόνο τότε καταλήγει στην παραγωγή. Τουλάχιστον, στα κυκλώματα δοκιμής και απελευθέρωσης, πρέπει να πραγματοποιήσουμε μια πλήρη παλινδρόμηση ολόκληρου του συστήματος.
Οι περιγραφόμενες ιδιότητες είναι στάνταρ για σχεδόν οποιοδήποτε σύστημα επιβράβευσης. Ας μιλήσουμε για τα χαρακτηριστικά του έργου μας.
Τεχνολογικά, το 90% της λογικής του συστήματος αφοσίωσης μας βασίζεται σε διακομιστές και υλοποιείται στην Oracle. Υπάρχει ένας πελάτης που εκτίθεται στους Δελφούς, ο οποίος εκτελεί τη λειτουργία ενός αυτοματοποιημένου διαχειριστή χώρου εργασίας. Υπάρχουν εκτεθειμένες υπηρεσίες web για εξωτερικές εφαρμογές (για παράδειγμα έναν ιστότοπο). Επομένως, είναι πολύ λογικό ότι εάν αναπτύξουμε ένα αυτοματοποιημένο σύστημα δοκιμών, θα το κάνουμε στην Oracle.
Το σύστημα πιστότητας στο Sportmaster υπάρχει για περισσότερα από 7 χρόνια και δημιουργήθηκε από μεμονωμένους προγραμματιστές... Ο μέσος αριθμός προγραμματιστών στο έργο μας αυτά τα 7 χρόνια ήταν 3-4 άτομα. Αλλά κατά τη διάρκεια του περασμένου έτους, η ομάδα μας έχει αυξηθεί σημαντικά, και τώρα υπάρχουν 10 άτομα που εργάζονται στο έργο. Δηλαδή, άνθρωποι έρχονται στο έργο που δεν είναι εξοικειωμένοι με τυπικές εργασίες, διαδικασίες και αρχιτεκτονική. Και υπάρχει αυξημένος κίνδυνος να χάσουμε λάθη.
Το έργο χαρακτηρίζεται από την απουσία ειδικών ελεγκτών ως μονάδων προσωπικού. Υπάρχει, φυσικά, δοκιμές, αλλά οι δοκιμές διενεργούνται από αναλυτές, εκτός από τις άλλες κύριες αρμοδιότητές τους: επικοινωνία με επιχειρηματικούς πελάτες, χρήστες, ανάπτυξη απαιτήσεων συστήματος κ.λπ. κλπ... Παρά το γεγονός ότι οι δοκιμές πραγματοποιούνται πολύ υψηλής ποιότητας (αυτό είναι ιδιαίτερα σκόπιμο να το αναφέρουμε, καθώς ορισμένοι από τους αναλυτές μπορεί να τραβήξουν το μάτι αυτής της έκθεσης), η αποτελεσματικότητα της εξειδίκευσης και της συγκέντρωσης σε ένα πράγμα δεν έχει ακυρωθεί .
Λαμβάνοντας υπόψη όλα τα παραπάνω, για τη βελτίωση της ποιότητας του παραδοθέντος προϊόντος και τη μείωση του χρόνου ανάπτυξης, η ιδέα της αυτοματοποίησης των δοκιμών σε ένα έργο φαίνεται πολύ λογική. Και σε διαφορετικά στάδια της ύπαρξης του συστήματος αφοσίωσης, μεμονωμένοι προγραμματιστές κατέβαλαν προσπάθειες να καλύψουν τον κώδικά τους με δοκιμές μονάδων. Συνολικά ήταν μια αρκετά ασύνδετη διαδικασία, με τον καθένα να χρησιμοποιεί τη δική του αρχιτεκτονική και μεθόδους. Τα τελικά αποτελέσματα ήταν κοινά για τις δοκιμές μονάδων: οι δοκιμές αναπτύχθηκαν, χρησιμοποιήθηκαν για κάποιο χρονικό διάστημα, αποθηκεύτηκαν σε μια έκδοση αποθήκευσης αρχείων, αλλά κάποια στιγμή σταμάτησαν να εκτελούνται και ξεχάστηκαν. Πρώτα απ 'όλα, αυτό οφειλόταν στο γεγονός ότι οι δοκιμές συνδέονταν περισσότερο με έναν συγκεκριμένο ερμηνευτή και όχι με το έργο.
Το utPLSQL έρχεται στη διάσωση
Ξέρετε τίποτα για τον Stephen Feuerstein;
Αυτός είναι ένας έξυπνος τύπος που αφιέρωσε μεγάλο μέρος της καριέρας του στη συνεργασία με την Oracle και την PL/SQL, και έχει γράψει αρκετά μεγάλο αριθμό έργων για αυτό το θέμα. Ένα από τα διάσημα βιβλία του ονομάζεται: «Oracle PL/SQL. Για επαγγελματίες». Ήταν ο Stephen που ανέπτυξε τη λύση utPLSQL ή, όπως σημαίνει, Unit Testing Framework για το Oracle PL/SQL. Η λύση utPLSQL δημιουργήθηκε το 2016, αλλά συνεχίζει να εργάζεται ενεργά και κυκλοφορούν νέες εκδόσεις. Κατά τη στιγμή της αναφοράς, η τελευταία έκδοση χρονολογείται από τις 24 Μαρτίου 2019.
Τι είναι αυτό. Αυτό είναι ένα ξεχωριστό έργο ανοιχτού κώδικα. Ζυγίζει μερικά megabyte, συμπεριλαμβανομένων παραδειγμάτων και τεκμηρίωσης. Φυσικά, είναι ένα ξεχωριστό σχήμα στη βάση δεδομένων ORACLE με ένα σύνολο πακέτων και πινάκων για την οργάνωση δοκιμών μονάδων. Η εγκατάσταση διαρκεί λίγα δευτερόλεπτα. Ένα ξεχωριστό χαρακτηριστικό του utPLSQL είναι η ευκολία χρήσης του.
Σε παγκόσμιο επίπεδο, το utPLSQL είναι ένας μηχανισμός για την εκτέλεση δοκιμών μονάδων, όπου μια δοκιμή μονάδας νοείται ως συνήθεις διαδικασίες παρτίδας της Oracle, η οργάνωση των οποίων ακολουθεί ορισμένους κανόνες. Εκτός από την εκκίνηση, το utPLSQL αποθηκεύει ένα αρχείο καταγραφής όλων των δοκιμαστικών εκτελέσεων και διαθέτει επίσης ένα εσωτερικό σύστημα αναφοράς.
Ας δούμε ένα παράδειγμα για το πώς μοιάζει ο κώδικας δοκιμής μονάδας, που υλοποιείται χρησιμοποιώντας αυτήν την τεχνική.
Έτσι, η οθόνη δείχνει τον κωδικό για μια τυπική προδιαγραφή πακέτου με δοκιμές μονάδας. Ποιες είναι οι υποχρεωτικές απαιτήσεις; Το πακέτο πρέπει να έχει το πρόθεμα "utp_". Όλες οι διαδικασίες με τεστ πρέπει να έχουν ακριβώς το ίδιο πρόθεμα. Το πακέτο πρέπει να περιέχει δύο τυπικές διαδικασίες: "utp_setup" και "utp_teardown". Η πρώτη διαδικασία καλείται με επανεκκίνηση κάθε δοκιμής μονάδας, η δεύτερη - μετά την εκκίνηση.
Το "utp_setup", κατά κανόνα, προετοιμάζει το σύστημά μας να εκτελέσει μια δοκιμή μονάδας, για παράδειγμα, να δημιουργήσει δεδομένα δοκιμής. "utp_teardown" - αντίθετα, όλα επιστρέφουν στις αρχικές ρυθμίσεις και επαναφέρουν τα αποτελέσματα εκκίνησης.
Ακολουθεί ένα παράδειγμα της απλούστερης δοκιμής μονάδας που ελέγχει την κανονικοποίηση του εισαγόμενου αριθμού τηλεφώνου πελάτη στην τυπική φόρμα για το σύστημα αφοσίωσης. Δεν υπάρχουν υποχρεωτικά πρότυπα για τη σύνταξη διαδικασιών με δοκιμές μονάδας. Κατά κανόνα, γίνεται κλήση σε μια μέθοδο του υπό δοκιμή συστήματος και το αποτέλεσμα που επιστρέφεται με αυτήν τη μέθοδο συγκρίνεται με το αντίστοιχο. Είναι σημαντικό η σύγκριση του αποτελέσματος αναφοράς και του ληφθέντος αποτελέσματος να πραγματοποιείται μέσω τυπικών μεθόδων utPLSQL.
Μια δοκιμή μονάδας μπορεί να έχει οποιοδήποτε αριθμό ελέγχων. Όπως φαίνεται από το παράδειγμα, πραγματοποιούμε τέσσερις διαδοχικές κλήσεις στη δοκιμασμένη μέθοδο για να ομαλοποιήσουμε τον αριθμό τηλεφώνου και να αξιολογήσουμε το αποτέλεσμα μετά από κάθε κλήση. Κατά την ανάπτυξη μιας δοκιμής μονάδας, πρέπει να λάβετε υπόψη ότι υπάρχουν έλεγχοι που δεν επηρεάζουν το σύστημα με κανέναν τρόπο και μετά από κάποιους θα πρέπει να επιστρέψετε στην αρχική κατάσταση του συστήματος.
Για παράδειγμα, στο παρουσιαζόμενο τεστ μονάδας απλώς μορφοποιούμε τον αριθμό τηλεφώνου εισαγωγής, κάτι που δεν επηρεάζει με κανέναν τρόπο το σύστημα πιστότητας.
Και αν γράψουμε δοκιμές μονάδας χρησιμοποιώντας τη μέθοδο δημιουργίας νέου πελάτη, τότε μετά από κάθε δοκιμή θα δημιουργείται ένας νέος πελάτης στο σύστημα, ο οποίος μπορεί να επηρεάσει την επακόλουθη εκκίνηση της δοκιμής.
Έτσι εκτελούνται οι δοκιμές μονάδας. Υπάρχουν δύο πιθανές επιλογές εκκίνησης: εκτέλεση όλων των δοκιμών μονάδας από ένα συγκεκριμένο πακέτο ή εκτέλεση συγκεκριμένης δοκιμής μονάδας σε ένα συγκεκριμένο πακέτο.
Έτσι μοιάζει ένα παράδειγμα εσωτερικού συστήματος αναφοράς. Με βάση τα αποτελέσματα της δοκιμής μονάδας, το utPLSQL δημιουργεί μια μικρή αναφορά. Σε αυτό βλέπουμε το αποτέλεσμα για κάθε συγκεκριμένο έλεγχο και το συνολικό αποτέλεσμα της δοκιμής μονάδας.
6 κανόνες αυτοδοκιμών
Πριν ξεκινήσουμε τη δημιουργία ενός νέου συστήματος για αυτοματοποιημένες δοκιμές του συστήματος πιστότητας, μαζί με τη διαχείριση, καθορίσαμε τις αρχές με τις οποίες θα πρέπει να συμμορφώνονται οι μελλοντικές αυτοματοποιημένες δοκιμές μας.
- Οι αυτόματες δοκιμές πρέπει να είναι αποτελεσματικές και χρήσιμες. Έχουμε υπέροχους προγραμματιστές, που πρέπει οπωσδήποτε να αναφερθούν, γιατί κάποιοι από αυτούς πιθανότατα θα δουν αυτήν την αναφορά και γράφουν υπέροχο κώδικα. Αλλά ακόμη και ο υπέροχος κώδικας τους δεν είναι τέλειος και έχει, έχει και θα συνεχίσει να περιέχει σφάλματα. Απαιτούνται αυτόματες δοκιμές για την εύρεση αυτών των σφαλμάτων. Αν δεν ισχύει αυτό, τότε είτε γράφουμε κακές αυτοδοκιμές, είτε έχουμε φτάσει σε μια νεκρή περιοχή που, καταρχήν, δεν αναπτύσσεται. Και στις δύο περιπτώσεις, κάνουμε κάτι λάθος και η προσέγγισή μας απλά δεν έχει νόημα.
- Θα πρέπει να χρησιμοποιούνται αυτόματες δοκιμές. Δεν έχει νόημα να ξοδεύετε πολύ χρόνο και προσπάθεια για να γράψετε ένα προϊόν λογισμικού, να το τοποθετήσετε σε ένα αποθετήριο και να το ξεχάσετε. Οι δοκιμές πρέπει να εκτελούνται και να εκτελούνται όσο πιο τακτικά γίνεται.
- Οι αυτόματες δοκιμές θα πρέπει να λειτουργούν σταθερά. Ανεξάρτητα από την ώρα της ημέρας, τη βάση εκκίνησης και άλλες ρυθμίσεις συστήματος, οι δοκιμαστικές εκτελέσεις θα πρέπει να οδηγούν στο ίδιο αποτέλεσμα. Κατά κανόνα, αυτό διασφαλίζεται από το γεγονός ότι οι αυτόματες δοκιμές λειτουργούν με ειδικά δεδομένα δοκιμής με σταθερές ρυθμίσεις συστήματος.
- Οι αυτόματες δοκιμές θα πρέπει να λειτουργούν με ταχύτητα αποδεκτή για το έργο σας. Αυτός ο χρόνος καθορίζεται ξεχωριστά για κάθε σύστημα. Μερικοί άνθρωποι έχουν την πολυτέλεια να εργάζονται όλη μέρα, ενώ άλλοι θεωρούν ότι είναι κρίσιμο να το κάνουν μέσα σε δευτερόλεπτα. Θα σας πω λίγο αργότερα ποια πρότυπα ταχύτητας πετύχαμε στο έργο μας.
- Η ανάπτυξη Autotest θα πρέπει να είναι ευέλικτη. Δεν είναι σκόπιμο να αρνηθείτε να δοκιμάσετε οποιαδήποτε λειτουργικότητα απλώς και μόνο επειδή δεν το έχουμε κάνει πριν ή για κάποιο άλλο λόγο. Το utPLSQL δεν επιβάλλει περιορισμούς στην ανάπτυξη και η Oracle, καταρχήν, σας επιτρέπει να εφαρμόσετε μια ποικιλία πραγμάτων. Τα περισσότερα προβλήματα έχουν λύση, είναι απλώς θέμα χρόνου και προσπάθειας.
- Δυνατότητα ανάπτυξης. Έχουμε πολλά περίπτερα όπου πρέπει να κάνουμε δοκιμές. Σε κάθε βάση, μια ένδειξη δεδομένων μπορεί να ενημερωθεί ανά πάσα στιγμή. Είναι απαραίτητο να πραγματοποιήσετε ένα έργο με αυτόματες δοκιμές με τέτοιο τρόπο ώστε να μπορείτε να πραγματοποιήσετε ανώδυνα την πλήρη ή μερική εγκατάστασή του.
Και στο δεύτερο post σε λίγες μέρες θα σας πω τι κάναμε και τι αποτελέσματα πετύχαμε.
Πηγή: www.habr.com