Jmeter 사용법 튜토리얼, 설치부터 HTTP 압력 측정까지 모든 실제 전투 튜토리얼 분석, 후회하지 않는 시리즈

개발 엔지니어로서 요구 사항을 받으면 일반적으로 요구 사항을 분석하고 아이디어, 코드, 자체 테스트를 결정한 다음 테스터에게 테스트하도록 합니다. 셀프 테스트 단계에서는 개발자로서 비즈니스 프로세스가 올바른지, 논리적인 오류가 있는지 테스트하는 경우가 대부분인데, 그렇지 않으면 거의 끝나게 됩니다. 그런 다음 테스터가 테스트하러 갈 때 테스터는 개발자의 단계를 여러 번 반복하고 테스트 사례, 특히 일부 경계 사용 사례를 확장합니다. 그러나 우리의 인터페이스는 초당 10개의 요청에서는 괜찮지만 초당 1000개의 요청에서도 괜찮다는 의미는 아닙니다.인터페이스가 온라인으로 배포될 때 동시성이 증가하면 테스트 단계에서 나타나지 않았던 많은 문제가 발생하게 됩니다. 온라인에 나타납니다. 나타날 수도 있습니다.

일부 회사는 상대적으로 큰 팀을 보유하고 있으며 좋은 테스터를 고용하여 다양한 테스트를 수행할 수 있지만 소규모 팀의 경우 테스터는 초당 10개의 요청과 초당 10,000개의 요청의 차이를 알지 못할 수도 있습니다. 비즈니스 로직과 관련하여 스트레스 테스트도 수행해야 합니다.

이 기사에서는 강력한 스트레스 테스트 도구인 JMeter를 소개합니다.

JMeter는 Apache의 최상위 프로젝트입니다. 공식 소개를 살펴보세요.

Apache JMeter™ 애플리케이션은 기능적 동작을 로드 테스트하고 성능을 측정하도록 설계된 100% 순수 Java 애플리케이션인 오픈 소스 소프트웨어입니다. 원래 웹 애플리케이션 테스트용으로 설계되었지만 이후 다른 테스트 기능으로 확장되었습니다.

이는 아마도 JMeter가 순수 Java로 작성된 오픈 소스 소프트웨어로서 다양한 동작과 성능을 테스트하는 데 사용된다는 의미일 것입니다. 원래 웹 애플리케이션을 테스트하도록 설계되었지만 이후 다른 테스트로 확장되었습니다.

JMeter가 테스트를 지원할 수 있는 애플리케이션/서비스/프로토콜은 많습니다: 웹(HTTP, HTTPS), SOAP/REST 웹 서비스, FTP, JDBC를 통한 데이터베이스, LDAP, JMS를 통한 메시지 지향 미들웨어(MOM), 메일 - SMTP(S) , POP3(S) 및 IMAP(S), 기본 명령 또는 셸 스크립트, TCP, Java 개체. 어쨌든, 서버 측의 몇 가지 일반적인 사항을 테스트할 수 있습니다.

이 문서에서는 HTTP 압력 테스트를 소개합니다.

1. 다운로드

공식 웹사이트로 이동하여 다운로드 링크를 찾거나 다음 링크를 사용하여 다운로드할 수 있습니다.

http://mirror.bit.edu.cn/apache//jmeter/binaries/apache-jmeter-5.2.1.zip

다운로드 후 바로 압축을 풀면 디렉토리 구조는 다음과 같습니다.

bin: 실행 가능한 스크립트 파일

문서: JMeter에서 제공하는 API 문서

extras: 추가 파일

lib: JMeter 자체가 의존하는 jar 패키지

라이센스: JMeter가 의존하는 jar 패키지의 라이센스

printable_docs: JMeter 소개 및 매뉴얼

JMeter는 사용자가 사용할 수 있는 GUI 인터페이스를 제공할 뿐만 아니라 사용자가 조작할 수 있는 명령줄도 제공합니다.먼저 Windows에서 JMeter를 사용합니다.

2. 준비

2.1 운영환경

JMeter5에는 최소한 JDK8이 필요합니다. 컴퓨터에 JDK가 설치되어 있지 않은 경우 먼저 JDK를 설치하십시오.

2.2 인터페이스 생성

여기서는 springboot를 사용하여 인터페이스를 빠르게 구축하며, 주요 코드는 다음과 같습니다.

@GetMapping(value = "/test")
public String performanceTest(@RequestParam(value="name", defaultValue="") String name) {
    log.info("进入测试，参数name的值为:{}", name);
    if (StringUtils.isEmpty(name)) {
        return "name cannot be null";
    } else {
        return RandomUtil.generateRandomString(16);
    }
}

그 중 generateRandomString은 지정된 길이의 무작위 문자를 생성하는 메소드이다.

application.properties에 로그 파일을 지정하기만 하면 됩니다.

logging.file=spring.log

그런 다음 패키지하여 Linux에 배포하면 시작 명령은 다음과 같습니다.

java -jar stress-testing-0.0.1-SNAPSHOT.jar

그런 다음 컬 명령을 사용하여 매개변수가 있는 인터페이스와 매개변수가 없는 인터페이스에 각각 액세스하고 브라우저에서도 액세스할 수 있습니다.

3. JMeter를 사용하여 HTTP 테스트

3.1 테스트 계획 수립

더블클릭하여 bin/jmeter.bat를 열고 JMeter GUI 프로그램이 시작되기를 기다립니다.성공한 후의 모습은 다음과 같습니다. 첫 번째 시작 시 기본 언어는 영어입니다. 메뉴 표시줄의 옵션->언어 선택->중국어(간체)에서 중국어 간체로 전환할 수 있습니다.

TestPlan->추가->스레드(사용자)->스레드 그룹을 마우스 오른쪽 버튼으로 클릭하고 완료 후 스레드 그룹을 선택하고 이 스레드 그룹을 마우스 오른쪽 버튼으로 클릭하고 추가->샘플러->HTTP 요청을 선택한 다음 이 HTTP 요청에서 HTTP 요청을 선택합니다. 이를 마우스 오른쪽 버튼으로 클릭하고 추가->리스너->결과 트리 보기를 수행한 후 다시 HTTP 요청을 선택하고 이 HTTP 요청을 마우스 오른쪽 버튼으로 클릭하여 추가->리스너->보고서 집계를 수행합니다. 완료 후 그림과 같이

다음 개념을 설명해 보겠습니다.

• TestPlan: 프로젝트와 동등한 테스트 계획, 테스트해야 할 사항, 테스트 방법이 테스트 계획에 정의되어 있습니다.
• 스레드 그룹: 시뮬레이션된 요청 수에 해당하는 스레드 그룹입니다. 스레드는 사용자 요청과 동일합니다.
• 결과 트리 보기: 요청을 보낼 때 각 요청의 상태를 모니터링합니다.
• 집계 보고서: 테스트 데이터를 요약합니다.

3.2 구성 매개변수

• 테스트 계획

왼쪽에서 Test Plan을 선택하고 오른쪽의 이름은 테스트 계획의 이름이며 주석은 코드의 주석과 동일하므로 말할 것도 없습니다. 아래는 독립적으로 실행되는 스레드 그룹입니다. 테스트 계획에서 여러 스레드 그룹을 생성할 수 있습니다. (현재는 하나만 있습니다.) 예를 들어 서로 다른 인터페이스의 동시성은 다릅니다. 이 때 필요에 따라 여러 스레드를 생성할 수 있습니다. .그룹은 별도로 테스트되었습니다. 글쎄, 기본적으로 수정하지 말자.

• 스레드 그룹

왼쪽의 스레드 그룹을 선택하면 스레드 그룹에도 이름과 설명이 있습니다. 예를 들어 동시성 수준과 같은 정보를 채울 수 있지만 어쨌든 사람들이 볼 수 있습니다. 다음 스레드 속성은 핵심 구성으로, 앞서 언급한 것처럼 스레드는 사용자 요청과 동일합니다. 예를 들어 스레드 수에 10을 입력하고, 램프업 시간에 5를, 주기 수에 1을 입력합니다. 이는 5초 내에 10개의 요청이 전송되고 한 번 실행된다는 의미입니다.

• HTTP 요청

왼쪽에서 HTTP 요청을 선택합니다. 여기서는 웹 서버와 HTTP 요청의 두 가지 속성에 중점을 둡니다. 프로토콜은 요청의 프로토콜이고 기본값은 http이며 ip는 서버 주소를 채우고 도메인 이름도 채울 수 있으며 포트 번호는 8080입니다. 방금 작성된 테스트 인터페이스는 GET 요청만 지원하므로 메소드는 다음을 선택합니다. GET, 경로는 url의 요청 경로이며 GET 요청 매개변수는 경로에 직접 전달되거나 다음 매개변수에 쓰여질 수 있으며 "추가" 버튼을 클릭하여 요청 매개변수를 추가할 수 있습니다.

왼쪽의 노드는 많은 경우에 반복될 수 있지만 범위가 다르다는 점도 주목할 가치가 있습니다. 예를 들어 현재 보기 결과 트리와 집계 보고서는 HTTP 요청에 따라 생성되고 보기 결과 트리와 집계 보고서는 HTTP 결과를 수신합니다. 스레드 그룹 아래에는 여러 HTTP 요청이 있을 수 있습니다. 예를 들어 테스트할 H5 페이지가 있는 경우 이 페이지를 열면 동시에 여러 인터페이스를 요청할 수 있으며 이 경우 여러 HTTP 요청을 생성해야 합니다. Thread Group에 생성된 결과 트리와 집계 보고서를 보면 해당 Thread 그룹에 속한 모든 HTTP 요청의 결과를 모니터링하기 위한 것입니다.

3.3 테스트

인터페이스 툴바의 녹색 삼각형 버튼을 클릭하여 압력 테스트를 시작하면 spring.log 파일이 지속적으로 정보를 출력하는 것을 볼 수 있습니다.

압력 테스트가 끝날 때까지 기다린 후 왼쪽의 결과 트리를 보고 이번 테스트 라운드의 요청 상태를 확인할 수 있습니다.

요청 중 하나를 선택하면 오른쪽에서 시간, 요청 데이터 길이, 요청 주소 등 해당 요청에 대한 자세한 정보를 볼 수 있습니다.

이번 테스트 라운드의 데이터 보고서를 보려면 집계 보고서를 선택하세요.

이 보고서를 설명하려면:

샘플: 요청 수, 계산 공식은 스레드 수 * 주기 수, 스레드 그룹 구성을 영원히 확인하는 경우 테스트를 중지할 때 보낸 실제 요청 수입니다. 평균: 평균 응답입니다. 시간(밀리초)입니다
. 예를 들어, 여기에서 평균 응답 시간은 38밀리초입니다.
중앙값: 응답 시간의 중앙값(밀리초)입니다.
90% 백분위수: 응답 시간의 90%가 이 값(밀리초)보다 작습니다. 여기서 응답 시간의 90%는 22밀리초 미만입니다.
95% 백분위수: 의미는 90%와 유사합니다.
99% 백분위수: 의미는 90%와 유사합니다.
최소값: 이 테스트 라운드의 최소 응답 시간(밀리초)입니다. .
최대값: 이번 테스트 라운드의 최대 응답 시간(밀리초)입니다.
비정상적인 %: 이번 테스트 라운드에서 비정상적인 요청의 비율입니다.
처리량: 요청을 처리하기 위해 테스트한 인터페이스의 기능인 QPS로 이해할 수 있습니다. 예를 들어, 초당 평균 2.2개의 요청이 있습니다
. 수신 KB/Sec: 응답 데이터의 수신 속도
Send KB/Sec: 요청 데이터의 전송 속도가
여기에서 끝납니다. 방금 작성한 인터페이스가 완벽하고 완벽하다고 생각하십니까? 서비스가 실행되고 있나요? 결함은 없나요? 인터페이스 왼쪽에서 스레드 그룹을 선택한 다음 스레드 수를 5000으로 변경하고 나머지는 변경하지 않고 유지하여 5000명의 사용자가 5초 이내에 인터페이스를 방문하는 것으로 시뮬레이션합니다. 그런 다음 인터페이스 상단에 있는 기어 버튼과 두 개의 빗자루 버튼을 클릭하여 결과 트리와 집계 보고서를 지우고 녹색 시작 버튼을 클릭합니다. 테스트 결과는 다음과 같습니다.

동시성이 증가하면 일부 요청이 비정상적이라는 것을 알게 될 것입니다. 그런 다음 집계 보고서로 전환하면 원래 평균 응답 시간이 30밀리초 이상에 불과했지만 직접 5초 이상으로 증가했으며 비정상적인 속도도 나타나는 것을 확인할 수 있습니다. 이때 시스템 수준이나 jvm 수준에서 발생하거나 코드 자체의 문제일 수 있는 일부 오류 메시지를 기반으로 일부 튜닝을 수행해야 합니다. 이 글에서 다루고자 하는 내용은 이것이 아니므로 여기서는 다루지 않겠습니다.

넷째, JMeter에서 변수를 사용하세요. 

위의 예에서 HTTP 구성을 작성할 때 IP가 IP 주소를 직접 작성하지만 문제가 있습니다.우리 인터페이스가 다른 시스템에 노드를 배포하는 경우 다른 시스템에서 인터페이스를 테스트하는 것이므로 변경할 수 없습니다. 각 테스트마다 하나씩 서비스에서 30개의 인터페이스를 테스트하려면 인터페이스를 변경하는 것이 고통스럽지 않을까요? JMeter는 HTTP 요청에 사용할 수 있는 변수를 제공합니다.

스레드 그룹을 마우스 오른쪽 버튼으로 클릭하고 추가 -> 구성 구성 요소 -> 사용자 정의 변수를 마우스 오른쪽 버튼으로 클릭합니다. 이는 테스트 계획 또는 HTTP 요청 아래에서도 생성될 수 있으므로 범위는 전체 테스트 계획 또는 HTTP 요청입니다. 그런 다음 사용자 정의 변수를 선택하고 오른쪽에 있는 추가 버튼을 클릭하여 두 개의 변수(host 및 port)를 추가합니다.

JMeter에서 사용하는 변수는 ${}로 참조합니다. 예를 들어 호스트 변수를 참조하려면 ${host}입니다. 그런 다음 HTTP 요청을 선택하고 IP 주소와 포트를 참조 변수 형식으로 변경합니다.

그런 다음 시작 버튼을 다시 클릭하여 테스트하고 결과 보기 트리를 열어 요청이 변수에 정의된 주소로 계속 전송되는지 확인합니다.

이렇게 하면 HTTP 요청이 30개라도 사용자 정의 변수의 변수 값만 수정할 수 있습니다.

후속 테스트를 용이하게 하기 위해 먼저 스레드 수를 500으로 변경한 다음 왼쪽에서 테스트 계획을 선택한 다음 파일 -> 다른 이름으로 테스트 계획 저장을 클릭한 다음 저장 디렉터리를 선택하여 jmx 형식의 파일을 가져옵니다. 나중에 문서로 사용될 예정입니다.

다섯째, JMeter 명령줄 사용

bin/jmeter.bat를 통해 JMeter를 시작하면 다음 정보가 콘솔에 출력됩니다.

이 프롬프트에서 우리는 최소한 두 가지 정보를 알 수 있습니다.

테스트를 위해 GUI 모드를 사용하지 말고 CLI 모드를 사용하여(실제로 명령줄을 사용하여)
매개변수를 실행하면 변경될 수 있습니다
. JMeter는 순수 Java로 작성되고 JVM에서 실행되기 때문에 두 번째 점에 대해 먼저 이야기하겠습니다. 따라서 그 동작은 JVM 매개변수에 의해 제어되며 기본 힙 크기는 1G(초기값 Xms 및 최대값 Xmx 모두 1G)이고 최대 Metaspace는 256M(JDK8에는 영구 생성 개념이 없으므로 대신 Metaspace를 사용하십시오) ). bin/jmeter.bat에는 JVM 매개변수를 설정하는 데 사용되는 행(150행)이 있습니다.

set HEAP=-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m

예를 들어 세 개의 매개변수를 두 배로 늘린 다음 다시 시작하면 JVM 매개변수가 변경된 것을 확인할 수 있습니다.

하지만 관계자는 시작 스크립트를 직접 수정하는 것을 권장하지 않고, bin 디렉터리에 setenv.bat를 생성하고 그 안에 실행 매개변수를 설정할 것을 제안합니다(Tomcat의 jvm 매개변수를 구성한 경우 익숙할 것입니다). 이 접근 방식), jmeter.bat 파일의 HEAP 매개 변수를 원래 값으로 변경한 후 bin 디렉터리에 setenv.bat 파일을 만들고 다음 내용을 작성합니다.

set HEAP=-Xms2g -Xmx2g -XX:MaxMetaspaceSize=512m

JMeter를 다시 시작하고 다음과 같이 JVM 매개변수를 다시 확인하세요.

위는 JMeter의 동작 파라메타 설정인데, 이렇게 말씀드리는 목적은 사실 첫 번째 포인트와 관련이 있습니다. 당사 서버는 기본적으로 Linux 시스템이며, 당사 서버에 GUI 운영 인터페이스를 설치해서는 안 되는데, 이는 서비스 실행에 쓸모가 없을 뿐만 아니라 많은 CPU 및 메모리 리소스를 소모하고 서버를 쓸모 없게 만들 수도 있기 때문입니다. . 이것이 바로 JMeter가 테스트에 GUI를 사용하지 말 것을 권장하는 이유입니다. 이 경우 JMeter가 GUI 인터페이스를 제공하는 이유는 무엇입니까? JMeter의 시작 콘솔을 다시 살펴보면 다음과 같은 정보가 있습니다.

jmeter -n -t [jmx file] -l [results file] -e -o [Path to web report folder]

여기서는 매개변수 -t에 이어 jmx 파일을 중점적으로 살펴보겠습니다. 이 파일은 위에서 저장한 jmx 파일로, JMeter 압력 테스트에 필요한 스레드 그룹, HTTP 요청과 같은 구성 매개변수가 저장되어 있습니다. 열어보면 실제로는 다양한 매개변수가 포함된 xml 형식의 파일임을 알 수 있는데, GUI 인터페이스가 없으면 사용자가 이러한 구성 파일을 직접 작성하는 것은 매우 번거로울 것입니다.

지금까지 jmeter 명령의 매개변수를 공식적으로 소개하겠습니다. jmeter의 전체 매개변수는 jmeter -?를 통해 볼 수 있습니다. 다음은 일반적으로 사용되는 몇 가지 매개변수입니다.

-n: 비 GUI 모드, 실제로는 명령줄 모드입니다.

-t: 뒤에 테스트 파일(jmx 파일)이 옵니다.

-l: 뒤에 로그 파일이 오고, 테스트 프로세스를 로그 파일에 출력합니다.

-e: 테스트 종료 후 보고서 생성

-o: 테스트 보고서 저장 디렉터리, 빈 디렉터리여야 함

아래 명령줄 테스트를 사용하세요.

완료되면 지정된 디렉터리에 html 형식의 테스트 보고서가 생성됩니다. 그 중 index.html이 있는데, 이를 열면 상사에게 보여줄 수 있는 매우 아름다운 그래픽 보고서를 볼 수 있습니다.

6. 분산 테스트 

위의 작업은 머신에서의 작업이므로 이런 문제가 있을 것입니다. 스레드 수를 10으로 설정하고 4코어 CPU 머신에서 실행하면 이 머신은 물론 10개의 스레드를 시뮬레이션합니다. 문제는 없지만, 스레드 수를 10,000개로 늘리면 표면적으로 이 기계도 10,000개의 스레드를 시뮬레이션하려고 시도하지만 코어 수는 4개에 불과합니다. 실제로 운영 체제는 맨 아래에서 지속적으로 스레드를 전환하고 있습니다. 이 10,000개의 스레드를 시뮬레이션하려면 , 스레드를 전환하는 데 시간이 걸리고 요청을 보내는 데 시간이 걸립니다. 이런 식으로 테스트 시스템의 CPU 사용률이 100%로 치솟는 것 외에도 부정확하거나 잘못된 데이터를 얻을 수도 있습니다. 실제로 기계는 5초 안에 이러한 10,000개의 요청을 보낼 수 있는 방법이 없습니다. 이때 여러 시스템을 사용하여 동시에 인터페이스 시스템에 요청을 보내야 하는데 이는 분산 테스트입니다.

일반적인 원리에 대해 말씀드리자면, 여러 대의 머신을 준비하는데 그 중 하나는 마스터 머신으로 나머지는 슬레이브 머신으로 사용됩니다. 마스터 머신은 명령을 보내고 슬레이브 머신은 이를 실행합니다. 다이어그램은 다음과 같습니다:

이 기계의 요구 사항은 다음과 같습니다.

방화벽을 닫거나 해당 포트를 엽니다.

동일한 서브넷에

JMeter는 테스트 인터페이스에 액세스할 수 있습니다.

JMeter 버전이 일치하고, JDK 버전도 일치하지 않으면 오류가 발생할 수 있습니다.

RMI에 대해 SSL을 설정하거나 꺼야 합니다.

위의 조건이 충족되면 먼저 각 슬레이브의 bin 디렉터리에서 jmeter-server를 실행한 다음 마스터 시스템에서 JMeter bin/jmeter.properties 파일을 개발하고 remote_hosts=127.0.0.1 줄을 찾아 다음으로 변경합니다. 슬레이브 인트라넷 주소, 주소는 영어 쉼표로 구분된 다음 마스터 시스템에서 JMeter를 열고 단일 시스템처럼 테스트합니다.

기계가 너무 많지 않으므로 여기서는 시연하지 않겠습니다.

마지막으로 제 글을 주의 깊게 읽어주신 모든 분들께 감사의 말씀을 전하고 싶습니다. 호혜는 언제나 필요합니다. 그다지 귀중한 것은 아니지만 필요하다면 가져갈 수 있습니다.

소프트웨어 테스팅 인터뷰 애플릿

수백만 명의 사람들이 참여하는 소프트웨어 테스트 문제 은행! ! ! 누가 아는가! ! ! 전체 네트워크에서 가장 포괄적인 퀴즈 미니 프로그램으로, 지하철이나 버스에서 휴대폰을 사용하여 퀴즈를 풀 수 있습니다!

다음 인터뷰 질문 섹션을 다룹니다.

1. 소프트웨어 테스팅의 기본이론, 2. 웹, 앱, 인터페이스 기능 테스팅, 3. 네트워크, 4. 데이터베이스, 5. 리눅스

6. 웹, 앱, 인터페이스 자동화, 7. 성능 테스트, 8. 프로그래밍 기초, 9. 시간 인터뷰 질문, 10. 공개 테스트 질문, 11. 보안 테스트, 12. 컴퓨터 기초

이 자료는 [소프트웨어 테스트] 친구들을 위한 가장 포괄적이고 완전한 준비 창고가 되어야 합니다. 이 창고는 또한 가장 어려운 여정을 통해 수만 명의 테스트 엔지니어와 동행했습니다. 당신에게도 도움이 되기를 바랍니다!