Parameterisasi, Fungsi, Transaksi di LoadRunner

Skrip yang direkam dapat mensimulasikan pengguna virtual; namun, rekaman saja mungkin tidak cukup untuk meniru “perilaku pengguna sebenarnya”.

Ketika sebuah skrip direkam, itu mencakup alur aplikasi subjek yang tunggal dan lurus. Padahal, pengguna sebenarnya dapat melakukan beberapa iterasi pada proses apa pun sebelum dia logout. Penundaan antara mengklik tombol (waktu berpikir) akan bervariasi dari orang ke orang. Kemungkinannya adalah beberapa pengguna sebenarnya mengakses aplikasi Anda melalui DSL dan beberapa mengaksesnya melalui dial-up. Jadi, untuk mendapatkan gambaran sebenarnya dari pengguna akhir, kita perlu menyempurnakan skrip kita agar sama persis, atau setidaknya sangat mirip perilakunya dengan pengguna sebenarnya.

Hal di atas adalah pertimbangan paling signifikan ketika melakukan “Pengujian Kinerja”, tapi ada yang lebih dari Skrip VU. Bagaimana Anda mengukur jumlah waktu yang tepat yang dibutuhkan oleh VUser saat SUL menjalani tes kinerja? Bagaimana Anda tahu jika VUser telah melewati atau gagal pada titik tertentu? Apa penyebab di balik kegagalan tersebut, apakah beberapa proses backend gagal atau sumber daya server terbatas?

Kita perlu menyempurnakan skrip kita untuk membantu menjawab semua pertanyaan di atas.

Menggunakan Transaksi

Transaksi adalah mekanisme untuk mengukur waktu respons server untuk setiap operasi. Dengan kata sederhana, penggunaan "Transaksi" membantu mengukur waktu yang dibutuhkan oleh sistem untuk permintaan tertentu. Waktu yang dibutuhkan bisa sekecil klik tombol atau panggilan AJAX saat kehilangan fokus dari kotak teks.

Menerapkan transaksi sangatlah mudah. Cukup tulis satu baris kode sebelum permintaan dibuat ke server dan tutup transaksi ketika permintaan berakhir. LoadRunner hanya membutuhkan string sebagai nama transaksi.

Untuk membuka transaksi, gunakan baris kode ini:

lr_start_transaction(“Transaction Name”);

Untuk menutup transaksi, gunakan baris kode ini:

lr_end_transaction(“Transaction Name”, <status>);

Itu memberi tahu LoadRunner apakah transaksi khusus ini berhasil atau tidak. Parameter yang mungkin dapat berupa:

• LR_AUTO
• LR_PASS
• LR_GAGAL

Contoh:

lr_end_transaction("Login_Saya", LR_AUTO);
lr_end_transaction(“001_Pembukaan_Nama Dasbor”, LR_PASS);
lr_end_transaction(“Alur Kerja_Bisnis_Nama Transaksi”, LR_FAIL);

Poin yang perlu diperhatikan:

• Jangan lupa, Anda bekerja dengan “C” dan itu adalah bahasa yang peka huruf besar-kecil.
• Karakter titik (.) tidak diperbolehkan dalam nama transaksi, meskipun Anda dapat menggunakan spasi dan garis bawah.
• Jika Anda telah membagi kode dengan baik dan menambahkan titik pemeriksaan untuk memverifikasi respons dari server, Anda dapat menggunakan penanganan kesalahan khusus, seperti LR_PASS atau LR_FAIL. Jika tidak, Anda dapat menggunakan LR_AUTO dan LoadRunner akan secara otomatis menangani kesalahan server (HTTP 500, 400, dst.)
• Saat menerapkan transaksi, pastikan tidak ada berpikir_waktu pernyataan yang diapit atau transaksi Anda akan selalu menyertakan periode tersebut.
• Karena LoadRunner memerlukan string konstan sebagai nama transaksi, masalah umum saat menerapkan transaksi adalah ketidakcocokan string. Jika Anda memberikan nama yang berbeda saat membuka dan menutup transaksi, setidaknya Anda akan mengalami 2 kesalahan. Karena transaksi yang Anda buka tidak pernah ditutup, LoadRunner akan menghasilkan kesalahan. Selain itu, transaksi yang ingin Anda tutup tidak pernah dibuka sehingga mengakibatkan kesalahan.
• Bisakah Anda menggunakan kecerdasan Anda dan menjawab sendiri kesalahan mana di atas yang akan dilaporkan terlebih dahulu? Untuk memvalidasi jawaban Anda, mengapa tidak membuat kesalahan Anda sendiri? Jika jawaban Anda benar, Anda berada di jalur yang benar. Jika Anda menjawab salah, Anda harus fokus.
• Karena LoadRunner secara otomatis menangani sinkronisasi permintaan dan respons, Anda tidak perlu khawatir tentang respons saat menerapkan transaksi.

Memahami Waktu Berpikir, Titik Pertemuan dan Komentar

Titik Pertemuan

Titik Pertemuan berarti “titik pertemuan”. Ini hanyalah satu baris pernyataan yang memberitahu LoadRunner untuk memperkenalkan konkurensi. Anda memasukkan titik pertemuan ke dalam skrip VUser untuk meniru beban pengguna yang berat di server.

Titik pertemuan menginstruksikan VUser untuk menunggu selama eksekusi pengujian hingga beberapa VUser tiba pada titik tertentu, sehingga mereka dapat melakukan tugas secara bersamaan. Misalnya, untuk meniru beban puncak di server bank, Anda dapat memasukkan titik pertemuan yang menginstruksikan 100 VUser untuk menyetor uang tunai ke rekening mereka pada saat yang bersamaan. Hal ini dapat dicapai dengan mudah menggunakan pertemuan.

Jika titik pertemuan tidak ditempatkan dengan benar, VUser akan mengakses bagian aplikasi yang berbeda – bahkan untuk skrip yang sama. Hal ini karena setiap VUser mendapatkan waktu respons yang berbeda sehingga hanya sedikit pengguna yang tertinggal.

Sintaks: lr_rendesvous("Nama Logis");

Praktik terbaik:

• Awali titik pertemuan dengan “rdv_” untuk keterbacaan kode yang lebih baik; misalnya “rdv_Login”
• Hapus semua pernyataan waktu berpikir langsung
• Menerapkan titik pertemuan dalam tampilan skrip (setelah perekaman)

komentar

Tambahkan komentar untuk mendeskripsikan aktivitas, sepotong kode, atau sebaris kode. Komentar membantu membuat kode dapat dimengerti oleh siapa pun yang merujuknya di masa mendatang. Mereka memberikan informasi tentang operasi spesifik dan memisahkan dua bagian untuk membedakannya.

Anda dapat menambahkan komentar

• Saat merekam (menggunakan alat)
• Setelah direkam (langsung menulis kode)

Praktik Terbaik: Tandai komentar apa pun di bagian atas setiap file skrip

Memasukkan Fungsi melalui menu

Meskipun Anda dapat langsung menulis baris kode sederhana, Anda mungkin memerlukan petunjuk untuk mengingat suatu fungsi. Anda juga dapat menggunakan Steps Toolbox (dikenal sebagai Insert Function sebelum versi 12) untuk menemukan dan menyisipkan fungsi apa pun langsung ke skrip Anda.

Anda dapat menemukan Toolbar Langkah di bawah Tampilan lalu Kotak Alat Langkah.

Ini akan membuka jendela samping, lihat snapshotnya:

Apa itu Parameterisasi?

A parameter di VUGen adalah wadah yang berisi nilai tercatat yang diganti untuk berbagai pengguna.

Selama eksekusi skrip (di VUGen atau Controller), nilai dari sumber eksternal (seperti .txt, XML, atau database) menggantikan nilai parameter sebelumnya.

Parameterisasi berguna dalam mengirimkan nilai dinamis (atau unik) ke server, misalnya; proses bisnis diinginkan untuk menjalankan 10 iterasi tetapi memilih nama pengguna yang unik setiap saat.

Ini juga membantu dalam merangsang perilaku nyata pada sistem subjek. Lihat contoh di bawah ini:

Contoh masalah:

Proses bisnis hanya berfungsi untuk tanggal saat ini yang berasal dari server, sehingga tidak dapat diteruskan sebagai permintaan hardcode.

Terkadang, aplikasi klien meneruskan ID Unik ke server (misalnya session_id) agar proses dapat dilanjutkan (bahkan untuk satu pengguna) – Dalam kasus seperti itu, parameterisasi membantu.

Seringkali, aplikasi klien menyimpan cache data yang dikirim ke dan dari server. Akibatnya, server tidak menerima perilaku pengguna yang sebenarnya (jika server menjalankan algoritma yang berbeda tergantung pada kriteria pencarian). Meskipun skrip VUser akan berhasil dijalankan, statistik kinerja yang diambil tidak akan berarti. Menggunakan data yang berbeda melalui parameterisasi membantu mengemulasi aktivitas sisi server (prosedur, dll.) dan melatih sistem.

Tanggal yang di-hardcode di VUser selama perekaman mungkin tidak berlaku lagi jika tanggal tersebut telah berlalu. Parameterisasi tanggal memungkinkan eksekusi VUser berhasil dengan mengganti tanggal hard-coded. Bidang atau permintaan tersebut adalah kandidat yang tepat untuk parameterisasi.

Klik di sini jika video tidak dapat diakses

Pengaturan Waktu Jalankan dan dampaknya terhadap simulasi VU

Pengaturan Waktu Jalankan sama pentingnya dengan Skrip VUGen Anda. Dengan konfigurasi yang bervariasi, Anda dapat memperoleh desain pengujian yang berbeda. Inilah sebabnya, Anda mungkin mendapatkan hasil yang tidak dapat diulang jika Pengaturan Waktu Proses tidak konsisten. Mari kita bahas setiap atribut satu per satu.

Jalankan Logika

Run Logic menentukan berapa kali semua tindakan akan dieksekusi, kecuali vuser_init dan vuser_end.

Mungkin ini memperjelas mengapa LoadRunner menyarankan untuk menyimpan semua kode Login di dalam vuser_init, dan bagian Logout di vuser_end, keduanya secara eksklusif.

Jika Anda telah membuat beberapa tindakan, misalkan, Masuk, Buka Layar, Hitung Sewa, Kirim Dana, Periksa Saldo dan logout, maka skenario di bawah ini akan terjadi untuk setiap VUser:

Semua VUsers akan login, jalankan Open Screen, Hitung Sewa, Kirim Dana, Cek Saldo – lalu – lagi Buka layar, Hitung sewa…dan seterusnya – iterasi 10 kali – dilanjutkan dengan logout (sekali).

Ini adalah pengaturan yang kuat yang memungkinkan untuk bertindak lebih seperti pengguna sebenarnya. Ingat, pengguna sebenarnya tidak login dan logout setiap saat – dia biasanya mengulangi langkah yang sama.

Berapa kali Anda mengklik "kotak masuk" saat memeriksa email sebelum keluar?

Mondar-mandir

Ini penting. Kebanyakan orang tidak dapat memahami perbedaan antara tempo dan waktu berpikir. Satu-satunya perbedaan adalah, “pacing mengacu pada penundaan antar iterasi” sedangkan waktu berpikir adalah penundaan antara 2 langkah.

Pengaturan yang disarankan bergantung pada desain pengujian. Namun, jika Anda ingin memuat secara agresif, pertimbangkan untuk memilih “Segera setelah iterasi sebelumnya berakhir”

Log

Log (seperti yang dipahami secara umum) adalah pembukuan semua peristiwa saat Anda menjalankan LoadRunner. Anda dapat mengaktifkan log untuk mengetahui apa yang terjadi antara aplikasi dan server Anda.

LoadRunner memberikan mekanisme logging yang kuat dan dapat diskalakan dengan sendirinya. Ini memungkinkan Anda untuk hanya menyimpan "Log Standar" atau log tambahan yang terperinci dan dapat dikonfigurasi atau menonaktifkannya sama sekali.

Log standar bersifat informatif dan mudah dimengerti. Ini berisi jumlah pengetahuan yang tepat yang biasanya Anda perlukan untuk memecahkan masalah skrip VUser Anda.

Dalam kasus Log Diperluas, semua informasi log Standar adalah subset. Selain itu, Anda dapat melakukan substitusi parameter. Ini memberitahu komponen LoadRunner untuk menyertakan informasi lengkap semua parameter (dari parameterisasi) termasuk permintaan, serta data respons.

Jika Anda memasukkan “Data yang Dikembalikan oleh Server” maka log Anda akan panjang. Ini akan mencakup semua HTML, tag, sumber daya, informasi non-sumber daya yang disertakan langsung di dalam log. Opsi ini bagus hanya jika Anda memerlukan pemecahan masalah yang serius. Biasanya, hal ini membuat ukuran file log menjadi sangat besar dan tidak mudah dipahami.

Seperti yang sudah Anda duga jika Anda memilih "Advance Trace", berkas log Anda akan sangat besar. Anda harus mencobanya. Anda akan melihat jumlah waktu yang dibutuhkan oleh VUGen juga meningkat secara signifikan, meskipun ini tidak akan berdampak pada waktu respons transaksi yang dilaporkan oleh VUGen. Namun, ini adalah informasi yang sangat canggih dan mungkin berguna jika Anda memahami aplikasi subjek, komunikasi klien ke server antara aplikasi dan perangkat keras Anda serta detail tingkat protokol. Biasanya, informasi ini pada dasarnya tidak berguna karena memerlukan upaya yang sangat besar untuk memahami dan memecahkan masalah.

Tip:

• Tidak peduli berapa lama waktu yang dibutuhkan VUGen saat log diaktifkan, hal ini tidak berdampak pada waktu respons transaksi. HP menyebut fenomena ini sebagai “teknologi tercanggih”.
• Nonaktifkan log jika tidak diperlukan.
• Nonaktifkan log ketika Anda selesai dengan skrip Anda. Menyertakan skrip dengan logging diaktifkan akan menyebabkan pengontrol berjalan lebih lambat dan melaporkan pesan-pesan yang mengganggu.
• Menonaktifkan log akan meningkatkan kapasitas jumlah maksimum pengguna yang dapat Anda simulasikan dari LoadRunner.
• Pertimbangkan untuk menggunakan “Kirim pesan hanya ketika terjadi kesalahan” – ini akan membungkam pesan informasi yang tidak perlu dan hanya melaporkan pesan terkait kesalahan.

Pikirkan Waktu

Think Time hanyalah penundaan antara dua langkah.

Think Time membantu mereplikasi perilaku pengguna karena tidak ada pengguna sebenarnya yang dapat menggunakan aplikasi apa pun seperti mesin (VUGen). VUGen menghasilkan waktu berpikir secara otomatis. Anda masih memiliki kendali penuh untuk menghilangkan, mengalikan, atau mengubah durasi waktu berpikir.

Untuk memahami lebih lanjut, misalnya, pengguna dapat membuka layar (yaitu respons yang diikuti dengan permintaan) dan kemudian memberikan nama pengguna dan kata sandinya sebelum menekan enter. Interaksi aplikasi ke server selanjutnya akan terjadi ketika dia mengklik “Masuk”. Waktu yang dibutuhkan pengguna untuk mengetikkan nama pengguna dan kata sandinya adalah Think Time di LoadRunner.

Jika Anda ingin menyimulasikan beban agresif pada aplikasi, pertimbangkan untuk menonaktifkan waktu berpikir sepenuhnya.

Namun, untuk mensimulasikan perilaku serupa yang sebenarnya, Anda dapat “Waktu Berpikir Acak Pengguna” dan mengatur persentase sesuai keinginan.

Pertimbangkan untuk menggunakan Batasi Waktu Berpikir hingga jangka waktu yang sah. Biasanya, 30 detik sudah cukup.

Simulasi Kecepatan

Simulasi kecepatan hanya mengacu pada kapasitas bandwidth untuk setiap mesin klien.

Karena kami mensimulasikan ribuan VUser melalui LoadRunner, sungguh menakjubkan betapa sederhananya LoadRunner untuk mengontrol simulasi bandwidth/kecepatan jaringan.

Jika Anda pelanggan mengakses aplikasi Anda lebih dari 128 Kbps, Anda dapat mengontrolnya dari sini. Anda akan dapat mensimulasikan "perilaku serupa yang sebenarnya" yang akan membantu mendapatkan statistik kinerja yang tepat.

Rekomendasi terbaik adalah mengatur Gunakan bandwidth maksimum. Hal ini akan membantu mengabaikan hambatan kinerja terkait jaringan dan fokus pada potensi masalah dalam aplikasi terlebih dahulu. Anda selalu dapat menjalankan pengujian beberapa kali untuk melihat perilaku yang berbeda-beda dalam situasi yang berbeda.

Emulasi Peramban

Pengalaman pengguna tidak bergantung pada browser yang digunakan pengguna akhir. Jelas, hal ini berada di luar cakupan ukuran Kinerja. Namun, Anda dapat memilih browser mana yang ingin Anda tiru.

Bisakah Anda menjawab sendiri kapan tepatnya penting bagi Anda untuk memilih browser yang tepat dalam konfigurasi ini?

Anda akan menggunakan konfigurasi ini jika aplikasi subjek Anda adalah aplikasi web, yang menghasilkan respons berbeda untuk browser berbeda. Misalnya, Anda dapat melihat gambar dan konten berbeda untuk IE dan Firefox dan sebagainya

Pengaturan penting lainnya adalah Simulasikan cache browser. Jika Anda ingin mengukur waktu respons saat cache diaktifkan, centang kotak ini. Jika Anda mencari situasi terburuk, ini jelas bukan pertimbangan.

Mengunduh sumber daya non-HTML akan memungkinkan LoadRunner mengunduh CSS, JS, dan media kaya lainnya. Ini harus tetap diperiksa. Namun, jika Anda ingin menghilangkan ini dari desain pengujian kinerja Anda, Anda dapat menghapus centang ini.

wakil

Yang terbaik adalah menghilangkan proxy sepenuhnya dari Anda Lingkungan Uji – ini akan membuat hasil tes tidak dapat diandalkan. Namun, Anda mungkin menghadapi situasi yang tidak bisa dihindari. Dalam situasi seperti ini, LoadRunner memfasilitasi Anda dengan pengaturan proxy.

Anda akan bekerja (atau seharusnya bekerja) dengan pengaturan Tanpa proxy. Anda dapat memperolehnya dari browser default Anda. Namun, jangan lupa untuk memeriksa browser mana yang disetel ke default dan apa konfigurasi proxy untuk browser default.

Jika Anda menggunakan proxy dan memerlukan otentikasi (atau skrip) maka Anda dapat mengklik tombol Otentikasi yang mengarah ke jendela baru. Lihat tangkapan layar di bawah ini.

Gunakan layar ini untuk memberikan nama pengguna dan kata sandi untuk diautentikasi di server proxy. Klik OK untuk menutup layar.

Selamat. Anda selesai dengan konfigurasi skrip VUGen Anda. Jangan lupa untuk mengkonfigurasinya untuk semua skrip VUser Anda.