Bună, Habr! Aceasta este o continuare a mea , în care voi vorbi despre opțiunile pentru plasarea mesajelor în cozi folosind JMeter.
Facem o magistrală de date pentru o mare companie federală. Diverse formate de solicitare, transformări, rutare complicată. Pentru testare, trebuie să trimiteți o mulțime de mesaje la coadă. Manual este o durere pe care nu orice chiropractician o poate suporta.
Introducere
Deși a trebuit să suport această durere la început. Totul a început cu RFHUtil. Puternic, dar stingher și înfricoșător: Ei bine, îl cunoști pe Rus.
Indispensabil în unele cazuri, dar în scădere constantă în cazul utilizării active.
Testarea convenabilă este imposibilă cu el.
Cu JMeter totul a devenit mai ușor. După prima etapă de stăpânire și obișnuire cu ea, a început să răsară speranța pentru o testare fericită.
Folosesc în mod activ probele JMS Publisher și JMS Subscriber. Spre deosebire de JMS Point-to-Point, această pereche părea mai convenabilă de utilizat. De exemplu, cu Subscriber în JMS Selector poți specifica o variabilă, dar cu Point-to-Point nu poți (sau această metodă nu este foarte evidentă).
Pregătirea probelor
JMS Publisher
- Configurare - Fiecare Probă. Apache utilizați această opțiune dacă cozile/subiectele sunt specificate prin variabile.
- Expirare (ms) = 120000. În caz de eșec, cererile de testare vor dispărea din coadă după 2 minute.
- Folosiți modul de livrare nepersistent? - Adevărat. IBM acel mod persistent asigură păstrarea fiabilă a mesajelor transmise în cazul unei eșecuri bruște. Și schimb mai rapid în modul non-persistent. În scopuri de testare, viteza este mai importantă.
În fiecare Publisher am setat o proprietate jms pe care Abonatul o va folosi în JMS Selector. Pentru fiecare trimitere, este generată o valoare aleatorie în elementul de plan de testare Parametri utilizator:
În acest fel, puteți fi sigur că este citit mesajul corect.
Ultimul „blank” al unui editor JMS preconfigurat:
Abonat JMS
- Configurare - Fiecare Probă. Ei bine, înțelegi.
- Timeout (ms) = 100000. Dacă cererea nu ajunge în coadă după 100 de secunde de așteptare, atunci ceva a mers prost.
- Opriți între mostre? - Adevărat.
JMS Selector - destul de convenabil . Abonat final JMS:
Cum să tratați alfabetul chirilic în mesajele transmise. În JMeter, implicit, după corectare, este afișat strâmb. Pentru a evita acest lucru și a te bucura de marele și puternicul mereu și pretutindeni, trebuie să:
- Adăugați un argument JVM la „lansatorul” JMeter:
-Dfile.encoding=UTF-8 - Adăugați postprocesor JSR223 la abonat cu o linie groovy:
prev.setDataEncoding("UTF-8")
Trimite text
Cea mai leneșă opțiune. Potrivit pentru depanarea testelor proaspăt scrise. Sau pentru cazurile în care trebuie să trimiteți măcar ceva mic. Selectați opțiunea Sursa mesajului - Textarea și plasați corpul mesajului într-un bloc de text:
Transfer de fișiere
Cea mai comună opțiune. Potrivit pentru majoritatea scenariilor. Selectați opțiunea Sursa mesajului - Din fișier și indicați calea către mesaj în câmp Fișier - Nume fișier:
Transferarea unui fișier într-un câmp de text
Cea mai versatilă opțiune. Potrivit pentru majoritatea scenariilor + poate fi folosit în JMS Point-to-Point unde nu există o a doua opțiune de trimitere:
Trecerea unei matrice de octeți
Cea mai dificilă variantă. Potrivit pentru verificarea transmiterii infailibil de precise a cererilor până la octet, fără distorsiuni, SMS și perturbări. Nu veți putea face acest lucru în JMeter implicit. Cu siguranță mi s-a spus despre asta.
Așa că a trebuit să descarc si modifica Abonat JMS.
Înlocuit în metodă extractContent(..) linia:
buffer.append(bytesMessage.getBodyLength() + " bytes received in BytesMessage");pe:
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);
}și a reconstruit JMeter.
Tot ce rămâne este să adăugați câteva probe JSR223. Primul este înainte de perechea Editor/Abonat pentru a crea un fișier DAT care conține octeți aleatori:
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");
}Al doilea - la sfârșitul scriptului, șterge fișierul:
import java.io.File;
File RESULT_FILE = new File(vars.get("PATH_TO_BYTES"));
RESULT_FILE.delete();Și nu uitați să adăugați calea fișierului în Publisher:
Și, de asemenea, o verificare în JSR223 Assertion for Subscriber - compara octeții sursă cu cei care ajung în coada destinatarului:
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;
}Concluzie
Am descris patru moduri de a trimite mesaje la cozi, pe care le folosesc zilnic în practică. Sper că aceste informații vă vor face viața mai ușoară. În continuare, intenționez să vorbesc despre experiența mea de a testa un schimb unde există o coadă la un capăt și o bază de date sau un sistem de fișiere la celălalt.
Economisiți timp. Și mulțumesc pentru atenție.
Sursa: www.habr.com