Hallo, Habr! Dit is de sequel van mijn , waarin ik de opties voor het plaatsen van berichten in wachtrijen met behulp van JMeter bespreek.
We maken een gegevensbus voor een grote federale onderneming. Verschillende verzoekformaten, conversies, complexe routering. Voor het testen moeten we veel berichten naar wachtrijen verzenden. Handmatig is pijnlijk, iets waar niet elke manualist mee overweg kan.
Inleiding
Hoewel we in het begin met deze pijn moesten leven. Het begon allemaal met RFHUtil. Krachtig, maar onhandig en eng: je kent Rus vast.
Onmisbaar in sommige gevallen, maar valt vaak uit bij intensief gebruik.
Comfortabel testen is met hem onmogelijk.
Met JMeter is alles eenvoudiger geworden. Na de eerste fase van het leren en wennen, gloren er hoopvolle tijden voor gelukkige testen.
Ik gebruik actief de JMS Publisher en JMS Subscriber samplers. In tegenstelling tot JMS Point-to-Point, lijkt dit duo handiger in gebruik. Bijvoorbeeld, bij de Subscriber kan ik een variabele opgeven in JMS Selector, maar bij Point-to-Point is dat niet mogelijk (of die manier is niet zo voor de hand liggend).
Voorbereiding van samplers
JMS Publisher
- Setup — Elke Sample. Apache gebruik deze optie als de wachtrijen/onderwerpen via variabelen zijn ingesteld.
- Expiration (ms) = 120000. In geval van een fout verdwijnen de testverzoeken na 2 minuten uit de wachtrij.
- Use non-persistent delivery mode? — true. IBM , want persistent mode zorgt voor betrouwbare opslag van verzonden berichten in geval van een plotselinge storing. En snellere uitwisseling in non-persistent mode. Voor testdoeleinden is snelheid belangrijker.
In elke Publisher stel ik de jms-eigenschap in die de Subscriber zal gebruiken in JMS Selector. Voor elke verzending wordt een willekeurige waarde gegenereerd in het testplan User Parameters:
Zo kan ik er zeker van zijn dat het juiste bericht is gelezen.
De uiteindelijke 'klon' van de vooraf ingestelde JMS Publisher:
JMS Subscriber
- Setup — Elke Sample. Nou, je snapt het.
- Timeout (ms) = 100000. Als het verzoek na 100 seconden wachten niet in de wachtrij komt, is er iets misgegaan.
- Stop tussen samples? — true.
JMS Selector — een vrij handige . De uiteindelijke JMS Subscriber:
Hoe om te gaan met cyrillische tekens in verzonden berichten. In JMeter worden ze standaard krom weergegeven na het lezen. Om dit te voorkomen en altijd en overal van de grote en machtige te genieten, moet je:
- Voeg het JVM-argument toe in de JMeter 'launcher':
-Dfile.encoding=UTF-8 - Voeg een JSR223 PostProcessor toe aan de Subscriber met de regel in groovy:
prev.setDataEncoding("UTF-8")
Verzending van tekst
De meest vrijblijvende optie. Geschikt voor het debuggen van net geschreven tests. Of voor gevallen waarin je iets kleins moet verzenden. Kies deze optie Berichtbron — Tekstgebied en plaats de inhoud van het bericht in het tekstblok:
Bestandsoverdracht
De meest gebruikelijke optie. Geschikt voor de meeste scenario's. Kies deze optie Berichtbron — Van bestand en geef het pad naar het bericht op in het veld Bestand — Bestandsnaam:
Bestandsoverdracht in het tekstveld
De meest veelzijdige optie. Geschikt voor de meeste scenario's + kan worden gebruikt in JMS Point-to-Point, waar geen tweede verzendoptie is:
Overdracht van byte-array
De meest complexe optie. Geschikt voor het nauwkeurig controleren van foutloze overdracht van verzoeken tot op de byte, zonder vervormingen, sms-berichten of verstoringen. Dit kan niet in de standaard JMeter worden gedaan, dit is me duidelijk gezegd.
Daarom moest ik het downloaden en aanpassen JMS Subscriber.
Ik heb in de methode extractContent(..) de regel vervangen:
buffer.append(bytesMessage.getBodyLength() + " bytes ontvangen in BytesMessage");door:
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);
}en heb JMeter opnieuw opgebouwd.
Het is nu een kwestie van een paar JSR223 Sampler toevoegen. De eerste — vóór de Publisher/Subscriber-paar voor het maken van een DAT-bestand dat willekeurige bytes bevat:
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("bestand niet gevonden");
}De tweede — aan het einde van het scenario, verwijdert het bestand:
import java.io.File;
File RESULT_FILE = new File(vars.get("PATH_TO_BYTES"));
RESULT_FILE.delete();En vergeet niet het pad naar het bestand bij de Publisher toe te voegen:
En ook een controle in de JSR223 Assertion voor de Subscriber — vergelijk de oorspronkelijke bytes met die van de ontvanger in de wachtrij:
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("Vergelijking mislukt");
SampleResult.setResponseData("Bytes zijn veranderd","UTF-8");
IsSuccess=false;
}Conclusie
Ik heb vier manieren beschreven om berichten in de wachtrij te verzenden die ik dagelijks in de praktijk gebruik. Ik hoop dat deze informatie uw leven gemakkelijker maakt. In de volgende fase ben ik van plan mijn ervaring met het testen van de uitwisseling te delen, waarbij aan de ene kant de wachtrij staat en aan de andere kant een database of een bestandssysteem.
Bespaar uw tijd. En bedankt voor uw aandacht.
Bron: habr.com
