Μενού

Πλήρης οδηγός δοκιμής επαλήθευσης έκδοσης (BVT Testing)

build verification testing complete guide

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

Τι είναι ο έλεγχος επαλήθευσης έκδοσης (BVT);

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

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

Δοκιμή επαλήθευσης έκδοσης (Δοκιμή BVT)

Ονομάζεται επίσης BVT Δοκιμή καπνού ή Δημιουργία δοκιμής αποδοχής (BAT)

Το New Build ελέγχεται κυρίως για δύο πράγματα:

qa διευθύνσεις ερωτήσεων συνέντευξης απαντήσεις pdf
  • Κατασκευή επικύρωσης
  • Κατασκευή αποδοχής

Μερικά βασικά BVT:

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

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

Ποια είναι η κύρια εργασία στο Build Release; Προφανώς αρχειοθετήστε το «check-in», δηλαδή να συμπεριλάβετε όλα τα νέα και τροποποιημένα αρχεία έργου που σχετίζονται με τις αντίστοιχες εκδόσεις. Το BVT παρουσιάστηκε κυρίως για να ελέγξει την αρχική κατάσταση κατασκευής, δηλαδή για να ελέγξει εάν - όλα τα νέα και τροποποιημένα αρχεία περιλαμβάνονται στην κυκλοφορία, όλες οι μορφές αρχείων είναι σωστές, κάθε έκδοση αρχείου και γλώσσα, σημαίες που σχετίζονται με κάθε αρχείο.

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

Ποιες δοκιμαστικές περιπτώσεις πρέπει να περιλαμβάνονται στο BVT;

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

Ακολουθούν μερικές απλές συμβουλές για συμπερίληψη Θήκες δοκιμής στη σουίτα αυτοματισμού BVT:

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

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

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

Για παράδειγμα, Δοκιμαστικές περιπτώσεις που θα συμπεριληφθούν στο BVT για εφαρμογή επεξεργασίας κειμένου (Μερικά μόνο δείγματα δοκιμών):

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

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

Τα κοστούμια αυτοματισμού BVT πρέπει να συντηρούνται και να τροποποιούνται κατά καιρούς. Π.χ. Συμπεριλάβετε δοκιμαστικές περιπτώσεις στο BVT όταν υπάρχουν διαθέσιμες νέες σταθερές ενότητες έργου.

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

Τι συμβαίνει όταν εκτελείται το BVT Suite;

Ας πούμε ότι η δοκιμαστική σουίτα αυτοματοποίησης κατασκευής εκτελέστηκε μετά από οποιαδήποτε νέα έκδοση.
# 1) Το αποτέλεσμα της εκτέλεσης BVT αποστέλλεται σε όλα τα αναγνωριστικά email που σχετίζονται με αυτό το έργο.
#δύο) Ο κάτοχος του BVT (άτομο που εκτελεί και συντηρεί τη σουίτα BVT) ελέγχει το αποτέλεσμα του BVT.
# 3) Εάν το BVT αποτύχει, τότε ο κάτοχος του BVT θα διαγνώσει την αιτία της αποτυχίας.
# 4) Εάν η αιτία αποτυχίας είναι το ελάττωμα στο build, όλες οι σχετικές πληροφορίες με αρχεία καταγραφής αποστολής αποστέλλονται στους αντίστοιχους προγραμματιστές.
# 5) Ο προγραμματιστής στις αρχικές διαγνωστικές απαντήσεις του στην ομάδα σχετικά με την αιτία αποτυχίας. Αν αυτό είναι πραγματικά ένα σφάλμα; Και αν είναι ένα σφάλμα τότε ποιο θα είναι το σενάριό του για τη διόρθωση σφαλμάτων.
# 6) Στην επιδιόρθωση σφαλμάτων για άλλη μια φορά εκτελείται η δοκιμαστική σουίτα BVT και εάν το build περάσει το BVT, το build περνά στην ομάδα δοκιμών για περισσότερες λεπτομέρειες λειτουργικότητας, απόδοσης και άλλων δοκιμών.

Αυτή η διαδικασία επαναλαμβάνεται για κάθε νέα έκδοση.

Γιατί απέτυχε το BVT ή το Build;

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

Συμβουλές για την επιτυχία του BVT:

# 1) Αφιερώστε πολύ χρόνο γράφοντας σενάρια δοκιμαστικών περιπτώσεων BVT.
#δύο) Συνδεθείτε όσο το δυνατόν πιο λεπτομερείς πληροφορίες για τη διάγνωση της επιτυχίας BVT ή του αποτελέσματος αποτυχίας. Αυτό θα βοηθήσει την ομάδα προγραμματιστών να εντοπίσει σφάλματα και να γνωρίσει γρήγορα την αιτία αποτυχίας.
# 3) Επιλέξτε σταθερές δοκιμαστικές περιπτώσεις που θα συμπεριληφθούν στο BVT. Για νέες δυνατότητες, εάν η νέα κρίσιμη περίπτωση δοκιμής περνά με συνέπεια σε διαφορετική διαμόρφωση, προωθήστε αυτήν τη δοκιμαστική θήκη στη σουίτα BVT. Αυτό θα μειώσει την πιθανότητα συχνής αποτυχίας κατασκευής λόγω νέων ασταθών μονάδων και δοκιμαστικών περιπτώσεων.
# 4) Αυτοματοποιήστε τη διαδικασία BVT όσο το δυνατόν περισσότερο. Από τη διαδικασία έκδοσης build έως το αποτέλεσμα BVT - αυτοματοποιήστε τα πάντα.
# 5) Έχετε κάποιες κυρώσεις για το σπάσιμο του build ;-) Μερικές σοκολάτες ή ομαδικό πάρτι καφέ από έναν προγραμματιστή που σπάει το build θα κάνουν.

συμπέρασμα

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

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

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

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

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

^