성능 테스트 기법 (3) Scripting for Rest API
Updated:
1. 단위 성능 테스트에 대한 고객 관심 증가
다양한 Project들을 대상으로 성능 테스트 지원을 나가다 보면, 최근 몇년 사이 눈에 띄게 달라진 고객들의 (공통적인) 성능관련 요구사항이 느껴지는 것이 사실입니다. 그것은, “주요 단위 기능”들에 대한 성능 테스트가 이루어지지 않은 채로, 시스템 Open을 1달여 남겨둔 시점에 통합 성능테스트만 수행되고 마는 것에 대한 아쉬움을 토로하는 내용들입니다.
기존에는 AS-IS Workload 분석에 따라, 전체 업무의 80% 이상의 비중을 차지하고 있는 대표 업무들을 10~20개 사이로 선정해서 성능 테스트를 수행한 후 결과 보고해도, 큰 이슈 없이 지나갔던 것이 사실입니다.
하지만, 최근의 경험들을 통해 성능테스트가 수행되지 않은 채로 상용환경에 노출되는 주요 API 기능들이, 시스템 Open 이후 실제적인 장애의 원인이 될 수 있다는 점에 대한 고객의 위험 인지 수준이 높아지면서, “단위 성능테스트”에 대한 요구들이 조금씩 늘어나고 있는 상황으로 보여집니다.
우리 모두에게 익숙한 최근의 API 장애 사례로는, 작년 3월 ‘공적 마스크 대란’으로 온국민의 관심이 집중되었던, ‘마스크 재고 조회’ 기능 관련 OPEN API의 장애 사건이 있습니다.
‘마스크앱’ 서비스, 첫날부터 ‘삐거덕’ 조선비즈 박현익 기자 입력 2020.03.11
공적 마스크 판매 현황 등을 알려주는 애플리케이션(앱)과 웹 서비스가 11일 공식 개시됐지만 접속자가 몰리면서 제대로 작동되지 않고 있다. 서버에서 갑자기 늘어나는 트래픽(접속량)을 감당하지 못한 탓이다.
이처럼 각 서비스들이 일제히 지연 현상을 나타낸 것과 관련해 업체들은 민간 개발자들에게 API(응용프로그래밍 인터페이스) 형태의 가공된 정보를 제공하는 정부 문제라고 설명했다.
Source: https://biz.chosun.com/site/data/html_dir/2020/03/11/2020031101366.html
2. 단위 성능 테스트는 현실적으로 가능한가요?
이 질문은 상당히 ‘현실적인 질문’인 것이 사실입니다. ‘단위 성능 테스트’를 추가로 수행하기 위해, 성능 테스트 이전 시점에 (보통 통합 테스트가 한참 진행되는 즈음에) Project에 들어가보면, 온라인 사이트 개발의 경우 UI 기능의 완성도 수준이 낮아 아직 성능 Script를 작성하기 어려운 상황인 경우가 많습니다.
하지만, UI 기반 접근이 가능한 상태가 아니더라도, API 단위로는 기능 개발이 완료되어 있는 경우가 많기 때문에, API 호출을 중심으로 한 단위 기능 대상 성능 테스트 수행은 가능한 상태일 수 있습니다.
한편, ‘단위 성능’이란 표현이 “수많은 단위 기능들에 대해 모두 성능 테스트를 수행해야 하는가?”라는 의문을 불러 일으킬 수 있지만, ‘주요(또는 핵심) 기능’에 대한 단위 성능을 점검한다는 기준을 가지고 접근한다면, 제한된 시간과 자원 내에서 수용 가능한 수준의 대상 기능들을 선별하는데는 크게 어려움이 없을 것으로 보입니다.
참고로, 2021년 4월 현재 성능테스트를 지원하고 있는 S사의 CRM 시스템에 대해서도, 실제로 포인트 관련 주요 API들(ex. 포인트적립요청, 사용가능포인트조회, 쿠폰번호인증, 회원 신규가입 등)에 대해 단위 성능 테스트 대상으로 선정한 바 있으며, 실제적인 수행을 위해 현재 해당 API들을 대상으로 Script 작업을 진행중에 있습니다.
3. API 대상 Script는 어렵지 않나요?
기존에 화면이 있는 시스템들만을 대상으로 Recording 하는 것이 익숙했기 때문에, 화면이 없는 API를 대상으로 Script를 작성해야 한다고 하면, 단위 성능테스트를 수행하는 것이 어렵지 않을까 생각할 수도 있습니다.
하지만, Script를 작성하는 방법만 다를 뿐, 이후 성능 테스트를 수행하는 방법은 기존과 동일하기 때문에, 결국 API를 대상으로 Script 작업이 가능해진다면, API 대상 단위 성능 테스트 또한 수행 가능하다고 생각하시면 됩니다.
한편, 기존에는 개발자에게 JSON 전문을 받아 Script를 한줄 한줄 직접 작성하거나, 아니면 개발자의 도움을 받아 Script를 작성한 후 Replay해보고, 그 결과값이 사전 정의된 값과 동일한지 확인하는 (다소 번거로운) 작업을 거쳤던 것이 사실입니다.
하지만, LoadRunner의 Design 기능들도 계속해서 업그레이드 되다보니, Script 대상 UI 화면이 없다는게 전혀 불편하지 않을 정도로, 상당히 쉽게 Script를 작성할 수 있도록 지원기능이 잘 구성되어 있다는 것을 이번에 확인할 수 있었습니다.
이번 글에서는 LoadRunner에서 제공하고 있는 ‘Rest API’ Script 작성 기능에 대해 소개하고자 합니다.
4. REST API 대상 Script 만들기
1) 대상 API 선정 및 JSON 전문 받기
Project에서 단위 성능 테스트를 수행할 API들이 선정되면, 해당 API별로 아래와 같은 JSON 전문을 개발자를 통해 받습니다.
[예시]
URL: https://test-crm-api.abc.com/api/v1/ABCD_EFG123
Method Type: POST
Encoding Type: application/json
Request Body:
{
"header":{
"abcRspDef":"",
"stdTime":"20200320180000",
"uuid":"BBBB-BBBB"
중략
},
"data":{
"mbshNo":"1234567890" /*회원번호*/
, "date":"20200320" /*당일날짜*/
중략
}
}
개발자는 POSTMAN 등을 통해 해당 JSON 전문에 대한 단위 기능 테스트를 완료한 상태이기 때문에, 우리는 API의 기능이 정상적으로 작동한다는 전제 하에 성능 Script를 준비합니다.(간혹, 개발자가 전문에 주석을 덧붙이는 과정에서 기호 등이 삭제되는 경우가 있으므로, 주의깊게 살펴보고 해당 전문에서 주석부분은 삭제합니다.)
2) LoadRunner - Create a New Script
제공받은 JASON 전문을 LoadRunner Script로 전환하기 위해서는 우선, 기존과 동일하게 ‘Web-HTTP/HTML’ Protocol을 선택합니다.
3) Scrip 작성 준비
이번 작업은 Recording 작업이 아니기 때문에, JASON 전문이 Script로 전환 될 때 정확한 위치에 들어갈 수 있도록, 마우스 커서를 Action의 { } 사이에 들어가도록 클릭한 후 작업을 시작합니다.
4) REST API 선택
상단의 메뉴들 중 ‘Design’을 클릭해 보면, ‘Insert in Script’ 항목에 ‘REST API’가 있음을 확인할 수 있습니다. 해당 메뉴를 클릭합니다.
5) Rest Step Properties
이제 우리를 도와줄 ‘Rest Step Properties’란 팝업창이 뜹니다. 구성 내용을 살펴보면, 맨 위에 우리가 제공받은 URL을 입력하는 란이 있고, 그 옆에는 GET, POST, PUT등과 같은 Method를 선택하는 란이 있습니다. 우리가 받은 Method Type은 POST이므로, 해당 메뉴를 선택합니다.
6) Content Type 선택
POST를 선택하면 하단에 Body값에 대한 Content Type을 선택하는 메뉴가 나타나는데, 우리가 제공받은 대로 ‘application/json’을 선택합니다.
7) Build Step
URL 부분과 아래 Body 부분에 각각 제공받은 주소와 JSON 전문을 복사하여 붙여넣기를 합니다.
‘이렇게만 하면 되나?’ 하는 고민과 함께, 우측 하단의 ‘Insert Step’ 버튼을 눌러 LoadRunner Script로 삽입해야 하는지 궁금해질 무렵, 문득 왼쪽에도 버튼이 하나 있는 것을 발견할 수 있습니다. Script로 전환하기 전에 ‘Run Step’을 눌러봅니다.
8) Step Results
‘무슨 기능일까?’ 궁금했는데, (눌러보니) LoadRunner Script로 전환되어 반영되기 전, 팝업 화면 상태에서 해당 전문이 정상 작동되어 예상 결과값을 제공하는지 최종 점검해 보는 기능이었습니다. 이런 점은 상용 도구의 가장 매력적인 부분인 것 같습니다. 무심코 놓치기 쉬운 부분을 직관적으로 절차화시켜 줌으로써, 불필요한 재작업이 발생하지 않도록 기능적으로 최대한 지원해 주고 있습니다.
개발자에게서 제공받은 전문을 Loadrunner에 입력한 후 그 결과를 확인해 보면, 아래 화면과 같이 “정상 처리되었습니다”라는 예상 결과를 쉽게 확인해 볼 수 있습니다.
참고로, 오류가 발생하는 경우에는 400 Error 등의 응답값을 그대로 보여 주기 때문에, 개발자와 함께 JSON 전문의 어떤 부분이 문제인지 함께 확인해 보시면 됩니다.
이제 안심하고 우측 하단의 ‘Insert Step’버튼을 클릭합니다.
9) Script 완성
화면이 없는 API에 대해서도 (생각보다 쉽게) 아래와 같이 LoadRunner Script가 완성되는 것을 확인할 수 있습니다.
이제는 작성된 Script가 정상 작동하는지 Replay를 통해 응답값을 확인해 봐야하는데, 해당 버튼을 누르기 전에 설정할 작업이 하나 있습니다.
10) Runtime Settings
Replay 버튼을 그냥 누르게 되면, 응답값이 상세하게 나오지 않기 때문에 해당 전문이 받는 응답 데이터를 모두 표시하기 위해서는 Log 부분에 대한 설정을 변경해 준 후 Replay를 실행해야 합니다.
‘Standard Log’로 기본 설정되어 있는 값을, ‘Extended Log’로 변경해 준 후 하단의 두개 메뉴를 그림과 같이 체크해 줍니다.
11) Output 확인
‘Replay’ 버튼을 클릭하여 하단의 Output 값을 확인해 보면, 수행된 Script가 정상적으로 작동하였는지 여부를 확인하실 수 있습니다. 다만, 아쉬운 점은 이전 팝업 화면에서의 ‘Step Results’에서는 한글 메시지가 깨지지 않고 표현되었는데, 여기서는 한글 메시지가 깨져서 나온다는 점입니다.
하지만, 간단한 LoadRunner Script 기능을 이용해서, 해당 메시지를 확인해 볼 수 있는 쉬운 방법이 있습니다.
12) lr_convert_string_encoding 활용
Output 화면에서 깨진 메시지 부분을 복사하고, 아래와 같은 LoadRunner Script를 별도로 하나 만든 후 해당란에 붙여 넣어 Replay 해보면, 하단의 output에서 깨진 글씨가 “정상 처리되었습니다”라는 정상적인 한글로 변환되어 보여주고 있는 것을 알 수 있습니다.
깨진 한글 메시지 확인시 유용한 기능이므로, 해당 Script는 별도로 하나 만들어서 필요시마다 재사용하시면 도움이 되실 겁니다.(유용한 해당 Tip은 현재 Project에서 함께 성능 테스트 지원을 담당하고 계신 이비웨어 김종철 이사님께서 공유해 주셨습니다.^^)
5. 마무리
이제 API에 대한 Script 준비가 완료되었으므로, 단위 기능별로 성능 테스트를 수행하실 수 있습니다.
LoadRunner의 REST API Script 관련 Micro Focus의 공식적인 도움말은 ‘Create a script for a REST API’을 참조하시기 바랍니다.
참고로, LoadRunner Tool의 기본 사용법은 Google에서 검색해보면 이미 상세하고 친절한 연재글들이 많이 있어서, (유사한 글을) 추가로 작성할 필요성은 없어 보입니다. 다만, 실제 성능 테스트 수행을 해 나가면서 (상황별로) 부연 설명이 필요하겠다 싶은 기법관련 부분들은, 이번 글과 같이 하나의 주제로 분리하여 작성해 보도록 하겠습니다.
읽어 주셔서 감사합니다.^^
[끝]