🥇Jonot ja JMeter: vaihto julkaisijan ja tilaajan kanssa

Hei, Habr! Tämä on jatkoa omalleni edellinen julkaisu, jossa puhun vaihtoehdoista viestien sijoittamiseksi jonoihin JMeterin avulla.

Teemme dataväylää suurelle liittovaltion yritykselle. Erilaisia pyyntömuotoja, muunnoksia, monimutkaista reititystä. Testausta varten sinun on lähetettävä paljon viestejä jonoon. Manuaalinen on kipu, jota kaikki kiropraktikot eivät voi käsitellä.

Esittely

Vaikka minun piti aluksi sietää tätä kipua. Kaikki alkoi RFHUtilistä. Voimakas, mutta kömpelö ja pelottava: No, sinä tiedät Venäjän.

Välttämätön joissakin tapauksissa, mutta vähenee jatkuvasti aktiivisessa käytössä.
Kätevä testaus on mahdotonta sen kanssa.

JMeterin avulla kaikesta on tullut helpompaa. Ensimmäisen masterointivaiheen ja siihen totuttelun jälkeen alkoi nousta toivo onnelliseen testaukseen.

Käytän aktiivisesti JMS Publisher- ja JMS Subscriber -näytteitä. Toisin kuin JMS Point-to-Point, tämä pari vaikutti kätevämmältä käyttää. Esimerkiksi JMS-valitsimen Subscriber-toiminnolla voit määrittää muuttujan, mutta Point-to-Point-toiminnolla et voi (tai tämä menetelmä ei ole kovin ilmeinen).

Näytteenottajien valmistelu

JMS-julkaisija

Asennus - Jokainen näyte. Apache suosittelee käytä tätä vaihtoehtoa, jos jonot/aiheet määritetään muuttujien kautta.
Vanheneminen (ms) = 120000. Epäonnistumisen sattuessa testipyynnöt katoavat jonosta 2 minuutin kuluttua.
Käytätkö jatkuvaa toimitustapaa? - totta. IBM vaatimuksetettä jatkuva tila varmistaa lähetettyjen viestien luotettavan säilymisen äkillisen vian sattuessa. Ja nopeampi vaihto ei-pysyvässä tilassa. Testaustarkoituksiin nopeus on tärkeämpi.

Asetin jokaisessa julkaisijassa jms-ominaisuuden, jota tilaaja käyttää JMS-valitsimessa. Jokaiselle lähetykselle luodaan satunnainen arvo User Parameters -testisuunnitelman elementtiin:

Näin voit olla varma, että oikea viesti on luettu.

Esikonfiguroidun JMS-julkaisijan viimeinen "tyhjä":

JMS-tilaaja

Asennus - Jokainen näyte. No, sinä ymmärrät.
Aikakatkaisu (ms) = 100000. Jos pyyntö ei saavu jonoon 100 sekunnin odotuksen jälkeen, jokin meni pieleen.
Pysähdytkö näytteiden välillä? - totta.

JMS Selector - melko kätevä asia. Lopullinen JMS-tilaaja:

Kuinka käsitellä kyrillisiä aakkosia lähetetyissä viesteissä. JMeterissä se näkyy oletusarvoisesti oikolukemisen jälkeen vinosti. Välttääksesi tämän ja nauttiaksesi suuresta ja voimakkaasta aina ja kaikkialla sinun on:

Lisää JVM-argumentti JMeterin "käynnistimeen":
```
-Dfile.encoding=UTF-8
```
Lisää JSR223 PostProcessori tilaajaan groovy-viivalla:
```
prev.setDataEncoding("UTF-8")
```

Lähetä teksti

Laiskin vaihtoehto. Soveltuu juuri kirjoitettujen testien virheenkorjaukseen. Tai tapauksiin, joissa sinun on lähetettävä ainakin jotain pientä. Valitse vaihtoehto Viestin lähde - Textarea ja sijoita viestin runko tekstilohkoon:

Tiedostonsiirto

Yleisin vaihtoehto. Sopii useimpiin skenaarioihin. Valitse vaihtoehto Viestin lähde - Tiedostosta ja osoita kenttään viestin polku Tiedosto - Tiedostonimi:

Tiedoston siirtäminen tekstikenttään

Monipuolisin vaihtoehto. Sopii useimpiin skenaarioihin + voidaan käyttää JMS-pisteestä pisteeseen, jossa ei ole toista lähetysvaihtoehtoa:

Tavutaulukon välittäminen

Vaikein vaihtoehto. Soveltuu pyyntöjen erehtymättömän tarkan siirron tarkistamiseen tavua myöten ilman vääristymiä, tekstiviestejä ja häiriöitä. Et voi tehdä tätä oletusarvoisessa JMeterissä. täällä Minulle kerrottiin tästä ehdottomasti.

Joten minun piti ladata lähteet ja muokata koodi JMS-tilaaja.

Korvattu menetelmässä extractContent(..) linja:

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

ja rakennettiin uudelleen JMeter.

Jäljelle jää vain pari JSR223-sampleria. Ensimmäinen on ennen julkaisija/tilaaja-paria satunnaisia tavuja sisältävän DAT-tiedoston luomiseksi:

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

Toinen - komentosarjan lopussa poistaa tiedoston:

import java.io.File;

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

Äläkä unohda lisätä tiedoston polkua Publisherissa:

Ja myös tarkistus JSR223 Assertion for Subscriber -sovelluksesta - vertaa lähdetavuja vastaanottajan jonoon saapuviin tavuihin:

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

Johtopäätös

Kuvasin neljä tapaa lähettää viestejä jonoihin, joita käytän käytännössä päivittäin. Toivottavasti tämä tieto helpottaa elämääsi. Jatkossa aion kertoa kokemuksistani sellaisen vaihdon testaamisesta, jossa toisessa päässä on jono ja toisessa tietokanta tai tiedostojärjestelmä.

Säästä aikaasi. Ja kiitos huomiostasi.

Lähde: will.com

Jonot ja JMeter: jakaminen julkaisijan ja tilaajan kanssa