🥇Järjekorrad ja JMeter: vahetus Publisher'i ja Subscriber'i vahel

Tere, Habr! See on minu eelnevas postituses, kus räägin diferentsiaalide edastamise variantidest JMeteris.

Teeme andmesilla suurele föderaalsele ettevõttele. Erinevad päringuvormingud, teisendused, keerukas marsruutimine. Testimise jaoks on vaja saata palju sõnumeid järjekordades. Kätega — valu, millega ei suuda iga käsitööline toime tulla.

Sissejuhatus

Kuigi selle valuga tuli leppida esimestel päevadel. Kõik algas RFHUtilist. Võimas, kuid ebamugav ja hirmutav: Teate küll, Rusa.

Asendamatu mõnel juhul, kuid pidevalt kukkuv aktiivse kasutamise korral.
Mugav testimine selle abil on võimatu.

JMeteriga on kõik lihtsam. Peale esimest etappi, millega tutvumine ja harjumine, säras lootus õnnelikust testimisest.

Kasutame aktiivselt JMS Publisher ja JMS Subscriber näidikuid. Erinevalt JMS Point-to-Point'ist, tundus see paari töötamine mugavam. Näiteks võimaldab Subscriberis JMS Selectoris määrata muutujat, Point-to-Pointis — ei (või see meetod ei ole eriti selge).

Näidikute ettevalmistamine

JMS Publisher

Seadistamine — Iga Proov. Apache soovitab kasutada seda valikut, kui järjekorrad/teemad on määratud muutuja kaudu.
Aegumise aeg (ms) = 120000. Rikke korral testikutsed kaovad järjekorrast kahe minuti pärast.
Kas kasutada mitte-püsivat edastamisrežiimi? — tõsi. IBM väidab, mis tähendab, et püsiv režiim tagab edastatud sõnumite usaldusväärse säilitamise äkilise rikke korral. Kiirema vahetuse jaoks mitte-püsivas režiimis. Testimise eesmärkide jaoks on kiirus olulisem.

Igas Publisheris määran jms-omaduse, mida Subscriber kasutab JMS Selectoris. Iga saatmise jaoks genereeritakse testiplaanis User Parameters juhuslik väärtus:

Nii saab olla kindel, et õige sõnum loetakse.

Lõplik „mall“ eelkonfigureeritud JMS Publisherist:

JMS Subscriber

Seadistus — Iga näide. Noh, sa said aru.
Ajutine katse (ms) = 100000. Kui päring ei jõua järjekorda 100 sekundi pärast, siis on midagi valesti läinud.
Kas peatuda näidise vahel? — tõsi.

JMS Selector — üsna mugav asi. Lõplik JMS Subscriber:

Kuidas olla kirillitsaga edastatud sõnumites. JMeteris kuvatakse see vahepeal moonutatult. Selle vältimiseks ja suure ja võimsa nautimiseks igal pool, tuleb teha:

Lisada JMeteri „käivitajale“ JVM argument:
```
-Dfile.encoding=UTF-8
```
Lisada JSR223 PostProcessor Subscriberisse koos järgnevaga groovy's:
```
prev.setDataEncoding("UTF-8")
```

Teksti edastamine

Kõige laisem variant. Sobib värskelt kirjutatud testide silumiseks või olukordadeks, kus tuleb saata vähemalt midagi väikest. Vali valik Sõnumi allikas — Tekstiala ja paiguta sõnumi sisu tekstiblokki:

Faili edastamine

Kõige sagedasem variant. Sobib enamuseks stsenaariume. Vali valik Sõnumi allikas — Failist ja täida sõnumi tee väljal Fail — Failinimi:

Faili edastamine tekstivälja

Kõige universaalsem variant. Sobib enamuseks stsenaariume + võib kasutada JMS Point-to-Point'is, kus teist saatmisvarianti pole:

Baiti massiivi edastamine

Kõige keerulisem variant. Sobib absoluutse täpsusega päringute ülekandmiseks ilma moonutusteta, SMS-ideta ja segadusteta. Seda ei saa teha vaikimisi JMeter'iga, siit seda ütlesid mulle selgelt.

Seega pidin alla laadima allikaid ja modifitseerima kood JMS Subscriber.

Asendasin meetodis extractContent(..) rea:

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

puhul:

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

ja kompileerisin JMeter'i uuesti.

Jääb lisada paar JSR223 Samplerit. Esimene — enne paarikaupa Publisher/Subscriber, et luua DAT-fail, mis sisaldab juhuslikke bite:

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("faili ei leitud");
        }

Teine — skripti lõpus, mis eemaldab faili:

import java.io.File;

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

Ja ära unusta lisada faili teed Publisheris:

Samuti kontroll Subscriberi JSR223 Assertionis — võrrelda algseid bite neid, mis jõuavad vastuvõtja järjekorda:

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("Võrdlus ebaõnnestus");
	   SampleResult.setResponseData("Bited on muutunud","UTF-8");
     	   IsSuccess=false;
	}

Kokkuvõte

Kirjeldasin nelja meetodit sõnumite saatmiseks järjekordades, mida kasutan igapäevaselt praktikas. Loodan, et see teave muudab teie elu lihtsamaks. Jätkusan kirjeldama oma kogemusi vahetamisel, kus ühel pool on järjekord ja teisel pool andmebaas või failisüsteem.

Hoidke oma aega. Ja aitäh tähelepanu eest.

Allikas: habr.com