Κορυφαίες 25 ερωτήσεις και απαντήσεις συνέντευξης λειτουργικών δοκιμών

top 25 functional testing interview questions

Συνήθεις ερωτήσεις και απαντήσεις συνέντευξης λειτουργικών δοκιμών:

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

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

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

Οι πιο δημοφιλείς ερωτήσεις συνέντευξης λειτουργικών δοκιμών

Ε # 1) Τι καταλαβαίνετε με τον όρο «Λειτουργικές δοκιμές»;

Απάντηση: Μια τεχνική δοκιμής μαύρου κουτιού, όπου η λειτουργικότητα μιας εφαρμογής δοκιμάζεται για τη δημιουργία της επιθυμητής εξόδου παρέχοντας συγκεκριμένη είσοδο ονομάζεται «Λειτουργική δοκιμή».

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

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

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

Q # 2) Ποια είναι τα σημαντικά βήματα που καλύπτονται στις λειτουργικές δοκιμές;

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

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

Ε # 3) Εξηγήστε τη διαφορά μεταξύ λειτουργικών δοκιμών και μη λειτουργικών δοκιμών.

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

Q # 4) Πώς διαφέρει το 'Build' από το 'Release';

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

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

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

Ε # 5) Εξηγήστε τον κύκλο σφαλμάτων.

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

Το παρακάτω σχήμα θα σας δώσει μια ιδέα του κύκλου ζωής του Bug:

(εικόνα πηγή )

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

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

Εάν τα ζητήματα / bug συμπεριφέρονται τώρα όπως αναμένεται, τότε η κατάστασή του αλλάζει σε Verified / Closed another Reopen.

Q # 6) Καταχωρίστε κάποια κατάσταση σφάλματος μαζί με την περιγραφή του.

εφαρμογή μιας συνδεδεμένης λίστας στο java

Απάντηση: Παρακάτω αναφέρονται μερικές καταστάσεις σφαλμάτων μαζί με τις περιγραφές τους:

• Νέος: Όταν το ελάττωμα ή το σφάλμα καταγράφεται για πρώτη φορά λέγεται Νέο.
• Ανατεθεί: Αφού ο υπεύθυνος δοκιμής καταγράψει ένα σφάλμα, το σφάλμα του ελέγχεται από τον επικεφαλής της δοκιμής και στη συνέχεια ανατίθεται στην αντίστοιχη ομάδα προγραμματιστών.
• Ανοιξε: Ο ελεγκτής καταγράφει ένα σφάλμα στην κατάσταση Open και παραμένει σε ανοιχτή κατάσταση έως ότου ο προγραμματιστής έχει εκτελέσει κάποια εργασία σε αυτό το σφάλμα.
• Επιλύθηκε / Διορθώθηκε: Όταν ένας προγραμματιστής έχει επιλύσει το σφάλμα, δηλαδή τώρα η εφαρμογή παράγει την επιθυμητή έξοδο για ένα συγκεκριμένο ζήτημα, τότε ο προγραμματιστής αλλάζει την κατάστασή του σε Resolved / Fixed.
• Επαληθεύτηκε / έκλεισε: Όταν ένας προγραμματιστής έχει αλλάξει την κατάσταση για να επιλυθεί / επιδιορθωθεί, τότε ο υπεύθυνος δοκιμών δοκιμάζει τώρα το ζήτημα στο τέλος του και αν επιδιορθωθεί τότε αλλάζει την κατάσταση του σφάλματος σε 'Επαληθεύτηκε / Κλείσιμο'.
• Ξανανοίγω: Εάν ένας υπεύθυνος δοκιμής είναι σε θέση να αναπαραγάγει ξανά το σφάλμα, δηλαδή το σφάλμα εξακολουθεί να υπάρχει ακόμη και μετά την επιδιόρθωση από τον προγραμματιστή, η κατάστασή του επισημαίνεται ως Άνοιγμα ξανά.
• Όχι σφάλμα / Μη έγκυρο: Ένα σφάλμα μπορεί να επισημανθεί ως μη έγκυρο ή όχι σφάλμα από τον προγραμματιστή, όταν το αναφερόμενο πρόβλημα είναι σύμφωνα με τη λειτουργικότητα, αλλά καταγράφεται λόγω εσφαλμένης ερμηνείας.
• Αναβαλλόμενος: Συνήθως όταν το σφάλμα έχει ελάχιστη προτεραιότητα για την κυκλοφορία και εάν υπάρχει έλλειψη χρόνου, σε αυτήν την περίπτωση, αυτά τα σφάλματα ελάχιστης προτεραιότητας μεταφέρονται στην επόμενη έκδοση.
• Αδυναμία αναπαραγωγής: Εάν ο προγραμματιστής δεν είναι σε θέση να αναπαραγάγει το σφάλμα στο τέλος του ακολουθώντας τα βήματα που αναφέρονται στο ζήτημα.

Q # 7) Τι είναι γνωστό ως δοκιμή βάσει δεδομένων;

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

Για παράδειγμα, ένα στούντιο δοκιμής χρησιμοποιείται για δοκιμές βάσει δεδομένων.

Μερικά πλεονεκτήματα των δοκιμών βάσει δεδομένων είναι:

• Επαναχρησιμοποίηση.
• Επαναληψιμότητα.
• Διαχωρισμός δεδομένων δοκιμής από τη λογική δοκιμής.
• Ο αριθμός των δοκιμαστικών περιπτώσεων μειώνεται.

Ε # 8) Ποια είναι τα σημαντικά σημεία που πρέπει να ληφθούν υπόψη κατά τη σύνταξη δοκιμαστικών περιπτώσεων;

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

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

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

Q # 9) Τι είναι ο έλεγχος αυτοματισμού;

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

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

Ορισμένα εργαλεία δοκιμών αυτοματισμού παρατίθενται παρακάτω:

• Σελήνιο
• Τελλούριο
• νερό
• ΣΑΠΟΥΝΙ

Q # 10) Εξηγήστε τον όρο Δοκιμή πίεσης και δοκιμή φορτίου.

Απάντηση:

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

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

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

Ε # 11) Τι καταλαβαίνετε από τον Έλεγχο έντασης;

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

Ε # 12) Ποιες είναι οι διαφορετικές τεχνικές δοκιμών που χρησιμοποιούνται στις λειτουργικές δοκιμές;

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

Μπορούν να οριστούν ως εξής:

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

Ε # 13) Τι καταλαβαίνετε με την Εξερευνητική δοκιμή; Πότε εκτελείται;

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

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

Η διερευνητική δοκιμή πραγματοποιείται συνήθως σε περιπτώσεις όπου:

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

Ε # 14) Για οποιαδήποτε εφαρμογή Ιστού, ποιες είναι οι πιθανές δυνατότητες σύνδεσης που πρέπει να δοκιμαστούν;

Απάντηση: Παρατίθενται παρακάτω τα πιθανά σενάρια που μπορούν να εκτελεστούν για να δοκιμάσουν πλήρως τη δυνατότητα σύνδεσης οποιασδήποτε εφαρμογής:

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

Υπάρχουν και μερικά άλλα πιθανά σενάρια που μπορούν να δοκιμαστούν.

Ε # 15) Εξηγήστε τον έλεγχο προσβασιμότητας και τη σημασία του στο παρόν σενάριο.

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

καλύτερο λογισμικό για αντιγραφή dvd σε mp4

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

Παρατίθενται παρακάτω μερικοί τύποι λογισμικού που βοηθούν και βοηθούν τα άτομα με ειδικές ανάγκες να χρησιμοποιούν τεχνολογία:

• Λογισμικό αναγνώρισης ομιλίας
• Λογισμικό αναγνώστη οθόνης
• Λογισμικό μεγέθυνσης οθόνης
• Ειδικό πληκτρολόγιο

Q # 16) Τι είναι η δοκιμή Adhoc;

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

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

Q # 17) Τι είναι το Equivalence Partitioning;

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

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

Για παράδειγμα: Για να προσδιορίσουμε το επιτόκιο σύμφωνα με το υπόλοιπο του λογαριασμού, μπορούμε να προσδιορίσουμε το εύρος του ποσού υπολοίπου στον λογαριασμό που κερδίζει διαφορετικό επιτόκιο.

Q # 18) Εξηγήστε την Ανάλυση Οριακής Αξίας.

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

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

Q # 19) Εξηγήστε τη διαφορά μεταξύ σοβαρότητας και προτεραιότητας.

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

Ακολουθούν οι 4 κατηγορίες στις οποίες κατηγοριοποιείται μια σοβαρότητα ελαττώματος:

• Κρίσιμος
• Μείζων
• Μεσαίο
• Χαμηλός

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

Ακολουθούν οι 3 κλάσεις στις οποίες ορίζεται μια προτεραιότητα ελαττώματος:

• Υψηλός
• Μεσαίο
• Χαμηλός

Ε # 20) Πότε εκτελούμε τον έλεγχο καπνού;

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

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

Ε # 21) Τι καταλαβαίνετε από το Sanity testing;

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

Δεν έχει νόημα να αποδεχτείτε το build από τον υπεύθυνο δοκιμών και να χάνετε χρόνο εάν αποτύχει η δοκιμή Sanity.

Q # 22) Τι καταλαβαίνετε από το Matrix Απαιτήσεων ιχνηλασιμότητας;

Απάντηση: Απαιτείται ιχνηλασιμότητα Matrix (RTM) είναι ένα εργαλείο για να παρακολουθείτε την κάλυψη των απαιτήσεων κατά τη διαδικασία της δοκιμής.

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

Το RTM δημιουργείται μόλις παραληφθεί το έγγραφο απαίτησης και διατηρείται μέχρι την κυκλοφορία του προϊόντος.

Q # 23) Ποιοι είναι οι παράγοντες που πρέπει να λαμβάνονται υπόψη στις δοκιμές βάσει κινδύνου;

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

Οι κύριοι παράγοντες που πρέπει να λαμβάνονται υπόψη στις δοκιμές βάσει κινδύνου είναι οι εξής:

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

Q # 24) Διαχωρίστε μεταξύ δοκιμών παλινδρόμησης και δοκιμής εκ νέου.

Απάντηση: Η διαφορά μεταξύ του Regression testing και του Re-testing μπορεί να εξηγηθεί ως εξής:

Q # 25) Εξηγήστε τη δοκιμή αποδοχής χρήστη.

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

Το UAT είναι επίσης γνωστό ως δοκιμή τελικού χρήστη.

συμπέρασμα

Μέσω αυτού του άρθρου, προσπάθησα να εξηγήσω κάθε θέμα του Functional Testing, έτσι ώστε κάθε άτομο που προετοιμάζεται για τη συνέντευξη να μπορεί εύκολα να κατανοήσει το θέμα και να τα θυμάται επίσης.

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

Σας ευχόμαστε καλή επιτυχία.

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

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

• Λειτουργική δοκιμή Vs Μη λειτουργική δοκιμή
• 16 Νέες δυνατότητες του εργαλείου Micro Focus UFT (Unified Functional Testing) - QTP έναντι UFT
• 5 καλύτερα εναλλακτικά εργαλεία HP Unified Functional Testing (UFT)
• Ένας πλήρης μη λειτουργικός οδηγός δοκιμών για αρχάριους
• Ένας οδηγός βήμα προς βήμα για το Jubula - Το Εργαλείο αυτοματοποιημένων λειτουργικών δοκιμών ανοιχτού κώδικα
• Λειτουργική δοκιμή έναντι δοκιμής απόδοσης: Πρέπει να γίνει ταυτόχρονα;
• Πλήρης οδηγός λειτουργικών δοκιμών με τους τύπους και το παράδειγμά του
• Tutorial Parrot QA: Ανασκόπηση λειτουργικών δοκιμών Cross Browser
• Spock για ενσωμάτωση και λειτουργική δοκιμή με σελήνιο
• Οι διαφορές μεταξύ δοκιμών μονάδας, δοκιμής ολοκλήρωσης και δοκιμής λειτουργίας
• Κορυφαίες 25 ερωτήσεις και απαντήσεις συνέντευξης λειτουργικών δοκιμών
• Κορυφαία 30 λειτουργικά εργαλεία δοκιμών το 2021