블로그 이미지
신세계 SSG.COM / IT개발 1팀 / 상품개발담당 / 김지영 FreeEnd

카테고리

전체 (81)
끄적끄적 (13)
News (1)
Movie (11)
Security (1)
Design Patterns (2)
Operating System (4)
Database (8)
Framework (4)
Solution (7)
Language (1)
Web (4)
Lib (3)
TEST_Tools (4)
ETC... (7)
Software Factory (0)
Total193,650
Today34
Yesterday92


달력

« » 2017.08
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

공지사항

글 보관함

'TEST_Tools'에 해당되는 글 4건

  1. 2008.09.11 webtest 튜토리얼
  2. 2008.09.10 Jmeter를 사용한 Stress Test(3)
  3. 2008.09.10 Jmeter를 사용한 Stress Test(2)
  4. 2008.09.10 Jmeter를 사용한 Stress Test(1)

webtest 튜토리얼

TEST_Tools / 2008.09.11 13:57

 

webtest 튜토리얼


 

 

Webtest XML을 이용해 작업을 스크립트한 다음 그 스크립트 내용대로 작업을 진행할 수 있는 web 자동화 테스트 툴이다.

기존 테스트를 수행하기 위해 개발자가 직접 수행한 반복적인 비 생산적 작업을 Webtest을 이용하면 쉽고 빠르게 테스트를 진행 할 수 있다.

 

 다음은 WebTest를 이용한 테스트 결과 화면이다.


 

사용자 삽입 이미지

그림 1 webtest의 테스트 결과 페이지

 

상기 화면은 단순히 페이지를 33번 연속으로 방문한 결과를 나타낸 페이지이다. 이렇게 canoo webtest는 작업 결과를 html화면으로 출력해 보다 쉽게 결과를 확인할 수 있게 도와준다.

 

 

 

설치

Canoo Webtest 설치 방법은 어렵지 않다. Webtest의 공식 홈페이지에 접속해 다운로드하면된다

.

사용자 삽입 이미지

그림 2 webtest 다운롣드 페이지

 

현재 가장 최신 버전은 2.6 이므로 2.6버전을 다운로드한다. Webtest에서 다운로드 받을 수 있는 압축파일은 크게 5개이다. build.zip, doc.zip, src.zip, selftest.war, build-maven.zip이 있는데 각 파일 이름별로 해당 패키지가 들어 있다. 우리는 우선 모든 파일을 포함하고 있는 Build.zip을 다운로드 하기로 한다.

 

다운로드된 파일의 압축을 풀고 webtest를 설치하고자 하는 디렉토리에 복사한다.

 

 

사용자 삽입 이미지

그림 3 webtest의 저장 경로

 

Webtest“Program Files” 밑에 설치 하는 것이 일반적이므로 압축을 푼뒤 디렉토리 이름을 webtest로 변경한 뒤 Program Files밑에 둔다.

 

다음은 환경변수 설정을 해야 한다.

내컴퓨터에서 마우스 오른쪽 버튼을 누르고 시스템 등록정보, 혹은 winkey + pause를 눌러 시스템 등록정보에 들어간뒤 고급탭에 있는 환경변수에 들어간다.


사용자 삽입 이미지

그림 4 시스템 등록 정보

 

 이곳에서 path에 다음과 같이 webtest 디렉토리에 포함된 bin디렉토리를 path 에 추가한다.

 

“C:\Program Files\WebTest\bin”

 

사용자 삽입 이미지

그림 5 환경변수 설정

 

환경 변수 설정이 끝났으면 커맨드라인에서 설치완료를 확인한다.

 

C:\> webtest –version

 

다음과 같이 버전정보가 출력되면 설치가 완료된 것이다.

 


사용자 삽입 이미지

그림 6 설치후 버젼 확인

 

Webtest의 예

 

Webtest의 실행을 위해서 우선 테스트 디렉토리를 하나 생성한다.

디렉토리를 하나 생성했으면 그 밑에 테스트 파일을 위핸 simpletest.xml파일을 생성한다.

 

사용자 삽입 이미지

그림 7 테스트 디렉토리

 

그 다음 테스트 스크립트를 작성한다.

 

<?xml version="1.0" encoding="euc-kr"?>

<project name="SimpleTest" basedir="." default="wt.full">

 

  <property name="webtest.home" location="C:\Program Files\WebTest" />

  <import file="${webtest.home}/webtest.xml"/>

 

  <target name="wt.testInWork">

             <webtest name="check that WebTest is FreeEnd's top 'bolg' result">

                           <invoke url="http://freeend.tistory.com/" description="FreeEnd Blog"/>

                           <verifyTitle text="FreeEnd" />

             </webtest>

  </target>

</project>


 

 

 

 우선 한글 사용을 위해 xml encoding형식을 euc-kr로 설정한다.

 

<?xml version="1.0" encoding="euc-kr"?>

 

 

 현재 테스트 프로젝트의 이름 등의 환경을 설정한다. Name은 이름 basedir은 작업 디렉토리이다.

 

<project name="SimpleTest" basedir="." default="wt.full">

 

 

 웹 테스트의 빌드를 위해 webtest에서 제공하는 webtest.xml파일을 import한다. 이 파일은 webtest를 설치한 디렉토리에 있으므로 location webtest_home 디렉토리를 설정해 주면 된다.

Property태그는 wettest,home의 프로퍼티를 설정해 주는 탭으로 webtest의 홈 디렉토리를 넣어준다.  이렇게 property를 설정해 두면 webtest의 홈 디렉토리를 webtest,home으로 대체하여 사용할 수 있다.

 

  <property name="webtest.home" location="C:\Program Files\WebTest" />

  <import file="${webtest.home}/webtest.xml"/>

 

 

실제로 이루어질 테스트의 한 step의 이름을 입력한다. 여기서는 FreeEnd Blog 라는 페이지를 대상으로 삼았으므로 그에 알맞은 테스트 이름을 입력하였다.

 

             <webtest name="check that WebTest is FreeEnd's top 'bolg' result">

 

 

다음으로 가장 중요한 실제 수행할 스크립트를 작성하는 부분이다. 이곳에서는 페이지를 요청하는 단순한 작업이므로 그에 해당하는 invoke 태그를 이용해 url을 입력한다. Description은 해당 요청사항에 대한 설명을 입력한다.

                           <invoke url="http://freeend.tistory.com/" description="FreeEnd Blog"/>

 

 

다음은 해당 요청 페이지가 정확하게 요청되어 원하는 페이지가 응답 되었는지를 확인하는 태그이다. verifyTitle 태그는 요청 페이지의 헤더 부분에 있는 title태그의 같을 가져와 자신의 태그에 있는 text값과 비교해 같으면 success, 다르면 fail을 리턴해 요청의 성공 실패를 확인시켜 준다.

 

                           <verifyTitle text="FreeEnd" />

 

 

 

실행

 

요청 스크립트의 작성이 끝나면 잘 저장한 후 실행 시킨다. 실행 명령어는 다음과 같다.

 

 

 C:\WebTestTest> webtest -buildfile simpletest.xml

 

 

다음은 요청된 스크립트의 실행 화면이다.

 

사용자 삽입 이미지

그림 8 실행중인 webtest의 콘솔화면

 

 

 

사용자 삽입 이미지

그림 9 테스트 모니터

 

테스트가 성공적으로 끝나면 windows에 설정된 default 브라우저로 결과같이 다음과 같이 출력된다.

 

사용자 삽입 이미지

그림 10 테스트 완료후 결과

 

 

 

 현재 위 테스트는 요청 페이지로의 요청에 대해 테스트 한 것이다. 이러한 테스트는 아주 기초적인 스크립트 작성으로 다양한 테그를 이용해 필드 채우기, 버튼클릭, 하이퍼링크 따라가기 등 많은 작업을 요청할 수 있다. 다른 요청 태그를 알고 싶다면 http://webtest.canoo.com/webtest/manual/stepIndex.html 를 방문하면 다양한 태그를 얻어 사용할 수 있다. 김지영.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 지영옹 FreeEnd
TAG webtest
Published on Hanbit Network (http://network.hanb.co.kr)

Jmeter를 사용한 Stress Test(3)

제공 : 한빛 네트워크
저자 : 이상호

5. JMeter를 사용한 실제 전략

본 섹션에서는 JMeter를 사용해 실제로 로그인하고 로그인한 정보를 바탕으로 접근 가능한 URL에 접근해 부하 테스트를 진행해보겠다.

본문에서는 테스트를 설명하기 위해서 daum 에 로그인하고 저자가 카페지기로 있는 사이트에 가서 특정글에 대한 요청을 서버에게 던져서 정상적으로 글을 가져오는지 확인해보겠다.

우선 다음과 같이 Test Plan 노드를 추가한다.


[그림 5-1] Daum의 Café에 접속하기 위해 글을 가져오기 위한 Test Plan

[그림 5-1]과 같이 Test Plan을 만들면 되는데 가만 보면 못 보던 요소가 하나 존재한다. 바로 HTTP Cookie Manager인데 Cookie Manager는 JMeter 2.0.3 부터 새로이 추가된 element다.

이 element의 추가는 [그림 5-2]에서 보이는 것과 같이 추가한다.


[그림 5-2] HTTP Cookie Manager 추가하기

Cookie Manager는 Thread Group이나 Test Plan 노드에 추가해도 되는데 Test Plan 노드에 추가하는 경우는 여러 Thread Group이 모두 로그인 페이지를 요구하는 경우 유용하게 사용할 수 있다.

반대로 특정 Thread Group에서만 로그인 페이지를 요구하는 경우 Thread Group에만 추가하면 된다.

그리고 HTTP Request Sampler를 총 2개 추가한다.

HTTP Request Sampler는 다음 [그림 5-3]과 같이 설정한다.


[그림 5-3] HTTP Request 1

첫번째 HTTP Request는 Daum에 로그인 요청을 하는 Sampler이다. [그림 5-3]에 보이는 요소에 대해서는 섹션 4에서 다루었기 때문에 섹션 4와 비교했을 때 다른 것만 알아보기로 한다.

[그림 5-3]에는 빨간 박스로 강조되어진 부분이 있는데 이 부분은 JMeter에서 요청을 한후 자동으로 주소를 변경할지를 설정하는데 일부 사이트의 경우 이 옵션이 켜져 있을 경우 문제가 된다. 때문에 로그인하는 요청의 경우 옵션은 해제해주는게 좋다. 그리고 Follow Redirects 옵션을 켜주는게 좋다. Follow Redirects 옵션은 웹 사이트의 Redirect 액션을 허용한다.

[그림 5-4]는 실제 게시물에 접근하는 요청이다. 이때 접근하는 URL은 미리 페이지 등록정보를 통해 확인한 URL을 이용한다.


[그림 5-4] HTTP Request 2

[그림 5-4]는 게시물에 접근하는 요청이다. 빨간 박스로 강조된 부분은 Path에 인자로 넘겨지는 부분인데 이와 같이 URL에 접근에 있어서 파라메터를 요구하는 경우는 1개씩 인자를 생성해주어야 한다.

이제 요청 결과를 알아보기 위해 Test Plan을 실행한다. Test Plan의 실행은 Run > Start 메뉴를 선택하거나 Ctrl + R 키를 누른다.

그럼 [그림 5-5]와 같이 Test Plan을 저장할 것이냐고 물어오는데 본문은 테스트이므로 아니오를 눌러 저장하지 않는다.


[그림 5-5] Test Plan을 저장할것입니까?

스트레스 테스트가 끝나면 JMeter의 왼쪽 트리에서 View Results Tree 노드를 선택한다.


[그림 5-6] View Results Tree 노드 선택

이제 JMeter의 화면 오른편에는 [그림 5-7]과 같은 화면이 있는 걸 볼 수 있다.


[그림 5-7] View Results Tree 초기 화면

이제 [그림 5-7]에 보이는 항목을 클릭하면 [그림 5-8]과 같이 변경된다.


[그림 5-8] 2번째 HTTP Request 클릭 후

[그림 5-8]의 결과를 보면 정상적으로 수행은 된거 같은데 어떤 결과가 왔을지 사뭇 궁금해진다. 결과를 확인하기 위해 [그림 5-8]에 보이는 Response data 탭을 클릭하고 적절하게 위치를 이동하면 아래와 같은 결과를 확인해볼 수 있다.


[그림 5-9] 정상적으로 받아온 데이터

[그림 5-9]에 보이는 화면과 같이 데이터를 정상적으로 받아온 것을 확인할 수 있다. 물론 [그림 5-9]에 보이는 것과 같이 보이지 않는다면 [그림 5-9] 하단에 보이는 Render HTML이나 Show Text 라디오 버튼을 선택해야 한다. Render HTML의 경우 일부 웹 사이트는 정상적으로 보여지지 않을 수 있기 때문에 Show Text 라디오 버튼을 선택해서 보는 것이 더 정확하다.

사족으로 [그림 5-9]에 보이는 내용은 가수 이소은씨가 팬카페에 2007년 4월에 게시판에 남겨준 내용이다.

여기까지 잘 따라왔다면 정상적으로 처리가 되어야 하지만 그렇지 않다면 뭔가 이상이 있는 경우이므로 다시한번 확인해보기로 한다.

6. JMeter 로그 분석하기

JMeter로 테스트는 했는데 정작 테스트 결과를 볼 수 없거나 엉뚱한 자료만 가지고 있다면 분석은 못하게 될것이다.

이를 위해서 Listener로 Summary Report element를 추가해주는 것을 권장한다.

섹션 5에서 수행했던 Summary Report를 보면 [그림 6-1]과 같다.


[그림 6-1] Summary Report

[그림 6-1]은 섹션 5에서 수행된 Summary Report인데 눈여겨 봐야 할 컬럼은 총 5개로 위 그림에서 강조되어 있다.

결과 분석을 위해 첫번째 컬럼부터 살펴본다.
  • 1번째 컬럼 : 서버에 요청한 횟수
  • 2번째 컬럼 : 평균 응답시간(ms단위)
  • 3번째 컬럼 : 최소 응답시간(ms단위)
  • 4번째 컬럼 : 최대 응답시간(ms단위)
  • 5번째 컬럼 : Error율(%단위)
5번째 컬럼을 제외하곤 4번째 컬럼까지는 값의 단위는 밀리 세컨드 단위(ms)이다. 1초는 0.001 밀리세컨드이다. 계산이 귀찮다면 google 에 밀리 세컨드 값을 넣고 다음과 같이 검색어를 입력한다.

78 milliseconds to seconds

그러면 google이 자동으로 계산해준다.

5번째 컬럼은 서버로의 요청 중에 문제가 있을 경우 에러가 났다거나 한 경우 그 에러율을 퍼센테이지로 표시해준다.

여기서 살펴본 것을 기준으로 간단한 보고서 작성이 가능하겠으나 더 자세한 보고서 작성을 위해 JMeter User Manual을 참조해 다양한 Listener 추가를 통해 다양한 결과 형태를 볼 수 있으므로 꼭 한번씩 참조해서 실행해보는 것을 권장한다.

7. JMeter 활용 전략

JMeter는 그 초기 목적과 달리 다양한 테스트를 위해 확장되고 있으므로 여러 목적으로 사용할 수 있다.

따라서 저자는 JDBC, Java Request, JUnit, FTP 등을 테스트 하기 위해 JMeter 사용을 권장한다.

JMeter의 보다 폭 넓은 활용을 위해서 다음과 같은 사용 전략을 제시한다.
  • JDBC 테스트 : DB가 얼마나 부하를 견딜 수 있는지 알고 싶다
  • Java Request 테스트 : 순수 자바 애플리케이션을 만들고 있는데 별도의 테스트 툴이 없어서 힘들다.
  • JUnit 테스트 : 애플리케이션 테스트를 위해 Junit Test Case를 만들었는데 JMeter로 대신 실행해서 JUnit을 부하 테스트 하는데 사용하고 싶다.
  • FTP 테스트 : FTP 서버를 구축했는데 얼마나 접속했을 때 다운되는지 알고 싶다(실제 이렇게 할 사람이 있는지 모르겠다)
물론 위와 같은 사용 제시 외에도 JMeter는 대표적인 오픈소스 IDE인 Eclipse와 연동해서 사용하는 것이 가능하다. 다음에 기회가 되면 이 같은 사용법을 제시할 수 있기 바란다.

Copyright © 2008 Hanbit Media, Inc.
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 지영옹 FreeEnd
TAG jmeter
Published on Hanbit Network (http://network.hanb.co.kr)

Jmeter를 사용한 Stress Test(2)

제공 : 한빛 네트워크
저자 : 이상호

4. JMeter를 사용한 Simple Test

지금까지 간략히 JMeter의 테스트 계획에 대해서 알아보았는데 본 섹션에서는 앞에서 다루었던 Test Plan에 실제 숨을 불어넣어 본다.

본문에서는 저자가 운영진으로 활동하고 있는 한국 아파치 사용자 모임 사이트를 대상으로 삼았다. 우선 HTTP Request 노드를 선택하면 JMeter 의 오른쪽 화면이 바뀌면서 [그림 4-1]처럼 나타나게 된다.


[그림 4-1] HTTP Request 선택

[그림 4-1]에는 빨간 박스가 다수 보이는데 이 박스 안의 내용을 입력하거나 선택함으로서 테스트 정보를 입력한다.

첫번째 입력할 정보는 테스트할 서버의 IP 또는 URL을 입력하는데 URL은 프로토콜 정보를 제외한 순수 주소만 적는다. 다음과 같은 URL이 테스트할 정보라고 보고 Server Name을 분리하자.

http://www.apache-kr.org/www/board.php?cmd=retrieveContent&board_cd=techtalk&rg_d=20080410&rg_seq_n=1&pageID=1&search_gb=&fr_rg_d=&to_rg_d=&searchstring=
Server Name은 www.apache-kr.org가 되어야 한다.

두번째 입력하고 선택할 정보는 Method와 Path인데 이 정보는 실제로 테스트할 URL 정보가 들어간다.

Path는 실제 테스트할 URL을 말하는데 / 로부터 시작하고 인자가 시작되기 전까지의 정보를 적는다. 앞에서 언급된 URL을 기준으로 path는 아래와 같이 분리된다.
/www/board.php
위에서 나타난 파일이 어떤 인자를 받는다면 그 인자 방식을 Method에서 선택해준다. 여러 Method를 사용할 수 있지만 웹 애플리케이션은 일반적으로 GET 방식과 POST 방식을 사용한다. 예제로 쓰는 URL은 모든 정보를 GET 방식으로 던진다. 따라서 Method는 GET으로 지정한다. 물론 인자를 받지 않는다면 Parameter 정보를 입력하지 않아도 된다.

HTTP Request 노드의 Method 기본값은 GET이기 때문에 혹시 GET이 아니면 수정해주도록 한다. Add 버튼을 클릭하면 파라메터 정보를 입력받게 된다.

본문에서는 Add 버튼을 5번 눌러 파라메터 입력을 5개 만들었다. 입력할 파라메터는 다음 목록과 같다.
cmd
board_cd
rg_d
rg_seq_n
pageID
서버 정보 및 파라메터 정보를 모두 입력한 화면은 [그림 4-2]와 같다.


[그림 4-2] 테스트 정보를 모두 입력한 화면

HTTP Request 정보를 모두 입력했다면 Thread Group에 관한 설정을 할 차례다. JMeter의 왼쪽 트리에서 Thread Group 노드를 선택하면 [그림 4-3]과 같은 화면이 나타난다.


[그림 4-3] Thread Group 정보 입력

[그림 4-3]에 보이는 Thread Group 정보는 몇가지 예의 주시해서 입력해야 할 정보가 있다.

첫번째 박스는 몇 명의 사용자로 동시 접속 부하를 줄것인지에 대한 것인데 사용자명을 높게 지정할수록 서버의 부하 테스트도 더 커진다.
두번째 박스는 한명의 사용자가 접속자가 서버로 부하를 주러 떠나고 다른 사용자가 부하를 주러 떠날 때 사용자간의 접속 시간을 지정한다. JMeter 문서에는 쓰레드의 생성 주기를 나타낸다고 하지만 이해를 돕기 위해서 사용자간의 접속 시간으로 보면 된다.

세번째 박스는 Thread Group에 속해있는 Sampler들을 몇번 보낼 것인지 지정한다. 이해가 어렵다면 HTTP Request에서 지정했던 URL을 Loop Count 에 지정한 숫자만큼 다시 서버에 요청을 한다고 이해하면 된다. 만약 Forever 박스를 체크했다면 JMeter 실행자는 JMeter를 수동적으로 정지시켜줘야 한다.

본문에서는 Number of Threads(users)를 10명으로 Loop Count는 3으로 수정하였다. 이 숫자나 양은 테스트 부하에 따라 적절하게 조정해주면 된다.

이제 부하 테스트를 해볼 차례다. 부하 테스트는 메뉴에서 Run > Start를 선택하거나 Ctrl + R 키를 누르면 Test Plan을 저장할 것인지 묻게 되고 아니오(N)을 누르면 테스트를 시작한다. 만약 Test Plan이 저장되어 있다면 바로 부하 테스트를 시작하게 된다.


[그림 4-4] 테스트 계획을 저장하시겠습니까?

부하가 진행되는 중에는 [그림 4-5]에 있는 네모 박스에 녹색불이 들어오면서 테스트를 시작한다.


[그림 4-5] 부하가 진행중인 표시

부하 테스트가 끝나면 JMeter의 왼쪽 트리에서 View Results Tree를 선택하면 오른쪽 화면이 [그림 4-6] 처럼 바뀌게 된다.


[그림 4-6] View Results Tree

[그림 4-6]과 같이 테스트한 결과가 출력되었다면 테스트는 정상적으로 이루어진 것이다. 하지만 종종 화면 좌측에 보이는 초록색의 삼각 아이콘 모습이 나타나지 않으면 네트워크 연결 오류나 서버측 오류로 인해 테스트할 없는 상황으로 본다.

다음 [그림 4-7]은 Graph Results 노드를 선택한 결과이다.


[그림 4-7] Graph 결과로 표시된 부하 테스트

Copyright © 2008 Hanbit Media, Inc.
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 지영옹 FreeEnd
TAG jmeter
Published on Hanbit Network (http://network.hanb.co.kr)

Jmeter를 사용한 Stress Test(1)

제공 : 한빛 네트워크
저자 : 이상호

1. JMeter의 소개

JMeter는 Apache Jakarta 프로젝트의 일환으로 만들어진 테스트 기능과 퍼포먼스를 측정하는 애플리케이션이다. 이 애플리케이션 100% 순수 자바로 작성되었으며 원래 웹 애플리케이션을 위해 디자인되고 사용되었으나 현재는 다른 기능의 테스트를 위해 확장되고 있다.

JMeter는 static, dynamic 한 모든 자원(파일, 서블릿, perl script, java object, database and query, ftp, soap 등)에 대해 퍼포먼스를 테스트할 수 있다. 이러한 테스트 결과로 분석결과를 그래픽으로 표시해주는 기능과 스크립트 객체 등에 대해 과도한 동시 처리 부하가 가능하다.

Apache Jmeter는 다음 사이트에서 얻을 수 있다.

http://jakarta.apache.org/jmeter/

JMeter에 대한 추가 정보는 위 사이트에서 얻을 수 있다. 한데 위 사이트는 영어로 구성되어 있기 때문에 조금 빈약하더라도 한국어로 된 정보는 자카르타 서울 프로젝트에서 얻을 수 있다.

http://jakarta.apache-korea.org

2. JMeter를 얻고 설치하기

JMeter를 설치 하기 위해서 우선 Jakarta 의 JMeter 사이트에 접속한다. 다음 그림들은 Jakarta 메인 사이트와 JMeter 사이트를 보여준다.


[그림 2-1] Jakarta 사이트


[그림 2-2] Jakarta JMeter 사이트

JMeter를 다운로드 받기 위해선 화면 왼쪽의 Download Binary 링크를 통해 들어가면 다운로드 받을 수 있다.


[그림 2-3] Jakarta 다운로드 링크 페이지

Jakarta 프로젝트는 다수의 서브 프로젝트들로 이뤄져 있기 때문에 실제적인 다운로드는 Downloads 섹션의 Jmeter를 클릭하면 다운로드 받을 수 있게 된다. [그림 2-3]은 그 화면을 나타낸다.


[그림 2-4] Mirror 페이지

[그림 2-3]에서 JMeter 를 클릭하면 곧 바로 다운로드를 시작하지는 않고 어디서 다운로드 받을지 물어오게 된다. 본 문서에서는 미러 사이트로 한국 아파치 사용자 모임을 선택했다. [그림 2-4]에 보이는 빨간 박스를 클릭하면 미러 사이트가 나타나게 된다. 미러 사이트를 선택했다면 Change 버튼을 눌러 미러 페이지를 변경시킨다.

미러 사이트는 다수가 존재하는데 다운로드 속도가 느릴 경우 바꿔가며 시도해본다. 일반적으로 기본적으로 선택되는 미러 사이트를 이용해도 된다.


[그림 2-5] JMeter 다운로드 링크

[그림 2-4]의 화면에서 미러 사이트를 변경하지 않았거나 변경한 경우 화면 스크롤을 내리면 빨간박스로 그려진 부분 2.3.1.zip 부분을 볼 수 있다. 이 부분을 클릭하면 본격적인 다운로드 윈도우를 볼 수 있다.


[그림 2-6] 파일 저장 윈도우

[그림 2-6]에서 보여지는 윈도우는 파일을 어디에 저장할 것인지를 물어오는 화면이다. 본문에서는 바탕 화면에 저장하였다.


[그림 2-7] 바탕화면에 저장된 JMeter 파일

[그림 2-6]에서 바탕 화면에 저장된 파일은 [그림 2-7]과 같다.


[그림 2-8] JMeter 실행 파일

JMeter는 Java Application 이기 때문에 별도의 설치 프로그램을 필요로 하지 않는다. 본문에서는 압축파일을 선택한 후 바탕 화면 폴더에 압축 내용을 별도의 폴더 생성 과정 없이 풀었다. 이렇게 푸는 이유는 JMeter 압축파일이 별도의 상위 폴더를 가지고 있기 때문이다. [그림 2-8]은 그런 화면을 나타낸다.

JMeter의 실행은 [그림 2-8]에 보이는 것처럼 jmeterw.cmd 파일을 더블 클릭하면 실행한다.


[그림 2-9] JMeter의 실행 화면

3. JMeter 기본 과정

JMeter는 테스트 환경에 있어 상위 항목으로 WorkBench와 Test Plan를 두고 있다. 이 상위 항목을 다른 이름으로 노드라고 표현한다. 노드라는 단어는 Tree에서 비롯되었는데 JMeter는 각각의 element를 계층적으로 관리 하기 위해서 Tree 구조를 사용한다. JMeter는 테스트 앞서 Test Plan을 먼저 작성하게 된다. Test Plan은 한국어로 풀어 쓰면 테스트 계획인데 JMeter의 모든 Test는 이 Test Plan을 먼저 세워야 한다.
Test Plan
+ HTTP Test
WorkBench
[모식도 3-1] JMeter 모식도

[모식도 3-1]은 위에서 설명한 구조를 간략히 그려내 본 것이다. JMeter는 Test Plan과 WorkBench 아래에 놓이는 것을 가리켜 Element라고 한다. 한국어로는 요소라는 말이 적절하겠지만 이해를 돕기 위해 원어로 표기한다. Element는 여러 종류가 있는데 Test Plan에 바로 올 수 있는 Element는 다음과 같은 것들이 있다.


[그림 3-1] Test Plan 에 추가될 수 있는 element

[그림 3-1]은 Test Plan 노드 아래 추가될 수 있는 element를 나타내고 있는데 기본 테스트를 하기 위해선 Thread Group과 Listener 의 추가가 우선적이다. Thread Group는 테스트의 가장 기본적인 요소로써 Test Plan 노드 아래 몇 개든 올 수 있다. Thread Group은 논리적인 모습으로 표현하면 테스트 클라이언트들의 묶음이라고 보는 표현이 타당하다.

JMeter는 단지 Thread Group을 구성하는 것만으로 결과를 볼 수 없다. 이 뚱딴지 같은 이야기는 JMeter가 결과를 보기 위한 또 다른 구성 요소를 필요로 한다는 것이다. JMeter는 테스트 결과를 다양한 형태로 볼 수 있도록 다음과 같은 구성 요소를 지원한다.


[그림 3-2] Listener의 구성 요소

[그림 3-2]에 보이는 element 중 가장 많이 사용되는 요소는 Graph Results, Summary Report, View Results in Table, View Results Tree다.

다시 앞으로 돌아가서 Thread Group은 테스트에 있어서 기본적인 단위가 된다고 했다. 이제 Thread Group 아래 다른 element를 추가할 필요가 있다.

Test Plan 노드에 Thread Group을 추가한 후 마우스 오른쪽 클릭을 통해 보면 [그림 3-1]에서 보던 것과 비슷한 화면이 보이는데 하나 더 추가된 element 그룹이 존재한다.


[그림 3-3] Thread Group에서의 마우스 오른쪽 팝업

[그림 3-3]에는 Sampler 그룹이 보이는데 바로 이 그룹이 JMeter 테스트에 있어서 실제로 부하를 보내는 실제적인 주체가 들어 있는 그룹이다. Sampler는 다양한 element가 들어가 있는데 대표적으로 다음과 같은 sampler 항목을 들어볼 수 있다.


[그림 3-4] 많이 쓰이는 Sampler

Sampler는 위의 그림에 보이는 것보다 더 많지만 기본적인 기능 테스트 및 웹 애플리케이션 테스트에는 [그림 3-4]에 있는 Sampler가 더 많이 쓰인다.

본문에서는 HTTP Request Sampler에 대해서만 집중적으로 다룰텐데 다른 Sampler에 대해선 다른 기회가 주어진다면 하나씩 파보는 기회를 가져보도록 하겠다.

Thread Group에는 Sampler 뿐 아니라 다른 element들도 추가가 가능한데 이들 element에 대해서도 다른 기회가 주어졌을 때 파보는 기회를 가져보겠다.

자 이제까지 설명한 것은 JMeter에서 스트레스 테스트를 하기 위한 기본 구조를 설명하였다. [그림 3-5]는 지금까지 설명한 구조를 실제로 구현한 JMeter의 Test Plan 의 모습이다.


[그림 3-5] 간단한 Test를 위한 Test Plan

다음 섹션에서는 [그림 3-5]를 기반으로 한 Simple한 Test를 진행해보겠다.

Copyright © 2008 Hanbit Media, Inc.
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 지영옹 FreeEnd
TAG jmeter

티스토리 툴바