Queues kaj JMeter: kundividado kun Eldonisto kaj Abonanto

Saluton, Habr! Ĉi tio estas sekvo de mia antaŭa publikigo, en kiu mi parolos pri ebloj por meti mesaĝojn en vostoj per JMeter.

Ni faras datumbuson por granda federacia kompanio. Diversaj petaj formatoj, transformoj, komplika vojigo. Por testado, vi devas sendi multajn mesaĝojn al la atendovico. Mane estas doloro, kiun ne ĉiu kiropractoro povas trakti.

Enkonduko

Kvankam mi unue devis toleri ĉi tiun doloron. Ĉio komenciĝis per RFHUtil. Potenca, sed mallerta kaj timiga: Nu, vi konas Rus.

Nemalhavebla en iuj kazoj, sed konstante malpliiĝanta en kazo de aktiva uzo.
Konvena testado estas neebla kun ĝi.

Kun JMeter ĉio fariĝis pli facila. Post la unua etapo de majstrado kaj alkutimiĝo, espero komencis aperi por feliĉa testado.

Mi aktive uzas la samplilojn de JMS Publisher kaj JMS Subscriber. Male al JMS Point-to-Point, ĉi tiu paro ŝajnis pli oportuna uzi. Ekzemple, kun Subscriber en JMS Selector vi povas specifi variablon, sed kun Punkto-al-Punkto vi ne povas (aŭ ĉi tiu metodo ne estas tre evidenta).

Preparado de sampliloj

JMS-Eldonisto

• Agordo - Ĉiu Specimeno. Apache rekomendas uzu ĉi tiun opcion se vostoj/temoj estas specifitaj per variabloj.
• Finiĝo (ms) = 120000. En kazo de malsukceso, testpetoj malaperos el la atendovico post 2 minutoj.
• Ĉu uzi nedaŭran liveran reĝimon? - vera. IBM aprobastiu persista reĝimo certigas fidindan konservadon de elsenditaj mesaĝoj okaze de subita malsukceso. Kaj pli rapida interŝanĝo en ne-daŭra reĝimo. Por testaj celoj, rapideco estas pli grava.

En ĉiu Eldonisto mi starigas jms-posedaĵon, kiun la Abonanto uzos en la JMS-Elektilo. Por ĉiu submetiĝo, hazarda valoro estas generita en la prova plana elemento de Uzantaj Parametroj:

Tiel vi povas esti certa, ke la ĝusta mesaĝo estas legita.

La fina "malplena" de antaŭ-agordita JMS-Eldonisto:

JMS-abonanto

• Agordo - Ĉiu Specimeno. Nu, vi komprenas.
• Timeout (ms) = 100000. Se la peto ne alvenas en la atendovico post 100 sekundoj da atendado, tiam io misfunkciis.
• Ĉu halti inter specimenoj? - vera.

JMS Selector - sufiĉe oportuna afero. Fina JMS-abonanto:

Kiel trakti la cirilan alfabeton en elsenditaj mesaĝoj. En JMeter, defaŭlte, post provlegado, ĝi montriĝas malrekte. Por eviti ĉi tion kaj ĝui la bonegan kaj potencan ĉiam kaj ĉie, vi devas:

1. Aldonu JVM-argumenton al la "lanĉilo" de JMeter:

   -Dfile.encoding=UTF-8

2. Aldonu JSR223 PostProcessor al Abonanto kun groovy linio:

   prev.setDataEncoding("UTF-8")

Sendu tekston

La plej maldiligenta elekto. Taŭga por sencimigi ĵus skribitajn testojn. Aŭ por kazoj, kiam vi bezonas sendi almenaŭ ion malgrandan. Elektu opcion Mesaĝfonto - Textarea kaj metu la korpon de la mesaĝo en tekstblokon:

Transfer de dosieroj

La plej ofta opcio. Taŭga por plej multaj scenaroj. Elektu opcion Fonto de mesaĝoj - El dosiero kaj indiku la vojon al la mesaĝo en la kampo Dosiero - Dosiernomo:

Transdono de dosiero al teksta kampo

La plej diverstalenta opcio. Taŭga por plej multaj scenaroj + uzeblas en JMS Punkto-al-Punkto kie ne ekzistas dua senda opcio:

Pasante bajtan tabelon

La plej malfacila opcio. Taŭga por kontroli la senerare precizan transdonon de petoj ĝis la bajto, sen distordo, SMS kaj perturbo. Vi ne povos fari tion en la defaŭlta JMeter. tie Mi certe estis rakontita pri ĉi tio.

Do mi devis elŝuti fontoj kaj modifi kodo JMS-abonanto.

Anstataŭita en la metodo extractContent(..) linio:

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

en:

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

kaj rekonstruis JMeter.

Restas nur aldoni kelkajn JSR223 Samplers. La unua estas antaŭ la paro Eldonisto/Abonanto por krei DAT-dosieron enhavantan hazardajn bajtojn:

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

La dua - ĉe la fino de la skripto, forigas la dosieron:

import java.io.File;

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

Kaj ne forgesu aldoni la vojon al la dosiero en Publisher:

Kaj ankaŭ kontrolo en JSR223 Asertion for Subscriber - komparu la fontbajtojn kun tiuj, kiuj alvenas en la atendovico de la ricevanto:

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

konkludo

Mi priskribis kvar manierojn sendi mesaĝojn al atendovicoj, kiujn mi uzas ĉiutage en la praktiko. Mi esperas, ke ĉi tiu informo faciligos vian vivon. Daŭre, mi planas paroli pri mia sperto pri testado de interŝanĝo, kie estas vico ĉe unu fino kaj datumbazo aŭ dosiersistemo ĉe la alia.

Ŝparu vian tempon. Kaj dankon pro via atento.

fonto: www.habr.com