Ciao, Habr! Questo è il seguito del mio , in cui parlerò delle opzioni per posizionare i messaggi in coda utilizzando JMeter.
Stiamo realizzando un bus dati per una grande azienda federale. Vari formati di richiesta, trasformazioni, instradamento complesso. Per eseguire il test, è necessario inviare molti messaggi alla coda. Manualmente è un dolore che non tutti i chiropratici possono gestire.
Introduzione
Anche se all'inizio ho dovuto sopportare questo dolore. Tutto è iniziato con RFHUtil. Potente, ma imbarazzante e spaventoso: beh, conosci Rus.
Indispensabile in alcuni casi, ma in costante calo in caso di utilizzo attivo.
Con esso è impossibile eseguire test convenienti.
Con JMeter tutto è diventato più semplice. Dopo la prima fase di padronanza e di adattamento, la speranza ha cominciato a sorgere per test felici.
Utilizzo attivamente i campionatori JMS Publisher e JMS Subscriber. A differenza di JMS Point-to-Point, questa coppia sembrava più comoda da usare. Ad esempio, con Subscriber in JMS Selector è possibile specificare una variabile, ma con Point-to-Point non è possibile (o questo metodo non è molto ovvio).
Preparazione dei campionatori
Editore JMS
- Configurazione: ciascun campione. Apache utilizzare questa opzione se le code/gli argomenti vengono specificati tramite variabili.
- Scadenza (ms) = 120000. In caso di fallimento, le richieste di test scompariranno dalla coda dopo 2 minuti.
- Utilizzare la modalità di consegna non persistente? - VERO. IBM tale modalità persistente garantisce una conservazione affidabile dei messaggi trasmessi in caso di guasto improvviso. E scambio più veloce in modalità non persistente. Ai fini dei test, la velocità è più importante.
In ogni editore imposto una proprietà jms che l'abbonato utilizzerà nel selettore JMS. Per ogni invio, viene generato un valore casuale nell'elemento del piano di test Parametri utente:
In questo modo puoi essere sicuro che venga letto il messaggio corretto.
Lo "spazio vuoto" finale di un JMS Publisher preconfigurato:
Abbonato JMS
- Configurazione: ciascun campione. Beh, hai capito.
- Timeout (ms) = 100000. Se la richiesta non arriva in coda dopo 100 secondi di attesa, allora qualcosa è andato storto.
- Interruzione tra i campioni? - VERO.
Selettore JMS: abbastanza conveniente . Abbonato JMS finale:
Come trattare l'alfabeto cirillico nei messaggi trasmessi. In JMeter, per impostazione predefinita, dopo la correzione di bozze, viene visualizzato in modo storto. Per evitare ciò e godere dei grandi e dei potenti sempre e ovunque, è necessario:
- Aggiungi un argomento JVM al "launcher" di JMeter:
-Dfile.encoding=UTF-8 - Aggiungi il PostProcessor JSR223 all'abbonato con la linea groovy:
prev.setDataEncoding("UTF-8")
Invia testo
L'opzione più pigra. Adatto per il debug di test appena scritti. O nei casi in cui è necessario inviare almeno qualcosa di piccolo. Selezionare l'opzione Origine del messaggio: area di testo e inserisci il corpo del messaggio in un blocco di testo:
Trasferimento file
L'opzione più comune. Adatto per la maggior parte degli scenari. Selezionare l'opzione Origine del messaggio: dal file e indicare nel campo il percorso del messaggio File - Nome file:
Trasferimento di un file in un campo di testo
L'opzione più versatile. Adatto per la maggior parte degli scenari + può essere utilizzato in JMS Point-to-Point dove non è disponibile una seconda opzione di invio:
Passaggio di un array di byte
L'opzione più difficile. Adatto per verificare l'infallibile precisione della trasmissione delle richieste fino al byte, senza distorsioni, SMS e perturbazioni. Non sarai in grado di farlo nel JMeter predefinito. Questo mi è stato sicuramente detto.
Quindi ho dovuto scaricarlo e modificare Abbonato JMS.
Sostituito nel metodo extractContent(..) linea:
buffer.append(bytesMessage.getBodyLength() + " bytes received in BytesMessage");на:
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 ricostruito JMeter.
Non resta che aggiungere un paio di campionatori JSR223. Il primo è prima che la coppia Editore/Abbonato crei 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 not found");
}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 in Publisher:
E anche un controllo in JSR223 Assertion for Subscriber: confronta i byte di origine 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("Comparison failed");
SampleResult.setResponseData("Bytes have changed","UTF-8");
IsSuccess=false;
}conclusione
Ho descritto quattro modi per inviare messaggi alle code, che utilizzo quotidianamente nella pratica. Spero che queste informazioni ti semplifichino la vita. In seguito, ho intenzione di parlare della mia esperienza nel testare uno scambio in cui c'è una coda da un lato e un database o un file system dall'altro.
Risparmia tempo. E grazie per la tua attenzione.
Fonte: habr.com