Halo, Habr!
Ini adalah sekuel dari
publikasi saya
sebelumnya , di mana saya akan berbicara tentang opsi untuk menempatkan pesan dalam antrian menggunakan JMeter.
Kami membuat bus data untuk perusahaan federal besar. Berbagai format kueri, konversi, perutean rumit. Untuk pengujian, Anda perlu mengirim banyak pesan dalam antrian. Secara manual - rasa sakit yang tidak semua insinyur manual akan atasi.
Pendahuluan
Meskipun saya harus menahan rasa sakit ini pada awalnya. Semuanya dimulai dengan RFHUtil. Kuat, tetapi tidak nyaman dan menakutkan:
Ya, Anda tahu Rus.
Sangat diperlukan dalam beberapa kasus, tetapi stabil jika digunakan secara aktif.
Tes yang mudah dengannya tidak mungkin dilakukan.
Dengan JMeter, segalanya menjadi lebih mudah. Setelah tahap pertama dengan menguasai dan membiasakan diri, harapan pengujian yang bahagia datang.
Saya secara aktif menggunakan JMS Publisher dan sampler Pelanggan JMS. Tidak seperti JMS Point-to-Point, pasangan ini sepertinya lebih nyaman untuk bekerja dengannya. Misalnya, dalam Pelanggan di Selektor JMS Anda dapat menentukan variabel, di Point-to-Point - tidak (atau metode ini tidak terlalu jelas).
Persiapan Sampler
Penerbit JMS
- Setup - Setiap Sampel. Apache merekomendasikan untuk menggunakan opsi ini jika antrian / topik ditentukan melalui variabel.
- Kedaluwarsa (ms) = 120000. Jika gagal, permintaan tes akan hilang dari antrian setelah 2 menit.
- Gunakan mode pengiriman non-persisten? - benar. IBM mengklaim bahwa mode persisten memberikan persistensi pesan yang andal jika terjadi kegagalan mendadak. Dan berbagi lebih cepat dalam mode non-persisten. Untuk tujuan pengujian, kecepatan lebih penting.
Di setiap Penerbit, saya mengatur properti jms yang akan digunakan oleh Pelanggan di Pemilih JMS. Untuk setiap pengiriman, nilai acak dihasilkan dalam elemen rencana pengujian Parameter Pengguna:
Jadi Anda dapat yakin bahwa pesan yang benar telah dibaca.
"Kosong" terakhir dari Penerbit JMS yang telah dikonfigurasi sebelumnya:
Pelanggan Jms
- Setup - Setiap Sampel. Nah, Anda mengerti intinya.
- Timeout (ms) = 100000. Jika permintaan tidak masuk ke antrian setelah 100 detik menunggu, maka ada yang tidak beres.
- Berhenti di antara sampel? - benar.
Pemilih JMS adalah hal yang sangat berguna. Ringkasan Pelanggan JMS:
Cara menangani alfabet Cyrillic dalam pesan yang dikirimkan. Di JMeter, secara default, setelah dikurangi, ini ditampilkan dengan bengkok. Untuk menghindari hal ini dan menikmati yang hebat dan yang kuat selalu dan di mana-mana, Anda perlu:
- Tambahkan argumen JVM ke “peluncur” JMeter:
-Dfile.encoding=UTF-8
- Tambahkan JSR223 PostProcessor ke Pelanggan dengan baris di groovy:
prev.setDataEncoding("UTF-8")
Transfer teks
Opsi paling malas. Cocok untuk debugging tes yang baru ditulis. Atau untuk kasus-kasus ketika Anda perlu mengirim setidaknya sesuatu yang kecil. Pilih opsi
Sumber pesan - Textarea dan tempatkan badan pesan di blok teks:
Transfer file
Opsi paling umum. Cocok untuk sebagian besar skenario. Pilih opsi
Sumber pesan - Dari file dan tentukan jalur ke pesan di bidang
File - Nama file:
Transfer file ke bidang teks
Opsi paling serbaguna. Cocok untuk sebagian besar skenario + dapat digunakan di JMS Point-to-Point, di mana tidak ada opsi pengiriman kedua:
Transfer array byte
Opsi paling sulit. Cocok untuk memeriksa transfer permintaan yang sangat akurat ke byte, tanpa distorsi, SMS, dan gangguan. Saya tidak bisa melakukan ini di JMeter default, di
sini mereka pasti memberi tahu saya tentang hal itu.
Karena itu, saya harus mengunduh
sumber dan memodifikasi
kode Pelanggan JMS.
Mengganti baris dalam metode
extractContent(..) :
buffer.append(bytesMessage.getBodyLength() + " bytes received in BytesMessage");
pada:
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); }
dan membangun kembali JMeter.
Masih menambahkan beberapa Sampler JSR223. Yang pertama adalah sebelum pasangan Penerbit / Pelanggan untuk membuat file dat yang berisi byte acak:
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:\\temp\\randomBytes.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"); }
Yang kedua, di akhir skrip, menghapus file:
import java.io.File; File RESULT_FILE = new File(vars.get("PATH_TO_BYTES")); RESULT_FILE.delete();
Dan jangan lupa untuk menambahkan path ke file dari Publisher:
Dan juga cek di Pernyataan JSR223 untuk Pelanggan - bandingkan byte sumber dengan yang ada di antrian penerima:
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; }
Kesimpulan
Dia menggambarkan empat cara mengirim pesan dalam antrian, yang saya gunakan dalam praktik setiap hari. Saya harap informasi ini membuat hidup Anda lebih mudah. Dalam sekuel, saya berencana untuk berbicara tentang pengalaman saya dalam pengujian pertukaran, di mana di satu ujung adalah antrian, dan di sisi lain adalah database atau sistem file.
Jaga waktu Anda. Dan terima kasih sudah menonton.