sdet interview questions
테스트 인터뷰에서 소프트웨어 개발 엔지니어에 대한 전체 가이드를 읽고 다양한 라운드에서 묻는 SDET 인터뷰 질문에 대한 형식과 답변 방법을 알아보세요.
이 튜토리얼에서는 SDET 역할에 대해 자주 묻는 몇 가지 인터뷰 질문에 대해 알아 봅니다. 또한 일반적으로 인터뷰의 일반적인 패턴을 확인하고 인터뷰에서 탁월한 성과를 거둘 수있는 몇 가지 팁을 공유 할 것입니다.
이 튜토리얼의 코딩 문제에 Java 언어를 사용할 것이지만 대부분의 SDET 튜토리얼은 언어에 구애받지 않으며 인터뷰어는 일반적으로 후보자가 사용하기로 선택한 언어에 대해 유연합니다.
학습 내용 :
SDET 인터뷰 준비 가이드
대부분의 최고 제품 회사에서 SDET 인터뷰는 개발 역할에 대한 인터뷰 방식과 매우 유사합니다. 이는 SDET가 개발자가 알고있는 거의 모든 것을 광범위하게 알고 이해해야하기 때문입니다.
다른 점은 SDET 인터뷰 대상자가 판단되는 기준입니다. 이 역할의 면접관은 비판적 사고 능력과 인터뷰 대상자가 코딩에 대한 실무 경험이 있고 품질과 세부 사항에 대한 안목이 있는지 여부를 찾습니다.
다음은 SDET 인터뷰를 준비하는 사람이 주로 집중해야 할 몇 가지 사항입니다.
네트워크 주소 변환 (nat)을 수행하는 장치는 무엇입니까?
- 대부분의 경우 이러한 인터뷰는 기술 / 언어에 구애받지 않으므로 응시자는 필요할 때 새로운 기술을 배우고 기존 기술을 활용할 의향이 있어야합니다.
- 오늘날 SDET 역할은 여러 이해 관계자와 다양한 수준의 의사 소통 및 협업을 필요로하므로 우수한 의사 소통 및 팀 기술을 가져야합니다.
- 다양한 시스템 설계 개념, 확장 성, 동시성, 비 기능적 요구 사항 등에 대한 기본적인 이해가 있어야합니다.
아래 섹션에서는 몇 가지 샘플 질문과 함께 인터뷰의 일반적인 형식을 이해하려고 노력할 것입니다.
테스트 인터뷰에서 소프트웨어 개발 엔지니어의 형식
대부분의 회사는 때때로 SDET 역할에 대한 후보자를 인터뷰하는 선호하는 형식을 가지고 있으며 역할은 팀에 대해 매우 구체적이며 그 사람은 그 사람이 고용되는 팀에 완벽하게 적합하다고 평가 될 것으로 예상됩니다.
그러나 인터뷰의 주제는 일반적으로 다음 사항을 기반으로합니다.
- 전화 토론 : 일반적으로 선별 라운드 인 관리자 및 / 또는 팀원과의 대화.
- 작성된 라운드 : 테스트 / 테스트 케이스 특정 질문 포함.
- 코딩 능력 라운드 : 간단한 코딩 질문 (언어에 구애받지 않음) 및 응시자는 프로덕션 수준 코드를 작성해야합니다.
- 기본 개발 개념 이해 : OOPS 개념, SOLID 원칙 등
- 테스트 자동화 프레임 워크 설계 및 개발
- 스크립팅 언어 : Selenium, Python, Javascript 등
- Culture Fit / HR 토론 및 협상
SDET 인터뷰 질문 및 답변
이 섹션에서는 SDET 역할을 위해 고용하는 대부분의 제품 회사에서 요청하는 다양한 범주에 대한 자세한 답변과 함께 몇 가지 샘플 질문에 대해 설명합니다.
코딩 능력
이 라운드에서는 선택한 언어로 작성하기위한 간단한 코딩 문제가 제공됩니다. 여기에서 면접관은 코딩 구성에 대한 숙련도를 측정하고 에지 시나리오 및 널 검사 등과 같은 작업을 처리하려고합니다.
때때로 면접관은 작성된 프로그램에 대한 단위 테스트를 작성하도록 요청할 수도 있습니다.
몇 가지 샘플 문제를 살펴 보겠습니다.
Q # 1) 세 번째 (임시) 변수를 사용하지 않고 두 숫자를 바꾸는 프로그램을 작성하세요?
대답 :
두 개의 숫자를 바꾸는 프로그램 :
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 개의 no를 교체하도록 특별히 요청했습니다. 또한 솔루션을 제출하기 전에 항상 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)Q # 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
Q # 3) 숫자의 계승을 계산하는 프로그램을 작성하세요?
대답: Factorial은 거의 모든 인터뷰 (개발자 인터뷰 포함)에서 가장 자주 묻는 질문 중 하나입니다.
개발자 인터뷰의 경우 동적 프로그래밍, 재귀 등과 같은 프로그래밍 개념에 더 중점을 두는 반면, 테스트 관점의 소프트웨어 개발 엔지니어에서는 최대 값, 최소값, 음수 값 등과 같은 가장자리 시나리오 및 접근 / 효율성을 처리하는 것이 중요합니다. 중요하지만 부차적입니다.
음수를 처리하고 계승 함수를 호출하는 프로그램에서 처리해야하는 음수에 대해 고정 값 say -9999를 반환하는 재귀 및 for 루프를 사용하는 계승 프로그램을 살펴 보겠습니다.
아래 코드 스 니펫을 참조하세요.
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를 반환 함)
Q # 4) 주어진 문자열에 균형 잡힌 괄호가 있는지 확인하는 프로그램을 작성합니까?
대답:
접근하다 - 이것은 약간 복잡한 문제인데, 면접관은 단지 코딩 구조에 대한 지식보다 약간 더 많은 것을보고 있습니다. 여기서 예상되는 것은 당면한 문제에 적합한 데이터 구조를 생각하고 사용하는 것입니다.
많은 사람들이 이러한 유형의 문제에 대해 겁을 먹을 수 있습니다. 여러분 중 일부는 이러한 문제를 듣지 못했을 수 있기 때문에 간단하더라도 복잡하게 들릴 수 있습니다.
그러나 일반적으로 이러한 문제 / 질문에 대해서는 현재 질문에서 균형 잡힌 괄호가 무엇인지 모를 경우 면접관에게 질문 한 다음 사각 지대를 맞추는 대신 해결책을 향해 작업 할 수 있습니다.
솔루션에 접근하는 방법을 살펴 보겠습니다. 균형 잡힌 괄호가 무엇인지 이해 한 후 올바른 데이터 구조 사용에 대해 생각한 다음 솔루션 코딩을 시작하기 전에 알고리즘 (단계) 작성을 시작할 수 있습니다. 많은 경우 알고리즘 자체는 많은 에지 시나리오를 해결하고 솔루션이 어떻게 생겼는지에 대한 많은 명확성을 제공합니다.
솔루션을 살펴 보겠습니다.
균형 잡힌 괄호는 괄호 (또는 대괄호)를 포함하는 주어진 문자열을 확인하는 것입니다. 여는 횟수와 닫는 횟수가 같고 위치가 잘 구성되어 있어야합니다. 이 문제의 맥락에서 균형 잡힌 괄호를 –‘()’,‘()’,‘{}’와 같이 사용할 것입니다. 즉, 주어진 문자열은 이러한 대괄호의 조합을 가질 수 있습니다.
문제를 시도하기 전에 문자열에 대괄호 문자 또는 숫자 등이 포함되는지 확인하는 것이 좋습니다 (논리가 약간 변경 될 수 있음).
예: 주어진 문자열 – '{() {} ()} – 구조화되어 있고 닫는 괄호와 여는 괄호가 같지 않은 균형 잡힌 문자열이지만 문자열 –'{(}) {} () '–이 문자열 – 비록 여는 괄호와 닫는 괄호가 같지 않습니다. 닫는 '('없이는 '}'를 닫았 음을 알 수 있기 때문에 여전히 균형이 맞지 않습니다 (즉, 외부 괄호를 닫기 전에 모든 내부 괄호를 닫아야합니다).
이 문제를 해결하기 위해 스택 데이터 구조를 사용할 것입니다. 스택의 기본에 대해 더 알고 싶다면 여기
스택은 LIFO (Last In First Out 유형의 데이터 구조)이며 결혼식에서 접시 더미 / 더미로 생각하면 사용할 때마다 맨 위에있는 접시를 집을 수 있습니다.
연산:
#1) 문자 스택을 선언합니다 (문자열에 문자를 포함하고 일부 논리에 따라 문자를 밀어 내고 팝합니다).
# 2) 입력 문자열을 통과 할 때마다
- 여는 괄호 문자가 있습니다. 즉,‘(‘, {‘또는‘(‘-스택에 문자를 밀어 넣습니다.
- 닫는 문자 (예 : ')', '}', ')'가 있습니다. 스택에서 요소를 팝하고 닫는 문자의 반대와 일치하는지 확인합니다. 즉, 문자가 '}'이면 스택 팝에서 ' { '
- 팝된 요소가 닫는 괄호와 맞지 않는 경우 문자열이 균형을 이루지 않고 결과를 반환 할 수 있습니다.
- 그렇지 않으면 스택 푸시 및 팝 접근 방식을 계속합니다 (2 단계로 이동).
- 문자열이 완전히 순회되고 스택 크기도 0이면 주어진 문자열이 균형 잡힌 괄호 문자열이라고 말 / 추론 할 수 있습니다.
이 시점에서 알고리즘으로서의 솔루션 접근 방식에 대해 논의하고 면접관이 접근 방식에 동의하는지 확인하는 것이 좋습니다.
암호:
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 책임에 대해 더 구체적입니다. 자동화 프레임 워크 설계 및 개발 관련 질문, 다양한 접근 방식 사용의 장단점 등을 예상합니다.
이에 대한 몇 가지 샘플 질문과 솔루션을 살펴 보겠습니다.
Q # 5) 웹 애플리케이션을위한 자동화 프레임 워크의 구성 요소를 설명하고 설계합니까?
대답: 이 질문은 약간 주관적이며 면접관은 후보자가 프레임 워크 설계 및 개발에 대해 얼마나 알고 있는지 측정하려고합니다. 이 질문에 대한 답변은 응시자가 사용자 지정 프레임 워크를 처음부터 만들거나 만들 수 있는지 면접관이 이해하는 데 도움이됩니다.
이 질문에 대한 솔루션을 구성하는 데 도움이되는 몇 가지 사항을 살펴 보겠습니다.
- 데이터 기반, 키워드 기반, 하이브리드 프레임 워크와 같은 다양한 유형의 프레임 워크에 대해 이야기 할 수 있습니다.
- 웹 애플리케이션의 다른 페이지 / 모듈에 다양한 요소의 세부 사항을 저장하기위한 페이지 객체 모델.
- 도우미 기능, 유틸리티, 로거 등과 같은 공통 모듈
- 테스트 실행 보고서 생성, 보고서와 이메일 통합, 테스트 실행 예약 등과 같은보고 모듈
추천 자료 => 가장 인기있는 테스트 자동화 프레임 워크
Q # 6) 모바일 애플리케이션에 대한 테스트 전략을 설명 하시겠습니까?
대답: 이러한 질문은 일반적으로 역할에 따라 달라집니다. 역할이 주로 모바일 앱에서 작업하는 것이라면 문제는 더 관련성이 있습니다. 현재 또는 이전 역할의 일부로 모바일 테스트를 계획했다면 경험을 통해 이야기 할 수 있습니다.
이 질문에 대한 답을 구조화하기위한 몇 가지 지침은 다음과 같습니다.
- 기기와 에뮬레이터에서 테스트합니다.
- 다른 화면에서 개체 / 요소 식별 및 저장 – 예: 페이지 개체 모델.
- 모바일 애플리케이션 부하 테스트.
- 네이티브 앱, 하이브리드 앱과 같은 다양한 유형의 모바일 애플리케이션에 대해 이야기하고이를 테스트하는 데 사용할 전략 / 접근법에 대해 논의 할 수 있습니다.
추천 자료 => 모바일 앱 테스트 자습서
Q # 7) REST API 테스트를위한 자동화 프레임 워크를 설계합니까?
대답: 이것은 다시 주관적인 질문이며 면접관이 API의 기능적 동작을 테스트하기위한 프레임 워크를 개발하기를 원하는지 또는로드 / 성능 테스트와 같은 비 기능적 요구 사항을 개발하기를 원하는지에 대한 명확한 질문을 할 수 있습니다.
아래 사항에 대한 답변을 시작할 수 있습니다.
- 로컬 설정, API의 모의 설정 또는 호스팅 된 API 테스트와 같은 API 자동화 프레임 워크 구성 요소.
- API 자동화에 사용되는 도구. REST 기반 API의 기능적 측면을 검증하기 위해 즉시 사용할 수있는 다양한 도구가 있습니다. 이러한 도구로는 Postman, Rest Assured 등이 있습니다. 다양한 도구에 대한 자세한 내용은 기사를 참조하세요. 여기 .
- API의 비 기능적 자동화.
- 자동화 테스트의 예약 된 실행.
- API에 대한 자동화 테스트 통합.
Q # 8) 프레임 워크 관련 질문.
대답: 인터뷰 대상 프로필에 따라 응시자가 특정 프레임 워크에 능숙해야한다는 요구 사항이있을 수 있습니다. 셀레늄, JMeter 등
추천 자료 => 우편 집배원 , Mockito , Specflow , 셀렌 , JMeter
관련 테스트
드물지만 프로필에 따라 일반적인 테스트 관행, 용어 및 기술 (예 : 버그 심각도, 우선 순위, 테스트 계획, 테스트 케이스 등)에 대한 질문이있을 수 있습니다. SDET는 모든 수동 테스트 개념을 알고 있어야하며 익숙해야합니다. 중요한 용어와 함께.
이 섹션에서는 다음과 같은 질문을 예상 할 수 있습니다.
Q # 9) 테스트 계획의 다른 구성 요소는 무엇입니까?
대답: 이들은 일반적으로 기본 테스트 개념 및 사고 방식을 검증하도록 요청됩니다. 이러한 용어와 문서는 모든 수동 QA 및 자동화 SDET가 알아야 할 사항입니다.
여기에서 테스트 계획의 다양한 구성 요소를 논의 할 수 있습니다.
- 진입 및 퇴장 기준
- 범위: 범위 내에있는 테스트 기능과 모두 자동화 될 사항에 대해 논의합니다. 기능적 기능일까요 아니면 확장 성, 성능 등과 같은 비 기능적 요구 사항일까요?
- 타임 라인
- 사용할 도구
- 자원 할당 등
추천 자료 => 좋은 테스트 계획을 작성하는 방법
Q # 10) 버그의 우선 순위와 심각도를 정의하고 결정하는 것은 무엇입니까?
대답: 결함 우선 순위 및 심각도는 예제를 통해 쉽게 설명 할 수 있습니다. 가입과 같은 기능이 손상되어 사용자가 애플리케이션에 액세스하지 못하도록한다고 가정하면 우선 순위가 높고 심각도가 높은 문제입니다. 마찬가지로 심각도가 낮거나 우선 순위가 높은 결함 및 기타 다양한 조합의 예가있을 수 있습니다.
일반적으로
- 우선 순위 문제의 중요성을 나타냅니다.
- 심각성 문제가 애플리케이션의 고객 또는 사용자에게 미치는 영향을 나타냅니다.
추천 자료 => 결함 우선 순위 및 심각도
Q # 11) 등가 분할이란 무엇입니까? 예를 들어 설명하십시오.
대답: 등가 분할은 주어진 필드에 대해 다양한 입력 조합을 테스트하기 위해 블랙 박스 테스트에 주로 사용되는 기술입니다.
예를 들면 거래 애플리케이션을 테스트하고 '수량'필드에 대한 모든 테스트 시나리오를 작성하려는 경우이 필드에 대해 테스트 할 다른 입력은 무엇입니까?
기능적 요구 사항이 수량은 1에서 100000 사이의 양의 정수 값이어야한다는 점을 감안할 때. 따라서 다양한 입력 (유효 및 유효하지 않음)을 테스트하려면 각 카테고리에서 1 개의 입력에 대한 테스트를 수행 할 수 있습니다.
- 유효한 값 : 1에서 100000 사이-> x> 1 및 x가되도록 유효한 값 x 테스트<100000.
- 경계 값 : 허용 된 경계 값 (예 : 1 및 100000)을 테스트합니다.
- 잘못된 값 : 허용 된 범위를 벗어난 값 – 즉 x 100000과 같은 x에 대해 이러한 값을 테스트합니다.
추천 자료 => 등가 분할 전략
시스템 설계 관련
시스템 설계 질문은 일반적으로 개발자가 확장 성, 가용성, 내결함성, 데이터베이스 선택, 스레딩 등과 같은 다양한 일반 개념에 대한 폭 넓은 이해를 바탕으로 판단되는 개발자 인터뷰에 더 적합합니다. 간단히 말해서 전체를 사용해야합니다. 이러한 질문에 답하기위한 경험과 시스템 지식.
하지만 수년간의 경험과 수백 명의 개발자가 코딩하는 시스템이 어떻게 45 분 안에 질문에 답할 수 있을까요?
정답은: 여기서 기대하는 것은 응시자의 이해와 복잡한 문제를 해결하면서 적용 할 수있는 광범위한 지식을 판단하는 것입니다.
요즘에는 SDET 인터뷰에서도 이러한 질문이 던져지기 시작했습니다. 여기에서 기대치는 개발자 인터뷰와 동일하지만 판단 기준이 완화되고 대부분 후보자의 답변에 따라 후보자가 다음 레벨로 고려되거나 하위 레벨로 이동할 수있는 바 레이즈 라운드입니다.
일반적으로 시스템 설계 면접 질문의 경우 응시자는 아래 개념을 잘 알고 있어야합니다.
- 운영 체제의 기초 : 페이징, 파일 시스템, 가상 메모리 및 물리적 메모리 등
- 네트워킹 개념 : HTTP 통신, TCP / IP 스택, 네트워크 토폴로지.
- 확장 성 개념 : 수평 및 수직 확장.
- 동시성 / 스레딩 개념
- 데이터베이스 유형 : SQL / No SQL 데이터베이스, 어떤 유형의 데이터베이스를 사용해야할지, 다른 유형의 데이터베이스의 장점 및 단점.
- 해싱 기술
- 기본 이해 캡 정리, 샤딩, 분할 등
몇 가지 샘플 질문을 보겠습니다.
Q # 12) URL 단축 시스템을 작은 URL ?
대답: 많은 후보자는 일반적으로 URL 단축 시스템에 대해 알지 못할 수도 있습니다. 이 경우 이해하지 않고 잠수하는 대신 면접관에게 문제 설명에 대해 물어 보는 것이 좋습니다.
이러한 질문에 답하기 전에 응시자는 솔루션을 구성하고 글 머리 기호를 작성한 다음 면접관과 솔루션에 대해 논의해야합니다.
솔루션에 대해 간략하게 논의하겠습니다.
a) 기능 및 비 기능 요구 사항을 명확히합니다.
기능 요구 사항: 기능적 요구 사항은 단순히 고객의 관점에서 볼 때 큰 (긴 길이) URL이 제공되는 시스템이며 출력은 단축 된 URL이어야합니다.
단축 URL에 액세스하면 사용자를 원래 URL로 리디렉션해야합니다. 예를 들면 – https://tinyurl.com/ 웹 페이지에서 실제 URL을 줄이고 www.softwaretestinghelp.com과 같은 입력 URL을 입력하면 https://tinyurl.com/shclcqa와 같은 작은 URL이 표시됩니다.
비 기능적 요구 사항 : 시스템은 밀리 초 지연 시간 (원래 URL에 액세스하는 사용자를위한 추가 홉)으로 리디렉션 측면에서 성능이 우수해야합니다.
- 단축 된 URL에는 구성 가능한 만료 시간이 있어야합니다.
- 단축 된 URL은 예측할 수 없어야합니다.
b) 용량 / 트래픽 추정
이것은 모든 시스템 설계 질문의 관점에서 매우 중요합니다. 용량 예측은 기본적으로 시스템이받을 예상 부하를 결정합니다. 가정에서 시작하여 면접관과 논의하는 것이 항상 좋습니다. 이것은 또한 시스템이 읽기 나 쓰기가 많든 상관없이 데이터베이스 크기 조정을 계획하는 관점에서 중요합니다.
URL 단축기 예에 대해 몇 가지 용량 번호를 작성해 보겠습니다.
하루에 100,000 개의 새로운 URL 단축 요청이 있다고 가정합니다 (읽기-쓰기 비율이 100 : 1입니다. 즉, 단축 된 URL 1 개마다 단축 된 URL에 대해 100 개의 읽기 요청이 있음).
그래서 우리는
100k write requests/day => 100000/(24x60x60) => 1.15 request/second 10000k read requests/day => 10000000/(24x60x60) => 1157 requests/second c) 스토리지 및 메모리 고려 사항
용량 수치 다음에이 수치를 추정하여 얻을 수 있습니다.
- 예상 부하를 수용하는 데 필요한 저장 용량, 예를 들면 최대 1 년 동안 요청을 지원하는 스토리지 솔루션을 설계 할 계획입니다.
예: 단축 된 모든 URL이 50 바이트를 소비하는 경우 1 년 동안 필요한 총 데이터 / 스토리지는 다음과 같습니다.
=> total write requests/day x 365 x 50 / (1024x1024) => 1740 MB - 독자의 관점에서 시스템을 계획하려면 메모리 고려 사항이 중요합니다. 즉, 우리가 빌드하려는 시스템과 같이 읽기가 많은 시스템의 경우 (URL이 한 번 생성되지만 여러 번 액세스되기 때문입니다).
읽기가 많은 시스템은 일반적으로 캐싱을 사용하여 성능을 높이고 읽기 I / O를 절약하기 위해 영구 저장소에서 읽기를 피합니다.
읽기 요청의 60 %를 캐시에 저장하려고하므로 1 년 동안 총 읽기의 60 %가 각 항목에 필요한 바이트 x
=> (60/100) x 100000 x 365 x (50/1024x1024) => 1045 MB ~ 1GB따라서 용량 수치에 따라이 시스템에는 약 1GB의 실제 메모리가 필요합니다.
d) 대역폭 추정
시스템을 수행하는 데 필요한 읽기 및 쓰기 속도 (바이트)를 분석하려면 대역폭 추정이 필요합니다. 우리가 취한 용량 수치에 대해 추정 해 봅시다.
예: 단축 된 모든 URL이 50 바이트를 소비하는 경우 필요한 총 읽기 및 쓰기 속도는 다음과 같습니다.
WRITE - 1.15 x 50bytes = 57.5 bytes/s READS - 1157 x 50bytes = 57500 bytes/s => 57500 / 1024 => 56.15 Kb/s e) 시스템 설계 및 알고리즘
이것은 본질적으로 기능 요구 사항을 충족하는 데 사용되는 주요 비즈니스 논리 또는 알고리즘입니다. 이 경우 주어진 URL에 대해 고유 한 단축 URL을 생성하려고합니다.
단축 URL을 생성하는 데 사용할 수있는 다양한 접근 방식은 다음과 같습니다.
해싱 : 입력 URL의 해시를 생성하고 해시 키를 단축 URL로 할당하여 단축 URL 생성을 생각할 수 있습니다.
이 접근 방식은 서비스의 다른 사용자가있을 때 몇 가지 문제가있을 수 있으며 동일한 URL을 입력하면 동일한 단축 URL을 얻게됩니다.
미리 만들어진 단축 된 문자열서비스가 호출 될 때 URL에 할당됩니다.: 또 다른 방법은 이미 생성 된 문자열 풀에서 미리 정의 된 단축 문자열을 반환하는 것입니다.
서비스 API : URL 단축기 시스템은 다음과 같은 엔드 포인트가있는 REST 기반 API 세트로 생각할 수 있습니다.
- createUrl (문자열 URL, 날짜 / 시간 만료 시간) : 이 끝점은 입력에 지정된 만료 기간이 설정된 단축 URL을 생성하고 반환합니다.
- retrieveUrl (문자열 shortenedUrl) : 이 엔드 포인트는 주어진 단축 URL에 대해 리디렉션 할 URL을 검색합니다.
f) 확장 및 동시성
확장은 비 기능적 요구 사항 관점에서 중요한 고려 사항입니다.
어떻게 시스템을 다룰 수 있습니까?
- 부하시 확장 : 시스템은 예상치 못한 부하 급증이 발생한 후 작동을 중지하는 것이 아니라 부하 상태에서 정상적으로 확장 할 수 있어야합니다.
추천 자료 => 확장 기술
- 시스템이 얼마나 성능을 발휘할 수 있는지, 예를 들면 : 시스템을 장기간 지속 용량으로 사용하면 시스템 성능이 저하되거나 안정적으로 유지됩니까?
아래와 같이 다양한 시스템 설계 질문이있을 수 있지만 일반적으로이 모든 질문은 URL 단축 시스템 솔루션에서 논의한 다양한 개념에 대한 응시자의 폭 넓은 이해를 테스트합니다.
Q # 13) Youtube와 같은 비디오 플랫폼을 디자인하십시오.
대답: 위의 TinyUrl 질문에서 논의한 것과 유사한 방식으로이 질문에 접근 할 수도 있습니다 (거의 모든 시스템 설계 인터뷰 질문에 적용됨). 한 가지 차별화 요소는 설계하려는 시스템을 둘러보고 세부 사항을 살펴 보는 것입니다.
따라서 Youtube의 경우 우리 모두는 비디오 스트리밍 응용 프로그램을 알고 있으며 사용자가 새 비디오를 업로드하고 라이브 웹 캐스트를 스트리밍하는 등의 많은 기능을 가지고 있습니다. 따라서 시스템을 설계하는 동안 필요한 시스템 설계 구성 요소를 적용해야합니다. 이 경우 비디오 스트리밍 기능과 관련된 구성 요소를 추가해야 할 수 있습니다.
다음과 같은 요점을 논의 할 수 있습니다.
- 저장: 비디오 콘텐츠, 사용자 프로필, 재생 목록 등을 저장하기 위해 어떤 종류의 데이터베이스를 선택 하시겠습니까?
- 보안 및 인증 / 승인
- 캐싱 : YouTube와 같은 스트리밍 플랫폼은 성능이 뛰어나야하기 때문에 캐싱은 이러한 시스템을 설계하는 데 중요한 요소입니다.
- 동시성 : 얼마나 많은 사용자가 비디오를 병렬로 스트리밍 할 수 있습니까?
- 사용자가 볼 수있는 다음 동영상을 추천 / 제안하는 동영상 추천 서비스와 같은 기타 플랫폼 기능
Q # 14) 엘리베이터 6 대를 운영 할 수있는 효율적인 시스템을 설계하고 엘리베이터가 도착하기를 기다리는 동안 사람이 최소 시간을 기다려야합니다. ?
대답: 이러한 유형의 시스템 설계 질문은 더 낮은 수준이며 후보자가 먼저 엘리베이터 시스템을 생각하고 지원해야하는 가능한 모든 기능을 나열하고 클래스 및 DB 관계 / 스키마를 솔루션으로 설계 / 생성 할 것으로 기대합니다.
SDET 관점에서 면접관은 응용 프로그램이나 시스템이 가질 것이라고 생각하는 주요 클래스를 예상하고 기본 기능은 제안 된 솔루션으로 처리됩니다.
기대되는 엘리베이터 시스템의 다양한 기능을 살펴 보겠습니다.
다음과 같은 명확한 질문을 할 수 있습니다.
- 몇 층이 있습니까?
- 엘리베이터가 몇 대 있습니까?
- 모든 엘리베이터가 서비스 / 승객 리프트입니까?
- 모든 엘리베이터가 각 층에서 정지되도록 구성되어 있습니까?
간단한 엘리베이터 시스템에 적용 할 수있는 다양한 사용 사례는 다음과 같습니다.
이 시스템의 핵심 클래스 / 객체 측면에서 다음을 고려할 수 있습니다.
- 사용자: 사용자의 모든 속성과 그들이 Elevator Object에 대해 취할 수있는 작업을 다룹니다.
- 엘리베이터: 엘리베이터 높이, 너비, Elevator_serial_number와 같은 특정 속성.
- 엘리베이터 문 : 문 없음, 문 유형, 자동 또는 수동 등과 같은 문과 관련된 모든 것.
- Elevator_Button_Control : 엘리베이터에서 사용할 수있는 다양한 버튼 / 컨트롤과 해당 컨트롤이있을 수있는 다양한 상태.
완료되면 클래스 및 해당 관계를 설계하고 DB 스키마 구성에 대해 이야기 할 수 있습니다.
엘리베이터 시스템의 또 다른 중요한 구성 요소는 이벤트 시스템입니다. 큐를 구현하거나 이벤트가 작동 할 각 시스템에 전달되는 Apache Kafka를 사용하여 이벤트 스트림을 만드는 더 복잡한 설정에 대해 이야기 할 수 있습니다.
이벤트 시스템은 여러 사용자 (다른 층에있는)가 동시에 리프트를 사용하기 때문에 중요한 측면입니다. 따라서 사용자의 요청은 엘리베이터 컨트롤러에 구성된 로직에 따라 대기열에 추가되고 제공되어야합니다.
Q # 15) Instagram / Twitter / Facebook을 디자인하세요.
대답: 이러한 모든 플랫폼은 사용자가 어떤 방식 으로든 연결되고 메시지 / 비디오 및 채팅과 같은 다양한 미디어 유형을 통해 공유 할 수 있기 때문에 서로 관련이 있습니다.
따라서 이러한 유형의 소셜 미디어 응용 프로그램 / 플랫폼의 경우 이러한 시스템을 설계하는 동안 아래 사항을 포함해야합니다 (URL 단축기 시스템 설계에 대해 논의한 내용에 추가).
- 용량 추정 : 이러한 시스템의 대부분은 읽기가 많으므로 용량 추정이 필요하며 필요한로드를 처리하기 위해 적절한 서버 및 데이터베이스 구성이 보장되도록 할 수 있습니다.
- DB 체계 : 논의해야 할 주요 DB 스키마는 사용자 세부 정보, 사용자 관계, 메시지 스키마, 콘텐츠 스키마입니다.
- 비디오 및 이미지 호스팅 서버 : 이러한 응용 프로그램의 대부분에는 사용자간에 공유되는 비디오와 이미지가 있습니다. 따라서 비디오 및 이미지 호스팅 서버는 필요에 따라 구성해야합니다.
- 보안: 이러한 모든 앱은 저장하는 사용자의 사용자 정보 / 개인 식별 정보로 인해 높은 수준의 보안을 보장해야합니다. 해킹 시도, SQL 인젝션은 수백만 고객의 데이터 손실을 초래할 수 있으므로 이러한 플랫폼에서 성공해서는 안됩니다.
시나리오 기반 문제
시나리오 기반 문제는 일반적으로 다른 실시간 시나리오가 제공되고 후보자에게 그러한 상황을 어떻게 처리할지에 대한 생각을 묻는 고위급 사람들을위한 것입니다.
Q # 16) 중요한 핫픽스를 가능한 한 빨리 출시해야하는 경우 – 어떤 종류의 테스트 전략을 갖고 계십니까?
대답: 자, 여기서 면접관은 본질적으로
- 어떻게 그리고 어떤 종류의 테스트 전략을 생각할 수 있습니까?
- 핫픽스에 대해 어떤 범위를 적용 하시겠습니까?
- 배포 후 핫픽스를 어떻게 검증 하시겠습니까? 기타
그러한 질문에 답하기 위해 문제와 관련이 있다면 실제 상황을 사용할 수 있습니다. 또한 적절한 테스트 없이는 코드를 프로덕션에 릴리스 할 의향이 없음을 언급해야합니다.
중요한 수정 사항의 경우 항상 개발자와 협력하여 영향을 미칠 수있는 영역을 이해하고 시나리오를 복제하고 수정 사항을 테스트 할 비 프로덕션 환경을 준비해야합니다.
또한 배포 후 수정 사항을 모니터링 (모니터링 도구, 대시 보드, 로그 등을 사용)하여 프로덕션 환경에서 비정상적인 동작을 확인하고 수정 사항에 부정적인 영향이 없는지 확인해야한다는 점을 언급하는 것도 중요합니다. 끝난.
자동화 테스트, 제공 일정 등에 대한 응시자의 관점을 이해하기위한 다른 질문도있을 수 있습니다 (이러한 질문은 역할의 직급뿐 아니라 회사마다 다를 수 있습니다. 일반적으로 이러한 질문은 선임 / 리드 수준에서 요청됩니다. 역할)
Q # 17) 제품을 빨리 출시하기 위해 전체 테스트를 희생 하시겠습니까?
대답: 이러한 질문에는 일반적으로 면접관이 리더십 관점에서 귀하의 생각을 이해하고 타협 할 수있는 사항이 무엇인지, 더 짧은 시간 대신 버그가있는 제품을 출시 할 의향이 있는지가 포함됩니다.
이러한 질문에 대한 답변은 응시자의 실제 경험과 비교하여 입증되어야합니다.
예를 들면 과거에는 일부 핫픽스를 릴리스하기 위해 전화를 받아야했지만 통합 환경을 사용할 수 없기 때문에 테스트 할 수 없었습니다. 따라서 더 적은 비율로 롤아웃 한 다음 로그 / 이벤트를 모니터링 한 다음 전체 롤아웃을 시작하는 등 제어 된 방식으로 릴리스했습니다.
Q # 18) 자동화 테스트가 전혀없는 제품에 대한 자동화 전략을 어떻게 생성 하시겠습니까?
대답: 이러한 유형의 질문은 개방형이며 일반적으로 원하는 방식으로 토론 할 수있는 좋은 장소입니다. 또한 자신의 강점 인 기술, 지식 및 기술 영역을 선보일 수 있습니다.
예를 들면 이러한 유형의 질문에 답하기 위해 이전 역할에서 제품을 구축하는 동안 채택한 자동화 전략의 예를 인용 할 수 있습니다.
예를 들어, 다음과 같은 점을 언급 할 수 있습니다.
- 제품은 처음부터 자동화를 시작해야했기 때문에 대부분의 사람들이 새로운 도구를 도입하지 않고 기존 지식을 활용할 수있는 지식이있는 언어 / 기술을 선택하는 적절한 자동화 프레임 워크를 생각하고 설계 할 충분한 시간을 확보했습니다.
- P1로 간주되는 가장 기본적인 기능 시나리오를 자동화하는 것으로 시작했습니다 (릴리스가 진행되지 않는 경우).
- 또한 JMETER, LoadRunner 등과 같은 자동화 된 테스트 도구를 통해 시스템의 성능 및 확장 성을 테스트하는 것도 고려했습니다.
- 에 나열된대로 애플리케이션의 보안 측면을 자동화하는 것에 대해 생각했습니다. OWASP 보안 표준.
- 초기 피드백 등을 위해 빌드 파이프 라인에 자동화 된 테스트를 통합했습니다.
팀 핏 및 문화 핏
이 라운드는 일반적으로 회사마다 다릅니다. 그러나 이번 라운드의 필요성 / 필요성은 팀 및 조직 문화의 관점에서 후보자를 이해하는 것입니다. 이 질문의 목적은 또한 후보자의 성격과 직장 / 사람 등에 대한 접근 방식을 이해하는 것입니다.
일반적으로 HR 및 고용 관리자가이 라운드를 수행합니다.
이 라운드에서 일반적으로 나오는 질문은 다음과 같습니다.
Q # 19) 현재 역할 내에서 갈등을 어떻게 해결합니까?
대답: 추가 설명은 다음과 같습니다. 상사 또는 직속 팀원과 갈등이 있다고 가정하면 이러한 갈등을 해결하기 위해 어떤 조치를 취해야합니까?
이러한 유형의 질문은 현재 또는 이전 조직에서 경력 내에서 발생했을 수있는 실제 사례를 통해 가능한 한 많은 것을 입증합니다.
다음과 같은 것을 언급 할 수 있습니다.
- 전문적인 이유로 인해 발생하는 갈등을 가능한 한 빨리 정리하고 싶습니다 (이로 인해 개인 관계에 영향을 미치고 싶지 않음).
- 일반적으로 효과적으로 의사 소통을 시도하고 그 사람과 개별적으로 대화 / 토론하여 차이점 / 문제를 해결하려고한다고 언급 할 수 있습니다.
- 상황이 악화되기 시작하면 상급자 / 관리자의 도움을 받아 그 / 그녀의 의견을받을 것이라고 언급 할 수 있습니다.
팀 핏 / 컬처 핏 질문의 다른 예는 아래에 있습니다 (대부분은 위 질문에 대해 논의한 유사한 접근 방식으로 답변해야합니다. 면접관이 다음과 같이 더 나은 방식으로 관련시킬 수 있으므로 실제 시나리오에 대해 이야기하는 것이 핵심입니다. 잘.
Q # 20) 채용 된 것으로 간주되는 새로운 역할에서 어떤 일과 삶의 균형을 기대하십니까?
대답: 고용 관리자는 역할에 필요한 것이 무엇인지 아는 사람이므로 때때로 추가 노력이 얼마나 필요할 수 있으므로 일반적으로 면접관은 귀하의 기대가 역할이 기대하는 것과 근본적으로 다른지 측정하려고합니다.
당신이 야간 회의에 참석하는 것을 선호하지 않고 역할이 다른 시간대에있는 팀 간의 주요 협력을 기대하는 경우 면접관은 이것이 역할에서 기대하는 사항이라는 토론을 시작할 수 있습니다. 개조 하다? 기타
다시 말하지만, 이것은 평범한 대화에 가깝지만 면접관의 관점에서는 면접 대상 위치에 대한 후보자를 평가하기 위해 귀하의 기대치를 이해하려고합니다.
Q # 21) 일 외에 취미는 무엇입니까?
대답: 이 질문은 순전히 주관적이고 개별적이며 일반적으로 후보자가 편안하고 쉽게 느끼고 캐주얼 토론을 시작하는 데 유용합니다.
일반적으로 이러한 질문에 대한 답변은 다음과 같을 수 있습니다. 특정 장르를 읽는 것을 좋아하고, 음악을 좋아하고, 일부 자발적 / 자선 활동에 대한 상을 받았습니다. 또한 이러한 질문은 일반적으로 HR 라운드 (및 기술 담당자가 요청할 가능성이 적습니다.)
Q # 22) 새로운 도구와 기술을 사전에 배우는 데 얼마나 많은 시간을 할애 하시겠습니까?
대답: 여기서 면접관은 비정상적이거나 새로운 것이 당신에게 던져지면 새로운 것을 배우려는 당신의 의지를 측정합니다. 또한 면접관에게 당신이 능동적이라는 것을 알 수 있습니까? 자신과 경력에 기꺼이 투자 하시겠습니까? 기타
따라서 그러한 질문에 대답하는 동안 – 정직하고 예를 들어 대답을 입증하십시오 – 예를 들면 작년에 Java 인증을 받고 매주 몇 시간 씩 시간을내어 업무 외 준비를했다고 언급 할 수 있습니다.
결론
이 기사에서는 테스트 인터뷰 프로세스의 소프트웨어 개발 엔지니어와 다양한 조직 및 프로필의 후보자가 일반적으로 묻는 샘플 질문에 대해 논의했습니다. 일반적으로 SDET 인터뷰는 본질적으로 매우 광범위하며 회사마다 많이 의존합니다.
하지만 인터뷰 프로세스는 품질 및 자동화 프레임 워크에 더 중점을 두는 개발자 프로필의 프로세스와 유사합니다.
오늘날 기업은 특정 언어 나 기술에 덜 집중하고 있지만 개념에 대한 폭 넓은 이해와 회사에서 요구하는 도구 / 기술에 적응하는 능력에 더 중점을두고 있다는 사실을 이해하는 것이 중요합니다.
SDET 인터뷰를 기원합니다!
추천 도서
