🥇Опашки и JMeter: обмен с Publisher и Subscriber

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

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

Въведение

Въпреки че с тази болка се наложи да живеем в началото. Всичко започна с RFHUtil. Мощен, но неудобен и страшен: Знаете за какво говоря.

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

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

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

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

JMS Publisher

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

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

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

Крайният "шаблон" на предварително настроен JMS Publisher:

JMS Subscriber

Настройка — Всеки семпл. Разбрахте ме.
Време за изчакване (мс) = 100000. Ако заявката не постъпи в опашката след 100 секунди изчакване, значи нещо не е наред.
Спирка между семплите? — вярно.

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

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

Да добавим аргумент на JVM в "стартера" на JMeter:
```
-Dfile.encoding=UTF-8
```
Да добавим JSR223 PostProcessor в Subscriber със строчка на groovy:
```
prev.setDataEncoding("UTF-8")
```

Предаване на текст

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

Предаване на файл

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

Предаване на файл в текстовото поле

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

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

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

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

Замених в метода 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 Sampler. Първият — преди двойката Publisher/Subscriber за създаване на 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("файл не е намерен");
        }

Вторият — в края на сценария, изтрива файла:

import java.io.File;

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

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

А също така проверка в JSR223 Assertion за 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("Сравнението се провали");
	   SampleResult.setResponseData("Байтовете са се променили","UTF-8");
     	   IsSuccess=false;
	}

Заключение

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

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

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