Rest api 테스트 수행가이드

REST API 테스트의 모든 것
2014.02 by JungGun
home: genycho.blog.me

- 목차 -
REST API의 이해
REST API 설계와 스펙
스펙기반 테스트 설계
테스트 툴을 이용한 테스트 수행
수행 사례와 빈발 결함

OpenAPI의 인기
“최근 인터넷 업계는 OpenAPI의 열풍이 불고 있다. 너도나도 OpenAPI를
공개하고 있고 사용자들에게 다양한 방식의 사용을 기대하고 있다.
최근 이 OpenAPI와 함께 거론되는 기술은 당연 REST이다. 구글, 아마존,
네이버 모두가 OpenAPI를 REST 방식으로 지원한다”
신용
정보
회사
우리 시스템
[ 예전의 OpenAPI ]
버스 도착정보
알림 서비스
개인이
만든 앱
게임
앱
게임 서버
비즈니스
서비스(예:CellWe)
스마트
폰
웹
HTTP
HTTP
HTTP
HTTP
스마트폰 보급과 함께다양한 디바이스에서의서비스 욕구↑

OpenAPI 란
- 데이터 플랫폼을 외부에 공개하여 다양하고 재미있는 서비스 및 어플리케이션을
개발할 수 있도록 외부 개발자와 사용자들과 공유하는 프로그램 (Daum)
- 다양한 서비스와 컨텐츠, 데이터를 좀더 쉽게 이용할 수 있도록 공개한 개발자를
위한 인터페이스 (Naver)
- 웹사이트가 자신의 기능을 이용할 수 있도록 공개한 프로그래밍 인터페이스로
내부를 모르더라도 공개된 API를 이용하여 해당 사이트의 기능, 데이터들을 쉽게
이용 가능 (Nate)
- a word used to describe sets of technologies that enable websites to
interact with each other by using REST, SOAP, JavaScript and other web
technologies (Wikipedia)

RESTful 웹 서비스
- REST (Representational State Transfer)
- SOAP기반, WSDL기반 웹서비스를 대체하는 개념
- 쉬운 사용성으로 Yahoo, Google, Facebook 등 각 서비스들이 SOAP, WSDL을
대체하여 서비스 중
- CRUD를 위해 HTTP 메소드를 사용
- Stateless 함 = 요청을 위해 특정 값, 세션, 쿠키값을 유지 하지 않음
- 디렉토리 구조와 같은 URI 을 통한 리소스 접근
- XML, JSON 데이터 구조를 통한 데이터 전송
웹 상에 공개되는 OpenAPI의 경우 RESTful 웹서비스(*)로
구현되는 경우가 많음

RESTful 웹 서비스 구성
- HTTP URI + HTTP Method
- 리소스 기반의 접근
HTTP Method
WADL URL
(End Point)
Resource Path
Query Parameter
(Method Parameter)
Path Parameter
(Resource Parameter)

REST METHOD
- CRUD 연산에 HTTP Method 를 이용
- POST, PUT의 경우 Request Body 필요

REST API의 설계와 스펙
책
“일관성 있는 웹 서비스 인터페이스 설계를 위한 REST API 디자인 규칙”과
“apigee사의 web API design eBook”

※ 책 “일관성 있는 웹 서비스 인터페이스 설계를 위한 REST API 디자인
규칙활용 시나리오” 목차 소개
2장. URI 식별자 설계
01 URI 13
02 URI 형태
규칙: 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용한다
규칙: URI 마지막 문자로 슬래시(/)를 포함하지 않는다
규칙: 하이픈(-)은 URI 가독성을 높이는 데 사용한다
규칙: 밑줄( _ )은 URI에 사용하지 않는다
규칙: URI 경로에는 소문자가 적합하다
규칙: 파일 확장자는 URI에 포함시키지 않는다
03 URI 권한 설계
규칙: API에 있어서 서브 도메인은 일관성 있게 사용해야 한다
규칙: 클라이언트 개발자 포탈 서브 도메인 이름은 일관성 있게 만들어
야 한다
04 리소스 모델링
05 리소스 원형
도큐먼트
컬렉션
스토어
컨트롤러
06 URI 경로 디자인
규칙: 도큐먼트 이름으로는 단수 명사를 사용해야 한다
규칙: 컬렉션 이름으로는 복수 명사를 사용해야 한다
규칙: 스토어 이름으로는 복수 명사를 사용해야 한다
규칙: 컨트롤러 이름으로는 동사나 동사구를 사용해야 한다
규칙: 경로 부분 중 변하는 부분은 유일한 값으로 대체한다
규칙: CRUD 기능을 나타내는 것은 URI에 사용하지 않는다
07 URI Query 디자인
규칙: URI 쿼리 부분으로 컬렉션이나 스토어를 필터링할 수 있다
규칙: URI 쿼리는 컬렉션이나 스토어의 결과를 페이지로 구분하여 나
타내는 데 사용해야 한다
08 정리
3장. HTTP를 이용한 인터랙션 설계
02 요청 메서드
규칙: GET 메서드나 POST 메서드를 사용하여 다른 요청 메서드를 처리해서
는 안 된다
규칙: GET 메서드는 리소스의 상태 표현을 얻는 데 사용해야 한다
규칙: 응답 헤더를 가져올 때는 반드시 HEAD 메서드를 사용해야 한다
규칙: PUT 메서드는 리소스를 삽입하거나 저장된 리소스를 갱신하는 데 사
용해야 한다
규칙: PUT 메서드는 변경 가능한 리소스를 갱신하는 데 사용해야 한다
규칙: POST 메서드는 컬렉션에 새로운 리소스를 만드는 데 사용해야 한다
규칙: POST 메서드는 컨트롤러를 실행하는 데 사용해야 한다
규칙: DELETE 메서드는 그 부모에서 리소스를 삭제하는 데 사용해야 한다
규칙: OPTIONS 메서드는 리소스의 사용 가능한 인터랙션을 기술한 메타데
이터를 가져오는 데 사용해야 한다
03 응답 상태 코드
규칙: 200("OK")는 일반적인 요청 성공을 나타내는 데 사용해야 한다
규칙: 200("OK")는 응답 바디에 에러를 전송하는 데 사용해서는 안 된다
규칙: 201("Created")는 성공적으로 리소스를 생성했을 때 사용해야 한다
규칙: 202("Accepted")는 비동기 처리가 성공적으로 시작되었음을 알릴 때
사용해야 한다
규칙: 204("No Content")는 응답 바디에 의도적으로 아무것도 포함하지 않
을 때 사용한다
규칙: 301("Moved Permanently")는 리소스를 이동시켰을 때 사용한다
규칙: 302("Found")는 사용하지 않는다
규칙: 303("See Other")은 다른 URI를 참조하라고 알려줄 때 사용한다
규칙: 304("Not Modified")는 대역폭을 절약할 때 사용한다
규칙: 307("Temporary Redirect")은 클라이언트가 다른 URI로 요청을 다시
보내게 할 때 사용해야 한다
규칙: 400("Bad Request")은 일반적인 요청 실패에 사용해야 한다
규칙: 401("Unauthorized")은 클라이언트 인증에 문제가 있을 때 사용해야
한다
규칙: 403("Forbidden")은 인증 상태에 상관없이 액세스를 금지할 때 사용
해야 한다

규칙: 404("Not Found")는 요청 URI에 해당하는 리소스가 없을 때 사용
해야 한다
규칙: 405("Method Not Allowed")는 HTTP 메서드가 지원되지 않을
때 사용해야 한다
규칙: 406("Not Acceptable")은 요청된 리소스 미디어 타입을 제공하
지 못할 때 사용해야 한다
규칙: 409("Conflict")는 리소스 상태에 위반되는 행위를 했을 때 사용
해야 한다
규칙: 412("Precondition Failed")는 조건부 연산을 지원할 때 사용한
다
규칙: 415("Unsupported Media Type")은 요청의 페이로드에 있는 미
디어 타입이 처리되지 못했을 때 사용해야 한다
규칙: 500("Internal Server Error")는 API가 잘못 작동할 때 사용해야
한다
04 정리
5장. 표현 디자인
01 메시지 바디 포맷
규칙: JSON 리소스 표현을 지원해야 한다
규칙: JSON은 문법에 잘 맞아야 한다
규칙: XML과 다른 표현 형식은 선택적으로 지원할 수 있다
규칙: 추가 봉투는 없어야 한다
02 하이퍼미디어 표현
규칙: 링크는 일관된 형태로 나타내야 한다
규칙: 링크 관계를 표현할 때에는 일관된 형태를 사용해야 한다
규칙: 링크를 표현할 때는 일관된 형태를 사용해야 한다
규칙: 응답 메시지 바디 표현에 셀프 링크를 포함해야 한다
규칙: 진입 API URI 수를 최소화하라
규칙: 리소스의 상태에 따라 가능한 액션을 표현하기 위해서 링크를
사용해야 한다
03 미디어 타입 표현
규칙: 미디어 타입 format은 일관성 있는 폼을 사용해야 한다
규칙: 미디어 타입 스키마를 표현할 때는 일관성 있는 형식을 사용해야 한
다
04 오류 표현
규칙: 오류는 일관성 있게 표현한다
규칙: 오류 응답은 일관성 있게 표현한다
규칙: 일반적인 오류 상황에서는 일관성 있는 오류 타입을 사용해야 한다
05 정리
6장. 클라이언트 영역
01 개요
02 버전을 정의하는 방법
규칙: 새로운 개념을 도입하려면 새로운 URI를 사용해야 한다
규칙: 표현 형태의 버전을 관리하기 위해서는 스키마를 사용해야 한다
규칙: 엔티티 태그는 표현 상태 버전을 관리하기 위해 사용한다
03 보안
규칙: 리소스 보호를 위해 OAuth를 사용할 수 있다
규칙: 리소스 보호를 위해 API 관리 솔루션을 사용할 수 있다
04 응답 표현 조합
규칙: URI의 쿼리 부분은 부분 응답을 지원할 때 사용해야 한다
규칙: URI 쿼리 부분은 연결된 리소스를 포함할 때 사용해야 한다
05 하이퍼미디어 처리
06 자바스크립트 클라이언트
규칙: 자바스크립트에서 여러 웹 사이트에 읽기 접근이 가능하도록
JSONP를 지원해야 한다
규칙: 자바스크립트에서 여러 웹 사이트에 읽기/쓰기 접근이 가능하도록
CORS를 지원해야 한다

API 스펙 예 (NAVER (영화)검색 OpenAPI)
- 기본 URL, API
: https://openapi.naver.com/v1/search/movie
- API 설명

- 응답코드
400 HTTP 코드는 Bad request 를 의미하며 이에 대해 별도의 에러 코드를
정의해서 상세한 에러 사유를 전달한다

스펙 기반의 테스트 접근
(테스트 설계)

명세를 이용한 테스트 접근
- OpenAPI의 특성 상 이 API를 사용할 일반 사용자 관점에서 접근할 필요가 있음
- 스펙 기반으로 테스트를 수행하고, 이를 통해 기능 뿐만 아니라 스펙에 대한 검증을
동시에 수행
Test Basis
Test Condition Test Condition
Test
Case
Test
Case
Test
Case
Test
Procedure
Test
Procedure
테테테테
스스스스
트트트트
설설설설
계계계계
테테테테
스스스스
트트트트
설설설설
계계계계
HTTP Method Input parameter
Test
Case?
Test
Case?
Test
Case?
Test
Case?… …
…
Test
Procedure
Test
Procedure
Test
Procedure
Test
Procedure
명세

테스트 접근 전략
API의 오픈 정도, 대상, 중요도에 따라서 테스트 설계 수준을 정한다
Lv
1
Lv
2
Lv
3
Lv
4
Lv
5
레벨 1) 기본적인 테스트
필수입력 값/모든 입력 값에 대한 기본적인 테스트
레벨 2) 응답코드 기반 테스트
스펙에 정의된 응답코드별 테스트
레벨3) 메소드 타입별 테스트
Get/Post/Put/Delete 방식에 따른 테스트 접근
레벨4) 입력 파라미터에 따른 테스트
입력 값의 타입, 코드형, 범위,순서에 따른 테스트
레벨5) 비즈니스 흐름 기반 테스트
보다 복잡한 정황에 따른 테스트
(공통) 인증, 인코딩, 타임존 등에 대한 테스트

(1) 기본 테스트
- 필수입력 값/ 모든 입력 값 2개 테스트 케이스로 테스트를 수행하고 그 결과가 맞는지
상세하게 확인한다
yearto는 yearfrom과 함께 사용되어야 한다.
검색을 원하는 영화의 제작년도(최대)를 의미한다.
-N
integer(ex :
2008)
yearto
yearfrom은 yearto와 함께 사용되어야 한다.
검색을 원하는 영화의 제작년도(최소)를 의미한다.
-N
integer(ex :
2000)
yearfrom
검색을 원하는 국가 코드를 의미한다. 국가코드는 대문자만
사용 가능하며, 분류는 다음과 같다.
한국 (KR), 일본 (JP), 미국 (US), 홍콩 (HK),
영국 (GB), 프랑스 (FR), 기타 (ETC)
-Nstringcountry
검색을 원하는 장르 코드를 의미한다. 영화 코드는 다음과 같
다.
1: 드라마 2: 판타지 3: 서부 4: 공포 5: 로맨스 6: 모험 7: 스릴
러 8: 느와르 9: 컬트 10: 다큐멘터리 11: 코미디 12: 가족 13:
미스터리 14: 전쟁 15: 애니메이션 16: 범죄
-Nstringgenre
검색의 시작 위치를 지정할 수 있다. 최대 1000까지 가능하
다.
기본값 1,
최대 1000
Nintegerstart
검색 결과 출력 건수를 지정한다. 최대 100까지 가능하다.
기본값 10,
최대 100
Nintegerdisplay
검색을 원하는 질의. UTF-8 인코딩이다.-Ystring (필수)query
설명기본 값필수여부타입요청 변수명
https://openapi.naver.com/v1/search/movie.xmlURL
GETHTTP METHOD
영화정보 검색 APIAPI명
API 스펙 예

테스트 접근 예
- API가 기대한 대로 정상 수행되는지 확인하는 가장 기본적인 테스트
- 실제 테스트를 할 때는 기본 테스트와 응답코드 기반 테스트는 필수라고 생각된다
기본 테스트
필수입력
모든입력
영화이름
영화이름,
display, start,
genre, country,
yearfrom, yearto
입력한 값을 제외한 나머지 파라미
터들이 정해진 디폴트 값으로 설정
되어 정상 수행되었는지 확인한다
디폴트 값이 아닌 입력한 각 값들로
기능이 수행되었는지 확인한다

(2) 응답코드 기반 테스트
- 스펙에 정의된 응답코드 별로 해당 응답코드를 발생시키는 테스트 케이스를 1개씩 생성
500
404
400
400
400
400
400
HTTP코드
서버 내부 에러가 발생하였습니다. 포럼에
올려주시면 신속히 조치하겠습니다.
System Error (시스템 에러)SE99
검색 API 대상에 오타가 없는지 확인해 보
세요.
Invalid search api (존재하지 않
는 검색 api 입니다.)
SE05
검색어를 UTF-8로 인코딩하세요.
Malformed encoding (잘못된 형
식의 인코딩입니다.)
SE06
sort 요청 변수값에 오타가 없는지 확인해
보세요.
Invalid sort value (부적절한 sort
값입니다.)
SE04
start 요청 변수값이 허용 범위(1~1000)인지
확인해 보세요.
Invalid start value (부적절한
start 값입니다.)
SE03
display 요청 변수값이 허용 범위(1~100)인
지 확인해 보세요.
Invalid display value (부적절한
display 값입니다.)
SE02
검색 API 요청에 오류가 있습니다. 요청
URL, 필수 요청 변수가 정확한지 확인 바랍
니다.
Incorrect query request (잘못된
쿼리 요청입니다.)
SE01
조치 방안에러 메시지에러 코드

- 각 응답 코드가 발생하는 입력 값과 상황을 설정하여 테스트를 수행한다
- 하나의 응답코드가 여러 상황에 따라 발생할 수 있는 경우 테스트 케이스를 추가한다
- 실제 구현에 따라 공통으로 처리되는 에러(시스템 오류, 인코딩 등)인 경우는 공통으로
처리한다
응답코드
테스트
400::SE01
필수입력 파라미터
누락
에러 코드 및 메시지 Incorrect query request (잘
못된 쿼리 요청입니다 )가 발생하는지 확인한다
400::SE02
400::SE03
400::SE04
display =101 요
청
에러 코드 및 메시지 Invalid display value (부적
절한 display 값입니다) 가 발생하는지 확인한다
에러 코드 및 메시지 Invalid start value (부적절
한 start 값입니다)가 발생하는지 확인한다
에러 코드 및 메시지 Invalid sort value (부적절한
sort 값입니다) 가 발생하는지 확인한다
start = a 요청
스펙 오류 발견

(3) 메소드 타입별 테스트
- Get/Post/Put/Delete 방식에 따른 테스트 접근
- 조회(GET)는 조회 결과가 있을 때와 없을 때,
- 등록(POST)은 로직적으로 유니크해야 하는 값을 넣었을 때나, 이미 있는 값을 또 등록
시도할 때
- 수정(PUT) 은 존재하지 않는 데이터에 대한 수정 시도 외에 등록과 유사한 테스트를
- 삭제(DELETE)는 존재하지 않는 데이터에 대한 삭제 시도나, 하위 데이터(또는 관련된
데이터)가 존재하는 경우 상위 데이터 삭제 시도 등을 테스트한다

Method별
테스트
조회
조회 결과가 없을
때
조회 결과에 데이터가 없는지 확인한다
등록
수정
유일해야 하는 값
에 대해 중복 등록
할 때
정의된 에러코드가 발생하는지 확인한다
적합한 에러코드가 정의되었는지 스펙을 검토한다
존재하지 않는 데
이터에 대한 수정
시도
조회 결과가 너무
많을 때
유일해야 하는 값
에 대해 중복 되도
록 수정 할 때
삭제
페이징 등 사전에 정한 기준에 따라 적절한 양만
조회가 되는지 확인한다
존재하지 않는 데
이터에 대한 삭제
시도
상하 관계가 있는
데이터에서 상위
데이터 삭제
연관관계가 있는 데이
터가 수정으로 인해 관
계가 끊어질 때
사전에 정의한 처리 로직에 따라 수행되는지 확인
한다 (수정을 막거나, 다른 요소의 연결 관계를 일
괄로 처리 등)
사전에 정의한 처리 로직에 따라 삭제되는지 확인
한다 (삭제를 막거나, 다른 요소의 연결 관계를 일
괄로 처리 등)

(4) 입력 파라미터에 따른 테스트
- 입력 값의 타입 - string , 숫자, 정해진 코드, 날짜, 범위형 변수에 따른 테스트 설계
검색을 원하는 영화의 제작년도(최대)를 의미한다.
yearto는 yearfrom과 함께 사용되어야 한다
-N
integer(ex :
2008)
yearto
검색을 원하는 영화의 제작년도(최소)를 의미한다.
yearfrom은 yearto와 함께 사용되어야 한다
-N
integer(ex :
2000)
yearfrom
검색을 원하는 국가 코드를 의미한다. 국가코드는 대문자
만 사용 가능하며, 분류는 다음과 같다.
한국 (KR), 일본 (JP), 미국 (US), 홍콩 (HK),
영국 (GB), 프랑스 (FR), 기타 (ETC)
-Nstringcountry
검색을 원하는 장르 코드를 의미한다. 영화 코드는 다음과
같다.
1: 드라마 2: 판타지 3: 서부 4: 공포 5: 로맨스 6: 모험 7: 스
릴러 8: 느와르 9: 컬트 10: 다큐멘터리 11: 코미디 12: 가족
13: 미스터리 14: 전쟁 15: 애니메이션 16: 범죄
-Nstringgenre
검색의 시작 위치를 지정할 수 있다. 최대 1000까지 가능
하다.
기본값 1,
최대
1000
Nintegerstart
검색 결과 출력 건수를 지정한다. 최대 100까지 가능하다.
기본값 10,
최대 100
Nintegerdisplay
검색을 원하는 질의. UTF-8 인코딩이다.-Ystring (필수)query
설명기본 값
필수여
부
타입요청 변수명
문자
숫자
코드
범위-최소/최대
연도
코드
범위

Method별
테스트
문자
빈문자(“”),공백문자(“_”)
잘못된 입력 값에 대해
필요에 따라 적절한 에러
와 메시지를 제공해 주는
지 확인한다
숫자
시간,연도
코드
범위
앞뒤 공백문자(“_단어_”)
문제가 될수있는 특수문자
(/,’,?,$,&...)
일반적인 특수문자
너무 긴 문자열
숫자가 아닌 문자
Int 타입을 벗어나는 큰 숫자
소수, 음수, 0 값 등
잘못된 구분자
시간,연도 구분을 넘어가는
숫자(25시간,13월,9999년)
정의된 코드가 아닌 값
대소문자가 다른 코드값
시작-끝, 측위(각도), 시간 등
에서 최소,최대 범위를 벗어나
는 값

(5) 비즈니스 흐름 기반 테스트
- 복잡한 정황을 고려하여 다른 API 와의 호출관계, 자원의 상태나 존재 유무에 따른
테스트를 고민한다
(예1) 재고가 떨어진 제품에 대해 구매 요청시 현재 재고가 아닌 예약 주문의 수량이
증가하는지 확인
(예2) 회원가입이 되어 있지 않은 사용자가 구매 신청 시 게스트 ID가 부여되어 진행된다
(예3) 권한에 대한 테스트
- 글로벌 지원을 위한 확인사항
(예1) 금액에 있어서 화폐단위를 입력 값으로 고려하지 않았다
(예2) 시간에 대해 타임존을 구분하지 않았다
(예3) 위치 정보에 대해 위,경도 기반으로 입력 받지 않았다

(6) 공통
- 인증되지 않은 요청에 대한 에러코드 반환
- 인코딩이 맞지 않았을 때의 테스트
등

툴을 이용한 REST API
테스트 수행

툴 선정 시 고려사항
1) 테스트 기능이 포함되어 있는지
- 스크립트를 통해서 API를 호출하고 결과를 검증하는 기능이 있는지
2) 반복,회귀 테스트가 가능하고 쉬운지
- 툴이 반복적인 테스트를 위한 기능을 제공하는지
3) 스크립트 작성자의 특성
- 개발자인지 별도 테스트 인력인지에 따라 툴 스크립트 언어 의존성
3’) 스크립트 유지보수 역할자의 특성
- 간혹 스크립트 유지보수 담당자가 다른 경우가 있음
4) 스크립트 유지보수가 용이한지

OpenAPI 테스트 툴 소개
https://github.com/stekycz/restful-api-testing/blob/master/chapters/03-restful-api-description-and-testing-tools.md
개발 코드에
Swagger가 적용되어
있어야 함
-크롬 브라우저에서 수행제약사항
GUIJavaGUIGUI스크립트 언어
수행불가Junit 기능 그대로 활용가능기능 확장 중?
커맨드라인 인터페이스를
통해 반복테스트 수행
반복테스트 지
원
수행하고 바로 확인
만 가능
Junit의 기능을 그대로 활용
기본적인 테스트 기능 존
재
setUp,tearDown,
assertion 등 테스트 특화
된 기능 포함
테스트기능
무료무료무료
무료 버전과 상용버전이
있으며 무료 버전에는 몇
가지 기능이 미지원
무료,상용
Swagger는 REST
API 설계부터 테스트
까지를 지원하려 하
고 있으며 웹UI를 통
해 스펙 제공 및 실
행결과까지를 확인
할 수 있음
구글 개발팀이 만든 REST
API 테스트 쿨로 junit 기반
으로 쉽게 REST API를 테스
트하고 결과를 확인할 수 있
음
크롬 브라우저의 플러그
인으로 손쉽게 REST API
값 검증이 가능.
웹UI 상에서 테스트를 수
행하고 결과를 캡처하여
재검증이 가능
가장 널리 알려져 있는
REST API 툴
설명
http://swagger.io/
https://github.com/rest-
assured/rest-assured
http://www.getpostman.c
om/
https://www.soapui.org/공식사이트
SwaggerUIRestAssuredPostManSoapUI항목
※ REST API 테스트 툴은 이외에 훨씬 많이 있으며 4개 툴을 선정한 사유는 작성자 마음대로..

OpenAPI 테스트 툴
쓰기
편한
정도
테스트 기능
많음적음
스크립트
스킬
필요
쓰기
쉬움
SoapUI
Rest-Assured
PostMan
SwaggerUI
※ REST API 테스트 툴은 이외에 훨씬 많이 있으며 4개 툴을 선정한 사유는 작성자 마음대로..

(1) SoapUI
- SOAP, REST 방식을 모두 지원하는 웹서비스 기능 테스트 툴
- 무료, 오픈소스
- GUI 제공 (Java Swing으로 개발)
- 무료버전과 상용버전이 있음(Pro버전)
- 공식 사이트 : www.soapui.org
싸이트의 문서가 굉장히 잘 나와 있음
- 웹 서비스 특유의 http 호출, 응답을 툴을 통해 테스트 지원
- 성능/보안 테스트 기능 확보

SoapUI GUI 실행
- 툴 설치 후 실행하면 swing으로 개발된 별도 프로그램이 실행 됨
Toolbar 영역
Main toolbar, Icons toolbar
Navigator 영역
각 구성요소를 생성, 수
정, 삭제하면서 관리하기
위한 영역
Properties 영역
각 구성요소의 속성 및 Parameter
를 설정하기 위한 영역
Main 작업 영역
각 구성요소에 대한 주요 작
업 수행 및 수행결과를 확인
하기 위한 영역

SoapUI 스크립트 구성
- 하나의 워크스페이스에 여러 개의 프로젝트가 있을 수 있으며 프로젝트
하위에는 각 Request를 정의하는 부분과 TestSuite을 정의하는 부분이 존재한다
└ Service
└ Resource
└ Method
└ Request
└ TestSuite
└ TestCase
└ TestStep
(2) API를 테스트하기 위한 요소로 TestSuite, TestCase,
TestStep 의 순서로 계층 구조로 생성됨
(1) API를 정의하는 요소로 Service, Resource,
Method, Request 의 순서로 계층 구조로 정의됨
Workspace
└ Project

SoapUI 스크립트 작성
API 스펙에 따라 요청 값을 추가한다
실행 버튼을 클릭해서 호출이 수행되는지
확인해 볼 수 있다
[ 기본 테스트의 입력 데이터 예 ]
target : movie
query : 명량
display : 20( 기본값 10, 최대 100(,
start : 1 (기본값 1, 최대 1000(
genre : 20 (액션 장르)
country : KR (한국)
yearfrom : 2014 (제작년도)
yearto : 2015

결과 검증
수행 결과에서 Add Assertion 메뉴로 결과 값을 검증하는 스크립트를 추가
항목의 결과가 기
대하는 값과 일치
하는지 여부 점검
항목의
개수 점검
항목의 존재
여부 점검
항목의 결과가 기대하는
값과 일치하는지 점검
(Regular Expression)
항목의 존재 여부
(Script 방식)

(2) Rest-Assured
- Junit을 기반으로 rest-assured 라이브러리를 활용하여 작성하는 툴
- 오픈소스, RESTful 웹 서비스 방식을 지원
- 사이트 : https://github.com/rest-assured/rest-assured/wiki
( 예 ) get 방식으로 /lotto 요청했을 때 다음과 같은 응답(JSON)을 받았다고 하면
Junit 코드에서는 get(“/lotto”) 로 호출하고 그 결과 값에 대해 다양하게 확인 가능

(3) PostMan
- 구글 크롬 브라우저의 플러그인 형태로 제공
- http://www.getpostman.com/
- 기본 기능은 무료이나 고급화된 기능은 상용으로 제공
- 단순 호출/확인을 넘어서 테스트로 저장하고 실행시키는 기능 탑재

(4) SwaggerUI
- http://swagger.io/
- Swagger는 REST API 스펙 내용을 개발코드에 정의하고 이로부터 스펙을 자동으로 생성해
주는 기능에서 시작해서 현재는 REST API 프레임워크라 자칭하고 있다
- Swagger UI를 통해 REST API 스펙과 수행 결과를 확인할 수 있음
- 무료
- (제약사항) 개발 코드에 Swagger가 적용되어 있어야 사용 가능

어떤 툴을 사용할 것인가?
- 개발 언어에 능숙하지 않은 별도 테스트 인력이 작성한다면?
> 오픈소스 버전의 SoapUI나 PostMan을 이용해 테스트를 수행한다
- 스크립트 작성이 가능하고, 별도 복잡한 단계가 필요하다면?
> 개발팀에서 REST API를 자바로 구현한 경우 Java로 작성하는 Rest-Assured가 굉장히
적합한 경우가 많다. 개발자와 같은 언어로, 같은 IDE에서 얘기하는 강점이 생긴다
- 그냥 한번 확인만 해 볼거라면?
> PostMan을 써서 쉽고 빠르게 REST API를 확인해 볼 수 있다
- Swagger를 이용하고 있다면?
> API 스펙 문서를 Swagger를 이용해서 생성하고 있다면 SwaggerUI를 사용해서 API를
호출해 볼 수 있다. 하지만 Swagger UI 자체는 수행한 호출을 검증하고 자동 테스트하는
기능이 포함되어 있지 않다. (Swagger CodeGen을 통해 junit 형태의 호출 코드 생성이
가능)

테스트 수행 사례
쇼핑몰 사용자 인증 및 물품 구매 요청 API
(1) 로그인 API
(2) 구매요청 API
쇼핑 앱쇼핑 앱
모바일 서버
쇼핑 사이트쇼핑 사이트
(1) 로그인 요청
(1’) 확인(완료)
(a) 사용자 정보확인,
인증키 반환
(2) 상품구매 요청
(2’) 확인(완료)
(b) 인증키 확인,
구매진행
로그인 요청
구매 요청
서버단의 구매요청 API 테스트를 위해서는 사전에
적합한 인증키를 알고 있어야 함

SoapUI를 이용한 REST API 테스트 수행
1) 스펙 리뷰
2) 테스트 요건 도출
3) 테스트 요건 리뷰,
인터뷰 with 개발팀
4) API 수행을 위한
기술 이슈 분석
5) 가상의 클라이언트
구현(java)
6) SoapUI 확장 기능 이용
인증키 생성 setUp 구현
7) 테스트 수행 및 결과 리뷰

결함 사례
- 필수 입력 값만 넣고 기능 수행 시 스펙에 정의된 디폴트 값으로 처리되지 않는 경우
- 필수 입력 체크가 누락되거나 잘못된 경우
- 선택 입력 값이 반영되지 않는 경우
- 특정 상황에 대해 정의한 에러코드가 발생하지 않는 경우
- 특정 상황에 대해 적합한 에러코드가 아닌 다른 에러 코드가 발생하는 경우
- 스펙 오류(현행화, 맞지 않음, 상세하지 않음 등)
- 에러코드가 상세하지 않아 사용자가 정확한 에러의 원인을 알기 어려운 경우
- DB에서 허용된 값보다 긴 값으로 요청 시 500 에러코드 및 DB 에러 메시지가
그대로노출되는 경우

Rest api 테스트 수행가이드

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Rest api 테스트 수행가이드

Similar to Rest api 테스트 수행가이드 (20)

More from SangIn Choung

More from SangIn Choung (16)

Rest api 테스트 수행가이드