Sorok és JMeter: megosztás a kiadóval és az előfizetővel

Szia Habr! Ez az enyém folytatása korábbi kiadvány, amelyben az üzenetek sorba helyezésének lehetőségeiről fogok beszélni a JMeter használatával.

Adatbuszt készítünk egy nagy szövetségi cég számára. Különféle kérési formátumok, átalakítások, bonyolult útválasztás. A teszteléshez sok üzenetet kell küldenie a sorba. A manuális olyan fájdalom, amelyet nem minden csontkovács képes kezelni.

Bevezetés

Bár először el kellett viselnem ezt a fájdalmat. Az egész az RFHUtil-lal kezdődött. Erőteljes, de kínos és ijesztő: Nos, tudod Rus.

Néha nélkülözhetetlen, de aktív használat esetén folyamatosan csökken.
A kényelmes tesztelés lehetetlen vele.

A JMeterrel minden könnyebbé vált. Az elsajátítás és a hozzászokás első szakasza után kezdett felvirradni a remény a boldog teszteléshez.

Aktívan használom a JMS Publisher és JMS Subscriber mintavevőket. A JMS-től eltérően pont-pont kapcsolattal ez a pár kényelmesebbnek tűnt a használata. Például a JMS Selector Subscriber funkciójával megadhat egy változót, de a Point-to-Point funkcióval nem (vagy ez a módszer nem túl nyilvánvaló).

Mintavevők előkészítése

JMS kiadó

• Beállítás – Minden minta. Apache ajánlja akkor használja ezt az opciót, ha a várólisták/témák változókon keresztül vannak megadva.
• Lejárat (ms) = 120000. Hiba esetén a tesztkérések 2 perc elteltével eltűnnek a sorból.
• Nem állandó kézbesítési módot használ? - igaz. IBM követelésekhogy a perzisztens mód biztosítja a továbbított üzenetek megbízható megőrzését hirtelen hiba esetén. És gyorsabb csere nem perzisztens módban. Tesztelési szempontból a sebesség fontosabb.

Minden kiadóban beállítok egy jms tulajdonságot, amelyet az Előfizető használni fog a JMS Selectorban. Minden egyes benyújtáshoz egy véletlenszerű érték generálódik a Felhasználói paraméterek tesztterv elemében:

Így biztos lehet benne, hogy a megfelelő üzenetet olvasta el.

Az előre konfigurált JMS Publisher végső „üres része”:

JMS előfizető

• Beállítás – Minden minta. Nos, érted.
• Időtúllépés (ms) = 100000. Ha a kérés 100 másodperces várakozás után nem érkezik meg a sorba, akkor valami hiba történt.
• Megáll a minták között? - igaz.

JMS Selector - nagyon kényelmes dolog. Végső JMS előfizető:

Hogyan kezeljük a cirill ábécét a továbbított üzenetekben. A JMeterben alapértelmezés szerint a korrektúra után ferdén jelenik meg. Ennek elkerülése és a nagyszerű és hatalmas mindig és mindenhol élvezete érdekében a következőket kell tennie:

1. Adjon hozzá egy JVM argumentumot a JMeter „indítóhoz”:

   -Dfile.encoding=UTF-8

2. Adja hozzá a JSR223 PostProcessort az előfizetőhöz groovy vonallal:

   prev.setDataEncoding("UTF-8")

Szöveg küldése

A leglustább lehetőség. Alkalmas frissen írt tesztek hibakeresésére. Vagy olyan esetekre, amikor legalább valami apróságot kell küldenie. Válasszon opciót Üzenet forrása - Textarea és helyezze az üzenet törzsét egy szövegblokkba:

Fájl átvitel

A leggyakoribb lehetőség. A legtöbb forgatókönyvhöz megfelelő. Válasszon opciót Üzenet forrása – Fájlból és a mezőben jelölje meg az üzenet elérési útját Fájl - Fájlnév:

Fájl átvitele szövegmezőbe

A legsokoldalúbb lehetőség. Alkalmas a legtöbb forgatókönyvhöz + használható JMS pont-pont között, ahol nincs második küldési lehetőség:

Egy bájttömb átadása

A legnehezebb lehetőség. Alkalmas a kérések bájtig tévedhetetlenül pontos továbbításának ellenőrzésére, torzítás, SMS és perturbáció nélkül. Ezt nem fogja tudni megtenni az alapértelmezett JMeterben. itt Nekem határozottan szóltak erről.

Szóval le kellett töltenem források és módosítani kód JMS előfizető.

Cserélve a módszerben extractContent(..) vonal:

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

on:

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

és átépítették a JMetert.

Már csak néhány JSR223 mintavevőt kell hozzáadni. Az első a kiadó/előfizető páros előtt van, hogy véletlenszerű bájtokat tartalmazó DAT-fájlt hozzon létre:

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

A második - a szkript végén törli a fájlt:

import java.io.File;

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

És ne felejtse el hozzáadni a fájl elérési útját a Publisherben:

És egy ellenőrzés a JSR223 Assertion for Subscriber programban – hasonlítsa össze a forrás byte-okat a címzett sorába érkezőkkel:

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

Következtetés

Leírtam négyféle üzenetküldési módot a sorokba, amelyeket a gyakorlatban minden nap használok. Remélem, ez az információ megkönnyíti az életét. A folytatásban azt tervezem, hogy egy olyan központ tesztelése során szerzett tapasztalataimról beszélek, ahol az egyik végén sor van, a másik végén pedig adatbázis vagy fájlrendszer.

Takarítson meg időt. És köszönöm a figyelmet.

Forrás: will.com