🥇Fronty a JMeter: výměna s Publisherem a Subscriberem

Ahoj, Habr! Toto je sequel mého předchozí publikace, ve kterém vám povím o možnostech umístění zpráv do front pomocí JMeter.

Vytváříme datový kanál pro velkou federální společnost. Různé formáty požadavků, transformace, složité směrování. Pro testování je potřeba posílat mnoho zpráv do fronty. Ručně – to je bolest, se kterou si ne každý tester poradí.

Úvod

I když s touto bolestí jsme se museli smířit na začátku. Všechno začalo s RFHUtil. Silný, ale nepohodlný a děsivý: No, víte, jaký je Rus.

Nezbytný v některých případech, ale stabilně padá při aktivním používání.
Pohodlné testování s ním není možné.

S JMeter se všechno stalo jednodušší. Po prvním kroku s osvojením a přizpůsobením se objevila naděje na šťastné testování.

Aktivně používám vzorkovače JMS Publisher a JMS Subscriber. Na rozdíl od JMS Point-to-Point, tato dvojice se mi zdá pohodlnější na práci. Například u Subscriber v JMS Selector můžete uvést proměnnou, u Point-to-Point – ne (nebo to není příliš zřejmé).

Příprava vzorkovačů

JMS Publisher

Nastavení – Každý vzorek. Apache doporučuje použít tuto možnost, pokud jsou fronty/témata zadána prostřednictvím proměnných.
Expiration (ms) = 120000. V případě selhání testovací požadavky zmizí z fronty po 2 minutách.
Použít režim doručení jako nepersistentní? – true. IBM tvrdí, že persistentní režim zajišťuje spolehlivé uložení přenášených zpráv v případě náhlého selhání. A rychlejší výměnu v nepersistentním režimu. Pro testovací účely je důležitější rychlost.

U každého Publishera nastavím jms-vlastnost, kterou Subscriber bude používat v JMS Selector. Pro každé odeslání se generuje náhodná hodnota v prvku testovacího plánu User Parameters:

Tak můžeme mít jistotu, že bylo přečteno správné zpráva.

Konečná "šablona" přednastaveného JMS Publishera:

JMS Subscriber

Nastavení – Každý vzorek. No, chápete.
Timeout (ms) = 100000. Pokud požadavek nepřichází do fronty po 100 sekundách čekání, něco není v pořádku.
Zastavit mezi vzorkem? – true.

JMS Selector – docela pohodlná věc. Konečný JMS Subscriber:

Jak se vyrovnat s cyrilicí v předávaných zprávách. V JMeter se ve výchozím nastavení po načtení zobrazuje nesprávně. Abychom se tomu vyhnuli a vychutnávali si velký a mocný vždy a všude, musíme:

Přidat do "spouštěče" JMeter argument JVM:
```
-Dfile.encoding=UTF-8
```
Přidat JSR223 PostProcessor do Subscriber s řádkou na groovy:
```
prev.setDataEncoding("UTF-8")
```

Předání textu

Nejpohodlnější varianta. Vhodné pro ladění nově napsaných testů. Nebo pro případy, kdy je potřeba odeslat alespoň něco malého. Zvolit možnost Zpráva zdroj — Textové pole a umístit tělo zprávy do textového bloku:

Přenos souboru

Nejčastější varianta. Vhodné pro většinu scénářů. Zvolit možnost Zpráva zdroj — Z souboru a uvést cestu ke zprávě v poli Soubor — Název souboru:

Přenos souboru do textového pole

Nejvíce univerzální varianta. Vhodné pro většinu scénářů + může být použito v JMS Point-to-Point, kde není druhá možnost odesílání:

Přenos pole bajtů

Nejkomplexnější varianta. Vhodné pro testování bezchybného přenosu požadavků po bajtech, bez zkreslení, SMS a perturnace. To nelze provést v defaultním JMetru, zde bylo mi o tom jasně řečeno.

To proto jsem musel stáhnout zdrojové kódy a modifikovat kód JMS Subscriber.

Nahradil jsem v metodě extractContent(..) řádek:

buffer.append(bytesMessage.getBodyLength() + " bajtů přijato v BytesMessage");

na:

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);
}

a znovu sestavil JMeter.

Zbývá přidat pár JSR223 Samplerů. První — před párem Publisher/Subscriber pro vytvoření DAT souboru, obsahujícího náhodné bajty:

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("soubor nenalezen");
        }

Druhý — na konci scénáře, odstraní soubor:

import java.io.File;

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

A nezapomeňte přidat cestu k souboru u Publisher:

A také kontrolu v JSR223 Assertion pro Subscriber — porovnat původní bajty s těmi, které přicházejí do fronty příjemce:

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("Porovnání selhalo");
	   SampleResult.setResponseData("Bajty se změnily","UTF-8");
     	   IsSuccess=false;
	}

Závěr

Popisal jsem čtyři způsoby odesílání zpráv do fronty, které denně používám v praxi. Doufám, že vám tyto informace usnadní život. V dalším článku plánuji vyprávět o své zkušenosti s testováním výměny, kde na jednom konci je fronta a na druhém databáze nebo souborový systém.

Chraňte svůj čas. A děkujeme za pozornost.

Zdroj: habr.com