sdet interview questions
Přečtěte si tohoto úplného průvodce Software Development Engineer v Test Interviews, abyste věděli, v jakém formátu a jak odpovídat na otázky SDET Interview, které byly položeny v různých kolech:
V tomto tutoriálu se dozvíme o některých běžně kladených dotazovacích otázkách pro role SDET. Obecně také uvidíme společný vzor rozhovorů a sdílíme několik tipů, jak v rozhovorech vyniknout.
Pro problémy s kódováním budeme v tomto výukovém programu používat jazyk Java. Většina výukových programů SDET je však jazykově agnostická a tazatelé jsou obecně flexibilní ohledně jazyka, který si kandidát zvolí.
Co se naučíte:
Průvodce přípravou rozhovoru SDET
Rozhovory SDET jsou ve většině předních produktových společností velmi podobné způsobu, jakým jsou rozhovory vedeny pro vývojové role. Je to proto, že se také očekává, že SDET budou znát a rozumět zhruba všemu, co vývojář ví.
Liší se podle kritérií, podle nichž je respondent SDET souzen. Tazatelé pro tuto roli hledají dovednosti kritického myšlení a také to, zda má dotazovaná osoba praktické zkušenosti s kódováním a má smysl pro kvalitu a detail.
Zde je několik bodů, na které by se měl někdo připravující na pohovor SDET do značné míry zaměřit:
co je bezpečnostní klíč pro bezdrátovou síť
- Vzhledem k tomu, že tyto rozhovory jsou většinou technologicky / jazykově agnostické, musí být uchazeči ochotni učit se novým technologiím (a využívat stávající dovednosti) podle potřeby.
- Měl by mít dobré komunikační a týmové dovednosti, protože role SDET dnes vyžadují komunikaci a spolupráci na různých úrovních s více zúčastněnými stranami.
- Měl by mít základní znalosti různých koncepcí návrhu systému, škálovatelnosti, souběžnosti, nefunkčních požadavků atd.
V následujících částech se pokusíme porozumět obecnému formátu rozhovoru spolu s některými ukázkovými otázkami.
Formát inženýra pro vývoj softwaru v testovacím rozhovoru
Většina společností má svůj preferovaný formát pohovoru s kandidáty na roli SDET, protože role je někdy velmi specifická pro tým a očekává se, že osoba bude hodnocena jako perfektní pro tým, pro který je osoba najata.
Téma rozhovorů je ale obecně založeno na následujících bodech:
- Telefonická diskuse: Konverzace s manažerem nebo členy týmu, což je obvykle screeningové kolo.
- Psané kolo: S testováním / testováním konkrétních otázek.
- Kolo kódovacích znalostí: Jednoduché otázky týkající se kódování (jazykově agnostické) a uchazeč je požádán o napsání kódu na úrovni výroby.
- Pochopení základních koncepcí vývoje: Stejně jako koncepty OOPS, SOLID Principles atd.
- Otestujte návrh a vývoj Framework Automation Framework
- Skriptovací jazyky: Selen, Python, Javascript atd
- Diskuse a jednání o kultuře / HR
SDET Interview Otázky a odpovědi
V této části probereme několik ukázkových otázek spolu s podrobnými odpověďmi pro různé kategorie, které požaduje většina produktových společností najímajících role SDET.
Znalost kódování
V tomto kole jsou uvedeny jednoduché problémy s kódováním pro psaní ve zvoleném jazyce. Zde chce tazatel posoudit odbornost pomocí kódovacích konstruktů a zvládnout věci, jako jsou hraniční scénáře a nulové kontroly atd.
Tazatelé mohou také občas požádat o zapsání jednotkových testů pro psaný program.
Podívejme se na některé ukázkové problémy.
Otázka č. 1) Napsat program pro výměnu 2 čísel bez použití 3. (dočasné) proměnné?
Odpovědět :
Program pro výměnu dvou čí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); } }Tady je výstup výše uvedeného fragmentu kódu:
Ve výše uvedeném fragmentu kódu je důležité si uvědomit, že tazatel konkrétně požádal o výměnu 2 nosů bez použití třetí dočasné proměnné. Je také důležité, aby před odesláním řešení bylo vždy doporučeno projít (nebo proběhnout nasucho) kód alespoň pro 2-3 vstupy. Zkusme pozitivní a negativní hodnoty.
Kladné 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) Napsat program pro obrácení čísla?
Odpovědět: Nyní může být prohlášení o problému zpočátku zastrašující, ale vždy je moudré požádat tazatele o vysvětlení (ale ne o mnoho podrobností). Tazatelé se mohou rozhodnout poskytnout nápovědu k problému, ale pokud se kandidát zeptá na spoustu otázek, pak to také poukazuje na to, že kandidát nedává dostatek času na to, aby problému dobře porozuměl.
Zde problém očekává, že kandidát učiní také určité předpoklady - například, číslo může být celé číslo. Pokud je vstup 345, pak by měl být výstup 543 (což je opačná hodnota než 345)
Podívejme se na fragment kódu pro toto řešení:
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 pro tento program proti vstupu : 10025 - Očekávalo by se : 52001
Otázka č. 3) Napište program pro výpočet faktoriálu čísla?
Odpovědět: Faktoriál je jednou z nejčastěji kladených otázek téměř u všech rozhovorů (včetně rozhovorů s vývojáři)
U rozhovorů s vývojáři se více zaměřujeme na koncepty programování, jako je dynamické programování, rekurze atd., Zatímco z hlediska vývoje softwaru v perspektivě testování je důležité zvládnout okrajové scénáře, jako jsou maximální hodnoty, minimální hodnoty, záporné hodnoty atd. A přístup / účinnost jsou důležité, ale stávají se druhotnými.
Podívejme se na program pro faktoriál pomocí rekurze a smyčky pro zpracování záporných čísel a vrácení pevné hodnoty řekněme -9999 pro záporná čísla, která by měla být zpracována v programu, který volá funkci faktoriálu.
Přečtěte si fragment kódu níže:
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); } }Podívejme se na výstup pro - faktoriál využívající smyčku, faktoriál využívající rekurzi a faktoriál záporného čísla (což by vrátilo výchozí nastavenou hodnotu -9999)
Otázka č. 4) Napište program a zkontrolujte, zda má daný řetězec vyvážené závorky?
Odpovědět:
Přístup - Jedná se o mírně složitý problém, kdy tazatel hledá o něco více než znalost pouhé kódování konstruktů. Očekává se zde přemýšlení a použití vhodné datové struktury pro daný problém.
Mnoho z vás se může cítit zastrašováno těmito typy problémů, protože někteří z nich je možná neslyšeli, a proto i když jsou jednoduché, mohou znít komplexně.
Ale obecně pro takové problémy / otázky: Například v aktuální otázce, pokud nevíte, co jsou to vyvážené závorky, můžete se tazatele velmi dobře zeptat a pak se dopracovat k řešení místo zasažení mrtvého úhlu.
Podívejme se, jak přistupovat k řešení: Po pochopení vyvážených závorek můžete přemýšlet o použití správné datové struktury a poté začít psát algoritmy (kroky), než začnete kódovat řešení. Samotné algoritmy mnohokrát řeší mnoho okrajových scénářů a poskytují velkou jasnost v tom, jak bude řešení vypadat.
Podívejme se na řešení:
Vyvážené závorky jsou pro kontrolu daného řetězce, který obsahuje závorky (nebo závorky), měl by mít stejný počet otevírání a zavírání, stejně jako pozičně dobře strukturovaný. V souvislosti s tímto problémem použijeme vyvážené závorky jako - „()“, „()“, „{}“ - tj. Daný řetězec může mít libovolnou kombinaci těchto závorek.
Pamatujte, že před pokusem o problém je dobré ujasnit si, zda řetězec bude obsahovat pouze znaky hranatých závorek nebo libovolná čísla atd. (Protože by to mohlo trochu změnit logiku)
Příklad: Daný řetězec - '{() {} ()} - je vyvážený řetězec, protože je strukturovaný a má stejnou počet zavíracích a otevíracích závorek, ale řetězec -' {(}) {} () '- tento řetězec - i když nemá stejný počet otevíracích a zavíracích závorek, stále to není vyvážené, protože vidíte, že bez uzavíracího „(“ jsme zavřeli „}“ (tj. všechny vnitřní závorky by měly být uzavřeny před uzavřením vnější závorky)
K vyřešení tohoto problému budeme používat datovou strukturu zásobníku. Pokud se chcete dozvědět více o základech zásobníku, přečtěte si tady
Zásobník je LIFO (datová struktura typu Last In First Out), představte si to jako hromádku / hromádku talířů na svatbě - nejvyšší desku si vezmete, kdykoli ji používáte.
Algoritmus:
# 1) Deklarovat zásobník znaků (který by držel znaky v řetězci a v závislosti na nějaké logice vytlačil a vysunul znaky).
# 2) Procházejte vstupním řetězcem a kdykoli
- Existuje znak úvodní závorky - tj. „(“, {„Nebo“ („- posuňte znak na Stack.
- Existuje uzavírací znak - tj. ')', '}', ')' - vysuňte prvek ze zásobníku a zkontrolujte, zda odpovídá opaku uzavíracího znaku - tj. Pokud je znak '}', pak byste měli očekávat, že na zásobníku bude ' {'
- Pokud vyskočený prvek neodpovídá závěrečné závorce, řetězec není vyvážený a můžete vrátit výsledky.
- Jinak pokračujte v přístupu zásobníku a popu (přejděte ke kroku 2).
- Pokud je řetězec zcela projet a velikost zásobníku je také nulová, pak můžeme říci / odvodit, že daný řetězec je vyvážený řetězec v závorkách.
V tomto okamžiku možná budete chtít prodiskutovat přístup řešení, který máte jako algoritmus, a zajistit, aby tazatel byl s přístupem v pořádku.
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 výše uvedeného fragmentu kódu:
Stejně jako u předchozích problémů s kódováním je vždy dobré nasucho spustit kód s alespoň 1–2 platnými i 1–2 neplatnými vstupy a zajistit, aby byly všechny případy správně zpracovány.
POZNÁMKA: Vždy je dobré řešení promyslet nahlas (nejen v mysli) - a překvapivě je to důležitá vlastnost, kterou tazatelé hledají. Spousta tazatelů mohla tento algoritmus jednoduše zrušit a přejít k dalšímu popisu problému.
Ve výše uvedeném řešení kódování, pro rozhovor s vývojářem, může tazatel požádat, aby to vyřešil pomocí polí namísto přímo zásobníku (tj. Pomocí pole jako zásobníku), ale obecně jde spíše o to, aby byl koncepčně jasný a schopný zvládnout všechny platné a neplatné vstupy.
Související s testovacím automatizačním rámcem
Tato část rozhovoru je konkrétnější ohledně testování a odpovědnosti SDET. Očekávejte návrh rámce automatizace a otázky související s vývojem, klady a zápory používání různých přístupů atd.
Podívejme se na několik vzorových otázek a řešení.
Otázka č. 5) Vysvětlete a navrhněte komponenty automatizačního rámce pro webovou aplikaci?
Odpovědět: Tato otázka je trochu subjektivní a tazatel má v úmyslu posoudit, kolik toho kandidát ví o návrhu a vývoji rámce. Odpověď na tuto otázku pomáhá tazateli pochopit, zda může kandidát vytvořit nebo vytvořit vlastní rámce od nuly.
Podívejme se na několik bodů, které vám pomohou strukturovat řešení této otázky:
- Můžete hovořit o různých typech rámců jako - Data-driven, Keyword-driven, Hybrid Framework.
- Page Object Model pro ukládání podrobností o různých prvcích na různých stránkách / modulech webové aplikace.
- Běžné moduly, jako jsou pomocné funkce, obslužné programy, protokolovací nástroje atd.
- Moduly pro vytváření zpráv, jako je generování zpráv o provádění testu, integrace zpráv s e-mailem a plánování provádění testu atd.
Doporučené čtení => Nejoblíbenější rámce automatizace testů
Otázka č. 6) Vysvětlete strategie testování pro mobilní aplikaci?
Odpovědět: Tyto otázky jsou obvykle kladeny v závislosti na roli. Pokud je hlavní úlohou hlavně pracovat na mobilních aplikacích, pak je otázka důležitější. Ze svých zkušeností můžete hovořit, pokud jste plánovali mobilní testování jako součást svých současných nebo předchozích rolí.
Některé ukazatele pro strukturování odpovědi na tuto otázku by mohly být,
- Testování na zařízeních vs emulátorech.
- Identifikace a ukládání objektů / prvků na různých obrazovkách - Příklad: Model objektu stránky.
- Zátěžové testování mobilní aplikace.
- Můžete hovořit o různých typech mobilních aplikací, jako jsou - nativní aplikace, hybridní aplikace a diskutovat o strategiích / přístupech, které byste použili k jejich testování.
Doporučené čtení => Výukové programy pro testování mobilních aplikací
Otázka č. 7) Navrhnout rámec automatizace pro testování rozhraní REST API?
Odpovědět: Toto je opět subjektivní otázka a můžete si položit objasňující otázky, zda tazatel chce, abyste vyvinuli rámec pro testování funkčního chování API nebo nefunkčních požadavků, jako je testování zátěže / výkonu.
Svou odpověď můžete začít pokrývat následující body:
- Součásti rozhraní API Automation framework, jako je místní nastavení, Mock nastavení API nebo hostované testování API.
- Nástroje používané pro automatizaci API. Po vybalení z krabice jsou k dispozici různé nástroje k ověření funkčních aspektů rozhraní API založeného na REST. Některé takové nástroje jsou Postman, Rest Assured atd. Podrobné informace o různých nástrojích najdete v našem článku tady .
- Nefunkční automatizace API.
- Plánované provádění automatizačních testů.
- Integrace automatizačních testů pro API.
Otázka č. 8) Specifické otázky rámce.
Odpovědět: Někdy v závislosti na profilu, s nímž vedete pohovor, může existovat požadavek, aby kandidát zvládl určitý rámec - např. Selen, JMeter atd.
Doporučené čtení => Listonoš , Mockito , Specflow , Selen , JMeter
Související s testováním
I když jen zřídka, ale v závislosti na profilu, mohou existovat otázky týkající se obecných testovacích postupů, pojmů a technologií - jako je závažnost chyby, priorita, plánování testů, testování testů atd. Očekává se, že SDET zná všechny koncepty ručního testování a měl by být obeznámen s důležitými terminologiemi.
V této části můžete očekávat podobné otázky:
Otázka č. 9) Jaké jsou různé součásti testovacího plánu?
Odpovědět: Obvykle se od nich požaduje ověření základních testovacích konceptů a myšlení. Tyto termíny a dokumenty jsou něco, co by měla vědět každá manuální kontrola kvality i automatizace SDET.
Zde můžete diskutovat o různých součástech testovacího plánu, například
- Kritéria pro vstup a výstup
- Rozsah: Diskutujte o testovacích funkcích, které jsou v rozsahu, a o tom, co by se automatizovalo - Budou to jen funkční funkce nebo nefunkční požadavky, jako je škálovatelnost, výkon atd.
- Časové osy
- Nástroje, které se mají použít
- Přidělování zdrojů atd
Doporučené čtení => Jak napsat dobrý testovací plán
Otázka č. 10) Co definuje a rozhoduje o prioritě a závažnosti chyby?
Odpovědět: Prioritu a závažnost defektu lze snadno vysvětlit pomocí příkladů. Předpokládejme, že funkce jako registrace je poškozená a brání uživatelům v přístupu k aplikaci - pak je to problém s vysokou prioritou a závažností. Podobně mohou existovat příklady závad s nízkou závažností / vysokou prioritou a různé další kombinace.
Obecně,
- Přednost znamená důležitost problému.
- Vážnost znamená dopad, který má problém na zákazníka nebo uživatele aplikace.
Doporučené čtení => Priorita a závažnost defektu
Otázka č. 11) Co je rozdělení ekvivalence? Ilustrujte na příkladu.
Odpovědět: Equivalence Partitioning je technika většinou používaná pro testování Black box, k testování různých kombinací vstupů proti danému poli.
Například, pokud testujete obchodní aplikaci a chcete napsat všechny testovací scénáře pro pole „Množství“ - jaké by byly různé vstupy, které byste testovali pro toto pole?
Vzhledem k funkčnímu požadavku je kvantita kladná celočíselná hodnota mezi 1 a 100 000. Chcete-li tedy otestovat různé vstupy (platné i neplatné), můžete mít testy pro 1 vstup z každé takové kategorie.
- Platné hodnoty: Mezi 1 a 100 000 -> test na jakoukoli platnou hodnotu x takovou, že x> 1 a x<100000.
- Hraniční hodnoty: Vyzkoušejte povolené hraniční hodnoty, tj. 1 a 100 000.
- Neplatné hodnoty: Hodnoty, které leží mimo povolený rozsah - tj. Test na jednu takovou hodnotu pro x, například x 100000.
Doporučené čtení => Strategie dělení na rovnocennost
Související s návrhem systému
Otázky týkající se návrhu systému jsou obvykle vhodnější pro rozhovory s vývojáři, kde se vývojář posuzuje na základě širokého porozumění různým obecným konceptům - jako je škálovatelnost, dostupnost, odolnost proti chybám, výběr databáze, vytváření vláken atd. Stručně řečeno, budete muset použít celý zkušenosti a znalosti systémů k zodpovězení těchto otázek.
Ale možná máte pocit, že systém, který vyžaduje roky zkušeností a stovky vývojářů, aby mohl kódovat, jak by mohl člověk odpovědět na otázku asi za 45 minut?
Odpověď je: Zde se očekává, že bude posouzeno porozumění kandidáta a široké spektrum znalostí, které může uplatnit při řešení složitých problémů.
V dnešní době se tyto otázky začínají házet i v rozhovorech SDET. Očekávání zde zůstává stejné jako očekávání rozhovoru pro vývojáře, ale s uvolněnými kritérii úsudku a jeho většinou se jedná o postup zvyšování baru, kde v závislosti na odpovědi kandidáta může být kandidát považován za další úroveň nebo přesunut na nižší úroveň.
Obecně platí, že pokud jde o otázky týkající se pohovoru o návrhu systému, měl by kandidát znát níže uvedené pojmy
- Základy operačních systémů: Stránkování, souborové systémy, virtuální paměť a fyzická paměť atd.
- Síťové koncepty: Komunikace HTTP, zásobník TCP / IP, topologie sítě.
- Koncepty škálovatelnosti: Horizontální a vertikální měřítko.
- Koncepty souběžnosti / podprocesů
- Typy databází: SQL / Žádné SQL databáze, kdy použít jaký typ databáze, výhody a nevýhody různých typů databází.
- Techniky hašování
- Základní porozumění VÍČKO věta, střepy, rozdělení atd.
Podívejme se na několik ukázkových otázek
Otázka č. 12) Navrhněte systém zkracování adres URL jako a malá URL ?
Odpovědět: Mnoho kandidátů možná ani neví o systémech zkracování adres URL obecně. V takovém případě je v pořádku požádat tazatele o prohlášení o problému, místo aby se potápělo bez porozumění.
Ještě než na tyto otázky odpovíte, měli by kandidáti strukturovat řešení, napsat odrážky a poté začít diskutovat o řešení s tazatelem.
Pojďme si o řešení krátce promluvit
a) Upřesněte funkční a nefunkční požadavky
Funkční požadavky: Funkční požadavek je jednoduše z pohledu zákazníka, jedná se o systém, který je napájen velkou (dlouhou) adresou URL a výstupem by měla být zkrácená adresa URL.
Při přístupu ke zkrácené adrese URL by měla uživatele přesměrovat na původní adresu URL. Například - zkuste zkrátit skutečnou adresu URL na webové stránce https://tinyurl.com/, vložte vstupní adresu URL jako www.softwaretestinghelp.com a měli byste získat malou adresu URL jako https://tinyurl.com/shclcqa
Nefunkční požadavky: Systém by měl být výkonný, pokud jde o přesměrování s latencí v milisekundách (jako další skok pro uživatele, který přistupuje k původní adrese URL).
- Zkrácené adresy URL by měly mít nastavitelnou dobu vypršení platnosti.
- Zkrácené adresy URL by neměly být předvídatelné.
b) Odhad kapacity / provozu
To je velmi důležité z pohledu všech otázek týkajících se návrhu systému. Odhad kapacity v podstatě určuje očekávané zatížení, které systém získá. Vždy je dobré začít s předpokladem a diskutovat s tazatelem. To je také důležité z hlediska plánování velikosti databáze, ať už je systém těžký pro čtení nebo těžký zápis atd.
Uděláme několik čísel kapacity pro příklad zkracovače URL.
Předpokládejme, že za den bude existovat 100 000 nových žádostí o zkrácení adresy URL (s poměrem čtení a zápisu 100: 1 - tj. Na každou 1 zkrácenou adresu URL budeme mít 100 žádostí o zkrácení oproti zkrácené adrese URL)
Takže budeme mít,
100k write requests/day => 100000/(24x60x60) => 1.15 request/second 10000k read requests/day => 10000000/(24x60x60) => 1157 requests/second c) Úvahy o úložišti a paměti
Po číslech kapacity můžeme tato čísla extrapolovat, abychom získali,
- Úložná kapacita, která by byla potřebná k uspokojení očekávané zátěže, Například, můžeme plánovat návrh řešení úložiště pro podporu požadavků až na 1 rok.
Příklad: Pokud každá zkrácená adresa URL spotřebuje 50 bajtů, pak celková data / úložiště, které bychom požadovali za jeden rok, budou:
=> total write requests/day x 365 x 50 / (1024x1024) => 1740 MB - Při plánování systému z pohledu čtenáře je důležité mít na paměti paměť. tj. pro systémy, které jsou náročné na čtení - jako ten, který se snažíme vybudovat (protože adresa URL by byla vytvořena jednou, ale přístupná několikrát).
Čtení těžkých systémů obecně používá ukládání do mezipaměti, aby se stalo výkonnějším, a vyhnout se čtení ze stálého úložiště, aby se ušetřilo čtení I / O.
Předpokládejme, že chceme uložit 60% našich požadavků na čtení do mezipaměti, takže v průběhu roku budeme vyžadovat 60% z celkového počtu přečtení za rok x bajtů požadovaných každou položkou
=> (60/100) x 100000 x 365 x (50/1024x1024) => 1045 MB ~ 1GBPodle našich čísel kapacity by tedy tento systém vyžadoval asi 1 GB fyzické paměti
d) Odhady šířky pásma
Pro analýzu rychlosti čtení a zápisu v bajtech, které by byly vyžadovány pro provedení systému, jsou nutné odhady šířky pásma. Udělejme odhady oproti číslům kapacity, která jsme vzali.
Příklad: Pokud každá zkrácená adresa URL spotřebuje 50 bajtů, pak by celková rychlost čtení a zápisu, kterou bychom potřebovali, byla níže:
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 zásadě hlavní obchodní logika nebo algoritmus, který by byl použit ke splnění funkčních požadavků. V tomto případě chceme pro danou adresu URL vygenerovat jedinečné zkrácené adresy URL.
Různé přístupy, které lze použít ke generování zkrácených adres URL, jsou:
Hašování: Můžeme uvažovat o generování zkrácených adres URL vytvořením hash vstupní adresy URL a přiřazením hash klíče jako zkrácené adresy URL.
Tento přístup může mít určité problémy, když existují různí uživatelé služby, a pokud zadají stejnou adresu URL, bude mít za následek získání stejné zkrácené adresy URL.
Předem vytvořené zkrácené řetězcea přiřazeno k URL, když je služba volána: Dalším přístupem může být vrácení předdefinovaného zkráceného řetězce z fondu již vygenerovaných řetězců.
Rozhraní API služby: Můžeme si představit systém zkracovačů adres URL jako sadu API založených na REST, které mají následující koncové body:
- createUrl (String Url, DateTime expiryTime): Tento koncový bod vytvoří a vrátí zkrácenou adresu URL s nastavenou dobou vypršení platnosti, jak je uvedeno ve vstupu.
- retrieveUrl (String shortenedUrl): Tento koncový bod načte adresu URL, která má být přesměrována proti dané zkrácené adrese URL.
f) Škálování a souběžnost
Škálování je důležitým hlediskem z hlediska nefunkčních požadavků.
Zabývá se tím, jak může systém
- Stupnice při zatížení: Systém by měl být schopen ladně škálovat při zatížení a nejen přestat pracovat po neočekávaném nárůstu zatížení.
Doporučené čtení => Techniky škálování
- Jak výkonný může být systém, například: pokud je systém používán s trvalou kapacitou po dlouhou dobu, snížil by se výkon systému nebo by zůstal stabilní?
Může existovat spousta různých otázek týkajících se návrhu systému, jak je uvedeno níže, ale obecně řečeno, všechny z nich by otestovaly širší chápání různých konceptů kandidáta, o nichž jsme diskutovali při řešení systému zkracování adres URL.
Otázka č. 13) Navrhněte platformu videa, jako je Youtube.
Odpovědět: K této otázce lze také přistupovat podobným způsobem, jak jsme diskutovali výše o otázce TinyUrl (a to platí pro téměř všechny otázky týkající se rozhovorů o návrhu systému). Jediným rozlišujícím faktorem by bylo podívat se / podrobně na systém, který chcete navrhnout.
Takže pro Youtube všichni víme, že je to aplikace pro streamování videa a má spoustu funkcí, jako je umožnit uživateli nahrávat nová videa, streamovat živé webové vysílání atd. Při navrhování systému byste tedy měli použít požadované komponenty návrhu systému. V tomto případě možná budeme muset přidat komponenty související s možnostmi streamování videa.
Můžete diskutovat o bodech jako,
- Úložný prostor: Jaký druh databáze byste zvolili pro ukládání video obsahu, uživatelských profilů, seznamů skladeb atd.?
- Zabezpečení a autentizace / autorizace
- Ukládání do mezipaměti: Protože streamovací platforma jako youtube by měla být výkonná, ukládání do mezipaměti je důležitým faktorem pro návrh jakéhokoli takového systému.
- Konkurence: Kolik uživatelů může streamovat video paralelně?
- Další funkce platformy, jako je služba doporučení videa, která uživatelům doporučuje / navrhuje další videa, která mohou sledovat atd.
Otázka č. 14) Navrhněte efektivní systém pro provoz 6 výtahů a zajistěte, aby člověk musel čekat na minimální dobu, zatímco čeká na příjezd výtahu ?
Odpovědět: Tyto typy návrhových otázek systému jsou více nízké úrovně a očekával by, že kandidát nejprve promyslí výtahový systém a vyjmenuje všechny možné funkce, které je třeba podporovat, a navrhne / vytvoří třídy a vztahy / schémata DB jako řešení.
Z pohledu SDET by tazatel očekával pouze hlavní třídy, o kterých si myslíte, že by vaše aplikace nebo systém měly, a základní funkce budou zpracovány s navrhovaným řešením.
Podívejme se na různé funkce výtahového systému, které by se daly očekávat
Můžete položit objasňující otázky jako
- Kolik podlaží je tam?
- Kolik je výtahů?
- Jsou všechny výtahy servisní / osobní výtahy?
- Jsou všechny výtahy nakonfigurovány tak, aby byly zastaveny na každém patře?
Zde jsou různé případy použití, které jsou použitelné pro jednoduchý výtahový systém:
Pokud jde o základní třídy / objekty tohoto systému, můžete zvážit:
- Uživatel: Zabývá se všemi vlastnostmi uživatele a akcemi, které může s Elevator Object provádět.
- Výtah: Výtah Specifické vlastnosti, jako je výška, šířka, číslo_výtahu.
- Dveře výtahu: Všechny věci týkající se dveří, jako žádné dveře, typ dveří, automatické nebo manuální atd.
- Elevator_Button_Control: Různá tlačítka / ovládací prvky dostupné ve výtahu a různé stavy, ve kterých tyto ovládací prvky mohou být.
Jakmile skončíte s návrhem tříd a jejich vztahů, můžete hovořit o konfiguraci schémat DB.
Další důležitou součástí systému Elevator je systém událostí. Můžete hovořit o implementaci front nebo ve složitějším nastavení vytváření streamů událostí pomocí Apache Kafka, kde jsou události doručovány do příslušných systémů, na které se má jednat.
Systém událostí je důležitým aspektem, protože výtah používá více uživatelů (na různých podlažích) současně. Požadavky uživatele by proto měly být zařazeny do fronty a obsluhovány podle nakonfigurované logiky v řadičích výtahu.
Otázka č. 15) Design Instagram / Twitter / Facebook.
Odpovědět: Všechny tyto platformy svým způsobem souvisejí, protože umožňují uživatelům být nějakým způsobem spojeni a sdílet věci prostřednictvím různých typů médií - například zpráv / videí a chatů.
U těchto typů aplikací / platforem sociálních médií byste tedy měli při projednávání návrhu těchto systémů zahrnout níže uvedené body (kromě toho, o čem jsme diskutovali při navrhování systému zkracovačů URL):
- Odhad kapacity: Většina z těchto systémů by byla těžká pro čtení, a proto je vyžadován odhad kapacity, což by nám umožnilo zajistit, aby byla zajištěna vhodná konfigurace serveru a databáze, která bude sloužit požadované zátěži.
- Schéma DB: Hlavní důležitá schémata DB, která by měla být diskutována, jsou - Údaje o uživateli, Vztahy s uživateli, Schémata zpráv, Schémata obsahu.
- Servery hostující video a obrázky: Většina z těchto aplikací má videa a obrázky sdílené mezi uživateli. Servery Video a Image Hosting by proto měly být konfigurovány podle potřeb.
- Bezpečnostní: Všechny tyto aplikace by měly zajistit vysokou úroveň zabezpečení díky informacím o uživateli / osobně identifikovatelným informacím uživatelů, které ukládají. Jakékoli pokusy o hacking, SQL Injection by na těchto platformách neměly být úspěšné, protože by to mohlo stát ztrátu dat milionů zákazníků.
Scénářové problémy
Problémy založené na scénářích jsou obecně pro lidi na vyšší úrovni, kde jsou uvedeny různé scénáře v reálném čase a kandidát je dotázán na své myšlenky o tom, jak takovou situaci vyřeší.
Otázka č. 16) Vzhledem k tomu, že je nutné co nejdříve vydat kritickou opravu hotfix - Jakou strategii testování byste měli?
Odpovědět: Nyní zde tazatel v podstatě chce pochopit
- Jak a jaký druh testovacích strategií vás napadne?
- Jaké pokrytí byste udělali pro opravu hotfix?
- Jak byste ověřili opravu hotfix po nasazení? atd.
Chcete-li odpovědět na tyto otázky, mohli byste použít situace z reálného života, pokud byste mohli souviset s problémem. Měli byste také zmínit, že bez příslušného testování byste nebyli ochotni vydat do produkce žádný kód.
U kritických oprav byste měli vždy spolupracovat s vývojářem a pokusit se pochopit, jaké oblasti by to mohlo ovlivnit, a připravit neprodukční prostředí k replikaci scénáře a otestování opravy.
Je zde také důležité zmínit, že byste i nadále sledovali opravu (pomocí monitorovacích nástrojů, řídicích panelů, protokolů atd.) Po nasazení, abyste viděli jakékoli neobvyklé chování v produkčním prostředí a zajistili, že nedojde k žádnému negativnímu dopadu opravy, která je Hotovo.
Mohou existovat i další otázky, které mají většinou pochopit perspektivu kandidáta na testování automatizace, časové harmonogramy dodávek atd. (A tyto otázky se mohou lišit společnost od společnosti, stejně jako seniorita role. Obecně jsou tyto otázky kladeny na úroveň senior / lead role)
Otázka č. 17) Obětovali byste plné testování k rychlému vydání produktu?
Odpovědět: Tyto otázky obvykle zahrnují tazatele, aby pochopil vaše myšlenky z hlediska vedení a jaké jsou věci, ve kterých byste udělali kompromis, a byli byste ochotni vydat buggy produkt místo kratšího času.
Odpovědi na tyto otázky by měly být podloženy skutečnými zkušenostmi kandidáta.
Například, můžete zmínit, že v minulosti bylo nutné zavolat, abyste vydali nějakou opravu hotfix, ale nebylo možné ji otestovat kvůli nedostupnosti integračního prostředí. Vydali jste jej tedy kontrolovaným způsobem - zavedením na menší procento a následným sledováním protokolů / událostí a následným zahájením plného zavedení atd.
Otázka č. 18) Jak byste vytvořili automatizační strategii pro produkt, který nemá vůbec žádné automatizační testy?
Odpovědět: Tyto typy otázek jsou otevřené a jsou obecně dobrým místem pro diskusi tak, jak chcete. Můžete také předvést své dovednosti, znalosti a technologické oblasti, které jsou vaší silnou stránkou.
Například, Chcete-li odpovědět na tyto typy otázek, můžete uvést příklady strategie automatizace, kterou jste přijali při vytváření produktu ve své minulé roli.
Můžete například zmínit body jako,
- Vzhledem k tomu, že produkt vyžadoval spuštění automatizace od nuly, máte dostatek času na přemýšlení a návrh vhodného automatizačního rámce výběrem jazyka / technologie, které většina lidí měla znalosti, aby se vyhnula zavedení nového nástroje a využila stávající znalosti.
- Začali jste s automatizací nejzákladnějších funkčních scénářů, které byly považovány za P1 (bez kterých by žádná verze nemohla projít).
- Přemýšleli jste také o testování výkonu a škálovatelnosti systému prostřednictvím automatizovaných testovacích nástrojů, jako jsou JMETER, LoadRunner atd.
- Přemýšleli jste o automatizaci bezpečnostních aspektů aplikace, jak je uvedeno v OWASP Bezpečnostní standardy.
- Integrovali jste automatizované testy do kanálu sestavení pro včasnou zpětnou vazbu atd.
Team Fit a kultura Fit
Toto kolo obecně závisí na společnosti. Potřeba / nutnost tohoto kola je však pochopit kandidáta z pohledu týmové a organizační kultury. Účelem těchto otázek je také porozumět osobnosti kandidáta a jeho přístupu k práci / lidem atd.
Toto kolo obecně vedou personalisté a náboroví manažeři.
Otázky, které se během tohoto kola obvykle objeví, jsou například:
Otázka č. 19) Jak řešíte konflikty ve vaší aktuální roli?
Odpovědět: Další vysvětlení je zde: Předpokládejme, že máte konflikt se svým šéfem nebo bezprostředními členy týmu, jaké kroky podniknete k vyřešení těchto konfliktů?
U tohoto typu otázek doložte co nejvíce skutečnými příklady, které by se mohly stát během vaší kariéry v současných nebo předchozích organizacích.
Můžete zmínit věci jako:
- Rádi byste co nejdříve vyřešili jakékoli konflikty, ke kterým dojde z profesionálních důvodů (a nechcete kvůli tomu ovlivnit vaše osobní vztahy).
- Můžete zmínit, že se obecně snažíte efektivně komunikovat a mluvit / diskutovat s danou osobou individuálně, abyste vyřešili jakékoli rozdíly / problémy.
- Můžete zmínit, že pokud by se věci začaly zhoršovat, využili byste pomoci nadřízeného / vašeho nadřízeného a získali jeho / její vstupy.
Další příklady otázek týkajících se vhodnosti týmu / kultury jsou uvedeny níže (na většinu z nich je třeba odpovědět podobným přístupem, o kterém jsme diskutovali výše. Mluvit o scénářích z reálného života je zde klíčové, protože tazatel to může lépe spojit, protože studna.
Otázka č. 20) Jakou rovnováhu mezi pracovním a soukromým životem očekáváte od nové role, pro kterou jste považováni za zaměstnané?
Odpovědět: Vzhledem k tomu, že náborový manažer je někdo, kdo ví, co role vyžaduje, kolik dalšího úsilí může být občas zapotřebí, takže se tazatel obecně snaží zjistit, zda se vaše očekávání radikálně liší od toho, co role očekává.
Předpokládejme, že říkáš že se nechcete raději účastnit nočních schůzek a role očekává, že budete mít zásadní spolupráci mezi týmem, který sedí v jiném časovém pásmu, může tazatel zahájit diskusi, že se jedná o očekávání od role - budete schopni přizpůsobit? atd.
Opět se tedy jedná spíše o neformální rozhovor, ale z pohledu tazatele chtějí pochopit vaše očekávání týkající se vyhodnocení vaší kandidatury na pozici, na kterou se dotazujete.
Otázka č. 21) Jaké jsou vaše koníčky kromě práce?
Odpovědět: Tyto otázky jsou čistě subjektivní a specifické pro jednotlivce a tyto otázky jsou obecně užitečné k tomu, aby se kandidát cítil uvolněně a snadno a zahájil neformální diskuse.
Obecně by odpovědi na tyto otázky mohly být podobné - rádi čtete určitý žánr, máte rádi hudbu, získali jste nějaké ocenění za nějakou dobrovolnou / filantropickou činnost atd. Tyto otázky jsou obecně kladeny v kole lidských zdrojů (a méně pravděpodobné, že vás požádá technická osoba).
Otázka č. 22) Kolik času jste ochotni proaktivně věnovat učení se novým nástrojům a technologiím?
Odpovědět: Tazatel zde měří vaši ochotu učit se nové věci, pokud na vás vrhne něco neobvyklého nebo nového. Také umožňuje tazateli vědět, že jste aktivní? Jste ochotni investovat do sebe a své kariéry? atd.
Takže při odpovídání na tyto otázky - buďte upřímní a své odpovědi podložte příklady - Například, Můžete zmínit, že jste se loni setkali s certifikací Java a připravovali se mimo práci tím, že jste si každý týden vzali několik hodin.
Závěr
V tomto článku jsme diskutovali o Software Development Engineer v procesu testovacího pohovoru a ukázkových otázkách, které jsou obecně kladeny od kandidátů napříč různými organizacemi a profily. Obecně platí, že rozhovory SDET jsou velmi široké a jsou velmi závislé na společnosti.
Procesy rozhovorů jsou však podobné tomu, co existuje pro profil vývojáře, s větším důrazem na kvalitu a automatizační rámce.
Je důležité si uvědomit, že v dnešní době se společnosti méně zaměřují na konkrétní jazyk nebo technologii, ale spíše na široké chápání konceptů a schopnost přizpůsobit se nástrojům / technologiím požadovaným společností.
Všechno nejlepší pro váš SDET rozhovor!
Doporučené čtení
- Co je SDET: Znát rozdíl mezi testerem a SDET
- Dotazy a odpovědi na pohovor
- ETL Testing Interview Otázky a odpovědi
- Některé složité otázky a odpovědi týkající se ručního testování
- Spock Interview Otázky s odpověďmi (nejoblíbenější)
- 25 nejlepších agilních testovacích otázek a odpovědí na rozhovor
- Top 32 nejlepších datastage rozhovor otázky a odpovědi
- Top 20+ .NET Interview Otázky a odpovědi
