sdet interview questions
Прочетете това пълно ръководство за Инженер за разработка на софтуер в тестови интервюта, за да знаете формата и как да отговорите на интервютата на SDET, зададени в различните кръгове:
В този урок ще научим за някои често задавани въпроси за интервюта за ролите на SDET. Също така ще видим като цяло общия модел на интервютата и ще споделим някои съвети за превъзходство в интервютата.
Ще използваме езика Java за проблеми с кодирането в този урок, но повечето уроци по SDET са езикови агностици и интервюиращите обикновено са гъвкави около езика, който кандидатът избира да използва.
Какво ще научите:
SDET Ръководство за подготовка на интервю
Интервютата SDET в повечето от най-добрите продуктови компании са доста сходни с начина, по който се провеждат интервюта за роли в развитието. Това е така, защото се очаква също така SDET да знаят и разбират почти всичко, което разработчикът знае.
Това, което се различава, са критериите, по които се оценява интервюирания в SDET. Интервюиращите за тази роля търсят умения за критично мислене, както и дали интервюираният има практически опит в кодирането и има ли око за качество и детайли.
Ето няколко точки, върху които някой, който се подготвя за интервю за SDET, трябва да се съсредоточи до голяма степен:
най-добрият уебсайт за гледане на аниме онлайн
- Тъй като през повечето време тези интервюта са технологични / езикови агностици, следователно кандидатите трябва да са готови да усвоят нови технологии (и да използват съществуващите умения), когато и когато е необходимо.
- Трябва да има добри комуникативни и екипни умения, тъй като в днешно време ролите на SDET изискват комуникация и сътрудничество на различни нива с множество заинтересовани страни.
- Трябва да има основно разбиране на различни концепции за проектиране на системата, мащабируемост, паралелност, нефункционални изисквания и т.н.
В секциите по-долу ще се опитаме да разберем общия формат на интервюто, заедно с някои примерни въпроси.
Формат на инженер за разработка на софтуер в тестово интервю
Повечето от компаниите имат предпочитания формат за интервюиране на кандидати за ролята на SDET, както понякога, ролята е супер специфична за екип и се очаква човекът да бъде оценен като идеален за екипа, за когото е назначен.
Но темата на интервютата обикновено се основава на следните точки:
- Телефонна дискусия: Разговор с мениджъра и / или членовете на екипа, който обикновено е кръг за проверка.
- Писмен кръг: С конкретни въпроси за тестване / тестване на корпуса.
- Кръг на владеене на кодиране: Прости въпроси за кодиране (езиков агностик) и кандидатът е помолен да напише код на производствено ниво.
- Разбиране на основните концепции за развитие: Като OOPS концепции, ТВЪРДИ принципи и т.н.
- Проектиране и разработка на Framework за автоматизация на тестовете
- Езици за скриптове: Селен, Python, Javascript и др
- Culture Fit / HR дискусия и преговори
Въпроси и отговори за интервю за SDET
В този раздел ще обсъдим някои примерни въпроси, заедно с подробни отговори, за различни категории, които се задават от повечето продуктови компании, наемащи за SDET роли.
Владеене на кодирането
В този кръг са дадени прости задачи за кодиране, за да пишете на избрания език. Тук интервюиращият иска да прецени уменията с конструкции за кодиране, както и да се справи с неща като крайни сценарии и нулеви проверки и т.н.
Понякога интервюиращите могат също да поискат да запишат единични тестове за написаната програма.
Нека да видим някои примерни проблеми.
В # 1) Напишете програма за размяна на 2 числа, без да използвате третата (временна) променлива?
Отговор :
Програма за размяна на две числа:
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); } }
Ето изхода на горния кодов фрагмент:
В горния кодов фрагмент е важно да се отбележи, че интервюиращият специално е поискал да размени 2 номера, без да използва трета временна променлива. Също така е важно, преди да изпратите решението, винаги се препоръчва да преминете (или да стартирате) кода за поне 2-3 входа. Нека опитаме за положителни и отрицателни стойности.
Положителни стойности: 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)
Отрицателни стойности: 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)
В # 2) Напишете програма за обръщане на число?
Отговор: Сега изложението на проблема може първоначално да изглежда смущаващо, но винаги е разумно да поискате да изясните въпроси на интервюиращия (но не много подробности). Интервюиращите могат да изберат да дадат подсказки за проблема, но ако кандидатът зададе много въпроси, тогава той също така сочи към кандидата, който не му дава достатъчно време, за да разбере добре проблема.
Тук проблемът очаква кандидатът да направи и някои предположения - например, числото може да бъде цяло число. Ако входът е 345, тогава изходът трябва да бъде 543 (което е обратно на 345)
Нека видим кодовия фрагмент за това решение:
public class ReverseNumber { public static void main(String() args) { int num = 10025; System.out.println('Input - ' + num + ' Output:' + reverseNo(num)); } public static int reverseNo(int number) { int reversed = 0; while(number != 0) { int digit = number % 10; reversed = reversed * 10 + digit; number /= 10; } return reversed; } }
Изход за тази програма срещу вход : 10025 - Очаквано ще бъде : 52001
В # 3) Напишете програма за изчисляване на факториал на число?
Отговор: Factorial е един от най-често задаваните въпроси в почти всички интервюта (включително интервютата за разработчици)
За интервюта за разработчици, по-голям фокус е върху концепции за програмиране като динамично програмиране, рекурсия и т.н., докато от Инженера за разработка на софтуер в перспектива на теста е важно да се справят с крайните сценарии като максимални стойности, минимални стойности, отрицателни стойности и т.н. и подход / ефективност са важни, но стават вторични.
Нека видим програма за факториал, използваща рекурсия и for-loop с обработка на отрицателни числа и връщане на фиксирана стойност от -9999 за отрицателни числа, която трябва да се обработва в програмата, извикваща факториалната функция.
Моля, обърнете се към кодовия фрагмент по-долу:
public class Factorial { public static void main(String() args) { System.out.println('Factorial of 5 using loop is:' + factorialWithLoop(5)); System.out.println('Factorial of 10 using recursion is:' + factorialWithRecursion(10)); System.out.println('Factorial of negative number -100 is:' + factorialWithLoop(-100)); } public static long factorialWithLoop(int n) { if(n <0) { System.out.println('Negative nos can't have factorial'); return -9999; } long fact = 1; for (int i = 2; i <= n; i++) { fact = fact * i; } return fact; } public static long factorialWithRecursion(int n) { if(n < 0) { System.out.println('Negative nos can't have factorial'); return -9999; } if (n <= 2) { return n; } return n * factorialWithRecursion(n - 1); } }
Нека да видим изход за - факториал, използващ цикъла, факториал, използващ рекурсия и факториал на отрицателно число (което би върнало зададена стойност по подразбиране -9999)
В # 4) Напишете програма, за да проверите дали даден низ има балансирани скоби?
Отговор:
Приближаване - Това е малко сложен проблем, при който интервюиращият търси малко повече от знания за просто кодиране на конструкции. Тук очакването е да се мисли и използва подходящата структура от данни за разглеждания проблем.
Много от вас може да се почувстват уплашени от този тип проблеми, тъй като някои от вас може да не са ги чували и следователно дори да са прости, те може да звучат сложно.
Но обикновено за такива проблеми / въпроси: Например, в текущия въпрос, ако не знаете какво са балансираните скоби, можете много добре да попитате интервюиращия и след това да работите за решението, вместо да удряте сляпо място.
Нека да видим как да подходим към решение: След като разберете какво са балансираните скоби, можете да помислите за използването на правилната структура на данните и след това да започнете да пишете алгоритми (стъпки), преди да започнете да кодирате решението. Много пъти самите алгоритми решават много крайни сценарии и дават много яснота как ще изглежда решението.
Нека да разгледаме решението:
Балансираните скоби трябва да проверят за даден низ, който съдържа скоби (или скоби), трябва да имат еднакъв брой отваряне и затваряне, както и позиционно добре структурирани. За контекста на този проблем ще използваме балансирани скоби като - ‘()’, ‘()’, ‘{}’ - т.е. даден низ може да има всяка комбинация от тези скоби.
Моля, обърнете внимание, че преди да опитате проблема, добре е да изясните дали низът ще съдържа само скобите или някакви числа и т.н. (тъй като това може да промени логиката малко)
Пример: Даден низ - '{() {} ()} - е балансиран низ, тъй като е структуриран и има равен брой затварящи и отварящи скоби, но низ -' {(}) {} () '- този низ - въпреки че има равен брой отварящи и затварящи скоби, това все още не е балансирано, защото можете да видите, че без затваряне '(' ние затворихме '}' (т.е. всички вътрешни скоби трябва да бъдат затворени преди затваряне на външна скоба)
За да разрешим този проблем, ще използваме структура от данни на стека. Ако искате да научите повече за основите на стека, моля, направете справка тук
Стекът е LIFO (тип структура от данни „Last In First Out“), помислете за него като за стек / купчина чинии на сватба - ще вземете най-горната плоча, когато я използвате.
Алгоритъм:
# 1) Декларирайте стека от символи (който ще съдържа символите в низа и в зависимост от някаква логика изтласква и изскача символите навън).
# 2) Преминаване през входния низ и винаги
- Има знак за отваряща скоба - т.е. ‘(‘, {‘или‘ (‘- натиснете знака в стека.
- Има затварящ символ - т.е. ')', '}', ')' - извадете елемент от Stack и проверете дали съвпада с обратното на затварящия символ - т.е. ако символът е '}' тогава в Stack pop трябва да очаквате ' {'
- Ако изскачащият елемент не съответства на затварящите скоби, тогава низът не е балансиран и можете да върнете резултатите.
- В противен случай продължете с подхода на стека и натиснете (преминете към стъпка 2).
- Ако низът е обходен изцяло и размерът на стека също е нула, тогава можем да кажем / заключим, че даденият низ е балансиран низ в скоби.
На този етап може да искате да обсъдите подхода за решение, който имате като алгоритъм, и да се уверите, че интервюиращият е добре с подхода.
Код:
import java.util.Stack; public class BalancedParanthesis { public static void main(String() args) { final String input1 = '{()}'; System.out.println('Checking balanced paranthesis for input:' + input1); if (isBalanced(input1)) { System.out.println('Given String is balanced'); } else { System.out.println('Given String is not balanced'); } } /** * function to check if a string has balanced parentheses or not * @param input_string the input string * @return if the string has balanced parentheses or not */ private static boolean isBalanced(String input_string) { Stack stack = new Stack(); for (int i = 0; i Резултатът от горния кодов фрагмент:
Както направихме за предишните ни проблеми с кодирането, винаги е добре да стартирате кода на сухо с поне 1-2 валидни, както и 1-2 невалидни входа и да се уверите, че всички случаи са обработени по подходящ начин.
ЗАБЕЛЕЖКА: Винаги е добре да измислите решението на глас (и не само в ума) - и изненадващо това е важна черта, която търсят интервюиращите. Много интервюиращи биха могли просто да премахнат алгоритъма и да преминат към следващото изявление на проблема.
В горното решение за кодиране за интервюто за разработчици интервюиращият може да поиска да го реши с помощта на масиви вместо директно стека (т.е. използване на масив като стек), но като цяло става дума за това да бъде концептуално ясен и да може да се справи с всички валидни и невалидни входове.
Свързани с тестовата рамка за автоматизация
Този раздел на интервюто е по-специфичен около тестването и отговорностите на SDET. Очаквайте проекти за рамка за автоматизация и свързани с развитието въпроси, плюсове и минуси на използването на различни подходи и т.н.
Нека да видим няколко примерни въпроса и решения за същото.
В # 5) Обяснете и проектирайте компонентите на рамката за автоматизация за уеб приложение?
Отговор: Този въпрос е малко субективен и интервюиращият възнамерява да прецени доколко кандидатът знае за рамковия дизайн и разработка. Отговорът на този въпрос помага на интервюиращия да разбере дали кандидатът може да изгради или създаде персонализирани рамки от нулата.
Нека да видим няколко точки, които биха ви помогнали да структурирате решението на този въпрос:
- Можете да говорите за различни видове рамки като - управлявани от данни, управлявани от ключови думи, хибридни рамки.
- Page Object Model за съхраняване на подробности за различни елементи на различни страници / модули на уеб приложението.
- Общи модули като помощни функции, помощни програми, регистратори и др.
- Модули за отчитане като генериране на отчети за изпълнение на теста, интегриране на отчети с имейл и планиране на изпълнение на теста и др.
Препоръчително четене => Най-популярните рамки за автоматизация на тестове
В # 6) Обяснете стратегиите за тестване на мобилно приложение?
Отговор: Тези въпроси обикновено се задават в зависимост от ролята. Ако ролята е главно да работи върху мобилни приложения, тогава въпросът има по-голямо значение. Можете да говорите от своя опит, ако сте планирали мобилно тестване като част от текущата или предишната си роля.
Някои насоки за структуриране на отговора на този въпрос могат да бъдат,
- Тестване на устройства срещу емулатори.
- Идентифициране и съхраняване на обекти / елементи на различни екрани - Пример: Модел на обект на страница.
- Тестване на натоварване на мобилно приложение.
- Можете да говорите за различни видове мобилни приложения, като - естествени приложения, хибридни приложения, и да обсъждате стратегии / подходи, които бихте използвали, за да ги тествате.
Препоръчително четене => Уроци за тестване на мобилни приложения
В # 7) Проектиране на рамка за автоматизация за тестване на REST API?
Отговор: Това отново е субективен въпрос и можете да зададете уточняващи въпроси дали интервюиращият иска да разработите рамка за тестване на функционално поведение на API или нефункционални изисквания като тестване на натоварване / производителност.
Можете да започнете отговора си по следните точки:
- Компоненти на рамката за автоматизация на API като Local setup, Mock setup of API или Hosted API Testing.
- Инструменти, използвани за API автоматизация. Налични са различни инструменти, които да потвърдят функционалните аспекти на REST-базиран API. Някои такива инструменти са Postman, Rest Assured и др. За подробни подробности за различни инструменти можете да се обърнете към нашата статия тук .
- Нефункционална автоматизация на API.
- Планово изпълнение на тестове за автоматизация.
- Интегриране на тестове за автоматизация за API.
В # 8) Въпроси, специфични за рамката.
Отговор: Понякога в зависимост от интервюирания профил може да има изискване кандидатът да бъде опитен с определена рамка - напр. Селен, JMeter и др.
Препоръчително четене => Пощальон , Мокито , Specflow , Селен , JMeter
Свързани с тестване
Макар и рядко, но в зависимост от профила, може да има въпроси около общи практики за тестване, термини и технологии - като сериозност на грешките, приоритет, планиране на теста, корпус на теста и др. Очаква се SDET да знае всички концепции за ръчно тестване и трябва да е запознат с важните терминологии.
В този раздел можете да очаквате въпроси като тези:
В # 9) Кои са различните компоненти на тестовия план?
Отговор: От тях обикновено се иска да валидират основните концепции за тестване и начин на мислене. Тези термини и документи са нещо, което всеки ръчен QA, както и SDET за автоматизация трябва да знаят.
Тук можете да обсъдите различни компоненти на тестовия план като,
- Критерии за влизане и излизане
- Обхват: Обсъдете тестовите функции, които са в обхвата и какво всичко ще бъде автоматизирано - ще бъдат ли само функционални характеристики или нефункционални изисквания като мащабируемост, производителност и т.н.
- Срокове
- Инструменти, които да се използват
- Разпределение на ресурси и др
Препоръчително четене => Как да напиша добър план за тест
В # 10) Какво определя и решава приоритета и тежестта на грешката?
Отговор: Приоритетът и тежестта на дефектите могат лесно да бъдат обяснени с помощта на примери. Да предположим, че функция като регистрация е повредена и пречи на потребителите да имат достъп до приложението - тогава това е проблем с висок приоритет и сериозност. По същия начин може да има примери за дефекти с ниска тежест / висок приоритет и различни други комбинации.
Общо взето,
- Приоритет означава важността на въпроса.
- Тежест означава въздействието, което проблемът оказва върху клиента или потребителя на приложението.
Препоръчително четене => Приоритет и тежест на дефектите
В # 11) Какво е разделяне на еквивалентност? Илюстрирайте с пример.
Отговор: Разделянето на еквивалентността е техника, използвана най-вече за тестване на Черната кутия, за да се тестват различни комбинации от входове срещу дадено поле.
Например, ако тествате приложение за търговия и искате да напишете всички тестови сценарии за полето „Количество“ - какви биха били различните входове, които бихте тествали за това поле?
Като се има предвид функционалното изискване количеството трябва да е положително цяло число между 1 и 100000. Така че, за да тествате различни входове (както валидни, така и невалидни), можете да имате тестове за 1 вход от всяка такава категория.
- Валидни стойности: Между 1 и 100000 -> тест за всяка валидна стойност x такава, че x> 1 и x<100000.
- Гранични стойности: Тест за допустимите гранични стойности, т.е. 1 & 100000.
- Невалидни стойности: Стойности, които са извън допустимия диапазон - т.е. тествайте за една такава стойност за x, такава че x 100000.
Препоръчително четене => Стратегия за разделяне на еквивалентност
Свързани със системния дизайн
Въпросите за системния дизайн обикновено са по-подходящи за интервюта за разработчици, където разработчикът се оценява на широко разбиране на различни общи понятия - като мащабируемост, наличност, толерантност към грешки, избор на база данни, резби и др. Накратко, ще трябва да използвате целия си опит и системни познания за отговор на такива въпроси.
Но може би се чувствате, че система, която отнема години опит и стотици разработчици, за да кодира, как човек може да отговори на въпроса за около 45 минути?
Отговорът е: Тук очакването е да се прецени разбирането на кандидата и широкия спектър от знания, които той или тя може да приложи, докато решава сложни проблеми.
В днешно време тези въпроси започват да се хвърлят и в интервюта на SDET. Тук очакванията остават същите като на интервюто за разработчици, но с облекчени критерии за преценка и най-вече кръг за повишаване на летвата, където в зависимост от отговора на кандидата кандидат може да бъде разгледан за следващо ниво или да бъде преместен на по-ниско ниво.
Като цяло, при въпроси за интервю за проектиране на система, кандидатът трябва да е запознат с концепциите по-долу
- Основи на операционните системи: Пейджинг, файлови системи, виртуална памет и физическа памет и др.
- Концепции за работа в мрежа: HTTP комуникация, TCP / IP стек, мрежови топологии.
- Концепции за мащабируемост: Хоризонтално и вертикално мащабиране.
- Концепции за съвпадение / резба
- Типове бази данни: SQL / Няма SQL бази данни, кога да се използва какъв тип база данни, предимства и недостатъци на различните видове бази данни.
- Техники за хеширане
- Основно разбиране на ШАПКА С КОЗИРКА теорема, рязкост, разделяне и др.
Нека да видим няколко примерни въпроса
В # 12) Проектирайте система за съкращаване на URL адреси като малък URL ?
Отговор: Много кандидати може дори да не знаят за системите за съкращаване на URL адреси като цяло. В този случай е добре да попитате интервюиращия относно изявлението на проблема, вместо да се гмурнете без разбиране.
Преди дори да отговорят на такива въпроси, кандидатите трябва да структурират решението и да напишат точки и след това да започнат да обсъждат решението с интервюиращия.
Нека обсъдим решението накратко
а) Изяснете функционални и нефункционални изисквания
Функционални изисквания: Функционалните изисквания са просто от гледна точка на клиента, това е система, която се подава с голям (дълъг) URL адрес, а изходът трябва да бъде съкратен URL адрес.
Когато се осъществи достъп до съкратения URL адрес, той трябва да пренасочи потребителя към оригиналния URL адрес. Например - опитайте да съкратите действителен URL адрес на https://tinyurl.com/ уеб страница, въведете входен URL като www.softwaretestinghelp.com и трябва да получите малък URL като https://tinyurl.com/shclcqa
Нефункционални изисквания: Системата трябва да бъде ефективна по отношение на пренасочване с милисекундна латентност (като допълнителен скок за потребител, който има достъп до оригиналния URL адрес).
- Съкратените URL адреси трябва да имат конфигурируемо време на изтичане.
- Съкратените URL адреси не трябва да бъдат предвидими.
б) Оценка на капацитета / трафика
Това е много важно от гледна точка на всички въпроси за дизайна на системата. Оценката на капацитета по същество определя очакваното натоварване, което системата ще получи. Винаги е добре да започнете с предположение и да обсъдите с интервюиращия. Това е важно и от гледна точка на планирането на размера на базата данни, независимо дали системата е тежка за четене или тежка за запис и т.н.
Нека направим няколко номера на капацитета за примера за съкращаване на URL адреси.
Да предположим, че ще има 100 000 нови заявки за съкращаване на URL на ден (със съотношение 100: 1 за четене и запис - т.е. за всеки 1 съкратен URL адрес, ще имаме 100 заявки за четене срещу съкратения URL адрес)
Така че ще имаме,
100k write requests/day => 100000/(24x60x60) => 1.15 request/second 10000k read requests/day => 10000000/(24x60x60) => 1157 requests/second
в) Съображения за съхранение и памет
След номерата на капацитета можем да екстраполираме тези числа, за да получим,
- Капацитетът за съхранение, който би бил необходим, за да поеме очакваното натоварване, Например, можем да планираме да проектираме решение за съхранение, което да поддържа заявките до 1 година.
Пример: Ако всеки съкратен URL адрес консумира 50 байта, тогава общите данни / съхранение, които бихме изисквали за една година, ще бъдат:
=> total write requests/day x 365 x 50 / (1024x1024) => 1740 MB
- Съображенията за паметта са важни за планирането на системата от гледна точка на читателя. т.е.за системи, които са тежки за четене - като тази, която се опитваме да изградим (защото URL адресът ще бъде създаден веднъж, но ще бъде достъпен няколко пъти).
Тежките системи за четене обикновено използват кеширане, за да станат по-ефективни и да избягват четенето от постоянното хранилище, за да спестят от четене на вход / изход.
Да предположим, че искаме да съхраняваме 60% от нашите заявки за четене в кеша, така че през годината бихме изисквали 60% от общите четения през годината x байта, изисквани от всеки запис
=> (60/100) x 100000 x 365 x (50/1024x1024) => 1045 MB ~ 1GB
Така че, според нашите номера на капацитета, тази система ще изисква около 1 GB физическа памет
г) Оценки на честотната лента
Оценките на честотната лента са необходими за анализ на скоростта на четене и запис в байтове, които биха били необходими за изпълнение на системата. Нека направим оценки спрямо номерата на капацитета, които сме взели.
Пример: Ако всеки съкратен URL адрес консумира 50 байта, тогава общата скорост на четене и запис, която ни е необходима, ще бъде както по-долу:
WRITE - 1.15 x 50bytes = 57.5 bytes/s READS - 1157 x 50bytes = 57500 bytes/s => 57500 / 1024 => 56.15 Kb/s
д) Системен дизайн и алгоритъм
Това по същество е основната бизнес логика или алгоритъм, които биха били използвани за изпълнение на функционалните изисквания. В този случай искаме да генерираме уникални съкратени URL адреси за даден URL адрес.
Различните подходи, които могат да се използват за генериране на съкратени URL адреси, са:
Хеширане: Можем да мислим за генериране на съкратени URL адреси, като създадем хеш на входния URL адрес и присвоим хеш ключа като съкратен URL адрес.
Този подход може да има някои проблеми, когато има различни потребители на услугата и ако те въведат един и същ URL адрес, това ще доведе до получаване на същия съкратен URL адрес.
Предварително създадени съкратени низовеи се присвояват на URL адреси при извикване на услугата: Друг подход може да бъде връщането на предварително дефиниран съкратен низ от пула на вече генерирани низове.
API за услуги: Можем да разглеждаме системата за съкращаване на URL адреси като набор от REST-базирани API, които имат следните крайни точки:
- createUrl (String Url, DateTime expiryTime): Тази крайна точка създава и връща съкратен URL адрес с продължителност на изтичане, зададена както е посочено във входа.
- retrieveUrl (низ, съкратен Url): Тази крайна точка извлича URL, за да бъде пренасочена към дадения съкратен URL адрес.
е) Мащабиране и паралелност
Мащабирането е важно съображение от гледна точка на нефункционалните изисквания.
Той се занимава с това, как може система
- Скала под товар: Системата трябва да може грациозно да се мащабира при натоварване, а не просто да спира да работи след неочакван скок на товара.
Препоръчително четене => Техники за мащабиране
- Колко ефективна може да бъде системата, например: ако системата се използва с постоянен капацитет за дълго време, ще се влоши ли производителността на системата или тя остава стабилна?
Може да има много различни въпроси за дизайна на системата, както по-долу, но най-общо казано, всички те биха проверили по-широкото разбиране на кандидата за различни концепции, които сме обсъждали в решението на системата за съкращаване на URL адреси.
В # 13) Проектирайте видео платформа като Youtube.
Отговор: Към този въпрос също може да се подходи по подобен начин, както обсъдихме въпроса за TinyUrl по-горе (и това се отнася за почти всички въпроси за интервюта за проектиране на системата). Единственият диференциращ фактор би бил да разгледате / детайлирате системата, която искате да проектирате.
Така че за Youtube всички ние познаваме приложението му за видео стрийминг и има много възможности, като например позволяване на потребителя да качва нови видеоклипове, да излъчва уеб предавания на живо и т.н. Така че, докато проектирате системата, трябва да приложите необходимите компоненти на системния дизайн. В този случай може да се наложи да добавим компоненти, свързани с възможностите за видео стрийминг.
Можете да обсъждате точки като,
- Съхранение: Каква база данни бихте избрали да съхранявате видео съдържание, потребителски профили, плейлисти и т.н.?
- Сигурност и удостоверяване / оторизация
- Кеширане: Тъй като платформата за стрийминг като youtube трябва да бъде ефективна, кеширането е важен фактор за проектирането на всяка такава система.
- Съвпадение: Колко потребители могат да предават видео паралелно?
- Други функционалности на платформата като услуга за препоръчване на видео, която препоръчва / предлага на потребителите следващите видеоклипове, които могат да гледат и т.н.
Въпрос # 14) Проектирайте ефективна система за работа с 6 асансьора и се уверете, че човек трябва да изчака минимално време, докато чака пристигането на асансьора ?
Отговор: Този тип въпроси за проектиране на системата са на по-ниско ниво и биха очаквали кандидатът първо да премисли системата на асансьора и да изброи всички възможни функции, които трябва да бъдат поддържани, и да проектира / създаде класове и връзки / схеми на DB като решение.
От гледна точка на SDET, интервюиращият просто би очаквал основните класове, които смятате, че вашето приложение или система ще има и основните функции ще бъдат обработени с предложеното решение.
Нека да видим различни функционалности на асансьорната система, които биха могли да се очакват
Можете да зададете уточняващи въпроси като
- Колко етажа има?
- Колко асансьора има?
- Обслужват ли всички асансьори / пътнически асансьори?
- Всички асансьори конфигурирани ли са да спират на всеки етаж?
Ето различните случаи на употреба, които са приложими за обикновена асансьорна система:
По отношение на основните класове / обекти на тази система, можете да помислите да имате:
- Потребител: Справя се с всички свойства на даден потребител и действия, които те могат да предприемат над Elevator Object.
- Асансьор: Асансьор Специфични свойства като височина, ширина, elevator_serial_number.
- Врата на асансьора: Всички неща, свързани с вратата, като без врати, тип врата, автоматична или ръчна и т.н.
- Elevator_Button_Control: Налични са различни бутони / контроли в асансьора и различни състояния, в които тези контроли могат да бъдат.
След като приключите, проектирате класове и техните взаимоотношения, можете да говорите за конфигуриране на DB схеми.
Друг важен компонент на асансьорната система е Eventing System. Можете да говорите за внедряване на опашки или в по-сложна настройка, създавайки потоци от събития, използвайки Apache Kafka, където събитията се доставят до съответните системи, за да се действа.
Системата за събития е важен аспект, тъй като има няколко потребители (на различни етажи), които използват асансьора едновременно. Следователно заявките на потребителя трябва да бъдат на опашка и обслужвани според конфигурираната логика в контролерите на асансьора.
Въпрос # 15) Дизайн на Instagram / Twitter / Facebook.
Отговор: Всички тези платформи са свързани по някакъв начин, тъй като позволяват на потребителите да бъдат свързани по някакъв начин или по друг начин и да споделят неща чрез различни видове медии - като съобщения / видеоклипове и чатове.
Така че, за тези видове приложения / платформи за социални медии, трябва да включите точки по-долу, докато обсъждате проектирането на такива системи (в допълнение към това, което обсъдихме за проектирането на система за съкращаване на URL адреси):
- Оценка на капацитета: Повечето от тези системи ще бъдат тежки за четене, поради което се изисква оценка на капацитета и ще ни позволи да гарантираме, че е осигурена подходяща конфигурация на сървъра и базата данни, за да обслужва необходимото натоварване.
- DB схема: Основните важни DB схеми, които трябва да бъдат обсъдени, са - Потребителски подробности, Взаимоотношения с потребители, Схеми на съобщения, Схеми на съдържанието.
- Сървъри за хостинг на видео и изображения: Повечето от тези приложения имат видеоклипове и изображения, споделени между потребителите. Следователно сървърите за хостинг на видео и изображения трябва да бъдат конфигурирани според нуждите.
- Сигурност: Всички тези приложения трябва да осигуряват високо ниво на сигурност благодарение на информацията за потребителя / лична информация за потребителите, които съхраняват. Всякакви опити за хакване, SQL Injection не трябва да са успешни на тези платформи, тъй като може да струва загуба на данни на милиони клиенти.
Проблеми, базирани на сценарий
Проблемите, базирани на сценарии, обикновено са за хора на по-високо ниво, където се дават различни сценарии в реално време и кандидатът се пита за мислите им как ще се справят с такава ситуация.
Въпрос # 16) Като се има предвид, че критичната корекция трябва да бъде пусната възможно най-скоро - каква стратегия за тестване бихте имали?
Отговор: Сега тук интервюиращият по същество иска да разбере
- Как и за какви тестови стратегии можете да се сетите?
- Какво покритие бихте направили за актуална корекция?
- Как бихте проверили актуалната корекция след разполагане? и т.н.
За да отговорите на такива въпроси, бихте могли да използвате ситуации от реалния живот, ако можете да се свържете с проблема. Трябва също да споменете, че без подходящо тестване не бихте искали да пуснете кода за производство.
За критичните поправки винаги трябва да работите в тандем с разработчика и да се опитате да разберете върху кои области може да повлияе и да подготвите непроизводствена среда, за да репликирате сценария и да тествате поправката.
Тук също е важно да споменем, че ще продължите да наблюдавате корекцията (като използвате инструменти за мониторинг, табла за управление, регистрационни файлове и т.н.) след внедряването, за да видите всяко ненормално поведение в производствената среда и да гарантирате, че няма отрицателно въздействие на корекцията, която е Свършен.
Възможно е да има и други въпроси, които са предимно за разбиране на перспективата на кандидата за тестване на автоматизацията, срокове за доставка и т.н. (и тези въпроси могат да варират от компания до компания, както и старшинство на ролята. Обикновено тези въпроси се задават за ниво старши / ръководител) роли)
Въпрос # 17) Бихте ли пожертвали пълното тестване, за да пуснете продукта бързо?
Отговор: Тези въпроси обикновено включват интервюиращия да разбере вашите мисли от гледна точка на лидерството и кои са нещата, за които бихте направили компромис, и бихте ли искали да пуснете бъги продукт вместо по-малко време.
Отговорите на тези въпроси трябва да бъдат обосновани спрямо действителния опит на кандидата.
Например, можете да споменете, че в миналото е трябвало да се обадите, за да пуснете някаква актуална корекция, но тя не може да бъде тествана поради липсата на среда за интеграция. Така че го пуснахте контролирано - чрез пускане на по-малък процент и след това наблюдение на дневници / събития и след това иницииране на пълно пускане и т.н.
В # 18) Как бихте създали стратегия за автоматизация за продукт, който изобщо няма тестове за автоматизация?
Отговор: Този тип въпроси са с отворен край и обикновено са добро място за провеждане на дискусията по начина, по който искате. Можете също така да покажете своите умения, знания и технологични области, които са вашата сила.
Например, за да отговорите на този тип въпроси, можете да цитирате примери за стратегия за автоматизация, която сте приели, докато сте създавали продукт в предишната си роля.
Например, можете да споменете точки като,
- Тъй като продуктът изискваше стартиране на автоматизацията от нулата, имате достатъчно време да помислите и да проектирате подходяща рамка за автоматизация, като изберете език / технология, която повечето хора да имат познанията, за да избегнат въвеждането на нов инструмент и да използват съществуващите знания.
- Започнахте с автоматизирането на най-основните функционални сценарии, които се смятаха за P1 (без които не може да премине нито едно издание).
- Мислили сте и за тестване на производителността и мащабируемостта на системата чрез автоматизирани тестови инструменти като JMETER, LoadRunner и др.
- Мислили сте за автоматизиране на аспектите на сигурността на приложението, изброени в OWASP Стандарти за сигурност.
- Интегрирахте автоматизираните тестове в компилационния конвейер за ранна обратна връзка и т.н.
Екип и култура
Този кръг обикновено зависи от компания до компания. Но необходимостта / необходимостта от този кръг е да се разбере кандидата от гледна точка на гледната точка на екипа и организационната култура. Целта на тези въпроси е също така да се разбере личността на кандидата и техния подход към работата / хората и т.н.
Обикновено мениджърите по човешки ресурси и наемане са тези, които провеждат този кръг.
Въпросите, които обикновено се появяват по време на този кръг, са като:
В # 19) Как разрешавате конфликти в рамките на текущата си роля?
Отговор: Допълнително обяснение тук е: да предположим, че имате конфликт с вашия шеф или непосредствени членове на екипа, какви са стъпките, които предприемате, за да разрешите тези конфликти?
За този тип въпроси обосновете колкото е възможно повече с реални примери, които може да са се случили в рамките на вашата кариера в настоящата или предишни организации.
Можете да споменете неща като:
- Обичате да подреждате възможно най-скоро всички конфликти, възникнали в резултат на професионални причини (и не бихте искали да повлияете на личните ви отношения поради тях).
- Можете да споменете, че обикновено се опитвате да общувате ефективно и да говорите / дискутирате с човека поотделно, за да разрешите различията / проблемите.
- Можете да споменете, че ако нещата започнат да се влошават, бихте помогнали на старши човек / вашия мениджър и ще получите неговите приноси.
Други примери за въпроси за екип / култура са по-долу (на повечето от тях трябва да се отговори по подобен подход, който обсъдихме за горния въпрос. Разговорът за сценарии от реалния живот е ключов тук, тъй като интервюиращият може да го свърже по-добре, добре.
Въпрос # 20) Какъв баланс между професионалния и личния живот очаквате от новата роля, за която се смята, че сте нает?
Отговор: Тъй като Мениджърът по наемане е човек, който знае какво изисква ролята, колко допълнителни усилия може да са необходими на моменти, така че като цяло интервюиращият се опитва да прецени дали вашите очаквания са коренно различни от това, което ролята очаква.
Да предположим, че казвате че не предпочитате да присъствате на нощни срещи и ролята очаква да имате голямо сътрудничество между екип, който седи в различна часова зона, тогава интервюиращият може да започне дискусия, че това са очакванията от ролята - ще можете ли да адаптиране? и т.н.
Така че отново, това е по-скоро непринуден разговор, но от гледна точка на интервюиращия, те искат да разберат вашите очаквания, за да оценят кандидатурата ви за позицията, за която сте интервюирани.
В # 21) Освен работата, какви са вашите хобита?
Отговор: Тези въпроси са чисто субективни и индивидуално специфични и тези въпроси обикновено са полезни, за да накарат кандидата да се чувства спокоен и лесен и да инициират непринудени дискусии.
Като цяло отговорите на тези въпроси могат да бъдат като - обичате да четете определен жанр, харесвате музика, получили сте някаква награда за някаква доброволна / филантропска дейност и др. Освен това тези въпроси обикновено се задават в кръга за човешки ресурси (и по-малко вероятно да бъде поискано от техническо лице).
Въпрос # 22) Колко време сте готови да отделите активно за изучаване на нови инструменти и технологии?
Отговор: Тук интервюиращият преценява вашата готовност да научите нови неща, ако ви се хвърли нещо необичайно или ново. Това също така дава възможност на интервюиращия да знае, че сте инициативен? Готови ли сте да инвестирате в себе си и кариерата си? и т.н.
Така че, докато отговаряте на такива въпроси - бъдете честни и аргументирайте отговорите си с примери - Например, Бихте могли да споменете, че миналата година се явихте за сертифициране на Java и се подготвихте извън работа, като отделяте по няколко часа всяка седмица.
Заключение
В тази статия обсъдихме инженера по разработване на софтуер в процеса на тестово интервю и примерни въпроси, които обикновено се задават от кандидатите в различни организации и профили. Като цяло, интервютата за SDET имат много широк характер и много зависят от компанията до компанията.
Но процесите на интервюта са подобни на това за профила на разработчика с по-голям акцент върху рамките за качество и автоматизация.
Важно е да се разбере, че в днешно време компаниите са по-малко фокусирани върху някакъв специфичен език или технология, а повече за широко разбиране на понятията и способността да се адаптират към инструментите / технологиите, изисквани от компанията.
Най-добри пожелания за вашето интервю за SDET!
Препоръчително четене
- Какво е SDET: Знайте разликата между тестера и SDET
- Въпроси и отговори за интервюта
- Въпроси и отговори за интервю за ETL тестване
- Някои сложни ръчни тестови въпроси и отговори
- Въпроси за интервю с Spock с отговори (най-популярни)
- 25 най-добри пъргави тестови интервюта Въпроси и отговори
- Топ 32 най-добри въпроси и отговори за интервю за сцената на данни
- Топ 20+ .NET интервюта и отговори