Meniu

Întrebări și răspunsuri la interviu SDET (Ghid complet)

sdet interview questions

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Citiți acest ghid complet pentru inginerul de dezvoltare software în Test Interviews pentru a cunoaște formatul și cum să răspundeți la întrebările SDET Interview adresate în diferitele runde:

În acest tutorial, vom afla despre câteva întrebări frecvente la interviu pentru rolurile SDET. De asemenea, vom vedea, în general, modelul comun al interviurilor și vom împărtăși câteva sfaturi pentru a excela în interviuri.

Vom folosi limbajul Java pentru problemele de codare pentru acest tutorial, cu toate acestea, majoritatea tutorialelor SDET sunt agnostice de limbă, iar intervievatorii sunt, în general, flexibili în jurul limbii pe care candidatul alege să o folosească.

Întrebări și răspunsuri la interviu SDET

Ce veți învăța:

Ghid de pregătire a interviului SDET

Interviurile SDET, în majoritatea companiilor de top ale produselor, sunt destul de asemănătoare cu modul în care sunt realizate interviurile pentru roluri de dezvoltare. Acest lucru se datorează faptului că SDET-urile sunt, de asemenea, așteptate să știe și să înțeleagă în general aproape tot ceea ce știe dezvoltatorul.

Ceea ce diferă este criteriile pe baza cărora este judecat intervievatul SDET. Intervievatorii pentru acest rol caută abilități de gândire critică, precum și dacă persoana intervievată are experiență practică în codificare și are un ochi pentru calitate și detalii.

Iată câteva puncte pe care cineva care se pregătește pentru un interviu SDET ar trebui să se concentreze în mare măsură:

software de copiere DVD gratuit pentru Mac
  • Deoarece, de cele mai multe ori, aceste interviuri sunt agnostice tehnologice / lingvistice, prin urmare candidații trebuie să fie dispuși să învețe noi tehnologii (și să valorifice abilitățile existente) după cum este necesar.
  • Ar trebui să aibă bune comunicări și abilități de echipă, deoarece rolurile SDET necesită în prezent comunicarea și colaborarea la diferite niveluri cu mai multe părți interesate.
  • Ar trebui să aibă o înțelegere de bază a diferitelor concepte de proiectare a sistemului, scalabilitate, concurență, cerințe nefuncționale etc.

În secțiunile de mai jos, vom încerca să înțelegem formatul general al interviului împreună cu câteva exemple de întrebări.

Format al inginerului de dezvoltare software în interviul de testare

Majoritatea companiilor au formatul lor preferat de intervievare a candidaților pentru un rol SDET, deoarece uneori, rolul este foarte specific pentru o echipă și se așteaptă ca persoana să fie potrivită perfect pentru echipa pentru care persoana este angajată.

Dar, tema interviurilor se bazează, în general, în jurul punctelor de mai jos:

  • Discuție telefonică: Conversație cu managerul și / sau membrii echipei, care este de obicei o rundă de screening.
  • Rundă scrisă: Cu testarea / testarea carcasei întrebări specifice.
  • Runda de competență de codificare: Întrebări simple de codificare (limbă agnostică) și candidatului i se cere să scrie cod la nivel de producție.
  • Înțelegerea conceptelor de bază de dezvoltare: La fel ca conceptele OOPS, principiile SOLID etc.
  • Proiectare și dezvoltare Test Automation Framework
  • Limbi de scriptare: Seleniu, Python, Javascript etc.
  • Discuție și negocieri Cultură Fit / HR

Întrebări și răspunsuri la interviu SDET

În această secțiune, vom discuta câteva exemple de întrebări împreună cu răspunsuri detaliate, pentru diferite categorii solicitate de majoritatea companiilor de produse care angajează pentru roluri SDET.

Competență de codificare

În această rundă, sunt date probleme de codare simple pentru a scrie în limba dorită. Aici, intervievatorul dorește să evalueze competența cu structuri de codificare, precum și să gestioneze lucruri precum scenarii marginale și verificări nule etc.

Ocazional, intervievatorii ar putea cere, de asemenea, să noteze teste unitare pentru programul scris.

Să vedem câteva exemple de probleme.

Q # 1) Scrieți un program pentru a schimba 2 numere fără a utiliza a treia variabilă (temporară)?

Răspuns :

Programați pentru a schimba două numere:

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); } }

Iată rezultatul fragmentului de cod de mai sus:

output-swap2nos 8 new 1

În fragmentul de cod de mai sus, este important să rețineți că, intervievatorul a cerut în mod specific să schimbe 2 numere fără a utiliza o a treia variabilă temporară. De asemenea, este important ca, înainte de a trimite soluția, să fie întotdeauna recomandat să parcurgeți (sau să rulați în sec) codul pentru cel puțin 2-3 intrări. Să încercăm valori pozitive și negative.

Valori pozitive: X = 2, Y = 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)

Valori negative: X = -3, Y = 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)

Q # 2) Scrieți un program pentru a inversa un număr?

Răspuns: Acum, declarația problemei ar putea părea inițial intimidantă, dar este întotdeauna înțelept să cereți clarificarea întrebărilor intervievatorului (dar nu o mulțime de detalii). Intervievatorii pot alege să ofere indicii despre problemă, dar dacă candidatul pune o mulțime de întrebări, atunci indică, de asemenea, că candidatul nu acordă suficient timp pentru a înțelege bine problema.

Aici, problema se așteaptă ca un candidat să facă și câteva presupuneri - de exemplu, numărul ar putea fi un număr întreg. Dacă intrarea este 345, atunci ieșirea ar trebui să fie 543 (care este inversă a 345)

Să vedem fragmentul de cod pentru această soluție:

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; } }

Ieșire pentru acest program contra intrare : 10025 - Așteptat ar fi : 52001

output-reverse Numărul 6 nou

Q # 3) Scrieți un program pentru a calcula factorialul unui număr?

Răspuns: Factorial este una dintre cele mai frecvente întrebări în aproape toate interviurile (inclusiv interviurile cu dezvoltatorii)
Pentru interviurile cu dezvoltatorii, se pune mai mult accent pe concepte de programare precum programare dinamică, recursivitate etc., în timp ce din perspectiva inginerului de dezvoltare software în perspectiva testului, este important să se ocupe de scenariile marginale precum valorile maxime, valorile minime, valorile negative etc. și abordarea / eficiența sunt importante, dar devin secundare.

Să vedem un program pentru factorial folosind recursivitate și for-loop cu gestionarea numerelor negative și returnarea unei valori fixe de -9999 pentru numerele negative care ar trebui tratate în programul care apelează funcția factorială.
Vă rugăm să consultați fragmentul de cod de mai jos:

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); } }

Să vedem ieșirea pentru - factorial folosind bucla, factorial folosind recursivitate și factorial al unui număr negativ (care ar returna o valoare setată implicit de -9999)

output-factorial 4 nou

Q # 4) Scrieți un program pentru a verifica dacă un șir dat are paranteze echilibrate?

Răspuns:

Abordare - Aceasta este o problemă ușor complexă, în care intervievatorul arată puțin mai mult decât cunoașterea doar a constructelor de codificare. Aici, așteptarea este să gândiți și să utilizați structura de date adecvată pentru problema de față.

Mulți dintre voi s-ar putea să vă simțiți intimidați de aceste tipuri de probleme, deoarece unii dintre voi nu le-ați auzit și, prin urmare, chiar dacă sunt simple, pot părea complexe.

Dar, în general, pentru astfel de probleme / întrebări: De exemplu, în întrebarea actuală, dacă nu știți ce sunt parantezele echilibrate, puteți să întrebați foarte bine intervievatorul și apoi să lucrați spre soluție în loc să atingeți un punct mort.

Să vedem cum să abordăm o soluție: După ce înțelegeți ce sunt parantezele echilibrate, vă puteți gândi să utilizați structura corectă de date și apoi să începeți să scrieți algoritmi (pași) înainte de a începe să codificați soluția. De multe ori, algoritmii în sine rezolvă o mulțime de scenarii de margine și oferă multă claritate cu privire la aspectul soluției.

Să analizăm soluția:

Parantezele echilibrate trebuie să verifice dacă există un șir dat care conține paranteze (sau paranteze), ar trebui să aibă un număr egal de deschidere și închidere, precum și structurat pozițional. Pentru contextul acestei probleme, vom folosi paranteze echilibrate ca - ‘()’, ‘()’, ‘{}’ - adică șirul dat poate avea orice combinație a acestor paranteze.

Vă rugăm să rețineți că, înainte de a încerca problema, este bine să clarificați dacă șirul va conține doar caractere între paranteze sau orice numere etc. (deoarece acest lucru ar putea schimba puțin logica)

Exemplu: Un șir dat - '{() {} ()} - este un șir echilibrat, deoarece este structurat și are paranteze de închidere și deschidere egale, dar șir -' {(}) {} () '- acest șir - chiar dacă are paranteze de deschidere și închidere egale, acest lucru nu este încă echilibrat, deoarece puteți vedea că fără o închidere „(am închis”} (adică toate parantezele interioare ar trebui închise înainte de a închide o paranteză exterioară)

Vom folosi o structură de date stivă pentru a rezolva această problemă. Dacă doriți să aflați mai multe despre elementele de bază ale stivei, consultați Aici

Un teanc este un LIFO (tipul de structură de date Last In First Out), gândiți-vă la el ca la un teanc / teanc de farfurii la o nuntă - veți ridica farfuria cea mai de sus ori de câte ori îl folosiți.

Algoritm:

# 1) Declarați o stivă de caractere (care ar ține caracterele din șir și, în funcție de o anumită logică, împingeți și scoateți caracterele afară).

# 2) Treceți prin șirul de intrare și oricând

  • Există un caracter de paranteză de deschidere - adică ‘(‘, {‘sau‘ (‘- împingeți caracterul pe Stack.
  • Există un caracter de închidere - adică ')', '}', ')' - scoateți un element din Stack și verificați dacă se potrivește opusului caracterului de închidere - adică dacă caracterul este '}', atunci pe Stack pop ar trebui să vă așteptați ' {'
    • Dacă elementul popped nu se potrivește opus parantezelor de închidere, atunci șirul nu este echilibrat și puteți returna rezultate.
    • Altfel continuați cu abordarea prin împingere și apăsare a stivei (treceți la pasul 2).
  • Dacă șirul este parcurs complet și dimensiunea stivei este de asemenea zero, atunci putem spune / deduce că șirul dat este un șir de paranteze echilibrat.

În acest moment, ați putea dori, de asemenea, să discutați abordarea soluției pe care o aveți ca algoritm și să vă asigurați că intervievatorul este în regulă cu abordarea.

Cod:

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

Ieșirea fragmentului de cod de mai sus:

output-balanceParantheses 2 new

Așa cum am făcut pentru problemele noastre de codificare anterioare, este întotdeauna bine să rulați codul cu cel puțin 1-2 valide, precum și 1-2 intrări nevalide și să vă asigurați că toate cazurile sunt tratate corespunzător.

NOTĂ: Este întotdeauna bine să gândim soluția cu voce tare (și nu doar în mintea noastră) - și în mod surprinzător, aceasta este o trăsătură importantă pe care o caută intervievatorii. Mulți dintre intervievatori ar putea să elimine algoritmul și să treacă la următoarea declarație a problemei.

În soluția de codare de mai sus, pentru interviul cu dezvoltatorii, intervievatorul ar putea cere să o rezolve folosind matrici în loc de stivă directă (adică folosind matricea ca stivă), dar, în general, este mai mult despre a fi clar din punct de vedere conceptual și capabil să gestioneze toate intrări nevalide.

Test Automation Framework Related

Această secțiune a interviului este mai specifică în ceea ce privește responsabilitățile de testare și SDET. Așteptați întrebări legate de proiectarea cadrului de automatizare și dezvoltare, argumente pro și contra utilizării diferitelor abordări etc.

Să vedem câteva exemple de întrebări și soluții pentru același lucru.

Q # 5) Explicați și proiectați componentele cadrului de automatizare pentru o aplicație web?

Răspuns: Această întrebare este puțin subiectivă, iar intervievatorul intenționează să evalueze cât de mult știe candidatul despre proiectarea și dezvoltarea cadrului. Răspunsul la această întrebare îl ajută pe intervievator să înțeleagă dacă candidatul poate construi sau crea cadre personalizate de la zero.
Să vedem câteva puncte care vă vor ajuta să structurați soluția pentru această întrebare:

  • Puteți vorbi despre diferite tipuri de cadre cum ar fi: bazat pe date, bazat pe cuvinte cheie, cadru hibrid.
  • Model de obiecte de pagină pentru stocarea detaliilor diferitelor elemente pe diferite pagini / module ale aplicației web.
  • Module obișnuite, cum ar fi funcțiile de asistență, utilitare, logere etc.
  • Module de raportare cum ar fi generarea de rapoarte de execuție a testelor, integrarea rapoartelor cu e-mailul și programarea executării testului etc.

Lectură recomandată => Cele mai populare cadre de automatizare a testelor

Q # 6) Explicați strategiile de testare pentru o aplicație mobilă?

Răspuns: Aceste întrebări sunt de obicei puse în funcție de rol. Dacă rolul este major de a lucra pe aplicații mobile, atunci întrebarea are o relevanță mai mare. Puteți vorbi din experiența dvs. dacă ați planificat testarea mobilă ca parte a rolurilor dvs. actuale sau anterioare.

Unele indicații pentru a structura răspunsul la această întrebare ar putea fi,

  • Testarea pe dispozitive vs emulatoare.
  • Identificarea și stocarea obiectelor / elementelor pe diferite ecrane - Exemplu: Model de obiect de pagină.
  • Încărcați testarea unei aplicații mobile.
  • Puteți vorbi despre diferite tipuri de aplicații mobile cum ar fi - aplicații native, aplicații hibride și puteți discuta despre strategii / abordări pe care le-ați folosi pentru a le testa.

Lectură recomandată => Tutoriale de testare a aplicațiilor mobile

Q # 7) Proiectați un cadru de automatizare pentru testarea API-urilor REST?

Răspuns: Aceasta este din nou o întrebare subiectivă și puteți pune întrebări clarificatoare dacă intervievatorul dorește să dezvoltați un cadru pentru testarea comportamentului funcțional al API sau a cerințelor nefuncționale, cum ar fi testarea sarcinii / performanței.

Puteți începe răspunsul dvs. acoperind următoarele puncte:

  • Componentele cadrului de automatizare API, cum ar fi Configurarea locală, Configurarea falsă a API sau Testarea API găzduită.
  • Instrumente utilizate pentru automatizarea API. Există diverse instrumente disponibile pentru a valida aspectele funcționale ale unui API bazat pe REST. Unele astfel de instrumente sunt Postman, Rest Assured, etc. Pentru detalii detaliate despre diferite instrumente, puteți consulta articolul nostru Aici .
  • Automatizarea non-funcțională a API-urilor.
  • Execuția programată a testelor de automatizare.
  • Integrarea testelor de automatizare pentru API-uri.

Q # 8) Întrebări specifice cadrului.

Răspuns: Uneori, în funcție de profilul intervievat, ar putea exista o cerință pentru ca un candidat să fie competent cu un anumit cadru - ex. Seleniu, JMeter etc.

Lectură recomandată => Poştaş , Mockito , Specflow , Seleniu , JMeter

Testare legată

Deși rareori, dar în funcție de profil, ar putea exista întrebări legate de practicile generale de testare, termenii și tehnologiile - cum ar fi severitatea erorilor, prioritatea, planificarea testelor, carcasa testelor etc. Se așteaptă ca un SDET să cunoască toate conceptele de testare manuală și ar trebui să fie familiar cu terminologiile importante.

În această secțiune, vă puteți aștepta la astfel de întrebări:

Q # 9) Care sunt diferitele componente ale unui plan de testare?

Răspuns: Acestora li se cere, în general, să valideze conceptele de bază de testare și mentalitatea. Acești termeni și documente sunt ceva ce trebuie să știe fiecare QA manual, precum și SDET-urile de automatizare.
Puteți discuta aici despre diferite componente ale planului de testare, cum ar fi,

  • Criterii de intrare și ieșire
  • Domeniu de aplicare: Discutați despre caracteristicile de testare care sunt în domeniul de aplicare și despre ce ar fi automatizate toate - vor fi doar caracteristici funcționale sau cerințe nefuncționale, cum ar fi scalabilitatea, performanța etc.
  • Cronologii
  • Instrumente de utilizat
  • Alocarea resurselor etc

Lectură recomandată => Cum se scrie un plan bun de testare

Q # 10) Ce definește și decide prioritatea și severitatea unui bug?

Răspuns: Prioritatea și severitatea defectelor pot fi ușor explicate cu ajutorul exemplelor. Să presupunem că o funcție precum înscrierea este defectă și împiedică utilizatorii să acceseze aplicația - atunci este o problemă cu prioritate ridicată și severitate ridicată. În mod similar, pot exista exemple de defecte de severitate scăzută / prioritate ridicată și diverse alte combinații.

În general,

  • Prioritate semnifică importanța problemei.
  • Severitate semnifică impactul pe care problema îl are asupra clientului sau utilizatorului aplicației.

Lectură recomandată => Prioritatea și severitatea defectelor

Q # 11) Ce este partiționarea echivalenței? Ilustrați cu un exemplu.

Răspuns: Partiționarea echivalenței este o tehnică utilizată în cea mai mare parte pentru testarea cutiei negre, pentru a testa diverse combinații de intrări împotriva unui câmp dat.

De exemplu, dacă testați o aplicație de tranzacționare și doriți să scrieți toate scenariile de testare pentru câmpul „Cantitate” - care ar fi diferitele intrări pe care le-ați testa pentru acest câmp?
Având în vedere cerința funcțională, cantitatea ar trebui să fie o valoare întreagă pozitivă între 1 și 100000. Deci, pentru a testa diferite intrări (valide și invalide), puteți avea teste pentru 1 intrare din fiecare astfel de categorie.

  • Valori valide: Între 1 și 100000 -> testați orice valoare validă x astfel încât x> 1 și x<100000.
  • Valorile limită: Testați pentru valorile limită permise, adică 1 și 100000.
  • Valori nevalide: Valori care se află în afara intervalului permis - adică testați o astfel de valoare pentru x, astfel încât x 100000.

Lectură recomandată => Strategia de partiționare a echivalenței

Proiectarea sistemului este legată

Întrebările de proiectare a sistemului sunt de obicei mai potrivite pentru interviurile cu dezvoltatorii în care un dezvoltator este evaluat pe baza unei înțelegeri largi a diferitelor concepte generale - cum ar fi scalabilitatea, disponibilitatea, toleranța la erori, selecția bazei de date, threading, etc. experiență și cunoștințe de sisteme pentru a răspunde la astfel de întrebări.

Dar s-ar putea să simțiți că un sistem care necesită ani de experiență și sute de dezvoltatori pentru a codifica, cum ar putea o persoană să răspundă la întrebare în aproximativ 45 de minute?

Raspunsul este: Aici, așteptarea este de a judeca înțelegerea candidatului și spectrul larg de cunoștințe pe care el sau ea le poate aplica în timp ce rezolvă probleme complexe.

În zilele noastre, aceste întrebări încep să fie aruncate și în interviurile SDET. Aici, așteptarea rămâne aceeași cu cea a interviului cu dezvoltatorii, dar cu criterii de judecată relaxate și este în mare parte o rundă de ridicare a barelor în care, în funcție de răspunsul candidatului, un candidat poate fi luat în considerare pentru nivelul următor sau mutat la un nivel inferior.

În general, pentru întrebările de interviuri de proiectare a sistemului, candidatul ar trebui să fie familiarizat cu conceptele de mai jos

  1. Bazele sistemelor de operare: Paginarea, sistemele de fișiere, memoria virtuală și memoria fizică etc.
  2. Concepte de rețea: Comunicare HTTP, stivă TCP / IP, topologii de rețea.
  3. Concepte de scalabilitate: Scalare orizontală și verticală.
  4. Conceptele de simultanitate / filetare
  5. Tipuri de baze de date: Bazele de date SQL / Fără SQL, când se folosește ce tip de bază de date, avantaje și dezavantaje ale diferitelor tipuri de baze de date.
  6. Tehnici de hash
  7. Înțelegerea de bază a CAPAC teorema, fragmentarea, partiționarea etc.

Să vedem câteva exemple de întrebări

Q # 12) Proiectați un sistem de scurtare a adreselor URL ca un URL minuscul ?

Răspuns: Este posibil ca mulți candidați să nu știe nici măcar despre sistemele de scurtare a adreselor URL în general. În acest caz, este bine să întrebați intervievatorul despre afirmația problemei în loc să vă scufundați fără să înțelegeți.

Înainte chiar de a răspunde la astfel de întrebări, candidații ar trebui să structureze soluția și să scrie puncte glonț și apoi să înceapă să discute soluția cu intervievatorul.

Să discutăm pe scurt soluția

a) Clarificați cerințele funcționale și nefuncționale

Cerințe funcționale: Cerința funcțională este pur și simplu din perspectiva clientului, este un sistem care este alimentat cu un URL mare (lung) și rezultatul ar trebui să fie un URL scurtat.

Când se accesează adresa URL scurtată, aceasta ar trebui să redirecționeze utilizatorul către adresa URL originală. De exemplu - încercați să scurtați o adresă URL reală la https://tinyurl.com/ pagina web, alimentați o adresă URL de intrare precum www.softwaretestinghelp.com și ar trebui să obțineți o mică adresă URL precum https://tinyurl.com/shclcqa

Cerințe nefuncționale: Sistemul ar trebui să fie performant în ceea ce privește redirecționarea cu latență de milisecundă (ca un salt suplimentar pentru un utilizator care accesează adresa URL originală).

  • Adresele URL scurtate ar trebui să aibă un timp de expirare configurabil.
  • Adresele URL scurtate nu ar trebui să fie previzibile.

b) Estimarea capacității / traficului

Acest lucru este foarte important din perspectiva tuturor întrebărilor legate de proiectarea sistemului. Estimarea capacității determină în esență sarcina așteptată pe care o va obține sistemul. Este întotdeauna bine să începeți cu o presupunere și să discutați cu intervievatorul. Acest lucru este, de asemenea, important din perspectiva planificării dimensionării bazei de date, indiferent dacă sistemul este greu de citit sau greu de scris etc.

Să facem câteva numere de capacitate pentru exemplul de scurtare URL.

Să presupunem că vor exista 100k noi solicitări de scurtare a URL-ului pe zi (cu un raport de citire-scriere 100: 1 - adică pentru fiecare 1 adresă URL scurtată, vom avea 100 de cereri de citire împotriva URL-ului scurtat)

Deci vom avea,

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

c) Considerații privind stocarea și memoria

După numerele de capacitate, putem extrapola aceste numere pentru a obține,

  • Capacitatea de stocare care ar fi necesară pentru a se potrivi sarcinii preconizate, De exemplu, putem planifica să proiectăm o soluție de stocare pentru a susține solicitările de până la 1 an.
    Exemplu: Dacă fiecare adresă URL scurtată consumă 50 de octeți, atunci datele / stocarea totală pe care le-am solicita peste un an ar fi:
=> total write requests/day x 365 x 50 / (1024x1024) => 1740 MB
  • Considerațiile de memorie sunt importante pentru a planifica sistemul din perspectiva cititorului. adică pentru sistemele care sunt greu de citit - cum ar fi cel pe care încercăm să îl construim (deoarece adresa URL ar fi creată o dată, dar ar fi accesată de mai multe ori).
    Sistemele de citire grea utilizează în general cache pentru a deveni mai performante și pentru a evita citirea din stocarea permanentă pentru a economisi pe I / O citite.

Să presupunem că vrem să stocăm 60% din solicitările noastre de citire în cache, așa că, pe parcursul anului, am avea nevoie de 60% din totalul citirilor pe parcursul anului x octeți necesari pentru fiecare intrare

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

Deci, conform numerelor noastre de capacitate, acest sistem ar necesita aproximativ 1 GB de memorie fizică

d) Estimări ale lățimii de bandă

Sunt necesare estimări ale lățimii de bandă pentru a analiza viteza de citire și scriere în octeți care ar fi necesară pentru efectuarea unui sistem. Să facem estimări în funcție de numărul de capacități pe care le-am luat.

Exemplu: Dacă fiecare adresă URL scurtată consumă 50 de octeți, atunci viteza totală de citire și scriere de care am avea nevoie ar fi următoarea:

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

e) Proiectarea sistemului și algoritmul
Aceasta este în esență principala logică de afaceri sau algoritm care ar fi utilizat pentru a îndeplini cerințele funcționale. În acest caz, dorim să generăm adrese URL scurte unice pentru o anumită adresă URL.

Diferitele abordări care ar putea fi utilizate pentru a genera URL-uri scurtate sunt:

Hashing: Ne putem gândi să generăm adrese URL scurtate prin crearea unui hash al adresei URL de intrare și atribuirea cheii hash ca adresă URL scurtată.

Hashing

Această abordare ar putea avea unele probleme atunci când există utilizatori diferiți ai serviciului și, dacă introduc aceeași adresă URL, ar avea ca rezultat obținerea aceluiași URL scurtat.

Șiruri scurtate pre-createși atribuit adreselor URL atunci când este apelat serviciul: O altă abordare poate fi returnarea unui șir scurtat predefinit din grupul de șiruri deja generate.

Șiruri scurtate pre-create

API-uri de servicii: Ne putem gândi la sistemul de scurtare a adreselor URL ca la un set de API-uri bazate pe REST care au următoarele puncte finale:

  • createUrl (Strl Url, DateTime expiryTime): Acest punct final creează și returnează o adresă URL scurtată cu durata de expirare setată așa cum se specifică în intrare.
  • retrieveUrl (String shortenedUrl): Acest punct final extrage adresa URL pentru a fi redirecționată către adresa URL scurtată dată.

f) Scalare și concurență

Scalarea este un aspect important din perspectiva cerințelor nefuncționale.

Se ocupă de, cum poate sistemul

  • Scară sub sarcină: Sistemul ar trebui să fie capabil să escaladeze grațios sub sarcină și să nu oprească doar funcționarea după ce apare o creștere neașteptată a sarcinii.

Lectură recomandată => Tehnici de scalare

  • Cât de performant poate fi sistemul, de exemplu: dacă sistemul este utilizat cu o capacitate susținută pentru o lungă perioadă de timp, performanța sistemului se va degrada sau rămâne stabilă?

Pot exista o mulțime de întrebări diferite despre proiectarea sistemului, cum ar fi mai jos, dar, în general, toate acestea vor testa înțelegerea mai largă a diferitelor concepte ale candidatului despre care am discutat în soluția sistemului de scurtare a adreselor URL.

Q # 13) Proiectați o platformă video precum Youtube.

Răspuns: Această întrebare poate fi abordată, de asemenea, într-un mod similar, așa cum am discutat despre întrebarea TinyUrl de mai sus (și acest lucru se aplică aproape tuturor întrebărilor de interviuri de proiectare a sistemului). Singurul factor de diferențiere ar fi privirea / detaliile în jurul sistemului pe care doriți să îl proiectați.

Deci, pentru Youtube, știm cu toții că este o aplicație de streaming video și are o mulțime de capabilități, cum ar fi permiterea unui utilizator să încarce videoclipuri noi, să transmită în direct transmisii web etc. Deci, în timp ce proiectați sistemul, ar trebui să aplicați componentele necesare pentru proiectarea sistemului. În acest caz, s-ar putea să fie nevoie să adăugăm componente legate de capacitățile de streaming video.

Puteți discuta puncte precum,

  • Depozitare: Ce fel de bază de date ați alege pentru a stoca conținut video, profiluri de utilizator, liste de redare etc.?
  • Securitate și autentificare / autorizare
  • Memorarea în cache: Deoarece o platformă de streaming precum YouTube ar trebui să fie performantă, cache-ul este un factor important pentru proiectarea oricărui astfel de sistem.
  • Concurență: Câți utilizatori pot transmite în flux video în paralel?
  • Alte funcționalități ale platformei, cum ar fi serviciul de recomandare video, care recomandă / sugerează utilizatorilor următoarele videoclipuri pe care le pot viziona etc.

Q # 14) Proiectați un sistem eficient pentru funcționarea a 6 ascensoare și asigurați-vă că o persoană trebuie să aștepte timp min în așteptarea sosirii liftului ?

Răspuns: Aceste tipuri de întrebări de proiectare a sistemului au un nivel mai scăzut și s-ar aștepta ca candidatul să analizeze mai întâi sistemul ascensorului și să enumere toate funcțiile posibile care trebuie suportate și să proiecteze / creeze clase și relații / scheme DB ca soluție.

Din perspectiva SDET, intervievatorul s-ar aștepta doar la principalele clase pe care credeți că le-ar avea aplicația sau sistemul dvs., iar funcționalitățile de bază ar fi tratate cu soluția sugerată.

Să vedem diferite funcționalități ale sistemului de ascensoare care ar fi de așteptat

Puteți pune întrebări clarificatoare precum

  • Cate etaje sunt?
  • Câte lifturi sunt?
  • Sunt toate lifturile de serviciu / ascensoare pentru pasageri?
  • Sunt toate lifturile configurate pentru a fi oprite pe fiecare etaj?

Iată diferitele cazuri de utilizare care sunt aplicabile pentru un sistem de ascensor simplu:

design-sistem-sistem_ascensor

În ceea ce privește clasele / obiectele de bază ale acestui sistem, puteți lua în considerare:

  • Utilizator: Se ocupă de toate proprietățile unui utilizator și acțiunile pe care le poate întreprinde asupra Elevator Object.
  • Lift: Proprietăți specifice elevatorului, cum ar fi înălțimea, lățimea, numărul_serial_elevator.
  • Ușa liftului: Toate lucrurile legate de ușă, cum ar fi lipsa ușilor, tipul de ușă, automat sau manual etc.
  • Control_buton_elevator: Butoane / comenzi diferite disponibile în lift și diferite stări în care pot fi acele comenzi.

După ce ați terminat, proiectarea cursurilor și a relațiilor acestora, puteți vorbi despre configurarea schemelor DB.

O altă componentă importantă a sistemului de ascensor este sistemul de evenimente. Puteți vorbi despre implementarea cozilor sau într-o configurație mai complexă, crearea de fluxuri de evenimente folosind Apache Kafka, unde evenimentele sunt livrate către sistemele respective pentru a fi acționate.

Sistemul de evenimente este un aspect important, deoarece există mai mulți utilizatori (pe etaje diferite) care utilizează liftul în același timp. Prin urmare, solicitările utilizatorului ar trebui să fie în așteptare și să fie servite conform logicii configurate în controlerele Elevator.

Q # 15) Proiectați Instagram / Twitter / Facebook.

Răspuns: Toate aceste platforme sunt într-un fel legate, deoarece permit utilizatorilor să fie conectați într-un fel sau altul și să partajeze lucruri prin diferite tipuri de media - cum ar fi mesaje / videoclipuri și chaturi.

Deci, pentru aceste tipuri de aplicații / platforme de social media, ar trebui să includeți puncte de mai jos în timp ce discutați despre proiectarea unor astfel de sisteme (în plus față de ceea ce am discutat pentru proiectarea sistemului de scurtare a adreselor URL):

  • Estimarea capacității: Majoritatea acestor sisteme ar fi greu de citit, prin urmare este necesară estimarea capacității și ne-ar permite să ne asigurăm că este asigurată o configurație adecvată a serverului și a bazei de date pentru a servi sarcina necesară.
  • Schema DB: Principalele scheme DB importante care ar trebui discutate sunt - Detalii utilizator, relații cu utilizatorii, scheme mesaje, scheme de conținut.
  • Servere de găzduire de imagini și imagini: Majoritatea acestor aplicații au videoclipuri și imagini partajate între utilizatori. Prin urmare, serverele de găzduire de imagini și imagini ar trebui configurate conform nevoilor.
  • Securitate: Toate aceste aplicații ar trebui să asigure un nivel ridicat de securitate datorită informațiilor utilizatorului / informațiilor de identificare personală ale utilizatorilor pe care îi stochează. Orice încercare de hacking, SQL Injection nu ar trebui să aibă succes pe aceste platforme, deoarece ar putea costa pierderea datelor de milioane de clienți.

Probleme bazate pe scenarii

Problemele bazate pe scenarii sunt, în general, pentru persoanele de nivel superior, unde sunt oferite diferite scenarii în timp real și candidaților li se cere gândurile despre cum se va descurca cu o astfel de situație.

Q # 16) Având în vedere o remediere rapidă critică, trebuie lansată cât mai curând posibil - Ce fel de strategie de testare ați avea?

Răspuns: Acum, aici intervievatorul vrea în esență să înțeleagă

  • Cum și ce fel de strategii de testare vă puteți gândi?
  • Ce acoperire ați face pentru o remediere rapidă?
  • Cum ați valida remedierea rapidă după implementare? etc.

Pentru a răspunde la astfel de întrebări, ai putea folosi situații din viața reală dacă ai putea să te raportezi la problemă. De asemenea, trebuie să menționați că, fără testarea adecvată, nu ați fi dispus să eliberați niciun cod producției.

Pentru corecțiile critice, ar trebui să lucrați întotdeauna în tandem cu dezvoltatorul și să încercați să înțelegeți ce domenii ar putea avea impact și să pregătiți un mediu non-producție pentru a reproduce scenariul și a testa corecția.

De asemenea, este important să menționăm că veți continua să monitorizați remedierea (folosind instrumente de monitorizare, tablouri de bord, jurnale etc.) după implementare pentru a vedea orice comportament anormal în mediul de producție și pentru a vă asigura că nu există niciun impact negativ al remedierii care este Terminat.

S-ar putea să existe și alte întrebări, care sunt în mare parte pentru a înțelege perspectiva candidatului cu privire la testarea automatizării, termenele de livrare etc. (și aceste întrebări pot varia de la o companie la alta, precum și de vechimea rolului. În general, aceste întrebări sunt puse la nivel de senior / lead roluri)

Q # 17) Ați sacrifica testarea completă pentru a lansa rapid un produs?

Răspuns: Aceste întrebări implică de obicei intervievatorul să vă înțeleagă gândurile dintr-o perspectivă de conducere și care sunt lucrurile pe care ați compromite-o și ați fi dispus să lansați un produs buggy în loc de mai puțin timp.

Răspunsurile la aceste întrebări trebuie justificate în funcție de experiențele reale ale candidatului.

De exemplu, ați putea menționa că, în trecut, a trebuit să luați un apel pentru a elibera o remediere rapidă, dar nu a putut fi testat din cauza nedisponibilității mediului de integrare. Așa că l-ați lansat într-un mod controlat - prin lansarea la un procent mai mic, apoi ați monitorizat jurnalele / evenimentele și ați inițiat lansarea completă etc.

Î.18) Cum ați crea strategia de automatizare pentru un produs care nu are deloc teste de automatizare?

Răspuns: Aceste tipuri de întrebări sunt deschise și sunt, în general, un loc bun pentru a lua discuția așa cum doriți. De asemenea, vă puteți prezenta abilitățile, cunoștințele și domeniile tehnologice care vă reprezintă punctul forte.

De exemplu, pentru a răspunde la aceste tipuri de întrebări, puteți cita exemple de strategie de automatizare pe care ați adoptat-o ​​în timp ce construiți un produs în rolul dvs. trecut.

De exemplu, ai putea menționa puncte precum:

  • Deoarece produsul a necesitat pornirea automatizării de la zero, ați avut suficient timp să vă gândiți și să proiectați un cadru de automatizare adecvat alegând un limbaj / tehnologie pe care majoritatea oamenilor îl cunoșteau pentru a evita introducerea unui nou instrument și pentru a valorifica cunoștințele existente.
  • Ați început cu automatizarea celor mai de bază scenarii funcționale considerate a fi P1 (fără de care nu ar putea trece nicio versiune).
  • De asemenea, v-ați gândit la testarea performanței și scalabilității sistemului prin instrumente de testare automate precum JMETER, LoadRunner etc.
  • V-ați gândit să automatizați aspectele de securitate ale aplicației, așa cum sunt listate în OWASP Standarde de securitate.
  • Ați integrat testele automate în conducta de construcție pentru feedback timpuriu etc.

Echipa Fit & Culture Fit

Această rundă depinde, în general, de la companie la companie. Dar necesitatea / necesitatea acestei runde este de a înțelege candidatul din perspectiva culturii echipei și organizației. Scopul acestor întrebări este, de asemenea, de a înțelege personalitatea candidatului și abordarea lor față de muncă / oameni etc.

În general, managerii de resurse umane și angajări sunt cei care conduc această rundă.

Întrebările care apar de obicei în timpul acestei runde sunt:

Q # 19) Cum rezolvați conflictele din cadrul rolului dvs. actual?

Răspuns: O explicație suplimentară aici este: să presupunem că aveți un conflict cu șeful dvs. sau cu membrii echipei imediate, care sunt pașii pe care îi luați pentru a rezolva aceste conflicte?

Pentru acest tip de întrebări, susțineți cât de mult puteți cu exemple reale care s-ar fi putut întâmpla în cariera dvs. la organizațiile actuale sau anterioare.

Puteți menționa lucruri precum:

  • Vă place să rezolvați cât mai curând posibil orice conflicte care apar ca urmare a unor motive profesionale (și nu doriți să vă afecteze relațiile personale din cauza acestora).
  • Puteți menționa că în general încercați să comunicați eficient și să discutați / discutați individual cu persoana respectivă pentru a rezolva orice diferență / problemă.
  • Puteți menționa că dacă lucrurile încep să se înrăutățească, veți lua ajutorul unei persoane în vârstă / managerului dvs. și veți obține contribuțiile sale.

Alte exemple de întrebări de potrivire a culturii / culturii sunt mai jos (cele mai multe dintre ele ar trebui să răspundă într-o abordare similară pe care am discutat-o ​​pentru întrebarea de mai sus. A vorbi despre scenarii din viața reală este o cheie aici, întrucât intervievatorul o poate raporta într-un mod mai bun bine.

Q # 20) La ce fel de echilibru dintre muncă și viață vă așteptați de la noul rol pentru care sunteți considerat a fi angajat?

Răspuns: Deoarece Managerul de angajare este cineva care știe ce cere rolul, cât de mult efort ar putea fi necesar uneori, așa că, în general, intervievatorul încearcă să evalueze dacă așteptările dvs. sunt radical diferite de ceea ce se așteaptă rolul.

Să presupunem că spui că nu preferați să participați la întâlnirile de noapte și rolul vă așteaptă să aveți o colaborare majoră între o echipă care se află într-un fus orar diferit, atunci intervievatorul ar putea iniția o discuție că acestea sunt așteptările din rol - Veți putea adapta? etc.

Din nou, aceasta este mai degrabă o conversație întâmplătoare, dar din perspectiva intervievatorului, ei vor să înțeleagă așteptările dvs. pentru a evalua candidatura dvs. pentru funcția pentru care a fost intervievat.

Q # 21) În afară de muncă, care sunt hobby-urile tale?

Răspuns: Aceste întrebări sunt pur subiective și individuale, iar aceste întrebări sunt în general utile pentru a face candidatul să se simtă relaxat și ușor și să inițieze discuții întâmplătoare.

În general, răspunsurile la aceste întrebări ar putea fi de genul - vă place să citiți un anumit gen, vă place muzica, ați primit un premiu pentru o activitate voluntară / filantropică etc. De asemenea, aceste întrebări sunt, în general, adresate în runda HR (și mai puțin probabil să fie întrebat de o persoană tehnică).

Q # 22) Cât timp sunteți dispus să dedicați învățării noi instrumente și tehnologii în mod proactiv?

Răspuns: Aici intervievatorul vă evaluează dorința de a învăța lucruri noi dacă vi se aruncă ceva neobișnuit sau nou. De asemenea, îi permite interviului să știe că sunteți proactiv? Ești dispus să investești în tine și în cariera ta? etc.

Deci, în timp ce răspundeți la astfel de întrebări - fiți sinceri și justificați răspunsurile cu exemple - De exemplu, Ați putea menționa că ați apărut pentru o certificare Java anul trecut și v-ați pregătit în afara locului de muncă luând câteva ore în fiecare săptămână.

Concluzie

În acest articol, am discutat despre inginerul de dezvoltare software în procesul de testare a interviului și eșantionăm întrebări care sunt, în general, adresate de candidați din diferite organizații și profiluri. În general, interviurile SDET sunt de natură foarte largă și depind mult de la o companie la alta.

Dar procesele de interviu sunt similare cu ceea ce există pentru un profil de dezvoltator, cu un accent mai mare pe calitatea și cadrele de automatizare.

Este important să înțelegem că, în zilele noastre, companiile sunt mai puțin concentrate pe orice limbaj sau tehnologie specifică, dar mai mult despre o înțelegere largă a conceptelor și capacitatea de a se adapta la instrumentele / tehnologiile solicitate de companie.

Cele mai bune urări pentru interviul dvs. SDET!

Lectură recomandată

^