안녕하세요
29CM에서 정다정님, 홍해진님과 함께 QA팀을 맡고 있는 박현준 입니다.
29CM QA팀은 UI 테스트 자동화와 API 테스트 자동화를 모두 진행하고 있습니다. 그중 이번에는 API 테스트 자동화와 API 를 활용하고 있는 부분에 대해서 이야기 해보려고 합니다.
29CM QA팀은 API와 관련된 업무를 할 때 Postman을 사용하고 있습니다.
테스트 도구로 사용하거나 다른 도구들과의 연동이 편해서 사용하고 있는데요 팀 내에서는 주로 CLI에서 사용할 수 있는 newman을 사용하고 있습니다. 이럴경우 xml로 결과를 제네레이트 해서 Slack에 알림을 보내기도 굉장히 용이합니다.
그럼 이러한 도구를 어떻게 사용하고 있는지 이야기 해보겠습니다.
API 테스트 & 자동화
29CM에서는 여러 개의 스쿼드가 각각 목적에 맞는 기능을 개발하고 있습니다. QA팀은 스쿼드에서 협업 요청을 할 경우 해당 기간 동안 QA활동을 하게 되는데 이러한 활동 중에는 개발되는 기능의 API 테스트와 API 테스트 자동화도 포함되어 있습니다.
먼저 API 관련 문서와 백엔드 엔지니어 분들과의 커뮤니케이션으로 API에 대한 정보를 수집하고 테스트 케이스를 작성하게 됩니다.
기본적이고 공통적인 테스트케이스 산정은 아래와 같은 과정으로 진행됩니다.
- Status Code를 체크합니다. (ex. 200, 401, 500 등)
- 파라미터 값을 넣지 않고 (Null)요청을 보냅니다.
- 유효하지 않은 파라미터 값을 넣고 요청을 보냅니다.
- 인증값 (대체로 Token) 을 넣지 않고 (Null) 요청을 보냅니다.
- 유효하지 않은 인증값 (ex. 인증기간 만료된 Token) 을 넣고 요청을 보냅니다.
6. 등등…
이렇게 기본적인 API 테스트의 테스트 케이스가 완성되면 이제 HTTP Method별로 약간씩 차이가 나도록 테스트 케이스를 추가 작성합니다.
Path Parameter나 Query String은 다양한 HTTP Method에서 사용할 수 있으나, GET인 경우 Body Parameter가 대부분 없는 등의 차이를 고려하며 테스트 케이스를 작성합니다.
- 응답값의 key가 명세한 내용대로 다 포함되어있는지 체크합니다.
- 응답값 key에 해당하는 값의 유효성을 체크합니다.
- 응답값 key에 해당하는 값의 타입을 체크합니다.
- 등등…
POST나 PUT같이 데이터를 생성하거나 수정하는 API의 경우 Request Body 값들을 별도로 저장해 놓고 해당 API의 응답값과 비교하거나 해당 API로 생성된 데이터를 조회하는 API를 사용해서 응답값과 비교합니다. 유효한 테스트 케이스가 될 수 있어 자주 활용하는 편입니다.
이렇게 여러 상황들을 고려한 테스트 케이스 작성이 완료되면 테스트가 진행되는 시점을 파악해야 합니다. 테스트는 어떠한 변경점이 있을 때 진행될 수 있도록 하는것이 가장 효율이 좋기 때문에 서버 배포가 된 뒤에 바로 테스트가 진행되도록 설정합니다.
QA팀 Jenkins에 해당 API 테스트가 진행되도록 설정해 놓은뒤 remote 빌드가 가능하도록 하고 해당 빌드를 실행할 수 있는 스크립트를 해당 서버 배포담당 개발자 분께 전달합니다.
그리고 배포된 뒤에 API 테스트 자동화 트리거 요청을 하면 서버 배포 파이프라인 제일 마지막 단계에 QA팀 Jenkins에 remote빌드가 실행되어 바로 테스트가 진행되게 됩니다.
트리거 된 QA Jenkins 에서 테스트 자동화가 진행되고 테스트 결과를 Slack에 리포팅 합니다.
모든 결과가 SUCCESS이면 너무나 행복하겠지만 :) 우리의 일상은 그렇지 않죠. 물론 테스트 결과가 FAIL일 경우도 있습니다. 이럴때는 제네레이팅 된 XML 내용을 참고하여 실패한 케이스를 slack에 같이 표시해줍니다.
그리고 해당 테스트를 생성해 놓은 담당 QA를 멘션하여 확인을 유도합니다.
이렇게 각 서버(서비스) 에 맞는 테스트 케이스를 만들고 배포시 트리거 되도록 설정해 놓으면 스쿼드와의 협업이 완료되어 담당 QA가 또다른 스쿼드와의 협업을 위해 떠나게 되더라도 해당 테스트는 자동적으로 계속 실행되게 됩니다.
- 스쿼드가 QaaS (QA as a Service) 를 사용하게 되는것이 아닐까 하는 생각을 해봅니다 :)
물론 API의 변동이 있을 경우는 유지보수가 필요하지만 API의 스펙이 변동되는 경우는 UI 보다는 월등히 적고, 변경이 되더라도 큰 폭으로 변경되지 않기 때문에 유지보수도 상대적으로 적은 리소스로 가능합니다.
저비용 고효율의 테스트가 가능하기 때문에 29CM QA팀에서는 API 테스트를 중요시 생각하며 테스트 커버리지를 넓히는 목적으로 진행하고 있습니다.
API 테스트에 활용하기
API는 검증대상인 것만은 아니라 테스트를 좀 더 편리하고 수월하게 해줄 수 있는 하나의 고마운 도구로도 사용할 수 있습니다.
29CM는 이커머스 플랫폼이기 때문에 상품과 관련된 테스트를 하는 경우가 많습니다. 그래서 테스트용 상품을 생성, 수정 하거나 주문, 클레임(취소, 교환, 반품) 처리를 하는 경우가 많은데요 이러한 경우 UI를 거치지 않고 빠르게 테스트를 위한 상태를 만들기 위해 API를 구성해서 사용합니다.
이렇게 할 경우 UI화면을 거치지 않고 내가 원하는 상태를 곧바로 만들 수 있기 때문에 해당 기능에 대한 테스트를 진행할 경우 상당량의 시간을 절약할 수 있습니다.
추가적으로 동일한 API를 반복해서 사용해야 하는 경우에도 활용합니다.
테스트 시 브랜드를 100개 이상 사용해야 할 경우가 있는데 이런 상황에서 브랜드 생성 API를 사용하여 100회 이상 반복 실행을 통해 빠르게 브랜드를 생성할 수 있습니다.
postman은 javascript를 지원하기 때문에 간단하게 랜덤함수를 사용하여 수백회 반복하여도 최대한 중복되지 않는 이름의 브랜드를 생성할 수 있습니다. 저같은 경우 이름 뒤에 임의의 숫자를 추가하는 방식을 주로 사용합니다.
Pre-request Script 탭에 코드를 작성해 놓으면 실제 API요청을 보내기 전에 실행되기 때문에 미리 설정해 놓으면 건건마다 이름을 랜덤으로 지정하며 요청을 보낼 수 있게 됩니다.
ran_num = _.random(1000, 9999)
pm.environment.set("ran_num", ran_num)
그리고 파라미터 value에 이렇게 설정하여 보내게 될 경우 4자리 랜덤한 숫자와 mpark brand 라는 이름이 합쳐져서 요청을 보내게 됩니다.
그럼 반복 횟수만 정해주면 해당 횟수만큼 내가 원하는 브랜드 들이 생겨나게 됩니다.
이 외에도 테스트 시 필요한 API가 있을 경우 적극적으로 백엔드 엔지니어 분과 커뮤니케이션하여 정보를 얻고 활용하고 있습니다. 29CM에서는 개발자분들과 QA팀간의 커뮤니케이션이 원활히 진행되고 있기 때문에 어려움 없이 API에 대한 정보를 얻고 사용할 수 있습니다.
29CM QA팀원분들도 처음에는 API와 친하지 않으셨습니다
하지만 API 테스트 필요성에 대한 팀 내 가이드를 진행하고, 활용했을 때의 QA팀이 가질 수 있는 임팩트에 대한 이야기를 공유하며 지속적으로 학습한 결과 이제는 팀원분들도 API를 활용하며 테스트와 자동화를 진행하고 계십니다. 지금은 API없이 테스트 하려고 하면 오히려 불편함을 느끼시지 않을까 하네요.
API는 활용면에서 QA팀에 많은 도움을 주고 있습니다. 테스트 커버리지에 포함될 경우 UI 테스트만 진행했을 때 보다 더 넓은 테스트 커버리지를 가질 수 있게 하는 것도 그중 하나입니다.
29CM QA팀은 앞으로도 API를 활용하여 테스트 커버리지를 넓혀갈 예정입니다. 현재는 App 테스트 자동화 시에도 API를 활용하고 있는데요 이 이야기는 추후에 App 테스트 자동화 이야기를 할 때 같이 이야기해보도록 해보겠습니다.
이번 글에는 29CM QA팀이 API를 어떻게 효율적으로 활용하는지에 대해 이야기 해보았습니다. 이 글이 API를 어떻게 활용하고, 어떻게 테스트 해야 하는지에 대한 도움이 조금이라도 되었으면 좋겠습니다.
감사합니다!
이렇게 QA활동과 지식공유 활동이 활발하게 이루어지고 있는
‘29CM 엔지니어링 조직에 합류하세요!’
🚀 29CM 채용 페이지 : https://www.29cmcareers.co.kr
