REST API 테스트 튜토리얼: 수동 테스트 사례
⚡ 스마트 요약
REST API 테스트는 GET, POST, PUT, DELETE와 같은 HTTP 요청을 전송하고 서버에서 반환된 상태 코드, 응답 헤더 및 페이로드를 검증하여 RESTful 웹 서비스를 검증합니다.

REST API 테스트란 무엇입니까?
REST API 테스트 REST API 테스트는 웹 애플리케이션의 RESTful API를 테스트하는 데 사용되는 오픈 소스 웹 자동화 테스트 기법입니다. REST API 테스트의 목적은 다양한 HTTP/S 요청을 전송하여 REST API의 응답을 기록하고, REST API가 정상적으로 작동하는지 확인하는 것입니다. REST API 테스트는 GET, POST, PUT, DELETE 메서드를 사용하여 수행됩니다.
REST Representational State Transfer의 약자입니다. 이는 개발에 사용되는 건축 스타일이자 커뮤니케이션 접근 방식입니다. 웹 서비스REST는 사용자가 클라우드 서비스에 효율적으로 연결하고 상호 작용할 수 있도록 해주기 때문에 API 구축에 있어 논리적인 선택이 되었습니다.
API, 즉 애플리케이션 프로그래밍 인터페이스는 웹 기반 소프트웨어 애플리케이션에 접근하기 위한 프로그래밍 명령어 집합입니다. 다시 말해, 한 프로그램이 다른 프로그램과 직접 통신하고 서로의 기능을 사용하여 정보를 얻기 위해 사용하는 명령어 집합입니다.
예를 들어 Google 웹사이트는 검색, 번역, 캘린더 기능을 위한 API를 가질 수 있습니다. 일반적으로 API는 아래 예시와 같이 서버 이름, 경로, 매개변수를 포함합니다.
http://<server name>/v1/export/Publisher/Standard_Publisher_Report?format=csv
그렇다면 왜 굳이 이 단계에 테스트 노력을 투자해야 할까요?
REST API 테스트가 중요한 이유
REST API는 사용자 인터페이스와 데이터베이스 사이에 위치하므로 대부분의 비즈니스 로직이 실제로 존재하는 계층입니다. 가격 규칙이나 권한 확인의 결함은 사용자가 화면에서 잘못된 숫자를 발견하기 훨씬 전에 API 응답에서 드러나므로, 여기서의 테스트는 문제를 더 일찍, 그리고 원인에 더 가깝게 발견할 수 있도록 해줍니다.
두 번째 이유는 속도입니다. 요청 처리는 밀리초 단위로 완료되며 브라우저, 렌더링 엔진, 불안정한 요소 로케이터가 필요하지 않습니다. 테스터는 인터페이스 테스트에서 페이지를 로드하는 데 걸리는 시간 동안 수십 개의 엔드포인트를 테스트할 수 있으며, 프런트엔드가 웹사이트, 모바일 앱 또는 파트너 통합이든 관계없이 동일한 요청이 동일하게 동작합니다.
세 번째 이유는 안정성입니다. 레이아웃은 끊임없이 바뀌지만, 게시된 REST API는 안정적인 레이아웃을 제공합니다.tract는 안정적으로 유지될 것으로 예상됩니다. 그에 반해 작성된 테스트는 다음과 같습니다.trac재설계를 견뎌내지 못하기 때문에 다른 팀이 실제로 구축하는 제품 부분을 보호합니다.
API 메소드 유형
크게 4가지 종류가 있습니다 API 테스팅 메서드: GET, POST, DELETE, PUT.
- 바로– GET 메서드는 예시를 위해 사용됩니다.trac주어진 URI를 사용하여 주어진 서버에서 정보를 가져옵니다. GET 요청을 사용할 때는 다음과 같은 경우에만 해당됩니다.tract 데이터에 영향을 미치지만 다른 데이터에는 영향을 주지 않아야 합니다.
- POST– POST 요청은 새 엔터티를 생성하는 데 사용됩니다. 또한 HTML 양식을 사용하여 고객 정보, 파일 업로드 등의 데이터를 서버에 보내는 데에도 사용할 수 있습니다.
- PUT– 새 엔터티를 생성하거나 기존 엔터티를 업데이트합니다.
- 삭제– URI가 제공하는 대상 리소스의 현재 표현을 모두 제거합니다.
REST API를 테스트하는 방법
REST API 테스트를 위해서는 애플리케이션이 테스트용 샘플 API와 상호 작용해야 합니다. API를 테스트하려면 다음 두 가지가 필요합니다.
- API를 구동하기 위한 테스트 도구/프레임워크
- 샘플 REST API를 테스트하기 위한 자체 코드 작성
REST API 테스트 케이스는 다음과 같은 도구를 사용하여 테스트할 수 있습니다.
- 고급 휴식 클라이언트
- Postman- 휴식 클라이언트
- 리눅스에서의 컬
여기서는 Advanced Rest Client를 사용하겠습니다. Advanced Rest Client를 다운로드하는 단계는 다음과 같습니다.
Advanced REST Client를 어떻게 얻을 수 있나요?
- We Buy Orders 신청서를 클릭하세요. Google Chrome님의 웹 스토어
- "Advanced Rest Client"를 검색하거나 직접 이동하세요. 여기에서 확인하세요 그리고 확장 프로그램을 설치하세요
- Chrome의 앱 섹션(chrome://apps/)에서 "Advanced Rest Client(고급 휴식 클라이언트)" 아이콘을 선택하세요.
웹 스토어 목록은 아래와 같이 표시됩니다.
설치가 완료되면 아래 테스트 절차를 따라 테스트를 진행하십시오. RESTful API.
REST API 테스트 단계
여기서는 크롬 브라우저의 REST 클라이언트 확장 프로그램을 사용합니다. 이해를 돕기 위해 테스트용 더미 API를 사용하겠습니다.
http://ip.jsontest.com/
1단계) 고급 REST 클라이언트 열기
앱이 성공적으로 설치되면 고급 REST 클라이언트(ARC)를 실행합니다.
2단계) 입력하세요 URL API 테스트
샘플 REST API를 입력하세요. URL 테스트용으로 URL 텍스트 상자.
3단계) HTTP 메소드 선택
API 테스트에서 히트할 HTTP 메소드 유형에 대한 메소드 선택(예: POST)
4단계) 헤더 세트 제공
헤더 텍스트 상자에 헤더 세트를 제공합니다. 헤더 세트 삽입을 클릭합니다.
5단계) 헤더 설정 확인
다음 이 세트 사용을 클릭하세요.
6단계) 필수 본문 콘텐츠 제공
- 이제 본문 탭으로 전환하세요.
- 필요한 본문 콘텐츠 유형 및 편집기 보기를 설정합니다. 예: 본문 콘텐츠 유형: application/json
- 편집기 보기: 원시 입력.
- 페이로드 필드에는 테스트를 위해 데모 API의 요청 본문을 키-값 쌍 형태로 전달합니다. 예를 들어, {“key1″:”value1″,”key2″:”value2”}와 같이 입력합니다. POST API인 경우 본문 또는 매개변수를 전달해야 하며, 이는 지정된 페이로드 필드에 전달됩니다.
{"property" : ["Sites"], "report_type" : ["ALL"]}
⚠️ 경고: 유효하지 않은 페이로드를 가진 Content-Type이 application/json입니다. JSON 400 Bad Request 오류가 반환됩니다.
7단계) 테스트를 시작하기 위한 세부 정보 제출
- 보내기 버튼을 누르세요.
- 'DETAILS' 버튼을 클릭하면 응답 헤더를 볼 수 있습니다.
응답 세부 사항은 다음과 같습니다.
그 반응은 여전히 예상 결과와 비교하여 평가되어야 합니다.
결과 검증
웹 API 테스트에서는 주로 응답 코드, 응답 메시지 및 응답 본문을 확인해야 합니다.
응답 코드는 다섯 가지 유형으로 분류됩니다.
| 가족 | 카테고리 | 의미 |
|---|---|---|
| 1xx | 정보 | 접수 완료, 처리 중 |
| 2xx | 성공 | 완료됨; 200개 확인됨, 201개 생성됨 |
| 3xx | 리디렉션 | 추가 조치가 필요합니다 |
| 4xx | 클라이언트 오류 | 잘못된 페이로드, 토큰 또는 리소스입니다. |
| 5xx | 서버 오류 | 유효한 요청입니다. 서버 오류 발생 |
아래는 발생할 수 있는 응답 코드입니다.
한 번의 요청으로 엔드포인트가 작동하는 것을 증명할 수 있습니다. 여러 번의 요청을 통해 엔드포인트가 지속적으로 작동하는 것을 증명할 수 있습니다.
반드시 다뤄야 할 REST API 테스트 케이스
유용한 REST API 모음은 동일한 정상 경로 호출을 다른 데이터로 반복하는 대신 여러 범주에 걸쳐 제공됩니다.
- 행복한 길: 각 엔드포인트에 유효한 요청을 보내고 상태 코드, 스키마 및 모든 필드 값을 확인하십시오.
- 음성 사례: 형식이 잘못된 JSON, 지원되지 않는 메서드, 누락된 리소스 ID를 전송한 다음 500 오류 대신 400, 405, 404 오류를 예상합니다.
- 경계 값: 입력 필드가 1~200자까지 허용하는 경우, 0, 1, 200, 201을 모두 테스트하십시오. 유효성 검사 규칙은 범위 경계에서 제대로 작동하지 않을 수 있습니다.
- 특수 문자: 인코딩 오류를 드러내기 위해 악센트가 있는 문자, 이모티콘, 따옴표 및 멀티바이트 텍스트를 모든 필드에 입력해 보세요.
- 와tract 검사: 응답을 공개된 OpenAPI 또는 Swagger 사양과 비교하여 문서화되지 않은 변경 사항을 조기에 발견하십시오.
- 시퀀싱 : 상태 정보가 호출 간에 전달되므로 POST, GET, DELETE와 같이 실제적인 순서로 엔드포인트를 호출하십시오.
- 성능 건전성: 모든 실행 시 응답 시간을 기록하고 팀과 합의한 임계값을 초과하는 모든 엔드포인트를 표시합니다.
REST API 테스트 도구
테스트 단계에 따라 적합한 도구가 다릅니다.
| 수단 | 타입 | 가장 좋은 |
|---|---|---|
| 고급 휴식 클라이언트 | 데스크톱 클라이언트 | 빠른 수동 호출 |
| Postman | 데스크톱 클라이언트 | 컬렉션 및 팀 작업 공간 |
| JMeter | 부하 테스트 | 부하 시 응답 시간 |
| SoapUI | 기능 테스트 | 휴식과 비누를 함께 사용하세요 |
| 안심하세요 | Java 도서관 | 안정적인 사례 자동화 |
| cURL | 커맨드 라인 | 버그 보고서에 호출 내용을 붙여넣기 |
요약 내용을 확인하세요 API 테스트 도구.
대부분의 실제 엔드포인트는 요청을 보낸 사람이 누구인지 증명될 때까지 응답을 거부합니다.
REST API 인증 및 보안 검사
공개 데모 엔드포인트는 누구나 응답할 수 있지만, 실제 운영 환경의 REST API는 인증 체계 뒤에 숨겨져 있으며, 권한 부여 오류는 잘못된 필드 값보다 훨씬 더 심각한 문제를 야기할 수 있습니다. 먼저 정적 API 키, HTTP 기본 자격 증명, OAuth 2.0 베어러 토큰 또는 서명된 JSON 웹 토큰 중 어떤 인증 메커니즘을 사용하는지 파악해야 합니다.
인증된 요청이 성공하면 실패 경로를 차근차근 살펴보십시오.
- 자격 증명 없음: Authorization 헤더를 제거하세요. 그러면 401 Unauthorized 오류가 발생하고 본문에 레코드 데이터가 없을 것으로 예상됩니다.
- 자격 증명이 잘못되었습니다. 토큰의 문자 하나가 손상되었습니다. 이유를 설명하지 않는 메시지와 함께 401 오류가 다시 발생할 것으로 예상됩니다.
- 만료된 자격 증명: 토큰이 만료된 후에도 재사용하지 마십시오. 토큰이 승인되지 않고 거부되었는지 확인하십시오. 이는 흔히 발생하는 시간 차이 오류입니다.
- 권한 수준이 잘못되었습니다: 권한이 낮은 사용자로 인증하여 관리자 전용 엔드포인트를 호출합니다. 200 응답이 아닌 403 Forbidden 응답이 반환될 것으로 예상됩니다.
- 다른 사용자의 기록: 사용자 ID를 변경하여 사용자 A가 사용자 B의 데이터를 요청하도록 합니다. 이렇게 하면 접근 제어에 심각한 결함이 발생합니다.
마지막으로 모든 호출이 HTTPS를 통해 이루어지고, 실패한 응답에서 스택 트레이스가 유출되지 않는지 확인하십시오. traces 또는 버전 배너가 빠르게 반복되면 429 너무 많은 요청 오류가 발생합니다.
REST API 테스트는 인터페이스 테스트에는 없는 어려움을 수반합니다.
API 테스트의 과제
REST API 테스트 중에 테스터가 직면하는 흥미로운 문제는 다음과 같습니다.
- 테스트 환경이 API 호출의 매개변수를 다양하게 변화시켜 기능 검증은 물론 오류 발생 가능성까지 파악할 수 있도록 해야 합니다. 이를 위해 경계 조건 탐색 및 공통 매개변수 할당 등이 포함됩니다.
- 두 개 이상의 매개변수가 있는 호출에 대해 흥미로운 매개변수 값 조합 만들기
- API 호출이 이루어져야 하는 콘텐츠를 식별합니다. 여기에는 외부 환경 조건(주변 장치, 파일 등) 설정뿐만 아니라 API에 영향을 미치는 내부 저장 데이터도 포함될 수 있습니다.
- 함수가 실행되는 순서에 따라 API 호출 순서 지정
- API가 연속 호출에서 유용한 결과를 생성하도록 합니다.










