Στατικές δοκιμές και δυναμικές δοκιμές - διαφορά μεταξύ αυτών των δύο σημαντικών τεχνικών δοκιμών

static testing dynamic testing difference between these two important testing techniques

Η δοκιμή είναι Επαλήθευση και επικύρωση . Όλοι γνωρίζουμε ότι χρειάζονται 2 V για να ολοκληρωθεί η δοκιμή.

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

char στη συμβολοσειρά c ++

Ωστόσο, καμία συζήτηση για τις στατικές δοκιμές δεν θα ήταν πλήρης χωρίς εξήγηση για το τι σημαίνει το αντίστοιχο δυναμικό τεστ. Η δυναμική δοκιμή είναι επικύρωση, το άλλο «V».

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

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

1. Η δοκιμή είναι μια δραστηριότητα που έρχεται στο τέλος
2. Εκτελείται μόνο από δοκιμαστές και οι υπόλοιποι δεν έχουν καμία σχέση

Ας ξεκινήσουμε με μια γρήγορη αναφορά στο μοντέλο v :

• Στο αριστερή πλευρά του μοντέλου V, έχουμε δραστηριότητες που δεν εκτελούνται από την ομάδα QA.
• Στο η δεξιά πλευρά , έχουμε μερικά από αυτά που φροντίζονται από την ομάδα Dev, μερικά από τους υπεύθυνους δοκιμών και κάποια από τους χρήστες.

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

Το επόμενο στάδιο είναι το Σχεδιασμός συστήματος . Ο σχεδιασμός συστήματος είναι μια φάση όπου οι επιχειρησιακές απαιτήσεις μεταφράζονται στις λειτουργικές απαιτήσεις, στο FRD (έγγραφο λειτουργικών απαιτήσεων).

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

Ενα παράδειγμα: Ας πούμε ότι αυτό είναι το BRD για έναν τραπεζικό ιστότοπο που έχει μεγάλη ασφάλεια. Υπάρχει μια ενότητα στο BRD που μιλά για τους κανόνες κωδικού πρόσβασης για τους διάφορους χρήστες που δημιουργούν λογαριασμό στον ιστότοπο διαδικτυακής τραπεζικής. Ένας από τους κανόνες είναι: Ένας χρήστης δεν μπορεί να χρησιμοποιήσει έναν κωδικό πρόσβασης που χρησιμοποιεί για άλλους λογαριασμούς.

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

Ας εξετάσουμε τώρα τα ακόλουθα σημεία με βάση αυτό το παράδειγμα:

ηλεκτρονικό λογισμικό δημιουργίας αντιγράφων ασφαλείας για παρόχους υπηρεσιών

1. Πώς καθορίζεται ότι αυτή η απαίτηση δεν είναι οικοδομήσιμη και έτσι δεν μπορεί να ελεγχθεί (με άλλα λόγια, όχι εφικτή); Διαθέτουμε τον ιστότοπο της τράπεζας και, στη συνέχεια, ορίζουμε τα στοιχεία σύνδεσης και τον κωδικό πρόσβασης - και μετά συνειδητοποιούμε ότι αυτό δεν είναι δυνατό; Όχι, το βασίζουμε απλώς στην αναθεώρησή μας για το BRD και φυσικά σε κάποια κοινή επιχειρηματική λογική.
2. Δοκιμάζουμε αυτήν την απαίτηση; Σίγουρα, αλλά βασίζεται αποκλειστικά στη θεωρητική, εννοιολογική έννοια αλλά όχι στην πραγματική ΑΥΤ (Εφαρμογή υπό δοκιμή).
3. Ποια είναι η φυσική μορφή αυτού του τεστ; - Μια απλή ανάγνωση ή μια επίσημη ανασκόπηση του BRD ή μια ακόμη πιο επίσημη ανάλυση σκοπιμότητας των επιχειρησιακών απαιτήσεων.

Επιστρέφοντας στις παρανοήσεις μας:

4. Ποιος πραγματοποιεί αυτήν την κριτική του BRD; - Κυρίως η ομάδα dev και άλλες τεχνικές ομάδες που είναι υπεύθυνες για τη δημιουργία του προϊόντος. Όχι δοκιμαστές.
5. Αυτή η κριτική συνεχίζεται στο τέλος της δημιουργίας προϊόντων; Όχι, στο αρχικό στάδιο ανάπτυξης του έργου. Ως εκ τούτου, όχι μόνο το τέλος.

Τεχνικές στατικών δοκιμών:

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

• Κριτικές εγγράφων
• Περιηγήσεις
• Επιθεώρηση
• Ανάλυση σκοπιμότητας ή οποιαδήποτε άλλη μορφή ανάλυσης για να προσδιοριστεί εάν το λογισμικό είναι αυτό που πρέπει να είναι ή όχι
• Αναθεώρηση κώδικα

Για να παραθέσω το CSTE CBOK, 'Η επαλήθευση απαντά στην ερώτηση,' Κατασκευάσαμε το σωστό σύστημα; ' ενώ οι επικυρώσεις απευθύνονται, 'Κατασκευάσαμε σωστά το σύστημα;'

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

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

βοηθά ερωτήσεις και απαντήσεις συνέντευξης γραφείου pdf

Στη δεξιά πλευρά του μοντέλου V υπάρχει επικύρωση.

Δυναμικές τεχνικές δοκιμών:

• Δοκιμή μονάδας
• Δοκιμή ολοκλήρωσης
• Δοκιμή συστήματος

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

Επομένως, οποιαδήποτε μορφή δοκιμής όπου έχουμε μια δοκιμή που πρέπει να εκτελεστεί σε AUT και η έξοδος της απαιτείται για τον προσδιορισμό του αποτελέσματος της δοκιμής (επιτυχής ή όχι) - είναι επικύρωση.

Τώρα, θα ήταν εντάξει να γενικεύσουμε ότι στη δεξιά πλευρά (RHS) του μοντέλου V δεν υπάρχει καμία επαλήθευση; Η απάντηση είναι όχι.

Όλες οι δοκιμές που δημιουργούνται σε κάθε στάδιο του RHS εξετάζονται πολλές φορές κατά τη διάρκεια του σταδίου δημιουργίας / οριστικοποίησης. Η λεπτομερής διαδικασία της αναθεώρησης τεκμηρίωσης δοκιμής βρίσκεται στις https://www.softwaretestinghelp.com/test-documentation-reviews/

Στο RHS:

• Οι δοκιμές και ο κώδικας ελέγχονται στα στάδια δοκιμής Ενότητας / Ενσωμάτωσης από τους προγραμματιστές.
• Οι δοκιμές συστήματος υποβάλλονται σε αξιολόγηση από ομοτίμους κατά τη διάρκεια της τεκμηρίωσής τους και μετά την ολοκλήρωση υποβάλλονται σε έλεγχο από την ομάδα dev και τον επιχειρηματικό αναλυτή.
• Οι δοκιμές UAT υπόκεινται σε έλεγχο από την ομάδα QA καθώς και από τους χρήστες πριν από την έναρξη του UAT.

συμπέρασμα

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

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

Σχετικά με τον συγγραφέα: Αυτό το άρθρο γράφτηκε από το μέλος της ομάδας STH Swati S.

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

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

• Διαφορά μεταξύ Desktop, Client Server Testing και Web Testing
• Τεχνικές εκτίμησης ευκίνητων: μια πραγματική εκτίμηση σε ένα έργο ευκίνητο
• Δοκιμή μαύρου κουτιού: Ένα σε βάθος εκπαιδευτικό πρόγραμμα με παραδείγματα και τεχνικές
• Τι είναι ο έλεγχος συμμόρφωσης (δοκιμή συμμόρφωσης);
• Ποια είναι η διαφορά μεταξύ δοκιμών SIT Vs UAT;
• Δοκιμή άλφα και δοκιμή beta (Ένας πλήρης οδηγός)
• Βασικές διαφορές μεταξύ δοκιμής μαύρου κουτιού και δοκιμής λευκού κουτιού
• Οι διαφορές μεταξύ δοκιμών μονάδας, δοκιμών ολοκλήρωσης και δοκιμών λειτουργίας