Përshëndetje, Habr! Ky është një vazhdim i imi , në të cilën do të flas për opsionet për vendosjen e mesazheve në radhë duke përdorur JMeter.
Ne po bëjmë një autobus të dhënash për një kompani të madhe federale. Formate të ndryshme kërkesash, transformime, rrugëzim të ndërlikuar. Për testim, duhet të dërgoni shumë mesazhe në radhë. Me dorë është një dhimbje që jo çdo kiropraktor mund ta trajtojë.
Paraqitje
Edhe pse në fillim më duhej ta përballoja këtë dhimbje. Gjithçka filloi me RFHUtil. E fuqishme, por e sikletshme dhe e frikshme: Epo, ju e njihni Rusin.
I domosdoshëm në disa raste, por në rënie të vazhdueshme në rast të përdorimit aktiv.
Testimi i përshtatshëm është i pamundur me të.
Me JMeter gjithçka është bërë më e lehtë. Pas fazës së parë të zotërimit dhe të mësuarit me të, shpresa filloi të lindte për testim të lumtur.
Unë përdor në mënyrë aktive mostrat JMS Publisher dhe JMS Subscribers. Ndryshe nga JMS Point-to-Point, kjo palë dukej më e përshtatshme për t'u përdorur. Për shembull, me Subscriber në JMS Selector mund të specifikoni një variabël, por me Point-to-Point nuk mundeni (ose kjo metodë nuk është shumë e dukshme).
Përgatitja e mostrave
Botuesi JMS
- Konfigurimi - Çdo mostër. Apache përdorni këtë opsion nëse radhët/temat janë të specifikuara nëpërmjet variablave.
- Skadimi (ms) = 120000. Në rast dështimi, kërkesat e testimit do të zhduken nga radha pas 2 minutash.
- Të përdoret modaliteti i dërgimit jo të vazhdueshëm? - e vertete. IBM ai modalitet i vazhdueshëm siguron ruajtjen e besueshme të mesazheve të transmetuara në rast të një dështimi të papritur. Dhe shkëmbim më i shpejtë në modalitetin jo të vazhdueshëm. Për qëllime testimi, shpejtësia është më e rëndësishme.
Në çdo Publisher vendos një veçori jms që Abonenti do të përdorë në Zgjedhësin JMS. Për çdo paraqitje, gjenerohet një vlerë e rastësishme në elementin e planit të testit të parametrave të përdoruesit:
Në këtë mënyrë mund të siguroheni që mesazhi i saktë është lexuar.
"Bloshi" i fundit i një botuesi JMS të para-konfiguruar:
Abonent JMS
- Konfigurimi - Çdo mostër. Epo, ju e kuptoni.
- Kohëzgjatja (ms) = 100000. Nëse kërkesa nuk arrin në radhë pas 100 sekondash pritjeje, atëherë diçka shkoi keq.
- Ndalimi midis mostrave? - e vertete.
Zgjedhësi JMS - mjaft i përshtatshëm . Abonenti i fundit JMS:
Si të merreni me alfabetin cirilik në mesazhet e transmetuara. Në JMeter, si parazgjedhje, pas korrigjimit, ai shfaqet shtrembër. Për të shmangur këtë dhe për të shijuar të madhen dhe të fuqishmen gjithmonë dhe kudo, ju duhet:
- Shtoni një argument JVM në "hapësi" JMeter:
-Dfile.encoding=UTF-8 - Shto JSR223 PostProcessor te pajtimtari me linjë groovy:
prev.setDataEncoding("UTF-8")
Dërgo tekst
Opsioni më dembel. I përshtatshëm për korrigjimin e testeve të sapo shkruara. Ose për rastet kur duhet të dërgoni të paktën diçka të vogël. Zgjidh opsionin Burimi i mesazhit - Textarea dhe vendosni trupin e mesazhit në një bllok teksti:
Transferimi i skedarit
Opsioni më i zakonshëm. I përshtatshëm për shumicën e skenarëve. Zgjidh opsionin Burimi i mesazhit - Nga skedari dhe tregoni shtegun e mesazhit në fushë Skedari - Emri i skedarit:
Transferimi i një skedari në një fushë teksti
Opsioni më i gjithanshëm. I përshtatshëm për shumicën e skenarëve + mund të përdoret në JMS Point-to-Point ku nuk ka opsion të dytë dërgimi:
Kalimi i një grupi bajt
Opsioni më i vështirë. I përshtatshëm për të kontrolluar transmetimin e pagabueshëm të saktë të kërkesave deri në bajt, pa shtrembërim, SMS dhe shqetësime. Nuk do të mund ta bëni këtë në JMeterin e paracaktuar. Më thanë patjetër për këtë.
Kështu që më duhej të shkarkoja dhe modifikoni Abonent JMS.
Zëvendësuar në metodë extractContent(..) linjë:
buffer.append(bytesMessage.getBodyLength() + " bytes received in BytesMessage");në:
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);
}dhe rindërtoi JMeter.
Gjithçka që mbetet është të shtoni disa mostra JSR223. E para është përpara çiftit Publisher/Subscriber për të krijuar një skedar DAT që përmban bajt të rastësishëm:
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");
}E dyta - në fund të skenarit, fshin skedarin:
import java.io.File;
File RESULT_FILE = new File(vars.get("PATH_TO_BYTES"));
RESULT_FILE.delete();Dhe mos harroni të shtoni shtegun në skedar në Publisher:
Dhe gjithashtu një kontroll në JSR223 Assertion for Subscriber - krahasoni bajtet e burimit me ato që mbërrijnë në radhën e marrësit:
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;
}Përfundim
Përshkrova katër mënyra për të dërguar mesazhe në radhë, të cilat i përdor çdo ditë në praktikë. Shpresoj që ky informacion ta bëjë jetën tuaj më të lehtë. Në vazhdim, planifikoj të flas për përvojën time të testimit të një shkëmbimi ku ka një radhë në njërën anë dhe një bazë të dhënash ose sistem skedarësh në anën tjetër.
Kurseni kohën tuaj. Dhe faleminderit për vëmendjen tuaj.
Burimi: www.habr.com