Ciao, Habr! Questo è il seguito del mio , in cui parlerò delle opzioni per inviare messaggi in coda usando JMeter.
Stiamo creando un bus dati per un'importante azienda federale. Vari formati di richieste, trasformazioni, instradamenti complessi. Per testare è necessario inviare molti messaggi in coda. Farlo manualmente è un inconveniente che non tutti possono gestire.
Introduzione
Sebbene inizialmente si dovesse fare i conti con questo inconveniente. Tutto è iniziato con RFHUtil. Potente, ma scomodo e spaventoso: sapete di cosa parlo.
Indispensabile in alcuni casi, ma instabile con un uso attivo.
Un test efficiente con esso è impossibile.
Con JMeter tutto è diventato più semplice. Dopo una prima fase di apprendimento e adattamento, è emersa la speranza di un testing sereno.
Utilizzo attivamente i campionatori JMS Publisher e JMS Subscriber. A differenza di JMS Point-to-Point, questa coppia si è rivelata più comoda da usare. Ad esempio, in Subscriber nel JMS Selector si può specificare una variabile, in Point-to-Point no (o questo metodo non è troppo ovvio).
Preparazione dei campionatori
JMS Publisher
- Setup — Ogni campione. Apache utilizzare questa opzione se le code/i topic sono impostati 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? — vero. IBM , che la modalità persistente garantisce il salvataggio affidabile dei messaggi trasmessi in caso di errori imprevisti. E uno scambio più veloce nella modalità non persistente. Per obiettivi di test, la velocità è più importante.
In ogni Publisher imposto la 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 si può essere certi di aver letto il messaggio corretto.
Il template finale del JMS Publisher preimpostato:
JMS Subscriber
- Impostazione — Ogni Campione. Capisci.
- Timeout (ms) = 100000. Se la richiesta non arriva in coda dopo 100 secondi di attesa, significa che qualcosa è andato storto.
- Fermarsi tra i campioni? — vero.
JMS Selector — un'ottima . Il JMS Subscriber finale:
Come gestire i caratteri cirillici nei messaggi trasmessi. In JMeter, per impostazione predefinita, dopo la lettura, si visualizzano male. Per evitare questo e godere della grande e potente lingua 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 testo
La soluzione più semplice. Ideale per il debug di test appena scritti. Oppure per casi in cui è necessario inviare qualcosa di piccolo. Seleziona l'opzione Origine messaggio — Textarea e inserisci il corpo del messaggio nel blocco di testo:
Trasmissione file
L'opzione più comune. Adatta per la maggior parte degli scenari. Seleziona l'opzione Origine messaggio — Da file e specifica il percorso al messaggio nel campo File — Nome file:
Trasmissione file nel campo di testo
La soluzione più versatile. Adatta per la maggior parte degli scenari e può essere utilizzata in JMS Point-to-Point, dove non c'è un secondo modo di invio:
Trasmissione array di byte
L'opzione più complessa. Adatta per verificare la trasmissione di richieste con precisione byte per byte, senza distorsioni, SMS e perturbazioni. Non è possibile farlo con il JMeter di default, me lo hanno detto chiaramente.
Pertanto, ho dovuto scaricare e modificare JMS Subscriber.
Ho sostituito nel metodo extractContent(..) la riga:
buffer.append(bytesMessage.getBodyLength() + " bytes received in BytesMessage");su:
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 solo da aggiungere un paio di JSR223 Sampler. Il primo — prima del paio 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 script, 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 al file nel Publisher:
Inoltre, aggiungere un controllo nell'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 nelle code che utilizzo quotidianamente nella pratica. Spero che queste informazioni ti semplifichino la vita. In futuro, intendo parlare della mia esperienza nel testare lo scambio, dove da un lato c'è la coda e dall'altro un database o un sistema di file.
Risparmia il tuo tempo. E grazie per l'attenzione.
Fonte: habr.com
