sdet interview questions
Przeczytaj ten kompletny przewodnik dla inżyniera programisty w rozmowach testowych, aby poznać format i sposób odpowiadania na pytania do wywiadu SDET zadawane w różnych rundach:
W tym samouczku dowiemy się o kilku często zadawanych pytaniach podczas rozmów kwalifikacyjnych dla ról SDET. Zobaczymy również ogólnie wspólny schemat wywiadów i podzielimy się wskazówkami, jak osiągnąć sukces w wywiadach.
Będziemy używać języka Java do rozwiązywania problemów z kodowaniem w tym samouczku, jednak większość samouczków SDET jest niezależnych od języka, a ankieterzy są ogólnie elastyczni w zakresie języka, którego wybiera kandydat.
Czego się nauczysz:
Poradnik przygotowania do rozmowy kwalifikacyjnej SDET
Wywiady SDET, w większości czołowych firm produktowych, są dość podobne do sposobu, w jaki przeprowadza się wywiady na stanowiska rozwojowe. Dzieje się tak, ponieważ od SDET oczekuje się również, że będą wiedzieć i rozumieć prawie wszystko, co wie programista.
Różnią się one kryteriami, na podstawie których ocenia się respondenta SDET. Osoby przeprowadzające rozmowę kwalifikacyjną na tę rolę szukają umiejętności krytycznego myślenia, a także tego, czy osoba przesłuchiwana ma praktyczne doświadczenie w kodowaniu oraz zwraca uwagę na jakość i szczegółowość.
Oto kilka punktów, na których osoba przygotowująca się do wywiadu SDET powinna w dużej mierze skupić się na:
Ups koncepcja w C # z przykładem
- Ponieważ w większości przypadków rozmowy kwalifikacyjne są niezależne od technologii / języka, kandydaci muszą chcieć uczyć się nowych technologii (i wykorzystywać istniejące umiejętności) w razie potrzeby.
- Powinien mieć dobrą komunikację i umiejętności zespołowe, ponieważ role SDET w dzisiejszych czasach wymagają komunikacji i współpracy na różnych poziomach z wieloma interesariuszami.
- Powinien mieć podstawową wiedzę na temat różnych koncepcji projektowych systemu, skalowalności, współbieżności, wymagań niefunkcjonalnych itp.
W poniższych sekcjach postaramy się zrozumieć ogólny format wywiadu wraz z kilkoma przykładowymi pytaniami.
Format inżyniera programisty w rozmowie kwalifikacyjnej
Większość firm ma preferowany format przeprowadzania rozmów kwalifikacyjnych z kandydatami na stanowisko SDET, ponieważ czasami rola jest bardzo specyficzna dla zespołu i oczekuje się, że osoba będzie oceniana jako idealnie dopasowana do zespołu, do którego jest zatrudniona.
Ale temat wywiadów jest generalnie oparty na poniższych punktach:
- Rozmowa telefoniczna: Rozmowa z menadżerem i / lub członkami zespołu, która zwykle jest rundą sprawdzającą.
- Runda pisemna: Z testowaniem / testowaniem obudów konkretnych pytań.
- Runda biegłości kodowania: Proste pytania dotyczące kodowania (bez znajomości języka), a kandydat jest proszony o napisanie kodu na poziomie produkcyjnym.
- Zrozumienie podstawowych koncepcji programistycznych: Podobnie jak koncepcje OOPS, SOLID Principles itp.
- Projektowanie i programowanie platformy automatyzacji testów
- Języki skryptowe: Selen, Python, Javascript itp
- Kultura Fit / HR dyskusja i negocjacje
Pytania i odpowiedzi do wywiadu SDET
W tej sekcji omówimy kilka przykładowych pytań wraz ze szczegółowymi odpowiedziami dla różnych kategorii, które są zadawane przez większość firm produktowych zatrudniających na stanowiska SDET.
Umiejętność kodowania
W tej rundzie proste problemy z kodowaniem mają zostać napisane w wybranym języku. W tym przypadku ankieter chce ocenić biegłość w zakresie konstrukcji kodowania, a także poradzić sobie z takimi rzeczami, jak scenariusze brzegowe i kontrole zerowe itp.
Czasami ankieterzy mogą również poprosić o zapisanie testów jednostkowych dla napisanego programu.
Zobaczmy kilka przykładowych problemów.
P # 1) Napisz program do zamiany 2 liczb bez używania trzeciej (tymczasowej) zmiennej?
Odpowiedź :
Program do zamiany dwóch liczb:
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); } }Oto wynik powyższego fragmentu kodu:
W powyższym fragmencie kodu należy zauważyć, że ankieter specjalnie poprosił o zamianę 2 numerów bez używania trzeciej zmiennej tymczasowej. Ponadto ważne jest, aby przed przesłaniem rozwiązania zawsze sprawdzić (lub uruchomić próbny) kod przez co najmniej 2-3 dane wejściowe. Spróbujmy znaleźć wartości pozytywne i negatywne.
Wartości dodatnie: 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)Wartości ujemne: 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)P # 2) Napisz program odwracający liczbę?
Odpowiedź: Teraz stwierdzenie problemu może początkowo wyglądać onieśmielająco, ale zawsze rozsądnie jest zadawać pytania prowadzącemu rozmowę (ale nie ma zbyt wielu szczegółów). Ankieterzy mogą zdecydować się na udzielenie wskazówek na temat problemu, ale jeśli kandydat zadaje wiele pytań, oznacza to również, że kandydat nie daje wystarczająco dużo czasu na dobre zrozumienie problemu.
W tym przypadku problem wymaga od kandydata również przyjęcia pewnych założeń - na przykład, liczba może być liczbą całkowitą. Jeśli na wejściu jest 345, to na wyjściu powinno być 543 (co jest odwrotnością 345)
Zobaczmy fragment kodu tego rozwiązania:
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; } }Dane wyjściowe tego programu w porównaniu z danymi wejściowymi : 10025 - Oczekiwano, że będzie : 52001
P # 3) Napisz program do obliczania silni liczby?
Odpowiedź: Silnia to jedno z najczęściej zadawanych pytań w prawie wszystkich wywiadach (w tym wywiadach z programistami)
W przypadku wywiadów z programistami większy nacisk kładzie się na koncepcje programistyczne, takie jak programowanie dynamiczne, rekurencja itp., Podczas gdy z perspektywy inżyniera programisty z perspektywy testów ważne jest, aby obsługiwać scenariusze brzegowe, takie jak wartości maksymalne, wartości minimalne, wartości ujemne itp. Oraz podejście / wydajność są ważne, ale stają się drugorzędne.
Zobaczmy program do silni używający rekurencji i pętli for z obsługą liczb ujemnych i zwracający stałą wartość, powiedzmy -9999 dla liczb ujemnych, którą powinien obsługiwać program wywołujący funkcję silni.
Zapoznaj się z poniższym fragmentem kodu:
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); } }Zobaczmy dane wyjściowe dla - silnia przy użyciu pętli, silnia przy użyciu rekurencji i silnia liczby ujemnej (co zwróci domyślną ustawioną wartość -9999)
P # 4) Napisz program sprawdzający, czy dany ciąg ma zrównoważone nawiasy?
Odpowiedź:
Podejście - Jest to nieco złożony problem, w którym ankieter szuka czegoś więcej niż znajomości samych konstrukcji kodowania. W tym przypadku oczekuje się przemyślenia i wykorzystania struktury danych apt dla danego problemu.
Wielu z was może czuć się onieśmielonych tego typu problemami, ponieważ niektórzy z was mogli ich nie słyszeć, a zatem nawet jeśli są proste, mogą wydawać się skomplikowane.
Ale ogólnie w przypadku takich problemów / pytań: na przykład w obecnym pytaniu, jeśli nie wiesz, jakie są wyważone nawiasy, możesz bardzo dobrze zapytać ankietera, a następnie pracować nad rozwiązaniem, zamiast trafiać w ślepy punkt.
Zobaczmy, jak podejść do rozwiązania: Po zrozumieniu, czym są zrównoważone nawiasy, możesz pomyśleć o użyciu odpowiedniej struktury danych, a następnie rozpocząć pisanie algorytmów (kroków), zanim zaczniesz kodować rozwiązanie. Często same algorytmy rozwiązują wiele scenariuszy brzegowych i dają dużą jasność co do tego, jak będzie wyglądać rozwiązanie.
Spójrzmy na rozwiązanie:
Zrównoważone nawiasy służą do sprawdzania, czy dany ciąg zawiera nawiasy (lub nawiasy), powinien mieć równą liczbę otwarcia i zamknięcia, a także dobrą strukturę pozycjonowania. W kontekście tego problemu użyjemy zrównoważonych nawiasów jako - „()”, „()”, „{}” - czyli dany ciąg może mieć dowolną kombinację tych nawiasów.
Pamiętaj, że przed przystąpieniem do rozwiązywania problemu dobrze jest wyjaśnić, czy ciąg będzie zawierał tylko znaki nawiasu, cyfry itp. (Ponieważ może to nieco zmienić logikę)
Przykład: Podany ciąg - '{() {} ()} - jest zrównoważonym ciągiem, ponieważ ma strukturę i ma równą liczbę nawiasów zamykających i otwierających, ale ciąg -' {(}) {} () '- ten ciąg - mimo że ma równą liczbę otwierających i zamykających nawiasów to nadal nie jest zrównoważone, ponieważ możesz zobaczyć, że bez zamykającego nawiasu '(' zamknęliśmy '}' (tj. wszystkie wewnętrzne nawiasy powinny być zamknięte przed zamknięciem zewnętrznego nawiasu)
Aby rozwiązać ten problem, będziemy używać struktury danych stosu. Jeśli chcesz dowiedzieć się więcej o podstawach stosu, zajrzyj tutaj
Stos jest strukturą danych typu LIFO (Last In First Out), potraktuj go jako stos / stos talerzy na weselu - za każdym razem będziesz podnosić najwyższy talerz.
Algorytm:
# 1) Zadeklaruj stos znaków (który będzie zawierał znaki w ciągu iw zależności od logiki wypychał i wyskakiwał znaki).
# 2) Przejdź przez ciąg wejściowy i kiedykolwiek
- Jest nawias otwierający - np. „(‘, {’Lub‘ (’- wciśnij znak na stosie.
- Jest znak zamykający - tj. „)”, „}”, „)” - zdejmij element ze stosu i sprawdź, czy pasuje on do przeciwnego znaku zamykającego - tj. Jeśli znakiem jest „}”, to na stosie pop powinieneś się spodziewać „ {'
- Jeśli wyskakujący element nie pasuje do nawiasów zamykających, to ciąg nie jest zbalansowany i można zwrócić wyniki.
- W przeciwnym razie kontynuuj podejście push i pop (przejdź do kroku 2).
- Jeśli ciąg jest całkowicie przemierzany, a rozmiar stosu również wynosi zero, możemy powiedzieć / wywnioskować, że dany ciąg jest zrównoważonym łańcuchem nawiasów.
W tym momencie możesz również chcieć omówić podejście do rozwiązania, które masz jako algorytm i upewnić się, że ankieter zgadza się z podejściem.
Kod:
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 Dane wyjściowe powyższego fragmentu kodu:
Podobnie jak w przypadku naszych poprzednich problemów z kodowaniem, zawsze dobrze jest uruchomić na sucho kod z co najmniej 1-2 poprawnymi i 1-2 nieprawidłowymi danymi wejściowymi i upewnić się, że wszystkie przypadki są odpowiednio obsługiwane.
UWAGA: Zawsze dobrze jest przemyśleć rozwiązanie głośno (i nie tylko w umyśle) - i, co zaskakujące, jest to ważna cecha, której szukają ankieterzy. Wielu ankieterów mogłoby po prostu pozbyć się algorytmu i przejść do następnego stwierdzenia problemu.
W powyższym rozwiązaniu do kodowania, w przypadku wywiadu z programistą, ankieter może poprosić o rozwiązanie go za pomocą tablic zamiast bezpośredniego stosu (tj. Używając tablicy jako stosu), ale ogólnie rzecz biorąc, bardziej chodzi o to, aby być koncepcyjnie przejrzystym i zdolnym do obsługi wszystkich ważnych i nieprawidłowe dane wejściowe.
Powiązane ramy automatyzacji testów
Ta część wywiadu jest bardziej szczegółowo poświęcona testowaniu i obowiązkom SDET. Spodziewaj się projektowania ram automatyzacji i pytań związanych z rozwojem, zalet i wad korzystania z różnych podejść itp.
Zobaczmy kilka przykładowych pytań i rozwiązań tego samego.
P # 5) Wyjaśnić i zaprojektować elementy struktury automatyzacji dla aplikacji internetowej?
Odpowiedź: To pytanie jest trochę subiektywne, a ankieter zamierza ocenić, ile kandydat wie na temat projektowania i rozwoju frameworka. Odpowiedź na to pytanie pomaga ankieterowi zrozumieć, czy kandydat może budować lub tworzyć niestandardowe ramy od podstaw.
Spójrzmy na kilka punktów, które pomogą Ci ustrukturyzować rozwiązanie tego pytania:
- Możesz mówić o różnych typach frameworków, takich jak - oparta na danych, oparta na słowach kluczowych, hybrydowa struktura.
- Page Object Model do przechowywania szczegółów różnych elementów na różnych stronach / modułach aplikacji internetowej.
- Typowe moduły, takie jak funkcje pomocnicze, narzędzia, rejestratory itp.
- Moduły raportowania, takie jak generowanie raportów z wykonania testów, integracja raportów z pocztą e-mail i planowanie wykonywania testów itp.
Zalecana lektura => Najpopularniejsze struktury automatyzacji testów
P # 6) Wyjaśnij strategie testowania aplikacji mobilnej?
Odpowiedź: Te pytania są zwykle zadawane w zależności od roli. Jeśli rola polega głównie na pracy w aplikacjach mobilnych, to pytanie ma większe znaczenie. Możesz mówić na podstawie swojego doświadczenia, jeśli zaplanowałeś testy mobilne w ramach swoich obecnych lub poprzednich ról.
Niektórymi wskazówkami do uporządkowania odpowiedzi na to pytanie mogą być:
- Testowanie na urządzeniach vs emulatorach.
- Identyfikowanie i przechowywanie obiektów / elementów na różnych ekranach - Przykład: Model obiektu strony.
- Testowanie obciążenia aplikacji mobilnej.
- Możesz rozmawiać o różnych typach aplikacji mobilnych, takich jak - aplikacje natywne, aplikacje hybrydowe, i omawiać strategie / podejścia, których użyjesz do ich przetestowania.
Zalecana lektura => Samouczki testowania aplikacji mobilnych
P # 7) Zaprojektować ramy automatyzacji do testowania interfejsów API REST?
Odpowiedź: To znowu jest subiektywne pytanie i możesz zadać wyjaśniające pytania, czy ankieter chce, abyś opracował ramy do testowania funkcjonalnego zachowania API, czy też wymagań niefunkcjonalnych, takich jak testy obciążenia / wydajności.
Możesz rozpocząć swoją odpowiedź od omówienia poniższych punktów:
- Komponenty struktury API Automation, takie jak konfiguracja lokalna, próbna konfiguracja interfejsu API lub testowanie hostowanego interfejsu API.
- Narzędzia używane do automatyzacji API. Istnieją różne narzędzia dostępne po wyjęciu z pudełka do sprawdzania funkcjonalnych aspektów interfejsu API opartego na REST. Niektóre z takich narzędzi to Postman, Rest Assured itp. Szczegółowe informacje na temat różnych narzędzi można znaleźć w naszym artykule tutaj .
- Niefunkcjonalna automatyzacja interfejsów API.
- Zaplanowane wykonanie testów automatyzacyjnych.
- Integracja testów automatyzacji dla API.
Q # 8) Pytania dotyczące ram.
Odpowiedź: Czasami, w zależności od profilu, z którym rozmawiasz, może istnieć wymóg, aby kandydat był biegły w określonych ramach - np. Selen, JMeter itp.
Zalecana lektura => Listonosz , Mockito , Specflow , Selen , JMeter
Testowanie związane
Chociaż rzadko, ale w zależności od profilu, mogą pojawić się pytania dotyczące ogólnych praktyk testowania, terminów i technologii - takich jak dotkliwość błędu, priorytet, planowanie testów, wielkość liter itp. SDET powinien znać wszystkie koncepcje testowania ręcznego i powinien być znajomy z ważnymi terminologiami.
W tej sekcji możesz spodziewać się takich pytań:
P # 9) Jakie są różne elementy planu testów?
Odpowiedź: Zwykle są one proszone o potwierdzenie podstawowych koncepcji testowania i sposobu myślenia. Te terminy i dokumenty są czymś, co powinien znać każdy ręczny zespół ds. Kontroli jakości, a także pracownicy SDET zajmujący się automatyzacją.
Możesz tutaj omówić różne elementy planu testów, takie jak:
- Kryteria wejścia i wyjścia
- Zakres: Omów funkcje testowe, które są w zakresie i co wszystko byłoby zautomatyzowane - Czy będą to tylko funkcje funkcjonalne, czy niefunkcjonalne wymagania, takie jak skalowalność, wydajność itp.
- Osie czasu
- Narzędzia do wykorzystania
- Alokacja zasobów itp
Zalecana lektura => Jak napisać dobry plan testów
P # 10) Co definiuje i decyduje o priorytecie i wadze błędu?
Odpowiedź: Priorytet i wagę defektu można łatwo wyjaśnić za pomocą przykładów. Załóżmy, że funkcja taka jak rejestracja jest zepsuta i uniemożliwia użytkownikom dostęp do aplikacji - wtedy jest to problem o wysokim priorytecie i istotnym znaczeniu. Podobnie mogą istnieć przykłady defektów o niskim / wysokim priorytecie i różne inne kombinacje.
Ogólnie,
- Priorytet wskazuje na wagę problemu.
- Surowość oznacza wpływ, jaki ma problem na klienta lub użytkownika aplikacji.
Zalecana lektura => Priorytet i waga defektu
P # 11) Co to jest partycjonowanie równoważne? Zilustruj przykładem.
Odpowiedź: Partycjonowanie równoważności jest techniką najczęściej używaną do testowania czarnoskrzynkowego, do testowania różnych kombinacji danych wejściowych w danym polu.
Na przykład, jeśli testujesz aplikację handlową i chcesz napisać wszystkie scenariusze testowe dla pola „Ilość” - jakie byłyby różne dane wejściowe, które testowałbyś dla tego pola?
Biorąc pod uwagę wymaganie funkcjonalne, ilość powinna być dodatnią liczbą całkowitą z przedziału od 1 do 100 000. Aby przetestować różne dane wejściowe (zarówno prawidłowe, jak i nieprawidłowe), można przeprowadzić testy dla 1 wejścia z każdej takiej kategorii.
- Prawidłowe wartości: Między 1 a 100000 -> test dla dowolnej prawidłowej wartości x takiej, że x> 1 i x<100000.
- Wartości graniczne: Sprawdź dozwolone wartości graniczne, tj. 1 i 100000.
- Nieprawidłowe wartości: Wartości, które leżą poza dozwolonym zakresem - tj. Test dla jednej takiej wartości dla x, takiej jak x 100000.
Zalecana lektura => Strategia podziału na partycje równoważne
Związane z projektem systemu
Pytania dotyczące projektowania systemu są zwykle bardziej odpowiednie w przypadku wywiadów z programistami, w których ocenia się programistę na podstawie szerokiego zrozumienia różnych ogólnych pojęć - takich jak skalowalność, dostępność, odporność na błędy, wybór bazy danych, wątki itp. Krótko mówiąc, będziesz musiał wykorzystać cały swój doświadczenie i znajomość systemów, aby odpowiedzieć na takie pytania.
Ale możesz mieć wrażenie, że system, którego kodowanie wymaga lat doświadczeń i setek programistów, jak osoba może odpowiedzieć na pytanie w około 45 minut?
Odpowiedź to: Tutaj oczekuje się oceny zrozumienia przez kandydata i szerokiego spektrum wiedzy, którą może zastosować przy rozwiązywaniu złożonych problemów.
W dzisiejszych czasach pytania te pojawiają się również w wywiadach SDET. Tutaj oczekiwania pozostają takie same jak podczas rozmowy z deweloperem, ale z mniejszymi kryteriami oceny i jest to głównie runda podnoszenia poprzeczki, w której, w zależności od odpowiedzi kandydata, kandydat może zostać rozpatrzony na następny poziom lub przeniesiony na niższy poziom.
Ogólnie rzecz biorąc, w przypadku pytań do rozmowy kwalifikacyjnej dotyczącej projektowania systemu kandydat powinien znać poniższe pojęcia
- Podstawy systemów operacyjnych: Strony, systemy plików, pamięć wirtualna i pamięć fizyczna itp.
- Koncepcje sieciowe: Komunikacja HTTP, stos TCP / IP, topologie sieciowe.
- Koncepcje skalowalności: Skalowanie poziome i pionowe.
- Pojęcia dotyczące współbieżności / wątkowości
- Typy baz danych: Bazy danych SQL / No SQL, kiedy używać jakiego typu bazy danych, zalety i wady różnych typów baz danych.
- Techniki haszowania
- Podstawowe rozumienie CZAPKA twierdzenie, fragmentacja, partycjonowanie itp.
Zobaczmy kilka przykładowych pytań
P # 12) Zaprojektuj system skracania adresów URL, taki jak mały adres URL ?
Odpowiedź: Wielu kandydatów może nawet nie wiedzieć ogólnie o systemach skracania adresów URL. W takim przypadku można zapytać ankietera o stwierdzenie problemu, zamiast zanurkować bez zrozumienia.
Jeszcze przed udzieleniem odpowiedzi na takie pytania kandydaci powinni ustrukturyzować rozwiązanie i napisać wypunktowania, a następnie rozpocząć dyskusję na temat rozwiązania z ankieterą.
Omówmy w skrócie rozwiązanie
a) Wyjaśnij wymagania funkcjonalne i niefunkcjonalne
Wymagania funkcjonalne: Wymóg funkcjonalny jest po prostu z punktu widzenia klienta, jest to system, który otrzymuje duży (długi) adres URL, a wynik powinien być skrócony.
Kiedy uzyskiwany jest dostęp do skróconego adresu URL, powinien on przekierowywać użytkownika do pierwotnego adresu URL. Na przykład - spróbuj skrócić rzeczywisty adres URL na stronie https://tinyurl.com/, podaj wejściowy adres URL, taki jak www.softwaretestinghelp.com, a powinieneś otrzymać mały adres URL, taki jak https://tinyurl.com/shclcqa
Wymagania niefunkcjonalne: System powinien być wydajny pod względem przekierowań z milisekundowym opóźnieniem (jako dodatkowy przeskok dla użytkownika uzyskującego dostęp do oryginalnego adresu URL).
- Skrócone adresy URL powinny mieć konfigurowalny czas wygaśnięcia.
- Skrócone adresy URL nie powinny być przewidywalne.
b) Oszacowanie przepustowości / ruchu
Jest to bardzo ważne z punktu widzenia wszystkich pytań projektowych systemu. Szacowanie wydajności zasadniczo określa oczekiwane obciążenie systemu. Zawsze dobrze jest zacząć od założenia i porozmawiać z osobą prowadzącą rozmowę. Jest to również ważne z punktu widzenia planowania rozmiaru bazy danych, niezależnie od tego, czy system jest intensywny do odczytu, czy do zapisu itp.
Zróbmy kilka liczb pojemności dla przykładu skracacza adresów URL.
Załóżmy, że dziennie będzie 100 tys. Nowych żądań skracania adresów URL (przy współczynniku odczytu i zapisu 100: 1 - tj. Na każdy 1 skrócony adres URL będziemy mieli 100 żądań odczytu ze skróconego adresu URL)
Więc będziemy mieć,
100k write requests/day => 100000/(24x60x60) => 1.15 request/second 10000k read requests/day => 10000000/(24x60x60) => 1157 requests/second c) Zagadnienia dotyczące przechowywania i pamięci
Po liczbach pojemności możemy ekstrapolować te liczby, aby uzyskać:
- Pojemność składowania wymagana do przyjęcia spodziewanego ładunku, Na przykład, możemy zaplanować zaprojektowanie rozwiązania magazynowego obsługującego żądania przez okres do 1 roku.
Przykład: Gdyby każdy skrócony adres URL zajmował 50 bajtów, to całkowita ilość danych / pamięci, których potrzebowalibyśmy w ciągu jednego roku, wyniosłaby:
=> total write requests/day x 365 x 50 / (1024x1024) => 1740 MB - Rozważania dotyczące pamięci są ważne przy planowaniu systemu z perspektywy czytelnika. tj. dla systemów, które są z dużą ilością odczytu - jak ten, który próbujemy zbudować (ponieważ adres URL zostałby utworzony raz, ale byłby otwierany wielokrotnie).
Systemy odczytu ciężkiego zwykle używają buforowania, aby zwiększyć wydajność i unikać odczytu z pamięci trwałej, aby zaoszczędzić na odczytach we / wy.
Załóżmy, że chcemy przechowywać 60% naszych żądań odczytu w pamięci podręcznej, więc w ciągu roku wymagalibyśmy 60% wszystkich odczytów w ciągu roku x bajtów wymaganych przez każdy wpis
=> (60/100) x 100000 x 365 x (50/1024x1024) => 1045 MB ~ 1GBTak więc, zgodnie z naszymi danymi dotyczącymi pojemności, system ten wymagałby około 1 GB pamięci fizycznej
d) Oszacowanie przepustowości
Szacunki przepustowości są wymagane do analizy szybkości odczytu i zapisu w bajtach, które byłyby wymagane do wykonania systemu. Dokonajmy oszacowań w odniesieniu do wartości pojemności, które wzięliśmy.
Przykład: Gdyby każdy skrócony adres URL zajmował 50 bajtów, całkowita prędkość odczytu i zapisu, której potrzebowalibyśmy, byłaby taka, jak poniżej:
WRITE - 1.15 x 50bytes = 57.5 bytes/s READS - 1157 x 50bytes = 57500 bytes/s => 57500 / 1024 => 56.15 Kb/s e) Projekt systemu i algorytm
Zasadniczo jest to główna logika biznesowa lub algorytm, który zostałby użyty do spełnienia wymagań funkcjonalnych. W tym przypadku chcemy wygenerować unikalne skrócone adresy URL dla danego adresu URL.
Różne podejścia, które można wykorzystać do wygenerowania skróconych adresów URL, to:
Haszowanie: Możemy myśleć o generowaniu skróconych adresów URL, tworząc skrót wejściowego adresu URL i przypisując klucz hash jako skrócony adres URL.
Takie podejście może mieć pewne problemy, gdy są różni użytkownicy usługi, a jeśli wpiszą ten sam adres URL, spowoduje to uzyskanie tego samego skróconego adresu URL.
Gotowe skrócone stringii przypisywane do adresów URL w momencie wywołania usługi: Innym podejściem może być zwrócenie wstępnie zdefiniowanego skróconego ciągu z puli już wygenerowanych ciągów.
Interfejsy API usług: Możemy myśleć o systemie skracania adresów URL jako o zestawie interfejsów API opartych na REST, które mają następujące punkty końcowe:
- createUrl (String Url, DateTime expiryTime): Ten punkt końcowy tworzy i zwraca skrócony adres URL z czasem wygaśnięcia ustawionym zgodnie z danymi wejściowymi.
- retrieveUrl (String shortenedUrl): Ten punkt końcowy pobiera adres URL, który ma być przekierowany na podany skrócony adres URL.
f) Skalowanie i współbieżność
Skalowanie jest ważnym aspektem z perspektywy wymagań niefunkcjonalnych.
Zajmuje się tym, jak można system
- Waga pod obciążeniem: System powinien być w stanie płynnie skalować pod obciążeniem, a nie tylko przestać działać po wystąpieniu nieoczekiwanego wzrostu obciążenia.
Zalecana lektura => Techniki skalowania
- Jak wydajny może być system, na przykład: jeśli system będzie używany przez długi czas ze stałą wydajnością, czy jego wydajność ulegnie pogorszeniu, czy też pozostanie stabilna?
Może istnieć wiele różnych pytań dotyczących projektowania systemu, jak poniżej, ale ogólnie rzecz biorąc, wszystkie z nich byłyby testem szerszego zrozumienia przez kandydata różnych koncepcji, które omówiliśmy w rozwiązaniu systemu skracania adresów URL.
Pytanie 13) Zaprojektuj platformę wideo, taką jak Youtube.
Odpowiedź: Do tego pytania można również podejść w podobny sposób, jak omówiliśmy powyżej pytanie TinyUrl (i dotyczy to prawie wszystkich pytań do rozmowy kwalifikacyjnej dotyczącej projektowania systemu). Jedynym czynnikiem różnicującym byłoby rozejrzenie się / uszczegółowienie wokół systemu, który chcesz zaprojektować.
Więc jeśli chodzi o YouTube, wszyscy wiemy, że jest to aplikacja do strumieniowego przesyłania wideo i ma wiele możliwości, takich jak umożliwienie użytkownikowi przesyłania nowych filmów, strumieniowania transmisji internetowych na żywo itp. Dlatego podczas projektowania systemu należy zastosować wymagane elementy projektu systemu. W takim przypadku może być konieczne dodanie komponentów związanych z możliwościami przesyłania strumieniowego wideo.
Możesz omawiać takie punkty, jak:
- Przechowywanie: Jaką bazę danych wybrałbyś do przechowywania treści wideo, profili użytkowników, list odtwarzania itp.?
- Bezpieczeństwo i uwierzytelnianie / autoryzacja
- Buforowanie: Ponieważ platforma przesyłania strumieniowego, taka jak YouTube, powinna być wydajna, buforowanie jest ważnym czynnikiem przy projektowaniu każdego takiego systemu.
- Konkurencja: Ilu użytkowników może równolegle przesyłać strumieniowo wideo?
- Inne funkcje platformy, takie jak usługa rekomendacji wideo, która poleca / sugeruje użytkownikom następne filmy, które mogą obejrzeć itp.
P # 14) Zaprojektuj wydajny system do obsługi 6 wind i upewnij się, że osoba musi czekać min. Czas, czekając na przybycie windy ?
Odpowiedź: Tego typu pytania dotyczące projektowania systemu są na niższym poziomie i oczekuje się, że kandydat najpierw przemyśli system windy i wyszczególni wszystkie możliwe funkcje, które muszą być obsługiwane, i zaprojektuje / utworzy klasy oraz relacje / schematy bazy danych jako rozwiązanie.
Z punktu widzenia SDET ankieter oczekiwałby po prostu głównych klas, które Twoim zdaniem miałaby Twoja aplikacja lub system, a podstawowe funkcjonalności byłyby obsługiwane za pomocą proponowanego rozwiązania.
Przyjrzyjmy się różnym funkcjonalnościom systemu windy, których można by się spodziewać
Możesz zadawać wyjaśniające pytania, takie jak
- Ile tam jest pięter?
- Ile jest wind?
- Czy wszystkie windy obsługują / osobowe windy?
- Czy wszystkie windy są skonfigurowane tak, aby zatrzymywały się na każdym piętrze?
Oto różne przypadki użycia, które mają zastosowanie do prostego systemu wind:
Jeśli chodzi o podstawowe klasy / obiekty tego systemu, możesz rozważyć posiadanie:
- Użytkownik: Zajmuje się wszystkimi właściwościami użytkownika i działaniami, które mogą wykonywać na obiekcie Elevator.
- Winda: Właściwości specyficzne dla windy, takie jak wysokość, szerokość, numer_seryjny_ windy.
- Drzwi windy: Wszystkie rzeczy związane z drzwiami, takie jak brak drzwi, rodzaj drzwi, automatyczne lub ręczne itp.
- Elevator_Button_Control: Różne przyciski / kontrolki dostępne w windzie i różne stany, w których te kontrolki mogą się znajdować.
Gdy skończysz, projektowanie klas i ich relacji, możesz porozmawiać o konfigurowaniu schematów bazy danych.
Kolejnym ważnym elementem systemu Elevator jest Eventing System. Możesz mówić o wdrażaniu kolejek lub w bardziej złożonej konfiguracji, tworząc strumienie zdarzeń za pomocą Apache Kafka, gdzie zdarzenia są dostarczane do odpowiednich systemów, na których mają działać.
System Eventing jest ważnym aspektem, ponieważ wielu użytkowników (na różnych piętrach) korzysta z windy w tym samym czasie. Dlatego żądania użytkownika powinny być umieszczane w kolejce i obsługiwane zgodnie ze skonfigurowaną logiką w kontrolerach Elevator.
Pytanie # 15) Zaprojektuj Instagram / Twitter / Facebook.
Odpowiedź: Wszystkie te platformy są w pewien sposób powiązane, ponieważ umożliwiają użytkownikom łączenie się w taki lub inny sposób i udostępnianie rzeczy za pośrednictwem różnych typów mediów - takich jak wiadomości / filmy i czaty.
Dlatego w przypadku tego typu aplikacji / platform społecznościowych należy uwzględnić poniższe punkty podczas omawiania projektowania takich systemów (oprócz tego, co omówiliśmy przy projektowaniu systemu skracania adresów URL):
- Szacowanie pojemności: Większość z tych systemów wymagałaby dużej ilości odczytu, dlatego wymagane jest oszacowanie wydajności, które umożliwiłoby nam zapewnienie odpowiedniej konfiguracji serwera i bazy danych w celu obsługi wymaganego obciążenia.
- Schemat DB: Główne ważne schematy bazy danych, które należy omówić, to - szczegóły użytkowników, relacje użytkowników, schematy wiadomości, schematy treści.
- Serwery hostingu wideo i obrazów: W większości tych aplikacji filmy i obrazy są udostępniane użytkownikom. Dlatego serwery hostujące wideo i obrazy powinny być skonfigurowane zgodnie z potrzebami.
- Bezpieczeństwo: Wszystkie te aplikacje powinny zapewniać wysoki poziom bezpieczeństwa dzięki informacjom o użytkowniku / informacjom umożliwiającym identyfikację użytkowników, które przechowują. Wszelkie próby włamania do SQL Injection na tych platformach nie powinny zakończyć się sukcesem, ponieważ może to kosztować utratę danych milionów klientów.
Problemy oparte na scenariuszach
Problemy oparte na scenariuszach są na ogół przeznaczone dla osób na wyższym szczeblu, gdzie podawane są różne scenariusze w czasie rzeczywistym, a kandydat jest pytany o jego przemyślenia, jak poradzą sobie w takiej sytuacji.
P # 16) Biorąc pod uwagę, że krytyczna poprawka musi zostać wydana tak szybko, jak to możliwe - jaką miałbyś strategię testowania?
Odpowiedź: Teraz, tutaj ankieter zasadniczo chce zrozumieć
- Jak i jakie rodzaje strategii testowych możesz wymyślić?
- Jakie pokrycie zrobiłbyś dla poprawki?
- Jak zweryfikowałbyś poprawkę po wdrożeniu? itp.
Aby odpowiedzieć na takie pytania, możesz wykorzystać sytuacje z życia codziennego, jeśli potrafisz odnieść się do problemu. Należy również wspomnieć, że bez odpowiednich testów nie byłbyś skłonny wypuścić żadnego kodu do produkcji.
W przypadku poprawek krytycznych należy zawsze współpracować z programistą i starać się zrozumieć, na jakie obszary może to wpłynąć, oraz przygotować środowisko nieprodukcyjne do replikacji scenariusza i przetestowania poprawki.
Ważne jest również, aby wspomnieć, że po wdrożeniu będziesz nadal monitorować poprawkę (za pomocą narzędzi do monitorowania, pulpitów nawigacyjnych, dzienników itp.), Aby zobaczyć wszelkie nietypowe zachowanie w środowisku produkcyjnym i upewnić się, że nie ma negatywnego wpływu poprawki, która gotowy.
Mogą być również inne pytania, które głównie mają na celu zrozumienie perspektywy kandydata w zakresie testowania automatyzacji, terminów dostaw itp. (I te pytania mogą się różnić w zależności od firmy, a także stażu pracy. Zazwyczaj te pytania są zadawane na poziomie wyższego / wiodącego) role)
P # 17) Czy poświęciłbyś pełne testowanie, aby szybko wypuścić produkt?
Odpowiedź: Te pytania zazwyczaj dotyczą osoby przeprowadzającej rozmowę, aby zrozumieć Twoje myśli z perspektywy przywództwa i jakie są rzeczy, z którymi chciałbyś pójść na kompromis, i czy byłbyś skłonny wypuścić wadliwy produkt zamiast mniej czasu.
Odpowiedzi na te pytania należy uzasadnić rzeczywistymi doświadczeniami kandydata.
Na przykład, można wspomnieć, że w przeszłości trzeba było odebrać telefon, aby wydać jakąś poprawkę, ale nie można było jej przetestować z powodu niedostępności środowiska integracyjnego. Więc wydałeś to w kontrolowany sposób - wdrażając do mniejszego procentu, a następnie monitorując dzienniki / zdarzenia, a następnie inicjując pełne wdrożenie itp.
P # 18) Jak stworzyłbyś strategię automatyzacji dla produktu, który w ogóle nie ma testów automatyzacji?
Odpowiedź: Tego typu pytania są otwarte i na ogół są dobrym miejscem do prowadzenia dyskusji w taki sposób, w jaki chcesz. Możesz również zaprezentować swoje umiejętności, wiedzę i obszary technologiczne, które są Twoją mocną stroną.
Na przykład, Aby odpowiedzieć na tego typu pytania, możesz przytoczyć przykłady strategii automatyzacji przyjętej podczas tworzenia produktu w przeszłości.
Możesz na przykład wspomnieć o takich punktach, jak:
- Ponieważ produkt wymagał rozpoczęcia automatyzacji od zera, masz wystarczająco dużo czasu na przemyślenie i zaprojektowanie odpowiedniego frameworka automatyzacji, wybierając język / technologię, którą większość ludzi posiadała, aby uniknąć wprowadzania nowego narzędzia i wykorzystać istniejącą wiedzę.
- Zacząłeś od automatyzacji najbardziej podstawowych scenariuszy funkcjonalnych, które uważano za P1 (bez których żadne wydanie nie mogło przejść).
- Pomyślałeś również o przetestowaniu wydajności i skalowalności systemu za pomocą zautomatyzowanych narzędzi testowych, takich jak JMETER, LoadRunner itp.
- Myślałeś o zautomatyzowaniu aspektów bezpieczeństwa aplikacji wymienionych w OWASP Normy bezpieczeństwa.
- Zintegrowałeś testy automatyczne w potoku kompilacji, aby uzyskać wczesne opinie itp.
Zespół Fit & Culture Fit
Ta runda zazwyczaj zależy od firmy do firmy. Ale potrzebą / koniecznością w tej rundzie jest zrozumienie kandydata z perspektywy zespołu i kultury organizacji. Celem tych pytań jest również zrozumienie osobowości kandydata i jego podejścia do pracy / ludzi itp.
Ogólnie rzecz biorąc, menedżerowie HR i zatrudniania są tymi, którzy przeprowadzają tę rundę.
Pytania, które zwykle pojawiają się podczas tej rundy, to:
P # 19) Jak rozwiązujecie konflikty w ramach waszej obecnej roli?
Odpowiedź: Dalsze wyjaśnienie: załóżmy, że masz konflikt ze swoim szefem lub najbliższymi członkami zespołu, jakie kroki podejmujesz, aby rozwiązać te konflikty?
W przypadku tego typu pytań uzasadnij jak najwięcej prawdziwymi przykładami, które mogły wydarzyć się w Twojej karierze w obecnych lub poprzednich organizacjach.
Możesz wymienić takie rzeczy jak:
- Lubisz jak najszybciej rozwiązywać wszelkie konflikty, które wynikają z przyczyn zawodowych (i nie chciałbyś z ich powodu wpływać na Twoje osobiste relacje).
- Możesz wspomnieć, że generalnie starasz się skutecznie komunikować i rozmawiać / dyskutować z osobą indywidualnie, aby rozwiązać wszelkie różnice / problemy.
- Możesz wspomnieć, że jeśli sytuacja zacznie się pogarszać, skorzystasz z pomocy starszej osoby / swojego kierownika i uzyskasz od niego / jej wkład.
Inne przykłady pytań dotyczących dopasowania / kultury do zespołu znajdują się poniżej (na większość z nich należy odpowiedzieć w podobny sposób, jak omówiliśmy w przypadku powyższego pytania. Kluczowe jest tutaj mówienie o scenariuszach z życia wziętych, ponieważ ankieter może lepiej je odnieść, ponieważ dobrze.
P # 20) Jakiego rodzaju równowagi między życiem zawodowym a prywatnym oczekujesz od nowej roli, na którą jesteś uważany za osobę zatrudnioną?
Odpowiedź: Ponieważ Hiring Manager to osoba, która wie, czego wymaga rola, ile dodatkowego wysiłku może czasami wymagać, więc na ogół ankieter próbuje ocenić, czy Twoje oczekiwania są radykalnie różne od tego, czego oczekuje rola.
Przypuśćmy, że powiesz że nie wolisz uczestniczyć w nocnych spotkaniach, a rola wymaga dużej współpracy między zespołem, który siedzi w innej strefie czasowej, wówczas osoba prowadząca rozmowę może zainicjować dyskusję, że takie są oczekiwania wobec roli - Czy będziesz w stanie przystosować się? itp.
Jest to więc bardziej luźna rozmowa, ale z perspektywy osoby przeprowadzającej rozmowę kwalifikacyjną chcą zrozumieć Twoje oczekiwania, aby ocenić Twoją kandydaturę na stanowisko, na które jest przeprowadzana rozmowa kwalifikacyjna.
P # 21) Jakie masz hobby poza pracą?
Odpowiedź: Te pytania są czysto subiektywne i specyficzne dla danej osoby, a te pytania są ogólnie przydatne, aby kandydat poczuł się zrelaksowany i łatwy oraz zainicjował niezobowiązujące dyskusje.
Ogólnie odpowiedzi na te pytania mogą być takie: lubisz czytać określony gatunek, lubisz muzykę, otrzymałeś jakąś nagrodę za jakąś działalność wolontariacką / filantropijną itp. Ponadto te pytania są zwykle zadawane w rundzie HR (i rzadziej zostanie zapytany przez osobę techniczną).
P # 22) Ile czasu jesteś skłonny poświęcić na aktywną naukę nowych narzędzi i technologii?
Odpowiedź: Tutaj ankieter ocenia twoją chęć uczenia się nowych rzeczy, jeśli rzuca się w ciebie czymś niezwykłym lub nowym. Pozwala również ankieterowi wiedzieć, że jesteś proaktywny? Czy chcesz zainwestować w siebie i swoją karierę? itp.
Odpowiadając więc na takie pytania - bądź szczery i uzasadniaj odpowiedzi przykładami - Na przykład, Możesz wspomnieć, że w zeszłym roku pojawiłeś się na certyfikacji Java i przygotowywałeś się poza pracą, poświęcając kilka godzin tygodniowo.
Wniosek
W tym artykule omówiliśmy proces rozmowy kwalifikacyjnej z inżynierem programistą w testach oraz przykładowe pytania, które są zazwyczaj zadawane kandydatom z różnych organizacji i profili. Ogólnie wywiady SDET mają bardzo szeroki charakter i są w dużym stopniu zależne od firmy do firmy.
Ale procesy wywiadów są podobne do tego, co jest dostępne dla profilu programisty, z większym naciskiem na jakość i ramy automatyzacji.
Ważne jest, aby zrozumieć, że w dzisiejszych czasach firmy są mniej skoncentrowane na jakimkolwiek konkretnym języku lub technologii, ale bardziej na szerokim zrozumieniu pojęć i umiejętnościach dostosowania się do narzędzi / technologii wymaganych przez firmę.
Najlepsze życzenia za rozmowę kwalifikacyjną z SDET!
rekomendowane lektury
- Co to jest SDET: poznaj różnicę między testerem a SDET
- Pytania i odpowiedzi do wywiadu
- ETL Pytania i odpowiedzi podczas rozmowy kwalifikacyjnej testującej
- Niektóre trudne pytania i odpowiedzi do testowania ręcznego
- Pytania do wywiadu Spocka z odpowiedziami (najpopularniejsze)
- 25 najlepszych pytań i odpowiedzi na rozmowę z testami zwinnymi
- 32 najlepsze pytania i odpowiedzi do wywiadów z danymi
- Ponad 20 pytań i odpowiedzi do wywiadów .NET
