API 테스트 자습서 : 초보자를위한 완벽한 가이드

api testing tutorial

이 심층 API 테스트 자습서는 API 테스트, 웹 서비스 및 조직에서 API 테스트를 도입하는 방법에 대한 모든 것을 설명합니다.

이 입문 자습서에서 시프트 레프트 테스트 및 웹 서비스 개념과 함께 API 테스트에 대한 심층적 인 통찰력을 얻으십시오.

웹 API와 같은 개념, API 작동 방식 (실제 사례 포함) 및 웹 서비스와 어떻게 다른지이 자습서의 예제를 통해 잘 설명합니다.

=>아래로 스크롤초보자를위한 5 개의 심층 API 테스트 자습서 전체 목록보기

학습 내용 :

• API 테스트 자습서 목록
• 이 API 테스트 시리즈의 자습서 개요
• API 테스트 가이드
  • 왼쪽으로 이동 테스트
  • Shift Left 테스트 전의 소프트웨어 개발 수명주기 (SDLC)
  • 왼쪽 교대 테스트 단계
  • 웹 API
  • API는 어떻게 작동합니까?
  • 웹 서비스
  • 웹 서비스 대 웹 API
• 조직에서 API 테스트 소개
  • API 테스트로의 초점 전환
  • API 테스트의 전체 스펙트럼
    • (i) 기능 테스트
    • (ii) 부하 및 성능 테스트
    • (iii) 보안 테스트
  • 조직에 API 테스트를 도입하는 방법
  • 일반적인 문제와이를 완화하는 방법
    • # 1) 올바른 도구 선택
    • # 2) 테스트 사양 누락
    • # 3) 학습 곡선
    • # 4) 기존 기술 세트
  • 사례 연구
• 결론
  • 추천 도서

API 테스트 자습서 목록

튜토리얼 # 1 : API 테스트 자습서 : 초보자를위한 완벽한 가이드
튜토리얼 # 2 : 웹 서비스 자습서 : 구성 요소, 아키텍처, 유형 및 예
튜토리얼 # 3 : 답변이 포함 된 상위 35 개 ASP.Net 및 Web API 인터뷰 질문
튜토리얼 # 4 : POSTMAN 자습서 : POSTMAN을 사용한 API 테스트
튜토리얼 # 5 : Apache HTTP 클라이언트를 사용한 웹 서비스 테스트

이 API 테스트 시리즈의 자습서 개요

API 테스트 가이드

이 섹션은 웹 서비스 및 웹 API에 대한 기본적인 이해를 돕고,이 API 테스트 시리즈의 다음 튜토리얼에서 주요 개념을 이해하는 데 도움이 될 것입니다.

API (Application Programming Interface)는 운영 체제 또는 플랫폼의 데이터 또는 기능에 액세스하여 응용 프로그램을 만들 수있는 모든 절차 및 기능의 집합입니다. 이러한 절차의 테스트를 API 테스트라고합니다.

왼쪽으로 이동 테스트

요즘 API 테스팅 인터뷰에서 요청되는 중요한 테스트 유형 중 하나는 Shift Left 테스팅입니다. 이러한 유형의 테스트는 애자일 방법론을 따르는 거의 모든 프로젝트에서 실행됩니다.

Shift Left Testing이 도입되기 전에는 코딩이 완료되고 코드가 테스터에게 전달 된 후에 만 ​​소프트웨어 테스트가 실현되었습니다. 이 관행은 마감일을 맞추기 위해 마지막 순간에 서두르고 제품 품질을 크게 저하 시켰습니다.

그 외에도 개발자가 설계 및 코딩 단계를 모두 다시 거쳐야했기 때문에 (생산 전 마지막 단계에서 결함이보고되었을 때) 노력이 엄청났습니다.

Shift Left 테스트 전의 소프트웨어 개발 수명주기 (SDLC)

전통적인 SDLC 흐름은 요구 사항 –> 디자인 –> 코딩 –> 테스트였습니다.

기존 테스트의 단점

• 테스트는 극히 옳습니다. 마지막 순간에 버그가 발견되면 많은 비용이 발생합니다.
• 버그를 해결하고 프로덕션으로 승격하기 전에 다시 테스트하는 데 걸리는 시간은 엄청납니다.

따라서 테스트 단계를 왼쪽으로 이동시키는 새로운 아이디어가 생겨서 Shift Left Testing으로 이어졌습니다.

추천 읽기 => Shift Left Testing : 소프트웨어 성공을위한 비밀 진언

왼쪽 교대 테스트 단계

Left Shift Testing은 결함 감지에서 결함 예방으로 성공적으로 마이그레이션했습니다. 또한 소프트웨어가 빠르게 실패하고 모든 실패를 가장 빨리 수정하는 데 도움이되었습니다.

웹 API

일반적으로 웹 API는 클라이언트 시스템에서 웹 서버로 요청을 받고 웹 서버에서 클라이언트 시스템으로 응답을 다시 보내는 것으로 정의 할 수 있습니다.

API는 어떻게 작동합니까?

여러 항공사의 정보를 집계하는 온라인 여행 서비스 인 www.makemytrip.com에서 항공편을 예약하는 매우 일반적인 시나리오를 살펴 보겠습니다. 항공편 예약을 할 때 여행 날짜 / 귀국 날짜, 클래스 등의 정보를 입력하고 검색을 클릭합니다.

이렇게하면 여러 항공사의 가격과 가용성이 표시됩니다. 이 경우 애플리케이션은 여러 항공사의 API와 상호 작용하여 항공사의 데이터에 대한 액세스를 제공합니다.

또 다른 예는 www.trivago.com으로 특정 도시의 다른 호텔의 가격, 가용성 등을 비교하고 나열합니다. 이 웹 사이트는 여러 호텔의 API와 통신하여 데이터베이스에 액세스하고 웹 사이트의 가격과 가용성을 나열합니다.

따라서 웹 API는 '클라이언트 시스템과 웹 서버 간의 통신을 용이하게하는 인터페이스'로 정의 할 수 있습니다.

웹 서비스

웹 서비스는 (웹 API와 같은) 한 시스템에서 다른 시스템으로 서비스하는 서비스입니다. 그러나 API와 웹 서비스간에 발생하는 주요 차이점은 웹 서비스가 네트워크를 사용한다는 것입니다.

모든 웹 서비스는 웹 API이지만 모든 웹 API는 웹 서비스가 아니라고 말할 수 있습니다 (기사 후반부에 설명 됨). 따라서 웹 서비스는 웹 API의 하위 집합입니다. 웹 API 및 웹 서비스에 대한 자세한 내용은 아래 다이어그램을 참조하십시오.

웹 API 대 웹 서비스

웹 서비스 대 웹 API

웹 API와 웹 서비스는 클라이언트와 서버 간의 통신을 용이하게하는 데 사용됩니다. 주요 차이점은 의사 소통 방식에만 있습니다.

각각은 특정 언어로 허용되는 요청 본문, 보안 연결 제공의 차이점, 서버와의 통신 및 클라이언트에 대한 응답 속도 등이 필요합니다.

웹 서비스와 웹 API의 차이점은 참조 용으로 아래에 나열되어 있습니다.

웹 서비스

• 웹 서비스는 일반적으로 XML (Extensible Markup Language)을 사용하므로 더 안전합니다.
• 웹 서비스와 API 모두 데이터 전송 중에 SSL (Secure Socket Layer)을 제공하기 때문에 웹 서비스는 더 안전하지만 WSS (Web Services Security)도 제공합니다.
• 웹 서비스는 웹 API의 하위 집합입니다. 예를 들어, 웹 서비스는 세 가지 사용 스타일, 즉 SOAP, REST 및 XML-RPC.
• 웹 서비스에는 항상 네트워크가 필요합니다.
• 웹 서비스는 '하나의 코드 다른 응용 프로그램'을 지원합니다. 이는보다 일반적인 코드가 여러 응용 프로그램에 작성된다는 것을 의미합니다.

웹 API

• Web API는 일반적으로 JSON (JavaScript Object Notation)을 사용하므로 Web API가 더 빠릅니다.
• XML과 달리 JSON은 가볍기 때문에 Web API가 더 빠릅니다.
• 웹 API는 웹 서비스의 상위 집합입니다. 예를 들어, 웹 서비스의 세 가지 스타일 모두 웹 API에도 존재하지만 그 외에는 JSON – RPC와 같은 다른 스타일을 사용합니다.
• 웹 API가 작동하는 데 반드시 네트워크가 필요하지는 않습니다.
• Web API는 시스템 또는 애플리케이션의 특성에 따라 상호 운용성을 지원하거나 지원하지 않을 수 있습니다.

조직에서 API 테스트 소개

일상 생활에서 우리 모두는 API로 앱과 상호 작용하는 데 너무 익숙하지만 기본 기능을 구동하는 백엔드 프로세스에 대해서는 생각조차하지 않습니다.

예를 들어, Amazon.com에서 제품을 탐색하고 있으며 정말 좋아하는 제품 / 거래를보고 Facebook 네트워크와 공유하고 싶다고 가정 해 보겠습니다.

페이지의 공유 섹션에서 Facebook 아이콘을 클릭하고 공유 할 Facebook 계정 자격 증명을 입력하는 순간 Amazon 웹 사이트를 Facebook에 원활하게 연결하는 API와 상호 작용합니다.

API 테스트로의 초점 전환

API 테스트에 대해 더 논의하기 전에 최근 API 기반 애플리케이션이 인기를 얻은 이유를 살펴 보겠습니다.

조직이 API 기반 제품 및 애플리케이션으로 전환하는 데에는 몇 가지 이유가 있습니다. 그리고 그들 중 일부는 귀하의 참조를 위해 아래에 나열되어 있습니다.

#1) API 기반 애플리케이션은 기존 애플리케이션 / 소프트웨어와 비교할 때 더 확장 성이 뛰어납니다. 코드 개발 속도는 더 빠르며 동일한 API는 주요 코드 나 인프라 변경없이 더 많은 요청을 처리 할 수 ​​있습니다.

#두) 개발 팀은 기능이나 애플리케이션 개발 작업을 시작할 때마다 처음부터 코딩을 시작할 필요가 없습니다. API는 가장 자주 기존의 반복 가능한 함수, 라이브러리, 저장 프로 시저 등을 재사용하므로이 프로세스를 통해 전체적으로 생산성을 높일 수 있습니다.

예를 들어, 전자 상거래 웹 사이트에서 작업하는 개발자이고 Amazon을 결제 프로세서로 추가하려는 경우 코드를 처음부터 작성할 필요가 없습니다.

통합 키를 사용하여 웹 사이트와 Amazon API 간의 통합을 설정하고 결제 중 결제 처리를 위해 Amazon API를 호출하기 만하면됩니다.

#삼) API를 사용하면 지원되는 독립형 애플리케이션 및 API 기반 소프트웨어 제품 모두에 대해 다른 시스템과 쉽게 통합 할 수 있습니다.

예를 들어 , 토론토에서 뉴욕으로화물을 보내고 싶다고 가정 해 보겠습니다. 온라인에 접속하여 잘 알려진화물 또는 물류 웹 사이트로 이동하여 필요한 정보를 입력합니다.

필수 정보를 제공 한 후 요금 확인 버튼을 클릭하면 백엔드에서이 물류 웹 사이트가 여러 운송 업체 및 서비스 제공 업체 API 및 애플리케이션과 연결되어 출발지에서 목적지까지의 위치 조합에 대한 동적 요금을 가져올 수 있습니다.

API 테스트의 전체 스펙트럼

API 테스트는 API에 요청을 보내고 응답의 정확성만을 분석하는 데 국한되지 않습니다. API는 취약성에 대해 서로 다른 부하에서 성능을 테스트해야합니다.

이에 대해 자세히 논의하겠습니다.

(i) 기능 테스트

기능 테스트는 GUI 인터페이스가 없기 때문에 어려운 작업이 될 수 있습니다.

C ++ 코딩 인터뷰 질문

방법을 보자 기능 테스트 접근법 for APIs는 GUI 기반 응용 프로그램과 다르며 이에 대한 몇 가지 예도 설명합니다.

에) 가장 명백한 차이점은 상호 작용할 GUI가 없다는 것입니다. 일반적으로 GUI 기반 기능 테스트를 수행하는 테스터는 이미 익숙한 사람과 비교할 때 비 GUI 애플리케이션 테스트로 전환하는 것이 조금 더 어렵다는 것을 알게됩니다.

처음에는 API 테스트를 시작하기 전에도 인증 프로세스 자체를 테스트하고 확인해야합니다. 인증 방법은 API마다 다르며 인증을 위해 일종의 키 또는 토큰이 필요합니다.

API에 성공적으로 연결할 수 없으면 추가 테스트를 진행할 수 없습니다. 이 프로세스는 로그인하고 응용 프로그램을 사용하기 위해 유효한 자격 증명이 필요한 표준 응용 프로그램의 사용자 인증과 비교할 수 있습니다.

비) 필드 유효성 검사 또는 입력 데이터 유효성 검사는 API를 테스트하는 동안 매우 중요합니다. 실제 양식 기반 (GUI) 인터페이스를 사용할 수있는 경우 프런트 엔드 또는 백 엔드에서 필드 유효성 검사를 구현하여 사용자가 잘못된 필드 값을 입력 할 수 없도록 할 수 있습니다.

예를 들어, 신청서에 날짜 형식이 DD / MM / YYYY 여야하는 경우 정보를 수집하는 양식에이 유효성 검사를 적용하여 신청서가 유효한 날짜를 수신하고 처리하는지 확인할 수 있습니다.

그러나 이것은 API 응용 프로그램과 동일하지 않습니다. API가 잘 작성되어 있고 이러한 모든 유효성 검사를 시행하고 유효한 데이터와 잘못된 데이터를 구분하고 응답을 통해 최종 사용자에게 상태 코드와 유효성 검사 오류 메시지를 반환 할 수 있는지 확인해야합니다.

씨) 유효하고 유효하지 않은 응답에 대한 API 응답의 정확성을 테스트하는 것은 실제로 중요합니다. 상태 코드 200 (모두 정상임을 의미)이 테스트 API에서 응답으로 수신되었지만 응답 텍스트에 오류가 발생했다고 표시되면 이는 결함입니다.

또한 오류 메시지 자체가 잘못된 경우이 API와 통합하려는 최종 고객에게 매우 오해의 소지가있을 수 있습니다.

아래 스크린 샷에서 사용자는 허용되는 2267Kgs보다 많은 잘못된 무게를 입력했습니다. API는 오류 상태 코드 및 오류 메시지로 응답합니다. 그러나 오류 메시지에 무게 단위가 KG 대신 lbs로 잘못 언급됩니다. 이는 최종 고객에게 혼란을 줄 수있는 결함입니다.

(ii) 부하 및 성능 테스트

API는 설계에 따라 확장 가능하도록 설계되었습니다.

이것은 차례로 Load를 만들고 성능 시험 특히 설계중인 시스템이 요구 사항에 따라 분당 또는 시간당 수천 개의 요청을 처리 할 것으로 예상되는 경우 특히 그렇습니다. API에서 정기적으로 부하 및 성능 테스트를 수행하면 성능, 최대 부하 및 중단 점을 벤치마킹하는 데 도움이 될 수 있습니다.

이 데이터는 응용 프로그램 확장을 계획 할 때 유용합니다. 이 정보를 사용할 수 있으면 특히 조직에서 더 많은 고객을 추가 할 계획 인 경우 의사 결정 및 계획을 지원하는 데 도움이됩니다.

예를 들어 , 제공된 요구 사항에 따라 설계된 API가 시간당 최소 500 개의 요청을 처리하고 평균 응답 시간을 .01 초 미만으로 유지해야한다는 것을 알고 있다고 가정 해 보겠습니다.

로드 및 성능 테스트에 따르면 API가 시간당 500 개 미만의 요청을 수신하는 한 평균 응답 시간 동안 SLA를 유지할 수 있음을 발견했습니다. 그러나 다른 200 개의 요청을 수신하면 평균 응답 시간이 증가하고 수신 요청이 시간당 1200을 초과하면 중단 점에 도달합니다.

일반적으로 초기 설계 단계에서 API의 기능적 측면에 중점을 두는 경우가 많습니다. 시간이 지남에 따라 제품은 여러 라이브 클라이언트를 지원하기 시작합니다. 즉, API 성능 및 부하 테스트에 대한 테스트가보다 일상적인 방식으로 진행됩니다.

Windows 10을위한 최고의 시스템 유틸리티

(iii) 보안 테스트

애플리케이션 프로그래밍 인터페이스 또는 API는 취약하며 데이터에 액세스하거나 애플리케이션을 제어하려는 악의적 인 해커에게 가장 쉬운 액세스 포인트입니다.

이로 인해 모든 회사는 보안 위반으로 인해 의도하지 않은 사람 및 / 또는 조직이 유서 깊은 API를 통해 고객의 데이터에 액세스 할 수있는 법적 문제로 이어질 수 있습니다.

보안 테스트 테스트의 전문 분야이며 전문가가 처리해야합니다. 보안 테스트 리소스는 조직 내부 또는 독립 컨설턴트가 될 수 있습니다.

또한 읽기 = >> Pact 계약 테스트 란?

조직에 API 테스트를 도입하는 방법

모든 조직에서 API 테스트를 도입하는 프로세스는 다른 테스트 도구 및 프레임 워크를 구현하거나 배포하는 데 사용되는 프로세스와 유사합니다.

아래 표에는 각 단계의 예상 결과와 함께 주요 단계가 요약되어 있습니다.

일반적인 문제와이를 완화하는 방법

QA 팀이 조직에서 API 테스트 프레임 워크를 구현하는 동안 직면하는 몇 가지 일반적인 과제에 대해 논의하겠습니다.

# 1) 올바른 도구 선택

작업에 적합한 도구를 선택하는 것이 가장 일반적인 과제입니다. 시장에서 사용할 수있는 여러 API 테스트 도구가 있습니다.

시장에서 가장 값 비싼 최신 도구를 구현하는 것이 매우 매력적으로 보일 수 있지만 원하는 결과를 얻지 못하면 해당 도구는 쓸모가 없습니다.

따라서 항상 조직의 요구 사항에 따라 '필수'요구 사항을 해결하는 도구를 선택하십시오.

다음은 사용 가능한 API 도구에 대한 샘플 도구 평가 매트릭스입니다.

# 2) 테스트 사양 누락

테스터로서 우리는 애플리케이션을 효과적으로 테스트하기 위해 예상되는 결과를 알아야합니다. 예상되는 결과를 알기 위해서는 명확하고 정확한 요구 사항이 필요하기 때문에 이는 종종 어려운 일입니다.

예를 들어 , 아래 제공된 요구 사항을 고려하십시오.

'신청서는 유효한 배송 날짜 만 수락해야하며 모든 유효하지 않은 요구 사항은 거부되어야합니다.'

이러한 요구 사항에는 주요 세부 정보가 누락되어 있고 매우 모호합니다. 유효한 날짜를 어떻게 정의하고 있습니까? 형식은 어떻습니까? 최종 사용자에게 거부 메시지를 반환하고 있습니까?

명확한 요구 사항의 예 :

1) 애플리케이션은 유효한 배송 날짜 만 수락해야합니다.

배송일이 유효한 경우 유효한 것으로 간주됩니다.

• 과거에는 아님
• 오늘 날짜보다 크거나 같음
• 허용되는 형식 : DD / MM / YYYY

2)

응답 상태 코드 = 200
메시지 : OK

삼) 위 기준을 충족하지 않는 배송일은 유효하지 않은 것으로 간주됩니다. 고객이 잘못된 배송 날짜를 보내는 경우 다음 오류 메시지로 응답해야합니다.

3.1

응답 상태 코드 NOT 200
오류 : 제공된 배송 날짜가 잘못되었습니다. 날짜가 DD / MM / YYYY 형식인지 확인하세요.

3.2

응답 상태 코드 NOT 200
오류 : 제공된 배송 날짜가 과거입니다.

# 3) 학습 곡선

앞서 언급했듯이 API 테스트를위한 접근 방식은 GUI 기반 애플리케이션을 테스트하는 동안 따르는 접근 방식과 비교할 때 다릅니다.

API 테스트를 위해 사내 또는 컨설턴트를 고용하는 경우 API 테스트 접근 방식 또는 API 테스트 도구의 학습 곡선이 최소화 될 수 있습니다. 이 경우 모든 학습 곡선은 제품 또는 응용 프로그램 지식 습득과 관련이 있습니다.

기존 팀 구성원이 API 테스트를 학습하도록 할당 된 경우 선택한 도구에 따라 학습 곡선이 중간에서 높고 테스트 접근 방식을 변경할 수 있습니다. 제품 또는 응용 프로그램 자체에 대한 학습 곡선은이 테스터가 해당 응용 프로그램을 이전에 테스트했는지 여부에 따라 중간 수준이 될 수 있습니다.

# 4) 기존 기술 세트

이것은 학습 곡선에 대한 이전 요점과 직접적으로 연결됩니다.

테스터가 GUI 기반 테스트에서 전환하는 경우 테스터는 테스트 접근 방식을 변경하고 필요에 따라 새로운 도구 또는 프레임 워크를 배워야합니다. 예 : API가 JSON 형식의 요청을 수락하는 경우 테스터는 테스트 생성을 시작하기 위해 JSON이 무엇인지 알아야합니다.

사례 연구

직무

기존 애플리케이션을 확장하기 위해 한 회사는 표준 GUI 애플리케이션뿐만 아니라 API로 제품을 제공하기를 원했습니다. QA 팀은 정규 GUI 기반 테스트를 넘어서 API 테스트를 수용 할 준비가되었는지 확인하기 위해 테스트 커버리지 계획을 제공하도록 요청 받았습니다.

도전

• 다른 소프트웨어 제품에는 API 기반 아키텍처가 없으므로이 작업에 대한 테스트를 수용하기 위해 팀은 API 테스트 프로세스를 처음부터 설정해야합니다. 즉, 도구를 평가하고, 최종 후보로 지정하고, 최종화하고, 테스트를 위해 팀을 교육해야했습니다.
• 도구를 획득하고 구현하기 위해 할당 된 추가 예산이 없습니다. 즉, 팀은 무료 또는 오픈 소스 API 테스트 도구를 선택해야하고 기존 팀의 누군가가이 작업을 수행하도록 교육을 받아야했습니다.
• API 필드 및 데이터 유효성 검사에 대한 요구 사항이 없습니다. 요구 사항은 '해당 GUI 응용 프로그램과 동일하게 작동해야합니다'.

위험을 완화하고 문제를 해결하기 위해 팀이 따르는 접근 방식

• QA 팀은 프로젝트 팀과 협력하여 다음 요구 사항을 확인했습니다.
  • API 유형 (REST / SOAP) : 쉬다
  • 필요한 테스트 (기능, 부하, 보안) : 기능 테스트 만
  • 자동화 된 테스트 필요 (예 / 아니요) : 지금은 선택 사항
  • 테스트 보고서 (예 / 아니오) : 필수
• QA 팀은 사용 가능한 도구 평가를 수행했습니다. API 테스트 도구 필수 요구 사항을 기반으로합니다. Postman API 도구는 무료이고 사용하기 쉽기 때문에 선택한 도구로 최종 확정되어 학습 곡선을 최소화하고 테스트를 자동화 할 수있는 잠재력이 있으며 우수한 보고서가 내장되어 있습니다.
• 애플리케이션을 테스트 한 동일한 테스터는 Postman을 사용하여 초기 테스트를 생성하여 제품 지식 격차를 제거하도록 교육을 받았습니다.
• 누락 된 요구 사항을 처리하기 위해 프로젝트 팀은 Swagger를 사용하여 높은 수준의 현장 수준 문서를 작성했습니다. 그러나 이로 인해 수용 가능한 데이터 형식 측면에서 약간의 차이가 남았으며 이는 프로젝트 팀과 함께 해결되었으며 예상 형식이 합의되고 문서화되었습니다.

결론

API 기반 애플리케이션은 최근 인기를 얻고 있습니다. 이러한 애플리케이션은 기존 애플리케이션 / 소프트웨어에 비해 확장 성이 뛰어나며 다른 API 또는 애플리케이션과 쉽게 통합 할 수 있습니다.

이 API 테스트 자습서에서는 API 테스트, Shift Left 테스트, 웹 서비스 및 웹 API에 대한 모든 것을 자세히 설명했습니다. 또한 예제를 통해 웹 서비스와 웹 API의 차이점을 살펴 보았습니다.

자습서의 두 번째 부분에서는 API 테스트의 전체 스펙트럼, 조직에 API 테스트를 도입하는 방법,이 프로세스의 몇 가지 일반적인 과제와 솔루션에 대해 논의했습니다.

예제와 함께 웹 서비스에 대한 자세한 내용은 다음 튜토리얼을 확인하십시오 !!

NEXT 튜토리얼

추천 도서

• 알파 테스트 및 베타 테스트 (전체 가이드)
• 기능 테스트 대 비 기능 테스트
• 사용성 테스트 자습서 : 완전한 시작 안내서
• 빌드 검증 테스트 (BVT 테스트) 전체 가이드
• DevOps 테스트 자습서 : DevOps가 QA 테스트에 어떤 영향을 미칠까요?
• 접근성 테스트 자습서 (단계별 전체 가이드)
• 최고의 소프트웨어 테스트 도구 2021 (QA 테스트 자동화 도구)
• 소프트웨어 테스팅이란? 100 개 이상의 무료 수동 테스트 자습서