3. 테스트 계획의 요소

3.0 테스트 계획 ¶

테스트 계획 개체에는 " 기능 테스트 " 라는 확인란이 있습니다. 선택하면 JMeter가 각 샘플에 대해 서버에서 반환된 데이터를 기록합니다. 테스트 리스너에서 파일을 선택한 경우 이 데이터가 파일에 기록됩니다. 이것은 JMeter가 올바르게 구성되고 서버가 예상 결과를 반환하는지 확인하기 위해 소규모 실행을 수행하는 경우에 유용할 수 있습니다. 그 결과 파일이 빠르게 커지고 JMeter의 성능이 저하됩니다. 스트레스 테스트를 수행하는 경우 이 옵션이 꺼져 있어야 합니다(기본적으로 꺼져 있음).

데이터를 파일에 기록하지 않는 경우 이 옵션은 차이가 없습니다.

리스너의 구성 버튼을 사용 하여 저장할 필드를 결정할 수도 있습니다.

3.1 스레드 그룹 ¶

스레드 그룹 요소는 모든 테스트 계획의 시작점입니다. 모든 컨트롤러와 샘플러는 스레드 그룹 아래에 있어야 합니다. Listeners와 같은 다른 요소는 테스트 계획 바로 아래에 배치될 수 있으며, 이 경우 모든 스레드 그룹에 적용됩니다. 이름에서 알 수 있듯이 스레드 그룹 요소는 JMeter가 테스트를 실행하는 데 사용할 스레드 수를 제어합니다. 스레드 그룹에 대한 컨트롤을 사용하면 다음을 수행할 수 있습니다.

• 스레드 수 설정
• 램프 업 기간 설정
• 테스트 실행 횟수 설정

각 스레드는 다른 테스트 스레드와 완전히 독립적으로 테스트 계획을 실행합니다. 다중 스레드는 서버 애플리케이션에 대한 동시 연결을 시뮬레이션하는 데 사용됩니다.

램프 업 기간은 선택한 스레드의 전체 수로 "램프 업"하는 데 걸리는 시간을 JMeter에 알려줍니다. 10개의 스레드가 사용되고 램프업 기간이 100초인 경우 JMeter는 10개의 스레드를 모두 가동하고 실행하는 데 100초가 걸립니다. 각 스레드는 이전 스레드가 시작된 후 10(100/10)초 후에 시작됩니다. 스레드가 30개이고 램프업 기간이 120초인 경우 각 연속 스레드는 4초씩 지연됩니다.

램프업은 테스트 시작 시 너무 큰 작업 부하를 피하기 위해 충분히 길어야 하고, 첫 번째 스레드가 완료되기 전에 마지막 스레드가 실행을 시작하도록 충분히 짧아야 합니다(원하는 경우 제외).

Ramp-up = 스레드 수로 시작하고 필요에 따라 위 또는 아래로 조정합니다.

기본적으로 스레드 그룹은 해당 요소를 한 번만 반복하도록 구성됩니다.

스레드 그룹은 스레드 수명 을 지정할 수도 있습니다 . 스레드 그룹 패널 하단에 있는 확인란을 클릭하여 테스트 기간 및 시작 지연을 입력할 수 있는 추가 필드를 활성화/비활성화합니다. Duration(초) 및 Startup Delay(초) 를 구성 하여 각 스레드의 기간을 제어할 수 있습니다. 그룹 및 몇 초 후에 시작되는지. 테스트가 시작되면 JMeter는 스레드 그룹의 스레드를 시작하기 전에 시작 지연(초) 을 기다리고 구성된 기간(초) 시간 동안 실행합니다.

3.2 컨트롤러 ¶

JMeter에는 샘플러와 논리 컨트롤러의 두 가지 유형의 컨트롤러가 있습니다. 이것들은 테스트 처리를 주도합니다.

샘플러는 JMeter에게 서버에 요청을 보내도록 지시합니다. 예를 들어, JMeter가 HTTP 요청을 보내도록 하려면 HTTP 요청 샘플러를 추가하십시오. 샘플러에 하나 이상의 구성 요소를 추가하여 요청을 사용자 정의할 수도 있습니다. 자세한 내용은 샘플러 를 참조하십시오 .

논리 컨트롤러를 사용하면 JMeter가 요청을 보낼 시기를 결정하는 데 사용하는 논리를 사용자 지정할 수 있습니다. 예를 들어 Interleave Logic Controller를 추가하여 두 개의 HTTP 요청 샘플러를 교체할 수 있습니다. 자세한 내용은 논리 컨트롤러 를 참조하십시오 .

3.2.1 샘플러 ¶

샘플러는 JMeter에게 서버에 요청을 보내고 응답을 기다리라고 지시합니다. 트리에 나타나는 순서대로 처리됩니다. 컨트롤러는 샘플러의 반복 횟수를 수정하는 데 사용할 수 있습니다.

JMeter 샘플러에는 다음이 포함됩니다.

• FTP 요청
• HTTP 요청(SOAP 또는 REST 웹 서비스에도 사용할 수 있음)
• JDBC 요청
• 자바 객체 요청
• JMS 요청
• JUnit 테스트 요청
• LDAP 요청
• 메일 요청
• OS 프로세스 요청
• TCP 요청

동일한 유형의 여러 요청(예: HTTP 요청)을 동일한 서버에 보내려는 경우 기본 구성 요소 사용을 고려하십시오. 각 컨트롤러에는 하나 이상의 Defaults 요소가 있습니다(아래 참조).

테스트 계획에 리스너를 추가하여 요청 결과를 보거나 디스크에 저장하는 것을 잊지 마십시오.

JMeter가 요청 응답에 대한 기본 유효성 검사를 수행 하도록 하려면 샘플러 에 Assertion 을 추가하십시오. 예를 들어, 웹 애플리케이션 스트레스 테스트에서 서버는 성공적인 "HTTP 응답" 코드를 반환할 수 있지만 페이지에 오류가 있거나 섹션이 누락될 수 있습니다. 특정 HTML 태그, 일반적인 오류 문자열 등을 확인하기 위해 어설션을 추가할 수 있습니다. JMeter를 사용하면 정규 표현식을 사용하여 이러한 어설션을 만들 수 있습니다.

JMeter의 내장 샘플러

3.2.2 로직 컨트롤러 ¶

로직 컨트롤러를 사용하면 JMeter가 요청을 보낼 시기를 결정하는 데 사용하는 로직을 사용자 지정할 수 있습니다. 논리 컨트롤러는 자식 요소에서 오는 요청의 순서를 변경할 수 있습니다. 그들은 요청 자체를 수정하고 JMeter가 요청을 반복하도록 할 수 있습니다.

테스트 계획에 대한 논리 컨트롤러의 영향을 이해하려면 다음 테스트 트리를 고려하십시오.

• 테스트 계획
• 스레드 그룹
• 한 번만 컨트롤러
• 로그인 요청( HTTP 요청 )
• 검색 페이지 로드(HTTP 샘플러)
• 인터리브 컨트롤러
• "A" 검색(HTTP 샘플러)
• "B" 검색(HTTP 샘플러)
• HTTP 기본 요청(구성 요소)
• HTTP 기본 요청(구성 요소)
• 쿠키 관리자(구성 요소)

이 테스트의 첫 번째 사항은 로그인 요청이 처음에만 실행된다는 것입니다. 후속 반복에서는 건너뜁니다. 이것은 Once Only Controller 의 효과 때문 입니다.

로그인 후 다음 샘플러는 검색 페이지를 로드합니다(사용자가 로그인한 다음 검색을 수행하기 위해 검색 페이지로 이동하는 웹 애플리케이션을 상상해 보세요). 이것은 로직 컨트롤러를 통해 필터링되지 않은 단순한 요청입니다.

검색 페이지를 로드한 후 검색을 하고 싶습니다. 사실, 우리는 두 가지 다른 검색을 하고 싶습니다. 그러나 각 검색 사이에 검색 페이지 자체를 다시 로드하려고 합니다. 4개의 간단한 HTTP 요청 요소(로드 검색, 검색 "A", 로드 검색, 검색 "B")를 사용하여 이를 수행할 수 있습니다. 대신 테스트를 통해 매번 하나의 하위 요청을 전달 하는 Interleave Controller 를 사용합니다. 자식 요소의 순서를 유지합니다(즉, 무작위로 전달하지 않지만 해당 위치를 "기억"함). 2개의 하위 요청을 인터리빙하는 것은 과잉일 수 있지만 쉽게 8개 또는 20개의 하위 요청이 있을 수 있습니다.

HTTP 요청 기본값 참고Interleave Controller에 속합니다. "검색 A"와 "검색 B"가 동일한 PATH 정보를 공유한다고 상상해 보십시오(HTTP 요청 사양에는 도메인, 포트, 메서드, 프로토콜, 경로 및 인수와 기타 선택적 항목이 포함됨). 이것은 의미가 있습니다. 둘 다 동일한 백엔드 검색 엔진(서블릿 또는 cgi 스크립트, 예를 들어)을 치는 검색 요청입니다. PATH 필드에 동일한 정보를 사용하여 두 HTTP 샘플러를 모두 구성하는 대신 해당 정보를 단일 구성 요소로 추상화할 수 있습니다. Interleave 컨트롤러가 "검색 A" 또는 "검색 B"의 요청을 "전달"할 때 HTTP 기본 요청 구성 요소의 값으로 공백을 채웁니다. 따라서 이러한 요청에 대해 PATH 필드를 비워 둡니다. 그리고 그 정보를 구성 요소에 넣습니다. 이 경우, 이것은 기껏해야 사소한 이점이지만 기능을 보여줍니다.

트리의 다음 요소는 이번에는 스레드 그룹 자체에 추가된 또 다른 HTTP 기본 요청입니다. Thread Group에는 Logic Controller가 내장되어 있으므로 위에서 설명한 대로 정확히 이 Configuration Element를 사용합니다. 통과하는 요청의 공백을 채웁니다. 웹 테스트에서 모든 HTTP 샘플러 요소에서 DOMAIN 필드를 비워두고 대신 해당 정보를 스레드 그룹에 추가된 HTTP 기본 요청 요소에 넣는 것이 매우 유용합니다. 이렇게 하면 테스트 계획에서 한 필드를 변경하기만 하면 다른 서버에서 애플리케이션을 테스트할 수 있습니다. 그렇지 않으면 모든 샘플러를 편집해야 합니다.

마지막 요소는 HTTP 쿠키 관리자 입니다. 쿠키 관리자는 모든 웹 테스트에 추가되어야 합니다. 그렇지 않으면 JMeter가 쿠키를 무시합니다. 스레드 그룹 수준에서 추가하여 모든 HTTP 요청이 동일한 쿠키를 공유하도록 합니다.

로직 컨트롤러를 결합하여 다양한 결과를 얻을 수 있습니다. 내장 로직 컨트롤러 목록을 참조하십시오 .

3.2.3 테스트 조각 ¶

Test Fragment 요소는 Thread Group 요소와 동일한 수준의 테스트 계획 트리에 존재 하는 특수 유형의 컨트롤러 입니다. 모듈 컨트롤러 또는 Include_Controller 에서 참조하지 않는 한 실행되지 않는다는 점에서 스레드 그룹과 구별됩니다 .

이 요소는 순전히 테스트 계획 내에서 코드 재사용을 위한 것입니다.

3.3 리스너 ¶

리스너는 JMeter가 실행되는 동안 JMeter가 테스트 케이스에 대해 수집하는 정보에 대한 액세스를 제공합니다. 그래프 결과 수신기 는 그래프에 응답 시간을 표시합니다. "결과 트리 보기" 리스너는 샘플러 요청 및 응답의 세부 정보를 표시하고 응답의 기본 HTML 및 XML 표현을 표시할 수 있습니다. 다른 수신기는 요약 또는 집계 정보를 제공합니다.

또한 리스너는 나중에 사용할 수 있도록 데이터를 파일로 보낼 수 있습니다. JMeter의 모든 리스너는 데이터를 저장할 파일을 나타내는 필드를 제공합니다. 저장할 필드와 CSV 또는 XML 형식을 사용할지 여부를 선택하는 데 사용할 수 있는 구성 버튼도 있습니다.

리스너는 테스트 계획 바로 아래를 포함하여 테스트의 모든 위치에 추가할 수 있습니다. 해당 수준 이하의 요소에서만 데이터를 수집합니다.

JMeter와 함께 제공 되는 여러 리스너 가 있습니다.

3.4 타이머 ¶

기본적으로 JMeter 스레드는 일시 중지하지 않고 샘플러를 순서대로 실행합니다. 스레드 그룹에 사용 가능한 타이머 중 하나를 추가하여 지연을 지정하는 것이 좋습니다. 지연을 추가하지 않으면 JMeter가 매우 짧은 시간에 너무 많은 요청을 만들어 서버를 압도할 수 있습니다.

타이머는 JMeter가 해당 범위 에 있는 각 샘플러 전에 특정 시간을 지연시키도록 합니다 .

스레드 그룹에 두 개 이상의 타이머를 추가하도록 선택하면 JMeter는 타이머가 적용되는 샘플러를 실행하기 전에 타이머의 합계를 가져와 해당 시간 동안 일시 중지합니다. 타이머가 적용되는 샘플러를 제한하기 위해 타이머를 샘플러 또는 컨트롤러의 자식으로 추가할 수 있습니다.

테스트 계획의 한 위치에서 일시 중지를 제공하기 위해 Flow Control Action Sampler를 사용할 수 있습니다.

3.5 주장 ¶

주장을 사용하면 테스트 중인 서버에서 받은 응답에 대한 사실을 주장할 수 있습니다. 어설션을 사용하면 기본적으로 애플리케이션이 예상한 결과를 반환하는지 "테스트"할 수 있습니다.

예를 들어 쿼리에 대한 응답에 특정 텍스트가 포함될 것이라고 주장할 수 있습니다. 지정한 텍스트는 Perl 스타일 정규식일 수 있으며 응답에 텍스트가 포함되거나 전체 응답과 일치해야 함을 나타낼 수 있습니다.

모든 샘플러에 어설션을 추가할 수 있습니다. 예를 들어, " </HTML> " 텍스트를 확인하는 HTTP 요청에 어설션을 추가할 수 있습니다. 그런 다음 JMeter는 텍스트가 HTTP 응답에 있는지 확인합니다. JMeter가 텍스트를 찾을 수 없으면 이를 실패한 요청으로 표시합니다.

어설션 결과를 보려면 스레드 그룹에 어설션 리스너를 추가하십시오. 실패한 어설션은 트리 보기 및 테이블 리스너에도 표시되며 집계 및 요약 보고서와 같은 오류 %age에 포함됩니다.

3.6 구성 요소 ¶

구성 요소는 샘플러와 밀접하게 작동합니다. 요청을 보내지는 않지만( HTTP(S) 테스트 스크립트 레코더 제외 ) 요청을 추가하거나 수정할 수 있습니다.

구성 요소는 요소를 배치한 트리 분기 내부에서만 액세스할 수 있습니다. 예를 들어 단순 논리 컨트롤러 내부에 HTTP 쿠키 관리자를 배치하면 쿠키 관리자는 단순 논리 컨트롤러 내부에 배치한 HTTP 요청 컨트롤러에서만 액세스할 수 있습니다(그림 1 참조). 쿠키 관리자는 HTTP 요청 "웹 페이지 1" 및 "웹 페이지 2"에 액세스할 수 있지만 "웹 페이지 3"에는 액세스할 수 없습니다.

또한 트리 분기 내부의 구성 요소는 "상위" 분기의 동일한 요소보다 우선 순위가 높습니다. 예를 들어, "Web Defaults 1" 및 "Web Defaults 2"라는 두 개의 HTTP 요청 기본값 요소를 정의했습니다. 루프 컨트롤러 내부에 "Web Defaults 1"을 배치했기 때문에 "Web Page 2"만 액세스할 수 있습니다. 다른 HTTP 요청은 스레드 그룹(다른 모든 분기의 "상위")에 배치했기 때문에 "Web Defaults 2"를 사용합니다.

3.7 전처리기 요소 ¶

전처리기는 샘플러 요청이 이루어지기 전에 일부 작업을 실행합니다. 전처리기가 Sampler 요소에 연결되어 있으면 해당 샘플러 요소가 실행되기 직전에 실행됩니다. 전처리기는 샘플 요청이 실행되기 직전에 설정을 수정하거나 응답 텍스트에서 추출되지 않은 변수를 업데이트하는 데 가장 자주 사용됩니다. 전처리기가 실행되는 시기에 대한 자세한 내용 은 범위 지정 규칙 을 참조하세요.

3.8 포스트 프로세서 요소 ¶

포스트 프로세서는 샘플러 요청이 이루어진 후 몇 가지 작업을 실행합니다. Post-Processor가 Sampler 요소에 연결되어 있으면 해당 sampler 요소가 실행된 직후에 실행됩니다. 후처리기는 응답 데이터를 처리하는 데 가장 자주 사용되며, 종종 응답 데이터에서 값을 추출하는 데 사용됩니다. 포스트 프로세서가 실행되는 시기에 대한 자세한 내용 은 범위 지정 규칙 을 참조하세요.

3.9 실행 순서 ¶

0. 구성 요소
1. 전처리기
2. 타이머
3. 샘플러
4. 후처리기(SampleResult가 null 인 경우 제외 )
5. 어설션(SampleResult가 null 이 아닌 경우 )
6. 리스너(SampleResult가 null 인 경우 제외 )

예를 들어 다음 테스트 계획에서:

• 제어 장치
• 포스트 프로세서 1
• 샘플러 1
• 샘플러 2
• 타이머 1
• 주장 1
• 전처리기 1
• 타이머 2
• 포스트 프로세서 2

전처리기 1
타이머 1
타이머 2
샘플러 1
포스트 프로세서 1
포스트 프로세서 2
주장 1

전처리기 1
타이머 1
타이머 2
샘플러 2
포스트 프로세서 1
포스트 프로세서 2
주장 1

3.10 범위 지정 규칙 ¶

JMeter 테스트 트리에는 계층적이고 순서가 지정된 요소가 포함되어 있습니다. 테스트 트리의 일부 요소는 엄격하게 계층적이며(리스너, 구성 요소, 후처리기, 전처리기, 주장, 타이머) 일부는 주로 순서가 지정됩니다(컨트롤러, 샘플러). 테스트 계획을 생성할 때 실행할 일련의 단계를 나타내는 샘플 요청의 정렬된 목록(샘플러를 통해)을 생성합니다. 이러한 요청은 종종 또한 주문된 컨트롤러 내에서 구성됩니다. 다음 테스트 트리가 주어집니다.

요청 순서는 하나, 둘, 셋, 넷입니다.

일부 컨트롤러는 하위 요소의 순서에 영향을 미치며 구성 요소 참조 에서 이러한 특정 컨트롤러에 대해 읽을 수 있습니다 .

다른 요소는 계층적입니다. 예를 들어 Assertion은 테스트 트리에서 계층적입니다. 부모가 요청이면 해당 요청에 적용됩니다. 부모가 컨트롤러인 경우 해당 컨트롤러의 하위 항목인 모든 요청에 ​​영향을 줍니다. 다음 테스트 트리에서:

주장 #1은 요청 1에만 적용되고 주장 #2는 요청 2와 3에 적용됩니다.

이번에는 타이머를 사용하는 또 다른 예:

이 예에서 요청은 실행되는 순서를 반영하도록 이름이 지정됩니다. 타이머 #1은 요청 2, 3 및 4에 적용됩니다(순서가 계층적 요소와 관련이 없다는 점에 유의하십시오). 주장 #1은 요청 3에만 적용됩니다. 타이머 #2는 모든 요청에 ​​영향을 미칩니다.

이러한 예를 통해 구성(계층적) 요소가 적용되는 방식이 명확해지기를 바랍니다. 각 요청이 트리 분기를 통해 부모에게 전달된 다음 부모의 부모 등으로 전달되고 매번 해당 부모의 모든 구성 요소를 수집한다고 상상하면 어떻게 작동하는지 알 수 있습니다.

3.11 속성과 변수 ¶

JMeter 속성 은 jmeter.properties 에 정의되어 있습니다 (자세한 내용은 시작하기 - JMeter 구성 참조).
속성은 jmeter에 전역적이며 대부분 JMeter가 사용하는 기본 설정을 정의하는 데 사용됩니다. 예를 들어 remote_hosts 속성 은 JMeter가 원격으로 실행하려고 시도할 서버를 정의합니다. 속성은 테스트 계획에서 참조할 수 있습니다( 함수 참조 - 속성 읽기). 그러나 스레드별 값에는 사용할 수 없습니다.

JMeter 변수 는 각 스레드에 대해 로컬입니다. 값은 각 스레드에 대해 동일하거나 다를 수 있습니다.
스레드에 의해 변수가 업데이트되면 변수의 스레드 복사본만 변경됩니다. 예를 들어 정규식 추출기 포스트 프로세서는 스레드가 읽은 샘플에 따라 변수를 설정하고 나중에 동일한 스레드에서 사용할 수 있습니다. 변수 및 함수를 참조하는 방법에 대한 자세한 내용은 함수 및 변수 를 참조하십시오.

테스트 계획 및 사용자 정의 변수 구성 요소에 의해 정의된 값 은 시작 시 전체 테스트 계획에서 사용할 수 있습니다. 동일한 변수가 여러 UDV 요소에 의해 정의된 경우 마지막 변수가 적용됩니다. 스레드가 시작되면 초기 변수 세트가 각 스레드에 복사됩니다. 사용자 매개변수 전처리기 또는 정규식 추출기 후처리기 와 같은 다른 요소 를 사용하여 동일한 변수를 재정의하거나 새 변수를 생성할 수 있습니다. 이러한 재정의는 현재 스레드에만 적용됩니다.

setProperty 함수는 JMeter 속성을 정의하는 데 사용할 수 있습니다 . 이것들은 테스트 계획에 대해 전역적이므로 필요한 경우 스레드 간에 정보를 전달하는 데 사용할 수 있습니다.

3.12 변수를 사용하여 테스트 매개변수화 ¶

변수는 다양할 필요가 없습니다. 한 번만 정의할 수 있으며 그대로 두면 값이 변경되지 않습니다. 따라서 테스트 계획에서 자주 나타나는 표현의 약어로 사용할 수 있습니다. 또는 실행 중에는 일정하지만 실행 간에 다를 수 있는 항목의 경우. 예를 들어, 호스트 이름 또는 스레드 그룹의 스레드 수입니다.

테스트 계획을 구성하는 방법을 결정할 때 실행에 대해 일정하지만 실행 간에 변경될 수 있는 항목을 기록해 두십시오. 이들에 대한 몇 가지 변수 이름을 결정하십시오 - 아마도 C_ 또는 K_ 접두사 를 사용하거나 테스트 중에 변경해야 하는 변수와 구별하기 위해 대문자만 사용 하는 것과 같은 명명 규칙을 사용하십시오. 또한 스레드에 대해 로컬이어야 하는 항목(예: 정규식 포스트 프로세서로 추출된 카운터 또는 값)을 고려하십시오. 이들에 대해 다른 명명 규칙을 사용할 수 있습니다.

예를 들어 테스트 계획에서 다음을 정의할 수 있습니다.

호스트 www.example.com
스레드 10
루프 20

호스트 ${__P(호스트,www.example.com)}
스레드 ${__P(스레드,10)}
루프 ${__P(루프,20)}

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