API 기능 테스트, 무엇을 어떻게 검증할 것인가?
안녕하세요, 기술로 수면 문제를 잠재우는 Asleep에서 Mobile SDK와 API System 그리고 Web Dashboard 품질을 보증하고 있는 지원입니다. API 기능 테스트를 어떻게 시작해야 하는지 어려움을 겪고 계신 QA Engineer 분들을 위해서 이번 블로깅을 작성하게 되었습니다. 현업 진행에 조금이나마 도움이 되길 바랍니다.
담당 서비스 구성도 소개
우선 제가 담당 중인 서비스에 대해 간단히 소개 드리자면 에이슬립은 수면 분석 API 서비스입니다. 스마트폰 혹은 마이크가 있는 스마트 디바이스에서 측정한 사운드 데이터를 API 서버에서 분석하여 사용자의 수면 상태를 실시간으로 트래킹하고 측정이 종료된 후에는 사용자의 지난밤 수면의 질에 대한 다양한 수면 메트릭 데이터를 제공합니다.
에이슬립 도입을 원하는 고객께서는 2가지 Type을 통해 도입해 볼 수 있는데요. 도입 표준 방식인 Regular Type 같은 경우는 SDK에 패키징 되어있는 오디오 레코딩, 전처리, API 통신, 분석 결과 확인 기능을 모두 활용하는 방식입니다. 고객사는 수면 측정 기능에 대한 추가 개발을 진행할 필요 없이 앱에서 수면 분석 결과를 받아 볼 수 있으며 callback url 등록을 통해 고객사 백엔드에서도 수면 분석 결과를 확인할 수 있습니다. 그 외에 Light Type 같은 경우는 고객사 앱 특성으로 인해 오디오 레코딩, API 통신 등의 기능을 고객사가 직접 구현해야 할 경우 활용되는 결합 방식으로 SDK의 전처리 기능만을 사용합니다.
서비스 구성도에 기재된 Asleep SDK와 API System 그리고 Management 영역에 필요한 품질 보증 활동을 진행하다 보면 담당 서비스와 소속 팀 특성상 API 기능 및 비기능(부하 테스트 등) 테스트가 소프트웨어 개발 수명 주기(SDLC) 동안 필수적인데요.
이번 포스팅에서는 API 기능 테스트에서 무엇을 테스트하고 어떻게 테스트하는지에 대한 핵심적인 내용을 살펴보도록 하겠습니다.
무엇을 테스트할 것인가?
API 기능 테스트 검증 방식을 단순히 특정 엔드 포인트에 대한 Response Body를 검증하는 것에만 집중하게 되면 다양한 상황이 존재하는 사용자 시나리오에 대한 오류를 발견하기 힘들 수 있습니다.
예를 들어 아래와 같이 사용자 식별자를 사용해 존재하는 사용자의 정보를 가져올 수 있는 API의 Body(result field)가 있다고 가정합니다.
API 기능 테스트는 UI 테스트와 마찬가지로 E2E 테스트 흐름과 관점으로 검증해야 합니다. QA Engineer가 API 테스트 진행 시 생각해야 할 부분은 우리 서비스를 사용하는 사용자는 항상 우리가 의도한 상황대로(Happy Path) 요청을 보내지 않는 상황(Nagative)을 가정하고 테스트 디자인을 진행해야 합니다.
10분 전에 생성된 user_id가, 현재는 삭제되어 존재하지 않을 경우, 해당 user_id로 조회 시 어떻게 될까?
단순히 엔드 포인트의 명세에 따라서 요청을 보내고 응답 본문을 검증하는 것이 아니라 위와 같이 다중 요청이 포함된 CRUD 플로우를 고려해야 하고 이를 테스트 디자인에 포함시킬 수 있어야 합니다. 위와 같은 플로우의 응답 예상 결과는 404 Not Found가 될 것이고, 생성 -> 조회 -> 삭제와 같은 흐름으로 검증하는 방향이 필요합니다.
조금 더 복잡한 시나리오를 살펴보겠습니다.
사용자를 생성합니다.
사용자를 조회하면 초기에는 Response body의 result 특정 값이 null로 출력되어야 합니다.
위와 같은 상태에서 해당 사용자로 세션을 생성할 경우 result 특정 값에 요청한 세션 정보가 출력되어야 합니다.
만약 세션이 아직 Open 상태라면 result의 특정 값은 Open과 null로 출력되어야 합니다.
만약 세션이 종료될 경우 result의 특정 값은 Complete와 YYYY-MM-DDThh:mm:ssZ 형식을 지닌 값이 출력되어야 합니다.
이때 해당 사용자 정보로 세션 생성 시 사용자 정보가 존재하지 않다는 404 Not Found 에러와 관련 정보가 출력되어야 합니다.
또한 해당 사용자 정보로 세션 종료 시 이미 종료되었다는 403 Forbidden 에러와 관련 정보가 출력되어야 합니다.
위와 같은 API 기능 테스트 플로우를 검증하려면 단순히 단일 API 요청과 응답 본문 검증(상태 코드, 객체 포함 유무, 데이터 타입, empty 유무, 속성 길이, 응답 시간, 올바른 스키마 등)만으로는 검증이 다소 제한적입니다. 초기 요청했던 테스트 데이터를 통해서 1번부터 7번까지의 검증 포인트에 활용이 되도록 구현이 필요하고 Nagative 상황을 의도적으로 구현하여 E2E 흐름에서 4xx 에러와 정상 응답이 반환되는지에 대한 검증이 필요합니다.
또한 요청을 보낼 때 요청 Parameters에 API Spec을 기반으로 다양한 테스트 데이터로 검증할 수 있도록 테스트 데이터를 적절히 생각해 내고 구현하는 과정이 필요합니다. 즉 아래에 대한 검증 범위를 고려한다면 보다 높은 테스트 커버리지를 유지할 수 있습니다.
Positive 테스트(Happy Path)
Option 매개변수를 활용한 Positive 테스트(Happy Path)
유효한 Input을 활용한 Nagative 테스트
잘못된 Input을 활용한 Nagative 테스트
API 성능을 확인하기 위한 Destructive 테스트(오버플로를 발생시킬 우려가 있는 페이로드 본문 전송 등, 의도적으로 API 중단을 시도하는 Nagative 테스트)
어떻게 검증할 것인가?
앞서 API 기능 테스트에서 무엇을 검증해야 하는지에 대해 단일 API 요청과 검증뿐 아니라 다중 API 요청 흐름(CRUD)의 중요성에 대해 살펴보았습니다. 이러한 테스트를 진행하기 위해서 어떻게 검증할 것인가의 관점을 통해 어떤 도구를 사용하면 좋을지 살펴보겠습니다.
결론부터 말씀드리면 Node.js와 브라우저를 위한 Promise 기반 HTTP 클라이언트인 Axios 라이브러리, Java 도메인에서 간단하게 REST 서비스를 테스트하고 검증 가능한 REST Assured 라이브러리, Python의 requests 라이브러리, GUI 기반의 서비스인 Postman 중에서 담당 서비스에 필요한 검증 플로우를 쉽게 구현할 수 있고 모니터링 시스템을 구축해 볼 수 있다면 어떠한 도구를 사용해도 무방합니다.
예를 들어 Axios를 사용한다고 해서 Postman으로 구현된 API 테스트와 다른 방식 또는 더 나은 방식으로 검증하지는 않습니다. 우선 아래 Axios로 구현된 사용자 생성과 사용자 조회 검증 코드를 살펴보겠습니다.
테스트 프레임워크는 Mocha를 사용 중이고 사용자 생성과 조회에 필요한 createUser와 getUser를 구현했습니다.
사용자 정보 획득 성공에 필요한 API 기능 테스트를 위와 같이 구현했습니다. 우선 사용자 생성 후 반환되는 user_id가 필요합니다. user_id는 사용자 정보 조회 시 필요한 Request Path Parameter입니다. 사용자 생성 후 반환된 user_id로 사용자 정보를 조회했을 때 응답 본문을 검증하도록 구현했습니다.
위와 같은 과정을 Postman에서도 동일하게 구현할 수 있습니다.
Collections에서 필요한 요청을 생성합니다.
Environment에서 테스트에 필요한 Variable를 작성합니다.
API Spec에 맞춰 Authorization과 Header를 구성합니다.
Tests에서 JavaScript로 아래와 같이 필요한 검증 로직을 구현합니다.(스키마 검증은 JsonPath Syntax 사용)
CRUD 흐름을 구현하기 위해 필요에 따라 다음번 요청에 사용할 변수를 셋업 합니다.
해당 과정을 반복하여 필요한 테스트 시나리오를 구현합니다.
API 기능 테스트 검증 관점에서 GUI 기반으로 보다 쉽게 테스트 환경을 구성하고 구현해 볼 수 있는 Postman과 Axios와 Mocha 테스트 프레임워크를 활용한 테스트 환경 구성 및 검증에는 크게 차이가 있지 않습니다.
다만 개인적으로 HTTP 요청 라이브러리와 각 언어에 존재하는 테스트 프레임워크(Mocha, TestNG, Pytest)를 활용해서 테스트 환경과 구현 방식 모두 프로그래밍 방식으로 진행할 경우 원하는 시나리오와 상황을 보다 입맛대로 구축해가는 과정이 편리했습니다.
예를 들어 4xx 에러를 확인해야 하는 테스트 시나리오를 구현해야 할 경우 Axios는 아래와 같이 비유효 데이터와 null 데이터를 빠르고 유연하게 구현할 수 있습니다.
하지만 Postman 같은 경우 테스트 환경 구성에 필요한 설정값들이 GUI 기반으로 제공되기 때문에 서로 다른 Authorization과 Header를 구성하기 위해 별도의 요청을 추가로 생성해야 하는 번거로움이 있었습니다. 만약 API 테스트 결과를 UI 테스트와 함께 활용한다고 가정할 경우 다양한 프레임워크를 프로그래밍 방식으로 연동하게 될 텐데, 이러한 상황에서는 오히려 HTTP 요청 라이브러리를 활용하여 구현하는 것이 보다 간편하게 느껴질 수도 있을 것 같습니다.
마치며
지금까지 API 기능 테스트에서 무엇을 검증해야 하고 어떻게 검증할 것인지에 대해 살펴보았습니다. 이번 포스팅에서 전하고 싶은 핵심 내용은 아래와 같습니다.
단일 API 요청뿐 아니라 다중 API 요청에 대한 CRUD 검증 플로우를 반드시 포함시키자
도구에 매몰되지 말고 지금 진행하는 테스트가 소프트웨어 품질 관점에서 어떠한 가치를 지닌 활동인지 끊임없이 생각하자
어제의 품질 기준과 오늘의 품질 기준은 계속해서 변화하고 높아져갑니다. 유연한 사고와 발전적인 태도로 지금 하고 있는 테스트와 QA 활동이 우리 서비스를 사용하는 고객께 어떠한 가치를 제공할 수 있을지, 서비스 품질 관점에서 어떠한 가치를 만들어낼 수 있을지 끊임없이 고민하고 개선한다면 보다 좋은 QA Engineer로 성장할 수 있지 않을까 생각해 봅니다.
감사합니다.
지원 드림.
