[Load Test]Apache JMeter User's Manual - 3. Elements of a Test Plan

매번 설치해서 테스트를 해보겠다 해보겠다 했는데, 자꾸 미뤄서, 이번 테스트 할때를 기회삼아서,

jMeter에 대해서 설치부터 전체적인 테스트 플랜 짜는 것과 JMeter 구동하는 것까지 전체적으로 정리를 해보도록 합니다.

reference가 잘 나와 있기 때문에, 발!!! 번역을 하면서 하나씩 테스트 해보도록 합니다. 

http://jmeter.apache.org/usermanual/test_plan.html

---

3. Elements of aTest Plan

이번 섹션에서는 Test Plan의 또 다른 부분을 설명합니다.

최소의 테스트는 Test Plan , Thread Group 과 하나 이상의 Sampler들로 구성됩니다.

3.0 Test Plan

Test Plan 객체는 "Functional Testing" 이라는 체크박스를 가지고 있습니다.

이걸 선택시, 각각의 샘플에 대해 서버에서 리턴받은 데이터를 JMeter가 저장하게 됩니다

테스트 Listener안에 있는 파일을 선택하면, 그 파일에 이 데이터가 저장될 것입니다.

이 방법은 JMeter가 정확하게 구성되었고, 서버가 예측한 결과를 리턴하고 있다는 것을 

확실하게 체크하도록 작게 기동할 목적이라면 아주 유용합니다.

지속적 진행하게 되면  그 파일은 순간적으로 커지고, JMeter의 성능은 급격히 떨어지게 될것 입니다.

혹시 스트레스 테스트를 하고 있다면 이 옵션을 끄는 것이 좋습니다. (꺼져있는 것이 옵션입니다.)

파일에 데이터를 기록하고 있지 않다면,이 옵션을 아무런 소용이 없죠 

어떤 필드들을 저장할지 결정하기 위해 Listener상에 Configuration 버튼을 사용 할 수도 있습니다.

3.1 Thread Group

Thread Group 구성요소는 모든 Test Plan에 있어서 시발점입니다.

모든 Controller와 Sampler들은 Thread Group 이하에 있습니다.

다른 구성 요소들, 예를 들어 Listener들은 Test Plan 아래 직접 놓여질 것입니다. 

이 경우에 Listener들은 모든 Thread Group에 적용될 것입니다. 

이름에서 암시하듯이, Thread Group 구성요소는 여러분의 테스트를 실행하는데 사용되는 JMeter Thread들의 개수를 조절합니다.

이 Thread Group에 대한 조절은 다음과 같이 가능하게 합니다.

• Thread들의 숫자 설정
• ramp-up period 설정
• 테스트을 실행하기 위한 시간의 숫자 설정

Thread는 각각의 Thread 안에서 다른 테스트 Thread들과는 와전히 독립적인 Test Plan을 실행 합니다.

다수의 Thread들은 여러분의 서버 어플리케이션에 동시접속을 시뮬레이션하는데 사용됩니다. 

ramp-up peroid 는 JMeter에게 선택된 완전한 Thread 숫자에 "ramp-up"하기 위해 얼마나 걸릴지를 전달합니다.

10 Thread, ramp-up period는 100 초이면,

JMeter는 모든 10개의 Thread가 올라와서 구동하는 것까지 100초를 쓸겁니다. 

각각의 Thread는 이전 Thread가 시작된 후에  10초(100/10)를 시작할 것입니다. 

30 Thread, ramp-up period 가 120초 이면, 

각각의 성공적인 Thread는 4초(120/30)마다 지연 될 것 입니다.

Ramp-up은 테스트 시작시에 너무 큰 작업-부하(work-load)을 피하기 위해 충분히 길게 잡아 주는 것이 필요하고,

첫번째 Thread가 끝나기 전(그런 일이 일어나지 않는 한)에  마지막 Thread 시작이 실행하는 것은 충분히 짧아야 합니다.

Start with Ramp-up = Thread 수  그리고 필요하면 위 아래 조정 

기본적으로 Thread Group은 자신의 구성요소들을 통해 한번 돌도록 구성됩니다.

Thread Group은 Scheduler를 제공합니다.

Thread Group 패널의 하단에서 테스트의 기간, startup delay, 실행의 시작과 끝 시작을 입력할수 있는 

추가적인 필드의 활성/비활성하기 위해 체크 박스를 클릭하시면 됩니다.

Duration (seconds)과 각각의 Thread Group의 기간과 몇만큼의 시작 후에 시작할지를 컨트롤 하기 위한

Startup Delay(Seconds) 를 구성할수 있습니다.

기억할 점은 이들 두개 옵션은 Start time 과 End time을 Override 합니다.

또는 (아주 다루기 쉽지 않은 만큼 추천하지 않지만) 두개의 다른 필드인 Start time 과 End time 을 사용할 수 있습니다. 

테스트가 시작될때, JMeter는 start-time에 도달할 때까지 필요하다면 기다릴 것입니다.

각각의 사이클의 끝에, JMeter는 end-time이 도달하는지를 체크하고, 도달했다면, 실행을 멈출것입니다. 

그렇지 않으면, 반복  제한이  도달할때 까지 테스트는 계속되는 것이 허가됩니다.

3.2 Controllers

JMeter는 두가지 Controller 타입을 가지고 있습니다. : Sampler 와 Logical Controller 입니다.

이둘은  테스트의 처리를 진행합니다.

Sampler는 JMeter에게 request를 서버로 보내라고 요청합니다.

예를들어,  HTTP Request Sampler를 추가합니다. JMeter가 HTTP Request를 보내길 원한다면.

Sampler에 Configuration Elements 을 추가함으로  request를 커스터마이징 할수 있습니다.

보다 자세한 내용은 Sampler를 참고하시길 바라는데... 뭐 아래 바로 나옵니다.

Logical Controller는 JMeter가 request을 보낼 때를 결정하는데 사용하는 로직을 커스터마이징 하게 합니다.

예를 들어, 두개의 HTTP Request Sampler 사이에서 번갈아 발송 하기 위해 , Interleave Logical Controller를 추가할수 있습니다.

보다 자세한 내용은 Logical Controller를 참고하면 되는데, 이것도 바로 설명이 나옵니다.

3.2.1. Samplers

Sampler는 Jmeter에게 서버에 요청을 보내도록 전달하고, 응답을 기다립니다.

트리에 나타는 순서대로 처리됩니다. Controller는 Sampler의 반복 숫자를 수정하는데 사용될수 있습니다.

JMeter Sampler는 다음을 포함합니다.

• FTP Request
• HTTP Request ( SOAP 나 REST 웹서비스에도 사용할수 있습니다.)
• JDBC Request
• Java object request
• JMS request
• JUnit Test request
• LDAP Request
• Mail request
• OS Process request
• TCP request

각각의 Sampler는 설정 가능한 몇가지 프로퍼티들을 가지고 있습니다.

Test Plan에 한개 이상의 Configuration Element를 추가해서 sampler를 좀더 커스터마이징 할수 있습니다.

같은 타입의 다수의 요청들을 같은 서버에 보낼꺼라면 (예를 들면 HTTP request) ,

Defatils Configuration Element를 사용하는 것을 생각해보세요.

각각의 Controller는 하나 혹은 그 이상의 Defaults 구성요소를 갖습니다.

요청 결과를 디스크에 저장하거나 보기 위해 여러분의 Test Plan에 Listener를 추가하는 것을 기억하세요

요청에 대한 응답에 JMeter performance basic validation을 갖는것에 관심이 있다면, 

Sampler에 Assertion을 추가하세요.

예를 들어, 웹 어플리케이션에 대한 스트레스 테스트상에 , 

서버가 성공적인 "HTTP Response" 코드를 리턴하겠지만, 페이지는 그것에 대한 에러들을 갖거나 섹션을 놓칠수도 있습니다.

확실한 HTML 태그, common error strings, 등등 에 대한 체크를 하기 위한 assertions을 추가 할수 있습니다.

JMeter는 이런 assertions을 정규식을 사용하여 생성할수 있게 합니다.

3.2.2 Logic Controllers

Logic Controller는 JMeter가 요청을 보낼때를 결정하는데 사용하는 로직을 커스터마이징 가능하게 합니다.

Logic Controller는 자식 구성요소로 부터 들어오는 요청들의 순서를 변경할수 있습니다.

요청 자체를 수정할 수 있고, JMeter가 요청을 반복하도록 할 수 있습니다.

Test Plan에서 Logic Controller들의 효과를 이해하기 위해서,

다음 테스트 트리를 고려해봅니다.

• Test Plan
• Thread Group
• Once Only Controller
• Login Request(an HTTP Request)
• Load Search Page(HTTP Sampler)
• Interleave Controller
• Search "A" (HTTP Sampler)
• Search "B" (HTTP Sampler)
• HTTP default request (Configuration Element)
• HTTP default request(Configuration Element)
• Cookie Manager (Configuration Element)

첫번째 것은 로그인 요청을 테스트 하는 것으로 처음 한번만 실행됩니다.

그 다음 반복에서는 건너뛰는 것이죠, Once Only Controller의 효과 덕택입니다.

로그인 후에, 다음 Sampler는 search page를 로드합니다.

(사용자 로그인하고 검색 하기 위해 검색 페이지로 가는 어플리케이션을 상상해보세요).

이건 단지 간단한 요청입니다. 어떤 Logic Controller를 통해 필터된것이 아닙니다.

검색 페이지가 로드된 후에, 우린 검색을 원하고, 두가지 다른 검색을 하길 원합니다.

하지만, 각각의 검색 사이에 자체 검색 페이지가 리로드 하길 원합니다.

우리는 4 개의 심플 HTTP request elements을 가지고 이걸 할 수 있습니다.

(load search, search "A", load search, search "B")

하지만 그렇게 하는 것보다  Interleave Controller를 사용합니다. 

테스트를 통해 하나의 child request를 매번 전달합니다. 

자식 요소들의 순서(예를 들어 랜덤상에 하나를 통과시키지 않고, 장소를 기억합니다.)를 유지합니다.

2 child requests를 interleaving하는 것는 과잉(overkill)일지 모르지만,  8, 또는 20 child requests가 쉽게 할수 있겠습니다.

Interleave Controller에 속한 HTTP Request Details을 기억하세요

"Search A" 와 "Search B"는 같은 PATH 정보를 공유하는 것을 상상하세요.

(HTTP request 명세는 domain, port, method, protocol, path , arguments, 더해서 다른 추가적인 아이템들을 포함합니다.)

이건 말이 됩니다 - 둘다 검색요청이고, 같은 백앤드 검색 엔진을 치고(서블릿이나 cgi-script )...

PATH 필드에 같은 정보를 갖는 HTTP Samplers 둘다 구성하는 것 보단, 

우리는 그 정보를 단일 Configuration Element로 꺼내 추상화 할수 있습니다.

lnterleave Controller가 "Search A" 또는 "Search B"로 부터 requests를  통과 할때,

그건 HTTP default request configuration Element로 부터 값을 빈칸에 채울 것입니다.

그래서, 우리는 이들 요청에 대해 PATH 필드를 빈칸으로 남기고, Configuration Element  안에 정보를 남깁니다.

이경우에, 이것은 최대 사소한 이익이 있지만, 기능을 보여줍니다. 

이 트리에서 다음 구성요소는 다른 HTTP default request 입니다.

이 경우에는 Thread Group 자신에 추가했습니다.

Thread Group는 내부 Logic Controller를 갖습니다. 따라서, 위에 정의된 것으로 정확하게 이 Configuration Element를 사용합니다.

이것은 통해 전달된 어떤 요청의 빈칸을 채워 넣습니다.

그것은 DOMAIN 필드를 모든 여러분의 HTTP Sample 구성요소에 빈값으로 남기 위해 웹 테스팅에서 아주 유용합니다.

그리고 대신에  HTTP Sampler element 안에 해당 정보를 넣고, Thread Group 안에 추가합니다.

그렇게 함으로써, 여러분은 간단히 여러분의 Test Plan에 한 필드를 변경함으로써 

다른 서버에 여러분의 어플리케이션을 테스트 할수 있습니다.

그렇지 않으면, 각각 모든 Sampler를 수정해야할 것입니다.

마지막 요소는 HTTP Cookie Manager 입니다.

쿠키 매니저는 모든 웹 테스트상에 추가해야합니다. JMeter가 쿠키를 무시할지라도 추가해야합니다.

쿠키 레벨에 그것을 추가함으로, 우리는 모든 HTTP 요청들을 같은 쿠키에 공유 할수 있것이란것 확실히 할수 있습니다.

Logic Controller는 다양한 결과를 얻기 위해 결합될수 있습니다.

built-in Logic Controller의 목록을 보세요 

http://jmeter.apache.org/usermanual/component_reference.html#logic_controllers

3.2.3 Test Fragments

Test Fragment 구성요소는 Thread Group 구성요소로써  

같은 레벨에서 Test Plan 트리에 존재하는 특별한 타입의 Controller 입니다.

Module Controller 나 Include_Controller 둘중에 하나에 의해 참조되지 않는한,  

실행되지 않는 것에서는 Thread Group과는 구별됩니다.

이 요소는 순수하게 Test Plan 안에서 재사용되는 코드를 위한것입니다.

3.3 Listeners 

Listener는 JMeter가 실행되는 동안 JMeter가 테스트 케이스에 대해서 모은 정보에 대한 접근을 제공합니다. 

Graph Results listener는 그래프에 응답 시간을 그린다고해야하나? 암튼 플롯(plot)합니다.

"View Results Tree" Listener는 Sampler의 요청과 응답의 상세를 보여주고, 

응답의 기본 HTML 과 XML 표현을 보여줄수 있습니다.

다른 Listener들은 요약이나 집합 정보를 제공합니다.

추가적으로, Listener들은 이후에 사용하기 위해 파일에 데이터를 가르키기도 합니다.

JMeter에서 모든 Listener들은 데이터를 저장할 파일을 지정하는 필드를 제공합니다.

또한 구성 버튼이 있습니다.

그건 이 필드가 저장하고 CSV 나 XML 포멧을 사용할지 말지에 대해서 선택하는데 사용할수 있습니다.

주의할것은 모든 Listener는 같은 데이터를 저장합니다. 

다른점은 화면에서 그 데이터를 어떻게 뿌리느냐 입니다.

테스트에서 Listener는 Test Plan 이하 직접 포함된  어디든지 추가할수 있습니다. 

해당 레벨 또는 아래 구성요소로 부터 데이터를 수집할 것입니다.

JMeter에서 제공하는 추가적인 Listener들은 아래 링크를 보시길 바랍니다.

http://jmeter.apache.org/usermanual/component_reference.html#listeners

3.4 Timers

기본적으로, JMeter Thread는 한 시퀀스에서 중지없이 Sampler들을 실행합니다.

여러분의 Thread Group에 가능한 타이머중에 하나를 추가해서 지연을 명시하는 것을 강추합니다.

지연을 추가하지 않으면,너무 많은 요청들을 매우 짧은 시간내에 만들어서.

 JMeter는 여러분의 서버를 압도(overwhelm),전복될 수 있을 겁니다.

타이머는 JMeter에 그 범위에 있는 각각의 Sampler 앞에 확실한 시간의 양의 지연을 제공합니다.

만약 Thread Group에 타이머 하나 이상 추가하는 것을 선택하면, 

JMeter는 timer의 합을 취하고 타이머가 적용된것에 Sampler들이 실행하기 전에 그 시간의 양동안 멈춥니다.

타이머는 sampler 나 controller의 자식으로 추가할수 있습니다.  타이머가 적용된 것에 Sampler를 제한하기 위해서

Test Plan에서 single place에 중지를 제공하기 위해서는,  Test Action Sampler를 사용할수 있습니다. 

3.5 Assertions

Assertions 은 테스트중인 서버로부터 받은 응답에 관한 사실들을 주장하도록 합니다.

assertion을 사용하는 것은, 필수적으로 어플리케이션이 

예상한 결과를 리턴하고 있다라는 "test"를 할수 있습니다. 

 

예를 들어, 여러분은 query에 대한 응답이 몇몇 특정 문자을 포함할것이라고 주장할수 있습니다.

여러분이 명시한 그 문자는 Perl-style 정규식일수 있고,  그 응답은 그 문자를 포함하기 위한 것 이나, 

전체 응답과 매칭되어야 한다는 것을 가르킬수 있습니다.

어떤 Sampler에나 assertion을 추가 할수 있습니다.

예를들어, "</HTML>" 문자에 대한 체크하는 HTTP Request에 assertion을 추가할수 있습니다.

JMeter는 그때 문자가 HTTP response안에 나타나는 지를 체크할 것입니다.

만약 JMEter가 그 문자를 찾을수 없다면, failed request로 이것을 표시할 것입니다.

assertion은  해당 범위에 있는 모든 Sampler에 적용한다는 것을 기억하세요.

싱글 Sampler에 assertion을 제한하기 위해서는 sampler 의 자식으로 assertion을 추가하세요.

assertion 결과를 보기 위해서는, Thread Group에 Assertion Listener를 추가하세요.

Failed Assertion는 또한 Tree View와 Table Listeners에 나타나고, 

Summery reports와 aggresage에 예제에 대해 error %age에 대해 카운트할 것입니다. 

 

3.6. Configuration Elements

구성 요소는 Sampler와 긴밀하게 작동합니다.

request를 보내진 않더라도(HTTP(S) Test Script Recorder를 제외하고), request를 추가하거나 수정할수 있습니다.

구성 요소는 요소을 배치하는 트리 브랜치 내부에만 접근할 수 있습니다. 

예를 들어, Sample Logic Controller 안에 HTTP Cookie Manager를 배치시키면, 

Cookie Manager는 Simple Logic Controller 안에 배치한 HTTP Request Controller에만 접근할수 있습니다.

Cookie Manager는 HTTP requests "Web Page 1" 과 "Web Page 2"에 접근할수 있으나,

"Web Page 3"에는 접근할수 없습니다.

또한, 트리  브랜치 안에 구성 요소가 "부모" 브랜치안에 같은 요소 보다 더 높은 상위(precedence)을 가지고 있습니다. 

 예를 들면, 우리는 두개의 HTTP Request Defaults 구성요소 "Web Default 1" 과 "Web Default 2"를 정의 했습니다.

Loop Contoller 안에 "Web Default 1"을 배치시키면, 오직 "Web Default 2"만 그것에 접근할수 있습니다.

Thread Group (다른 모든 브런치의 부모)안에 "Web Defaults 2"를 배치시키면, 

다른 HTTP Request는 "Web Defaults 2"를 사용할 것입니다. 

** 뭐 당연한 이야기입니다. 상위가 하위에 대한 내용에 Override 하는 개념

Figure 1 - Test Plan Showing Accessibility of  Configuration elements

User Defined Variables 구성 요소는  다릅니다.

그건 테스트의 시작에서 처리됩니다. 그걸 배치한 곳이 문제가 되질 않습니다.

간단하게 하기 위해, Thread Group의 시작에만 그 요소가 배치되는 것을 제안합니다.

3.7 Pre-Processor Elements

전처리기(Pre-Processor)는 만들고 있는 중인 Sampler Request에 앞서서 몇몇 액션을 실행합니다.

만약 Pre-Processor가 Sampler element 에 첨부되면, 그땐 해당 sampler element가 구동하는 것 이전에 실행될 것입니다.

전처리기는 Sampler Request 시작 전에  세팅을 수정하는데 대부분 종종 사용됩니다. 

또는 응답 문자로 부터 추출되지 않는 변수를 업데이트 할때 

전처리기가 실행될때에 상세를 좀 더 자세히 보고자 한다면, scoping rules를 보세요(3-10에서 설명 됩니다.)

3.8 Post-Processor Elements

후처리기(Post-Processor)는 Sampler Request가 만들어진 후에 몇몇 액션을 실행합니다.

만약 후처리기가 Sampler element에 첨부되면,  그땐 해당 sampler element가 구동된 후에 실행될 것입니다.

후처리기는 대부분 response 데이터를 처리하는데 사용되고, 종종 데이터로 부터 값을 추출하는데 사용됩니다.

후처리기가 실행될 때 상세를 좀 더 자세히 보고자 한다면 scopring rules를 보세요. (3-10에서 설명 됩니다.)

3.9 Execution order

0) Configuration elements

1) Pre-Processors

2) Timers

3) Sampler

4) Post-Processors (unless SampleResult is null)

5) Assertions (unless SampleRequest is null)

6) Listeners (unless SampleResult is null)

기억해주세요. Timers, Assertions, Pre 와 Post-Processors가 적용된곳에 sampler가 있을 경우에만 처리됩니다.

Logic Controllers 와 Samplers 는 트리에 나타난 순서대로 처리됩니다.

다른 테스트 구성요소들은 발견된 스코프와 테스트 요소의 타입에 따라서 처리됩니다.

[타입 내에서, 구성요소는 트리에 나타나는 순서대로 처리됩니다.]

예를 들어, 다음 Test Plan은 : 

• Controller
• Post-Processor 1
• Sampler 1
• Sampler 2
• Timer 1
• Assertion 1 
• Pre-Processor 1
• Timer 2
• Post-Processor 2

실행 순서는 아래와 같다

• Pre-Processor 1
• Timer 1
• Timer 2
• Sampler 1
• Post-Processor 1
• Post-Processor 2
• Assertion 1
• Pre-Processor 

3.10 Scoping Rules

JMeter 테스트 트리는 계층 과 순서 둘 다 있는 구성요소를 포함합니다.

테스트 트리안에 몇몇은 구성요소(Listener, Config Elements, Post-Processor, Pre-Processors,Assertions ,Timers)는 엄격하게 계층적이고, 몇몇 구성요소(controllers, samplers) 은 우선적으로 순차적입니다.

여러분이 Test Plan을 생성할때, 실행되는 것에 대한 단계의 셋을 나타내는 sample request(Sampler를 통해) 에 순차적인 리스트를 생성 할 것입니다.

위에 대한 요청들은 역시 순차적인 Controller들 안에서 종종 조직화 됩니다.

다음 테스트 트리가 주어졌습니다.

Example test tree

요청 순서는 One , Two , Three, Four 가 될 것입니다.

몇몇 Controller는 하위요소의 순서에 영향을 미치고 

여러분은 component reference 안에 이런 특정 Controller에 대해서 읽을수 있습니다.

http://jmeter.apache.org/usermanual/component_reference.html

다른 구성요소는 계층적입니다.

Assersion은 예를 들어, 테스트 트리에서 계층적입니다.

그것의 부모가 request 라면, 그땐 그것이 해당 request에 적용됩니다.

만일 그것의 부모가 controller 라면 그땐 해당 Controller의 자식들(descendants) 인 모든 request에  영향을 미치게 됩니다. 

다음 테스트 트리에서 

Hierarchy example

Assertion #1 은 오직 One 이라는 Request에만 적용됩니다. 

반면 Assertion #2는 Two 와 Three Requests에 적용됩니다.

또다른 예제는 Timers를 사용하는  이 time 은

complex example

이 예제에서, request들은 실행될 순서를 반영해서 이름을 지었습니다.

Timer #1은 Request Two, Three , Four 에 적용됩니다. 

(계층적 요소에  관해서 어떤 순서든지 무관하다는 것을 알아두세요)

Assertion #1은 Request Three에만 적용될 것입니다.

Timer #2 는 모든 request에 적용됩니다.

바라건데(Hopefully) 이 예제들은 어떤 구성 요소들이 적용되는지를 명확하게 해줍니다.

트리 브런치들이 부모, 그 담 부모의 부모, 등등  통과하는 각각의 Request 

그리고 그 부모의 모든 구성요수를 수집하는 각각의 시간를 생각하면, 

그땐 여러분은 어떻게 동작하는지를 알 수 있게 될것입니다.  

 

Header Manager, Cookie Manager, Authorization maner 같은 Configuration element들은

Configuration Default elements과는 다르게 다뤄집니다.

Configuration Default elements에서 세팅은 Sampler가 접근해온 값의 설정으로 결합됩니다.

하지만 Mangers로 부터 세팅은 결합되지 않습니다.

만약 한 Manager 이상은 Sampler 의 범위 안에 있을때, 

한 Manager만 사용되지만, 현재 사용할 수 있는 Manager를 특정할  방법이 없습니다.

3.11 Properties and Variables

JMeter properties는 jmeter.properties 에 정의됩니다.

Properties는 jmeter에 전역이고, 대부분은 기본 JMeter가 사용하는 일부를 정의하는데 대부분 사용합니다.

예를 들어 property remote_hosts는 JMeter가  원격에서 실행할 서버를 정의합니다.

Properties는 Test Plan에서 참조할수 있습니다.

Functions- read a property 을 보세요  - 하지만 thread-specfic 값에 대한 사용을 할 수 없습니다.

JMeter variables은 각각의 Thread에 로컬입니다.

그값은 각각의 Thread에 같을 수도 있고 다를 수도 있습니다.

변수가 Thread에 의해 업데이트 됐을땐, 변수의 Thread 카피만 변경됩니다.

예를들어, Regular Expression Extractor Post-Processor는 

그것의 Thread가 읽는 sample에 따라서 해당 변수를 설정할 것입니다. 

그리고 변수들은 같은 Thread에 의해 이후에 사용될수 있습니다.

변수들과 함수들이 어떻게 참조하는지에 대한 상세 내용은 Functions and Variables 편을 참고하세요

http://jmeter.apache.org/usermanual/functions.html

Test Plan 과 USer Defined Variables  구성요소에 의해 정의된 값은 startup 시에 전체 테스트 플렌에 사용하도록 만들어 집니다.

만약 같은 변수가 다수의 UDV 구성요소에 의해 정의되면, 그땐 마지막것만  적용됩니다.

한 Thread가 시작하면, 변수의 초기 설정은 각각의 Thread에 복사됩니다.

다른 구성요소, 예를들어 USer Parameter Pre-Processor 또는 Regular Expression Extrator Post-Processor는 같은 변수들을 재정의(또는 새로운 변수를 생성합니다.)하는데 사용할수도 있습니다.

이런 재정의된것은 현재 Thread에만 적용됩니다.

setProperty 함수는 JMeter property를 정의하는데 사용합니다.

테스트 플렌에 대해 전역이므로  thread 사이에 정보를 전달하는데 사용할수 있습니다. - should that be needed

변수와 프로퍼티 둘다 case-sensitive(대소문자를 구별) 입니다. 

3.12 Using Variables to parameterise tests

변수들은 변경하지 않아야 합니다. - 변수들을은 한번 정의 할수 있고, 홀로 남겨두면,  값은 변하지 않을 겁니다.

그래서 여러분은  Test Plan에서 자주 나타나는 표현에 대해 짧게(short-hand) 그것을 사용해야 합니다. 

또는 실행하는동안 일정 하지만, 실행간에 다를수도 있는 항목의 경우.

예를들어 host 이름이나 Thread group 에 스래드 개수들 .

Test Plan을 어떻게 구성할지를 결정할때, 

어떤 아이템이 실행시에 불변이지만, 실행간에 변경 될수 있는지를 기록해야 합니다.

이들에 대한 변수 이름을 정하세요 - 아마도 C_ 나 K_ 접두어를 붙이는 것이나 

테스트하는 동안 변경이 필요한 변수들로 부터 그것과 구별하기 위해서 소문자만 사용하는 것과 같은 네이밍 컨벤션을 사용합니다.

또한 아이템은 Thread에 로컬이 될 필요가 있다는 것을 고려하세요 

- 예를 들어 Regular Expression Post-Processor로 추출한 counters 나 values 등입니다.

여러분은 이들에 대해서 다른 네이밍 컨벤션을 하용하길 원할지도 모릅니다.

예를 들어, Test Plan상에 다음을 정의 할수도 있습니다.

HOST               www.example.com THREADS        10 LOOPS             20

Test Plan에서 ${HOST} ${THREADS} 등으로 이들을 참조할수 있습니다.

만약 이후에 host를 변경하고자  한다면, HOST 변수 값을 변경하세요.

이것은 작은 수의  테스트에 대해서는 잘 동작하지만, 많은 다른 결합들을 테스트할때는 진절머리나게 됩니다.

하나의 해결안으로 변수의 값을 정의한 property을 사용하는 것 입니다.

HOST               ${__P(hist, www.example.com)} THREADS        ${__P(threads,10)} LOOPS             ${__P(loops,20)}

다음과 같이 커맨드 라인에서 전체 값이나 부분을 변경할수 있습니다.

jmeter ... -Jhost=www3.example.org -Jloops=13