Hallo, Habr! Dit is in ferfolch op myn , wêryn ik sil prate oer opsjes foar it pleatsen fan berjochten yn wachtrigen mei JMeter.
Wy meitsje in databus foar in grut federaal bedriuw. Ferskate oanfraachformaten, transformaasjes, yngewikkelde routing. Foar testen moatte jo in protte berjochten nei de wachtrige stjoere. Hânmjittich is in pine dy't net elke kiropraktor kin omgean.
Ynlieding
Al moast ik earst mei dizze pine ophâlde. It begon allegear mei RFHUtil. Krêftich, mar ûnhandich en eng: No, do witst Rus.
Yn guon gefallen ûnmisber, mar stadichoan ôfnimme yn gefal fan aktyf gebrûk.
Handige testen is dêrmei ûnmooglik.
Mei JMeter is alles makliker wurden. Nei de earste etappe fan behearsking en wennen oan it, begon hope te daagjen foar lokkich testen.
Ik brûk aktyf de samplers fan JMS Publisher en JMS Subscriber. Oars as JMS Point-to-Point, like dit pear handiger te brûken. Bygelyks, mei Subscriber yn JMS Selector kinne jo in fariabele opjaan, mar mei Point-to-Point kinne jo net (of dizze metoade is net heul dúdlik).
It tarieden fan samplers
JMS Publisher
- Setup - Elts Sample. Apache brûk dizze opsje as wachtrijen / ûnderwerpen wurde oantsjutte troch fariabelen.
- Ferfal (ms) = 120000. Yn gefal fan mislearring sille testoanfragen nei 2 minuten ferdwine út 'e wachtrige.
- Brûk net-persistente leveringsmodus? - wier. IBM dy oanhâldende modus soarget foar betrouber behâld fan oerdroegen berjochten yn it gefal fan in hommelse mislearring. En flugger útwikseling yn net-persistente modus. Foar testdoelen is snelheid wichtiger.
Yn elke útjouwer set ik in jms-eigenskip yn dat de abonnee sil brûke yn 'e JMS-selektor. Foar elke yntsjinjen wurdt in willekeurige wearde generearre yn it testplan-elemint fan brûkersparameters:
Op dizze manier kinne jo der wis fan wêze dat it juste berjocht lêzen wurdt.
De lêste "blank" fan in foarôf ynstelde JMS Publisher:
JMS abonnee
- Setup - Elts Sample. No, jo begripe.
- Timeout (ms) = 100000. As it fersyk nei 100 sekonden wachtsjen net yn 'e wachtrige komt, dan gie der wat mis.
- Stopje tusken samples? - wier.
JMS Selector - hiel handich . Finale JMS-abonnee:
Hoe om te gean mei it Syrillyske alfabet yn ferstjoerde berjochten. Yn JMeter wurdt it standert, nei korrektyflêzen, krom werjûn. Om dit te foarkommen en altyd en oeral te genietsjen fan it geweldige en machtige, moatte jo:
- Foegje in JVM-argument ta oan 'e JMeter "launcher":
-Dfile.encoding=UTF-8 - Foegje JSR223 PostProcessor ta oan abonnee mei groovy line:
prev.setDataEncoding("UTF-8")
Stjoer tekst
De leechste opsje. Geskikt foar it debuggen fan nij skreaune tests. Of foar gefallen as jo op syn minst wat lyts moatte stjoere. Selektearje opsje Berjochtboarne - Textarea en pleats it lichem fan it berjocht yn in tekstblok:
Triem oerdracht
De meast foarkommende opsje. Geskikt foar de measte senario's. Selektearje opsje Berjocht boarne - Fan triem en jouwe it paad nei it berjocht yn it fjild oan Triem - Bestânsnamme:
It oerbringen fan in bestân nei in tekstfjild
De meast alsidige opsje. Geskikt foar de measte senario's + kin brûkt wurde yn JMS Point-to-Point wêr't d'r gjin twadde ferstjoeropsje is:
Trochjaan fan in byte array
De dreechste opsje. Geskikt foar it kontrolearjen fan de ûnfeilber krekte oerdracht fan oanfragen nei de byte, sûnder ferfoarming, SMS en fersteuring. Jo sille dit net kinne dwaan yn 'e standert JMeter. Ik waard perfoarst ferteld oer dit.
Dus ik moast download en wizigje JMS abonnee.
Ferfongen yn 'e metoade extractContent(..) rigel:
buffer.append(bytesMessage.getBodyLength() + " bytes received in BytesMessage");op 'e:
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 werboud JMeter.
Alles wat oerbliuwt is in pear JSR223 Samplers ta te foegjen. De earste is foar it Publisher / Subscriber-pear om in DAT-bestân te meitsjen mei willekeurige bytes:
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");
}De twadde - oan 'e ein fan it skript, wisket it bestân:
import java.io.File;
File RESULT_FILE = new File(vars.get("PATH_TO_BYTES"));
RESULT_FILE.delete();En ferjit net it paad ta te foegjen oan it bestân yn Publisher:
En ek in kontrôle yn JSR223 Assertion for Subscriber - fergelykje de boarnebytes mei dyjingen dy't yn 'e wachtrige fan' e ûntfanger komme:
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;
}konklúzje
Ik beskreau fjouwer manieren om berjochten nei wachtrigen te stjoeren, dy't ik elke dei yn 'e praktyk brûke. Ik hoopje dat dizze ynformaasje jo libben makliker makket. Yn ferfolch bin ik fan plan om te praten oer myn ûnderfining fan it testen fan in útwikseling wêr't d'r in wachtrige is oan ien ein en in databank of bestânsysteem oan 'e oare.
Besparje jo tiid. En tank foar jo oandacht.
Boarne: www.habr.com