Skrip yang direkam dapat mensimulasikan pengguna virtual; namun, rekaman belaka mungkin tidak cukup untuk mereplikasi "perilaku pengguna yang sebenarnya".
Ketika sebuah skrip direkam, itu mencakup aliran tunggal dan lurus dari aplikasi subjek. Padahal, pengguna sebenarnya dapat melakukan beberapa iterasi dari proses apa pun sebelum dia keluar. Penundaan antara mengklik tombol (pikirkan waktu) akan berbeda dari orang ke orang. Kemungkinan beberapa pengguna nyata mengakses aplikasi Anda melalui DSL dan beberapa mengaksesnya melalui dial-up. Jadi, untuk mendapatkan kesan pengguna akhir yang sebenarnya, kami perlu menyempurnakan skrip kami agar sama persis, atau setidaknya berperilaku sangat mirip dengan pengguna sebenarnya.
Di atas adalah pertimbangan paling signifikan saat melakukan "Pengujian Kinerja", tetapi ada lebih banyak hal pada 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?
Kami perlu meningkatkan skrip kami untuk membantu menjawab semua pertanyaan di atas.
- Menggunakan Transaksi
- Memahami Pikirkan Waktu, Titik Pertemuan, dan Komentar
- Memasukkan Fungsi melalui menu
- Apa itu Parameterisasi?
- Jalankan Pengaturan Waktu dan dampaknya pada simulasi VU
- Jalankan Logika
- Pacing
- Catatan
- Pikirkan Times
- Simulasi Kecepatan
- Emulasi Browser
- Proksi
Menggunakan Transaksi
Transaksi adalah mekanisme untuk mengukur waktu respons server untuk operasi apa pun. Dengan kata sederhana, penggunaan "Transaksi" membantu mengukur waktu yang dibutuhkan oleh sistem untuk permintaan tertentu. Ini bisa sekecil klik tombol atau panggilan AJAX setelah 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 (“Nama Transaksi”);
Untuk menutup transaksi, gunakan baris kode ini:
lr_end_transaction (“Nama Transaksi”,);
- LR_AUTO
- LR_PASS
- LR_FAIL
Contoh:
lr_end_transaction (“Login_Login Saya”, LR_AUTO);
lr_end_transaction (“Business_Workflow_Transaction Name”, LR_FAIL);
Poin yang perlu diperhatikan:
- Jangan lupa, Anda menggunakan "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 membuat kode Anda bercabang dengan baik dan menambahkan pos 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 dll.)
- Saat menerapkan transaksi, pastikan tidak ada pernyataan think_time yang diapit atau jika tidak, transaksi Anda akan selalu menyertakan periode tersebut.
- Karena LoadRunner membutuhkan string konstan sebagai nama transaksi, masalah umum saat menerapkan transaksi adalah ketidakcocokan string. Jika Anda memberikan nama yang berbeda saat membuka dan menutup transaksi, Anda setidaknya akan mengalami 2 kesalahan. Karena transaksi yang Anda buka tidak pernah ditutup, LoadRunner akan menghasilkan kesalahan. Selain itu, transaksi yang Anda coba tutup tidak pernah dibuka sehingga terjadi error.
- Dapatkah Anda menggunakan kecerdasan Anda dan menjawab sendiri yang mana dari kesalahan di atas yang akan dilaporkan terlebih dahulu? Untuk memvalidasi jawaban Anda, mengapa tidak membuat kesalahan Anda sendiri? Jika Anda menjawab dengan 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 Pikirkan Waktu, Titik Pertemuan, dan Komentar
Titik Pertemuan
Rendezvous Points berarti "titik pertemuan". Ini hanyalah satu baris pernyataan yang memberi tahu 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 uji untuk beberapa VUser tiba di 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 sama. 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. Ini karena setiap VUser mendapatkan waktu respons yang berbeda dan karenanya hanya sedikit pengguna yang tertinggal.
Sintaks: lr_rendesvous (“Nama Logis”);
Praktik terbaik:
- Awali titik pertemuan dengan “rdv_” untuk keterbacaan kode yang lebih baik; mis. “rdv_Login”
- Hapus semua pernyataan waktu berpikir segera
- Menerapkan titik pertemuan dalam tampilan skrip (setelah merekam)
Komentar
Tambahkan komentar untuk mendeskripsikan aktivitas, sepotong kode, atau sebaris kode. Komentar membantu membuat kode dapat dipahami oleh siapa pun yang merujuknya di masa mendatang. Mereka memberikan informasi tentang operasi tertentu dan memisahkan dua bagian untuk pembedaan.
Anda dapat menambahkan komentar
- Saat merekam (menggunakan alat)
- Setelah merekam (langsung menulis kode)
Praktik Terbaik: Tandai setiap komentar di atas setiap file skrip
Memasukkan Fungsi melalui menu
Meskipun Anda dapat langsung menulis baris kode sederhana, Anda mungkin memerlukan petunjuk untuk memanggil kembali suatu fungsi. Anda juga dapat menggunakan Steps Toolbox (dikenal sebagai Sisipkan Fungsi sebelum versi 12) untuk menemukan dan memasukkan fungsi apa pun secara langsung ke dalam skrip Anda.
Anda dapat menemukan Steps Toolbar di bawah View àSteps Toolbox.
Ini akan membuka jendela samping, lihat snapshot:
Apa itu Parameterisasi?
Sebuah parameter di VUGen adalah wadah yang berisi nilai tercatat diganti untuk berbagai pengguna.
Selama eksekusi skrip (dalam 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 seperti nyata ke sistem subjek. Lihat contoh di bawah ini:
Contoh masalah:
Proses bisnis hanya berfungsi untuk tanggal saat ini yang berasal dari server, oleh karena itu tidak dapat diteruskan sebagai permintaan hardcode.
Terkadang, aplikasi klien mengirimkan ID Unik ke server (misalnya session_id) untuk melanjutkan proses (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 algoritme yang berbeda bergantung pada kriteria pencarian). Sementara skrip VUser akan berhasil dijalankan, statistik kinerja yang ditarik 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 lagi valid ketika tanggal itu telah berlalu. Parameterisasi tanggal memungkinkan eksekusi VUser berhasil dengan mengganti tanggal hard-code. Bidang atau permintaan semacam itu adalah kandidat yang tepat untuk parameterisasi.
Klik di sini jika video tidak dapat diakses
Jalankan Pengaturan Waktu dan dampaknya pada simulasi VU
Jalankan Pengaturan Waktu sama pentingnya dengan VUGen Script 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 dijalankan, 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, katakanlah, Masuk, Buka Layar, Hitung Sewa, Kirim Dana, Periksa Saldo dan keluar, maka, skenario di bawah ini akan terjadi untuk setiap VUser:
Semua VUsers akan login, mengeksekusi Layar Terbuka, Menghitung Sewa, Mengirim Dana, Memeriksa Saldo - lalu - lagi Membuka layar, Menghitung rental… dan seterusnya - mengulang 10 kali - diikuti dengan logout (sekali).
Ini adalah pengaturan yang kuat yang memungkinkan untuk bertindak lebih seperti pengguna sungguhan. Ingat, pengguna sebenarnya tidak masuk dan keluar setiap saat - dia, biasanya, mengulangi langkah yang sama.
Berapa kali Anda mengklik "kotak masuk" saat memeriksa email Anda sebelum keluar?
Pacing
Ini penting. Kebanyakan orang tidak dapat memahami perbedaan antara mondar-mandir dan waktu berpikir. Satu-satunya perbedaan adalah, "pacing mengacu pada penundaan antar iterasi" sedangkan think time adalah penundaan antara 2 langkah apa pun.
Pengaturan yang direkomendasikan tergantung pada desain tes. Namun, jika Anda ingin memiliki pemuatan yang agresif, pertimbangkan untuk memilih "Segera setelah iterasi sebelumnya berakhir"
Catatan
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 Anda dan server Anda.
LoadRunner memberikan mekanisme logging yang kuat yang kuat dan dapat diskalakan sendiri. Hal ini memungkinkan Anda untuk menyimpan hanya "Log Standar" atau log diperpanjang rinci yang 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 Extended Log, semua informasi log Standar adalah subset. Selain itu, Anda dapat memiliki substitusi parameter. Ini memberi tahu komponen LoadRunner untuk menyertakan informasi lengkap dari semua parameter (dari parameterisasi) termasuk permintaan, serta data respons.
Jika Anda menyertakan "Data yang Dikembalikan oleh Server" maka log Anda akan panjang. Ini akan mencakup semua informasi HTML, tag, sumber daya, non-sumber daya yang disertakan langsung di dalam log. Opsi ini bagus hanya jika Anda membutuhkan pemecahan masalah yang serius. Biasanya, ini membuat file log berukuran sangat besar dan tidak mudah dipahami.
Seperti yang bisa Anda tebak sekarang jika Anda memilih "Pelacakan Lanjutan", file 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 maju 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 sudah mati karena membutuhkan upaya ekstrim untuk memahami dan memecahkan masalah.
Tips:
- Tidak peduli berapa banyak waktu yang dibutuhkan VUGen saat log diaktifkan, itu tidak berdampak pada waktu respons transaksi. HP menyebut fenomena ini sebagai "teknologi tercanggih".
- Nonaktifkan log jika tidak diperlukan.
- Nonaktifkan log setelah Anda selesai dengan skrip Anda. Menyertakan skrip dengan pencatatan diaktifkan akan menyebabkan pengontrol berjalan lebih lambat dan melaporkan 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 membisukan pesan informasi yang tidak perlu dan hanya melaporkan pesan terkait kesalahan.
Pikirkan Times
Pikirkan Waktu hanyalah penundaan antara dua langkah.
Think Time membantu mereplikasi perilaku pengguna karena tidak ada pengguna nyata yang dapat menggunakan aplikasi apa pun seperti mesin (VUGen). VUGen menghasilkan waktu berpikir secara otomatis. Anda masih memiliki kendali penuh untuk menghapus, menggandakan, atau mengubah durasi waktu berpikir.
Untuk lebih memahami, misalnya, pengguna dapat membuka layar (yang merupakan respons diikuti dengan permintaan) dan kemudian memberikan nama pengguna dan kata sandi sebelum menekan enter. Interaksi berikutnya dari aplikasi ke server akan terjadi saat dia mengklik "Masuk". Waktu yang dibutuhkan pengguna untuk mengetik nama pengguna dan kata sandinya adalah Think Time di LoadRunner.
Jika Anda ingin menyimulasikan pemuatan agresif pada aplikasi, pertimbangkan untuk menonaktifkan think time sepenuhnya.
Namun, untuk mensimulasikan perilaku serupa yang nyata, Anda dapat "Waktu Berpikir Acak Pengguna" dan mengatur persentase sesuai keinginan.
Pertimbangkan untuk menggunakan Batasi Waktu Berpikir untuk periode yang sah. Biasanya, 30 detik sudah cukup baik.
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 adalah pelanggan yang mengakses aplikasi Anda melalui 128 Kbps, Anda dapat mengontrolnya dari sini. Anda akan mendapatkan simulasi "perilaku seperti nyata" yang akan membantu mendapatkan statistik kinerja yang tepat.
Rekomendasi terbaik adalah mengatur ke Gunakan bandwidth maksimum. Ini akan membantu mengabaikan semua hambatan kinerja terkait jaringan dan fokus pada masalah potensial apa pun dalam aplikasi terlebih dahulu. Anda selalu dapat menjalankan pengujian beberapa kali untuk melihat berbagai perilaku dalam keadaan yang berbeda.
Emulasi Browser
Pengalaman pengguna tidak bergantung pada browser yang digunakan pengguna akhir. Jelas, ini di luar cakupan ukuran Kinerja. Namun, Anda dapat memilih browser mana yang ingin Anda tiru.
Dapatkah Anda menjawab kepada diri sendiri kapan sebenarnya penting bagi Anda untuk memilih browser yang tepat dalam konfigurasi ini?
Anda akan menggunakan konfigurasi ini jika aplikasi subjek Anda adalah aplikasi web, memberikan respons yang berbeda untuk browser yang berbeda. Misalnya, Anda bisa melihat berbagai gambar dan konten untuk IE dan Firefox dll.
Pengaturan penting lainnya adalah Simulasikan cache browser. Jika Anda ingin mengukur waktu respons saat cache diaktifkan, centang kotak ini. Jika Anda mencari situasi kasus 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.
Proksi
Cara terbaik adalah menghilangkan proxy sepenuhnya dari Lingkungan Pengujian Anda - ini akan membuat hasil pengujian tidak dapat diandalkan. Namun, Anda mungkin menghadapi situasi yang tidak bisa dihindari. Dalam situasi seperti itu, LoadRunner memfasilitasi Anda dengan pengaturan proxy.
Anda akan bekerja (atau seharusnya bekerja) dengan pengaturan Tanpa proxy. Anda bisa mendapatkannya dari browser default Anda. Namun, jangan lupa untuk memeriksa browser mana yang disetel ke default dan konfigurasi proxy untuk browser default apa.
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 mendapatkan otentikasi 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.