Ciao, Habr! Questo è il seguito del mio , in cui parlerò delle opzioni per l'invio di messaggi nelle code tramite JMeter.
Stiamo realizzando un data bus per una grande azienda federale. Vari formati di richieste, trasformazioni, complessa instradamento. Per i test, è necessario inviare molti messaggi nelle code. Farlo manualmente è un problema che non ogni tester riesce a gestire.
Introduzione
Anche se all'inizio ci siamo dovuti convivere. Tutto è iniziato con RFHUtil. Potente, ma scomodo e spaventoso: sapete già cosa intendo.
Indispensabile in alcuni casi, ma tende a bloccarsi durante un uso intensivo.
Eseguire test con questo è impossibile.
Con JMeter è tutto più semplice. Dopo la prima fase di apprendimento e adattamento, è germinata la speranza di un test sereno.
Utilizzo attivamente i campionatori JMS Publisher e JMS Subscriber. A differenza del JMS Point-to-Point, questa coppia mi è sembrata più comoda da usare. Ad esempio, con il Subscriber nel JMS Selector posso specificare una variabile, mentre con il Point-to-Point non è possibile (o questo metodo non è molto ovvio).
Preparazione dei campionatori
JMS Publisher
- Setup — Ogni campione. Apache utilizzare questa opzione se le code/i topic sono stati definiti tramite variabili.
- Scadenza (ms) = 120000. In caso di errore, le richieste di test scompariranno dalla coda dopo 2 minuti.
- Utilizzare la modalità di consegna non persistente? — true. IBM , poiché la modalità persistente garantisce una conservazione affidabile dei messaggi trasmessi in caso di guasto improvviso. E uno scambio più veloce in modalità non persistente. Per scopi di test la velocità è più importante.
In ogni Publisher imposto una proprietà JMS che il Subscriber utilizzerà nel JMS Selector. Per ogni invio viene generato un valore casuale nell'elemento del piano di test User Parameters:
In questo modo posso essere sicuro che sia stato letto il messaggio corretto.
Il risultato finale del JMS Publisher preimpostato:
JMS Subscriber
- Setup — Ogni campione. Capito.
- Timeout (ms) = 100000. Se la richiesta non arriva nella coda dopo 100 secondi di attesa, significa che qualcosa è andato storto.
- Stop tra i campioni? — true.
JMS Selector — piuttosto comodo . Il JMS Subscriber finale:
Come gestire la cyrillica nei messaggi trasmessi. In JMeter, per impostazione predefinita, dopo la lettura appare distorta. Per evitare ciò e godere della grandezza e potenza sempre e ovunque, è necessario:
- Aggiungere all'avviatore JMeter l'argomento JVM:
-Dfile.encoding=UTF-8 - Aggiungere un JSR223 PostProcessor nel Subscriber con la riga in groovy:
prev.setDataEncoding("UTF-8")
Trasmissione di testo
La soluzione più pigra. Adatta per il debug di test appena scritti. Oppure per i casi in cui è necessario inviare almeno qualcosa di piccolo. Scegli l'opzione Fonte del messaggio — Textarea e inserire il corpo del messaggio nel blocco di testo:
Trasferimento file
La soluzione più comune. Adatta per la maggior parte degli scenari. Scegli l'opzione Fonte del messaggio — Da file e specificare il percorso del messaggio nel campo File — Nome del file:
Trasferimento file nel campo di testo
La soluzione più universale. Adatta per la maggior parte degli scenari + può essere utilizzata in JMS Point-to-Point, dove non c'è un secondo metodo di invio:
Trasferimento di un array di byte
La soluzione più complessa. Adatta per testare la trasmissione precisa dei richieste byte per byte, senza distorsioni, messaggi e perturbazioni. Non è possibile farlo nel JMeter predefinito, me lo hanno detto chiaramente.
Quindi ho dovuto scaricare e modificare JMS Subscriber.
Ho sostituito nel metodo extractContent(..) la riga:
buffer.append(bytesMessage.getBodyLength() + " byte ricevuti in BytesMessage");a:
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);
}e ho ricompilato JMeter.
Rimane da aggiungere un paio di JSR223 Sampler. Il primo — prima della coppia Publisher/Subscriber per creare un file DAT, contenente byte casuali:
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 non trovato");
}Il secondo — alla fine dello scenario, elimina il file:
import java.io.File;
File RESULT_FILE = new File(vars.get("PATH_TO_BYTES"));
RESULT_FILE.delete();E non dimenticare di aggiungere il percorso del file al Publisher:
E inoltre un controllo in JSR223 Assertion per il Subscriber — confrontare i byte originali con quelli che arrivano nella coda del destinatario:
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("Confronto fallito");
SampleResult.setResponseData("I byte sono cambiati","UTF-8");
IsSuccess=false;
}Conclusione
Ho descritto quattro modi per inviare messaggi in coda che utilizzo quotidianamente nella pratica. Spero che queste informazioni possano semplificarti la vita. In seguito, intendo raccontare la mia esperienza nel testare lo scambio, dove a un'estremità c'è la coda e dall'altra un database o un sistema di file.
Proteggi il tuo tempo. E grazie per l'attenzione.
Fonte: habr.com
