Μενού

Ερωτήσεις και απαντήσεις συνέντευξης SDET (Πλήρης οδηγός)

sdet interview questions

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

Διαβάστε αυτόν τον πλήρη οδηγό για το Software Development Engineer σε δοκιμαστικές συνεντεύξεις για να μάθετε τη μορφή και πώς να απαντήσετε στις ερωτήσεις συνέντευξης SDET που τέθηκαν στους διάφορους γύρους:

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

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

Ερωτήσεις και απαντήσεις συνέντευξης SDET

Τι θα μάθετε:

Οδηγός προετοιμασίας συνέντευξης SDET

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

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

Ακολουθούν ορισμένα σημεία στα οποία κάποιος προετοιμάζεται για μια συνέντευξη SDET πρέπει να εστιάσει σε μεγάλο βαθμό:

πώς να δημιουργήσετε μια διπλά συνδεδεμένη λίστα java
  • Δεδομένου ότι, τις περισσότερες φορές, αυτές οι συνεντεύξεις είναι τεχνογνωσίας τεχνολογίας / γλώσσας, ως εκ τούτου οι υποψήφιοι πρέπει να είναι πρόθυμοι να μάθουν τη νέα τεχνολογία (και να αξιοποιήσουν τις υπάρχουσες δεξιότητες) όποτε απαιτείται.
  • Πρέπει να έχουν καλή επικοινωνία και ομαδικές δεξιότητες, καθώς οι ρόλοι του SDET αυτές τις μέρες απαιτούν επικοινωνία και συνεργασία σε διάφορα επίπεδα με πολλούς ενδιαφερόμενους.
  • Πρέπει να έχει μια βασική κατανόηση διαφορετικών εννοιών σχεδιασμού συστήματος, κλιμάκωσης, ταυτόχρονης λειτουργίας, μη λειτουργικών απαιτήσεων κ.λπ.

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

Μορφή μηχανικού ανάπτυξης λογισμικού σε συνέντευξη δοκιμής

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

Όμως, το θέμα των συνεντεύξεων βασίζεται γενικά στα παρακάτω σημεία:

  • Τηλεφωνική συζήτηση: Συνομιλία με τον διευθυντή ή / και τα μέλη της ομάδας που είναι συνήθως ένας γύρος προβολής.
  • Γραπτός γύρος: Με συγκεκριμένες ερωτήσεις δοκιμών / περιβλημάτων.
  • Γύρος ικανότητας κωδικοποίησης: Απλές ερωτήσεις κωδικοποίησης (γλώσσα αγνωστικής) και ζητείται από τον υποψήφιο να γράψει κώδικα σε επίπεδο παραγωγής.
  • Κατανόηση των βασικών εννοιών ανάπτυξης: Όπως OOPS Concepts, SOLID Principles κ.λπ.
  • Σχεδιασμός και ανάπτυξη πλαισίου αυτοματισμού δοκιμής
  • Γλώσσες γραφής: Σελήνιο, Python, Javascript, κ.λπ.
  • Πολιτισμός Fit / HR συζήτηση και διαπραγματεύσεις

Ερωτήσεις και απαντήσεις συνέντευξης SDET

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

Επάρκεια κωδικοποίησης

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

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

Ας δούμε μερικά δείγματα προβλημάτων.

Ε # 1) Γράψτε ένα πρόγραμμα για ανταλλαγή 2 αριθμών χωρίς τη χρήση της 3ης (προσωρινής) μεταβλητής;

Απάντηση :

Πρόγραμμα ανταλλαγής δύο αριθμών:

public class SwapNos { public static void main(String() args) { System.out.println('Calling swap function with inputs 2 & 3'); swap(2,3); System.out.println('Calling swap function with inputs -3 & 5'); swap(-3,5); } private static void swap(int x, int y) { System.out.println('values before swap:' + x + ' and ' + y); // swap logic x = x + y; y = x - y; x = x - y; System.out.println('values after swap:' + x + ' and ' + y); } }

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

έξοδος-swap2nos 8 νέα 1

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

Θετικές τιμές: X = 2, Υ = 3

// swap logic - x=2, y=3 x = x + y; => x=5 y = x - y; => y=2 x = x - y; => x=3 x & y swapped (x=3, y=2)

Αρνητικές τιμές: X = -3, Υ = 5

// swap logic - x=-3, y=5 x = x + y; => x=2 y = x - y; => y=-3 x = x - y; => x=5 x & y swapped (x=5 & y=-3)

Ε # 2) Γράψτε ένα πρόγραμμα για να αντιστρέψετε έναν αριθμό;

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

Εδώ, το πρόβλημα αναμένει από έναν υποψήφιο να κάνει και κάποιες υποθέσεις - για παράδειγμα, ο αριθμός θα μπορούσε να είναι ακέραιος. Εάν η είσοδος είναι 345, τότε η έξοδος θα πρέπει να είναι 543 (που είναι αντίστροφη από 345)

Ας δούμε το απόσπασμα κώδικα για αυτήν τη λύση:

public class ReverseNumber { public static void main(String() args) { int num = 10025; System.out.println('Input - ' + num + ' Output:' + reverseNo(num)); } public static int reverseNo(int number) { int reversed = 0; while(number != 0) { int digit = number % 10; reversed = reversed * 10 + digit; number /= 10; } return reversed; } }

Έξοδος για αυτό το πρόγραμμα έναντι εισόδου : 10025 - Αναμένεται να είναι : 52001

έξοδος-αντίστροφο Αριθμός 6 νέο

Q # 3) Γράψτε ένα πρόγραμμα για τον υπολογισμό των παραγόντων ενός αριθμού;

Απάντηση: Το Factorial είναι μια από τις πιο συχνές ερωτήσεις σε όλες σχεδόν τις συνεντεύξεις (συμπεριλαμβανομένων των συνεντεύξεων προγραμματιστή)
Για συνεντεύξεις προγραμματιστών, μεγαλύτερη έμφαση δίνεται σε έννοιες προγραμματισμού όπως δυναμικός προγραμματισμός, αναδρομή κ.λπ., ενώ από τον Μηχανικό Ανάπτυξης Λογισμικού σε προοπτική Δοκιμή, είναι σημαντικό να χειριστείτε τα σενάρια αιχμής όπως οι μέγιστες τιμές, οι ελάχιστες τιμές, οι αρνητικές τιμές κ.λπ. και η προσέγγιση / αποδοτικότητα είναι σημαντικά αλλά γίνονται δευτερεύοντα.

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

public class Factorial { public static void main(String() args) { System.out.println('Factorial of 5 using loop is:' + factorialWithLoop(5)); System.out.println('Factorial of 10 using recursion is:' + factorialWithRecursion(10)); System.out.println('Factorial of negative number -100 is:' + factorialWithLoop(-100)); } public static long factorialWithLoop(int n) { if(n <0) { System.out.println('Negative nos can't have factorial'); return -9999; } long fact = 1; for (int i = 2; i <= n; i++) { fact = fact * i; } return fact; } public static long factorialWithRecursion(int n) { if(n < 0) { System.out.println('Negative nos can't have factorial'); return -9999; } if (n <= 2) { return n; } return n * factorialWithRecursion(n - 1); } }

Ας δούμε την έξοδο για - factorial χρησιμοποιώντας τον βρόχο, factorial χρησιμοποιώντας recursion και faktorial ενός αρνητικού αριθμού (που θα επέστρεφε μια προεπιλεγμένη καθορισμένη τιμή -9999)

έξοδος-παραγοντική 4 νέα

Q # 4) Γράψτε ένα πρόγραμμα για να ελέγξετε αν μια δεδομένη συμβολοσειρά έχει ισορροπημένες παρενθέσεις;

Απάντηση:

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

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

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

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

Ας δούμε τη λύση:

Οι ισορροπημένες παρενθέσεις πρέπει να ελέγχουν για μια δεδομένη συμβολοσειρά που περιέχει παρενθέσεις (ή αγκύλες), θα πρέπει να έχουν ίσο πλήθος ανοίγματος και κλεισίματος καθώς και σωστά δομημένη θέση. Για το πλαίσιο αυτού του προβλήματος, θα χρησιμοποιήσουμε ισορροπημένες παρενθέσεις όπως - ‘()’, ‘()’, ‘{}’ - δηλ. Δεδομένη συμβολοσειρά μπορεί να έχει οποιονδήποτε συνδυασμό αυτών των αγκυλών.

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

Παράδειγμα: Μια δεδομένη συμβολοσειρά - '{() {} ()} - είναι μια ισορροπημένη συμβολοσειρά καθώς είναι δομημένη και δεν έχει ίσο αριθμό κλεισίματος και ανοίγματος παρενθέσεων, αλλά συμβολοσειρά -' {(}) {} () '- αυτή η συμβολοσειρά - παρόλο που δεν έχει ίσο αριθμό παρενθέσεων ανοίγματος και κλεισίματος, αυτό δεν είναι ακόμη ισορροπημένο, επειδή μπορείτε να δείτε ότι χωρίς κλείσιμο '(' έχουμε κλείσει '}' (δηλ. όλες οι εσωτερικές αγκύλες πρέπει να είναι κλειστές πριν κλείσετε ένα εξωτερικό βραχίονα)

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

Μια στοίβα είναι ένα LIFO (Last In First Out τύπος δομής δεδομένων), σκεφτείτε το ως στοίβα / στοίβα πλακών σε έναν γάμο - θα πάρετε την κορυφαία πλάκα όποτε τη χρησιμοποιείτε.

Αλγόριθμος:

# 1) Δηλώστε μια στοίβα χαρακτήρων (η οποία θα κρατούσε τους χαρακτήρες στη συμβολοσειρά και ανάλογα με κάποια λογική, σπρώξτε και βγάλτε τους χαρακτήρες έξω).

# 2) Διασχίστε τη συμβολοσειρά εισόδου και όποτε θέλετε

  • Υπάρχει ένας αρχικός χαρακτήρας αγκύλης - δηλαδή '(', {'ή' ('- ωθήστε τον χαρακτήρα στο Stack.
  • Υπάρχει ένας χαρακτήρας κλεισίματος - δηλαδή ')', '}', ')' - σκάστε ένα στοιχείο από το Stack και ελέγξτε αν ταιριάζει με το αντίθετο του χαρακτήρα κλεισίματος - δηλαδή αν ο χαρακτήρας είναι '}' τότε στο Stack pop θα πρέπει να περιμένετε ' {'
    • Εάν το αναδυόμενο στοιχείο δεν ταιριάζει με τις παρενθέσεις κλεισίματος, τότε η συμβολοσειρά δεν είναι ισορροπημένη και μπορείτε να επιστρέψετε αποτελέσματα.
    • Διαφορετικά συνεχίστε με την προσέγγιση στοίβας και ποπ (μεταβείτε στο βήμα 2).
  • Εάν η συμβολοσειρά διασχίζεται εντελώς και το μέγεθος στοίβας είναι επίσης μηδέν, τότε μπορούμε να πούμε / συμπεράνουμε ότι η δεδομένη συμβολοσειρά είναι μια ισορροπημένη συμβολοσειρά παρενθέσεων.

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

Κώδικας:

import java.util.Stack; public class BalancedParanthesis { public static void main(String() args) { final String input1 = '{()}'; System.out.println('Checking balanced paranthesis for input:' + input1); if (isBalanced(input1)) { System.out.println('Given String is balanced'); } else { System.out.println('Given String is not balanced'); } } /** * function to check if a string has balanced parentheses or not * @param input_string the input string * @return if the string has balanced parentheses or not */ private static boolean isBalanced(String input_string) { Stack stack = new Stack(); for (int i = 0; i

Η έξοδος του παραπάνω αποσπάσματος κώδικα:

εξισορρόπηση εξόδουParantheses 2 new

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

ΣΗΜΕΙΩΣΗ: Είναι πάντα καλό να σκεφτόμαστε τη λύση δυνατά (και όχι μόνο στο μυαλό) - και εκπληκτικά αυτό είναι ένα σημαντικό χαρακτηριστικό που αναζητούν οι συνεντεύκτες. Πολλοί ερευνητές θα μπορούσαν απλώς να καταργήσουν τον αλγόριθμο και να προχωρήσουν στην επόμενη δήλωση προβλήματος.

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

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

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

Ας δούμε μερικά δείγματα ερωτήσεων και λύσεων για το ίδιο.

Ε # 5) Εξηγήστε και σχεδιάστε στοιχεία του πλαισίου αυτοματισμού για μια εφαρμογή Ιστού;

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

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

Συνιστώμενη ανάγνωση => Τα πιο δημοφιλή πλαίσια δοκιμής αυτοματοποίησης

Ε # 6) Εξηγήστε τις στρατηγικές δοκιμών για μια εφαρμογή για κινητά;

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

Μερικοί δείκτες για τη δομή της απάντησης σε αυτήν την ερώτηση θα μπορούσαν να είναι,

  • Δοκιμή σε συσκευές έναντι εξομοιωτών.
  • Αναγνώριση και αποθήκευση αντικειμένων / στοιχείων σε διαφορετικές οθόνες - Παράδειγμα: Μοντέλο αντικειμένου σελίδας.
  • Φόρτωση δοκιμής μιας εφαρμογής για κινητά.
  • Μπορείτε να μιλήσετε για διαφορετικούς τύπους εφαρμογών για κινητά όπως - Εγγενείς εφαρμογές, Υβριδικές εφαρμογές και να συζητήσετε στρατηγικές / προσεγγίσεις που θα χρησιμοποιούσατε για να τις δοκιμάσετε.

Συνιστώμενη ανάγνωση => Εκμάθηση δοκιμών εφαρμογών για κινητά

Ε # 7) Σχεδιάστε ένα πλαίσιο αυτοματισμού για τη δοκιμή API REST;

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

Μπορείτε να ξεκινήσετε την απάντησή σας καλύπτοντας τα παρακάτω σημεία:

  • Στοιχεία πλαισίου αυτοματοποίησης API όπως τοπική ρύθμιση, πλαστή ρύθμιση API ή Hosted API Testing.
  • Εργαλεία που χρησιμοποιούνται για αυτοματοποίηση API. Υπάρχουν διάφορα εργαλεία που είναι διαθέσιμα για να επικυρώσουν τις λειτουργικές πτυχές ενός API που βασίζεται σε REST. Μερικά από αυτά τα εργαλεία είναι ταχυδρόμος, υπόλοιπο, κ.λπ. Για αναλυτικές λεπτομέρειες διαφορετικών εργαλείων, μπορείτε να ανατρέξετε στο άρθρο μας εδώ .
  • Μη λειτουργική αυτοματοποίηση των API.
  • Προγραμματισμένη εκτέλεση δοκιμών αυτοματισμού.
  • Ενσωμάτωση δοκιμών αυτοματισμού για API.

Ε # 8) Ειδικές ερωτήσεις για το πλαίσιο.

Απάντηση: Κατά καιρούς ανάλογα με το προφίλ που παίρνει συνέντευξη, μπορεί να υπάρχει απαίτηση για έναν υποψήφιο να είναι ικανός με ένα συγκεκριμένο πλαίσιο - π.χ. Σελήνιο, JMeter, κ.λπ.

Συνιστώμενη ανάγνωση => Ταχυδρόμος , Μόκκιτο , Ροή ροής , Σελήνιο , JMeter

Σχετικά με τις δοκιμές

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

Σε αυτήν την ενότητα, μπορείτε να περιμένετε ερωτήσεις όπως αυτές:

Ε # 9) Ποια είναι τα διαφορετικά στοιχεία ενός σχεδίου δοκιμών;

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

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

Συνιστώμενη ανάγνωση => Πώς να γράψετε ένα καλό σχέδιο δοκιμών

Ε # 10) Τι καθορίζει και αποφασίζει την προτεραιότητα και τη σοβαρότητα ενός σφάλματος;

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

Γενικά,

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

Συνιστώμενη ανάγνωση => Προτεραιότητα και σοβαρότητα ελαττώματος

Ε # 11) Τι είναι το Διαχωρισμό ισοδυναμίας; Απεικονίστε με ένα παράδειγμα.

Απάντηση: Το Equivalence Partitioning είναι μια τεχνική που χρησιμοποιείται κυρίως για τη δοκιμή Black Box, για να δοκιμάσετε διάφορους συνδυασμούς εισόδων σε ένα δεδομένο πεδίο.

Για παράδειγμα, εάν δοκιμάζετε μια εφαρμογή διαπραγμάτευσης και θέλετε να γράψετε όλα τα σενάρια δοκιμής για το πεδίο 'Ποσότητα' - ποιες θα ήταν οι διαφορετικές εισόδους που θα δοκιμάσατε για αυτό το πεδίο;
Δεδομένης της λειτουργικής απαίτησης, η ποσότητα πρέπει να είναι θετική ακέραια τιμή μεταξύ 1 και 100000. Επομένως, για να δοκιμάσετε διάφορες εισόδους (έγκυρες και μη έγκυρες), μπορείτε να κάνετε δοκιμές για 1 είσοδο από κάθε τέτοια κατηγορία.

  • Έγκυρες τιμές: Μεταξύ 1 και 100000 -> δοκιμή για οποιαδήποτε έγκυρη τιμή x έτσι ώστε x> 1 και x<100000.
  • Οριακές τιμές: Ελέγξτε για τις επιτρεπόμενες οριακές τιμές, δηλ. 1 & 100000.
  • Μη έγκυρες τιμές: Τιμές που βρίσκονται εκτός του επιτρεπόμενου εύρους - δηλαδή δοκιμή για μια τέτοια τιμή για το x, έτσι ώστε x 100000.

Συνιστώμενη ανάγνωση => Στρατηγική καταμερισμού ισοδυναμίας

Σχεδιασμός συστήματος

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

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

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

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

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

  1. Βασικά στοιχεία των λειτουργικών συστημάτων: Σελιδοποίηση, συστήματα αρχείων, εικονική μνήμη και φυσική μνήμη κ.λπ.
  2. Έννοιες δικτύωσης: Επικοινωνία HTTP, στοίβα TCP / IP, τοπολογίες δικτύου.
  3. Έννοιες επεκτασιμότητας: Οριζόντια και κάθετη κλιμάκωση.
  4. Έννοιες Concurrency / Threading
  5. Τύποι βάσεων δεδομένων: SQL / No SQL βάσεις δεδομένων, πότε να χρησιμοποιήσετε τι τύπο βάσης δεδομένων, πλεονεκτήματα και μειονεκτήματα διαφορετικών τύπων βάσεων δεδομένων.
  6. Τεχνικές κατακερματισμού
  7. Βασική κατανόηση του ΚΑΠΑΚΙ θεώρημα, θραύση, διαχωρισμός κ.λπ.

Ας δούμε μερικά δείγματα ερωτήσεων

Ε # 12) Σχεδιάστε ένα σύστημα συντόμευσης URL όπως ένα μικροσκοπική διεύθυνση URL ;

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

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

Ας συζητήσουμε εν συντομία τη λύση

α) Αποσαφήνιση λειτουργικών και μη λειτουργικών απαιτήσεων

Λειτουργικές απαιτήσεις: Η λειτουργική απαίτηση είναι απλώς από την πλευρά του πελάτη, είναι ένα σύστημα που τροφοδοτείται με ένα μεγάλο (μεγάλο μήκος) URL και η έξοδος πρέπει να είναι μια συντομευμένη διεύθυνση URL.

Κατά την πρόσβαση στη συντομευμένη διεύθυνση URL, θα πρέπει να ανακατευθύνει τον χρήστη στην αρχική διεύθυνση URL. Για παράδειγμα - δοκιμάστε να συντομεύσετε μια πραγματική διεύθυνση URL στη σελίδα https://tinyurl.com/, τροφοδοτήστε μια διεύθυνση URL εισαγωγής όπως το www.softwaretestinghelp.com και θα πρέπει να λάβετε ένα μικρό URL όπως https://tinyurl.com/shclcqa

Μη λειτουργικές απαιτήσεις: Το σύστημα θα πρέπει να είναι αποτελεσματικό όσον αφορά την ανακατεύθυνση με καθυστέρηση χιλιοστών του δευτερολέπτου (καθώς είναι ένα πρόσθετο άλμα για έναν χρήστη που έχει πρόσβαση στην αρχική διεύθυνση URL).

  • Τα συντομευμένα URL πρέπει να έχουν ρυθμιζόμενο χρόνο λήξης.
  • Οι συντομευμένες διευθύνσεις URL δεν πρέπει να είναι προβλέψιμες.

β) Εκτίμηση χωρητικότητας / κίνησης

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

Ας κάνουμε μερικούς αριθμούς χωρητικότητας για το παράδειγμα συντόμευσης URL.

Ας υποθέσουμε ότι θα υπάρχουν 100k νέα αιτήματα συντόμευσης URL ανά ημέρα (με αναλογία ανάγνωσης-εγγραφής 100: 1 - δηλαδή για κάθε 1 συντομευμένο URL, θα έχουμε 100 αιτήματα ανάγνωσης έναντι της συντομευμένης διεύθυνσης URL)

Έτσι θα έχουμε,

100k write requests/day => 100000/(24x60x60) => 1.15 request/second 10000k read requests/day => 10000000/(24x60x60) => 1157 requests/second

γ) Θέματα αποθήκευσης και μνήμης

Μετά τους αριθμούς χωρητικότητας, μπορούμε να παρέχουμε αυτούς τους αριθμούς για να πάρουμε,

  • Η χωρητικότητα αποθήκευσης που απαιτείται για την κάλυψη του αναμενόμενου φορτίου, Για παράδειγμα, μπορούμε να σχεδιάσουμε να σχεδιάσουμε μια λύση αποθήκευσης για να υποστηρίξουμε τα αιτήματα για έως και 1 έτος.
    Παράδειγμα: Εάν κάθε συντομευμένο URL καταναλώνει 50 byte, τότε τα συνολικά δεδομένα / αποθηκευτικός χώρος που θα χρειαζόμασταν πάνω από ένα έτος θα ήταν:
=> total write requests/day x 365 x 50 / (1024x1024) => 1740 MB
  • Τα ζητήματα μνήμης είναι σημαντικά για τον προγραμματισμό του συστήματος από την οπτική γωνία του αναγνώστη. δηλ. για συστήματα που έχουν μεγάλη σημασία - όπως αυτό που προσπαθούμε να δημιουργήσουμε (επειδή η διεύθυνση URL θα δημιουργηθεί μία φορά αλλά θα έχει πρόσβαση πολλές φορές).
    Τα βαριά συστήματα ανάγνωσης χρησιμοποιούν γενικά την προσωρινή αποθήκευση για να γίνουν πιο αποδοτικά και να αποφύγουν την ανάγνωση από τον μόνιμο χώρο αποθήκευσης για να εξοικονομήσουν χρήματα στην ανάγνωση I / O.

Ας υποθέσουμε, θέλουμε να αποθηκεύσουμε το 60% των αιτημάτων ανάγνωσής μας στην κρυφή μνήμη, οπότε κατά τη διάρκεια του έτους θα απαιτούσαμε το 60% των συνολικών αναγνώσεων κατά τη διάρκεια του έτους x byte που απαιτείται από κάθε καταχώριση

=> (60/100) x 100000 x 365 x (50/1024x1024) => 1045 MB ~ 1GB

Έτσι, σύμφωνα με τους αριθμούς χωρητικότητας, αυτό το σύστημα θα απαιτούσε περίπου 1 GB φυσικής μνήμης

δ) Εκτιμήσεις εύρους ζώνης

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

Παράδειγμα: Εάν κάθε συντομευμένο URL καταναλώνει 50 bytes, τότε οι συνολικές ταχύτητες ανάγνωσης και εγγραφής που θα χρειαζόμασταν θα ήταν οι παρακάτω:

WRITE - 1.15 x 50bytes = 57.5 bytes/s READS - 1157 x 50bytes = 57500 bytes/s => 57500 / 1024 => 56.15 Kb/s

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

Οι διαφορετικές προσεγγίσεις που θα μπορούσαν να χρησιμοποιηθούν για τη δημιουργία συντομευμένων διευθύνσεων URL είναι:

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

Κατακερματισμός

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

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

Προ-δημιουργημένες συντομευμένες χορδές

API υπηρεσιών: Μπορούμε να σκεφτούμε το σύστημα συντόμευσης διευθύνσεων URL ως ένα σύνολο API βασισμένο σε REST τα οποία έχουν τα ακόλουθα τελικά σημεία:

  • createUrl (String Url, DateTime expiryTime): Αυτό το τελικό σημείο δημιουργεί και επιστρέφει μια συντομευμένη διεύθυνση URL με καθορισμένη διάρκεια λήξης όπως καθορίζεται στην εισαγωγή.
  • retrieveUrl (String shortenedUrl): Αυτό το τελικό σημείο ανακτά τη διεύθυνση URL προς ανακατεύθυνση έναντι της δεδομένης συντομευμένης διεύθυνσης URL.

στ) Κλίμακα και Ταυτόχρονη

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

Ασχολείται με, πώς μπορεί το σύστημα

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

Συνιστώμενη ανάγνωση => Τεχνικές κλιμάκωσης

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

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

Ε # 13) Σχεδιάστε μια πλατφόρμα βίντεο όπως το Youtube.

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

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

Μπορείτε να συζητήσετε σημεία όπως,

  • Αποθήκευση: Τι είδους βάση δεδομένων θα επιλέξετε να αποθηκεύσετε περιεχόμενο βίντεο, προφίλ χρηστών, λίστες αναπαραγωγής κ.λπ.;
  • Ασφάλεια και έλεγχος ταυτότητας / Εξουσιοδότηση
  • Προσωρινή αποθήκευση: Δεδομένου ότι μια πλατφόρμα ροής όπως το youtube θα πρέπει να είναι αποτελεσματική, η προσωρινή αποθήκευση είναι ένας σημαντικός παράγοντας για το σχεδιασμό ενός τέτοιου συστήματος.
  • Συγχρονισμός: Πόσοι χρήστες μπορούν να μεταδίδουν βίντεο παράλληλα;
  • Άλλες λειτουργίες πλατφόρμας, όπως υπηρεσία προτάσεων βίντεο που προτείνει / προτείνει στους χρήστες τα επόμενα βίντεο που μπορούν να παρακολουθήσουν κ.λπ.

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

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

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

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

Μπορείτε να κάνετε διευκρινιστικές ερωτήσεις όπως

  • Πόσα πατώματα υπάρχουν;
  • Πόσα ανελκυστήρες υπάρχουν;
  • Είναι όλοι οι ανελκυστήρες σέρβις / ανελκυστήρες επιβατών;
  • Είναι διαμορφωμένοι όλοι οι ανελκυστήρες ώστε να σταματούν σε κάθε όροφο;

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

system-design-elevator_system

Όσον αφορά τις βασικές κλάσεις / αντικείμενα αυτού του συστήματος, μπορείτε να σκεφτείτε να έχετε:

  • Χρήστης: Ασχολείται με όλες τις ιδιότητες ενός χρήστη και τις ενέργειες που μπορούν να πραγματοποιήσουν στο αντικείμενο Elevator Object.
  • Ανελκυστήρας: Ανελκυστήρας Συγκεκριμένες ιδιότητες όπως ύψος, πλάτος, αριθμός ανελκυστήρα.
  • Πόρτα ασανσέρ: Όλα τα πράγματα που σχετίζονται με την πόρτα, όπως χωρίς πόρτες, τύπος πόρτας, αυτόματη ή χειροκίνητη κ.λπ.
  • Elevator_Button_Control: Διαφορετικά κουμπιά / χειριστήρια που διατίθενται στον ανελκυστήρα και διαφορετικές καταστάσεις στις οποίες μπορούν να βρίσκονται αυτά τα χειριστήρια.

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

Ένα άλλο σημαντικό συστατικό του συστήματος ανελκυστήρων είναι το Eventing System. Μπορείτε να μιλήσετε για την εφαρμογή ουρών ή σε μια πιο περίπλοκη ρύθμιση δημιουργώντας ροές συμβάντων χρησιμοποιώντας το Apache Kafka όπου τα συμβάντα παραδίδονται σε αντίστοιχα συστήματα προς εκτέλεση.

Το Eventing System είναι μια σημαντική πτυχή καθώς υπάρχουν πολλοί χρήστες (σε διαφορετικούς ορόφους) που χρησιμοποιούν τον ανελκυστήρα ταυτόχρονα. Ως εκ τούτου, τα αιτήματα του χρήστη θα πρέπει να βρίσκονται στην ουρά και να εμφανίζονται σύμφωνα με τη διαμορφωμένη λογική στους ελεγκτές Elevator.

Ε # 15) Σχεδιασμός Instagram / Twitter / Facebook.

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

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

  • Εκτίμηση χωρητικότητας: Τα περισσότερα από αυτά τα συστήματα θα ήταν βαρύ για ανάγνωση, επομένως απαιτείται εκτίμηση χωρητικότητας και θα μας επέτρεπε να διασφαλίσουμε ότι εξασφαλίζεται η κατάλληλη διαμόρφωση διακομιστή και βάσης δεδομένων για την εξυπηρέτηση του απαιτούμενου φορτίου.
  • Σχέδιο DB: Τα κύρια σημαντικά σχήματα DB που πρέπει να συζητηθούν είναι - Λεπτομέρειες χρήστη, Σχέσεις χρηστών, Σχέδια μηνυμάτων, Σχέδια περιεχομένου.
  • Διακομιστές φιλοξενίας βίντεο και εικόνας: Οι περισσότερες από αυτές τις εφαρμογές έχουν κοινόχρηστα βίντεο και εικόνες σε χρήστες. Ως εκ τούτου, οι διακομιστές φιλοξενίας βίντεο και εικόνας πρέπει να διαμορφωθούν σύμφωνα με τις ανάγκες.
  • Ασφάλεια: Όλες αυτές οι εφαρμογές πρέπει να διασφαλίζουν υψηλό επίπεδο ασφάλειας λόγω των πληροφοριών χρήστη / προσωπικά αναγνωρίσιμων πληροφοριών των χρηστών που αποθηκεύουν. Οποιαδήποτε απόπειρα πειρατείας, το SQL Injection δεν θα πρέπει να είναι επιτυχές σε αυτές τις πλατφόρμες, καθώς μπορεί να κοστίσει απώλεια δεδομένων εκατομμυρίων πελατών.

Προβλήματα βάσει σεναρίου

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

Ε # 16) Δεδομένου ότι μια κρίσιμη επείγουσα επιδιόρθωση πρέπει να κυκλοφορήσει το συντομότερο δυνατό - Τι είδους στρατηγική δοκιμών θα έχετε;

Απάντηση: Τώρα, εδώ ο ερευνητής θέλει ουσιαστικά να καταλάβει

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

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

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

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

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

Ε # 17) Θα θυσιάζατε τις πλήρεις δοκιμές για να απελευθερώσετε ένα προϊόν γρήγορα;

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

Οι απαντήσεις σε αυτές τις ερωτήσεις πρέπει να τεκμηριώνονται με βάση τις πραγματικές εμπειρίες του υποψηφίου.

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

Q # 18) Πώς θα δημιουργούσατε στρατηγική αυτοματισμού για ένα προϊόν που δεν έχει καθόλου δοκιμές αυτοματισμού;

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

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

Για παράδειγμα, θα μπορούσατε να αναφέρετε σημεία όπως,

  • Δεδομένου ότι το προϊόν απαιτούσε εκκίνηση αυτοματισμού από το μηδέν, έχετε αρκετό χρόνο για να σκεφτείτε και να σχεδιάσετε ένα κατάλληλο πλαίσιο αυτοματισμού επιλέγοντας μια γλώσσα / τεχνολογία που οι περισσότεροι άνθρωποι είχαν τη γνώση να αποφύγουν την εισαγωγή ενός νέου εργαλείου και να αξιοποιήσουν τις υπάρχουσες γνώσεις.
  • Ξεκινήσατε με την αυτοματοποίηση των πιο βασικών λειτουργικών σεναρίων που θεωρήθηκαν P1 (χωρίς την οποία δεν μπορούσε να περάσει καμία έκδοση).
  • Σκεφτήκατε επίσης να δοκιμάσετε την απόδοση και την επεκτασιμότητα του συστήματος μέσω αυτοματοποιημένων εργαλείων δοκιμής όπως JMETER, LoadRunner κ.λπ.
  • Σκεφτήκατε να αυτοματοποιήσετε τις πτυχές ασφαλείας της εφαρμογής όπως αναφέρονται στο OWASP Πρότυπα ασφαλείας.
  • Ενσωματώσατε τις αυτοματοποιημένες δοκιμές στον αγωγό build για πρώιμα σχόλια κ.λπ.

Team Fit & Culture Fit

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

Γενικά, οι υπεύθυνοι HR και Hiring είναι αυτοί που διεξάγουν αυτόν τον γύρο.

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

Ε # 19) Πώς επιλύετε τις συγκρούσεις εντός του τρέχοντος ρόλου σας;

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

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

Μπορείτε να αναφέρετε πράγματα όπως:

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

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

Ε # 20) Τι είδους ισορροπία μεταξύ επαγγελματικής και προσωπικής ζωής περιμένετε από τον νέο ρόλο για τον οποίο θεωρείται ότι θα προσληφθείτε;

Απάντηση: Δεδομένου ότι το Hiring Manager είναι κάποιος που ξέρει τι απαιτεί ο ρόλος, πόση επιπλέον προσπάθεια μπορεί να απαιτείται κατά καιρούς, οπότε γενικά ο ερευνητής προσπαθεί να εκτιμήσει εάν οι προσδοκίες σας είναι ριζικά διαφορετικές από αυτές που ο ρόλος αναμένει.

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

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

Ε # 21) Εκτός από τη δουλειά, ποια είναι τα χόμπι σας;

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

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

Ε # 22) Πόσος χρόνος είστε διατεθειμένοι να αφιερώσετε προληπτικά την εκμάθηση νέων εργαλείων και τεχνολογιών;

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

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

συμπέρασμα

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

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

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

Καλύτερες ευχές για τη συνέντευξη SDET!

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

^