🥇Редици и JMeter: размена со издавач и претплатник

Здраво, Хабр! Ова е продолжение на моето претходната публикација, во која ќе зборувам за опции за поставување пораки во редици користејќи JMeter.

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

Вовед

Иако на почетокот морав да ја трпам оваа болка. Сè започна со RFHUtil. Моќен, но незгоден и страшен: Па, знаете Рус.

Незаменлив во некои случаи, но постојано се намалува во случај на активна употреба.
Со него е невозможно практично тестирање.

Со JMeter сè стана полесно. По првата фаза на совладување и навикнување на тоа, надежта почна да изгрева за среќно тестирање.

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

Подготовка на семплери

JMS Publisher

Поставување - секој примерок. Апачи препорачува користете ја оваа опција ако редици/теми се наведени преку променливи.
Истекување (ms) = 120000. Во случај на неуспех, барањата за тестирање ќе исчезнат од редот по 2 минути.
Да се користи режимот на неупорна испорака? - вистина. IBM одобруватој постојан режим обезбедува сигурно зачувување на пренесените пораки во случај на ненадеен дефект. И побрза размена во неупорен режим. За цели на тестирање, брзината е поважна.

Во секој Publisher поставувам својство jms што претплатникот ќе го користи во избирачот JMS. За секое поднесување, се генерира случајна вредност во елементот за тест план за кориснички параметри:

На овој начин можете да бидете сигурни дека е прочитана точната порака.

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

Претплатник JMS

Поставување - секој примерок. Па, разбираш.
Истекување (ms) = 100000. Ако барањето не пристигне во редот по 100 секунди чекање, тогаш нешто тргна наопаку.
Застанете помеѓу примероците? - вистина.

JMS селектор - доста удобен нешто. Конечен претплатник на JMS:

Како да се справите со кирилицата во пренесените пораки. Во JMeter стандардно по лекторирање се прикажува криво. За да го избегнете ова и да уживате во големото и моќно секогаш и секаде, треба:

Додајте аргумент за JVM на „фрлачот“ на JMeter:
```
-Dfile.encoding=UTF-8
```
Додајте JSR223 PostProcessor на претплатникот со groovy линија:
```
prev.setDataEncoding("UTF-8")
```

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

Најмрзливата опција. Погоден за дебагирање на свежо напишани тестови. Или за случаи кога треба да испратите барем нешто мало. Изберете опција Извор на порака - Textarea и ставете го телото на пораката во текстуален блок:

Пренос на датотеки

Најчеста опција. Погоден за повеќето сценарија. Изберете опција Извор на порака - Од датотека и во полето наведете ја патеката до пораката Датотека - Име на датотека:

Пренесување датотека во текстуално поле

Најразновидна опција. Погодно за повеќето сценарија + може да се користи во JMS Point-to-Point каде што нема втора опција за испраќање:

Предавање низа бајти

Најтешката опција. Погоден за проверка на непогрешливо прецизно пренесување на барања до бајт, без изобличување, СМС и пертурбации. Нема да можете да го направите ова во стандардниот 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 for Subscriber - споредете ги изворните бајти со оние што пристигнуваат во редот на примачот:

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

Редици и JMeter: споделување со издавачот и претплатникот