Опашки и JMeter: споделяне с издател и абонат

Здравей, Хабр! Това е продължение на моето предишна публикация, в който ще говоря за опциите за поставяне на съобщения в опашки с помощта на JMeter.

Правим шина за данни за голяма федерална компания. Различни формати на заявки, трансформации, сложно маршрутизиране. За тестване трябва да изпратите много съобщения на опашката. Ръчното е болка, с която не всеки хиропрактик може да се справи.

въведение

Въпреки че в началото трябваше да търпя тази болка. Всичко започна с RFHUtil. Силно, но неудобно и страшно: Е, познавате Рус.

Незаменим в някои случаи, но постоянно намалява при активна употреба.
Удобното тестване е невъзможно с него.

С JMeter всичко стана по-лесно. След първия етап на усвояване и свикване започна да се появява надежда за щастливо тестване.

Активно използвам семплерите JMS Publisher и JMS Subscriber. За разлика от JMS Point-to-Point, тази двойка изглеждаше по-удобна за използване. Например с Subscriber в JMS Selector можете да посочите променлива, но с Point-to-Point не можете (или този метод не е много очевиден).

Подготовка на проби

JMS издател

• Настройка - всяка проба. Apache препоръчва използвайте тази опция, ако опашки/теми са посочени чрез променливи.
• Изтичане (ms) = 120000. В случай на неуспех, заявките за тест ще изчезнат от опашката след 2 минути.
• Да се ​​използва ли непостоянен режим на доставка? - вярно. IBM исковетози постоянен режим гарантира надеждно запазване на предадените съобщения в случай на внезапна повреда. И по-бърз обмен в непостоянен режим. За целите на тестването скоростта е по-важна.

Във всеки Publisher задавам свойство jms, което абонатът ще използва в JMS Selector. За всяко подаване се генерира произволна стойност в елемента на тестовия план на потребителските параметри:

По този начин можете да сте сигурни, че правилното съобщение е прочетено.

Последната „заготовка“ на предварително конфигуриран JMS Publisher:

JMS абонат

• Настройка - всяка проба. Е, разбирате.
• Изчакване (ms) = 100000 100. Ако заявката не пристигне в опашката след XNUMX секунди чакане, значи нещо се е объркало.
• Спиране между пробите? - вярно.

JMS Selector - доста удобно нещо. Краен JMS абонат:

Как да се справим с кирилицата в предаваните съобщения. В JMeter по подразбиране след корекция се показва накриво. За да избегнете това и да се наслаждавате на великото и мощно винаги и навсякъде, трябва:

1. Добавете JVM аргумент към JMeter „стартовия панел“:

   -Dfile.encoding=UTF-8

2. Добавяне на постпроцесор JSR223 към абоната с groovy линия:

   prev.setDataEncoding("UTF-8")

Изпратете текст

Най-мързеливият вариант. Подходящ за отстраняване на грешки в прясно написани тестове. Или за случаите, когато трябва да изпратите поне нещо малко. Изберете опция Източник на съобщение - Textarea и поставете тялото на съобщението в текстов блок:

Прехвърляне на файлове

Най-често срещаният вариант. Подходящ за повечето сценарии. Изберете опция Източник на съобщение - От файл и посочете пътя до съобщението в полето Файл - име на файл:

Прехвърляне на файл в текстово поле

Най-универсалният вариант. Подходящо за повечето сценарии + може да се използва в JMS Point-to-Point, където няма втора опция за изпращане:

Предаване на байтов масив

Най-трудният вариант. Подходящ за проверка на безпогрешно точното предаване на заявки до байта, без изкривяване, SMS и смущения. Няма да можете да направите това в JMeter по подразбиране. тук Определено ми казаха за това.

Така че трябваше да изтегля източници и модифицирайте код JMS абонат.

Заменен в метода extractContent(..) линия:

buffer.append(bytesMessage.getBodyLength() + " bytes received in BytesMessage");

На:

byte[] bytes = new byte[(int) bytesMessage.getBodyLength()];
bytesMessage.readBytes(bytes);
try {
	buffer.append(new String(bytes, "UTF-8"));
} catch (UnsupportedEncodingException e) {
	throw new RuntimeException(e);
}

и преустроен JMeter.

Всичко, което остава, е да добавите няколко JSR223 семплера. Първият е преди двойката Издател/Абонат за създаване на DAT файл, съдържащ произволни байтове:

import org.apache.commons.lang3.RandomUtils;

import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;

vars.put("PATH_TO_BYTES", "C:temprandomBytes.dat");
File RESULT_FILE = new File(vars.get("PATH_TO_BYTES"));
byte[] arr = RandomUtils.nextBytes((int)(Math.random()*10000));
        try {
            FileOutputStream fos = new FileOutputStream(RESULT_FILE);
            fos.write(arr);
            fos.close();
        } catch (IOException e) {
            System.out.println("file not found");
        }

Вторият - в края на скрипта, изтрива файла:

import java.io.File;

File RESULT_FILE = new File(vars.get("PATH_TO_BYTES"));
RESULT_FILE.delete();

И не забравяйте да добавите пътя към файла в Publisher:

И също така проверка в JSR223 Assertion за абонат - сравнете изходните байтове с тези, които пристигат в опашката на получателя:

import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.util.Arrays;

Path path = Paths.get(vars.get("PATH_TO_BYTES"), new String[0]);
byte[] originalArray = Files.readAllBytes(path);
byte[] changedArray = ctx.getPreviousResult().getResponseData();
System.out.println(changedArray.length);

if (Arrays.equals(originalArray, changedArray))
	{
     	SampleResult.setResponseMessage("OK");

	} else {
	   SampleResult.setSuccessful(false);
     	   SampleResult.setResponseMessage("Comparison failed");
	   SampleResult.setResponseData("Bytes have changed","UTF-8");
     	   IsSuccess=false;
	}

Заключение

Описах четири начина за изпращане на съобщения до опашки, които използвам всеки ден на практика. Надявам се тази информация да улесни живота ви. В продължение смятам да говоря за опита си от тестване на обмен, където има опашка в единия край и база данни или файлова система в другия.

Спестете си време. И благодаря за вниманието.

Източник: www.habr.com