책 발췌 – API 테스팅 by Gayathri Mohan

출처: 2022년, Full Stack Testing - A Practical Guide for Delivering High Quality Software by Gayathri Mohan, 2장 Manual Exploratory Testing

 

API Testing

애플리케이션 프로그래밍 인터페이스(API)는 시스템이 서로 상호 작용할 수 있는 방법을 제공한다. API는 시스템의 기본 복잡성을 추상화하고 HTTP 프로토콜을 사용하여 XML, JSON 또는 평문(plain text)으로 네트워크 상의 정보 교환을 단순화한다. 정보 교환을 표준화하기 위해 SOAP와 같은 프로토콜과 REST와 같은 사양이 개발되었다. 요즘에는 SOAP보다 RESTful API가 더 널리 사용되고 있으며, SOAP를 사용하던 레거시 시스템도 REST 사양으로 재작성되고 있다. REST API에 대한 이해를 돕기 위해 그림 2-9와 같은 샘플 전자상거래 애플리케이션을 고려해 보겠다. 이 애플리케이션이 세 가지 REST 서비스(주문, 인증 및 고객 서비스), UI 및 데이터베이스를 포함한다.

 

그림 2-9. 서비스 기반 아키텍처를 갖춘 샘플 전자상거래 애플리케이션

 

서비스 지향 아키텍처는 그림 2-9와 같이 핵심 애플리케이션 기능이 웹 서비스로 작성되는 아키텍처이다. 웹 서비스는 애플리케이션 내에서 독립적인 목적을 가진 컴포넌트이다. 위 전자상거래 애플리케이션에서 주문 서비스(Order service)는 주문 관리(생성, 갱신 및 삭제)를 담당하고 고객 서비스(Customer service)는 고객의 세부 정보를 유지 관리할 책임이 있다. 이는 정보 교환을 용이하게 하는데 애플리케이션의 타 컴포넌트가 관련 서비스의 API에 액세스하여 필요한 정보를 얻을 수 있기 때문이다.

 

예를 들어 최종 사용자가 전자상거래 UI를 통해 주문의 결제를 완료했다고 가정해 보자. 예 2-1과 같이 UI는 즉시 주문 세부 정보와 함께 주문 생성 요청(request)을 주문 서비스에 보내고, 주문 서비스는 이 요청을 처리한 후 다시 UI에 응답(response)을 보낸다.

 

예  2-1.  샘플  REST  요청 및 응답

 

예 2-1에서 요청이 POST HTTP 메서드를 사용하여 API /orders/new에 도달하는 것을 볼 수 있다. 일반적으로 POST는 새 정보를 생성하거나 추가하는 데 사용되고 GET은 정보 조회(예: 특정 고객이 주문한 주문목록 가져오기)에 사용된다. PUT과 DELETE 메서드도 있는데 각각 업데이트 및 삭제 작업에 사용된다. 요청 본문(request body)은 주문 세부 정보를 패키지화하는데 이 경우는 품목명, 재고 관리 단위(SKU), 색상 및 크기가 하나의 JSON 오브젝트로 묶였다. 이 전체 구조를 계약(contract)이라고 하며, UI 클라이언트가 이 계약을 준수하지 않으면 서비스는 해당 요청을 처리하지 않는다.

 

마찬가지로 응답도 계약을 준수한다. 작업의 성공 또는 실패를 나타내는 상태 코드가 포함되며 작업에 관한 추가 정보를 제공하는 응답 본문(response body)도 있을 수 있다. 예 2-1에서 응답 상태 코드 200 OK는 성공을 의미하고, 응답 본문에는 주문 서비스에서 생성된 주문 ID와 함께 “성공적으로 생성되었습니다”라는 메시지가 포함되어 있다. 이 응답을 받으면 전자상거래 UI가 사용자를 주문 확인 페이지로 이동시키고 해당 페이지에 주문 ID를 표시한다. 이 모든 액션들이 동시(synchronously) 발생인 점에 유의한다. 즉, 전자상거래 UI는 주문 확인 페이지로 이동하기 전에 응답을 받을 때까지 기다린다.

  

API의 작동 방식에 대한 기본적인 이해를 하면 “주문 생성 기능을 웹 UI에서 테스트할 수 있는데 왜 API를 별도로 테스트할 필요가 있는가”라는 질문이 생길 수 있다. 간단히 답하면 오늘날 API가 그 자체로 제품이 되었기 때문이다! 좀 더 자세한 대답은 API가 모든 비즈니스 로직과 검증을 포괄하고 있어서 다른 내부 및 외부 컴포넌트가 재사용할 수 있는 독립된 제품이기 때문이다. 위에서 예로 들었던 전자상거래 비즈니스가 새로운 모바일 쇼핑 앱을 구축하면서 동일한 주문 생성 API를 재사용하거나, 또는 고객 지원 포털을 구축하기 위해 동일한 고객 서비스 API를 사용할 수 있다. 심지어 완전히 새로운 도메인에 진출하면서 인증 서비스의 API를 재사용하여 해당 새 제품에 로그인 기능을 구축할 수도 있다. 따라서 API를 독립형 제품으로 테스트하는 것은 오늘날의 디지털 세계에서 매우 중요하다.

 

API를 테스트할 때 핵심 비즈니스 로직 외에도 신경 써야 할 몇 가지 탐색 경로가 다음과 같다.

• 요청 계약의 유효성 확인(Validation of the request contract): 예를 들어 부정한 클라이언트가 유효하지 않은 데이터 형식으로 새 주문을 생성하는 경우 주문 서비스가 이 요청을 거부하도록 검증이 이루어져야 한다.
• 인증(Authentication): 대부분의 경우 API는 보안을 위한 인증 메커니즘을 가진다. 예를 들면 요청 헤더에 토큰(긴 암호화 문자열)을 보내는 것과 같은 것이다. 이는 테스팅에서 중요한 탐색 경로이다.
• 권한(Permissions): API가 클라이언트에 대해 수행할 수 있는 작업에 대한 제한이 있을 수 있다. 예를 들어 관리자(admin)는 기존 주문을 편집할 수 있지만 고객 임원은 주문을 볼 수만 있도록 제한될 수 있다.
• 하위 호환성(Backward compatibility): 때로는 제품이 발전함에 따라 API 계약이 변경될 수 있다. API를 사용하는 기존 클라이언트가 있을 수 있으므로 새 버전을 구 버전과 동시에 생성하고 유지 관리해야 할 수도 있다. 애플리케이션은 두 API 버전 모두에서 테스트되어야 한다.
• HTTP 상태 코드(HTTP status codes): 기술 및 비즈니스 오류에 대해 반환되는 상태 코드는 관련성이 있어야 한다. 표 2-4에는 가장 일반적인 상태 코드가 나열되어 있다.

 

상태 코드	의미
200 OK	GET, PUT 또는 POST 요청이 성공했음을 나타낸다.
201 Created	새 오브젝트(예: 새 주문)가 생성되었음을 나타낸다.
400 Bad Request	요청의 형식이 잘못되었음을 나타낸다.
401 Unauthorized	클라이언트가 요청한 리소스에 액세스할 수 없으며 필수 자격 증명(credentials)을 사용하여 요청을 다시 발행해야 함을 나타낸다.
403 Forbidden	요청이 유효하고 클라이언트가 인증되었지만 모종의 이유로 클라이언트가 요청한 페이지나 리소스에 액세스할 수 없음을 나타낸다.
404 Not Found	요청한 리소스를 현재 사용할 수 없음을 나타낸다.
500 Internal Server Error	요청이 유효하지만 내부 버그 등으로 인해 서버가 이를 처리할 수 없음을 나타낸다.
503 Service Unavailable	서버가 다운되었음을 나타낸다(예: 유지보수 중 서버 다운).

표 2-4. HTTP 상태 코드

 

이러한 모든 탐색 경로를 탐색하려면 도구가 필요하다.

 

Postman

Postman은 API 테스트를 위한 도구이다. 데스크톱 버전의 설치 바이너리는 무료로 제공되며 웹 버전도 사용해 볼 수 있다.

 

Postman은 API 탐색을 위한 여러 기능을 제공하는데 흔히 활용되는 몇 가지가 다음과 같다.

• 인증 목적으로 전송된 토큰은 Authorization 탭에 추가하여 요청과 함께 전송할 수 있다. 여기에 잘못된 문자열을 추가하여 요청이 실패하는지 확인할 수 있다.
• 마찬가지로 쿠키가 요청과 함께 전송되면 Cookies 탭에 추가할 수 있다.
• Postman은 응답을 수신하는 데 걸린 시간을 캡처한다. 이는 입력에 따라 성능이 저하되는지 빠르게 탐색하는 데 도움이 된다.
• 요청을 수동으로 생성하는 대신 Swagger, OpenAPI 등에서 API 사양을 가져오기(import) 할 수 있다.

 

Postman은 REST 서비스 외에도 GraphQL 및 SOAP 서비스 테스트를 지원한다.

 

 

WireMock

WireMock은 다른 컴포넌트의 동작을 에뮬레이션 하는 소프트웨어 컴포넌트인 스터브(stubs)를 생성하고 변경하기 위한 도구이다. 스터브는 실제 통합될 서비스가 아직 모두 준비가 되지 않은 복잡한 애플리케이션을 개발하고 테스트할 때 특히 유용하다. 여러 팀이 서비스 계약(service contract)에 대한 합의를 하면 통합될 서비스의 스터브를 생성하여 개발을 계속할 수 있다. 스터브는 특정 요청에 미리 정해진 출력으로 응답하도록 명시적으로 프로그래밍하여 만들어진다. API 탐색적 테스트에서 다양한 긍정적 및 부정적 통합 테스트 케이스를 설정하는 데 이 기능을 사용할 수 있다. 물론, 실제 컴포넌트가 완성되면 엔드투엔드 기능을 다시 한 번 테스트하는 것이 필수적이다.

 

예 2-2. WireMock을 사용한 샘플 스터브

 

 

스터브 서버를 설정하고 스터브를 가리키도록 애플리케이션을 구성하는 것은 DevOps 엔지니어나 팀의 개발자가 담당하는 일일 수 있다. 하지만 테스트 케이스를 시뮬레이션하기 위해서 테스터도 스터브를 변경하는 방법을 알아야 한다.

 

 

아래 11분짜리 튜토리얼 영상은 WireMock를 사용하여 모의의 API 엔드포인트를 생성하고 Postman에서 테스트하는 방법을 설명한다.