🥇Čakalne vrste in JMeter: deljenje z založnikom in naročnikom

Pozdravljeni, Habr! To je nadaljevanje mojega prejšnja objava, v katerem bom govoril o možnostih za uvrščanje sporočil v čakalne vrste z uporabo JMeter.

Izdelujemo podatkovno vodilo za veliko zvezno podjetje. Različni formati zahtev, transformacije, zapleteno usmerjanje. Za testiranje morate v čakalno vrsto poslati veliko sporočil. Ročno je bolečina, ki je ne more obvladati vsak kiropraktik.

Predstavitev

Čeprav sem s to bolečino najprej morala potrpeti. Vse se je začelo z RFHUtil. Močno, a nerodno in strašljivo: No, saj poznate Rusa.

V nekaterih primerih nepogrešljiv, vendar vztrajno upada ob aktivni uporabi.
Priročno testiranje je z njim nemogoče.

Z JMeter je vse postalo lažje. Po prvi stopnji osvajanja in privajanja se je začelo porajati upanje na srečno testiranje.

Aktivno uporabljam vzorčevalnika JMS Publisher in JMS Subscriber. Za razliko od JMS Point-to-Point se je ta par zdel bolj priročen za uporabo. Na primer, s Subscriberjem v JMS Selector lahko podate spremenljivko, s Point-to-Point pa tega ne morete (ali pa ta metoda ni zelo očitna).

Priprava vzorčevalnikov

Založba JMS

Nastavitev – vsak vzorec. Apache priporoča uporabite to možnost, če so čakalne vrste/teme podane prek spremenljivk.
Potek (ms) = 120000. V primeru napake bodo testne zahteve izginile iz čakalne vrste po 2 minutah.
Ali želite uporabiti netrajni način dostave? - prav. IBM zahtevkita vztrajni način zagotavlja zanesljivo ohranitev poslanih sporočil v primeru nenadne okvare. In hitrejša izmenjava v netrajnem načinu. Za namene testiranja je hitrost bolj pomembna.

V vsakem Publisherju nastavim lastnost jms, ki jo bo naročnik uporabil v JMS Selectorju. Za vsako predložitev se v elementu preskusnega načrta uporabniških parametrov ustvari naključna vrednost:

Tako ste lahko prepričani, da je prebrano pravilno sporočilo.

Zadnji "prazen" vnaprej konfiguriran JMS Publisher:

Naročnik JMS

Nastavitev – vsak vzorec. No, razumeš.
Časovna omejitev (ms) = 100000. Če zahteva ne prispe v čakalno vrsto po 100 sekundah čakanja, je šlo nekaj narobe.
Ustavitev med vzorci? - prav.

JMS Selector - precej priročno stvar. Končni naročnik JMS:

Kako ravnati s cirilico v poslanih sporočilih. V JMeterju se privzeto po lektoriranju prikaže krivo. Da bi se temu izognili in uživali v velikem in močnem vedno in povsod, morate:

Dodajte argument JVM v »zaganjalnik« JMeter:
```
-Dfile.encoding=UTF-8
```
Dodajte postprocesor JSR223 naročniku z groovy line:
```
prev.setDataEncoding("UTF-8")
```

Pošlji besedilo

Najbolj lena možnost. Primerno za razhroščevanje sveže napisanih testov. Ali za primere, ko morate poslati vsaj nekaj malega. Izberite možnost Vir sporočila - Textarea in postavite telo sporočila v besedilni blok:

Prenos datoteke

Najpogostejša možnost. Primerno za večino scenarijev. Izberite možnost Vir sporočila - iz datoteke in v polju navedite pot do sporočila Datoteka – ime datoteke:

Prenos datoteke v besedilno polje

Najbolj vsestranska možnost. Primerno za večino scenarijev + lahko se uporablja v JMS Point-to-Point, kjer ni druge možnosti pošiljanja:

Posredovanje niza bajtov

Najtežja možnost. Primeren za preverjanje nezmotljivo natančnega prenosa zahtev do bajta, brez popačenja, SMS-ov in motenj. Tega ne boste mogli narediti v privzetem JMeterju. tukaj Vsekakor so mi povedali o tem.

Zato sem moral prenesti viri in spremenite koda Naročnik JMS.

Zamenjano v metodi extractContent(..) možganska kap:

buffer.append(bytesMessage.getBodyLength() + " bytes received in 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);
}

in obnovil JMeter.

Vse, kar ostane, je dodati nekaj vzorčevalnikov JSR223. Prvi je pred parom izdajatelj/naročnik za ustvarjanje datoteke DAT, ki vsebuje naključne bajte:

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

Drugi - na koncu skripta izbriše datoteko:

import java.io.File;

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

In ne pozabite dodati poti do datoteke v Publisherju:

In tudi preverjanje v trditvi JSR223 za naročnika - primerjajte izvorne bajte s tistimi, ki prispejo v čakalno vrsto prejemnika:

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

Zaključek

Opisal sem štiri načine pošiljanja sporočil v čakalne vrste, ki jih vsakodnevno uporabljam v praksi. Upam, da vam bodo te informacije olajšale življenje. V nadaljevanju nameravam spregovoriti o svoji izkušnji testiranja izmenjave, kjer je na enem koncu čakalna vrsta, na drugem pa baza podatkov ali datotečni sistem.

Prihranite čas. In hvala za vašo pozornost.

Vir: www.habr.com