🥇Køer og JMeter: utveksling med utgiver og abonnent

Hei, Habr! Dette er en oppfølger til min tidligere utgivelse, der jeg vil snakke om alternativer for å plassere meldinger i køer ved hjelp av JMeter.

Vi lager en databuss for et stort føderalt selskap. Ulike forespørselsformater, transformasjoner, intrikat ruting. For testing må du sende mange meldinger til køen. Manuelt er en smerte som ikke alle kiropraktorer kan håndtere.

Innledning

Selv om jeg måtte tåle denne smerten først. Det hele startet med RFHUtil. Kraftig, men vanskelig og skummel: Vel, du kjenner Rus.

Uunnværlig i noen tilfeller, men avtar stadig ved aktiv bruk.
Praktisk testing er umulig med det.

Med JMeter har alt blitt enklere. Etter den første fasen med å mestre og bli vant til det, begynte håpet å gry om lykkelig testing.

Jeg bruker aktivt JMS Publisher og JMS Subscriber samplere. I motsetning til JMS Point-to-Point, virket dette paret mer praktisk å bruke. For eksempel, med Subscriber i JMS Selector kan du spesifisere en variabel, men med Point-to-Point kan du ikke (eller denne metoden er ikke veldig åpenbar).

Klargjøring av prøvetakere

JMS utgiver

Oppsett - hver prøve. Apache anbefaler bruk dette alternativet hvis køer/emner er spesifisert via variabler.
Utløp (ms) = 120000. Ved feil vil testforespørsler forsvinne fra køen etter 2 minutter.
Vil du bruke ikke-vedvarende leveringsmodus? - sant. IBM påstanderat vedvarende modus sikrer pålitelig bevaring av overførte meldinger i tilfelle en plutselig feil. Og raskere utveksling i ikke-vedvarende modus. For testformål er hastighet viktigere.

I hver utgiver setter jeg en jms-egenskap som abonnenten vil bruke i JMS-velgeren. For hver innsending genereres en tilfeldig verdi i testplanelementet for brukerparametere:

På denne måten kan du være sikker på at riktig melding blir lest.

Den siste "blanke" av en forhåndskonfigurert JMS Publisher:

JMS-abonnent

Oppsett - hver prøve. Vel, du forstår.
Tidsavbrudd (ms) = 100000 100. Hvis forespørselen ikke kommer i køen etter XNUMX sekunders venting, så gikk noe galt.
Stopp mellom prøvene? - sant.

JMS Selector - ganske praktisk ting. Endelig JMS-abonnent:

Hvordan håndtere det kyrilliske alfabetet i overførte meldinger. I JMeter vises det som standard skjevt etter korrekturlesing. For å unngå dette og nyte det store og mektige alltid og overalt, må du:

Legg til et JVM-argument til JMeter "launcher":
```
-Dfile.encoding=UTF-8
```
Legg til JSR223 PostProcessor til abonnent med groovy linje:
```
prev.setDataEncoding("UTF-8")
```

Send tekst

Det mest late alternativet. Egnet for feilsøking av nyskrevne tester. Eller for tilfeller der du trenger å sende i det minste noe lite. Velg alternativ Meldingskilde - Textarea og plasser teksten til meldingen i en tekstblokk:

Filoverføring

Det vanligste alternativet. Passer for de fleste scenarier. Velg alternativ Meldingskilde - Fra fil og angi stien til meldingen i feltet Fil - Filnavn:

Overføre en fil til et tekstfelt

Det mest allsidige alternativet. Egnet for de fleste scenarier + kan brukes i JMS Point-to-Point der det ikke er noe andre sendealternativ:

Sender en byte-array

Det vanskeligste alternativet. Egnet for å sjekke den ufeilbarlig nøyaktige overføringen av forespørsler ned til byten, uten forvrengning, SMS og forstyrrelser. Du vil ikke kunne gjøre dette i standard JMeter. her Jeg ble definitivt fortalt om dette.

Så jeg måtte laste ned kilder og endre kode JMS-abonnent.

Erstattet i metoden extractContent(..) linje:

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

på:

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 gjenoppbygd JMeter.

Alt som gjenstår er å legge til et par JSR223-samplere. Den første er før utgiver/abonnent-paret for å lage en DAT-fil som inneholder tilfeldige byte:

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

Den andre - på slutten av skriptet, sletter filen:

import java.io.File;

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

Og ikke glem å legge til banen til filen i Publisher:

Og også en sjekk i JSR223 Assertion for Subscriber - sammenlign kildebytene med de som kommer i mottakerens 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("Comparison failed");
	   SampleResult.setResponseData("Bytes have changed","UTF-8");
     	   IsSuccess=false;
	}

Konklusjon

Jeg beskrev fire måter å sende meldinger til køer på, som jeg bruker hver dag i praksis. Jeg håper denne informasjonen gjør livet ditt enklere. I fortsettelsen planlegger jeg å fortelle om min erfaring med å teste en sentral der det er kø i den ene enden og en database eller filsystem i den andre.

Spar tid. Og takk for oppmerksomheten.

Kilde: www.habr.com

Køer og JMeter: deling med utgiver og abonnent