테스트 자동화 툴인 ReadyAPI(soupUI)에는 script 언어로 groovy가 쓰인다.
아무래도 원하는 바를 쉽게 하려면 groovy를 조금이라도 아는 게 중요, 지인짜 기본적인 것만 언급한다.
코드 끝에 세미콜론 있어도 되고 없어도 되고..
주석
//한줄
/* 여러줄
애해해
ㅇㅇㅇ*/
로그
//()가 있어도 되고
log.info("Result :" + c);
//괄호를 생략해도 가능
log.info "soapUI script"
log.info "aa" + c
변수 선언 def
string to json
import groovy.json.JsonSlurper
def resResponse = "{'a':'bb', 'n':3}"
//string 형태의 json을 진짜 json으로 바꿔주는 lib.function
def json = new JsonSlurper().parseText(restResponse)
//이후에는 json 접근하 듯 접근 가능
log.info json.a
//결과: bb
나머지는 java랑 비슷, 단 stream 쓸 때 {it -> } 로 내부 변수명이 it로 지정되어 있고 별도의 함수가 있는 듯 하다.
api management tool sits between client and backend
reverse proxy
An API gateway is set up in front of the microservices and becomes the entry point for every new request being executed by the app. It simplifies both the client implementations and the microservices app.
기능들
TLS termination
ssl /tls 1.3 지원
client authentication
auth_jwt 로 키고/켜고 가능
auth_jwt_key_file 로 저장된 키파일(.jwk)불러올 수 있음
키가 유효하면 프록시 됨
fine-grained access control
jwt_claim_uid -> 토큰 안 uri 값 가져올 수 있음, 가져와서 더 상세한 조건으로 제한 가능
request routing
uri별로 어디로 프록시할지 정할 수 있음
proxy_pass 와 =,~ 등을 이용한 정규식 사용 가능
rate limiting
limit_req_zone
속도 제한 가능(ex. 5r/m = 5requests per a minute); 사실 횟수 제한에 가까움
이를 초과하면 limit_req_status로 설정해둔 status code가 response로 내려감
#기본 경로
/etc/nginx
#메인 설정
/etc/nginx/nginx.conf
include /etc/nginx/conf.d/*.conf;
#설정 값 경로 -> alphabetical order로 설정파일 읽음
/etc/nginx/conf.d
#nginx -T 로 설정값 읽는 순서 파악 가능
reverse proxy로서의 역할
server side proxy; client와 백엔드 사이에서 연결 중재
server블락 안의 proxy_pass 지시문
연결이 끊어지기 전에 연결을 닫고, 백엔드에 대한 새 연결을 하는데, 도중에 original 정보 손실 가능성 있음
클라이언트 정보(ip, request, etc) 캡처 후 연결 종료
백엔드로 새 연결 시 기존 정보를 헤더(proxy_set_header)에 담아서 전달
웹서버 역할도 하고 애플리케이션을 호스팅도 하면서 프록시역할도 함
location / {
proxy_pass http://127.0.0.1:8080;
}
이것이 기본적인 구문이다. 즉, 현재 서버에 / 로 시작하는 path로 접근하면, http://127.0.0.1:8080 으로 return 한다는 의미이다. 그러면 실제 사용자는 8080 포트에 접근하지 않았지만 8080 포트에 접근한 것과 동일한 효과가 발생한다.
nginx는 클라이언트가 접근한 path를 보고, 가장 적합한 location의 블럭으로 요청을 보내서 처리하게 된다. 주소에 대한 규칙 및 우선순위는 다음과 같다.
api 두 개를 순차적으로 요청할 때, 첫 번째 api 결과로 얻은 list안의 어떤 값을 두 번째 api의 요청 값에 넣어 순차적으로 테스트하는 방법을 알아본다. 이전 글에서 다룬 chaining test랑도 비슷하지만, chaining test에서는 object안의 한 항목을 variable로 set 해서 전달했다면, 여기서는 마치 for loop을 도는 것처럼 list안의 항목을 하나씩 돌아 테스트한다.
이전에 다룬 bulk test와도 비슷하지만 별도의 csv파일을 활용하지 않고 진행하는 것에 차이가 있다.
여기서 status = '01' 이면 active, '01'이 아니면 inactive이다. 원하는 것은 active 한 object의 playerId를 꺼내서 다음 api의 request항목(여기서는 path param)에 넣어 순차적으로 요청하는 것이라면, 테스트 코드를 어떻게 작성해야 할까.
const playerIds = pm.collectionVariables.get("playerIds");
pm.test("Status code is 200", function () {
pm.response.to.have.status(200); //6. 현재 요청이 성공인지 우선 확인
});
if(playerIds && playerIds.length > 0){ //collection-var의 array에 데이터가 있는지 확인하고, 있으면
postman.setNextRequest("get affiliate by asp"); //7. 자기자신을 다시 실행
}else{
postman.setNextRequest(null); //7. 없으면 끝
}
이렇게 두고 테스트하니 아래처럼 첫 번째 api는 1번 두 번째 api는 playerIds array의 크기(여기서는 29)만큼의 루프를 모두 돌아 정상 실행됨을 확인할 수 있었다.
