sdet interview questions
Prečítajte si tohto kompletného sprievodcu softvérovým vývojárom v testovacích rozhovoroch, aby ste poznali formát a ako odpovedať na otázky týkajúce sa rozhovorov SDET v rôznych kolách:
V tomto tutoriále sa dozvieme o niektorých často kladených otázkach týkajúcich sa pohovorov pre úlohy SDET. Uvidíme tiež všeobecne všeobecný vzorec rozhovorov a podelíme sa o niekoľko rád, ako v rozhovoroch vyniknúť.
Pre problémy s programovaním budeme v tomto výučbe používať jazyk Java. Väčšina výučbových programov SDET je však jazykovo agnostická a anketári sú všeobecne flexibilní v jazyku, ktorý si kandidát zvolí.
Čo sa dozviete:
Sprievodca prípravou rozhovoru SDET
Rozhovory SDET sú vo väčšine špičkových produktových spoločností dosť podobné spôsobu, akým sa rozhovory vedú pre vývojové roly. Je to preto, že sa tiež očakáva, že SDET budú vedieť a rozumejú zhruba všetkému, čo vývojár vie.
Líšia sa od kritérií, podľa ktorých je účastník pohovoru v SDET hodnotený. Anketári pre túto rolu hľadajú schopnosti kritického myslenia a tiež to, či má osoba, s ktorou sa vedie rozhovor, praktické skúsenosti v kódovaní a má zmysel pre kvalitu a podrobnosti.
Tu je niekoľko bodov, na ktoré by sa mal niekto, kto sa pripravuje na pohovor SDET, zamerať do veľkej miery:
ako otvárať súbory mkv v systéme Windows -
- Pretože tieto rozhovory sú väčšinou technologicko-jazykové, musia byť kandidáti ochotní naučiť sa nové technológie (a využívať existujúce zručnosti) podľa potreby.
- Mali by mať dobrú komunikáciu a tímové zručnosti, pretože role SDET v dnešnej dobe vyžadujú komunikáciu a spoluprácu na rôznych úrovniach s viacerými zainteresovanými stranami.
- Mali by mať základné znalosti o rôznych koncepciách návrhu systému, škálovateľnosti, súbežnosti, nefunkčných požiadavkách atď.
V nasledujúcich častiach sa pokúsime porozumieť všeobecnému formátu rozhovoru a niektorým vzorovým otázkam.
Formát inžiniera pre vývoj softvéru v testovacom rozhovore
Väčšina spoločností má svoj preferovaný formát rozhovorov s kandidátmi na rolu SDET, ktorá je pre tím niekedy veľmi špecifická a očakáva sa, že osoba bude vyhodnotená ako dokonalá pre tím, do ktorého je osoba najatá.
Téma rozhovorov je však spravidla založená na nasledujúcich bodoch:
- Telefonická diskusia: Konverzácia s manažérom a / alebo členmi tímu, ktorá je zvyčajne skríningovým kolom.
- Písomné kolo: S testovaním / testovaním konkrétnych otázok.
- Kolo kódovacej spôsobilosti: Jednoduché otázky týkajúce sa kódovania (jazykovo agnostické) a uchádzač je vyzvaný k napísaniu kódu na úrovni výroby.
- Pochopenie základných koncepcií rozvoja: Rovnako ako koncepty OOPS, SOLID Principles atď.
- Návrh a vývoj testovacieho automatizačného rámca
- Skriptovacie jazyky: Selén, python, javascript atď
- Diskusia a rokovania o kultúre / HR
SDET Interview Otázky a odpovede
V tejto časti rozoberieme niekoľko vzorových otázok spolu s podrobnými odpoveďami pre rôzne kategórie, ktoré požaduje väčšina produktových spoločností najímajúcich úlohy SDET.
Znalosť kódovania
V tomto kole sú uvedené jednoduché problémy s kódovaním pri písaní v jazyku, ktorý si vyberiete. Tu chce anketár posúdiť odbornosť s kódovacími konštruktmi, ako aj vybaviť veci, ako sú hraničné scenáre a kontroly nuly atď.
Anketári môžu tiež občas požiadať o napísanie jednotkových testov pre napísaný program.
Pozrime sa na niekoľko vzorových problémov.
Otázka č. 1) Napíš program na výmenu dvoch čísel bez použitia tretej (dočasnej) premennej?
Odpoveď :
Program na zámenu dvoch čísel:
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); } }Tu je výstup vyššie uvedeného útržku kódu:
Vo vyššie uvedenom útržku kódu je dôležité poznamenať, že anketár konkrétne požiadal o výmenu 2 nosov bez použitia tretej dočasnej premennej. Je tiež dôležité, aby ste pred odoslaním riešenia vždy odporúčali prejsť (alebo spustiť nasucho) kód aspoň na 2 - 3 vstupy. Skúsme pozitívne a negatívne hodnoty.
Pozitívne hodnoty: 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)Záporné hodnoty: 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)Otázka 2) Napíš program na obrátenie čísla?
Odpoveď: Teraz môže vyhlásenie o probléme spočiatku pôsobiť odstrašujúco, ale vždy je rozumné požiadať anketára o objasnenie otázok (nie však o veľa podrobností). Anketári sa môžu rozhodnúť poskytnúť radu o probléme, ale ak kandidát kladie veľa otázok, potom to tiež poukazuje na to, že uchádzač nemá dostatok času na to, aby problému dobre porozumel.
Tu sa očakáva, že kandidát tiež urobí určité predpoklady - napríklad, číslo môže byť celé číslo. Ak je vstup 345, potom by mal byť výstup 543 (čo je opačná hodnota ako 345)
Pozrime sa na útržok kódu pre toto riešenie:
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; } }Výstup pre tento program oproti vstupu : 10025 - Očakávalo by sa : 52001
Otázka 3) Napíš program na výpočet faktoriálu čísla?
Odpoveď: Faktoriál je jednou z najčastejšie kladených otázok takmer vo všetkých rozhovoroch (vrátane rozhovorov pre vývojárov)
Pri rozhovoroch s vývojármi sa viac zameriava na koncepty programovania, ako je dynamické programovanie, rekurzia atď., Zatiaľ čo z hľadiska vývoja softvéru v testovacom pohľade je dôležité zvládnuť okrajové scenáre, ako sú maximálne hodnoty, minimálne hodnoty, záporné hodnoty atď. A prístup / efektívnosť. sú dôležité, ale stávajú sa druhoradými.
Pozrime sa na program pre faktoriál využívajúci rekurziu a cyklus so spracovaním záporných čísel a vrátením pevnej hodnoty povedzme -9999 pre záporné čísla, ktoré by sa mali spracovať v programe volajúcom faktoriálnu funkciu.
Prečítajte si útržok kódu nižšie:
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); } }Pozrime sa na výstup pre - faktoriál využívajúci slučku, faktoriál využívajúci rekurziu a faktoriál záporného čísla (ktorý by vrátil predvolenú nastavenú hodnotu -9999)
Otázka 4) Napíš program a skontroluj, či má daný reťazec vyvážené zátvorky?
Odpoveď:
Prístup - Toto je mierne zložitý problém, pri ktorom sa anketár pozerá o niečo viac ako na znalosti iba kódovania konštruktov. Očakáva sa tu premyslenie a použitie vhodnej dátovej štruktúry pre daný problém.
Mnoho z vás sa môže týmito druhmi problémov cítiť vystrašených, pretože niektorí z nich ich možno nepočuli, a preto aj keď sú jednoduché, môžu znieť zložito.
Ale všeobecne pre také problémy / otázky: Napríklad v aktuálnej otázke, ak neviete, čo sú vyvážené zátvorky, môžete sa anketára veľmi dobre opýtať a potom namiesto zásahu do mŕtveho bodu pracovať na riešení.
Pozrime sa, ako pristupovať k riešeniu: Po pochopení toho, čo sú vyvážené zátvorky, môžete premýšľať o použití správnej dátovej štruktúry a potom začať písať algoritmy (kroky) skôr, ako začnete kódovať riešenie. Samotné algoritmy mnohokrát riešia veľa okrajových scenárov a poskytujú veľkú jasnosť v tom, ako bude riešenie vyzerať.
Pozrime sa na riešenie:
Vyvážené zátvorky slúžia na kontrolu daného reťazca, ktorý obsahuje zátvorky (alebo zátvorky), ktorý by mal mať rovnaký počet otváraní a zatvárania a rovnako dobre pozične štruktúrovaný. V súvislosti s týmto problémom použijeme vyvážené zátvorky ako - „()“, „[]“, „{}“ - tj. Daný reťazec môže mať akúkoľvek kombináciu týchto zátvoriek.
Upozorňujeme, že pred pokusom o problém je dobré ujasniť si, či reťazec bude obsahovať iba znaky hranatých zátvoriek alebo akékoľvek čísla atď. (Pretože by to mohlo trochu zmeniť logiku)
Príklad: Daný reťazec - „{[] {} ()} - je vyvážený reťazec, pretože je štruktúrovaný a nemá rovnakú hodnotu ako záverečná a úvodná zátvorka, ale reťazec -„ {[}] {} () “- tento reťazec - aj keď má rovnaké množstvo zátvoriek na otvorenie a zatvorenie, stále to nie je vyvážené, pretože vidíte, že bez koncovky „[“ sme zatvorili „}“ (tj. všetky vnútorné zátvorky by mali byť zatvorené pred zatvorením vonkajšej zátvorky)
Na vyriešenie tohto problému použijeme štruktúru dát v zásobníku. Ak sa chcete dozvedieť viac základných informácií o zásobníku, prečítajte si tu
Hromada je LIFO (dátová štruktúra typu Last In First Out), na svadbe si to predstavte ako hromadu / hromadu tanierov - najvyšší tanier si zoberiete, kedykoľvek ho budete používať.
Algoritmus:
# 1) Deklarujte zásobník znakov (ktorý by pojal znaky v reťazci a v závislosti od logiky ich vytlačil a vysunul).
# 2) Prejdite vstupným reťazcom a kedykoľvek
- Existuje znak úvodnej zátvorky - teda ‘[‘, {‘alebo‘ (‘- posuňte znak na Stoh.
- Existuje záverečný znak - tj. „]“, „}“, „)“ - vysuňte prvok zo zásobníka a skontrolujte, či sa zhoduje s opakom uzatváracieho znaku - tj. Ak je znak „}“, potom by ste mali čakať na zásobníku {'
- Ak sa vyskočený prvok nezhoduje s koncovou zátvorkou, reťazec nie je vyvážený a výsledky môžete vrátiť.
- Ďalej pokračujte prístupom push-and-stack (prejdite na krok 2).
- Ak je reťazec úplne prekonaný a veľkosť zásobníka je tiež nulová, potom môžeme povedať / vyvodiť, že daný reťazec je reťazec s vyváženými zátvorkami.
V tomto okamihu môžete tiež prediskutovať prístup riešenia, ktorý máte ako algoritmus, a zabezpečiť, aby anketár bol s týmto prístupom v poriadku.
Kód:
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 Výstup vyššie uvedeného úryvku kódu:
Rovnako ako v prípade našich predchádzajúcich problémov s kódovaním, je vždy dobré spustiť kód nasucho s minimálne 1–2 platnými aj 1–2 neplatnými vstupmi a zabezpečiť, aby boli všetky prípady správne spracované.
POZNÁMKA: Vždy je dobré myslieť na riešenie nahlas (nielen v mysli) - a prekvapujúco je to dôležitá vlastnosť, ktorú anketári hľadajú. Mnoho anketárov by mohlo algoritmus jednoducho ukončiť a prejsť na ďalšie vyhlásenie o probléme.
Vo vyššie uvedenom riešení kódovania pre rozhovor s vývojárom môže anketár požiadať, aby to vyriešil pomocou polí namiesto priameho hromadenia (tj pomocou poľa ako hromady), ale vo všeobecnosti ide skôr o to, aby bol koncepčne jasný a schopný zvládnuť všetky platné a neplatné vstupy.
Súvisiace s testovacím automatizačným rámcom
Táto časť rozhovoru je konkrétnejšia okolo testovania a zodpovedností za SDET. Očakávajte návrh automatizačného rámca a otázky spojené s vývojom, klady a zápory používania rôznych prístupov atď.
Pozrime sa na niektoré vzorové otázky a ich riešenia.
Otázka č. 5) Vysvetlite a navrhnite komponenty automatizačného rámca pre webovú aplikáciu?
Odpoveď: Táto otázka je trochu subjektívna a anketár má v úmysle zistiť, koľko toho kandidát vie o návrhu a vývoji rámca. Odpoveď na túto otázku pomáha anketárovi pochopiť, či môže kandidát od nuly vytvárať alebo vytvárať vlastné rámce.
Pozrime sa na niekoľko bodov, ktoré vám pomôžu štruktúrovať riešenie tejto otázky:
- Môžete hovoriť o rôznych typoch rámcov, ako napríklad - založené na údajoch, založené na kľúčových slovách, Hybridné rámce.
- Objektový model stránky na ukladanie podrobností o rôznych prvkoch na rôznych stránkach / moduloch webovej aplikácie.
- Bežné moduly ako pomocné funkcie, pomocné programy, záznamníky atď.
- Moduly prehľadov, ako napríklad generovanie správ o vykonaní testu, integrácia správ s e-mailom a plánovanie vykonania testu atď.
Odporúčané čítanie => Najobľúbenejšie rámce automatizácie testov
Otázka č. 6) Vysvetlite stratégie testovania mobilnej aplikácie?
Odpoveď: Tieto otázky sa zvyčajne kladú v závislosti od roly. Ak je úlohou predovšetkým pracovať na mobilných aplikáciách, potom je otázka relevantnejšia. Zo svojich skúseností môžete hovoriť, ak ste testovanie mobilných zariadení plánovali ako súčasť svojich súčasných alebo predchádzajúcich rolí.
Niektoré ukazovatele na štruktúrovanie odpovede na túto otázku môžu byť,
- Testovanie na zariadeniach vs emulátoroch.
- Identifikácia a uloženie objektov / prvkov na rôznych obrazovkách - Príklad: Objektový model stránky.
- Testovanie záťaže mobilnej aplikácie.
- Môžete hovoriť o rôznych typoch mobilných aplikácií, ako sú - natívne aplikácie, hybridné aplikácie a diskutovať o stratégiách / prístupoch, ktoré by ste použili na ich testovanie.
Odporúčané čítanie => Výukové programy pre testovanie mobilných aplikácií
Otázka č. 7) Navrhnúť automatizačný rámec na testovanie rozhraní REST API?
Odpoveď: Toto je opäť subjektívna otázka a môžete si položiť objasňujúce otázky, či anketár chce, aby ste vytvorili rámec pre testovanie funkčného správania API alebo nefunkčné požiadavky, ako je testovanie záťaže / výkonu.
Odpoveď môžete začať od nasledujúcich bodov:
- Komponenty rámca automatizácie API, ako je miestne nastavenie, simulované nastavenie API alebo testovanie hosteného API.
- Nástroje používané na automatizáciu API. K dispozícii sú rôzne nástroje na overenie funkčných aspektov rozhrania API založeného na REST. Niektoré také nástroje sú Postman, Rest Assured atď. Podrobné informácie o rôznych nástrojoch nájdete v našom článku tu .
- Nefunkčná automatizácia API.
- Plánované vykonávanie automatizačných testov.
- Integrácia automatizačných testov pre API.
Otázka č. 8) Otázky špecifické pre daný rámec.
Odpoveď: V závislosti od profilu, s ktorým sa vedie pohovor, môže niekedy existovať požiadavka, aby bol kandidát zdatný v určitom rámci - napr. Selén, JMeter atď.
Odporúčané čítanie => Poštár , Mockito , Specflow , Selén , JMeter
Súvisiace s testovaním
Aj keď zriedka, ale v závislosti od profilu, môžu existovať otázky týkajúce sa všeobecných testovacích postupov, pojmov a technológií - ako je závažnosť chyby, priorita, plánovanie testu, testovanie, atď. Od SDET sa očakáva, že pozná všetky koncepty manuálneho testovania a mal by byť oboznámený s dôležitou terminológiou.
V tejto časti môžete očakávať podobné otázky:
Otázka č. 9) Aké sú rôzne súčasti plánu testovania?
Odpoveď: Všeobecne sa od nich žiada, aby potvrdili základné koncepty testovania a nastavenie mysle. Tieto výrazy a dokumenty by mali poznať všetky manuálne kontroly kvality, ako aj automatizované SDET.
Môžete tu diskutovať o rôznych komponentoch plánu testov, napríklad
- Kritériá vstupu a výstupu
- Rozsah: Diskutujte o testovacích vlastnostiach, ktoré sú v rozsahu a čo všetko by sa automatizovalo - Budú to iba funkčné vlastnosti alebo nefunkčné požiadavky ako škálovateľnosť, výkon atď.
- Časové osi
- Nástroje, ktoré sa majú použiť
- Prideľovanie zdrojov atď
Odporúčané čítanie => Ako napísať dobrý testovací plán
Otázka 10) Čo definuje a rozhoduje o priorite a závažnosti chyby?
Odpoveď: Prioritu a závažnosť chyby je možné ľahko vysvetliť pomocou príkladov. Predpokladajme, že funkcia ako prihlásenie je nefunkčná a bráni používateľom v prístupe k aplikácii - potom ide o problém s vysokou prioritou a závažnosťou. Podobne môžu existovať príklady chýb s nízkou závažnosťou / vysokou prioritou a rôzne ďalšie kombinácie.
Všeobecne,
- Priorita znamená dôležitosť problému.
- Závažnosť znamená dopad, ktorý má problém na zákazníka alebo používateľa aplikácie.
Odporúčané čítanie => Priorita a závažnosť chyby
Otázka č. 11) Čo je rozdelenie podľa ekvivalencie? Ilustrujte na príklade.
Odpoveď: Ekvivalenčné rozdelenie je technika väčšinou používaná na testovanie čiernej skrinky na testovanie rôznych kombinácií vstupov proti danému poľu.
Napríklad, ak testujete obchodnú aplikáciu a chcete napísať všetky testovacie scenáre pre pole „Množstvo“ - aké by boli rôzne vstupy, ktoré by ste testovali pre toto pole?
Vzhľadom na funkčnú požiadavku by mala byť kvantita kladná celočíselná hodnota medzi 1 a 100 000. Ak chcete otestovať rôzne vstupy (platné aj neplatné), môžete mať testy pre 1 vstup z každej takejto kategórie.
- Platné hodnoty: Medzi 1 a 100 000 -> test na akúkoľvek platnú hodnotu x takú, aby x> 1 a x<100000.
- Hraničné hodnoty: Vyskúšajte povolené hraničné hodnoty, tj. 1 a 100 000.
- Neplatné hodnoty: Hodnoty, ktoré ležia mimo povoleného rozsahu, t. J. Test jednej takejto hodnoty pre x, napríklad x 100 000.
Odporúčané čítanie => Stratégia rozdelenia ekvivalencie
Súvisiace s návrhom systému
Otázky týkajúce sa návrhu systému sú zvyčajne vhodnejšie na rozhovory s vývojármi, kde sa vývojár posudzuje na základe širokého porozumenia rôznych všeobecných konceptov - ako je škálovateľnosť, dostupnosť, odolnosť voči chybám, výber databázy, vytváranie vlákien atď. Stručne povedané, budete musieť použiť celú svoju prácu skúsenosti a znalosti systémov na zodpovedanie takýchto otázok.
Ale možno máte pocit, že systém, ktorého kódovanie si vyžaduje roky skúseností a stovky vývojárov, ako môže človek odpovedať na otázku asi za 45 minút?
Odpoveď je: Očakáva sa tu posúdenie súdneho chápania kandidáta a širokého spektra vedomostí, ktoré môže uplatniť pri riešení zložitých problémov.
V dnešnej dobe sa tieto otázky začínajú hádzať aj v rozhovoroch SDET. Očakávania tu zostávajú rovnaké ako v prípade rozhovoru pre vývojárov, ale s uvoľnenými kritériami úsudku a väčšinou s barom, keď sa v závislosti od odpovede uchádzača môže uchádzač uchádzať o ďalšiu úroveň alebo sa môže posunúť na nižšiu úroveň.
Všeobecne by kandidát mal pri otázkach týkajúcich sa pohovoru o návrhu systému byť oboznámený s nasledujúcimi pojmami
- Základy operačných systémov: Stránkovanie, súborové systémy, virtuálna pamäť a fyzická pamäť atď.
- Sieťové koncepty: Komunikácia HTTP, zásobník TCP / IP, topológie sietí.
- Koncepty škálovateľnosti: Horizontálne a vertikálne mierky.
- Koncepty súbežnosti / závitovania
- Typy databáz: SQL / Žiadne databázy SQL, kedy sa má použiť aký typ databázy, výhody a nevýhody rôznych typov databáz.
- Techniky hašovania
- Základné porozumenie SPP veta, rozdelenie, rozdelenie atď.
Pozrime sa na niekoľko vzorových otázok
Otázka č. 12) Navrhnite systém na skracovanie adries URL ako a malá adresa URL ?
Odpoveď: Mnoho kandidátov nemusí vôbec vedieť o systémoch skrátenia URL. V takom prípade je v poriadku pýtať sa anketára na vyhlásenie o probléme namiesto toho, aby ste sa potápali bez porozumenia.
Predtým, ako uchádzači odpovedia na tieto otázky, mali by si ich zostaviť, napísať odrážky a potom začať diskutovať o riešení s anketárom.
Poďme si v krátkosti prediskutovať riešenie
a) Objasnite funkčné a nefunkčné požiadavky
Funkčné požiadavky: Funkčné požiadavky sú jednoducho z pohľadu zákazníka, jedná sa o systém, ktorý je napájaný veľkou (dlhou) adresou URL a výstupom by mala byť skrátená adresa URL.
Pri prístupe k skrátenej adrese URL by malo používateľa presmerovať na pôvodnú adresu URL. Napríklad - skúste skrátiť skutočnú adresu URL na webovej stránke https://tinyurl.com/, vložte vstupnú adresu URL ako www.softwaretestinghelp.com a mali by ste dostať malú adresu URL ako https://tinyurl.com/shclcqa
Nefunkčné požiadavky: Systém by mal byť výkonný z hľadiska presmerovania s latenciou milisekúnd (ako ďalší skok pre používateľa, ktorý pristupuje k pôvodnej adrese URL).
- Skrátené adresy URL by mali mať nastaviteľný čas vypršania platnosti.
- Skrátené adresy URL by nemali byť predvídateľné.
b) Odhad kapacity / prenosu
To je veľmi dôležité z hľadiska všetkých otázok týkajúcich sa návrhu systému. Odhad kapacity v podstate určuje očakávané zaťaženie, ktoré systém dostane. Vždy je dobré začať s predpokladom a diskutovať s anketárom. To je tiež dôležité z hľadiska plánovania veľkosti databázy, či je systém ťažký na čítanie alebo na zápis atď.
Urobme niekoľko čísel kapacity pre príklad skracovača adries URL.
Predpokladajme, že za deň dôjde k 100 000 nových žiadostí o skrátenie adresy URL (s pomerom čítania a zápisu 100: 1 - t. J. Na každú jednu skrátenú adresu URL budeme mať 100 žiadostí o skrátenie adresy URL)
Takže budeme mať,
100k write requests/day => 100000/(24x60x60) => 1.15 request/second 10000k read requests/day => 10000000/(24x60x60) => 1157 requests/second c) Úvahy o úložisku a pamäti
Po číslach kapacity môžeme tieto čísla extrapolovať, aby sme dostali,
- Skladovacia kapacita, ktorá by bola potrebná na uspokojenie očakávaného zaťaženia, Napríklad, môžeme naplánovať návrh úložného riešenia na podporu požiadaviek až na 1 rok.
Príklad: Ak každá skrátená adresa URL spotrebuje 50 bajtov, potom celkové údaje / úložisko, ktoré by sme vyžadovali viac ako jeden rok, by boli:
=> total write requests/day x 365 x 50 / (1024x1024) => 1740 MB - Pri plánovaní systému z pohľadu čitateľa sú dôležité úvahy o pamäti. tj pre systémy, ktoré sú náročné na čítanie - napríklad ten, ktorý sa pokúšame vytvoriť (pretože adresa URL by bola vytvorená raz, ale bola by sprístupnená viackrát).
Ťažké systémy na čítanie zvyčajne používajú medzipamäť na zvýšenie výkonnosti a vyhnú sa čítaniu z permanentného úložiska, aby ušetrili čítané I / O.
Predpokladajme, že chceme uložiť 60% našich požiadaviek na čítanie do medzipamäte, takže v priebehu roka by sme vyžadovali 60% z celkového počtu prečítaní za rok x bajtov požadovaných každou položkou
=> (60/100) x 100000 x 365 x (50/1024x1024) => 1045 MB ~ 1GBPodľa našich čísel kapacity by teda tento systém vyžadoval asi 1 GB fyzickej pamäte
d) Odhady šírky pásma
Na analýzu rýchlosti čítania a zápisu v bajtoch, ktoré by boli potrebné na vykonanie systému, sú potrebné odhady šírky pásma. Urobme odhady podľa čísel kapacity, ktoré sme zobrali.
Príklad: Ak každá skrátená adresa URL spotrebuje 50 bajtov, celková rýchlosť čítania a zápisu, ktorú by sme potrebovali, by bola uvedená nižšie:
WRITE - 1.15 x 50bytes = 57.5 bytes/s READS - 1157 x 50bytes = 57500 bytes/s => 57500 / 1024 => 56.15 Kb/s e) Návrh systému a algoritmus
Toto je v podstate hlavná obchodná logika alebo algoritmus, ktorý by sa použil na splnenie funkčných požiadaviek. V takom prípade chceme pre danú adresu URL vygenerovať jedinečné skrátené adresy URL.
Na generovanie skrátených adries URL je možné použiť rôzne prístupy:
Hašovanie: Napadá nás generovanie skrátených adries URL vytvorením hašovania vstupnej adresy URL a priradením hash kľúča ako skrátenej adrese URL.
Tento prístup môže mať problémy, ak existujú rôzni používatelia služby, a ak zadajú rovnakú adresu URL, výsledkom by bolo získanie rovnakej skrátenej adresy URL.
Vopred vytvorené skrátené šnúrkya priradené k URL, keď sa volá služba: Ďalším prístupom môže byť vrátenie preddefinovaného skráteného reťazca z fondu už vygenerovaných reťazcov.
Rozhrania API služby: Systém skracovania adries URL si môžeme predstaviť ako množinu rozhraní API založených na REST, ktoré majú nasledujúce koncové body:
- createUrl (reťazec URL, DateTime expiryTime): Tento koncový bod vytvorí a vráti skrátenú adresu URL s nastaveným trvaním platnosti, ako je uvedené vo vstupe.
- retrieveUrl (reťazec shortenedUrl): Tento koncový bod načítava adresu URL, ktorá má byť presmerovaná proti danej skrátenej adrese URL.
f) Škálovanie a súbežnosť
Zmena mierky je dôležitým aspektom z hľadiska nefunkčných požiadaviek.
Zaoberá sa tým, ako môže systém
- Stupnica pri zaťažení: Systém by mal byť schopný ladne škálovať pri zaťažení a nielen prestať pracovať po neočakávanom výkyve zaťaženia.
Odporúčané čítanie => Techniky škálovania
- Aký efektívny môže byť systém, napríklad: ak by sa systém používal so zachovanou kapacitou dlhšiu dobu, znížil by sa výkon systému alebo by zostal stabilný?
Môže existovať veľa rôznych otázok týkajúcich sa návrhu systému, ako je uvedené nižšie, ale vo všeobecnosti by všetky tieto otázky otestovali širšie pochopenie rôznych koncepcií kandidáta, o ktorých sme hovorili pri riešení systému na skrátenie adries URL.
Otázka č. 13) Navrhnite platformu videa, ako je Youtube.
Odpoveď: K tejto otázke je tiež možné pristupovať podobným spôsobom, ako sme diskutovali vyššie v otázke TinyUrl (a týka sa to takmer všetkých otázok týkajúcich sa rozhovorov o dizajne systému). Jediným rozlišujúcim faktorom by bolo rozhliadnutie / detail okolo systému, ktorý chcete navrhnúť.
Takže pre Youtube všetci vieme, že je to aplikácia na streamovanie videa a má veľa funkcií, ako napríklad umožniť používateľovi nahrávať nové videá, streamovať živé webové vysielania atď. Takže pri navrhovaní systému by ste mali používať požadované komponenty návrhu systému. V takom prípade možno budeme musieť pridať komponenty súvisiace s možnosťami streamovania videa.
Môžete diskutovať o bodoch ako:
- Skladovanie: Aký typ databázy by ste si vybrali na ukladanie video obsahu, profilov používateľov, zoznamov skladieb atď.?
- Zabezpečenie a autentifikácia / autorizácia
- Ukladanie do pamäte cache: Pretože streamovacia platforma ako youtube by mala byť výkonná, ukladanie do pamäte cache je dôležitým faktorom pri navrhovaní každého takého systému.
- Súbežnosť: Koľko používateľov môže paralelne streamovať video?
- Ďalšie funkcie platformy, ako napríklad služba odporúčania videí, ktorá odporúča / navrhuje používateľom ďalšie videá, ktoré si môžu pozrieť, atď.
Otázka č. 14) Navrhnite efektívny systém na obsluhu 6 výťahov a zabezpečte, aby osoba čakala na príchod výťahu min. ?
Odpoveď: Tieto typy otázok týkajúcich sa návrhu systému sú na nízkej úrovni a očakávali by, že kandidát najskôr premyslí výťahový systém a vymenuje všetky možné funkcie, ktoré je potrebné podporiť, a ako riešenie navrhne / vytvorí triedy a vzťahy / schémy DB.
Z pohľadu SDET by anketár očakával iba hlavné triedy, ktoré si myslíte, že by vaša aplikácia alebo systém mal, a základné funkcie by zvládol navrhované riešenie.
Pozrime sa na rôzne funkcie výťahového systému, ktoré by sa dali očakávať
Môžete položiť objasňujúce otázky ako
- Koľko je tam poschodí?
- Koľko je tam výťahov?
- Sú všetky výťahy servisné / výťahy pre cestujúcich?
- Sú všetky výťahy nakonfigurované na zastavenie na každom poschodí?
Tu sú rôzne prípady použitia, ktoré sú použiteľné pre jednoduchý výťahový systém:
Z hľadiska základných tried / objektov tohto systému môžete zvážiť:
- Užívateľ: Zaoberá sa všetkými vlastnosťami používateľa a akciami, ktoré môže s Elevator Object vykonať.
- Výťah: Výťah Špecifické vlastnosti ako výška, šírka, výťah_číslo_čísla.
- Dvere výťahu: Všetky veci týkajúce sa dverí, ako napríklad žiadne dvere, typ dverí, automatické alebo manuálne atď.
- Elevator_Button_Control: Vo výťahu sú k dispozícii rôzne tlačidlá / ovládacie prvky a rôzne stavy, v ktorých sa tieto ovládacie prvky môžu nachádzať.
Po dokončení navrhovania tried a ich vzťahov môžete hovoriť o konfigurácii schém DB.
Ďalšou dôležitou súčasťou systému Elevator je systém udalostí. Môžete hovoriť o implementácii front alebo v zložitejšom nastavení vytvárania streamov udalostí pomocou Apache Kafka, kde sa udalosti doručujú do príslušných systémov, na ktoré sa má konať.
Systém udalostí je dôležitým aspektom, pretože výťah používa súčasne viac používateľov (na rôznych poschodiach). Požiadavky používateľa by preto mali byť zaradené do poradia a obsluhované podľa nakonfigurovanej logiky v ovládačoch výťahu.
Otázka č. 15) Dizajn Instagram / Twitter / Facebook.
Odpoveď: Všetky tieto platformy svojím spôsobom súvisia, pretože umožňujú používateľom byť nejakým spôsobom prepojení a zdieľať veci prostredníctvom rôznych typov médií - napríklad správ / videí a chatov.
Pre tieto typy aplikácií / platforiem sociálnych médií by ste teda pri diskusii o navrhovaní týchto systémov (okrem toho, o čom sme hovorili o návrhu systému na skracovanie adries URL), mali zahrnúť nasledujúce body:
- Odhad kapacity: Väčšina z týchto systémov by bola ťažká na čítanie, a preto je potrebný odhad kapacity, ktorý by nám umožnil zaistiť, aby bola zabezpečená vhodná konfigurácia servera a databázy, ktorá slúži požadovanej záťaži.
- Schéma DB: Hlavné dôležité schémy DB, o ktorých by sa malo diskutovať, sú - Detaily používateľa, Vzťahy s používateľmi, Schémy správ, Schémy obsahu.
- Servery hostujúce video a obrázky: Väčšina z týchto aplikácií má zdieľané videá a obrázky medzi používateľmi. Servery Video a Image Hosting by preto mali byť nakonfigurované podľa potreby.
- Zabezpečenie: Všetky tieto aplikácie by mali zabezpečiť vysokú úroveň zabezpečenia vďaka informáciám o používateľoch / osobným identifikačným údajom používateľov, ktorých ukladajú. Akékoľvek pokusy o hacknutie, SQL Injection by na týchto platformách nemali byť úspešné, pretože by to mohlo stáť stratu údajov miliónov zákazníkov.
Problémy založené na scenároch
Problémy založené na scenároch sa všeobecne týkajú ľudí na vyššej úrovni, kde sú uvedené rôzne scenáre v reálnom čase a kandidátovi sú položené otázky o tom, ako zvládne takúto situáciu.
Otázka č. 16) Vzhľadom na to, že je potrebné čo najskôr vydať kritickú rýchlu opravu - Akú stratégiu testovania by ste mali?
Odpoveď: Teraz, tu chce anketár v podstate porozumieť
- Ako a na aké stratégie testovania si spomeniete?
- Aké pokrytie by ste urobili pre rýchlu opravu?
- Ako by ste overili rýchlu opravu po nasadení? atď.
Na zodpovedanie takýchto otázok mohli by ste použiť situácie zo skutočného života, ak by ste sa týkali problému. Mali by ste tiež spomenúť, že bez príslušného testovania by ste neboli ochotní vydať do výroby žiadny kód.
Pri kritických opravách by ste mali vždy spolupracovať s vývojárom a snažiť sa pochopiť, na ktoré oblasti by to mohlo mať vplyv, a pripraviť neprodukčné prostredie na replikáciu scenára a otestovanie opravy.
Je tu tiež dôležité spomenúť, že po nasadení budete naďalej monitorovať opravu (pomocou monitorovacích nástrojov, dashboardov, protokolov atď.), Aby ste videli akékoľvek neobvyklé správanie v produkčnom prostredí a zabezpečili, aby neexistoval negatívny vplyv opravy, ktorá je hotový.
Môžu existovať aj ďalšie otázky, ktoré majú väčšinou porozumieť perspektíve kandidáta na testovanie automatizácie, časovým harmonogramom dodania atď. (A tieto otázky sa môžu líšiť od spoločnosti k spoločnosti, ako aj od seniority roly. Tieto otázky sa spravidla kladú na úroveň vedúceho / vedúceho. role)
Otázka č. 17) Obetovali by ste úplné testovanie na rýchle vydanie produktu?
Odpoveď: Tieto otázky typicky zahŕňajú anketára, aby pochopil vaše myšlienky z pohľadu vodcovstva a čo sú veci, v ktorých by ste robili kompromisy, a boli by ste ochotní vydať buggy produkt namiesto kratšieho času.
Odpovede na tieto otázky by mali byť odôvodnené skutočnými skúsenosťami uchádzača.
Napríklad, mohli by ste spomenúť, že v minulosti ste museli zavolať, aby ste vydali nejakú rýchlu opravu, ale tá nemohla byť testovaná kvôli nedostupnosti integračného prostredia. Vydali ste ho teda kontrolovane - zavedením na menšie percento a potom sledovaním protokolov / udalostí a následným úplným zavedením atď.
Otázka č. 18) Ako by ste vytvorili stratégiu automatizácie pre produkt, ktorý nemá vôbec žiadne testy automatizácie?
Odpoveď: Tieto typy otázok sú otvorené a sú všeobecne dobrým miestom na diskusiu tak, ako chcete. Môžete tiež predviesť svoje schopnosti, vedomosti a technologické oblasti, ktoré sú vašou silnou stránkou.
Napríklad, na zodpovedanie týchto typov otázok môžete uviesť príklady automatizačnej stratégie, ktorú ste prijali pri vytváraní produktu vo svojej minulej role.
Môžete napríklad spomenúť body ako,
- Pretože produkt vyžadoval od začiatku automatizáciu, mali ste dostatok času na premyslenie a návrh vhodného automatizačného rámca výberom jazyka / technológie, o ktorej väčšina ľudí vedela, aby sa vyhla zavedeniu nového nástroja a využila existujúce znalosti.
- Začali ste automatizáciou najzákladnejších funkčných scenárov, ktoré sa považovali za P1 (bez ktorých by žiadne vydanie nemohlo prejsť).
- Tiež ste mysleli na testovanie výkonu a škálovateľnosti systému prostredníctvom automatizovaných testovacích nástrojov, ako sú JMETER, LoadRunner atď.
- Uvažovali ste o automatizácii bezpečnostných aspektov aplikácie, ktoré sú uvedené v zozname OWASP Bezpečnostné normy.
- Integrovali ste automatizované testy do potrubia zostavy pre včasnú spätnú väzbu atď.
Team Fit a kultúra Fit
Toto kolo všeobecne závisí od spoločnosti k spoločnosti. Potreba / nevyhnutnosť tohto kola je však pochopiť kandidáta z pohľadu kultúry tímu a organizácie. Účelom týchto otázok je tiež porozumieť osobnosti kandidáta a jeho prístupu k práci / ľuďom atď.
Toto kolo vo všeobecnosti vedú personalisti a náboroví manažéri.
Otázky, ktoré sa počas tohto kola zvyčajne vyskytnú, sú napríklad:
Otázka č. 19) Ako riešite konflikty v rámci vašej súčasnej role?
Odpoveď: Ďalšie vysvetlenie je: Predpokladajme, že máte konflikt so šéfom alebo priamymi členmi tímu. Aké sú kroky, ktoré podniknete na riešenie týchto konfliktov?
Pre tento typ otázok čo najviac podložte skutočnými príkladmi, ktoré sa mohli stať počas vašej kariéry v súčasných alebo predchádzajúcich organizáciách.
Môžete spomenúť veci ako:
- Radi by ste čo najskôr urovnali konflikty, ktoré by mohli vzniknúť z profesionálnych dôvodov (a nechcete kvôli tomu ovplyvniť vaše osobné vzťahy).
- Môžete spomenúť, že sa všeobecne snažíte efektívne komunikovať a individuálne hovoriť / diskutovať s danou osobou, aby ste vyriešili prípadné rozdiely / problémy.
- Môžete spomenúť, že ak by sa to začalo zhoršovať, využili by ste pomoc staršej osoby / vášho nadriadeného a získali jeho / jej podnety.
Ďalšie príklady otázok týkajúcich sa vhodnosti tímu / kultúry sú uvedené nižšie (na väčšinu z nich by sme mali odpovedať podobným prístupom, o ktorom sme hovorili pri vyššie uvedenej otázke. Hovorenie o scenároch v reálnom živote je tu kľúčové, pretože anketár to môže lepšie prepojiť, pretože dobre.
Otázka 20) Aký druh rovnováhy medzi pracovným a súkromným životom očakávate od novej úlohy, do ktorej ste považovaní za prijatého?
Odpoveď: Pretože Hiring Manager je niekto, kto vie, čo si rola vyžaduje, koľko dodatočného úsilia môže byť niekedy potrebné, takže sa anketár vo všeobecnosti snaží zistiť, či sa vaše očakávania radikálne líšia od očakávaní od role.
Predpokladajme, že povieš že sa radšej nezúčastňujete nočných stretnutí a úloha od vás očakáva, že budete mať veľkú spoluprácu medzi tímom, ktorý sedí v inom časovom pásme, môže anketár iniciovať diskusiu, že ide o očakávania od danej úlohy - Budete schopní prispôsobiť sa? atď.
Takže opäť sa jedná o obyčajný rozhovor, ale z pohľadu anketára chcú pochopiť vaše očakávania týkajúce sa vyhodnotenia vašej kandidatúry na pozíciu, na ktorú sa vedie pohovor.
Otázka č. 21) Aké sú vaše koníčky okrem práce?
Odpoveď: Tieto otázky sú čisto subjektívne a sú špecifické pre jednotlivca. Tieto otázky sú všeobecne užitočné na to, aby sa uchádzač cítil uvoľnene a ľahko a aby navodili neformálne diskusie.
Odpovede na tieto otázky môžu byť vo všeobecnosti podobné - radi čítate konkrétny žáner, máte radi hudbu, dostali ste nejaké ocenenie za dobrovoľnícke / filantropické aktivity atď. Tieto otázky sa zvyčajne kladú v rámci kola ľudských zdrojov (a je menej pravdepodobné, že vás požiada technická osoba).
Otázka č. 22) Koľko času ste ochotní venovať proaktívnemu učeniu sa nových nástrojov a technológií?
Odpoveď: Tu anketár zisťuje vašu ochotu učiť sa nové veci, ak sa na vás hodí niečo neobvyklé alebo nové. Informuje tiež anketára o tom, že ste iniciatívny? Ste ochotní investovať do seba a svojej kariéry? atď.
Pri odpovedaní na tieto otázky teda buďte úprimní a svoje odpovede podložte príkladmi - Napríklad, Môžete spomenúť, že ste sa minulý rok uchádzali o certifikáciu Java a pripravili ste sa mimo prácu tým, že ste si každý týždeň vzali niekoľko hodín.
Záver
V tomto článku sme diskutovali o softvérovom vývojovom inžinierovi v procese testovacieho pohovoru a o vzorových otázkach, ktoré sa všeobecne kladú od kandidátov v rámci rôznych organizácií a profilov. Všeobecne platí, že rozhovory SDET sú veľmi široké a sú veľmi závislé od spoločnosti k spoločnosti.
Ale procesy pohovoru sú podobné tým, ktoré existujú pre profil vývojára, s väčším dôrazom na kvalitu a automatizačné rámce.
Je dôležité si uvedomiť, že v dnešnej dobe sa spoločnosti menej zameriavajú na akýkoľvek konkrétny jazyk alebo technológiu, ale skôr na široké pochopenie pojmov a schopnosť prispôsobiť sa nástrojom / technológiám vyžadovaným spoločnosťou.
Všetko najlepšie pre váš rozhovor SDET!
Odporúčané čítanie
- Čo je SDET: Poznajte rozdiel medzi testerom a SDET
- Dotazy a odpovede na pohovor
- ETL Testovacie otázky a odpovede na pohovor
- Niektoré zložité otázky a odpovede na ručné testovanie
- Spock Interview Otázky s odpoveďami (najobľúbenejšie)
- 25 najlepších otázok a odpovedí na agilné testovacie pohovory
- Top 32 najlepších otázok a odpovedí na rozhovor o údajoch
- Top 20+ .NET Interview otázok a odpovedí
