머리말
예전에 인터뷰 질문 몇 개 봤는데 항상 유용할 것 같아서 몇 번이고 읽어보니 기억이 안나서 각계의 거물들이 공유하는 모든 인터뷰 질문을 통합했습니다. 스와이프, 여기저기 질문 찾아볼 필요 없이 오늘 정리한 면접질문들을 공유합니다. 동시에 모든 사람을 위한 소프트웨어 테스트 비디오 자습서도 준비했습니다. 바로 아래에서 필요한 경우 직접 시청하거나 기사 끝에 있는 작은 카드를 직접 클릭하여 정보 문서를 얻을 수 있습니다. 무료로
다음에서 무료 비디오 자습서를 시청하십시오.
https://www.bilibili.com/video/BV1SY4y1p7k6/?spm_id_from=333.999.0.0&vd_source=74d0257ec7066cc4f9013524f0bb70131. 인터뷰 후 JD 소프트웨어 테스트를 위한 30개의 질문(건조 제품)
1. 블랙박스 테스트를 위한 테스트 케이스의 일반적인 설계 방법은 무엇입니까? 테스트 사례 설계에서 이러한 방법의 적용을 설명하기 위해 구체적인 예를 사용하십시오.
1) 동등 클래스 구분: 동등 클래스는 입력 필드의 하위 집합을 의미하며, 이 하위 집합에서 각 입력 데이터는 프로그램의 오류를 드러내는 것과 같습니다. 다음과 같이 가정하는 것이 합리적입니다. 클래스는 이 클래스의 다른 값에 대한 테스트와 동일하므로 모든 입력 데이터를 합리적으로 여러 개의 동등 클래스로 나눌 수 있으며 각 동등 클래스의 데이터를 하나의 데이터를 테스트의 입력 조건으로 간주하고 소량 의 대표 테스트 데이터 좋은 테스트 결과 얻기 동등 클래스 분할은 두 가지 다른 상황이 있을 수 있습니다: 유효한 동등 클래스와 잘못된 동등 클래스.
2) 경계값 분석: 등가분할법의 보완이다. 테스트 업무 경험상 입력과 출력 범위 내보다는 입력과 출력 범위의 경계에서 오류가 많이 발생하는 것으로 나타나므로 다양한 경계 조건에 대한 테스트 케이스를 설계하면 더 많은 오류를 검출할 수 있다.
경계값 분석법을 이용하여 테스트 케이스를 설계하기 위해서는 먼저 경계조건이 결정되어야 하는데, 보통은 입력과 출력 등가 클래스의 경계가 테스트에 중점을 두어야 할 경계조건과 정확히 일치하는 값, 경계보다 약간 크거나 작은 것을 테스트 데이터로 선택해야 하며, 동등 클래스의 일반적인 값이나 임의의 값을 테스트 데이터로 선택하는 대신.
3) 오류 추측 방법: 경험과 직관을 기반으로 프로그램에서 발생할 수 있는 모든 오류를 추측하여 대상 방식으로 테스트 케이스를 설계합니다.
오류 추측 방법의 기본 개념: 프로그램에서 발생할 수 있는 모든 오류와 오류가 발생하기 쉬운 특수한 경우를 나열하고 이를 기반으로 테스트 사례를 선택합니다. 이전 제품 테스트 등에서 발견한 오류, 이것들은 경험의 요약입니다.또한 입력 데이터와 출력 데이터가 0입니다. 입력 폼이 비어 있거나 입력 폼이 한 줄만 있는 경우입니다. 오류가 발생하기 쉬우므로 이러한 상황을 선택할 수 있습니다. 다음 예제는 테스트 케이스로 사용됩니다.
4) 인과도법 : 위에서 소개한 등가분할법과 경계값 분석법은 모두 입력조건을 고려하는 데 초점을 두고 있으나, 입력조건과 상호결합 등의 관계는 고려하지 않는다. 새로운 상황이 발생할 수 있으나 입력조건의 조합을 확인하는 것은 쉬운 일이 아니며 모든 입력조건을 등가부류로 나누어도 상당히 많은 조합이 존재하므로, 다양한 조건의 조합을 설명하기 위해 그에 따라 테스트 케이스 설계를 고려하기 위해 여러 작업을 생성하는 데 적합한 채택을 고려할 필요가 있습니다. 인과 다이어그램(논리 모델)의 사용이 필요합니다. 인과 다이어그램 방법의 최종 결과는 다양한 조합의 프로그램 입력 조건을 확인하는데 적합합니다.
5) 직교 테이블 분석 방법: 많은 수의 매개변수 조합으로 인해 테스트 케이스 수가 급증할 수 있음과 동시에 이러한 테스트 케이스는 우선 순위에 명백한 차이가 없으며 테스터는 이러한 테스트를 완료할 수 없습니다. 많은 수의 테스트. , 직교 테이블을 통해 일부 사용 사례를 줄일 수 있으므로 가능한 한 적은 사용 사례로 가능한 한 넓은 범위를 커버할 수 있습니다.
6) 시나리오 분석 방법: 사용자 시나리오에 따라 사용자의 작업 단계를 시뮬레이션하는 것을 말하며 인과도와 유사하지만 실행 깊이와 실행 가능성이 더 높을 수 있습니다.
7) 상태 다이어그램 방법: 입력 조건 및 시스템 요구 사항 설명을 통해 테스트 대상 시스템의 모든 상태를 가져오고 입력 조건 및 상태를 통해 출력 조건을 얻습니다. 입력 조건, 출력 조건 및 상태를 통해 테스트 대상 시스템의 테스트 케이스를 얻습니다.
8) 아웃라인 방식: 아웃라인 방식은 요구 사항에 초점을 맞춘 방식으로 다양한 테스트 조건을 나열하기 위해 요구 사항을 아웃라인으로 변환한다. 아웃라인은 루트와 각 리프 노드 사이에 고유한 경로가 있는 트리 구조로 표시됩니다. 아웃라인의 각 경로는 테스트 사례를 정의하는 데 사용되는 특정 입력 조건 집합을 정의합니다. 개요의 트리 또는 경로의 잎 수는 모든 기능을 테스트하는 데 필요한 대략적인 테스트 사례 수를 제공합니다.
2. 테스트 활동의 전체 프로세스를 자세히 설명하십시오. (참고로 이 답변은 주로 폭포수 모델의 실습입니다)
프로젝트 관리자는 고객과 소통하여 요구사항 문서를 완성하고, 개발자와 테스터는 공동으로 요구사항 문서의 검토를 완료합니다.검토 내용에는 다음이 포함됩니다. . 프로젝트 관리자는 개발자, 테스터 및 고객의 의견을 통합하여 프로젝트 계획을 완성합니다. 그런 다음 SQA가 프로젝트에 들어가 통계 및 추적을 시작합니다.
개발자는 요구사항 문서에 따라 요구사항 분석 문서를 완성하고 테스터는 검토를 진행하며, 검토의 주요 내용은 양 당사자 간의 이해의 누락이나 차이가 있는지 여부입니다. 테스터는 테스트 계획 문서를 완성하고 테스트 계획에 포함된 내용은 위에 설명되어 있습니다.
테스터는 수정된 요구사항 분석 문서에 따라 테스트 케이스 작성을 시작하고 개발자는 개요 설계 문서와 세부 설계 문서를 완성합니다. 이 두 문서는 테스터가 테스트 케이스를 작성하기 위한 보조 자료가 됩니다.
테스트 케이스가 완료되면 테스트 및 개발을 검토해야 합니다.
테스터가 환경을 구축합니다.
개발자가 첫 번째 버전을 제출하며 설명이 필요한 미완성 기능이 있을 수 있습니다. 테스터는 테스트를 수행하고 버그를 찾은 후 BugZilla에 제출합니다.
개발팀은 버그 수정 및 일부 기능 추가를 포함한 두 번째 버전을 제출하고 테스터는 테스트를 수행합니다.
일반적으로 3-4개 버전 이후에 위의 작업을 반복하면 BUG의 수가 줄어들고 출하 요구 사항이 충족됩니다.
고객이 보고한 문제가 있는 경우 테스터는 재현 및 재테스트를 지원해야 합니다.
3. BUG 관리 도구의 추적 프로세스(예: BugZilla 사용)
테스터는 BUG를 찾아 Bugzilla에 제출하고 상태는 신규이며 BUG의 수신자는 개발 인터페이스 담당자입니다.
개발 인터페이스는 해당 모듈의 개발자에게 BUG를 할당하고 상태는 할당으로 변경 개발자와 테스트에서 BUG를 확인 내 자신의 BUG이면 수신으로 설정하고 다른 경우 이 동작을 수행하는 것은 다음 개발자의 몫이며, 문제가 아닌 경우 논의 및 확인하고 이 BUG를 거부한 다음 테스터가 이 문제를 종료합니다.
개발자가 BUG를 수용하고 수정하면 BUG의 상태를 수정됨으로 변경하고 테스트할 수 있는 버전을 알려줍니다.
테스터는 새 버전에서 테스트하고 문제가 여전히 존재하는 것으로 확인되면 확인을 거부하고 수정된 경우 BUG를 닫습니다.
4. 테스터와 개발자 간의 커뮤니케이션 과정에서 커뮤니케이션의 효율성과 효과를 높이는 방법은 무엇이라고 생각하십니까? 테스터와 개발팀의 다른 구성원 간에 좋은 대인 관계를 유지하는 비결은 무엇입니까?
대면 소통을 시도하고, 두 번째로 전화로 직접 소통을 해보세요 이메일과 같은 비적절한 소통 수단을 통해서만 소통할 수 있다면 그 특성에 대한 깊은 이해와 명확하게 표현할 수 있어야 함을 강조하세요.
또한 TestDirector와 같은 일부 테스트 관리 도구를 사용하여 관리하는 것이 더 효과적이며 동시에 TestDirector에는 BUG에 대한 정확한 설명이 있음을 유의해야 합니다.
팀의 테스터와 개발자 간의 원활한 의사 소통을 위해 다음 사항에 주의하십시오.
하나는 성실함, 다른 하나는 팀 정신, 세 번째는 직업에서 공통 언어를 갖는 것, 네 번째는 사람이 아닌 사물에 올바르고 일을 먼저 하는 것입니다.
물론 BUG 추적 시스템에 들어가지 않고 약간의 사소한 문제를 직접 지적함으로써 상대방의 호감도를 높일 수도 있습니다.
5. 테스트에서 가장 관심 있는 곳은 어디입니까? 왜?
이 면접 질문에 대한 고정적이고 통일된 답변은 없지만 많은 회사에서 질문할 수 있습니다. 고려해야 할 다음 답변을 제공하십시오.
가장 큰 관심, 도전적인 직업이라는 느낌;
테스팅은 경험 산업이기 때문에 오래 일할수록 테스팅을 잘하기가 어렵고 재미있을 것입니다.
자신의 작업을 통해 소프트웨어 제품을 점점 더 완벽하게 만들고 그 재미를 경험할 수 있습니다.
이러한 질문에 답할 때 다음 사항에 주의하십시오.
채용 회사의 기술 경로를 최대한 매칭하여 관심을 표현하십시오.예를 들어 회사가 데이터베이스 응용 회사인 경우 데이터베이스 테스트에 관심을 표시하고 테스트를 통해 데이터베이스 숙달을 향상시키십시오.
귀하의 테스트 목적이 귀하의 능력을 향상시키고 더 나은 테스트 작업을 수행하는 것임을 나타내십시오.
채용 회사의 범위 밖에서 너무 많은 관심을 표현하지 마십시오. 예를 들어, 채용 회사는 금융 소프트웨어를 하고 있지만 귀하는 게임 소프트웨어에 관심을 보였거나, 채용 회사는 JAVA 개발을 하고 있지만 귀하의 관심은 C 언어 프로그램 개발에 있습니다.
6. 테스트의 장점은 무엇이라고 생각하십니까?
본 면접에 정답은 없으나 다음 사항을 참고하여 본인의 특성을 종합하면 됩니다.
회복탄력성, 인내심, 조직력, 도전을 좋아함, 모든 일을 잘할 수 있다는 자신감, 강력한 의사소통 능력, 이전 관리자의 좋은 평가는 내가 잘하고 있음을 보여줌
7. 이전 작업에서 수행한 작업과 익숙한 작업에 대해 간략하게 설명합니다. 참고 답변은 다음과 같습니다.
과거에 저의 주요 업무는 시스템 테스트 및 자동화 테스트였습니다. 시스템 테스트에서는 BOSS 시스템의 비즈니스 로직 기능과 소프트스위치 시스템의 Class 5 특성을 주로 테스트한다. 성능 테스트에서는 주로 스트레스 테스트를 진행하며 요청 건수가 다른 경우 시스템 응답 시간과 시스템 자원 소모량을 구한다. 자동 테스트는 주로 자체 작성 스크립트와 일부 타사 도구의 조합을 통해 소프트 스위치의 특성을 테스트하는 것입니다.
테스트에서는 사용자의 요구 사항을 완전히 정확하게 이해하는 것이 매우 중요하다고 생각합니다. 또한 BUG 관리는 요구 사항에 따라야 하며 모든 BUG를 수정할 필요는 없습니다.
새 버전에서는 원래 발견된 BUG의 대부분이 수정되었지만 원래 올바른 기능도 올바르지 않을 수 있기 때문에 테스트 작업에는 인내와 세심함이 필요합니다. 따라서 반복 테스트와 회귀 테스트에 주의를 기울이십시오.
8. C/C++에서 정적의 용도는 무엇입니까? (최소 2개 이상 지정해주세요)
1) 함수 본문에서 static으로 선언된 변수는 함수가 호출되는 동안 그 값을 유지합니다.
2) 모듈 내부(그러나 함수 본문 외부)에서 static으로 선언된 변수는 모듈에서 사용되는 함수에서 액세스할 수 있지만 모듈 외부의 다른 함수에서는 액세스할 수 없습니다. 지역 전역 변수입니다.
3) 모듈에서 static으로 선언된 함수는 이 모듈의 다른 함수에 의해서만 호출될 수 있습니다. 즉, 함수는 선언된 모듈의 로컬 범위로 제한됩니다.
9. 참조와 포인터의 차이점은 무엇입니까?
1) 참조는 초기화되어야 하지만 포인터는 그렇지 않습니다.
2) 참조가 초기화된 후에는 변경할 수 없으며 포인터는 가리키는 개체를 변경할 수 있습니다.
3) null에 대한 참조는 없지만 null에 대한 포인터는 있습니다.
10. 인터넷은 어떤 네트워크 프로토콜을 사용합니까? 프로토콜의 주요 계층 구조? 인터넷 물리적 주소 및 IP 주소 변환에 사용되는 프로토콜은 무엇입니까?
TCP/IP 프로토콜의 주요 계층 구조는 애플리케이션 계층/전송 계층/네트워크 계층/데이터 링크 계층입니다.
ARP(주소 확인 프로토콜)(주소 확인 프로토콜)
11. 통합 테스트에서 하향식 통합과 상향식 통합의 두 가지 전략에 대한 이해도를 알려주고 각각의 장단점과 주로 적합한 테스트 유형에 대해 이야기하십시오.
하향식 통합
장점: 주요 제어 및 판단 지점이 더 일찍 검증됨, 완전한 소프트웨어 기능이 먼저 깊이에 따라 구현 및 검증될 수 있음, 기능이 더 일찍 검증되어 자신감을 가져옴, 하나의 드라이버만 필요하므로 드라이버 개발 비용 절감 , 오류 격리를 지원합니다.
단점: 컬럼의 개발량이 많고, 기본 검증이 지연되며, 기본 구성 요소에 대한 테스트가 충분하지 않습니다.
제품 제어 구조가 비교적 명확하고 안정적임, 상위 인터페이스가 거의 변경되지 않음, 하위 인터페이스가 정의되지 않았거나 자주 수정될 수 있음, 생산 및 항만 제어 구성요소가 높은 기술적 위험이 있어 가능한 한 빨리 검증해야 함 ; 가능한 한 빨리 제품의 기능 동작을 시스템에서 볼 수 있기를 바랍니다.
상향식 통합
장점: 기본 구성 요소의 동작을 조기에 확인, 초기에 작업을 병렬로 통합할 수 있어 하향식보다 효율적, 스텁의 작업 부하 감소, 오류 격리 지원.
단점: 드라이버의 개발 작업량이 많고 높은 수준의 검증이 지연되며 설계 오류를 적시에 찾을 수 없습니다.
기본 인터페이스는 상대적으로 안정적이고 상위 수준 인터페이스는 자주 변경되며 기본 구성 요소는 더 일찍 완료됩니다.
12. 소프트웨어 승인 테스트에는 공식 승인 테스트, 알파 테스트 및 베타 테스트가 포함됩니다.
13. 성능 테스트, 로드 테스트, 강도 테스트, 사용성 테스트, 보안 테스트, 구성 테스트, 설치 테스트, 문서 테스트, 장애 복구 테스트, 사용자 인터페이스 테스트, 복구 테스트 및 배포 테스트를 포함하여 시스템 테스트를 위한 많은 전략이 있습니다. 테스트, 사용성 테스트.
14. 시스템 테스트 계획을 설계할 때 참조해야 하는 프로젝트 문서에는 소프트웨어 테스트 계획, 소프트웨어 요구 사항 아티팩트 및 반복 계획이 포함됩니다
. 인과도를 그려서 테스트 케이스를 작성하는 단계는 ___, ___, ___, ___이고 인과도를 상태 다이어그램으로 변환하는 5단계가 있다. 원인 및 결과 다이어그램을 사용하여 테스트 케이스를 생성하는 기본 단계는 다음과 같습니다.
§ 원인(즉, 입력 조건 또는 입력 조건의 동등한 클래스)이고 결과(즉, 출력 조건)인 소프트웨어 사양 설명을 분석하고 각 원인과 결과에 식별자를 할당합니다.
§ 소프트웨어 사양 설명의 의미를 분석하고 원인과 결과 사이, 원인과 원인 사이에 해당 관계가 무엇인지 알아내고 이러한 관계에 따라 원인과 결과 다이어그램을 그립니다.
§ 문법적 또는 환경적 제약으로 인해 원인과 원인, 원인과 결과 간의 일부 조합이 불가능합니다. 이러한 특수한 경우를 나타내기 위해 인과도에 기호로 제약 또는 제한이 표시됩니다. § 인과관계도를 결정표로 변환합니다.
§ 판단 테이블의 각 열을 기준으로 삼아 테스트 케이스를 설계한다.
16. 누가 이 테스트를 가장 잘 수행하는지 알려주십시오. 그리고 그들은 무엇을 테스트하고 있습니까?
코드 및 기능 수준 테스트는 일반적으로 지정된 기능을 올바르게 구현하는지 확인하기 위해 각 코드 또는 기능의 정확성을 확인하는 화이트박스 테스터가 수행합니다.
모듈 및 구성 요소 수준 테스트의 주요 기반은 일반적으로 테스터가 완료하는 프로그램 구조 설계와 테스트 모듈 간의 통합 및 호출 관계입니다.
시스템 테스트는 모듈 테스트와 단위 테스트를 기반으로 수행됩니다. 시스템 기능 및 성능을 이해하고 테스트 케이스를 기반으로 종합적인 테스트를 수행합니다.
17. 테스트 케이스를 설계할 때 어떤 측면을 고려해야 합니까? 즉, 다른 테스트 케이스에서 어떤 측면을 테스트해야 합니까?
테스트 케이스를 설계할 때 전체 프로세스 및 기능뿐만 아니라 강도 테스트, 성능 테스트, 스트레스 테스트, 경계 값 테스트, 안정성 테스트, 보안 테스트 및 기타 측면에 주의를 기울여야 합니다. (테스트 케이스에서 고려해야 할 4가지 기본 요소는 입력, 출력, 운영 및 테스트 환경입니다. 또한 테스트 케이스는 테스트 유형(기능, 성능, 보안...)을 고려해야 하며, 이 부분은 TP를 참고하여 답할 수 있으며, Use Case의 중요도와 우선순위도 고려해야 함)
18. 윈도우에서 텍스트 파일을 저장할 때 저장 대화상자가 뜨는데 파일명에 대한 테스트 케이스가 생성된다면 동등 클래스는 어떻게 나누어야 할까요?
A와 같은 1바이트, 2바이트, AA, I I, 특수 문자 /'. ';, =- 등; com과 같은 예약어; 파일 형식이 8.3 형식임; 파일 이름 형식이 8.3 형식이 아님; /,, *와 같은 9개의 특수 문자.
19. 우편번호 10자리를 입력해야 하는 글상자가 있다고 가정할 때 글상자를 등가등급으로 어떻게 구분해야 할까요?
특수 문자(예: 10 * 또는 ¥), 영문자(예: ABCDefghik), 10자 미만(예: 123), 10자 이상(예: 11111111111), 숫자 및 기타 혼합(예: 123AAAAAAAA), 빈 문자, 예약 문자
20. 소프트웨어 테스트 프로젝트는 언제 시작되었습니까? 왜?
소프트웨어 테스팅은 요구사항 분석 단계에 포함되어야 하는데, 테스팅의 대상이 프로그램 코딩뿐만 아니라 소프트웨어 개발 과정에서 생성되는 모든 제품을 테스트해야 하고 소프트웨어 결함이 증폭되는 경향이 있기 때문입니다. 그것을 고치는 데 더 많은 비용이 들수록 비용이 커집니다.
21. 회귀 테스트란 무엇입니까?
회귀 테스트: (회귀 테스트): 회귀 테스트에는 유스 케이스 회귀 및 오류 회귀의 두 가지 유형이 있습니다. 유스 케이스 회귀는 문제가 발견되는지 확인하기 위해 일정 기간 후에 이전에 사용된 유스 케이스를 다시 테스트하는 것 다시. 버그 회귀는 이전 버전에서 나타나고 수정된 결함을 새 버전에서 다시 확인하고 해당 결함을 핵심으로 수정된 부분을 테스트하는 방법입니다.
22. 단위 테스트, 통합 테스트 및 시스템 테스트의 초점은 무엇입니까?
단위 테스팅은 소프트웨어 설계의 가장 작은 단위인 프로그램 모듈(프로세스 지향에서는 기능과 프로시저, 객체 지향에서는 클래스)을 대상으로 하며, 정확성 검사를 위한 테스트 작업은 각 프로그램 모듈 내부에 존재할 수 있는 오류를 찾는 것입니다. 일반적으로 , 두 가지 단계가 있습니다: 수동 정적 검사 \ 동적 실행 추적
통합 테스트는 단위 테스트를 통과한 각 모듈이 통합한 구성 요소를 검사하는 것을 목표로 하며 주요 내용은 각 단위 모듈과 구현된 기능 간의 인터페이스입니다
. 시스템 테스트는 통합 소프트웨어 시스템을 대상으로 전체 컴퓨터 시스템의 한 요소로서 컴퓨터 하드웨어\주변\일부 지원 소프트웨어\데이터 및 인력과 같은 다른 시스템 요소와 결합됩니다.일련의 통합 테스트 및 확인 테스트는 운영 환경의 컴퓨터 시스템에서 수행됩니다.
23. 테스트 엔지니어는 어떤 자질을 갖추어야 합니까?
1. 책임감 2. 커뮤니케이션 능력 3. 팀워크 정신 4. 인내, 신중함, 자신감 5. 항상 회의적인 태도를 유지하고 결함 예방에 대한 인식 6. 일정한 프로그래밍 경험 보유
24. 어떤 유형의 소프트웨어 테스팅을 알고 있으며 간단히 소개합니다.
테스트 전략에 따라 분류: 1. 정적 및 동적 테스트 2. 블랙 박스 및 화이트 박스 테스트 3. 수동 및 자동 테스트 4. 스모크 테스트 5. 회귀 테스트;
테스트 단계에 따라 분류: 단위 테스트, 통합 테스트, 시스템 테스트;
기타 일반적인 테스트 방법: 1. 기능 테스트 2. 성능 테스트 3. 스트레스 테스트 4. 로드 테스트 5. 사용성 테스트 6. 설치 테스트 7. 인터페이스 테스트 8. 구성 테스트 9. 문서 테스트 10. 호환성 테스트 11. 보안 테스트 12 , 복구 테스트
25. 테스트 계획을 잘 세우기 위한 핵심은 무엇이라고 생각하십니까?
테스트 목표를 명확히 하고 테스트 계획의 실행 가능성을 높입니다.
소프트웨어 테스트 계획을 작성하는 중요한 목적은 테스트 프로세스에서 더 많은 소프트웨어 결함을 발견할 수 있도록 하는 것이므로 소프트웨어 테스트 계획의 가치는 테스트 프로젝트를 관리하고 잠재적인 소프트웨어 결함을 찾는 데 도움이 되는 기능에 달려 있습니다. 따라서 소프트웨어 테스트 계획의 테스트 범위는 기능 요구 사항을 많이 포함해야 하고 테스트 방법은 실용적이어야 하며 테스트 도구는 매우 실용적이고 사용하기 쉬워야 하며 생성된 테스트 결과는 직관적이고 정확해야 합니다.
"5W" 규칙을 준수하고 내용과 프로세스를 명확히 합니다.
"5W" 규칙은 "무엇을(what to do)", "왜(why do it)", "언제(when to do it)", "어디(where)", "어떻게(how to do it)"를 의미합니다. ". "5W" 규칙을 사용하여 소프트웨어 테스트 계획을 작성하면 테스트 팀이 테스트 목적(이유)을 이해하고 테스트 범위 및 내용을 명확히 하고(무엇) 테스트 시작 및 종료 날짜를 결정(언제)할 수 있습니다. ), 테스트 방법 및 도구(How), 테스트 문서 및 소프트웨어의 저장 위치(Where)를 지정합니다.
테스트 계획이 실제 요구 사항을 충족하는지 확인하기 위해 검토 및 업데이트 메커니즘을 채택합니다.
테스트 계획서 작성 후 검토를 거치지 않은 경우 테스트팀으로 직접 전달 테스트 계획서의 내용이 부정확하거나 테스트 내용이 누락될 수 있으며 변경으로 인해 테스트 범위가 증감될 수 있습니다. 소프트웨어 요구 사항에서 테스트 계획의 내용이 제 시간에 업데이트되지 않아 오해의 소지가 있습니다.
테스트 계획 및 테스트 세부 사양, 테스트 케이스 각각 작성
세부 테스트 기술 지표는 독립적으로 작성된 테스트 세부 사양 문서에 포함되어야 하며, 테스트 팀이 테스트 프로세스를 실행하도록 안내하는 테스트 케이스는 독립적으로 작성된 테스트 케이스 문서 또는 테스트 케이스 관리 데이터베이스에 배치되어야 합니다. 테스트 계획과 테스트 사양 및 테스트 케이스 사이에는 전략적, 전술적 관계가 있습니다.테스트 계획은 주로 거시적 관점에서 테스트 활동의 범위, 방법 및 리소스 할당을 계획하는 반면 테스트 사양 및 테스트 케이스는 특정 테스트 작업을 완료하기 위한 전술.
26. 테스트 케이스 디자인을 잘하기 위한 핵심은 무엇이라고 생각하십니까?
화이트박스 테스트 케이스 설계의 핵심은 더 적은 수의 테스트 케이스로 가능한 한 많은 내부 프로그램 논리 결과를 다루는 것입니다.
블랙박스 사용 사례 설계의 핵심은 더 적은 사용 사례로 모듈 출력 및 입력 인터페이스를 다루는 것입니다. 가장 적은 사용 사례로 합리적인 시간 내에 가장 많은 문제를 찾기 위해 완전히 테스트하는 것은 불가능합니다.
27. 테스트 경력 개발 목표는 무엇입니까?
테스트 경험이 많을수록 테스트 능력이 높아집니다. 그래서 내 경력 개발에는 시니어 테스트 엔지니어를 향해 단계적으로 축적할 시간이 필요합니다. 또한 예비 경력 계획이 있으며 처음 3 년 동안 테스트 경험을 축적하고 지속적으로 자신을 업데이트하고 수정하며 테스트 작업을 잘 수행합니다.
28. 시험 종료 기준이 어떻게 되나요?
미시적인 관점에서 테스트 계획에 정의되어 있습니다.예를 들어 시스템이 일정 성능 하에서 72시간 동안 원활하게 실행됩니다.현재 버그 추적 시스템에서는 이 버전에 일반적인 심각한 버그가 없습니다.숫자 일반적인 버그는 3개 미만이고 버그 수정률은 90%입니다.위의 매개 변수 등을 확인한 다음 개발 관리자, 테스트 관리자 및 프로젝트 관리자가 서명하여 버전 릴리스에 동의합니다.
매크로에 대해 이야기하면 소프트웨어가 완전히 사라지면 테스트가 종료됩니다.
29. 완전한 테스트 세트는 어떤 단계로 구성되어야 합니까?
타당성분석, 요구사항분석, 일반설계, 상세설계, 코딩, 단위테스팅, 통합테스팅, 시스템테스팅, 인수테스팅
30. 과거에 일했던 회사의 소프트웨어 개발 프로세스를 알고 있습니까? 그렇다면 전체 개발 프로세스에서 어떤 작업을 수행해야 하는지 설명해주세요. 이러한 작업을 수행하기 위한 다른 역할은 무엇입니까? 이전 테스트 작업에서 수행한 특정 작업은 무엇입니까? 업무 중 가장 잘하는 부분은 무엇입니까?
개발 프로세스 - 요구 사항 조사(요구 담당자), 요구 사항 분석(요구 사항 담당자), 개요 설계(디자이너), 상세 설계(디자이너), 코딩(개발자)
테스트 프로세스 - 요구 사항 검토, 시스템 테스트 설계, 요약 설계 검토, 통합 테스트 설계, 상세 설계 검토, 단위 테스트 설계, 테스트 실행
테스트 작업의 전체 프로세스를 수행하고 테스트 디자인에 능숙합니다.
프로세스가 품질을 결정하고 소프트웨어 프로세스 개선은 소프트웨어의 품질을 향상시키고 과거의 다양한 경험과 교훈을 축적하는 것입니다.
2. 소프트웨어 테스팅의 고전적인 인터뷰 질문이 모두 여기에 있으며 처음 5개의 질문을 해야 합니다.
질문 1: 소프트웨어 테스팅 산업을 선택한 이유는 무엇입니까?
답변: 저는 소프트웨어 테스팅을 좋아하기 때문에 소프트웨어 테스팅을 직업으로 선택했습니다. 소프트웨어 테스팅은 소프트웨어 프로그래밍보다 더 도전적이고 창의적인 직업이라고 생각합니다. (개발을 계속할 수 없어서 소프트웨어 테스트를 선택했다고 말하지 말고, 코드를 입력하는 것이 싫다고 말하지 마십시오)
질문 2: 소프트웨어 테스팅에 대한 당신의 이해에 대해 말해주시겠습니까?
대답: 소프트웨어 테스팅은 소프트웨어 기능을 확인하고 결함, 버그 및 오작동 없이 우수한 표준의 소프트웨어 제품을 생산하는 프로세스입니다.
질문 3: 테스트 로그는 무엇입니까?
대답: 테스트 로그에는 소프트웨어 테스트 중에 수행된 작업의 전체 목록이 포함되어 있으며 테스트 로그에서 테스트 통과 또는 실패 여부를 알 수 있습니다.
질문 4: 수동 테스트와 자동 테스트의 차이점은 무엇입니까?
답변: 수동 테스트는 사용자가 수동으로 수행하고 자동 테스트는 사전 스크립트의 도움으로 자동으로 수행됩니다. 자동 테스트는 더 빠르고 안전하며 비용 효율적인 반면 수동 테스트는 느리고 덜 안전합니다.
질문 5: 화이트 박스 테스트와 블랙 박스 테스트의 차이점은 무엇입니까?
답변: 화이트 박스 테스트는 사용자가 내부 구조의 실현을 알아야 하는 소프트웨어 테스트 방법인 반면 블랙 박스 테스트에서는 사용자가 사용자의 내부 작업 모듈을 알 필요가 없습니다. 화이트 박스 테스트에서는 사용자가 프로그래밍 기술을 가지고 있어야 하지만 블랙 박스 테스트에서는 사용자에게 프로그래밍 기술이 필요하지 않습니다.
질문 6: 블랙박스 테스트의 이점은 무엇입니까?
답변: 블랙 박스 테스트는 프로그래밍 지식이 거의 없는 사용자가 수행할 수 있으며 화이트 박스 테스트 프로세스보다 훨씬 빠릅니다. 소프트웨어의 모든 구성 요소와 모듈이 테스트되지 않았기 때문에 소프트웨어 제품에 오류가 발생할 수 있습니다.
질문 7: 화이트 박스 테스트의 장점은 무엇입니까?
답: 프로그래머가 각 구성 요소를 테스트하므로 화이트 박스 테스트는 더 높은 품질의 소프트웨어 제품을 보장합니다. 이는 블랙박스 테스트보다 더 많은 시간이 소요되는 긴 프로세스입니다.
질문 8: 회귀 테스트란 무엇입니까?
A: 소프트웨어가 변경되거나 수정되면 소프트웨어 기능이 제대로 작동하는지 확인하고 소프트웨어에 의도하지 않은 버그가 없는지 확인하기 위해 다시 테스트하십시오. 이 테스트 프로세스를 회귀 테스트라고 합니다.
질문 9: 기능 테스트란 무엇입니까?
A: 기능 테스트는 고객 사양에 대한 테스트 및 검증 프로세스이며 모든 고객 요구 사항을 충족합니다.
질문 10: 테스트 케이스와 테스트 스크립트 간의 관계는 무엇입니까?
세 번째, 소프트웨어 테스트 공통 면접 질문
1. 시험의 단계는 무엇입니까?
일반적으로 단위 테스트, 통합 테스트, 확인 테스트, 시스템 테스트, 승인 테스트의 다섯 단계로 나뉩니다.
2. 소프트웨어 테스트 방법은 무엇입니까?
블랙 박스, 화이트 박스, 그레이 박스.
3. 데이터베이스에서 sum과 count의 차이점과 사용
일반 면접은 합계와 그룹별 순서를 함께 사용합니다.
개수: 쿼리한 데이터 레코드의 수를 세십시오: 학생 테이블에서 개수(*)를 선택하십시오
.
4. 모듈 테스트 케이스 설계
면접관의 경험, 유스케이스 설계능력, 사고력, 숙달된 테스팅 방법 등이 종합적인지 조사
기능 테스팅, 인터페이스 테스팅, 예외 테스팅, 성능, 보안 테스팅 측면에서 분석
5. pytest는 테스트 케이스를 어떻게 관리합니까?
테스트로 시작, 테스트 이름을 딴 클래스 등 케이스 규칙 숙달
단일 py 케이스 파일 실행 방법, 여러 폴더 관리 방법
6. 소프트웨어 테스팅 산업을 선택한 이유는 무엇입니까?
이전에 소프트웨어 테스트 산업에 대해 알고 있었기 때문에 그의 개발 전망이 매우 좋다고 생각합니다.
(개발을 할 수 없을 때 테스트로 전환한다고 말하지 마십시오!)
7. 소프트웨어 테스트 유형은 무엇입니까?
테스트 유형에는 기능 테스트, 성능 테스트, 인터페이스 테스트가 포함됩니다.
8. 테스트 케이스란 무엇이며, 테스트 스크립트란 무엇이며, 둘 사이의 관계는 무엇입니까?
테스트 구현을 위해 테스트 중인 시스템에 제공되는 특정 입력 데이터, 작업 또는 다양한 환경 설정 및 예상 결과 집합입니다.
테스트 스크립트는 자동화된 테스트를 위해 작성된 스크립트입니다.
테스트 스크립트 작성은 해당 테스트 케이스와 일치해야 합니다.
9. 테스트 계획과 테스트 케이스는 어떻게 작성하는가?
간단하게 하기 위해 테스트 계획에는 상세한 테스트 전략과 테스트 방법, 합리적이고 상세한 리소스 배치 등이 포함되어야 합니다. 테스트할 수 있는지 여부는 기다리십시오.
10. 소프트웨어 테스트 전략은 무엇입니까?
소프트웨어 테스트 전략: 특정 소프트웨어 테스트 표준 및 테스트 사양의 지침에 따라 테스트 프로젝트의 특정 환경 제약 조건에 따라 규정된 소프트웨어 테스트 원칙, 방법 및 방법 모음.
소프트웨어 테스팅에 대한 일반적인 필기 시험 질문:
참 또는 거짓(Y=예, N=거짓)
1. 소프트웨어 테스트의 목적은 가능한 한 많은 소프트웨어 결함을 찾는 것입니다. (와이)
2. 베타 테스트는 일종의 수락 테스트입니다. (와이)
3. 승인 테스트는 최종 사용자가 수행합니다. (N)
4. 테스터는 프로젝트가 승인되기 전에 아티팩트를 제출할 필요가 없습니다. (와이)
5. 단위 테스트는 소프트웨어 결함의 약 80%를 찾을 수 있습니다. (와이)
6. 코드 검토는 소스 코드가 모듈 설계 요구 사항을 충족하는지 확인하는 것입니다. (N)
7. 상향식 통합을 위해서는 테스터가 드라이버를 작성해야 합니다. (와이)
8. 부하 테스트는 테스트 대상 시스템의 최고 수준의 성능을 확인하는 것입니다. (N)
9. 테스터는 원칙을 준수하여야 하며, 하자가 수리되지 않은 경우 불합격 처리한다. (N)
10. 코드 리뷰어는 일반적으로 테스터가 제공합니다. (N)
11. 인위적으로 소프트웨어 구성 문제를 무료로 만들 수 있습니다. (N)
12. 통합 테스트 계획은 요구 사항 분석 단계가 끝날 때 제출됩니다. (N)
다중 선택
1. 다음 논리 커버리지 테스트 방법 중 가장 커버력이 강한 것은 (라)
ㅏ. 진술 범위 b. 판단 범위 다. 조건 범위 d. 조건 조합 범위
2. 블랙박스 테스트와 화이트박스 테스트의 차이점에 대해 다음 중 올바른 설명은 무엇입니까? (A)
ㅏ. 화이트박스 테스트는 프로그램 구조에 초점을 맞추는 반면 블랙박스 테스트는 기능
B 에 초점을 맞춥니다. 화이트 박스 테스트는 자동 테스트 도구를 사용할 수 있지만 블랙 박스 테스트는 도구를 사용할 수 없습니다.문제에 대한 집중 강의 100개 다
. 화이트박스 테스트는 개발자의 참여가 필요한 반면 블랙박스 테스트는 그렇지 않습니다
. 블랙 박스 테스트는 화이트 박스 테스트보다 더 널리 사용됩니다.
3. HTTP 프로토콜의 상태 코드 표현과 관련하여 다음 중 잘못된 설명(D)
ㅏ. 1**: 클라이언트 오류
B．2*: 요청이 성공적으로 수신되었음을 나타냅니다 *
C. 3**: 요청이 완료되었으며 고객이 요청을 더 세분화해야 함을 나타냅니다.
D. 4**: 서버 오류를 나타냅니다.
4. Linux에서 bugzilla.tar.gz의 압축을 풀고 tar 명령으로 처리된 파일 이름을 자세히 보고하려면 명령 (A)를 사용해야 합니다.
A．tar –xvzf bugzilla.tar.gz B．tar –cvzf bugzilla.tar.gz
C．tar –cvzf bugzilla.tar.gz D．tar –cxvf bugzilla.tar.gz
5. Redhat linux 9에서 소프트웨어 패키지 perl.i386.rpm을 설치하고 설치 중에 #을 사용하여 설치 진행률을 표시하려면 사용해야 하는 명령은 (A)입니다.
A．rpm –ih perl.i386.rpm B．rpm –i perl.i386.rpm
C．rpm –e perl.i386.rpm D．rpm –V perl.i386.rpm
6. Linux의 vi 편집기에서 변경 사항을 저장하지 않고 vi를 종료하려고 합니다. 명령을 사용해야 하는 경우는 (C)입니다.
A．:qa B．:qw C．:q! D．:!q
7. 데이터베이스에는 두 개의 데이터 테이블이 저장되어 있습니다: Teacher 테이블(교사 번호, 교사 이름) 및 커리큘럼 테이블(과목 번호, 과목 이름, 교사 번호) 특정 교사가 가르치는 과목을 빠르게 찾기 위해 다음 인덱스를 사용합니다. 확립 올바른 방법은 (C)
ㅏ.
교사 ID B 로 교사 테이블에 인덱스를 작성하십시오.
과정 번호 C 로 커리큘럼에 대한 인덱스를 만듭니다.
교사 번호 D 로 커리큘럼에 대한 색인을 만듭니다. 교사 이름으로 교사 테이블의 인덱스
8. 책 테이블의 책 이름(bookname)에 "computer"가 포함된 모든 책의 상황을 쿼리하려면 문 (B)를 사용할 수 있습니다.
A. SELECT * FROM book WHERE bookname LIKE 'computer'
B. SELECT * FROM book WHERE book_name LIKE '%computer%'
C. SELECT * FROM book WHERE book_name='computer'
9. 알파 테스트에 대한 다음 설명 중 올바른 것은 무엇입니까? (AD)
A.alpha 테스트는 사용자 대표의 참여를 요구합니다.
B.alpha 테스트는 사용자 대표의 참여를 요구하지 않습니다.
C.alpha 테스트는 일종의 시스템 테스트입니다.
D.alpha 테스트는 승인 테스트의 한 유형입니다.
10. 누가 소프트웨어 테스트 계획 검토에 참여합니까?(ABCD)
A. 프로젝트 관리자
B. SQA 리더
C. 구성 리더
D. 테스트 그룹
4. 응답이 있는 전체 네트워크에서 가장 완벽한 소프트웨어 테스트 인터뷰 질문(성능 테스트 + 기능 테스트 + 인터페이스 테스트 + 자동 테스트)
성능 시험
성능 테스트 프로세스를 간략히 설명하십시오.
1. 성능 요구 사항을 분석합니다.
2. 성능 테스트 계획을 개발합니다.
3. 테스트 케이스 작성
4. 테스트 환경 구축 및 테스트 데이터 준비
5. 성능 테스트 스크립트 작성
6. 성능 테스트 스크립트 튜닝
7. 테스트 시나리오를 설계합니다.
8. 테스트 결과를 분석합니다.
9. 회귀 성능 테스트.
10. 테스트 보고서를 작성합니다.
성능 테스트는 어떤 환경에서 언제 수행됩니까?
우리는 테스트를 위한 독립적인 성능 테스트 환경을 구축할 것입니다.시간적으로
벤치마크 테스트: 기능 테스트 후 시스템이 비교적 안정될 때 수행합니다.
부하 테스트: 아무도 시스템을 사용하지 않는 한밤중에
think_time의 역할은 무엇입니까?
실제 프로덕션 사용자 작업을 시뮬레이션하여 서버에 미치는 영향을 조사합니다.
성능 테스트 결과가 신뢰할 수 있음을 확인한 후 다음과 같은 문제가 발견되면 아래 제공된 아이디어에 따라 문제를 찾습니다.
인증 코드 기능으로 성능 테스트를 수행하는 방법은 무엇입니까?
1. 인증코드를 일시적으로 차단했다가 성능 테스트 완료 후 복원
2. 범용 인증코드 사용
성능 테스트 지표는 무엇입니까?
응답 시간
처리량
cpu
메모리
io
디스크
기능 테스트
소프트웨어 테스트 산업에 대해 어떻게 생각하십니까? 소프트웨어 테스트를 선택해야 하는 이유는 무엇입니까?
소프트웨어 테스팅은 장래가 촉망되는 직업입니다. 저는 이 업계에서 더 많은 경험을 가지고 있습니다. 저는 이 직책에 매우 적합하다고 생각하고 굳건히 가고 싶습니다.
테스트 중에 버그가 발견되었지만 개발자가 버그가 아니라고 생각하는 경우 어떻게 해야 합니까?
먼저 결함 관리 플랫폼에 문제를 제출하여 제출 및 등록하십시오. 그런 다음 판단의 근거와 기준을 얻으려면 다음을 수행하십시오.
요구 사항 사양, 제품 설명, 설계 문서 등에 따라 실제 결과가 계획과 일치하지 않는지 확인하고 결함 확인을 위한 직접적인 근거를 제공합니다.
문서 근거가 없는 경우 유사 소프트웨어의 일반적인 특성을 기준으로 결함이 있는지 확인하여 불일치 여부를 설명할 수 있습니다.
사용자의 일반적인 사용 습관에 따라 결함 여부를 확인하기 위해;
설계자, 개발자, 상품담당자 등 관련 담당자와 상의하여 불량 여부를 확인합니다.
합리적으로 토론하고, 시험 관리자에게 판단 이유를 설명하고, 객관성과 엄격함에 주의하고, 개인적인 감정을 섞지 마십시오. 제품 관리자가 최종 결정을 내릴 때까지 기다리십시오. 여전히 분쟁이 있는 경우 테스트 관리자에게 확인하십시오. 온라인 보고서를 보낼 때 이 버그의 위험을 조기 경고로 남겨두고 프로젝트의 모든 사람에게 이 사실을 알립니다. 상황.
테스트 케이스를 설계하는 방법은 무엇입니까?
등가 클래스, 경계 값, 결정 테이블, 원인 및 결과 다이어그램.
소프트웨어 테스트 전략은 무엇입니까?
소프트웨어 테스트 전략: 특정 소프트웨어 테스트 표준 및 테스트 사양의 지침에 따라 테스트 프로젝트의 특정 환경 제약 조건에 따라 규정된 소프트웨어 테스트 원칙, 방법 및 방법 모음.
소프트웨어 개발 프로세스에서 테스터의 작업은 무엇입니까?
(1) 가능한 한 빨리 시스템의 버그를 찾으십시오.
(2) 소프트웨어 개발 과정에서 결함을 방지합니다.
(3) 소프트웨어의 품질을 측정하고 시스템의 품질을 보장합니다.
(4) 사용자의 요구에 주의를 기울이고 시스템이 사용자의 요구를 충족하는지 확인합니다. 전반적인 목표는 소프트웨어의 품질을 보장하는 것입니다.
인터페이스 자동화 테스트
get과 post의 차이점은 무엇입니까?
요청 받기, 브라우저는 http 헤더와 데이터를 함께 보내고, 서버는 200 응답 코드
Psot 요청을 반환하고, 브라우저는 먼저 헤더를 보내고, 서버는 100(계속)에 응답한 다음 데이터를 보내고, 서버는 200 응답을 반환합니다. 코드
포스트는 높아지는 것보다 더 안전합니다
인터페이스 자동화에서 연결을 처리하는 방법은 무엇입니까?
이전 요청에서 반환된 결과를 다음 요청의 매개변수로 전달하고, 요청 결과를 클래스 속성에 반영하고(setattr() 함수 사용) 다음 요청에서 클래스 속성을 호출합니다.
자동 테스트 결과를 어떻게 확인합니까?
어설션, 예상 결과를 실제 결과와 비교
테스트 시나리오에 따라 데이터베이스의 데이터를 쿼리하고 요청하기 전에 데이터를 비교하는 데이터베이스 확인
매개변수화 및 데이터 기반에 대한 귀하의 이해에 대해 말씀해 주시겠습니까?
이 질문은 자동화 테스트에서 매우 중요한 두 가지 개념인 매개변수화와 데이터 기반을 포함합니다. 실제로 테스트 스크립트와 데이터의 분리라는 동일한 것 같습니다. 예: 로그인 스크립트는 원래 고정된 테스트 데이터 세트(사용자 이름, 비밀번호)를 작성했습니다. 데이터가 변경될 때마다 스크립트를 변경해야 하는데 스크립트에서 데이터를 분리하려면 사용자 이름과 비밀번호를 외부, 가급적이면 외부 파일에 추출하는 것을 매개변수화라고 합니다.
성능 테스트를 위해 각 가상 사용자가 실제 비즈니스 시나리오에 더 가까운 다른 사용자 이름과 암호로 로그인하는지 확인하려고 합니다. 자동화된 테스트를 위해 다양한 유형의 사용자 이름, 비밀번호와 같은 다양한 데이터 조합을 테스트하고 싶습니다. 시나리오와 관계없이 여러 데이터 집합이 있어야 하지만 로그인 작업 프로세스는 고정되어 있습니다. 이를 데이터 기반이라고 합니다.
일반 개발 언어에 대한 단위 테스트 프레임워크에는 Python의 ddt 모듈 및 TestNG의 DataProvider 주석과 같은 데이터 기반 기능이 있습니다.
인터페이스에서 생성된 가비지 데이터를 어떻게 정리합니까?
위와 동일하게 데이터 생성 및 데이터 정리를 위해 Python을 사용하여 데이터베이스에 연결하고 추가, 삭제, 수정 및 쿼리 작업 수행
테스트 케이스 사전 작업, 데이터 준비를 위한 설정
사후 작업, 데이터를 위한 tearDown 청소
WebUI 자동화 테스트의 측면
셀레늄에 원소가 존재하는지 확인하는 방법은 무엇입니까?
요소의 존재 여부를 판단하는 기본 방법은 없습니다. 일반적으로 요소 찾기 + 예외 캡처로 판단할 수 있습니다.
숨김 또는 표시 = 없음 요소가 셀레늄에 있을 수 있습니까?
아니요, 클릭하려면 js를 사용하여 display=none 속성을 제거할 수 있습니다.
Selenium 스크립트의 실행 속도를 높이는 방법은 무엇입니까?
1. 테스트 사례를 최적화합니다.
2. 불필요한 작업 단계를 줄입니다.
3. 페이지 로드를 중단합니다.
4. 셀레늄 그리드를 사용합니다.
지속적인 통합이란 무엇입니까?
간선에 코드를 자주 통합하고 프로젝트의 지속적인 구축을 진행하여 오류를 빠르게 발견하고 분기가 간선에서 크게 벗어나지 않도록 합니다.
계층화 테스트란 무엇입니까?
1. 데이터 계층
2. 인터페이스 계층'
3. UI 계층
앱 테스트
IOS 휴대전화와 Android 휴대전화의 차이점, 시스템에 대해 설명해 주세요.
두 가지 작동 메커니즘이 다릅니다. IOS는 샌드박스 작동 메커니즘을 사용하고 Android는 가상 머신 작동 메커니즘을 사용합니다.
둘의 배경 시스템은 다릅니다: IOS의 모든 타사 프로그램은 백그라운드에서 실행할 수 없으며 Android의 모든 프로그램은 백그라운드에서 실행할 수 있으며 메모리가 부족할 때까지 닫히지 않습니다.
앱의 성능 테스트, 즉 특수 테스트는 어떤 부분에 중점을 두어야 한다고 생각하시나요?
메모리, CPU 사용량, 전력 소비량, 트래픽 등
Android 시스템의 4계층 아키텍처에 대해 간단히 소개해주세요.
위에서 아래로 응용 프로그램 계층, 응용 프로그램 프레임워크 계층, 시스템 런타임 계층 및 Linux 코어 계층입니다.
테스트 중에 앱에서 충돌 또는 ANR이 발생하면 어떻게 하시겠습니까?
먼저 로그를 필터링할 수 있습니다: adb logcat | findstr xxxxx(로그 정보 필터링), 그런 다음 예외, 충돌과 같은 키워드를 검색하여 문제를 전송한 방법이나 예외를 확인하고 처음 이후에 문제의 원인 찾기 , 근본적인 원인을 찾아 수정하기 위해 개발자에게 넘겨줄 수 있습니다.
실용적인 Android UI 자동화 테스트 도구를 간략하게 소개해주세요.
appium: 네이티브 애플리케이션, 모바일 웹 애플리케이션 및 하이브리드 애플리케이션을 테스트하는 데 사용할 수 있는 모바일 자동화 프레임워크이며 크로스 플랫폼입니다.
로보티움(robotium): 주로 안드로이드 플랫폼 애플리케이션의 블랙박스 자동화 테스트를 위한 외국 안드로이드 자동화 테스트 프레임워크로, 다양한 제스처 동작(클릭, 길게 누르기, 슬라이드 등), 검색 및 어설션 메커니즘을 시뮬레이트하기 위한 API를 제공하며, 다양한 컨트롤을 조작합니다.
전체 스택 자동화 테스트 인터뷰 질문
1. 웹 자동화 테스트 면접 질문
1. Selenium의 hidden 또는 display = none 요소를 찾을 수 있습니까?
아니요, JavaScript를 작성하여 레이블의 숨겨진 항목을 먼저 0으로 변경한 다음 요소를 배치할 수 있습니다.
2. Selenium에서 작동 요소의 성공률을 보장하는 방법은 무엇입니까? 즉, 내가 클릭한 요소가 클릭 가능해야 하는지 확인하는 방법은 무엇입니까?
요소 지능형 대기 시간 추가 driver.implicitly_wait(30)
필수 대기 시간 추가(예: 파이썬에서 절전 쓰기)
다른 방법으로 id, 이름, 클래스, x 경로, css 선택기를 찾으려고 시도합니다. 첫 번째 선택이 실패하면 자동으로 할 수 있습니다. 두 번째 것을 시도하십시오 두 종류
3. Selenium 스크립트의 실행 속도를 높이는 방법은 무엇입니까?
코드 최적화, 멀티태스킹 및 분산 배포는 모두 스크립트 실행 속도를 향상시킬 수 있습니다.
4. 유스 케이스는 실행 프로세스 중에 종종 불안정합니다. 즉, 이번에는 통과할 수 있지만 다음에는 통과하지 않습니다.유스 케이스의 안정성을 개선하는 방법은 무엇입니까?
time.sleep( )
driver.implicitly_wait(30)
try를 사용하여 예외를 캡처하고 처리합니다.
5. 자동화 사용 사례의 실행 전략은 무엇입니까?
자동화 테스트는 본질적으로 소프트웨어 개발과 동일하며 자동화 테스트 도구를 사용하고 테스트 요구 사항을 분석하여 자동화 테스트 케이스를 설계하여 자동화 테스트 프레임워크를 구축하고 자동화 스크립트를 설계 및 작성하고 테스트 스크립트의 정확성을 확인하고 최종적으로 자동화를 완료합니다. 테스트 스크립트(즉, 주요 기능이 테스트인 응용 소프트웨어) 및 출력 테스트 결과.
6. 자동 테스트 중 데이터 검증을 위해 데이터베이스에 연결해야 합니까?
데이터베이스 수준의 데이터 검증은 시스템의 데이터 처리가 올바른지 보다 쉽게 검증할 수 있으며, 데이터 처리 로직이 정상인 후에는 UI 수준의 검증도 수행해야 합니다.
7. id, name, class, xpath, css selector 속성 중 선호하는 속성과 그 이유는 무엇입니까?
css와 xpath의 거의 모든 요소를 찾을 수 있지만 페이지에서 요소가 변경된 후 위치가 변경되기 쉽기 때문에 id나 name을 먼저 사용한다는 단점이 있습니다.
8. 페이지에서 동적으로 로드된 요소를 찾는 방법은 무엇입니까?
위치 지정을 위해 동적 요소가 나타날 때까지 동적으로 로드된 요소의 이벤트를 트리거합니다.
9. 속성이 동적으로 변경되는 요소를 찾는 방법은 무엇입니까?
xpath 또는 css는 형제, 부모 및 자식을 통해 찾습니다.
10. 링크를 클릭하면 Selenium이 페이지가 로드될 때까지 자동으로 대기합니까?
할 것이다
11. 페이지 개체 디자인 패턴이란 무엇입니까?
간단히 말해서, 페이지를 객체로 사용하고, 사용 중인 페이지 객체를 전달하고, 페이지 객체에서 해당 멤버 또는 메서드를 사용하여 객체 지향 및 캡슐화 기능을 더 잘 반영할 수 있습니다. 언어(예: Java 또는 Python).
12. 요소를 배치한 후(디버깅 목적으로) 요소를 강조 표시하려면 어떻게 해야 합니까?
JavaScript와 같은 스크립트를 사용하여 요소 속성을 재설정하고 배치된 요소에 배경과 테두리를 추가합니다.
13. 어설션이란 무엇입니까?
어설션은 프로그램이 이미 가지고 있어야 하는 상태 또는 프로그램 실행 중 특정 시점에서 프로그램 변수 집합이 충족해야 하는 조건을 지정하는 논리식입니다.
14. 자동 테스트의 가장 큰 결함은 무엇이라고 생각하십니까?
불안정한
신뢰성 비용과 이익을
유지하기 어려움
2. APPUI 자동화 테스트 면접 질문
1. Android APP의 메모리가 부족할 때 시스템은 메모리 확보 프로세스를 어떻게 종료합니까?
시스템은 일시 중단된(일시 중단된) 프로세스를 종료하는 데 우선 순위를 부여하고 메모리를 해제합니다.
2. APP 테스트에서 흔히 발생하는 심각한 문제는 무엇입니까? 원인은 각각 무엇입니까?
일반적인 것은 충돌 및 ANR(응용 프로그램 응답 없음, 중단)이며 일반적으로 장치 조각화, 대규모 네트워크 변동, 메모리 누수 및 코드 작성 오류로 인해 발생합니다.
3. 사용해본 APP 자동화 테스트 도구에 대해 간단히 소개해주세요.
주관적인 의견이 포함된 개방형 질문
다른 친숙한 자동화 도구의 장단점을 비교하십시오.
자동화를 위한 간략한 계획(핵심 콘텐츠에 대해 간략하게 설명하십시오). (힌트: 앱늄 등)
4. Android 테스트와 웹 테스트의 차이점은 무엇입니까?
같은 점:
테스트 케이스의 설계는 등가 클래스, 경계값 등의 방법을 기반으로 하며 테스트 원칙은 동일하며
대부분 블랙박스 테스트 방법을 사용하여 비즈니스 기능을 검증하고
인터페이스 레이아웃, 스타일 여부를 확인해야 합니다. , 버튼이 아름답고 통일됨(UI 테스트)
;페이지 로딩 및 페이지 넘김 속도, 로그인 시간 초과 여부 및 기타 문제(성능 테스트)는
애플리케이션 시스템의 안정성을 테스트합니다.
차이점:
휴대폰은 통신 도구로 사용되며 통신과 같은 일부 동작은 APP(인터럽션 테스트)를 유발합니다.
휴대폰 사용자의 앱 제품 설치 및 제거: 이전 버전/이전 2개 버전에서 최신 버전으로 직접 업그레이드합니다.
웹 자동화 테스트에 가장 일반적으로 사용되는 도구는 Selenium이며 Android 휴대폰 자동 테스트에 더 일반적으로 사용되는 자동화 도구는 Monkey, Monkeyrunner 및 Appium입니다(테스트 도구는 다름).
5. 앱 테스트를 위한 환경은 어떤 것이 있나요?
로컬 환경: 앱이 설치된 휴대폰 환경과 컴퓨터에 구축된 자동화된 테스트 환경(예: Android SDK 등
).
서버 환경: war 패키지에 의해 배포된 서버, 서버는 브라우저 또는 앱을 통해 액세스할 수 있습니다
. (Access는 웹 프로그램의 인터페이스입니다)
6. Android SDK의 설치 단계를 간략하게 소개합니다.
jdk 및 Android SDK를 다운로드하여
jdk 설치, 환경 변수(java_home, classpath, path) 구성
7. 모바일 어플리케이션의 테스트 포인트와 서버에 대해 간단히 소개 부탁드립니다.
모바일 애플리케이션은 주로 권한, 설치, 운영 및 제거, UI, 기능, 성능, 중단, 호환성, 보안,
회귀, 업그레이드 및 업데이트, 사용자 경험을 포함합니다. (앱의 11대 주요 테스트 포인트)
서버는 인터페이스 테스트, 성능 테스트, 보안 테스트가 있습니다.
8. 앱 버그가 클라이언트 문제인지 백그라운드 문제인지 판단하는 방법
이것은 비즈니스에 따라 다릅니다.일반적인 데이터 문제에는 프런트 엔드 문제가 더 많습니다.일반적인 접근 방식은 프런트 엔드 개발자에게 문제를 제기하는 것입니다.그들은 그것이
자신의 문제인지 백그라운드에서 반환된 데이터인지 알고 있습니다.
9. Android에서 로그 정보를 검색하는 방법은 무엇입니까?
Android 시스템의 로그 정보를 실시간으로 로컬로 가져옵니다. adb logcat -v time > d:\mylog.log
앱을 실행하고 사용하여 앱의 로그 정보를 실시간으로 가져옵니다(반환 정보는 cmd).
adb shell monkey -p com.android.calendar -v 1000 > d:\mylog2.log
10. 일반 adb 명령:
현재 연결된 장치 보기: adb devices
소프트웨어 설치: adb install path\xx.apk
소프트웨어 제거: adb uninstall <패키지 이름>
컴퓨터에서 장치로 파일 보내기: adb push <로컬 경로> <원격 경로>
adb push C:\ test1. txt /sdcard/
장치에서 컴퓨터로 파일 다운로드: adb pull <remote path> <local path>
adb pull /sdcard/test1.txt D:
실시간으로 로그 가져오기: adb logcat -v time > D:\mylog. log
터미널 장치 셸에 로그인:
패키지 이름/활동 이름을 찾기 위한 adb shell: adb logcat | findstr START
(스크립트에서 cmp= 뒤의 값은 패키지 이름/활동 이름)
시작 APP 시작
adb shell am start -n packageName/activity
앱 닫기
구문: adb shell am force-stop 패키지 이름
모니터 APP 시작 시간
adb shell am start -W packageName/activity
Monkey 명령:
adb shell monkey -v -p mypackage 50
11. APP의 많은 주류 모델을 테스트하는 방법은 무엇입니까?
우리 회사는 그것을 구입했습니다, Meizu, Huawei, Xiaomi, iphone7, iphone8, iphone8plus, iphone
x 호환성 테스트, 사용할 수없는 일부 모델, 먼저 테스트를 위해 동료의 휴대폰을 빌려 동시에 구매하도록 회사에 신청 , 또는
클라우드 실제 머신을 사용하십시오.
12. 앱 충돌(플래시백), 이유는 무엇일까요?
너무 많은 캐시 쓰레기: Android 시스템의 특성상 오랫동안 정크 파일을 정리하지 않으면 점점 더 정체됩니다. 플래시백도 있습니다. 너무 많은 프로그램이 실행되어 결과적
으로 메모리 부족
응용 프로그램 버전 호환성 문제: 응용 프로그램 버전이 너무 낮으면 비호환성 및 충돌이 발생합니다. 또한 일부 새 버전이 디버깅되고 있으며 이로 인해 응용 프로그램이 충돌할 수도 있습니다. 해결 방법: 버전이 너무 오래된 경우 새 버전으로 업데이트하면 됩니다.
APP이 네트워크에 접속하는 위치와 컴포넌트에 있는 ImageView가 정상적으로 다운로드되어 앱 페이지에 표시되는지 확인합니다.
앱의 SDK가 휴대폰 시스템과 호환되는지 확인합니다.
Android 5.0을 Android 6.0으로 업그레이드할 때 비디오 재생과 같은 일부 특정 상황에서 Flashback이
발생하면 일부 시스템 API는 이전 버전에서 사용할 수 있지만 새 버전에서는 사용할 수 없습니다.
13. Appium의 시작 방법은 무엇입니까
1. 클라이언트 시작
2. 명령줄 시작
14. 사용한 Android UI 자동화 테스트 도구에 대해 간단히 소개해주세요.
appium: 네이티브 애플리케이션, 모바일 웹 애플리케이션 및 하이브리드 애플리케이션을 테스트하는 데 사용할 수 있는 모바일 자동화 프레임워크
이며 크로스 플랫폼입니다. 로보티움(robotium): 주로
안드로이드 플랫폼 애플리케이션의 블랙박스 자동화 테스트를 위한 외국 안드로이드 자동화 테스트 프레임워크로, 다양한 제스처 조작(클릭, 길게 누르기,
슬라이드 다양한 컨트롤을 작동합니다.
15. Android 휴대전화와 IOS 휴대전화의 차이점과 시스템에 대해 설명해 주세요.
두 가지 작동 메커니즘이 다릅니다. IOS는 샌드박스 작동 메커니즘을 사용하고 Android는 가상 머신 작동 메커니즘을 사용합니다.
둘의 백그라운드 시스템은 다릅니다: IOS의 모든 타사 프로그램은 백그라운드에서 실행할 수 없으며 Android의 모든 프로그램은 백그라운드에서 실행할 수 있으며 메모리가 부족할 때까지 닫히지 않습니다.
IOS는 UI 명령에 대한 최고 권한을 가지며 Android는 데이터 처리 명령에 대한 최고 권한을 갖습니다.
3. 인터페이스 자동화 테스트 면접 질문
1. Webdriver를 인터페이스 테스트에 사용할 수 있습니까?
인터페이스 테스트를 위한 기성품 모듈이 있으며 WebDriver는 WebUI의 자동화된 테스트에 사용됩니다. 인터페이스 테스트를 구현하려는 경우 요청 모듈을 사용하여 달성할 수 있습니다.
2. 귀하의 이해에 따르면 소프트웨어 인터페이스는 무엇입니까?
서로 다른 모듈 간에 데이터를 전송하거나 수신하고 이를 처리하는 프로그램의 클래스 또는 함수를 나타냅니다.
3. HTTP와 HTTPS 프로토콜의 차이점은 무엇입니까?
https 프로토콜은 CA(Certificate Authority, 인증 기관)로부터 인증서를 신청해야 하며, 일반적으로 무료 인증서가 거의 없기 때문에 일정 수수료가 필요하며, http는 하이퍼텍스트 전송
프로토콜이며 정보는 평문으로 전송됩니다. 암호화 전송 및 신원 인증을 위한 네트워크 프로토콜은
http 프로토콜보다 안전
하며 http와 https는 완전히 다른 연결 방법과 다른 포트를 사용하며 전자는 80, 후자는 443입니다.
4. HTTPS는 어느 계층에 있습니까?
HTTPS는 애플리케이션 계층에 있습니다.
5. get과 post의 차이점은 무엇입니까?
POST와 GET 모두 서버에 데이터를 제출하고 둘 다 서버에서 데이터를 가져옵니다.
차이점:
전송 방식: get은 주소 표시줄을 통해 전송, post는 메시지를 통해 전송 전송
길이: get 매개변수는 길이 제한(url 길이로 제한), post는 무제한
GET은 TCP 패킷 생성(GET의 경우) 요청, 브라우저는 http 헤더와 데이터를 함께 보내고, 서버는
200으로 응답하고 데이터를 반환합니다.) POST는 두 개의 TCP 패킷을 생성합니다(POST의 경우 브라우저가 먼저 헤더를 보내고 서버는 100으로
계속 응답하고 브라우저는 다음을 보냅니다. 서버는 200 ok로 응답하여 데이터를 반환합니다)
get 요청 매개변수는 검색 기록에 완전히 보존되지만 게시물의 매개변수는 보존되지 않습니다.
데이터 쿼리를 수행할 때 GET을 사용하는 것이 좋습니다. 방식을 사용하며, 데이터 추가, 수정, 삭제 시에는 post 방식 사용을 권장합니다.
6. 일반적인 POST 데이터 제출 방법
네 가지 주요 방법이 있습니다: application/x-www-form-urlencoded, multipart/form-data,
application/json, text/xml 등.
7. HTTP 프로토콜 상태 비저장 프로토콜이란 무엇입니까?HTTP 프로토콜 상태 비저장 프로토콜을 해결하는 방법
Stateless는 프로토콜에 트랜잭션 처리를 위한 메모리 기능이 없으며 서버는 클라이언트가 어떤 상태에 있는지 알 수 없음을 의미합니다. 즉,
서버에 HTTP 요청을 보낸 후 서버는 요청에 따라 데이터를 보내지만 보낸
후 정보가 기록되지 않습니다. HTTP는 상태 비저장 프로토콜입니다. 즉, 각 요청은 독립적이며 Keep-Alive는
이 결과를 변경할 수 없습니다.
상태 부족은 후속 처리를 위해 이전 정보가 필요한 경우 다시 전송해야 하므로 연결당 전송되는 데이터 양이 증가 할 수 있음을 의미합니다 . 반면에 서버가 이전 정보를 필요로 하지 않는 경우 응답이 더 빠릅니다. HTTP
프로토콜의 특징은 장점과 단점을 모두 가지고 있는데 장점은 서버가 자유롭고 각 요청이 불필요한 연결 점유를 일으키지 않는다는 점이며
단점은 각 요청이 반복되는 콘텐츠 정보를 대량으로 전송한다는 점입니다. 클라이언트와 서버 사이에서 동적으로 상호 작용하는 웹 응용 프로그램이 등장한 후
HTTP의 상태 비저장 특성은 이러한 응용 프로그램의 실현을 심각하게 방해합니다.결국
상호 작용은 과거와 미래를 연결하는 연결 고리여야 합니다.간단한 장바구니 프로그램은 또한 사용자가 이전에 무엇을 선택했는지 알아야 합니다. 따라서
HTTP 연결 상태를 유지하기 위한 두 가지 기술, 하나는 Cookie이고 다른 하나는 Session입니다.
8. 쿠키와 세션의 차이점
쿠키 데이터는 고객의 브라우저에 저장되며 세션 데이터는 서버에 매우 안전하지 않음
로컬에 저장된 쿠키를 다른 사람이 분석하여 쿠키를 속일 수 있음 보안을 고려하여
세션을 사용해야
함 세션은 다음 위치에 저장됨 일정시간동안 서버.. 방문 횟수가 증가하면 서버의 성능을 점유하게 됩니다 서버 성능
저하를 고려하여 쿠키를 사용해야 합니다
하나의 쿠키가 저장하는 데이터는 4K를 초과할 수 없습니다 많은 브라우저에서 한 사이트에 최대 20개까지 저장하도록 제한하고 있습니다 로그인 정보와 같은 중요한 정보를 저장할 수 있는 쿠키
세션을 위해 다른 정보를 저장해야 하며 쿠키에 넣을 수 있습니다.
9. 요청 인터페이스의 일반적인 반환 상태 코드
1xx – 정보(임시 응답을 나타냅니다. 클라이언트는 정규 응답을 받기 전에 하나 이상의 1xx 응답을 받을 준비가 되었습니다.)
2xx – 성공(서버가 클라이언트의 요청을 성공적으로 수락했음을 나타냄)
3xx – 리디렉션(클라이언트 탐색 서버는 요청을 이행하기 위한 추가 작업 예를 들어, 브라우저는 서버에서 다른 페이지를 요청하거나 프록시 서버를 통해 요청을 반복해야 할 수 있습니다.)
4xx – 클라이언트 오류(전송된 오류, 클라이언트에 문제가 있습니다. 예를 들어 , 클라이언트 클라이언트가 존재하지 않는 페이지를 요청하고 클라이언트가 유효한 ID 확인 정보를 제공하지 않음)
5xx – 서버 오류(오류로 인해 서버가 요청을 완료할 수 없음)
일반적인 반환 코드는 다음과 같습니다.
200 OK - [GET]: 서버가 사용자가 요청한 데이터를 성공적으로 반환
201 CREATED - [POST/PUT/PATCH]: 사용자가 데이터를 성공적으로 생성하거나 수정했습니다.
202 수락됨 - [*]: 요청이 백그라운드에 진입했음을 나타냅니다. queue (asynchronous task)
204 NO CONTENT - [DELETE]: 사용자가 데이터를 성공적으로 삭제
400 INVALID REQUEST - [POST/PUT/PATCH]: 사용자가 보낸 요청이 잘못되어 서버가 작업을 수행하지 않았습니다. 401 Unauthorized
-[*]: 사용자에게 권한이 없음을 나타냅니다(토큰, 사용자 이름, 암호 오류)
403 Forbidden -[*]: 사용자에게 권한이 있음을 나타냅니다(401 오류와 반대). 액세스가 금지됨
404 NOT FOUND -[*]: 사용자가 발행한 요청이 레코드에 대해 존재하지 않고, 서버가 작동하지 않았으며, 작업이 멱등적입니다.
406 Not Acceptable - [GET]: 사용자가 요청한 형식이 사용 가능(예: 사용자가 JSON 형식을 요청했지만 XML 형식만 요청)
500 INTERNAL SERVER ERROR - [*]: 서버에서 오류가 발생했습니다. 사용자는 요청이 성공했는지 여부를 알 수 없습니다.
10. DNS란 무엇입니까?
DNS는 도메인 네임 시스템(Domain Name System) DNS는 도메인 네임 해석에 사용되며
인터넷에 URL을 입력한 후 다른 서버에 접속하면 IP로 변환되므로 DNS가 없으면 기억해야 함 Baidu Baidu의 IP로 이동하고 싶지만
DNS 처리를 사용하는 경우 해당 웹사이트의 도메인 이름, 즉 URL만 기억하면 됩니다.
11. 귀사는 인터페이스 테스트를 어떻게 수행합니까?
인터페이스 테스트와 일반 테스트의 실제 차이점은 테스트 사례의 설계 부분입니다.
인터페이스 사양을 가져옵니다.
디자인 인터페이스 테스트 기능 사용 사례(주로 사용자의 관점에서 인터페이스가 비즈니스 요구 사항을 충족할 수 있는지 여부, 사용 사례 디자인은 블랙 박스 사용 사례 집합입니다).
다양한 입력 매개변수 검증(정상적인 경우, 비정상적 경우에는 잘못된 입력 매개변수 개수, 잘못된 유형, 선택/필수, 상호 배타적 또는 관련 매개변수 고려 포함).
인터페이스 반환 값의 다양한 검증(인터페이스 문서의 요구 사항 준수)은
인터페이스 구현 논리를 이해하고 논리 적용 범위(문/조건/분기/판단/…)를 실현합니다.
인터페이스가 동시에 실행될 수 있는지, 안전한지, 그리고 성능이 요구 사항을 충족하는지
확인하려면 도구 또는 자체 작성 코드를 사용하십시오.
발견된 문제는 기능 테스트와 동일하며, 버그를 보고해야 하며, 추적 상태를 추적해야 합니다.
12. 인터페이스 테스트 케이스를 설계하는 방법은 무엇입니까?
일반적으로 인터페이스 테스트 케이스의 디자인은 다음 측면을 고려해야 합니다.
사전 조건 충족 여부
일부 인터페이스는 성공적으로 데이터를 얻으려면 사전 조건을 충족해야 합니다.
Token 로그인이 필요한 일반적인 역유스 케이스: 전제 조건 충족 여부에 대한 유스 케이스 0~n개 설계(n개 조건으로 가정)
기본값 매개변수를 포함할지 여부
긍정적 사용 사례: 매개변수를 기본값으로 채우지 않음, 매개변수를 전달하지 않음, 올바른 기존 "일반" 값으로 필수 매개변수 채우기,
다른 항목을 채우지 않음, 디자인 1 사용 사례
비즈니스 규칙 및 기능 요구 사항
여기에서 시간 상황에 따라 인터페이스 매개변수 설명과 결합하여 N개의 순방향 사용 사례 및 역방향 사용 사례를 설계해야 할 수 있습니다.
파라미터가 필수인지 여부
역방향 사용 사례: 각 필수 파라미터에 대해 파라미터 값이 비어 있는 역방향 사용 사례를 설계합니다.
매개변수 사이에 상관 관계가 있는지 여부
일부 매개변수는 서로 상호 제한적인 관계가 있습니다.
매개변수 데이터 유형 제한
역 사용 사례: 매개 변수 값 유형과 일치하지 않는 각 매개 변수에 대한 역 사용 사례 설계
매개변수 데이터 유형 자체의 데이터 범위 값 제한
Forward use case: 모든 매개변수에 대해 각 매개변수의 매개변수 값이 데이터 범위 내에서 최대값이 되도록 전방 유스케이스를 설계합니다.
13. 인터페이스 테스트를 하고 있는데, 무엇을 테스트하고 있습니까?
사용성 테스트
합의된 프로토콜, 방법 및 형식 내용에 따라 데이터를 인터페이스로 전송하고 처리 후 예상 결과를 반환합니다.
인터페이스 기능이 올바르게 구현되었는지 여부
반환 값 테스트 - 콘텐츠 외에도 반환 값이 정확해야 하며 호출자가 올바르게 구문 분석할 수 있도록 형식이 정확해야 합니다. 매개 변수 값
경계 값, 등가 클래스 테스트
오류 및 예외 처리 테스트
비정상적인 값(null 값, 특수 문자, 합의된 길이 초과 등)을 입력하면 인터페이스가 올바르게 처리하고 예상대로 응답할 수
있습니다
. 입력 매개변수가 적을수록 인터페이스는 예상대로 처리 및 응답을 수정할 수 있습니다.
잘못된 전송 데이터 형식(예: 형식 형식으로 작성된 json 형식) 테스트,
보안 테스트는 주로 전송된 데이터의 보안을 나타냅니다.
민감한 데이터(예: 암호, 비밀 키)가 전송을 위해 암호화되었는지
여부 반환된 데이터에 사용자 암호, 전체 사용자 은행 계좌 정보 등과 같은 민감한 데이터가 포함되어 있는지 여부
인터페이스가 수신 데이터에 대해 보안 확인을 수행하는지 여부 신원 ID 및 토큰 유사한 검증,
인터페이스가 악의적인 요청(예: 서버 충돌을 유발하는 다수의 위조된 요청 인터페이스)을 방지하는지 여부,
인터페이스 응답 시간, 동시 처리 기능 및 스트레스 테스트 처리와 같은 성능 테스트:
동일한 인터페이스에 대한 동시 요청(특히 POST 요청), 인터페이스 처리(예: 동일한 레코드 삽입으로 인해 데이터 오류가 발생하여 시스템 오류 발생)
인터페이스의 응답 시간은 사용자가 허용할 수 있는 범위 내에 있습니다
. 가장 큰 병목 현상이 현재 비즈니스 요구 사항을 충족하는지 확인하기 위한 압력 테스트
14. 인터페이스 테스트에 일반적으로 사용되는 도구는 무엇입니까?
Postman, fiddler, jmeter와 같이 일반적으로 사용되는 http 프로토콜 인터페이스 테스트 도구, webService 인터페이스는 SoapUI,
jmeter 등을 사용합니다.
15. 인터페이스 문서가 없습니다. 인터페이스 테스트는 어떻게 하나요?
이 질문은 주로 EQ를 테스트합니다. 평신도의 말로는 면접관을 속일 수 있는 능력입니다. 먼저 면접관을 속이게 하십시오. 들어가면 블라인드 테스트이기도 합니다. 언제든지 비난받을 준비를 하십시오. 물론입니다. , 면접관의 놀라움 (심리 mmp, 얼굴 미소)에 대답해서는 안되며
, 다음 단계는
패킷 캡처 도구를 사용하여 인터페이스를 캡처하고 처리한 다음 대상 테스트를 수행하는 것입니다. 인터페이스의 필드 정보가 명확하지 않은 경우 찾기
개발 솔루션 에 집중할 시간입니다 . (일반적인 패킷 캡처 도구인 Fiddler, Charles 등)
16. 수동 인터페이스 테스트 또는 자동 인터페이스 테스트 과정에서 업스트림 및 다운스트림 인터페이스의 데이터 의존성을 어떻게 처리합니까?
전역 변수를 사용하여 로그인 후 토큰 반환과 같은 종속 데이터를 처리하고 다른 인터페이스에는 이 토큰이 필요하며
전역 변수를 사용하여 토큰 매개 변수를 전달합니다.
17. 타사 데이터에 의존하는 인터페이스를 테스트하는 방법은 무엇입니까?
모의가 끝나면 면접관이 묻습니다. 모의인지 계속해서 구덩이를 파고 모의 서비스를 구축합니다.
18. 인터페이스 테스트에서 로그인 상태에 따라 인터페이스를 테스트하는 방법은 무엇입니까?
로그인 상태에 따라 달라지는 인터페이스의 본질은 요청을 보낼 때마다 성공적으로 보내기 위해서는 세션이나 쿠키가 포함되어야 하고
POST 요청을 구성할 때 필요한 세션이나 쿠키가 추가된다는 것 입니다.
19. 테스트를 위해 약한 네트워크를 시뮬레이션하는 방법은 무엇입니까?
Fiddler와 charles 모두 약한 네트워크 테스트를 시뮬레이트할 수 있습니다. 일반적으로 시뮬레이트된 패킷 손실이라고 하는 것은 시뮬레이트된 약한 네트워크 테스트이기도 합니다. 자세한 내용 은
"몇 가지 약한 네트워크 시뮬레이션 방법, 항상 적합한 방법이 있습니다"를 참조하십시오.
20. 일반적인 인터페이스 테스트 중에 발견한 버그는 무엇입니까?
면접관이 이 질문을 하는 이유는 주로 인터페이스 테스트를 정말 했는지 알고 싶어서 입니다.결국 많은 소규모 파트너들의 이력서는 포장되어 있습니다. 살아남기 위해, 이해할 수 있습니다) 일반 오류,
인터페이스 구현되지 않음, 합의에 따라 결과가 반환되지 않음, 경계 값 처리 오류 등
비정상적인 값 입력(null 값, 특수문자, 합의된 길이 초과 등), 인터페이스에서 오류 발생, 캡슐화 안 함, 잘못된 매개
변수 입력, 더 많은 입력, 더 적은 입력 매개변수 입력 및 인터페이스 오류 가능성 ;
일반 텍스트 전송과 같은 보안 문제 , 반환된 결과에 민감한 정보가 포함되어 있음, 사용자 신원 정보 확인 없음, 악의적인 요청 가로채기 없음 등 성능
문제(예: 인터페이스에 여러 개의 동일한 작업 동시 삽입, 긴 응답 시간, 인터페이스 압력 테스트 등의 병목 현상;
21. 인터페이스에 예외가 있는 경우 예외를 어떻게 분석합니까?
먼저 패킷을 캡처하고 fiddler(charles) 도구를 사용하여 패킷을 캡처하거나 브라우저에서 F12 디버깅 도구를 사용하여 앱에 있는 경우 Fiddler를 프록시로 사용하고 휴대폰을 통해 프록시를 설정하여 볼 수 있습니다
. 요청 및 반환 메시지:
Linux 시스템이 xhell을 통해 서버에 연결하고, 인터페이스 로그를 확인하고, 오류 메시지가 있는지 확인하는 것과 같은 백엔드 로그를 확인합니다(명령: tail -f 로그 파일).
22. 버그가 프런트엔드인지 백엔드인지 분석하는 방법은 무엇입니까?
보통 버그가 언급되면 프론트엔드 개발과 백엔드 개발은 항상 다투고 상대방의 버그라고 인정하지 않습니다. 이러한 상황은 판단하기 쉬운데, 먼저 패킷을 캡쳐하여 요청 메시지를 보고 인터페이스 문서를 보고 요청 메시지 에 문제가 없는지 확인하고
문제가 있으면
프런트엔드에서 보낸 데이터를 잘못되었습니다.
, 반환된 데이터가 잘못되었습니다. 즉, 백엔드 개발의 문제입니다.
23. 인터페이스 테스트 자동화를 하시나요?
이제 많은 애플리케이션의 경우 일반적으로 유지 관리 비용이 낮고 수익이 높은 인터페이스 테스트를 자동화하는 것이 좋습니다.
Jmeter, Robot Framework, pytest 등과 같이 일반적으로 사용되는 도구가 많이 있습니다.
24. 얼마나 많은 JMeter 리스너가 나열되어 있습니까?
일부 JMeter 리스너는 다음과 같습니다.
수집 보고서
요약 보고서
보기 결과 트리
보기 테이블 그래프
결과 의 결과
BeanShell 리스너
요약 보고서 등
25. Python에서 데이터 기반 테스트
unittest에는 내장 데이터 드라이버가 없으며 이를 달성하기 위해 ddt를 사용해야 합니다. 우선
Python 운영 환경에 ddt를 설치해야 합니다. 다음 명령을 사용하여
pip install ddt
다른 테스트 프레임워크 pytest를 설치합니다. 데이터 기반 구현과 함께 제공되며
@pytest.mark.parametrize(arnames,argvalues)에 의해 매개변수화됩니다.
필요에 따라 Python을 사용하여 데이터를 읽고 구동할 수도 있습니다.
26. 인터페이스 자동화에서 연결을 처리하는 방법은 무엇입니까?
이전 요청에서 반환된 결과를 다음 요청의 매개변수로 전달하고, 요청 결과를 클래스 속성에 반영하고(setattr
() 함수 사용) 다음 요청에서 클래스 속성을 호출합니다.
27. 자동 테스트 결과를 어떻게 확인합니까?
어설션, 예상 결과와 실제 결과 비교
데이터베이스 검증, 테스트 시나리오에 따라 데이터베이스의 데이터를 쿼리하고 요청 전 데이터와 비교합니다.
28. 구체적으로 이 프로젝트의 실제 상황에 자동화가 어떻게 적용되었으며 자동화 결과에 대한 귀하의 분석
모든 자동화된 테스트 프레임워크의 설계 및 구현을 완료한 후 인터페이스 테스트를 수행한 다음
Jenkins에 통합하고 타이밍 실행을 구성하고 html 보고서를 생성하고 테스트 합격률을 확인하고 인터페이스의 기능을 확인합니다.버전이
릴리스될 때마다 개발 및 테스트 전에 회귀 테스트 및 새로운 기능을 수행하십시오.
기술적 지원
마지막으로 소프트웨어 테스팅을 위한 자가 학습 자습서 모음입니다. 테스트 업계에서 발전하고 있는 친구들에게 많은 도움이 될 것입니다.필요한 친구들을 위해 [기사 끝의 작은 카드를 클릭하여 무료로 받으세요] . 기본 보급형 리소스 외에도 블로거는 많은 고급 자동화 리소스를 수집하고 이론에서 실제 전투에 이르기까지 지식과 행동의 통일성을 진정으로 마스터할 수 있습니다. 전체 콘텐츠 세트는 네트워크 디스크에 패키징되었으며 총 콘텐츠는 300G에 가깝습니다.
☑ 215개 에피소드 - 기본 기초부터 숙달까지 전체 비디오 코스 세트
☑ [코스웨어 + 소스 코드] - 지원 튜토리얼 완료
☑ 18개 세트 - 실제 프로젝트 소스 코드 테스트
☑ 37개 세트 - 테스트 도구 패키지
☑ 268개 질문 - 실제 인터뷰 질문
☑ 200개의 템플릿 - 인터뷰 이력서 템플릿, 테스트 계획 템플릿, 소프트웨어 테스트 보고서 템플릿, 테스트 분석 템플릿, 테스트 계획 템플릿, 성능 테스트 보고서, 성능 테스트 보고서, 성능 테스트 스크립트 사용 사례 템플릿(전체 정보)
이 자료들은 [소프트웨어 테스팅]을 하는 친구에게 가장 포괄적이고 완전한 준비 창고가 되어야 합니다.이 창고는 또한 가장 어려운 여정을 함께했으며 여러분에게도 도움이 되었으면 합니다! 모든 것이 가능한 한 빨리 이루어져야 하며, 특히 기술 산업에서는 우리의 기술력을 향상시켜야 합니다.
