Μενού

Πότε να επιλέξετε τον αυτοματισμό;

when opt automation testing

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

Πρέπει να εξετάσουμε τη δοκιμή αυτοματισμού για ένα έργο; Πότε πρέπει να πάμε για αυτοματοποίηση δοκιμών;

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

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

Πότε να επιλέξετε τη δοκιμή αυτοματοποίησης

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

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

Τι θα μάθετε:

Δοκιμή λογισμικού και οφέλη κόστους

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

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

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

Δοκιμή κύκλου ζωής

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

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

Μη αυτόματη διαδικασία δοκιμής

Ευφυΐα πίσω από δοκιμές λογισμικού

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

Νοημοσύνη δοκιμών λογισμικού

Παρακάτω δίνονται τα κριτήρια για την είσοδο και έξοδο δοκιμών λογισμικού:

Κριτήρια εισόδου

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

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

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

(Σημείωση: Κάντε κλικ σε οποιαδήποτε εικόνα για μεγέθυνση)

Αυτοματοποίηση κριτηρίων εισόδου

Κριτήρια εξόδου

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

Έξοδος αυτοματισμού κριτηρίων

Τα κύρια κριτήρια δίνονται παρακάτω:

  • Όταν διορθώνονται όλα τα σφάλματα.
  • Όταν συμπληρωθεί η προθεσμία.
  • Όταν ο προϋπολογισμός εξαντληθεί ή εξαντληθεί.
  • Όταν περάσουν όλες οι δοκιμαστικές περιπτώσεις.
  • Όταν η συμφωνία υπογραφεί.
  • Όταν γίνεται ένα ορισμένο ποσοστό δοκιμών.
  • Οταν ο Αλφα και η δοκιμή beta τελειώνει.

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

Αυτοματοποίηση κριτηρίων εξόδου εισόδου

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

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

Αυτοματισμός - Είναι πραγματικά απαραίτητο;

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

τι είναι ένας καλός μετατροπέας φωνής

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

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

Είναι απαραίτητος ο αυτοματισμός

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

Ας υποθέσουμε ότι απαιτούνται 10 ημέρες μη αυτόματων προσπαθειών για την κάλυψη δοκιμών παλινδρόμησης και, στη συνέχεια, πρέπει να ληφθεί η μέγιστη προσοχή για την αυτοματοποίησή τους. Μπορεί να εξοικονομήσει τουλάχιστον 60% προσπάθεια και 10 * 8 = 80 ώρες χειροκίνητη εργασία.

Ο αυτοματισμός μπορεί να ολοκληρωθεί μόνο 80/24 = 3,33 ημέρες. Αυτό εξοικονομεί περίπου 6,67.

Γιατί αυτοματοποίηση;

Η αυτοματοποίηση μπορεί να επιλεγεί μόνο όταν:

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

Παράγοντας κινδύνου

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

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

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

Παράγοντας κινδύνου στον αυτοματισμό

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

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

Πότε δεν πρέπει να προτιμάται ο αυτοματισμός;

Υπάρχει μια ερώτηση μεταξύ πολλών οργανισμών που είναι - Γιατί δεν είναι δυνατή η αυτοματοποίηση 100%;

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

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

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

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

Κόστος έναντι ROI για αυτοματισμό

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

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

Εγχειρίδιο σύγκρισης κόστους έναντι αυτοματισμού

Πού μπορεί ο αυτοματισμός να αποδώσει ελάχιστο έως ΜΕΙΩΣΗ κόστους;

Ακόμη και η αυτοματοποίηση κοστίζει επειδή πρέπει να αγοραστεί το απαιτούμενο εργαλείο για τη δοκιμή. Οι πόροι πρέπει να εκπαιδευτούν με το συγκεκριμένο εργαλείο. Το εργαλείο που επιλέξατε πρέπει να είναι εφικτό για τη δοκιμή όλων των τομέων του λογισμικού.

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

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

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

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

συμπέρασμα

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

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

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

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

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

^