Web service performance_test_using_jmeter_ver1.2

Project Name : Mobile Service
© Sunny Kwak １
Performance Test using jMeter

© Sunny Kwak ２
Revision History
Version Description Author Date
1.0.0 초안작성 곽중선 2014-05-01
1.1.0 ‘온라인 서비스 OpenAPI 테스트 계획’ 추가 곽중선 2014-05-03
1.1.1 부하 테스트 계획 추가 곽중선 2014-05-06
1.2.0 ‘기능 및 부하 테스트 수행’ 추가 곽중선 2014-05-12

© Sunny Kwak ３
Table of Contents
1. jMeter 설치 ................................................................................................................... ６
1.1. jMeter 개요 및 활용 방안.............................................................................................. ６
기능 점검 ...................................................................................................................... ６
수용량 측정.................................................................................................................... ６
부하 테스트.................................................................................................................... ６
1.2. jMeter 설치 .............................................................................................................. ６
jMeter 설치 및 실행.......................................................................................................... ７
1.3. jMeter 플러그인 설치 .................................................................................................. ７
2. jMeter TestPlan 작성 절차 ................................................................................................. ８
2.1. jMeter UI ................................................................................................................. ８
2.2. TestPlan 구성 요소 및 용어 ........................................................................................... ９
Thread Groups (Users).....................................................................................................１０
Sampler (Unit Test) ........................................................................................................１０
Config Element .............................................................................................................１０
Listener (Report) ...........................................................................................................１０
2.3. TestPlan 작성 절차 ...................................................................................................１０
TestPlan 기본정보 입력 ...................................................................................................１０
Config Element 추가 .......................................................................................................１１
HTTP Request Defaults ............................................................................................. １１
HTTP Header Manager .............................................................................................. １１
HTTP Cookie Manager............................................................................................... １２
Thread Group 추가 .........................................................................................................１３
Listener 추가 ................................................................................................................１３
View Results Tree.................................................................................................... １３
Summary Report ..................................................................................................... １４
View Results in Table ............................................................................................... １５
Sampler 추가 ................................................................................................................１５
3. 온라인 서비스 OpenAPI 테스트 계획 ...................................................................................１７
테스트 목적 ....................................................................................................................１７
테스트 개요 ....................................................................................................................１７
기능 테스트 계획 (Functional Test Plan)..................................................................................１７
기능 테스트 구성 ...........................................................................................................１７
User Defined Variables ....................................................................................................１７
Thread Group ...............................................................................................................１９
Config Element .............................................................................................................１９
HTTP Request Sampler ....................................................................................................２１
사용자 등록 ........................................................................................................... ２１
사용자 읶증 ........................................................................................................... ２２
JSON Assertion..............................................................................................................２３
JSON Path Assertion................................................................................................. ２４
JSON Path Extractor................................................................................................. ２４
BeanShell Assertion.................................................................................................. ２５
Listener (View Results Tree) .............................................................................................２６
부하 테스트 계획 (Load Test Plan) .........................................................................................２６
테스트 시나리오 ............................................................................................................２７
부하 테스트 구성 ...........................................................................................................２７
CSV Data 생성...............................................................................................................２７
CSV Data Set Config........................................................................................................２７

© Sunny Kwak ４
Thread Group ...............................................................................................................２８
Timer (Constant & Uniform Random)...................................................................................２９
Listener (Report) ...........................................................................................................３１
Aggregate Graph (or Aggregate Report) ......................................................................... ３１
Response Time over Time .......................................................................................... ３２
Transactions per Seconds .......................................................................................... ３２
4. 기능 및 부하 테스트 수행.................................................................................................３４
준비 사항 .......................................................................................................................３４
기능 테스트 수행 절차........................................................................................................３４
jMeter 실행..................................................................................................................３４
Test Plan 실행 (기능) ......................................................................................................３５
실행 결과 검토 ..............................................................................................................３５
부하 테스트 수행 절차........................................................................................................３５
CSV generator 실행 ........................................................................................................３６
Test Plan 실행 ..............................................................................................................３６
jMeter GUI 모드 실행 ......................................................................................................３８
성능 리포트 작성 ...........................................................................................................３９
5. CSV 데이터 생성............................................................................................................４０
CSV Generator 개요...........................................................................................................４０
CSV Generator 어플리케이션 구조 .........................................................................................４０
Fatjar 플러그인 설치 .........................................................................................................４０
Jar 생성 및 CSV Generator 실행 ............................................................................................４２

© Sunny Kwak ５
Document Overview
 Purpose
본문서는 jMeter 기반의 웹 서비스 성능 평가 절차를 정리한 것이다.
 Scope
웹 기반 온라인 서비스의 성능을 평가하기 위해 jMeter 를 이용해 stress test 를 실시한다.
 Assumptions and Dependencies
 How to Use
 Read the document thoroughly and understand the standards before beginning

© Sunny Kwak ６
1. jMeter 설치
jMeter 어플리케이션과 추가 플러그읶(plugin)을 설치하는 젃차를 요약하였다.
1.1. jMeter 개요 및 활용 방안
jMeter 는 부하 테스트(load test) 및 성능 평가 (measure performance)를 위해 설계된 자바 기반의 오픈소스
데스크톱 어플리케이션이다. jMeter 를 이용해 정적/동적 웹 컨텐츠, FTP, mail, 데이터베이스, NoSQL 등의 성능
분석을 수행할 수 있다. 온라인 서비스 과제에서는 Open API 서버 (게임 서비스 온라인 컨텐츠 서버)에 대한 기능
점검 (단위 테스트), 수용량 측정 및 부하 테스트에 적용한다.
기능 점검
온라인 서비스 Open API 의 사용자 정보, 게임 정보, 채널 정보 및 컨텐츠 정보 서비스에 포함된 각각의 API 에
대한 정상 동작 유무를 테스트하는 테스트 케이스를 작성한다. 기능 테스트의 목적은 ‘지속적인 품질 확보’이다.
 Open API 기능 추가 및 개선, 버그 수정에 따른 변경 시, 자동화된 테스트 실시
 Development, Stage, Product 환경으로 이행(transfer) 시 정상 배포 여부 판정
수용량 측정
사용자의 서비스 사용 시나리오를 예측하여 시나리오 기반의 테스트 케이스(혹은 계획)을 작성하고, 이를 이용해
서비스 환경을 시뮬레이션(simulation) 한다. 다수의 가상 사용자(virtual user)가 접속하여, 소규모 서버에서 수용
가능한 동시 사용자 수(혹은 적정 사용자 수)를 산출한다. 수용량 측정의 목적은 ‘시스템 확장 및 운영 계획’ 수립을
위한 기초 자료 확보이다.
 온라인 서비스 사용자의 서비스 사용 시나리오 예측
 예상 시나리오 기반의 테스트 계획 작성
 개발 및 stage 서버 대상의 동시 접속 및 서비스 운영 테스트 실시
 테스트 결과를 이용해 수용 가능량, 자원 소모량 (CPU, 메모리, 디스크)을 측정한다.
 시뮬레이션 결과를 바탕으로 향후 서버 확장 및 스케일 자동화 (auto-scale) 계획을 수립한다.
부하 테스트
부하 테스트의 목적은 하드웨어, 소프트웨어, 네트워크 등 서버 아키텍처 전반에 걸친 안정성 점검, 취약점 분석 및
스케일 자동화의 모의 테스트 수행이다. jMeter 를 다수의 에이전트 서버에 설치한 후, 동시에 수백/수천에 이르는
사용자 접속을 시도하여, 시스템 응답 성능과 서버 자원의 상태를 모니터링 한다. 부하 테스트의 수행 방식은
수용량 측정과 동일하나, 의도적으로 과부하 상태를 유도하고 그에 따른 서버 상태를 확인한다는 점이 다르다.
또한 부하 테스트 시에는 응답 속도 등 성능 측정 보다는 취약점(개선점)을 찾는데 주력한다.
1.2. jMeter 설치
jMeter 는 오픈 소스이며, 아파치 홈페이지에서 다운로드 받을 수 있다. 온라인 서비스 Open API 가 RESTful
방식이고 응답 데이터 형식이 JSON 이므로, JSON 데이터 해석(parsing)을 위한 추가 플러그인을 설치해야 한다.

© Sunny Kwak ７
jMeter 설치 및 실행
jMeter 는 GUI 및 CLI 를 모두 제공하며, jMeter 테스트 계획(test plan)을 작성하거나, 수동으로 테스트를 수행하기
위해서 개발 PC 에 jMeter 를 설치해야 한다. 자동화된 테스트를 수행하거나, 부하 테스트를 실시할 경우에는 서버
상에서 jMeter 를 설치한다.
jMeter 를 개발 PC 에 설치하기 이전에 JDK 1.6 이상의 버전을 PC 에 설치해야 한다.
 http://jmeter.apache.org/download_jmeter.cgi 에서 jMeter 압축 파일을 다운로드 받는다.
 적절한 폴더 위치에 압축 파일을 해제한다.
 ${JMETER_HOME}/bin/jMeter.bat 파일을 실행하면 jMeter GUI 가 실행된다.
1.3. jMeter 플러그인 설치
Open API 의 응답 데이터를 파싱(parsing)하고, 서비스의 정상 수행 여부를 판단하기 위해 JSON Path Assertion
플러그인을 설치해야 한다. jMeter 플러그인을 사용하기 위해서는 jMeter version 2.8 이상을 설치해야 한다.
 http://jmeter-plugins.org/#/ 사이트에 접속한다.
 ‘Extras with Libs Set’ 을 다운로드 한다.
 압축 파일을 해제하면, lib 폴더 안에 jar 파일들이 포함되어 있으며 jar 파일들을 jMeter 홈 디렉토리
아래에 위치한 lib 폴더에 넣는다.
Report /
Graph
DBMS
Amazon Cloud
Web / WAS
Remote Client
jMeter #1
jMeter #2
jMeter #n
Run Stress Tess
HTTP Requests
HTTP Responses

© Sunny Kwak ８
2. jMeter TestPlan 작성 절차
jMeter 내에서 테스트 케이스(test case)를 작성하는 젃차와 jMeter 기능들에 대한 갂략한 설명, 테스트 케이스 작성
젃차를 이해하는데 필요한 jMeter 용어를 정리하였다.
2.1. jMeter UI
jMeter 기본 UI 내에서 기본적으로 알아야 할 항목들을 요약하였다.
① Start TestPlan
TestPlan 을 실행한다. TestPlan 내에 포함된 모든 테스트 케이스를 실행하며, 수행 결과를 기록한다. 테스트
케이스를 작성 완료한 후 시험하거나, 이젂에 작성된 TestPlan 을 로드(load)한 후 재실행할 때 사용한다.
② Clear output
TestPlan 수행 결과를 지운다. 테스트를 반복 수행하거나 TestPlan 이 변경되었을 때, 이젂 테스트 결과를
지우기 위해 사용한다.
① Start TestPlan ② Clear output ③ Error/Warning count

© Sunny Kwak ９
③ Error / Warning count
직젂 TestPlan 수행 결과에서 오류가 발생한 테스트 케이스 개수를 표시한다. 아이콘을 클릭하면 logViewer
패널이 표시된다.
jMeter UI 좌측 패널에는 ‘TestPlan’과 ‘WorkBench’가 표시된다.
① TestPlan
jMeter 테스트 케이스(혹은 시나리오)에 대한 젂반적읶 설정을 포함하는 영역이다.
② WorkBench
워크벤치는 계속 사용하지 않는 임시 테스트 케이스를 작성하고 실험하기 위한 영역이다.
TestPlan 에 테스트 케이스들을 입력한 예시는 아래와 같다.
2.2. TestPlan 구성 요소 및 용어
테스트를 수행하기 위한 젂반적읶 설정 및 개별 테스트 케이스는 TestPlan 에 설정 혹은 추가한다.
테스트 케이스를 작성하기 위해 추가해야 하는 필수(기본) 구성 요소들은 ‘Thead Groups (Users)’, ‘Config Elements’,
‘Sampler’ 및 ‘Listener’ 이다. 나머지 구성 요소들을 좀 더 정교한 테스트를 수행하기 위해 설정한다.

© Sunny Kwak １０
Thread Groups (Users)
Thead Groups 를 달리 표현하자면, 가상 사용자(virtual user)이다. 실제 사용자가 서비스(혹은 서버)를 호출하는
행위를 스레드가 모의 수행하는 것이다. 테스트를 실행하는 횟수, 주기, 동시에 실행되는 스레드 개수 등을 설정할
수 있다. TestPlan 작성 시 먼저 스레드를 생성하고, 스레드 아래에 sampler 들을 추가하게 된다.
Sampler (Unit Test)
사용자가 서비스를 실행하는 행위를 소프트웨어적으로 모방하는 것이며, 개별 테스트 케이스 혹은
액션(action)이라고 정의할 수 있다. HTTP 요청, TCP 통신, JDBC 쿼리 등 다양한 방식으로 서비스를 실행할 수
있는 sampler 들이 제공된다.
Config Element
테스트를 수행하기 위한 각종 환경 변수, 기본 값 등을 지정할 수 있다. 설정할 수 있는 항목들은 서버 주소 및 포트,
쿠키 값, HTTP 헤더 기본 값 등이 있다.
Listener (Report)
테스트 수행 결과를 기록하고, 리포트를 생성하는 역할을 담당한다. 그래프, 테이블, 요약 등 다양한
리스너(listener)가 제공된다.
2.3. TestPlan 작성 절차
TestPlan 을 작성하는 젃차를 요약하였다. 필수 요소들만으로 구성한 젃차이므로, 추가적읶 요소들을 반영해야 정밀한
테스트를 수행할 수 있다.
TestPlan 기본정보 입력
좌측 패널에서 TestPlan 을 선택한 후, 명칭 및 간단한 설명을 입력한다. 사용자 정의 변수들을 추가할 수 있다.

© Sunny Kwak １１
Config Element 추가
테스트를 수행하기 위한 ‘공통 설정(Common configurations)’을 추가한다. 온라인 서비스 테스트에서는 ‘HTTP
Request Defaults’, ‘HTTP Header Manager’, ‘HTTP Cookie Manager’ 등 3 가지를 설정한다.
HTTP Request Defaults
서버 주소 및 포트 번호, 요청 및 응답 시간 제한 값 등의 항목에 대한 기본 값(default value)를 설정할 수 있다.
HTTP Request Defaults 에서 설정한 값을 개별 sampler 에서 덮어 쓸(override) 수 있다.
HTTP Header Manager
HTTP 통신 헤더에 추가해야 하는 항목을 설정한다. 온라인 서비스 Open API 를 요청하기 위해 ‘Content-Type’을
‘application/x-www-form-urlencoded’ 값으로 설정한다.

© Sunny Kwak １２
HTTP Cookie Manager
세션(session)을 필요로 하는 테스트 케이스들을 위해 쿠키(cookie)를 설정한다.

© Sunny Kwak １３
Thread Group 추가
테스트 반복 횟수, 동시 접속 수 등을 설정하기 위해 Thread Groups 를 추가한다.
Listener 추가
테스트 수행 결과를 집계하고 리포트를 생성하기 위해 Listener 를 추가한다.
View Results Tree
테스트 수행 결과를 트리(tree) 형태로 상세하게 검토할 수 있다. 테스트 유형에 상관없이 기본적으로 추가하는
것을 권장한다. 단점은 대규모 테스트를 수행했을 때, 로그가 너무 많아 개별 항목을 찾아보기 불편할 수 있다.

© Sunny Kwak １４
Summary Report
테스트 수행 결과를 집계하고 요약된 결과를 출력한다. 부하 테스트 및 성능 측정 시에 유용하다.

© Sunny Kwak １５
View Results in Table
테스트 수행 시 발생한 개별 요청 수행 결과를 테이블 형태로 출력한다. 테스트 결과를 엑셀 등으로 내보낸 후 통계
등 후반 작업을 수행하고 싶을 때 적합하다.
Sampler 추가
마지막으로 테스트 케이스들을 추가한다. 개별 sampler 혹은 테스트 케이스는 호출하는 API 경로(path), 요청
인자(request parameters), 메소드(POST, GET, PUT 등) 등을 입력한다. POST 및 GET 메소드인 경우에는 요청
인자를 ‘Parameters’ 탭에 입력하고, PUT 메소드인 경우에는 Body Data 에 입력해야 한다.
POST 메소드인 경우, 아래와 같이 입력하면 된다.

© Sunny Kwak １６
PUT 메소드인 경우에는 아래와 같이 입력한다.

© Sunny Kwak １７
3. 온라인 서비스 OpenAPI 테스트 계획
테스트 목적
Open API 테스트의 목적은 다음과 같다.
 개발 짂행 중 Open API 기능의 점검 및 오동작 유무 파악
 유지보수 단계에서 기능 추가/변경 발생 시 젂체 API 에 대한 기능 점검 자동화
 부하 테스트(load test)를 통한 온라읶 서비스 성능 측정 및 자원(resource) 계획 수립
테스트 개요
 테스트 수행 도구는 오픈 소스 성능 테스트 도구읶 jMeter 를 사용한다.
 ‘기능’ 및 ‘부하’ 테스트 계획을 구분하여 별개의 스크립트로 작성한다.
 기능 테스트는 ‘Open API specification’을 참조하여 모든 온라읶 서비스 API 기능을 점검한다.
 기능 테스트 계획에는 개별 요청에 대한 요청/응답 데이터 및 정상 유무를 판단하는 Assertion 을 포함한다.
 부하 테스트는 사용자의 컨텎츠 홗용 시나리오를 예측하여, 시나리오 기반의 테스트를 수행한다.
 부하 테스트는 성능을 분석하기 위해 TPS (Transaction per Second), 응답 시갂 통계 등을 생성한다.
 부하 테스트는 하나의 마스터(master)와 복수의 (slave)로 구성된 분산 테스트(Distributed Test)를 실시한다.
기능 테스트 계획 (Functional Test Plan)
기능 테스트 계획은 온라읶 서비스 Open API (혹은 온라읶 서비스)의 정상 동작 유무를 자동화된 스크립트로 검증하기
위해 작성한다.
기능 테스트 구성
기능 테스트 계획의 구성 요소는 User Defined Variables, Thread Group, Config Element, Sampler, Assertion,
Listener 등이다. Thread Group 혹은 가상 사용자(virtual user)는 1 회 실행하는 것으로 설정한다. Config
Element 는 서버 주소, HTTP 헤더 및 쿠키 설정을 포함한다. Sampler 는 Open API 개수만큼 생성하며, 각각의 API
정상 동작 유무를 판단하기 위해 Assertion 을 추가한다. Listener 는 모든 요청/응답 데이터를 점검해야 하므로,
‘View Results in Table’을 추가한다.
User Defined Variables
Test Plan 의 속성 화면에서 사용자 정의 변수를 선언한다. 사용자 정의 변수는 Sampler, Thread Group, Listener,
Timer 등 Test Plan 하위에 등록된 각종 요소(element)에서 참조할 수 있다. 사용자 정의 변수의 장점은 반복적으로
같은 값을 입력하는 수고를 줄여주고, 시스템 환경이 변경되거나, 테스트 대상 시스템이 변경될 때 손쉽게 대응할
수 있다는 점이다. 사용자 정의 변수에는 서버 주소, 게임 순번, 채널 순번, 컨텐츠 ID 등의 항목을 선언한다.

© Sunny Kwak １８
Name Value Description
server_addr pelb-dan1swb-657109358.ap-northeast-
1.elb.amazonaws.com
URL 생성을 위한 서버 주소이며, 테스트 대상 서버 IP
주소 혹은 도메인 명칭
context_root /gcapi URL 생성을 위한 API 최상위 경로이며, Open API root
path or context root
game_seq GMGW1404081503010001GMGW14040815
03010001
컨텐츠 조회 및 등록 테스트를 위한 게임 정보. 테스트
대상 DB 에 등록되어 있는 임의의 게임 순번 (40 bytes)
ch_seq NIGW1404201230500000NIGW1404201230
500000
채널 및 컨텐츠 조회 및 등록 테스트를 위한 채널 정보.
테스트 대상 DB 에 등록되어 있는 임의의 채널 순번 (40
bytes)
cid CDA01404250715330000CDA01404250715
330000
컨텐츠 및 덧글 조회를 위한 컨텐츠 정보. 테스트 대상 DB
에 등록되어 있는 임의의 컨턴츠 ID (40 bytes)
auth_key 12345678901234567890123456${__time(yy
yyMMddHHmmss)}
모바일 장치 인증(mobile device authentication key).
사용자 신규 등록을 위한 인증 키. 반복적으로 사용자
등록 시 ‘기존 사용자 오류(already exist error)’가
발생하는 것을 방지하기 위해 테스트 실행 시각을 이용해
매번 인증 키를 신규 발행한다.
nick_name test_user_${__time(yyyyMMddHHmmss)} 사용자 신규 등록에 필요한 닉네임(nickname).
반복적으로 사용자 등록 시, ‘닉네임 중복’ 오류가
발생하는 것을 방지하기 위해 테스트 실행 시각을 이용해
매번 닉네임을 신규 발행한다.
device_id 15bf269cbffecf55b904648bb1304a376cd308
01
컨텐츠 등록 및 조회를 위한 디바이스 ID
사용자 정의 변수 중에서 game_seq, ch_seq, cid 등은 대상 서버를 바꾸거나 데이터의 변경이 발생할 경우,
데이터베이스 내에서 테스트 입력 데이터를 샘플링(sampling)한 후 jMeter 사용자 정의 변수 값을 재설정해야 한다.

© Sunny Kwak １９
‘auth_key’ 및 ‘nick_name’ 변수는 테스트 수행 시마다 다른 값이 입력되어야 하기 때문에 jMeter ‘__time’ 함수를
이용해 테스트 실행 시각을 바탕으로 매번 다른 값이 생성되도록 한다.
Thread Group
Number of Threads (users) 는 1, Ramp-up Period 및 Loop Count 는 1 로 설정한다. 기능 테스트는 모든 요청들이
정상 동작하거나 실패하는지 여부만을 확인하면 되기 때문에 반복 테스트를 수행할 필요가 없다.
Config Element
‘HTTP Request Defaults’, ‘HTTP Header Manager’, ‘HTTP Cookie Manager’ 등 3 가지 Config Element 를
설정한다.
Type Description
HTTP Request Defaults HTTP 요청(request) 시 필요한 기본 값들을 설정한다. 일반적으로 서버 주소, 포트 번호,
타임아웃(timeout) 등을 설정할 수 있다.
HTTP Header Manager HTTP 요청(request) 시, HTTP header 에 설정할 기본 항목들을 추가한다. 컨텐츠 타입,
에이전트 정보, 인코딩 타입(encoding type) 등을 설정한다.
HTTP Cookie Manager HTTP 요청 /응답에서 발생하는 쿠키(cookie)를 관리한다. 테스트 수행 중 서버에서 전송받은
쿠키를 보관하고, 이후 요청 수행 시 보관된 쿠키를 요청 패킷(packat)에 자동으로 설정해주는
기능을 제공한다. 필요하면, 쿠키 변수와 값을 기본 설정할 수 있다.

© Sunny Kwak ２０
HTTP Request Defaults 에는 ‘서버 주소’ (Server Name or IP)를 설정한다.
HTTP Header Manager 에는 ‘Content-Type’ 변수를 설정한다. ‘Content-Type’ 변수는 RESTful API 의 입력 데이터
형식을 정확히 지정해 서버에서 요청 인자 파싱(request parameter parsing) 오류가 발생하는 것을 방지하기 위한
것이다.

© Sunny Kwak ２１
HTTP Cookie Manager 에는 ‘Clear cookies each iteration?’ 을 체크한다. 반복(iteration) 테스트를 수행할 때마다
쿠키를 초기화하는 것이다.
HTTP Request Sampler
Open API 개수만큼 Sampler 를 추가한다. 필수 항목은 ‘Name’, ‘Method’, ‘Path’ 이며, 요청 입력 값이 존재할 경우,
‘Parameters’를 추가한다. 단, ‘Method’ 유형이 ‘PUT’ 인 경우에는 ‘Body data’에 요청 인자 값을 입력해야 한다.
Sampler 등록을 위한 API 정보는 ‘Open API 연동 규격서’를 참조한다.
기능 테스트를 위한 Sampler 들은 ‘사용자 등록’, ‘사용자 인증’ 및 기타 기능 테스트 순으로 등록해야 한다. ‘사용자
등록’은 임의의 인증 정보를 생성해 신규 사용자로 가입하는 것이며, ‘사용자 인증’은 신규 생성한 사용자로
정상적으로 로그인(login) 되는지 확인하는 것이다. 나머지 테스트를 인증 이후에 등록하는 이유는 대부분의
기능들이 로그인 상태가 아니면 정상 응답하지 않기 때문이다.
사용자 등록
사용자 등록 sampler 에서는 4 개의 필수 인자(parameter)를 등록한다. 만일, API spec 이 변경되어 필수 인자가
추가/삭제될 경우, 인자를 추가하거나 삭제해야 한다.
auth_key ${auth_key} 사용자 정의 변수를 참조한다. 중복을 방지하기 위해
테스트 수행 시 마다, 매번 새롭게 생성한 값을 사용한다.
auth_code IMEI 인증 방식은 고정된 값을 사용한다.
device_id 15bf269cbffecf55b904648bb1304a376cd30801 디바이스 ID 는 고정된 값을 사용한다.
nick_name ${nick_name} 사용자 정의 변수를 참조한다. 중복 방지를 위해 매번
새롭게 생성한 값을 사용한다.

© Sunny Kwak ２２
사용자 인증
사용자 인증 sampler 에서는 ‘auth_key’ ‘auth_code’, ‘device_id’ 등 3 개의 인자를 설정한다.
auth_key ${auth_key} 사용자 정의 변수를 참조한다. 중복을 방지하기 위해
테스트 수행 시 마다, 매번 새롭게 생성한 값을
사용한다.
auth_code IMEI 인증 방식은 고정된 값을 사용한다.
device_id 15bf269cbffecf55b904648bb1304a376cd30801 디바이스 ID 는 고정된 값을 사용한다.

© Sunny Kwak ２３
사용자 인증 후에, JSON Path Extractor 를 이용해 응답 JSON 데이터 내에서 ‘user_key’ 필드 값을 추출한다.
추출된 값은 ‘user_key’ 변수에 할당하고 이후 ‘사용자 정보 조회’ 등의 테스트 케이스에서 입력 값으로 사용한다.
JSON Assertion
Assertion 은 JSON 형식의 응답 데이터(response data)를 파싱(parsing) 한 후, 응답 코드를 체크하여 정상 유무를
판단한다. 정상 응답 코드가 단일 값일 경우에는 ‘JSON Path Assertion’을 이용하고, 정상 응답 코드가 두 가지

© Sunny Kwak ２４
이상인 경우에는 ‘JSON Path extractor’를 이용해 응답 코드를 변수에 담고 ‘BeanShell Assertion’로 에러를
검출한다.
JSON Path Assertion
정상 상태인 응답 코드가 단일 값일 경우에는 ‘JSON Path Assertion’을 이용해 기능 테스트 결과를 판단할 수
있으며, JSON 응답 데이터에서 값을 추출하는 작업과 추출 값을 예상 값(expected value)과 비교하는 작업을
한번에 처리할 수 있다. 아래 예시는 응답 코드가 ‘000’ 인 경우 정상으로 판단한다.
JSON Path Extractor
정상적인 처리에 대해 응답 코드가 하나 이상 반환될 경우, 먼저 ‘JSON Path extractor’를 이용해 JSON 응답
데이터에 포함되어 있는 값을 jMeter 변수에 할당한다. 아래 예시는 JSON 데이터의 ‘result_code’ 필드 값을 추출한
후, jMeter ‘result_code’ 변수에 할당한다.

© Sunny Kwak ２５
BeanShell Assertion
‘JSON Path Extractor’에 의해 추출된 변수를 ‘BeanShell Assertion’을 이용해 검사한다. 아래 예시는 ‘result_code’
변수의 값이 ‘000’ 이거나, ‘000’ 인 경우 정상으로 판정하고, 아닌 경우 오류 메시지를 출력한다.

© Sunny Kwak ２６
Listener (View Results Tree)
기능 테스트를 위한 Listener 는 개별 요청 건의 정상 유무와 요청/응답 데이터를 점검할 수 있어야 하며, 수행
성능을 파악할 수 있는 것들은 제외한다. 필수적으로 포함해야 하는 Listener 는 ‘View Results Tree’ 이다.
부하 테스트 계획 (Load Test Plan)
테스트 시나리오를 정의하고, 각각의 시나리오를 위한 테스트 계획(jMeter TestPlan script)를 작성한 후, BMT 서버
상에서 부하 테스트를 실시한다. 매 번 부하 테스트를 수행한 후, 테스트 수행 홖경, 수행 읶자(execution parameter),
결과를 포함한 보고서 등을 작성한다. 부하 테스트는 읷회성에 그쳐서는 앆되며, 기능 확장 및 변경, 서버 확장에 따라
지속적으로 보고서를 작성해야 한다. 이를 통해 변화에 대한 지속적읶 평가, 장기 예측을 위한 기초 자료 수집 및 부하
관리 노하우 축적이 가능해짂다.
부하 테스트와 기능 테스트의 차이점은 다음과 같다.
 기능 테스트는 가상 사용자(virtual user) 수를 한 명으로 설정하고, 반복 횟수 또한 1 회로 제한한다. 반면에
부하 테스트는 복수의 사용자가 반복적으로 테스트를 수행한다.
 기능 테스트에서는 Assertion 을 이용해 응답 데이터의 정상 유무를 검사하지만, 부하 테스트에서는 가급적
Assertion 을 포함시키기 않는다. (Assertion 을 많이 사용할수록, Assertion 수행으로 읶한 지연 및 자원 소모
등으로 읶해 부하 테스트의 측정 결과가 부정확해짂다.)
 기능 테스트에서는 수행 결과의 면밀한 분석을 위해 ‘Results in Tree’ 등 상세한 로그를 조회할 수 있는
Listener 를 사용하지만, 성능 테스트에서는 가급적 집계성(aggregate) Listener 들을 사용한다. 부하

© Sunny Kwak ２７
테스트에서 정밀한 결과를 산출하는 Listener 를 사용하거나, Listener 의 종류를 많이 적용할수록 부정확한
결과가 만들어짂다.
 부하 테스트 시에는 복수의 서버를 이용한 원격 테스트를 수행하거나, CLI(Command Line Interface)를
이용한 배치 처리(batch processing) 방식이 적용될 수 있다. 대규모 서비스에 대한 성능 분석 시에는 원격
테스트가 필수이다.
테스트 시나리오
온라인 서비스 사용자들의 이용 패턴을 예측하여 시나리오를 세분화 한다. 사용자들을 서비스 미사용자, 컨텐츠
소비자 및 컨텐츠 생산자 그룹으로 구분하여, 그에 따른 테스트 계획을 작성한다.
사용자 그룹 부하 테스트 시나리오 요약
서비스 미사용자 신규 가입 회원 정보를 입력 하고, 닉네임(nickname) 중복 여부를 체크한 후,
로그인하여 기본 정보를 확인한다.
컨텐츠 소비자 로그인 및 브라우징 이미 가입한 사용자가 온라인 서비스 서비스에 로그인 한 후,
자신이 즐겨보는 컨텐츠를 구독하고, 컨텐츠에 대한
리액션(reaction) – 좋아요, 즐겨찾기, 댓글 쓰기 - 을 수행하는
과정이다.
컨텐츠 생산자 컨텐츠 업로드 컨텐츠를 생성하는 BJ 들이 녹화한 동영상과 메타 정보를 등록 및
편집하는 과정이다.
개별 시나리오는 행위 주체(action behavior)와 발생 빈도가 상이하기 때문에 별개의 테스트 계획으로 작성하고,
부하를 측정해야 한다.
부하 테스트 구성
부하 테스트는 기능 테스트와 ‘Thread Group’, ‘Assertion’ 및 ‘Listener’ 구성(설정)이 다르다. 임의의 사용자를
등록하기 위해 ‘CSV Data Set Config’, 사용자의 실제 서비스 사용을 모방(simulation)하기 위해 ‘Timer’를 추가한다.
부하 테스트 수행 시에는 Open API 의 정상 동작 유무가 테스트 관심사가 아니며, jMeter 자원 소모를 줄이고 측정
정확도를 높이기 위해 ‘Assertion’은 제거한다. Listener 는 수행 성능을 측정해 통계 및 그래프를 생성하는 것들을
사용한다.
CSV Data 생성
부하 테스트 절차는 ‘5. CSV 데이터 생성’ 을 참조하면 된다.
CSV Data Set Config
부하 테스트 수행 시 임의의 사용자들을 신규 등록하고 로그인 하기 위해, 인증 키 (auth_key)와 닉네임
(nickname)을 일괄 생성한 CSV 파일을 입력 데이터로 사용한다.
CSV 파일 데이터 샘플은 다음과 같다. 인증 키 데이터는 40 bytes 이며, 닉네임의 최소 길이는 2 byte 이나,
일률적으로 32 bytes 길이로 생성한다.
-------------------------- CSV data sample (start) ---------------------------
userkey_12345678901_20140510141925000001,nickname_00_20140510141925000001

© Sunny Kwak ２８
-------------------------- CSV data sample (end) ---------------------------
‘CSV Data Set Config’ 에 설정하는 값들은 다음과 같다.
Column Description
Filename 인증 키(auth_key)와 닉네임 데이터를 포함한 CSV 파일 경로
Variable Names CSV 데이터를 로딩한 후, 대입할 변수 명칭들
Recycle on EOF 파일 끝에 도달했을 때, 처음 데이터부터 다시 읽어 들이는지 여부
Stop thread on EOF 파일 끝에 도달해 더 이상 읽을 데이터가 없을 경우, 스레드(thread)를 중지하는지 여부
Sharing mode ‘All threads’로 설정한다.
Thread Group
부하 테스트 시나리오에서는 ‘Thread Group’ 설정의 사용자 수 (Number of Threads), 램프 업 시간 (Ramp-up
Period), 반복 횟수 (Loop count)를 성능 테스트 목표에 맞도록 조정한다. (대상 서버 유형, 서버 성능, 테스트
목적에 따라 매번 다르게 설정한다.)
참고로 램프 업(Ramp-up)이란 공장 등에서 사용하는 산업 용어이며, 장비 설치 이후 대량 양산에 들어가기까지
생산 능력의 증가를 의미하는 말이다. 예를 들어, 사용자 수를 10 명으로 설정하고 램프 업 시간을 30 초로 설정한
경우, 30 초 구간 내에 사용자(스레드)가 순차적으로 시작하게 된다. 램프 업 시간을 사용자 수로 나눈 값이 각
사용자 간 시간 간격이 된다. (3 초 마다 한 명씩 시작 혹은 출발하게 되는 것이다.)
부하 테스트를 jMeter GUI 모드에서 실행할 경우에는 아래 그림과 같이 ‘Number of Threads’, “Ramp-up Period’,
‘Loop Count’ 값을 상수로 지정하면 된다.

© Sunny Kwak ２９
반면에 부하 테스트를 non-GUI 모드에서 수행하거나, 원격 테스트를 실시할 경우에는 jMeter property 를 참조하게
하고, property 값들을 jMeter 실행 인자로 지정한다. (상수로 설정하게 되면, 부하 수치를 변경하고자 할 때 마다
Test Plan 을 수정한 후 실행해야 한다.
Timer (Constant & Uniform Random)
사용자의 서비스 사용 패턴을 모방하기 위해서는 ‘실제’ 사용자가 요청하는 행위 사이에 시간 차가 존재한다는 것을
고려해야 한다. 즉, 사용자는 아주 짧은 간격으로 서버에 요청하지 않는다. (달리 말해서 순간적으로 대량의 요청을

© Sunny Kwak ３０
전송하는 것은 기계만이 가능한 것이다.) jMeter 는 서비스 요청 간에 일정한 시간 차이를 발생할 수 있도록
타이머(timer)를 제공한다. 다양한 타이머 유형이 존재하나, 일반적으로 고정 시간 타이머(Constant Timer)와 균일
랜덤 타이머(Uniform Random Timer)를 사용하는 것으로 충분하다.
고정 시간 타이머 설정 예시는 아래와 같다. 타이머가 포함된 요청(request)를 수행하기 전에 0.3 초를 대기하는
설정이다.
균일 랜덤 타이머(Uniform Random Timer) 예시는 아래와 같다. 타이머가 포함된 요청을 수행하기 전에 최소 3 초,
최대 5 초의 랜덤 시간을 대기하는 설정이다.

© Sunny Kwak ３１
Listener (Report)
성능 테스트 시 적용하는 Listener 는 ‘Aggregate Graph’, ‘Response Time Over Time’, ‘Transactions Per Second’
등 3 가지 이다. Aggregate Graph 를 제외한 나머지 2 가지 Listener 는 확장 플러그인에 포함되어 있다. 만일,
별도의 집계 툴을 사용하고자 로그 데이터를 저장하려고 할 경우에는 개별 요청에 대한 로그를 파일로 남길 수
있는 ‘Sample Data Writer’를 고려하면 된다.
Aggregate Graph (or Aggregate Report)
집계 보고(혹은 집계 리포트)는 각기 다른 명칭의 요청에 대한 요약 행(row)들을 포함하는 테이블을 생성한다.
각각의 요청에 대한 응답 정보 합계와 요청 횟수, 최소, 최대, 평균, 오류 빈도, 처리량 근사값(approximate
throughput), 초당 Kilobyte 단위 처리량 등을 제공한다.
집계 보고에 포함되는 항목들에 대한 간단한 설명은 다음과 같다.
Column Description
Label 샘플 명칭 (API 혹은 URL 명칭)
#Samples 특정 샘플의 요청(실행) 횟수
Average 평균 응답 시간
Median 응답 중간 집합의 수행 시간, 50%의 샘플은 Median 보다 응답시간이 작으며, 나머지는 응답 시간이 더
길다.
90% line 90%의 샘플은 ’90 % line’ 보다 적은 시간 내에 실행된다. 나머지 10%는 보다 수행 시간이 길다.
Min 최소 응답 시간
Max 최대 응답 시간
Error % 오류 발생 비율
Throughput 초/분/시간 당 수행된 요청 수
Kb/sec 초당 Kilobytes 단위로 계산된 처리량
집계 보고는 특정 시점의 부하 테스트 결과를 수치화된 형태로 기록하여, 주기적/반복적 부하 테스트 수행 시
이력을 통해 개선/변화 추이를 분석하고, 객관적 성능 평가 자료로 활용될 수 있다.
일반적인 활용 방식은 Benchmark Test 수행 전에 Median, Max 응답 시간의 목표 값을 설정하고, 집계 보고를 통해
목표 달성 여부를 판정하는 것이다. 목표에 도달하지 못했을 경우에는 하드웨어 확장, 데이터베이스 쿼리 튜닝,
어플리케이션 점검 등을 통해 튜닝을 수행한 목표에 도달할 때까지 성능 측정을 반복하는 것이다.

© Sunny Kwak ３２
Response Time over Time
부하 테스트 수행 구간 내에서 각 요청의 평균 응답 시간을 그래프로 출력한다. 서버에 대한 부하를 긴 시간(long
term)를 발생시켰을 때, 서비스 응답 시간이 시간의 흐름에 따라 증가하는지 여부를 분석할 수 있다. 또는
점진적으로 사용자가 증가하는 상황에서 서버의 응답 성능 추이를 파악할 수 있다. BMT 실시 결과 Response
Time 이 안정적이지 않을 경우, 서버 자원의 유출 혹은 감소(memory leak, I/O wait, database overload, application
error 등), 각종 장애 유무 등에 대한 점검을 실시한다. Response Timer over Time 리포트를 이용해 시스템의
신뢰성 및 안정성을 보증한다.
Transactions per Seconds
통상적으로 TPS 라는 약어로 알려져 있으며, 서비스(혹은 시스템)이 동시에 수용할 수 있는 사용자 수 혹은
수용량을 평가하는 보편적인 평가 지표이다. TPS 를 이용해 시스템의 최대 처리 가능 용량을 측정할 수는 있지만,
‘허용 가능한 최대치’이며, ‘적정 처리량’은 아니다. 적정 처리량은 하드웨어/네트워크/데이터베이스 자원 등에
여유가 있는지 여부를 함께 고려해 산정해야 한다.

© Sunny Kwak ３４
4. 기능 및 부하 테스트 수행
준비 사항
온라읶 서비스 기능 및 부하 테스트를 수행하기 위해서는 다음과 같은 사젂 준비가 필요하다.
 jMeter 설치 : 로컬 PC 혹은 개발 장비에 jMeter 어플리케이션이 설치되어 있어야 한다.
 jMeter Test Plan : 기능 혹은 부하 테스트 수행을 위해 jMeter 테스트 플랜 파읷을 작성해야 한다.
(파읷 확장자 : jmx)
 CSV 데이터 파읷 : 성능 및 부하 테스트를 수행하기 위해서는 CSV 데이터 파읷이 준비되어 있어야 한다.
기능 테스트 수행 절차
jMeter 실행
기능 테스트는 부하를 발생시키지 않으므로, Local PC 에서 jMeter 를 GUI 방식으로 실행한다. jMeter 실행 파일은
jMeter 설치 폴더 아래에 존재하는 bin 폴더 내의 ‘jmeter.bat’ 파일이다.
jMeter 를 실행한 후, ‘온라인 서비스_API_unit_test.jmx’ 파일을 로드(load)한다.
jMeter 실행 Test Plan 실행 (기능) 실행 결과 검토

© Sunny Kwak ３５
Test Plan 실행 (기능)
테스트 플랜(Test Plan)을 로드한 후, control-R 단축 키를 누르거나 메뉴 바에서 녹색 화살표 버튼을 클릭해
테스트를 실행한다.
실행 결과 검토
‘Summary Report’, ‘View Results in Tree’, ‘View Result Table’을 선택한 후, 실행 결과를 검토한다. 정상적으로
응답하지 않은 기능들은 붉은색으로 표시되며, Request 및 Response data 등을 검토하여 장애 원인을 분석한다.
부하 테스트 수행 절차
CSV generator 실행 Test Plan 실행 (부하) jMeter GUI 모드 실행
CSV input
Data file
성능 리포트 작성
Stress Test
수행 결과 (jtl)
Performance
Graph / Report

© Sunny Kwak ３６
CSV generator 실행
명령줄(command line)에서 CVS 를 생성하는 방법은 다음과 같다.
 java -jar RandomUserCsvGenerator_fat.jar
위와 같이 CSV Generator 를 실행하면, 동일 폴더 내에 ‘온라인 서비스 TestUsers.csv’ 파일이 생성된다.
(CSV generator 에 대한 상세한 설명은 ‘5. CSV 데이터 생성’ 절을 참조한다.)
Test Plan 실행
부하 테스트 시에는 jMeter 를 non-GUI 모드로 실행한다. non-GUI 모드로 실행하기 위한 배치 스크립트 예시는
다음과 같다.
배치 스크립트에 포함된 환경 변수(environment variables)들은 다음과 같다.
Variable Description
JMETER_HOME jMeter 프로그램 설치 경로 (실행 프로그램 경로)
TEST_PLAN jMeter test plan 파일 명칭 (입력 파일 경로)
RESULT_FILE jMter test 수행 결과 파일 명칭 (출력 파일 경로)
jMeter 실행 인자(parameter)에 대한 설명은 다음과 같다.
-n : jMeter 를 non-GUI 모드로 실행한다.
-t : jMeter test plan 입력 파일이름을 설정한다.
-l : jMeter 테스트 수행결과 출력 파일 이름을 설정한다.
-J : jMeter 속성(property)를 설정한다. name=value 형식으로 설정한다.
위 예시에서는 ‘loops’, ‘ramp_up’, ‘threads’ 변수를 선언하였으며, 3 가지 변수는 thread group 에서 참조한다.
rem jMeter run batch script for Windows
rem set jMeter installation directory
set JMETER_HOME=D:온라읶 서비스apache-jmeter-2.11
rem set jMeter "test plan" script file name
set TEST_PLAN=온라읶 서비스_API_load_test__2_login_browse.jmx
rem set jMeter stress test result file name
set RESULT_FILE=온라읶 서비스_Stress_Resuts.jtl
%JMETER_HOME%binjmeter -n -t %TEST_PLAN% -l %RESULT_FILE% -Jloops=1 -Jramp_up=30 -
Jthreads=30

© Sunny Kwak ３７
배치 실행 스크립트 파일 명칭이 ‘run_jmeter.bat’이라고 가정했을 때, 배치 스크립트를 실행하면 아래와 유사한
결과가 출력된다.
C:run>run_jmeter
C:run>rem set jMeter installation directory
C:run>set JMETER_HOME=D:온라인 서비스apache-jmeter-2.11
C:run>rem set jMeter "test plan" script file name
C:run>set TEST_PLAN=온라인 서비스_API_load_test__2_login_browse.jmx
C:run>rem set jMeter stress test result file name
C:run>set RESULT_FILE=온라인 서비스_Stress_Resuts.jtl
C:run>D:온라인 서비스apache-jmeter-2.11binjmeter -n -t 온라인 서비스_API_load_test__
2_login_browse.jmx -l 온라인 서비스_Stress_Resuts.jtl -Jloops=1
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=64m; support
was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; sup
port was removed in 8.0
Creating summariser <summary>
Created the tree successfully using 온라인 서비스_API_load_test__2_login_browse.jmx
Starting the test @ Mon May 12 15:04:10 KST 2014 (1399874650593)
Waiting for possible shutdown message on port 4445
summary + 94 in 19.1s = 4.9/s Avg: 223 Min: 134 Max: 587 Err: 19 (20.21%) Active: 20 Started: 20 Finished: 0

© Sunny Kwak ３８
summary = 277 in 49.1s = 5.6/s Avg: 239 Min: 90 Max: 587 Err: 37 (13.36%)
summary = 358 in 80s = 4.5/s Avg: 220 Min: 79 Max: 587 Err: 88 (24.58%)
summary + 2 in 1.1s = 1.8/s Avg: 173 Min: 164 Max: 183 Err:
2 (100.00%) Active: 0 Started: 30 Finished: 30
summary = 360 in 82.3s = 4.4/s Avg: 220 Min: 79 Max: 587 Err: 90 (25.00%)
Tidying up ... @ Mon May 12 15:05:33 KST 2014 (1399874733227)
... end of run
jMeter GUI 모드 실행
jMeter 를 non-GUI 모드로 실행했을 경우, 부하 테스트 실행 결과는 확장자가 ‘jtl’인 파일에 저장된다. 출력 결과는
jMeter 를 GUI 모드로 실행하고, 결과 파일을 로드(load)해 확인할 수 있다.
jMeter 를 실행한 후, 리포트를 생성할 listener 를 선택한다. Listener 내에서 ‘Write results to file / Read from file’
그룹의 ‘Filename’ 항목의 ‘Browse …’ 버튼을 클릭한다. 배치 수행 결과 jtl 파일을 선택하면 수행 결과를 chart /
report 형식으로 조회할 수 있다.

© Sunny Kwak ３９
성능 리포트 작성
‘Reponse Times Over Time’, ‘Transactions per Seconds’ 등의 listener 에서 생성된 chart / graph 이미지를
클립보드로 복사하거나, CSV 파일 형식으로 출력(export)한 후 엑셀에서 편집하는 등의 방법으로 성능 리포트를
작성한다. Listener 의 그래프 화면을 마우스로 우클릭하면, 이미지를 클립보드로 복사하거나, CSV 로 출력하는
컨텍스트 메뉴(context menu)가 나타난다.

© Sunny Kwak ４０
5. CSV 데이터 생성
CSV Generator 개요
온라읶 서비스 부하 테스트를 수행하기 위해서는 임의의 사용자를 생성해야 하며, 사용자 계정을 읷괄 생성하기 위한
데이터를 자바 배치 어플리케이션(Java batch application)를 이용해 CSV(Comma Separated Value) 형식의 텍스트
파읷로 생성한다.
CSV Generator 어플리케이션 구조
CSV Generator 어플리케이션의 프로젝트 명칭은 ‘RandomUserCsvGenerator’ 이다. 메읶 클래스는
‘CsvDataSetMaker’이며, 의존 라이브러리(dependent library)는 Apache Commons BeansUtils’이다. 프로젝트 구성은
아래와 같다.
Fatjar 플러그인 설치
CSV Generator 어플리케이션을 필요한 library 들을 포함한 단읷 jar 파읷로 변홖하기 위해, Fatjar 플러그읶을
사용한다. Fatjar 플러그읶을 설치하기 위해 이클립스의 ‘Help > Install New Software’ 메뉴를 선택한다.

© Sunny Kwak ４１
‘Install’ 다이얼로그 우측 상단의 ‘Add...’ 버튼을 클릭한다.
‘Name’ 항목에 ‘fatjar’를 입력하고, ‘Location’ 항목에 ‘http://kurucz-grafika.de/fatjar/’를 입력한 후, OK 버튼을
클릭한다.

© Sunny Kwak ４２
FatJar 플러그읶을 선택한 후, 설치를 짂행한다.
Jar 생성 및 CSV Generator 실행
실행 가능한 jar (executable jar)를 생성하기 위해서는 먼저 fatjar 플러그읶이 설치되어 있어야 한다. 패키지
익스플로러(package explorer)에서 ‘RandomUserCsvGenerator’ 프로젝트를 선택한 후, 마우스 우클릭 버튼을 이용해
컨텍스트 메뉴(context menu)를 실행한다. 컨텍스트 메뉴에서 ‘Build Fat Jar’를 선택한다.

© Sunny Kwak ４３
‘Main-class’ 항목에 ‘com.samsung.msc.온라읶 서비스.randcsv.CsvDataSetMaker’ 를 입력한 후, ‘Finish’ 버튼을
클릭한다.
프로젝트 루트(root) 경로에 ‘RandomUserCsvGenerator_fat.jar’ 파읷이 생성된 것을 확읶할 수 있다. 생성된
jar 파읷을 이용해 명령줄(command line)에서 손쉽게 CSV 생성 작업을 수행할 수 있다.

© Sunny Kwak ４４
명령줄(command line)에서 CVS 를 생성하는 방법은 다음과 같다.
 java -jar RandomUserCsvGenerator_fat.jar
위와 같이 CSV Generator 를 실행하면, 동읷 폴더 내에 ‘온라읶 서비스 TestUsers.csv’ 파읷이 생성된다.

Web service performance_test_using_jmeter_ver1.2

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (17)

Similar to Web service performance_test_using_jmeter_ver1.2

Similar to Web service performance_test_using_jmeter_ver1.2 (20)

More from 중선 곽

More from 중선 곽 (20)

Web service performance_test_using_jmeter_ver1.2