API Test를 설계 및 구축할 때의 몇가지 테스트 관점에 대해 기재해봅니다.
Why we test API?
요새 대부분의 서비스는 프론트엔드와 백엔드를 분리하여 구성하는데, 이때 프론트엔드 (클라이언트) 와 백엔드 (서버) 간의 데이터 통신을 하는데에 API를 사용합니다. 위 Test pyramid에서, API Test는 중간의 Intergration 단계에 해당하는데요, 자동화하기 쉽다는 특성을 살려, API를 테스트함으로 인해 프론트엔드 사이드(GUI) 에서 접근하는 UI 테스트(E2E Test)에서의 많은 시간적, 물질적 Cost들을 절약할 수 있습니다.
서비스들 중에서는 단순히 GUI환경 없이 백엔드만 상품으로 제공하는 경우가 많습니다. 이 경우라면 공개된 API는 그 자체로 하나의 프로덕트가 되는 것입니다. 이 API에서 장애가 발생한다면, 우리 서비스는 물론이거니와 고객의 비즈니스 자체에 큰 장애를 초래하게 됩니다.
API를 테스트하는 프레임워크 혹은 라이브러리들은 많이 있습니다. 이러한 것들을 선택하고, 학습하기 전에 어떠한 측면에서 테스트를 진행해야하는지, 어떠한 것을 테스트해야하는지 충분히 검토를 해야합니다.
테스트 담당자가 직접 API Test를 구현하지 않아도, Testcase를 작성하여 개발자들에게 전달할 수도 있고, 혹은 개발자들이 작성한 메소드 혹은 시나리오에 대해 Feedback을 제공할 수도 있습니다.
Check the Specification
우선, 당연하게도, 요구사항 및 기획서를 확인해야합니다. API는 클라이언트와 서버, 혹은 어떠한 프로그램과 프로그램 간의 일종의 계약(Contract) 입니다. 요구사항과 기획서를 확인하여 확인관점 및 테스트 시나리오를 도출해내어야 합니다.
Check point
요구사항 명세서와 기획서를 확인하였다면, 우선 무엇을 검증/확인해야하는지 추려내야합니다. API Test를 할 때 보편적으로 확인하는 내용들은 아래와 같습니다.
1. Response Status code
특정 Endpoint로 정해진 내용의 request를 날린다면, 정해진 status code의 response가 오는지 확인합니다. 될 수 있다면 정의된 모든 status code를 확인하는 것이 좋으며, 내용상 테스트환경에서는 확인이 어려운 특수한 상황에서의 status code에 대해서는 개발팀과 상의 후 테스트 환경에서 구현을 한다던지, 혹은 생략할 수도 있을 것입니다.
2. Response Payload
페이로드(영어: payload)는 사용에 있어서 전송되는 데이터를 뜻한다. 페이로드는 전송의 근본적인 목적이 되는 데이터의 일부분으로 그 데이터와 함께 전송되는 헤더와 메타데이터와 같은 데이터는 제외한다.
https://ko.wikipedia.org/wiki/%ED%8E%98%EC%9D%B4%EB%A1%9C%EB%93%9C_(%EC%BB%B4%ED%93%A8%ED%8C%85)
request를 하여 return되는 response의 데이터들을 확인합니다. 최근에는 json 형태의 response data가 많은데요, 아래와 같이 확인해볼 수 있을 것입니다.
- 특정 Key값 존재여부, 대소문자를 포함한 key값이 기획서에 정의된 내용과 일치하는지
- 특정 Key값의 value값
- value값의 데이터 타입
- value값에 Nested dictionary, array형태
- 특정 value값에 다시
Key:value형태, 혹은 array 형태가 e포함될 때, 그 구조가 올바른지.
- 특정 value값에 다시
3. Response header
return되는 header값에 문제 없는지, 불필요한 header값은 없는지, header값으로 인해 개인정보가 유출될만한 데이터는 없을지 확인합니다.
4. Response time
응답시간은 반드시 확인해야할 사항은 아니나, 너무 느리다면 프로덕트에 영향이 있을 것입니다. 이 경우는 별도로 Performance / Stress test를 진행해볼 수도 있을 것 입니다.
5. Application status
어플리케이션의 상태란, API호출로 인하여 바뀐 데이터 변경값이 제대로 반영되어있는지를 확인합니다.
확인 방법으로는
- Database의 테이블 값이 의도한대로 변경되었는지
- 특정 값을 변경 후, 해당 값을 참조하는 API를 호출하여 변경되었는지를 확인
- 예를 들어, 작성되어있는 게시물의 내용을 변경한다면, 다시 게시물을 조회하는 API를 호출하여 제대로 내용이 반영되어있는지 확인합니다.
- (UI가 존재하는 프로덕트의 경우) 직/간접적으로 API를 호출하는 부분을 확인하여 UI상에서도 반영되었는지
를 확인합니다.
Check Scenario
위와 같이 어떠한 부분들을 확인/검증할지 정해졌다면, 그 다음은 Scenario를 도출해냅니다. API 테스트에서의 Scenario란, 고객이 어떠한 상황에서 어떠한 endpoint를 호출할지를 상정한 scenario입니다. 보통은 CRUD의 흐름으로 진행됩니다.
아래 기술하는 Scenario 관점들을 모두 다 진행해야할 필요는 없으며 테스트 담당자의 판단 및 이해관계자들과의 커뮤니케이션을 통해 진행여부를 결정합니다.
1. Happy test
기본적인 기능테스트이며, Acceptance test의 내용이 되기도 합니다. 대부분의 경우 statusCode 200의 패턴만을 상정한 Scenario입니다.
Regression test의 testcase가 됩니다.
2. Happy test with Optional parameter
추가가능하면서도 없어도 무방한, Optional한 request 데이터에 대한 Happy test를 진행합니다. 구체적으로 예를 들자면 아래와 같을 것 입니다.
- 필수 paramter :
A- 선택 paramter :
B
A만 request로 보냈을 때statusCode 200return 되고,A와B를 같이 보냈을 때에도statusCode 200이 return되는지 확인.
3. Negative test
유효한 request 데이터를 이용한 negative test를 진행할 수도 있습니다.
statusCdoe 200을 제외한,400이나500등, Error handling 확인statusCode 200을 return하지만, 부정적인 의미가 담겨 return하는 경우
그 외에도 상정 이상의, 정의되지 않은 많은 양의 parameter를 보낸다던지의 테스트도 진행해볼 수 있을 것 입니다.
Test flow
테스트를 어떻게 진행해나갈지에 대해서도 정해야합니다.
1. Single API request
endpoint 하나씩 호출하여 response를 확인합니다.
2. Multi API flow
연관된 API에 대하여 연속적인 흐름으로 request를 실행합니다.
앞서 Scenario에서 말씀드린 CRUD와 같은 흐름입니다.
예를 들어 게시물에 대한 CRUD라면,
- 게시물 작성
- 게시물 확인
- 게시물 갱신
- 게시물 삭제
에 대한 흐름을 한 번에 진행합니다.
3. Combine API with UI
API실행과 UI확인을 같이 진행합니다. API실행으로 인한 데이터 변경이 제대로 반영되는지, 확실하게 확인합니다. 다만 다른 방법들보다 Cost가 더 필요하게됩니다.
Non-functional test
기능테스트 이외에, API는 비기능테스트를 실행하기도 적절한 대상입니다. 비기능테스트에 대해서는 대체적으로 아래와 같은 내용들을 고려해볼 수 있을 것 입니다.
- Security
- Authorization
- Performance / Stress
- Usability
- API의 내용, 사용방법에 대해 알기쉬운지, 사용하기 쉬운지 등을 의미합니다.
Static test about API Document
API의 요구사항 명세서, 기획서들과는 별도로 API를 어떻게 사용해야하는지가 주로 적혀있는 API Document에 대해서도 정적테스트를 진행해야합니다.
릴리즈 주기가 빠른 프로덕트라면 API 문서와 실제 response payload가 다른 경우가 간혹 있는데요, API 테스트를 하면서 API문서를 같이 대조해보고 해당 문서작성자에게 feedback을 제공해주어야 합니다.
그 외에도 읽기 쉬운지, 문맥의 흐름은 누가 읽어도 이해할 수 있는지 등에 대해, 이해관계자들과 함께 회의를 설정하고 API문서를 직접 읽어가면서 확인해볼 수도 있을 것입니다.
Ref
