🥇Køer og JMeter: udveksling med Publisher og Subscriber

Hej, Habr! Dette er efterfølgeren til min den forrige publikation, hvor jeg vil fortælle om mulighederne for at placere beskeder i køer ved hjælp af JMeter.

Vi laver en databus til et stort føderalt selskab. Forskellige formater til anmodninger, transformationer, kompleks routing. For at teste er det nødvendigt at sende mange beskeder til køerne. Manuel styring er smertefuldt, og ikke alle manuelle testere kan klare det.

Introduktion

Selvom vi måtte tåle denne smerte i de første dage. Alt begyndte med RFHUtil. Kraftfuld, men besværlig og skræmmende: I ved, hvordan Rus fungerer.

Uundgåelig i nogle tilfælde, men falder konstant ned ved aktiv brug.
Praktisk testning med det er umuligt.

Med JMeter blev alt lettere. Efter det første trin med at lære og vænne sig, dukkede der håb op om en lykkelig testning.

Jeg bruger flittigt JMS Publisher og JMS Subscriber samplere. I modsætning til JMS Point-to-Point syntes denne kombination mere brugervenlig. For eksempel kan der i Subscriber i JMS Selector angives en variabel, hvilket ikke er muligt i Point-to-Point (eller måske er denne metode ikke så åbenlys).

Forberedelse af samplere

JMS Publisher

Opsætning — Hver prøve. Apache anbefaler Brug denne mulighed, hvis køer/emner er angivet via variabler.
Udløbsfrist (ms) = 120000. I tilfælde af fejl forsvinder de testede anmodninger fra køen efter 2 minutter.
Brug ikke-persistent leveringsmode? — sandt. IBM udfører, at persistent mode sikrer pålidelig bevarelse af de overførte beskeder i tilfælde af pludselig fejl. Og hurtigere udveksling i ikke-persistent mode. For testformål er hastighed vigtigere.

I hver Publisher angiver jeg jms-egenskaber, som Subscriber vil bruge i JMS Selector. For hver afsendelse genereres en tilfældig værdi i testplanens element User Parameters:

Så kan jeg være sikker på, at den rigtige besked er blevet læst.

Den endelige "skabelon" af den forudindstillede JMS Publisher:

JMS Subscriber

Opsætning — Hver prøve. Nå, I forstår.
Timeout (ms) = 100000. Hvis anmodningen ikke ankommer i køen efter 100 sekunders ventetid, så er der noget, der er gået galt.
Stop mellem prøven? — sandt.

JMS Selector — en ret praktisk ting. Den endelige JMS Subscriber:

Hvordan håndterer man kyrillisk i de overførte beskeder. I JMeter vises den som standard forkert efter udlæsning. For at undgå dette og nyde det store og mægtige altid og overalt, er det nødvendigt at:

Tilføj JVM-argumentet til "launcher" JMeter:
```
-Dfile.encoding=UTF-8
```
Tilføj en JSR223 PostProcessor til Subscriber med linjen på groovy:
```
prev.setDataEncoding("UTF-8")
```

Overførsel af tekst

Den mest dovne mulighed. Velegnet til fejlfinding af nyoprettede tests. Eller i tilfælde, hvor der skal sendes noget lille. Vælg mulighed Beskedkilde — Tekstområde og anbring beskedens indhold i tekstblokken:

Overførsel af fil

Den mest almindelige mulighed. Velegnet til de fleste scenarier. Vælg mulighed Beskedkilde — Fra fil og angiv stien til beskeden i feltet Fil — Filnavn:

Overførsel af fil i tekstfeltet

Den mest alsidige mulighed. Velegnet til de fleste scenarier + kan bruges i JMS Point-to-Point, hvor der ikke er et andet sendemåde:

Overførsel af byte-array

Den mest komplekse mulighed. Velegnet til test af fuldstændig præcis overførsel af forespørgsler ned til byte, uden forvrængninger, sms'er og forstyrrelser. Dette kan ikke gøres i standard JMeter, her blev jeg klart informeret om det.

Derfor måtte jeg downloade kildeteksterne og modificere koden JMS Subscriber.

Jeg erstattede i metoden extractContent(..) linjen:

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

til:

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

og genopbyggede JMeter.

Det er tilbage at tilføje et par JSR223 Sampler. Den første — før parret Publisher/Subscriber til at oprette en DAT-fil, der indeholder tilfældige bytes:

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("fil ikke fundet");
        }

Den anden — i slutningen af scenariet, sletter filen:

import java.io.File;

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

Og glem ikke at tilføje stien til filen hos Publisher:

Og også en kontrol i JSR223 Assertion for Subscriber — sammenligne de originale bytes med dem, der kommer til modtagerens kø:

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("Sammenligning mislykkedes");
	   SampleResult.setResponseData("Bytes er ændret", "UTF-8");
     	   IsSuccess=false;
	}

Konklusion

Jeg har beskrevet fire måder at sende beskeder i køer, som jeg bruger dagligt i praksis. Jeg håber, denne information vil gøre dit liv lettere. I fremtiden planlægger jeg at dele mine erfaringer med testning af udveksling, hvor der i den ene ende er en kø, og i den anden en database eller filsystem.

Pas på din tid. Og tak for din opmærksomhed.

Kilde: habr.com