대기 시간은 로그인하는 데 걸리는 시간으로 설정됩니다.

이 샘플러를 사용하면 웹 서버에 HTTP/HTTPS 요청을 보낼 수 있습니다. 또한 JMeter가 이미지 및 기타 임베디드 리소스에 대한 HTML 파일을 구문 분석하고 이를 검색하기 위해 HTTP 요청을 보낼지 여부를 제어할 수 있습니다. 다음 유형의 포함된 리소스가 검색됩니다.

• 이미지
• 애플릿
• 스타일시트(CSS) 및 해당 파일에서 참조되는 리소스
• 외부 스크립트
• 프레임, iframe
• 배경 이미지(본체, 테이블, TD, TR)
• 배경음

기본 파서는 org.apache.jmeter.protocol.http.parser.LagartoBasedHtmlParser 입니다. " htmlparser.className " 속성을 사용하여 변경할 수 있습니다 . 자세한 내용은 jmeter.properties 를 참조하세요.

동일한 웹 서버에 여러 요청을 보내려는 경우 HTTP 요청 기본값 구성 요소를 사용하여 각 HTTP 요청에 대해 동일한 정보를 입력할 필요가 없도록 하십시오.

또는 HTTP 요청을 수동으로 추가하는 대신 JMeter의 HTTP(S) 테스트 스크립트 레코더 를 사용하여 생성할 수 있습니다. 이렇게 하면 HTTP 요청이 많거나 매개변수가 많은 요청이 있는 경우 시간을 절약할 수 있습니다.

샘플러를 정의하는 데 사용되는 세 가지 테스트 요소가 있습니다.

AJP/1.3 샘플러

Tomcat mod_jk 프로토콜 사용(Apache httpd 없이 AJP 모드에서 Tomcat 테스트 가능) AJP 샘플러는 다중 파일 업로드를 지원하지 않습니다. 첫 번째 파일만 사용됩니다.

HTTP 요청

여기에는 사용할 HTTP 프로토콜 구현을 선택하는 구현 드롭다운 상자가 있습니다.

자바

JVM에서 제공하는 HTTP 구현을 사용합니다. 이것은 HttpClient 구현과 비교하여 몇 가지 제한 사항이 있습니다. 아래를 참조하십시오.

HTTP클라이언트4

Apache HttpComponents HttpClient 4.x를 사용합니다.

공백 값

HTTP 샘플러에 대한 구현을 설정하지 않으므로 HTTP 요청 기본값이 있는 경우 또는 jmeter.properties에 정의된 jmeter.httpsampler 속성에 의존 합니다.

GraphQL HTTP 요청

이것은 동일한 샘플러를 사용하여 내부에서 자동으로 HTTP 인수로 변환하면서 GraphQL 쿼리 , 변수 및 작업 이름 을 보거나 편집하기 위한 보다 편리한 UI 요소를 제공 하는 HTTP 요청 의 GUI 변형입니다 . 이것은 HTTP/HTTPS를 통한 GraphQL 요청에 덜 편리하거나 관련이 없기 때문에 다음 UI 요소를 숨기거나 사용자 지정합니다.

• 메서드 : HTTP 사양을 통해 GraphQL을 준수하는 POST 및 GET 메서드만 사용할 수 있습니다. 기본적으로 POST 방법이 선택됩니다.
• 매개변수 및 포스트 본문 탭: 대신 쿼리, 변수 및 작업 이름 UI 요소를 통해 매개변수 내용을 보거나 편집할 수 있습니다.
• 파일 업로드 탭: GraphQL 쿼리와 관련이 없습니다.
• 고급 탭의 HTML 파일 섹션에서 포함된 리소스: GraphQL JSON 응답과 관련이 없습니다.

Java HTTP 구현에는 몇 가지 제한 사항이 있습니다.

• 연결을 재사용하는 방법을 제어할 수 없습니다. 연결이 JMeter에 의해 해제되면 동일한 스레드에서 다시 사용할 수도 있고 사용하지 않을 수도 있습니다.
• API는 단일 스레드 사용에 가장 적합합니다. 다양한 설정은 시스템 속성을 통해 정의되므로 모든 연결에 적용됩니다.
• Kerberos 인증을 지원하지 않음
• Keystore Config를 사용한 클라이언트 기반 인증서 테스트는 지원하지 않습니다.
• 재시도 메커니즘의 더 나은 제어
• 가상 호스트를 지원하지 않습니다.
• GET , POST , HEAD , OPTIONS , PUT , DELETE 및 TRACE 메서드만 지원합니다.
• DNS Cache Manager 로 DNS 캐싱에 대한 더 나은 제어

요청에 서버 또는 프록시 로그인 인증이 필요한 경우(즉, 브라우저가 팝업 대화 상자를 생성하는 경우) HTTP 인증 관리자 구성 요소도 추가해야 합니다. 일반 로그인의 경우(즉, 사용자가 양식에 로그인 정보를 입력하는 경우) 양식 제출 버튼이 무엇을 하는지 알아내고 적절한 메소드(일반적으로 POST )와 양식 정의의 적절한 매개변수를 사용하여 HTTP 요청을 생성해야 합니다. . 페이지에서 HTTP를 사용하는 경우 JMeter 프록시를 사용하여 로그인 시퀀스를 캡처할 수 있습니다.

각 스레드에 대해 별도의 SSL 컨텍스트가 사용됩니다. 단일 SSL 컨텍스트(브라우저의 표준 동작이 아님)를 사용하려면 JMeter 속성을 설정하십시오.

https.sessioncontext.shared=true

httpclient.reset_state_on_thread_group_iteration=true

https.default.protocol=SSLv3

JMeter는 또한 https.socket.protocols 속성을 변경하여 추가 프로토콜을 활성화할 수 있습니다 .

요청이 쿠키를 사용하는 경우 HTTP 쿠키 관리자 도 필요합니다 . 스레드 그룹 또는 HTTP 요청에 이러한 요소 중 하나를 추가할 수 있습니다. 권한 부여 또는 쿠키가 필요한 HTTP 요청이 두 개 이상 있는 경우 스레드 그룹에 요소를 추가하십시오. 그렇게 하면 모든 HTTP 요청 컨트롤러가 동일한 권한 부여 관리자와 쿠키 관리자 요소를 공유합니다.

요청이 세션을 유지 관리하기 위해 "URL 재작성"이라는 기술을 사용하는 경우 추가 구성 단계에 대해서는 섹션 6.1 URL 재작성으로 사용자 세션 처리 를 참조하십시오.

이 샘플러를 사용하면 데이터베이스에 JDBC 요청(SQL 쿼리)을 보낼 수 있습니다.

이것을 사용하기 전에 JDBC 연결 구성 구성 요소 를 설정해야 합니다.

변수 이름 목록이 제공되면 Select 문에서 반환된 각 행에 대해 해당 열의 값으로 변수가 설정되고(변수 이름이 제공된 경우) 행 개수도 설정됩니다. 예를 들어, Select 문이 3개 열의 2개 행을 반환하고 변수 목록이 A,,C 이면 다음 변수가 설정됩니다.

A_#=2(행 수)
A_1=1열, 1행
A_2=열 1, 행 2
C_#=2(행 수)
C_1=3열, 1행
C_2=3열, 2행

Select 문이 0개의 행을 반환하면 A_# 및 C_# 변수는 0 으로 설정되고 다른 변수는 설정되지 않습니다.

필요한 경우 이전 변수가 지워집니다. 예를 들어 첫 번째 선택이 6개의 행을 검색하고 두 번째 선택이 3개의 행만 반환하는 경우 4, 5, 6행에 대한 추가 변수가 제거됩니다.

이 샘플러를 사용하면 org.apache.jmeter.protocol.java.sampler.JavaSamplerClient 인터페이스를 구현하는 Java 클래스를 제어할 수 있습니다. 이 인터페이스의 고유한 구현을 작성하여 JMeter를 사용하여 다중 스레드, 입력 매개변수 제어 및 데이터 수집을 활용할 수 있습니다.

풀다운 메뉴는 클래스 경로에서 JMeter가 찾은 모든 구현 목록을 제공합니다. 그런 다음 구현에서 정의한 대로 매개변수를 아래 표에 지정할 수 있습니다. 두 가지 간단한 예제( JavaTest 및 SleepTest )가 제공됩니다.

JavaTest 예제 샘플러는 거의 모든 필드에 값을 설정할 수 있기 때문에 테스트 계획을 확인하는 데 유용할 수 있습니다 . 그런 다음 Assertion 등에서 사용할 수 있습니다. 필드에서 변수를 사용할 수 있으므로 해당 값을 쉽게 볼 수 있습니다.

동일한 LDAP 서버에 여러 요청을 보내려는 경우 각 LDAP 요청에 대해 동일한 정보를 입력할 필요가 없도록 LDAP 요청 기본값 구성 요소 사용을 고려하십시오.

동일한 LDAP 서버에 여러 요청을 보내려는 경우 각 LDAP 요청에 대해 동일한 정보를 입력할 필요가 없도록 LDAP 확장 요청 기본값 구성 요소 사용을 고려하십시오.

AccessLogSampler는 액세스 로그를 읽고 http 요청을 생성하도록 설계되었습니다. 액세스 로그에 익숙하지 않은 사용자를 위해 웹 서버가 수락한 모든 요청에 ​​대해 유지 관리하는 로그입니다. 이것은 모든 이미지, CSS 파일, JavaScript 파일, html 파일 등을 의미합니다.

Tomcat은 액세스 로그에 공통 형식을 사용합니다. 이는 공통 로그 형식을 사용하는 모든 웹 서버가 AccessLogSampler를 사용할 수 있음을 의미합니다. 공통 로그 형식을 사용하는 서버는 Tomcat, Resin, Weblogic 및 SunOne입니다. 일반적인 로그 형식은 다음과 같습니다.

127.0.0.1 - - [21/Oct/2003:05:37:21 -0500] "GET /index.jsp?%2Findex.jsp= HTTP/1.1" 200 8343

앞으로는 응답 코드 200 이 없는 항목을 필터링하는 것이 좋습니다 . 샘플러를 확장하는 것은 매우 간단해야 합니다. 구현해야 하는 두 가지 인터페이스가 있습니다.

• org.apache.jmeter.protocol.http.util.accesslog.LogParser
• org.apache.jmeter.protocol.http.util.accesslog.Generator

AccessLogSampler의 현재 구현은 생성기를 사용하여 새 HTTPSampler를 생성합니다. 서버 이름, 포트 및 가져오기 이미지는 AccessLogSampler에 의해 설정됩니다. 다음으로 파서는 정수 1 로 호출되어 하나의 항목을 구문 분석하도록 지시합니다. 그런 다음 HTTPSampler.sample() 을 호출하여 요청합니다.

samp = (HTTPSampler) GENERATOR.generateRequest();
samp.setDomain(this.getDomain());
samp.setPort(this.getPort());
samp.setImageParser(this.isImageParser());
PARSER.parse(1);
res = samp.sample();
res.setSampleLabel(samp.toString());

• setGenerator(생성기)
• 구문 분석(int)

Generator 인터페이스를 구현하는 클래스 는 모든 메서드에 대한 구체적인 구현을 제공해야 합니다. 두 인터페이스를 구현하는 방법의 예는 StandardGenerator 및 TCLogParser 를 참조하십시오 .

이 샘플러를 사용하면 BeanShell 스크립팅 언어를 사용하여 샘플러를 작성할 수 있습니다.

BeanShell 사용에 대한 자세한 내용은 BeanShell 웹사이트를 참조하십시오.

테스트 요소는 ThreadListener 및 TestListener 인터페이스 메서드를 지원합니다. 초기화 파일에 정의해야 합니다. 예제 정의 는 BeanShellListeners.bshrc 파일을 참조하십시오 .

BeanShell 샘플러는 Interruptible 인터페이스도 지원합니다. 인터럽트() 메서드 는 스크립트 또는 초기화 파일에서 정의할 수 있습니다.

JSR223 샘플러를 사용하면 JSR223 스크립트 코드를 사용하여 샘플을 수행하거나 변수를 생성/업데이트하는 데 필요한 일부 계산을 수행할 수 있습니다.

SampleResult.setIgnore();

JSR223 테스트 요소에는 성능을 크게 향상시킬 수 있는 기능(컴파일)이 있습니다. 이 기능을 활용하려면:

• 인라인 대신 스크립트 파일을 사용하십시오. ScriptEngine에서 이 기능을 사용할 수 있는 경우 JMeter가 이를 컴파일하고 캐시합니다.
• 또는 스크립트 텍스트를 사용하고 사용 가능한 속성 이 있으면 컴파일된 스크립트 캐시를 선택 합니다.
  이 기능을 사용할 때 캐싱은 첫 번째 교체만 캐시하므로 스크립트 코드가 스크립트 코드에서 직접 JMeter 변수 또는 JMeter 함수 호출을 사용하지 않는지 확인하십시오. 대신 스크립트 매개변수를 사용하십시오.
  캐싱 및 컴파일의 이점을 얻으려면 스크립팅에 사용되는 언어 엔진이 JSR223 Compilable 인터페이스를 구현해야 합니다(Groovy는 이 중 하나이고 Java, beanshell 및 javascript는 그렇지 않음)
  Groovy를 스크립팅 언어로 사용하고 사용 가능한 경우 캐시 컴파일된 스크립트를 확인하지 않는 경우 (캐싱이 권장되는 경우) 버전 2.4.6부터 Groovy 메모리 누수로 인해 이 JVM 속성 -Dgroovy.use.classvalue=true 를 설정해야 합니다 . 다음을 참조하세요.

  • 그루비-7683
  • 그루비-7591
  • JDK-8136353

jsr223.compiled_scripts_cache_size=100

TCP 샘플러는 지정된 서버에 대한 TCP/IP 연결을 엽니다. 그런 다음 텍스트를 보내고 응답을 기다립니다.

" Re-use connection "을 선택하면 정확히 동일한 호스트 이름 문자열과 포트가 사용되는 경우 동일한 스레드의 샘플러 간에 연결이 공유됩니다. 다른 호스트/포트 조합은 다른 스레드와 마찬가지로 다른 연결을 사용합니다. " Re-use connection "과 " Close connection "을 모두 선택하면 샘플러를 실행한 후 소켓이 닫힙니다. 다음 샘플러에서 다른 소켓이 생성됩니다. 각 스레드 루프의 끝에서 소켓을 닫고 싶을 수 있습니다.

오류가 감지되거나 " 연결 재사용 "이 선택되지 않은 경우 소켓이 닫힙니다. 다음 샘플에서 다른 소켓이 다시 열립니다.

다음 속성을 사용하여 작업을 제어할 수 있습니다.

tcp.status.prefix

상태 번호 앞에 오는 텍스트

tcp.status.suffix

상태 번호 뒤에 오는 텍스트

tcp.status.properties

상태 코드를 메시지로 변환하는 속성 파일의 이름

tcp.handler

TCP 핸들러 클래스의 이름(기본 TCPClientImpl ) - GUI에 지정되지 않은 경우에만 사용됩니다.

사용자는 자신의 구현을 제공할 수 있습니다. 클래스는 org.apache.jmeter.protocol.tcp.sampler.TCPClient 를 확장해야 합니다 .

현재 다음 구현이 제공됩니다.

• TCPClientImpl
• 바이너리TCPClientImpl
• 길이PrefixedBinaryTCPClientImpl

TCPClientImpl

이 구현은 상당히 기본적입니다. 응답을 읽을 때 tcp.eolByte 속성을 설정하여 정의된 경우 줄 끝까지 읽습니다 . 그렇지 않으면 입력 스트림이 끝날 때까지 읽습니다. 플랫폼 기본 인코딩으로 기본 설정되는 tcp.charset 을 설정하여 charset 인코딩을 제어할 수 있습니다 .

바이너리TCPClientImpl

이 구현은 16진수로 인코딩된 문자열이어야 하는 GUI 입력을 바이너리로 변환하고 응답을 읽을 때 역순으로 수행합니다. 응답을 읽을 때 tcp.BinaryTCPClient.eomByte 속성을 설정하여 정의된 경우 메시지 바이트 끝까지 읽고 , 그렇지 않으면 입력 스트림 끝까지 읽습니다.

길이PrefixedBinaryTCPClientImpl

이 구현은 이진 메시지 데이터에 이진 길이 바이트를 접두사로 붙여 BinaryTCPClientImpl을 확장합니다. 길이 접두사는 기본적으로 2바이트입니다. 이것은 tcp.binarylength.prefix.length 속성을 설정하여 변경할 수 있습니다 .

시간 초과 처리

시간 초과가 설정되면 만료될 때 읽기가 종료됩니다. 따라서 eolByte / eomByte 를 사용하는 경우 제한 시간이 충분히 긴지 확인하십시오. 그렇지 않으면 읽기가 일찍 종료됩니다.

응답 처리

tcp.status.prefix 가 정의되어 있으면 응답 메시지에서 접미사까지 이어지는 텍스트를 검색합니다. 이러한 텍스트가 발견되면 응답 코드를 설정하는 데 사용됩니다. 응답 메시지는 속성 파일(제공된 경우)에서 가져옵니다.

접미사와 접미사의 사용법 ¶

예를 들어, 접두사 = " [ " 및 접미사 = " ] "인 경우 다음 응답:

[J28] XI123,23,GBP,CR

응답 코드는 J28 입니다.

" 400 "-" 499 " 및 " 500 "-" 599 " 범위의 응답 코드 는 현재 실패로 간주됩니다. 나머지는 모두 성공합니다. [이것은 구성 가능해야합니다!]

JMS 게시자는 지정된 대상(주제/대기열)에 메시지를 게시합니다. JMS에 익숙하지 않은 사람들을 위해 메시징을 위한 J2EE 사양입니다. 시장에는 수많은 JMS 서버와 여러 오픈 소스 옵션이 있습니다.

JMS 구독자는 지정된 대상(주제 또는 대기열)의 메시지를 구독합니다. JMS에 익숙하지 않은 사람들을 위해 메시징을 위한 J2EE 사양입니다. 시장에는 수많은 JMS 서버와 여러 오픈 소스 옵션이 있습니다.

이 샘플러는 지점간 연결(대기열)을 통해 JMS 메시지를 보내고 선택적으로 받습니다. pub/sub 메시지와 다르며 일반적으로 트랜잭션 처리에 사용됩니다.

request_only 는 일반적으로 JMS 시스템에 부하를 가하는 데 사용됩니다.
request_reply 는 이 모드가 이 서비스에서 보낸 응답 대기열의 응답을 기다리므로 요청 대기열로 보낸 메시지를 처리하는 JMS 서비스의 응답 시간을 테스트하려는 경우에 사용됩니다.
찾아보기 는 현재 대기열 깊이, 즉 대기열에 있는 메시지 수를 반환합니다.
read 는 큐(있는 경우)에서 메시지를 읽습니다.
clear 는 대기열을 지웁니다. 즉, 대기열에서 모든 메시지를 제거합니다.

JMeter 는 대기열 연결을 생성할 때 java.naming.security.[principal|credentials] 속성을 사용합니다(있는 경우). 이 동작을 원하지 않으면 JMeter 속성 JMSSampler.useSecurity.properties=false 를 설정하십시오.

• JMeter의 테스트 인터페이스를 사용하는 대신 JUnit의 TestCase 클래스를 확장하는 클래스에 대해 jar 파일을 스캔합니다. 여기에는 모든 클래스 또는 하위 클래스가 포함됩니다.
• JUnit 테스트 jar 파일은 /lib 디렉토리 대신 jmeter/lib/junit 에 위치해야 합니다 . " user.classpath " 속성을 사용하여 TestCase 클래스를 찾을 위치를 지정할 수도 있습니다.
• JUnit 샘플러는 Java 요청 과 같은 구성에 이름/값 쌍을 사용하지 않습니다 . 샘플러는 setUp 및 tearDown 이 테스트를 올바르게 구성할 것이라고 가정합니다.
• 샘플러는 테스트 메서드에 대해서만 경과 시간을 측정하며 setUp 및 tearDown 은 포함하지 않습니다 .
• 테스트 메소드가 호출될 때마다 JMeter는 결과를 리스너에 전달합니다.
• oneTimeSetUp 및 oneTimeTearDown 에 대한 지원은 메서드로 수행됩니다. JMeter는 다중 스레드이므로 Maven과 같은 방식으로 oneTimeSetUp / oneTimeTearDown 을 호출할 수 없습니다.
• 샘플러는 예기치 않은 예외를 오류로 보고합니다. 표준 JUnit 테스트 러너와 JMeter의 구현 사이에는 몇 가지 중요한 차이점이 있습니다. 각 테스트에 대해 클래스의 새 인스턴스를 만드는 대신 JMeter는 샘플러당 1개의 인스턴스를 생성하고 재사용합니다. " 샘플당 새 인스턴스 만들기 " 확인란을 사용하여 변경할 수 있습니다 .

공개 클래스 myTestCase {
  공개 myTestCase() {}
}

공개 클래스 myTestCase {
  공개 myTestCase(문자열 텍스트) {
    슈퍼(텍스트);
  }
}

메일 판독기 샘플러는 POP3(S) 또는 IMAP(S) 프로토콜을 사용하여 메일 메시지를 읽고 선택적으로 삭제할 수 있습니다.

이 샘플러는 샘플을 생성할 필요 없이 일시 중지를 포함할 수 있으므로 트랜잭션 컨트롤러와 함께 사용할 수도 있습니다. 가변 지연의 경우 일시 중지 시간을 0으로 설정하고 Timer를 자식으로 추가합니다.

" 중지 " 작업은 진행 중인 샘플을 완료한 후 스레드 또는 테스트를 중지합니다. " 지금 중지 " 작업은 샘플이 완료될 때까지 기다리지 않고 테스트를 중지합니다. 모든 활성 샘플을 중단합니다. 일부 스레드가 5초 제한 시간 내에 중지되지 않으면 GUI 모드에서 메시지가 표시됩니다. Stop 명령을 사용하여 스레드가 중지되는지 확인할 수 있지만 그렇지 않으면 JMeter를 종료해야 합니다. CLI 모드에서 일부 스레드가 5초 제한 시간 내에 중지되지 않으면 JMeter가 종료됩니다.

SMTP 샘플러는 SMTP/SMTPS 프로토콜을 사용하여 메일 메시지를 보낼 수 있습니다. 사용자 인증은 물론 연결(SSL 및 TLS)에 대한 보안 프로토콜을 설정할 수 있습니다. 보안 프로토콜을 사용하는 경우 서버 인증서에 대한 확인이 수행됩니다.
이 확인을 처리하는 두 가지 대안을 사용할 수 있습니다.

모든 인증서 신뢰

인증서 체인 확인을 무시합니다.

로컬 신뢰 저장소 사용

이 옵션을 사용하면 인증서 체인이 로컬 신뢰 저장소 파일에 대해 검증됩니다.

OS 프로세스 샘플러는 로컬 시스템에서 명령을 실행하는 데 사용할 수 있는 샘플러입니다.
명령줄에서 실행할 수 있는 모든 명령의 실행을 허용해야 합니다.
반환 코드의 유효성 검사를 활성화하고 예상 반환 코드를 지정할 수 있습니다.

OS 셸은 일반적으로 명령줄 구문 분석을 제공합니다. 이것은 OS마다 다르지만 일반적으로 쉘은 공백에서 매개변수를 분할합니다. 일부 쉘은 와일드카드 파일 이름을 확장합니다. 일부는 그렇지 않습니다. 인용 메커니즘도 OS마다 다릅니다. 샘플러는 의도적으로 구문 분석이나 인용 처리를 하지 않습니다. 명령 및 해당 매개변수는 실행 파일에서 예상하는 형식으로 제공되어야 합니다. 이는 샘플러 설정이 OS 간에 이식될 수 없음을 의미합니다.

많은 OS에는 별도의 실행 파일로 제공되지 않는 몇 가지 내장 명령이 있습니다. 예를 들어 Windows DIR 명령은 명령 인터프리터( CMD.EXE )의 일부입니다. 이러한 내장 프로그램은 독립적인 프로그램으로 실행할 수 없지만 적절한 명령 인터프리터에 대한 인수로 제공해야 합니다.

예를 들어 Windows 명령줄: DIR C:\TEMP 는 다음과 같이 지정해야 합니다.

명령:

명령

매개변수 1:

/씨

매개변수 2:

감독

매개변수 3:

C:\TEMP

이 샘플러를 사용하면 MongoDB에 요청을 보낼 수 있습니다.

이것을 사용하기 전에 MongoDB 소스 구성 구성 요소 를 설정해야 합니다.

이 샘플러를 사용하면 Bolt 프로토콜을 통해 Cypher 쿼리를 실행할 수 있습니다.

이것을 사용하기 전에 볼트 연결 구성 을 설정해야 합니다.

모든 요청은 풀에서 획득한 연결을 사용하고 샘플러가 완료되면 풀로 반환합니다. 연결 풀 크기는 드라이버 기본값(~100)을 사용하며 현재 구성할 수 없습니다.

측정된 응답 시간은 cypher 쿼리를 실행하는 시간과 데이터베이스에서 다시 보낸 결과를 소비하는 시간을 모두 포함하여 "전체" 쿼리 실행에 해당합니다.

Simple Logic Controller를 사용하면 샘플러 및 기타 로직 컨트롤러를 구성할 수 있습니다. 다른 로직 컨트롤러와 달리 이 컨트롤러는 저장 장치 이상의 기능을 제공하지 않습니다.

루프 컨트롤러에 Generative 또는 Logic 컨트롤러를 추가하면 JMeter는 스레드 그룹에 대해 지정한 루프 값 외에 특정 횟수만큼 루프 컨트롤러를 반복합니다. 예를 들어 루프 카운트가 2인 루프 컨트롤러에 하나의 HTTP 요청을 추가하고 스레드 그룹 루프 카운트를 3으로 구성하면 JMeter는 총 2 * 3 = 6 HTTP 요청을 보냅니다.

Once Only Logic Controller는 JMeter에 내부 컨트롤러를 스레드당 한 번만 처리하도록 지시하고 테스트 계획을 통한 추가 반복 동안 그 아래에 있는 모든 요청을 전달합니다.

한 번만 컨트롤러는 이제 모든 루프 상위 컨트롤러의 첫 번째 반복 중에 항상 실행됩니다. 따라서 한 번만 컨트롤러가 5번 반복하도록 지정된 루프 컨트롤러 아래에 배치되면 한 번만 컨트롤러는 루프 컨트롤러를 통한 첫 번째 반복에서만(즉, 5회마다) 실행됩니다.

이것은 한 번만 컨트롤러가 스레드 그룹(스레드당 테스트당 한 번만 실행) 아래에 있는 경우 이전에 예상한 대로 계속 작동하지만 이제 사용자는 한 번만 컨트롤러를 사용할 때 더 많은 유연성을 갖게 됨을 의미합니다.

로그인이 필요한 테스트의 경우 각 스레드가 세션을 설정하기 위해 한 번만 로그인하면 되므로 이 컨트롤러에 로그인 요청을 배치하는 것을 고려하십시오.

Interleave Controller에 Generative 또는 Logic Controller를 추가하면 JMeter는 각 루프 반복에 대해 다른 컨트롤러 각각을 번갈아 사용합니다.

랜덤 로직 컨트롤러는 하위 컨트롤러와 샘플러를 순서대로 거치는 대신 각 패스에서 무작위로 하나를 선택한다는 점을 제외하고는 인터리브 컨트롤러와 유사하게 작동합니다.

Random Order Controller는 각 자식 요소를 최대 한 번만 실행한다는 점에서 Simple Controller와 비슷하지만 노드 실행 순서는 무작위입니다.

처리량 컨트롤러를 사용하면 사용자가 실행 빈도를 제어할 수 있습니다. 두 가지 모드가 있습니다.

• 퍼센트 실행
• 총 처형

실행률

컨트롤러가 테스트 계획을 통해 일정 비율의 반복을 실행하도록 합니다.

총 실행

특정 횟수의 실행이 발생한 후 컨트롤러가 실행을 중지하도록 합니다.

런타임 컨트롤러는 자식이 실행되는 시간을 제어합니다. 컨트롤러는 구성된 런타임 이 초과 될 때까지 자식을 실행합니다 .

If Controller를 사용하면 그 아래의 테스트 요소(자식)가 실행되는지 여부를 제어할 수 있습니다.

기본적으로 조건은 초기 입력 시 한 번만 평가되지만 컨트롤러에 포함된 모든 실행 가능한 요소에 대해 평가되도록 하는 옵션이 있습니다.

가장 좋은 옵션(기본값)은 조건을 변수 표현식으로 해석을 선택하는 것입니다. , 조건 필드에 2가지 옵션이 있습니다.

• 옵션 1: true 또는 false 를 포함하는 변수 사용
  마지막 샘플이 성공했는지 테스트하려면 ${JMeterThread.last_sample_ok} 를 사용할 수 있습니다.

  
• 옵션 2: 함수( ${__jexl3()} 권장)를 사용하여 true 또는 false 를 반환해야 하는 표현식 평가

  

"${myVar}" == "\${myVar}"

"${myVar}" != "\${myVar}"

While 컨트롤러는 조건이 " false " 가 될 때까지 자식을 실행합니다 .

가능한 조건 값:

• 공백 - 루프의 마지막 샘플이 실패하면 루프 종료
• LAST - 루프의 마지막 샘플이 실패하면 루프를 종료합니다. 루프 직전의 마지막 샘플이 실패한 경우 루프에 들어가지 마십시오.
• 그렇지 않으면 - 조건이 " false " 문자열과 같을 때 루프를 종료하거나 입력하지 마십시오 .

• ${VAR} - VAR 이 다른 테스트 요소에 의해 false로 설정된 경우
• ${__jexl3(${C}==10)}
• ${__jexl3("${VAR2}"=="abcd")}
• ${_P(property)} - 속성이 다른 곳 에서 " false "로 설정된 경우

스위치 컨트롤러는 각 반복에서 하위 요소 중 하나를 실행한다는 점에서 인터리브 컨트롤러 처럼 작동 하지만 컨트롤러는 순서대로 실행하는 대신 스위치 값으로 정의된 요소를 실행합니다.

스위치 값이 범위를 벗어나면 0번째 요소를 실행하므로 숫자 케이스의 기본값으로 작동합니다. 값이 빈 문자열인 경우 0번째 요소도 실행합니다.

값이 숫자가 아닌(비어 있지 않은 경우) 스위치 컨트롤러는 동일한 이름을 가진 요소를 찾습니다(대소문자가 중요함). 일치하는 이름이 없으면 " default "(대소문자가 중요하지 않음)라는 요소가 선택됩니다. 기본값이 없으면 요소가 선택되지 않고 컨트롤러는 아무 것도 실행하지 않습니다.

ForEach 컨트롤러는 관련 변수 집합의 값을 반복합니다. 샘플러(또는 컨트롤러)를 ForEach 컨트롤러에 추가하면 모든 샘플(또는 컨트롤러)이 한 번 이상 실행되며, 여기서 모든 루프 동안 변수는 새 값을 갖습니다. 입력은 밑줄과 숫자로 확장된 여러 변수로 구성되어야 합니다. 이러한 각 변수에는 값이 있어야 합니다. 따라서 예를 들어 입력 변수의 이름이 inputVar 인 경우 다음 변수가 정의되어야 합니다.

• inputVar_1 = 웬디
• inputVar_2 = 찰스
• inputVar_3 = 피터
• inputVar_4 = 존

참고: " _ " 구분 기호는 이제 선택 사항입니다.

반환 변수가 " returnVar "로 지정되면 ForEach 컨트롤러 아래의 샘플러 및 컨트롤러 컬렉션이 4 회 연속 실행되며 반환 변수는 위의 값을 각각 가지며 샘플러에서 사용할 수 있습니다.

정규식 후처리기로 실행하는 데 특히 적합합니다. 이것은 이전 요청의 결과 데이터에서 필요한 입력 변수를 "생성"할 수 있습니다. " _ " 구분 기호 를 생략하면 ForEach 컨트롤러를 사용하여 입력 변수 refName_g 를 사용하여 그룹을 반복할 수 있으며 refName_${C 형식의 입력 변수를 사용하여 모든 일치 항목의 모든 그룹을 반복할 수도 있습니다. }_g , 여기서 C 는 카운터 변수입니다.

모듈 컨트롤러는 런타임에 테스트 계획 조각을 현재 테스트 계획으로 대체하는 메커니즘을 제공합니다.

테스트 계획 조각은 컨트롤러와 여기에 포함된 모든 테스트 요소(샘플러 등)로 구성됩니다. 프래그먼트는 모든 스레드 그룹에 있을 수 있습니다. 프래그먼트가 스레드 그룹에 있는 경우 해당 컨트롤러를 비활성화하여 모듈 컨트롤러를 제외하고 프래그먼트가 실행되는 것을 방지할 수 있습니다. 또는 더미 스레드 그룹에 조각을 저장하고 전체 스레드 그룹을 비활성화할 수 있습니다.

여러 조각이 있을 수 있으며 각 조각 아래에는 서로 다른 일련의 샘플러가 있습니다. 그런 다음 모듈 컨트롤러를 사용하여 드롭다운 상자에서 적절한 컨트롤러를 선택하기만 하면 이러한 여러 테스트 사례 간에 쉽게 전환할 수 있습니다. 이를 통해 많은 대체 테스트 계획을 빠르고 쉽게 실행할 수 있습니다.

프래그먼트 이름은 컨트롤러 이름과 모든 상위 이름으로 구성됩니다. 예를 들어:

테스트 계획/프로토콜: JDBC/제어/인터리브 컨트롤러(Module1)

테스트 계획이 다시 로드될 때 이름이 대상 컨트롤러를 찾는 데 사용되기 때문에 모듈 컨트롤러에서 사용하는 모든 조각에는 고유한 이름이 있어야 합니다 . 이러한 이유로 컨트롤러 이름이 기본값에서 변경되었는지 확인하는 것이 가장 좋습니다(위의 예와 같이). 그렇지 않으면 새 요소가 테스트 계획에 추가될 때 실수로 중복이 생성될 수 있습니다.

포함 컨트롤러는 외부 JMX 파일을 사용하도록 설계되었습니다. 그것을 사용하려면 테스트 계획 아래에 테스트 조각을 만들고 그 아래에 원하는 샘플러, 컨트롤러 등을 추가하십시오. 그런 다음 테스트 계획을 저장합니다. 이제 파일이 다른 테스트 계획의 일부로 포함될 준비가 되었습니다.

편의를 위해 디버깅을 위해 외부 JMX 파일에 스레드 그룹 을 추가할 수도 있습니다. 모듈 컨트롤러 를 사용하여 테스트 조각을 참조할 수 있습니다 . 스레드 그룹 은 포함 프로세스 중에 무시됩니다.

테스트에서 쿠키 관리자 또는 사용자 정의 변수를 사용하는 경우 포함된 파일이 아닌 최상위 테스트 계획에 배치해야 합니다. 그렇지 않으면 작동이 보장되지 않습니다.

접두사 + Filename 으로 지정된 위치에서 파일을 찾을 수 없는 경우 컨트롤러 는 JMX 시작 디렉터리와 관련된 Filename 열기를 시도합니다 .

트랜잭션 컨트롤러는 중첩 테스트 요소를 수행하는 데 걸리는 전체 시간을 측정하는 추가 샘플을 생성합니다.

두 가지 작동 모드가 있습니다.

• 중첩된 샘플 다음에 추가 샘플이 추가됩니다.
• 추가 샘플이 중첩 샘플의 상위 항목으로 추가됩니다.

생성된 샘플 시간에는 기본적으로(2.11 이후) 타이머를 제외한 중첩된 샘플러의 모든 시간과 " 생성된 샘플에 타이머 및 사전 사후 프로세서의 지속 시간 포함 " 확인란이 선택되어 있지 않는 한 사전/사후 프로세서의 처리 시간이 포함 됩니다. 클럭 해상도에 따라 개별 샘플러와 타이머를 합한 것보다 약간 더 길 수 있습니다. 시계는 컨트롤러가 시작 시간을 기록한 후 첫 번째 샘플이 시작되기 전에 똑딱거릴 수 있습니다. 마찬가지로 마지막에.

생성된 샘플은 모든 하위 샘플이 성공한 경우에만 성공한 것으로 간주됩니다.

상위 모드에서 개별 샘플은 여전히 ​​트리 보기 리스너에서 볼 수 있지만 더 이상 다른 리스너에서 별도의 항목으로 나타나지 않습니다. 또한 하위 샘플은 CSV 로그 파일에 나타나지 않지만 XML 파일로 저장할 수 있습니다.

녹음 컨트롤러는 프록시 서버가 샘플을 녹음해야 하는 위치를 나타내는 자리 표시자입니다. 테스트 실행 중에는 Simple Controller와 유사하게 효과가 없습니다. 그러나 HTTP(S) 테스트 스크립트 레코더 를 사용하여 녹음하는 동안 모든 녹음된 샘플은 기본적으로 녹음 컨트롤러 아래에 저장됩니다.

크리티컬 섹션 컨트롤러는 컨트롤러의 자식을 실행하기 전에 명명된 잠금이 취해지기 때문에 자식 요소(샘플러/컨트롤러 등)가 단 하나의 스레드에 의해 실행되도록 합니다.

리스너는 아래와 같이 구성 팝업을 사용하여 결과 로그 파일(JTL)에 다른 항목을 저장하도록 구성할 수 있습니다. 기본값은 리스너 기본 구성 설명서에 설명된 대로 정의됩니다. 이름 뒤에 ( CSV )가 있는 항목은 CSV 형식에만 적용됩니다. ( XML )이 있는 항목은 XML 형식에만 적용됩니다. CSV 형식은 현재 줄 바꿈이 포함된 항목을 저장하는 데 사용할 수 없습니다.

쿠키, 메서드 및 쿼리 문자열은 " 샘플러 데이터 " 옵션 의 일부로 저장됩니다 .

그래프 결과 수신기는 모든 샘플 시간을 표시하는 간단한 그래프를 생성합니다. 그래프 하단을 따라 현재 샘플(검정색), 모든 샘플의 현재 평균(파란색), 현재 표준 편차(빨간색) 및 현재 처리율(녹색)이 밀리초 단위로 표시됩니다.

처리량 숫자는 서버가 처리한 실제 요청/분 수를 나타냅니다. 이 계산에는 테스트에 추가한 지연과 JMeter의 자체 내부 처리 시간이 포함됩니다. 이와 같은 계산을 수행할 때의 이점은 이 숫자가 실제를 나타낸다는 것입니다. 실제로 서버는 분당 많은 요청을 처리했으며 스레드 수를 늘리거나 지연을 줄여 서버의 최대 처리량을 찾을 수 있습니다. 반면에 지연과 JMeter의 처리를 고려한 계산을 수행했다면 그 수치에서 무엇을 결론을 내릴 수 있는지 명확하지 않을 것입니다.

어설션 결과 시각화 도우미는 가져온 각 샘플의 레이블을 보여줍니다. 또한 테스트 계획의 일부인 모든 어설션 의 실패를 보고합니다.

응답을 보는 방법에는 여러 가지가 있으며 왼쪽 패널 하단의 드롭다운 상자에서 선택할 수 있습니다.

일치 횟수: 74
일치[1]=#기능
경기[2]=#할 수 있는 일
일치[3]=#어디서
경기[4]=#어떻게
일치[5]=#function_helper
일치[6]=#기능
일치[7]=#__regex함수
일치[8]=#__regexFunction_parms
일치[9]=#__카운터
… 등등 …

일치 횟수: 26
Match[1][0]=JMeter - Apache JMeter</title>
일치[1][1]=JMeter
일치[2][0]=JMeter" title="JMeter" border="0"/></a>
일치[2][1]=JMeter
Match[3][0]=JMeterCommitters">기여자</a>
Match[3][1]=JMeterCommitters
… 등등 …

영상/
오디오/
동영상/

자동으로 스크롤하시겠습니까? 옵션은 트리 선택에서 마지막 노드를 표시하도록 허용합니다.

검색 옵션을 사용하면 대부분의 보기에서 표시된 데이터를 검색할 수도 있습니다. 검색 결과는 위의 디스플레이에서 강조 표시됩니다. 예를 들어 아래 제어판 스크린샷은 " Java "를 검색한 결과 중 하나를 보여줍니다. 검색은 보이는 텍스트에 대해 작동하므로 텍스트 및 HTML 보기를 검색할 때 다른 결과를 얻을 수 있습니다.
참고: 정규식은 Java 엔진(정규식 추출기 또는 Regexp 테스터 보기와 같은 ORO 엔진이 아님)을 사용합니다.

컨텐츠 유형 이 제공 되지 않으면 응답 데이터 패널에 컨텐츠가 표시되지 않습니다. 이 경우 파일에 응답 저장 을 사용 하여 데이터를 저장할 수 있습니다. 응답 데이터는 샘플 결과에서 계속 사용할 수 있으므로 포스트 프로세서를 사용하여 계속 액세스할 수 있습니다.

응답 데이터가 200K보다 크면 표시되지 않습니다. 이 제한을 변경하려면 JMeter 속성 view.results.tree.max_size 를 설정하십시오 . 파일에 응답 저장 을 사용하여 전체 응답을 파일에 저장할 수도 있습니다 .

추가 렌더러를 만들 수 있습니다. 클래스는 인터페이스 org.apache.jmeter.visualizers.ResultRenderer 를 구현 하거나 추상 클래스 org.apache.jmeter.visualizers.SamplerResultTab 을 확장해야 하며 컴파일된 코드는 JMeter에서 사용할 수 있어야 합니다(예: lib/ 확장 디렉토리).

처리량은 샘플러 대상(예: HTTP 샘플의 경우 원격 서버)의 관점에서 계산됩니다. JMeter는 요청이 생성된 총 시간을 고려합니다. 다른 샘플러와 타이머가 동일한 스레드에 있으면 총 시간이 증가하므로 처리량 값이 감소합니다. 따라서 이름이 다른 두 개의 동일한 샘플러는 동일한 이름을 가진 두 개의 샘플러 처리량의 절반이 됩니다. 집계 보고서에서 최상의 결과를 얻으려면 샘플러 이름을 올바르게 선택하는 것이 중요합니다.

중앙값 및 90% 선(90 ^번째 백분위수 ) 값 을 계산 하려면 추가 메모리가 필요합니다. JMeter는 이제 동일한 경과 시간으로 샘플을 결합하므로 훨씬 적은 메모리가 사용됩니다. 그러나 몇 초 이상 걸리는 샘플의 경우 더 적은 수의 샘플이 동일한 시간을 가질 가능성이 있으며 이 경우 더 많은 메모리가 필요합니다. 나중에 이 리스너를 사용하여 성능 영향을 피하기 위해 권장되는 방법인 CSV 또는 XML 결과 파일을 다시 로드할 수 있습니다. 개별 샘플을 저장하지 않으므로 일정한 메모리가 필요한 유사한 리스너에 대한 요약 보고서 를 참조하십시오 .

• 레이블 - 샘플의 레이블입니다. " 레이블에 그룹 이름을 포함하시겠습니까? "를 선택하면 스레드 그룹의 이름이 접두사로 추가됩니다. 이를 통해 필요한 경우 서로 다른 스레드 그룹의 동일한 레이블을 별도로 대조할 수 있습니다.
• # 샘플 - 동일한 레이블을 가진 샘플의 수
• Average - 결과 집합의 평균 시간
• 중앙값 - 중앙값 은 결과 집합의 중간에 있는 시간입니다. 샘플의 50%는 이 시간을 넘지 않았습니다. 나머지는 최소한 시간이 걸렸습니다.
• 90% 라인 - 샘플의 90%가 이 시간을 넘지 않았습니다. 나머지 샘플은 최소한 이 정도의 시간이 소요되었습니다. (90 ^번째 백분위수 )
• 95% 라인 - 샘플의 95%가 이 시간을 넘지 않았습니다. 나머지 샘플은 최소한 이 정도의 시간이 소요되었습니다. (95 ^번째 백분위수 )
• 99% 라인 - 샘플의 99%가 이 시간을 넘지 않았습니다. 나머지 샘플은 최소한 이 정도의 시간이 소요되었습니다. (99 ^번째 백분위수 )
• Min - 동일한 라벨의 샘플에 대한 최단 시간
• Max - 동일한 레이블을 가진 샘플의 가장 긴 시간
• 오류 % - 오류가 있는 요청 비율
• 처리량 - 처리량 은 초/분/시간당 요청으로 측정됩니다. 표시되는 비율이 최소 1.0이 되도록 시간 단위가 선택됩니다. 처리량을 CSV 파일로 저장할 때 요청/초로 표시됩니다. 즉, 30.0 요청/분은 0.5로 저장됩니다.
• 수신된 KB/초 - 초당 수신된 킬로바이트로 측정된 처리량
• 전송된 KB/초 - 전송된 초당 킬로바이트로 측정된 처리량

시간은 밀리초 단위입니다.

기본적으로 기본(상위) 샘플만 표시합니다. 하위 샘플(하위 샘플)을 표시하지 않습니다. JMeter에는 " Child Samples? " 체크박스가 있습니다. 이 옵션을 선택하면 기본 샘플 대신 하위 샘플이 표시됩니다.

메일러 시각화 도우미는 테스트 실행이 서버에서 너무 많은 실패한 응답을 받는 경우 이메일을 보내도록 설정할 수 있습니다.

BeanShell 리스너는 저장 등을 위해 샘플을 처리하기 위해 BeanShell을 사용할 수 있도록 합니다.

BeanShell 사용에 대한 자세한 내용은 BeanShell 웹사이트를 참조하십시오.

테스트 요소는 ThreadListener 및 TestListener 메서드를 지원합니다. 이들은 초기화 파일에 정의되어야 합니다. 예제 정의 는 BeanShellListeners.bshrc 파일을 참조하십시오 .

처리량은 샘플러 대상(예: HTTP 샘플의 경우 원격 서버)의 관점에서 계산됩니다. JMeter는 요청이 생성된 총 시간을 고려합니다. 다른 샘플러와 타이머가 동일한 스레드에 있으면 총 시간이 증가하므로 처리량 값이 감소합니다. 따라서 이름이 다른 두 개의 동일한 샘플러는 동일한 이름을 가진 두 개의 샘플러 처리량의 절반이 됩니다. 보고서에서 최상의 결과를 얻으려면 샘플러 레이블을 올바르게 선택하는 것이 중요합니다.

• 레이블 - 샘플의 레이블입니다. " 레이블에 그룹 이름을 포함하시겠습니까? "를 선택하면 스레드 그룹의 이름이 접두사로 추가됩니다. 이를 통해 필요한 경우 서로 다른 스레드 그룹의 동일한 레이블을 별도로 대조할 수 있습니다.
• # 샘플 - 동일한 레이블을 가진 샘플의 수
• Average - 결과 집합의 평균 경과 시간
• 최소 - 동일한 레이블이 있는 샘플의 가장 낮은 경과 시간
• Max - 동일한 레이블이 있는 샘플의 가장 긴 경과 시간
• 표준 개발 - 샘플 경과 시간 의 표준편차
• 오류 % - 오류가 있는 요청 비율
• 처리량 - 처리량 은 초/분/시간당 요청으로 측정됩니다. 표시되는 비율이 최소 1.0 이 되도록 시간 단위가 선택됩니다 . 처리량을 CSV 파일로 저장할 때 요청/초로 표시됩니다. 즉, 30.0 요청/분은 0.5 로 저장됩니다 .
• 수신된 KB/초 - 초당 킬로바이트로 측정된 처리량
• 보낸 KB/초 - 초당 킬로바이트로 측정된 처리량
• 평균 바이트 - 샘플 응답의 평균 크기(바이트)입니다.

시간은 밀리초 단위입니다.

이 테스트 요소는 테스트 계획의 아무 곳에나 배치할 수 있습니다. 해당 범위의 각 샘플에 대해 응답 데이터의 파일을 생성합니다. 이것의 주요 용도는 기능 테스트를 생성하는 것이지만 응답이 너무 커서 결과 보기 트리 수신기에 표시할 수 없는 경우에도 유용할 수 있습니다. 파일 이름은 지정된 접두사에 숫자를 더하여 생성됩니다(이가 비활성화되지 않은 경우 아래 참조). 파일 확장자는 알려진 경우 문서 유형에서 생성됩니다. 알 수 없는 경우 파일 확장자가 ' unknown 으로 설정됩니다.'. 번호 매기기가 비활성화되고 접미사 추가가 비활성화된 경우 파일 접두사가 전체 파일 이름으로 사용됩니다. 이렇게 하면 필요한 경우 고정 파일 이름을 생성할 수 있습니다. 생성된 파일 이름은 샘플 응답에 저장되며 필요한 경우 테스트 로그 출력 파일에 저장할 수 있습니다.

현재 샘플이 먼저 저장되고 그 다음에 하위 샘플(하위 샘플)이 저장됩니다. 변수 이름이 제공되면 파일 이름은 하위 샘플이 나타나는 순서대로 저장됩니다. 아래를 참조하십시오.

JSR223 Listener를 사용하면 JSR223 스크립트 코드를 샘플 결과에 적용할 수 있습니다.

# 해당 이름으로 요약자를 자동으로 시작하려면 다음 속성을 정의합니다.
# (CLI 모드에만 적용됨)
#summariser.name=요약
#
# 요약 사이의 간격(초) 기본 3분
#summariser.interval=30
#
# 로그 파일에 메시지 쓰기
#summariser.log=참
#
# System.out에 메시지 쓰기
#summariser.out=참

레이블 + 16 in 0:00:12 = 1.3/s 평균: 1608 최소: 1163 최대: 2009 오류: 0(0.00%) 활성: 5 시작: 5 완료: 0
레이블 + 82 in 0:00:30 = 2.7/s 평균: 1518 최소: 1003 최대: 2020 오류: 0(0.00%) 활성: 5 시작: 5 완료: 0
레이블 = 98 in 0:00:42 = 2.3/s 평균: 1533 최소: 1003 최대: 2020 오류: 0(0.00%)
레이블 + 85 in 0:00:30 = 2.8/s 평균: 1505 최소: 1008 최대: 2005 오류: 0(0.00%) 활성: 5 시작: 5 완료: 0
레이블 = 183 in 0:01:13 = 2.5/s 평균: 1520 최소: 1003 최대: 2020 오류: 0(0.00%)
레이블 + 79 in 0:00:30 = 2.7/s 평균: 1578 최소: 1089 최대: 2012 오류: 0 (0.00%) 활성: 5 시작: 5 완료: 0
레이블 = 262 in 0:01:43 = 2.6/s 평균: 1538 최소: 1003 최대: 2020 오류: 0(0.00%)
레이블 + 80 in 0:00:30 = 2.7/s 평균: 1531 최소: 1013 최대: 2014 오류: 0 (0.00%) 활성: 5 시작: 5 완료: 0
레이블 = 342 in 0:02:12 = 2.6/s 평균: 1536 최소: 1003 최대: 2020 오류: 0(0.00%)
레이블 + 83 in 0:00:31 = 2.7/s 평균: 1512 최소: 1003 최대: 1982 오류: 0(0.00%) 활성: 5 시작: 5 완료: 0
레이블 = 425 in 0:02:43 = 2.6/s 평균: 1531 최소: 1003 최대: 2020 오류: 0(0.00%)
레이블 + 83 in 0:00:29 = 2.8/s 평균: 1487 최소: 1023 최대: 2013 오류: 0(0.00%) 활성: 5 시작: 5 완료: 0
레이블 = 508 in 0:03:12 = 2.6/s 평균: 1524 최소: 1003 최대: 2020 오류: 0(0.00%)
레이블 + 78 in 0:00:30 = 2.6/s 평균: 1594 최소: 1013 최대: 2016 오류: 0(0.00%) 활성: 5 시작: 5 완료: 0
레이블 = 586 in 0:03:43 = 2.6/s 평균: 1533 최소: 1003 최대: 2020 오류: 0(0.00%)
레이블 + 80 in 0:00:30 = 2.7/s 평균: 1516 최소: 1013 최대: 2005 오류: 0(0.00%) 활성: 5 시작: 5 완료: 0
레이블 = 666 in 0:04:12 = 2.6/s 평균: 1531 최소: 1003 최대: 2020 오류: 0(0.00%)
레이블 + 86 in 0:00:30 = 2.9/s 평균: 1449 최소: 1004 최대: 2017 오류: 0 (0.00%) 활성: 5 시작: 5 완료: 0
레이블 = 752 in 0:04:43 = 2.7/s 평균: 1522 최소: 1003 최대: 2020 오류: 0(0.00%)
레이블 + 65 in 0:00:24 = 2.7/s 평균: 1579 최소: 1007 최대: 2003 오류: 0 (0.00%) 활성: 0 시작: 5 완료: 5
레이블 = 817 in 0:05:07 = 2.7/s 평균: 1526 최소: 1003 최대: 2020 오류: 0(0.00%)

레이블은 샘플 결과를 함께 그룹화하는 데 사용됩니다. 따라서 여러 스레드 그룹이 있고 모두 요약하려면 동일한 레이블을 사용하거나 요약자를 테스트 계획에 추가하십시오(모든 스레드 그룹이 범위 내에 있도록). 적절한 레이블을 사용하고 요약자를 테스트 계획의 적절한 부분에 추가하여 다양한 요약 그룹화를 구현할 수 있습니다.

CSV 데이터 세트 구성은 파일에서 행을 읽고 변수로 분할하는 데 사용됩니다. __CSVRead() 및 __StringFromFile() 함수 보다 사용하기 쉽습니다 . 많은 수의 변수를 처리하는 데 적합하며 "임의" 및 고유한 값으로 테스트하는 데에도 유용합니다.

런타임 시 고유한 임의 값을 생성하는 것은 CPU 및 메모리 측면에서 비용이 많이 들기 때문에 테스트 전에 데이터를 생성하십시오. 필요한 경우 파일의 "무작위" 데이터를 런타임 매개변수와 함께 사용하여 각 실행에서 다른 값 세트를 생성할 수 있습니다(예: 연결 사용). 이는 런타임에 모든 것을 생성하는 것보다 훨씬 저렴합니다.

JMeter를 사용하면 값을 인용할 수 있습니다. 이렇게 하면 값에 구분 기호가 포함될 수 있습니다. " 인용 데이터 허용 "이 활성화된 경우 값을 큰따옴표로 묶을 수 있습니다. 이들은 제거됩니다. 인용된 필드에 큰따옴표를 포함하려면 두 개의 큰따옴표를 사용합니다. 예를 들어:

1,"2,3","4""5" =>
1
2,3
4"5

JMeter는 열 이름을 정의하는 헤더 행이 있는 CSV 파일을 지원합니다. 이를 활성화하려면 " 변수 이름 " 필드를 비워 둡니다. 올바른 구분 기호를 제공해야 합니다.

JMeter는 줄 바꿈이 포함된 인용 데이터가 있는 CSV 파일을 지원합니다.

기본적으로 파일은 한 번만 열리며 각 스레드는 파일과 다른 행을 사용합니다. 그러나 행이 스레드로 전달되는 순서는 실행 순서에 따라 달라지며, 이는 반복마다 다를 수 있습니다. 각 테스트 반복이 시작될 때 행을 읽습니다. 파일 이름과 모드는 첫 번째 반복에서 확인됩니다.

추가 옵션은 아래 공유 모드에 대한 설명을 참조하십시오. 각 스레드가 고유한 값 집합을 가지려면 각 스레드에 대해 하나씩 파일 집합을 만들어야 합니다. 예를 들어 test1.csv , test2.csv , ..., test n .csv . 파일 이름 test${__threadNum}.csv 를 사용하고 " 공유 모드 "를 " 현재 스레드 "로 설정합니다.

특별한 경우로 구분자 필드 의 문자열 " \t "(따옴표 제외)는 탭으로 처리됩니다.

파일의 끝( EOF )에 도달하고 재활용 옵션이 true 이면 파일의 첫 번째 줄부터 읽기가 다시 시작됩니다.

재활용 옵션이 false 이고 stopThread 가 false 이면 파일 끝에 도달할 때 모든 변수가 <EOF> 로 설정됩니다. 이 값은 JMeter 속성 csvdataset.eofstring 을 설정하여 변경할 수 있습니다 .

Recycle 옵션이 false 이고 Stop Thread 가 true 이면 EOF 에 도달 하면 스레드가 중지됩니다.

DNS 캐시 관리자 요소를 사용하면 사용자가 다른 IP에서 콘텐츠를 수신할 때 로드 밸런서(CDN 등) 뒤에 여러 서버가 있는 응용 프로그램을 테스트할 수 있습니다. 기본적으로 JMeter는 JVM DNS 캐시를 사용합니다. 그렇기 때문에 클러스터에서 하나의 서버만 부하를 받습니다. DNS 캐시 관리자는 각 반복마다 개별적으로 각 스레드의 이름을 확인하고 확인 결과를 JVM 및 OS DNS 캐시와 독립적인 내부 DNS 캐시에 저장합니다.

정적 호스트에 대한 매핑을 사용하여 /etc/hosts 파일 과 같은 것을 시뮬레이션할 수 있습니다 . 이러한 항목은 사용자 지정 해석기보다 우선 적용됩니다. 이 매핑을 사용 하려면 사용자 지정 DNS 확인자를 사용 하도록 설정해야 합니다.

권한 부여 관리자를 사용하면 서버 인증을 사용하여 제한된 웹 페이지에 대해 하나 이상의 사용자 로그인을 지정할 수 있습니다. 브라우저를 사용하여 제한된 페이지에 액세스하고 브라우저에 로그인 대화 상자가 표시되면 이러한 유형의 인증이 표시됩니다. JMeter는 이러한 유형의 페이지를 만나면 로그인 정보를 전송합니다.

인증 헤더는 트리 보기 수신기 " 요청 " 탭 에 표시되지 않을 수 있습니다 . Java 구현은 선점 인증을 수행하지만 JMeter가 헤더를 가져올 때 Authorization 헤더를 반환하지 않습니다. HttpComponents(HC 4.5.X) 구현은 3.2 이후로 기본적으로 선점형이며 헤더가 표시됩니다. 이를 비활성화하려면 다음과 같이 값을 설정하십시오. 이 경우 인증은 챌린지에 대한 응답으로만 수행됩니다.

jmeter.properties 파일에서 httpclient4.auth.preemptive =false 설정

HTTP 캐시 관리자는 브라우저 캐시 기능을 시뮬레이션하기 위해 해당 범위 내에서 HTTP 요청에 캐싱 기능을 추가하는 데 사용됩니다. 각 가상 사용자 스레드에는 자체 캐시가 있습니다. 기본적으로 캐시 관리 프로그램은 LRU 알고리즘을 사용하여 가상 사용자 스레드당 최대 5000개의 항목을 캐시에 저장합니다. 이 값을 수정 하려면 " maxSize " 속성을 사용하십시오 . 이 값을 늘릴수록 HTTP 캐쉬 관리 프로그램이 메모리를 더 많이 사용하므로 -Xmx JVM 옵션을 적절하게 조정해야 합니다.

샘플이 성공하면(즉, 응답 코드가 2xx ) Last-Modified 및 Etag ( 관련되는 경우 만료됨 ) 값이 URL에 저장됩니다. 다음 샘플을 실행하기 전에 샘플러는 캐시에 항목이 있는지 확인하고, 있으면 If-Last-Modified 및 If-None-Match 조건부 헤더가 요청에 대해 설정됩니다.

또한 " Cache-Control/Expires 헤더 사용 " 옵션을 선택하면 Cache-Control / Expires 값이 현재 시간에 대해 확인됩니다. 요청이 GET 요청이고 타임스탬프가 미래의 것이라면 샘플러는 원격 서버에서 URL을 요청하지 않고 즉시 반환합니다. 이것은 브라우저 동작을 에뮬레이트하기 위한 것입니다. Cache-Control 헤더가 " no-cache "인 경우 응답은 사전 만료된 것으로 캐시에 저장되므로 조건부 GET 요청이 생성됩니다. Cache-Control 에 다른 값이 있으면 " max -age" 만료 옵션은 항목 수명을 계산하기 위해 처리되며 누락된 경우 만료 헤더가 사용되며 누락된 항목도 마지막 수정 시간 및 응답 날짜 를 사용하여 RFC 2616 섹션 13.2.4 에 지정된 대로 캐시됩니다.

쿠키 관리자 요소에는 두 가지 기능이 있습니다.
첫째, 웹 브라우저처럼 쿠키를 저장하고 전송합니다. HTTP 요청이 있고 응답에 쿠키가 포함된 경우 쿠키 관리자는 자동으로 해당 쿠키를 저장하고 해당 특정 웹 사이트에 대한 모든 향후 요청에 사용합니다. 각 JMeter 스레드에는 자체 "쿠키 저장 영역"이 있습니다. 따라서 세션 정보를 저장하기 위해 쿠키를 사용하는 웹 사이트를 테스트하는 경우 각 JMeter 스레드에는 고유한 세션이 있습니다. 이러한 쿠키는 쿠키 관리자 디스플레이에 나타나지 않지만 View Results Tree Listener를 사용하여 볼 수 있습니다.

JMeter는 수신된 쿠키가 URL에 유효한지 확인합니다. 즉, 도메인 간 쿠키가 저장되지 않습니다. 버그가 있는 동작이 있거나 도메인 간 쿠키를 사용하려면 JMeter 속성 " CookieManager.check.cookies=false "를 정의하십시오.

수신된 쿠키는 JMeter 스레드 변수로 저장할 수 있습니다. 쿠키를 변수로 저장하려면 " CookieManager.save.cookies=true " 속성을 정의하십시오. 또한 쿠키 이름에는 저장되기 전에 " COOKIE_ "가 접두사로 붙습니다(이렇게 하면 지역 변수가 우발적으로 손상되는 것을 방지할 수 있습니다). 원래 동작으로 되돌리려면 " CookieManager.name.prefix= " 속성을 정의하십시오(하나 이상의 공백). 활성화되면 이름이 TEST 인 쿠키의 값을 ${COOKIE_TEST} 로 참조할 수 있습니다 .

둘째, 쿠키 관리자에 쿠키를 수동으로 추가할 수 있습니다. 그러나 이렇게 하면 쿠키가 모든 JMeter 스레드에서 공유됩니다.

이러한 쿠키는 훨씬 먼 미래의 만료 시간으로 생성됩니다.

null 값이 있는 쿠키는 기본적으로 무시됩니다. 이것은 JMeter 속성을 설정하여 변경할 수 있습니다. CookieManager.delete_null_cookies=false . 이는 수동으로 정의된 쿠키에도 적용됩니다. 이러한 쿠키는 업데이트될 때 디스플레이에서 제거됩니다. 또한 쿠키 이름은 고유해야 합니다. 동일한 이름으로 두 번째 쿠키가 정의되면 첫 번째 쿠키가 대체됩니다.

이 요소를 사용하면 HTTP 요청 컨트롤러가 사용하는 기본값을 설정할 수 있습니다. 예를 들어, 25개의 HTTP 요청 컨트롤러가 있는 테스트 계획을 만들고 모든 요청이 동일한 서버로 전송되는 경우 " 서버 이름 또는 IP " 필드가 채워진 단일 HTTP 요청 기본값 요소를 추가할 수 있습니다. 그런 다음 , 25개의 HTTP 요청 컨트롤러를 추가할 때 " 서버 이름 또는 IP " 필드를 비워 둡니다. 컨트롤러는 HTTP 요청 기본값 요소에서 이 필드 값을 상속합니다.

헤더 관리자를 사용하면 HTTP 요청 헤더를 추가하거나 재정의할 수 있습니다.

JMeter는 이제 여러 헤더 관리자를 지원합니다 . 헤더 항목이 병합되어 샘플러에 대한 목록을 형성합니다. 병합할 항목이 기존 헤더 이름과 일치하면 이전 항목을 대체합니다. 이를 통해 기본 헤더 세트를 설정하고 특정 샘플러에 조정을 적용할 수 있습니다. 헤더의 빈 값은 기존 헤더를 제거하지 않고 해당 값을 대체할 뿐입니다.

Java 요청 기본값 구성 요소를 사용하면 Java 테스트에 대한 기본값을 설정할 수 있습니다. Java 요청 을 참조하십시오 .

키 저장소 구성 요소를 사용하면 키 저장소가 로드되는 방법과 사용할 키를 구성할 수 있습니다. 이 구성 요소는 일반적으로 응답 시간에 키 저장소 초기화를 고려하지 않으려는 HTTPS 시나리오에서 사용됩니다.

이 요소를 사용하려면 먼저 테스트하려는 클라이언트 인증서로 Java 키 저장소를 설정해야 합니다.

1. Java keytool 유틸리티 또는 PKI를 통해 인증서 생성
2. PKI로 생성한 경우 JKS에서 허용하는 형식으로 변환하여 Java Key Store에서 키를 가져옵니다.
3. 그런 다음 두 JVM 속성을 통해 키 저장소 파일을 참조하거나 system.properties 에 추가합니다 .
   • -Djavax.net.ssl.keyStore=path_to_keystore
   • -Djavax.net.ssl.keyStorePassword=password_of_keystore

PKCS11을 저장소의 소스로 사용하려면 javax.net.ssl.keyStoreType 을 PKCS11 로, javax.net.ssl.keyStore 를 NONE 으로 설정해야 합니다 .

로그인 구성 요소를 사용하면 설정의 일부로 사용자 이름과 비밀번호를 사용하는 샘플러에서 사용자 이름과 비밀번호 설정을 추가하거나 무시할 수 있습니다.

LDAP 요청 기본값 구성 요소를 사용하면 LDAP 테스트에 대한 기본값을 설정할 수 있습니다. LDAP 요청 을 참조하십시오 .

LDAP 확장 요청 기본값 구성 요소를 사용하면 확장 LDAP 테스트에 대한 기본값을 설정할 수 있습니다. LDAP 확장 요청 을 참조하십시오 .

TCP 샘플러 구성은 TCP 샘플러에 대한 기본 데이터를 제공합니다.

사용자 정의 변수 요소를 사용하면 테스트 계획 에서와 같이 초기 변수 세트 를 정의할 수 있습니다 .

UDV는 호출될 때마다 다른 결과를 생성하는 함수와 함께 사용하면 안 됩니다. 첫 번째 함수 호출의 결과만 변수에 저장됩니다. 그러나 UDV는 __P() 와 같은 함수와 함께 사용할 수 있습니다 . 예를 들면 다음과 같습니다.

호스트 ${__P(호스트, 로컬 호스트)}

JMeter 속성 " host " 의 값을 갖도록 " HOST " 변수를 정의하고 정의되지 않은 경우 기본값은 " localhost "입니다.

테스트 실행 중 변수를 정의하려면 사용자 매개변수 를 참조하십시오 . UDV는 계획에 나타나는 순서대로 위에서 아래로 처리됩니다.

단순화를 위해 UDV는 스레드 그룹의 시작 부분에만(또는 테스트 계획 자체 아래에) 배치하는 것이 좋습니다.

테스트 계획과 모든 UDV가 처리되면 결과 변수 집합이 각 스레드에 복사되어 초기 변수 집합을 제공합니다.

사용자 매개변수 전처리기 또는 정규식 추출기와 같은 런타임 요소가 UDV 변수 중 하나와 동일한 이름을 가진 변수를 정의하는 경우 이는 초기 값을 대체하고 스레드의 다른 모든 테스트 요소는 업데이트된 값을 보게 됩니다. 값.

임의 변수 구성 요소는 임의의 숫자 문자열을 생성하고 나중에 사용할 수 있도록 변수에 저장하는 데 사용됩니다. __Random() 함수 와 함께 사용자 정의 변수 를 사용하는 것보다 간단 합니다.

출력 변수는 난수 생성기를 사용하여 구성되고 결과 숫자는 형식 문자열을 사용하여 형식이 지정됩니다. 숫자는 minimum+Random.nextInt(maximum-minimum+1) 공식을 사용하여 계산됩니다 . Random.nextInt() 에는 양의 정수가 필요합니다. 이것은 최대-최소값 (즉, 범위)이 2147483647 보다 작아야 함을 의미합니다 . 그러나 최소값 과 최대 값은 범위가 정상인 한 긴 값 이 될 수 있습니다 .

사용자가 스레드 그룹의 어디에서나 참조할 수 있는 카운터를 만들 수 있습니다. 카운터 구성을 통해 사용자는 시작점, 최대값 및 증분을 구성할 수 있습니다. 카운터는 처음부터 최대까지 반복한 다음 처음부터 다시 시작하여 테스트가 끝날 때까지 계속합니다.

카운터는 값을 저장하기 위해 long을 사용하므로 범위는 -2^63 ~ 2^63-1 입니다.

단순 구성 요소를 사용하면 샘플러에서 임의의 값을 추가하거나 재정의할 수 있습니다. 값의 이름과 값 자체를 선택할 수 있습니다. 일부 모험적인 사용자는 이 요소의 용도를 찾을 수 있지만 여기서는 주로 개발자를 위한 기본 GUI로 새 JMeter 구성 요소를 개발하는 동안 사용할 수 있습니다.

그런 다음 이 코드를 사용하여 MongoDBHolder 요소를 통해 Beanshell 또는 JSR223 테스트 요소의 com.mongodb.DB 개체에 액세스할 수 있습니다.

수입 com.mongodb.DB;
org.apache.jmeter.protocol.mongodb.config.MongoDBHolder 가져오기;
DB db = MongoDBHolder.getDBFromSource("MongoDB 소스 속성 값",
            "속성 데이터베이스 이름의 값");
…
    

응답 어설션 제어판을 사용하면 요청 또는 응답의 다양한 필드와 비교할 패턴 문자열을 추가할 수 있습니다. 패턴 문자열은 다음과 같습니다.

• 포함 , 일치 : Perl5 스타일 정규식
• Equals , Substring : 일반 텍스트, 대소문자 구분

패턴 일치 문자의 요약은 ORO Perl5 정규식에서 찾을 수 있습니다.

문자열이 전체 응답 과 일치 할 것으로 예상되는지 또는 응답에 패턴 만 포함 할 것으로 예상되는지 여부를 선택할 수도 있습니다 . 추가 유연성을 위해 모든 컨트롤러에 여러 어설션을 연결할 수 있습니다.

패턴 문자열은 둘러싸는 구분 기호를 포함하지 않아야 합니다. 즉 /Price: \d+/ 가 아닌 Price: \d + 를 사용 합니다.

기본적으로 패턴은 여러 줄 모드에 있습니다. 즉, " . " 메타 문자가 줄 바꿈과 일치하지 않습니다. 여러 줄 모드에서 " ^ " 및 " $ "는 전체 문자열의 시작과 끝이 아니라 문자열 내의 모든 줄의 시작 또는 끝과 일치합니다. \s 는 개행과 일치합니다 . 경우도 중요합니다. 이러한 설정을 재정의하려면 확장된 정규식 구문을 사용할 수 있습니다. 예를 들어:

(?나)

대소문자 무시

(?에스)

대상을 한 줄로 취급합니다. 즉 " . "는 개행과 일치 합니다.

(?이다)

위의 둘 다

(?i)사과(?-i) 파이

" AppLE Pie " 는 일치 하지만 " AppLE pIe " 는 일치하지 않습니다.

(?s)애플.+?파이

다음 줄에 있을 수 있는 Apple 다음에 Pie 와 일치 합니다.

사과(?s).+?파이

위와 같지만 처음에 (?s) 를 사용하는 것이 더 명확할 것 입니다.

Duration Assertion은 각 응답이 주어진 시간 내에 수신되었는지 테스트합니다. 주어진 시간(밀리초)보다 오래 걸리는 응답(사용자가 지정)은 실패한 응답으로 표시됩니다.

Size Assertion은 각 응답에 올바른 수의 바이트가 포함되어 있는지 테스트합니다. 크기가 주어진 바이트 수와 같거나, 크거나, 작거나, 같지 않음을 지정할 수 있습니다.

XML Assertion은 응답 데이터가 형식적으로 올바른 XML 문서로 구성되어 있는지 테스트합니다. DTD 또는 스키마를 기반으로 하는 XML의 유효성을 검사하거나 추가 유효성 검사를 수행하지 않습니다.

BeanShell 주장은 사용자가 BeanShell 스크립트를 사용하여 주장 확인을 수행할 수 있도록 합니다.

BeanShell 사용에 대한 자세한 내용은 BeanShell 웹사이트를 참조하십시오.

테스트 스크립트의 각 스레드에서 어설션이 독립적으로 발생할 때마다 다른 인터프리터가 사용되지만 후속 호출에는 동일한 인터프리터가 사용됩니다. 이는 변수가 어설션에 대한 호출 간에 지속됨을 의미합니다.

모든 어설션은 샘플러와 동일한 스레드에서 호출됩니다.

" beanshell.assertion.init " 속성 이 정의되면 소스 파일의 이름으로 인터프리터에 전달됩니다. 이것은 공통 메소드 및 변수를 정의하는 데 사용할 수 있습니다. bin 디렉토리 에 샘플 초기화 파일이 있습니다 : BeanShellAssertion.bshrc

테스트 요소는 ThreadListener 및 TestListener 메서드를 지원합니다. 이들은 초기화 파일에 정의되어야 합니다. 예제 정의 는 BeanShellListeners.bshrc 파일을 참조하십시오 .

MD5Hex Assertion을 통해 사용자는 응답 데이터의 MD5 해시를 확인할 수 있습니다.

HTML Assertion을 사용하면 JTidy를 사용하여 응답 데이터의 HTML 구문을 확인할 수 있습니다.

XPath 어설션은 문서의 형식이 올바른지 테스트하고 DTD에 대해 유효성을 검사하거나 JTidy를 통해 문서를 배치하고 XPath를 테스트하는 옵션이 있습니다. 해당 XPath가 존재하는 경우 어설션은 true입니다. " / "를 사용하면 올바른 형식의 모든 문서와 일치하며 기본 XPath 표현식입니다. 어설션은 " count(//*error)=2 " 와 같은 부울 표현식도 지원합니다 . XPath에 대한 자세한 내용 은 http://www.w3.org/TR/xpath 를 참조 하십시오.

• //title[text()='일치할 텍스트'] - 응답의 모든 위치에서 <title>일치할 텍스트</title>와 일치 합니다.
• /title[text()='일치할 텍스트'] - 응답의 루트 수준에서 <title>일치할 텍스트</title>와 일치

XPath2 Assertion은 문서가 제대로 구성되었는지 테스트합니다. " / "를 사용하면 올바른 형식의 모든 문서와 일치하며 기본 XPath2 표현식입니다. 어설션은 " count(//*error)=2 " 와 같은 부울 표현식도 지원합니다 .

• //title[text()='일치할 텍스트'] - 응답의 모든 위치에서 <title>일치할 텍스트</title>와 일치 합니다.
• /title[text()='일치할 텍스트'] - 응답의 루트 수준에서 <title>일치할 텍스트</title>와 일치

XML Schema Assertion을 사용하면 사용자가 XML Schema에 대한 응답의 유효성을 검사할 수 있습니다.

JSR223 Assertion을 사용하면 JSR223 스크립트 코드를 사용하여 이전 샘플의 상태를 확인할 수 있습니다.