Alat Pengujian LoadRunner – Komponen & Architekstur

Apa itu LoadRunner?

LoadRunner adalah alat Pengujian Kinerja yang dipelopori oleh Mercury pada tahun 1999. LoadRunner kemudian diakuisisi oleh HPE pada tahun 2006. Pada tahun 2016, LoadRunner diakuisisi oleh MicroFocus.

LoadRunner mendukung berbagai alat pengembangan, teknologi, dan protokol komunikasi. Faktanya, ini adalah satu-satunya alat di pasar yang mendukung sejumlah besar protokol untuk dijalankan Pengujian Kinerja. Hasil Uji Kinerja yang dihasilkan oleh perangkat lunak LoadRunner digunakan sebagai tolok ukur terhadap alat lainnya

Video LoadRunner

Mengapa LoadRunner?

LoadRunner bukan hanya alat pionir dalam Pengujian Kinerja, namun masih menjadi pemimpin pasar dalam paradigma Pengujian Kinerja. Dalam penilaian baru-baru ini, LoadRunner memiliki sekitar 85% pangsa pasar di industri Pengujian Kinerja.

Secara umum, alat LoadRunner mendukung RIA (Aplikasi Internet Kaya), Web 2.0 (HTTP/HTML, Ajax, Flex dan Silverlight dll.), Seluler, SAP, Oracle, NONA SQL Server, Citrix, RTE, Mail dan di atas segalanya, Windows Stopkontak. Tidak ada alat pesaing di pasar yang dapat menawarkan beragam protokol yang dimiliki oleh satu alat.

Hal yang lebih meyakinkan untuk memilih LoadRunner dalam pengujian perangkat lunak adalah kredibilitas alat ini. Alat LoadRunner telah lama memiliki reputasi yang sering Anda temukan klien memverifikasi silang tolok ukur kinerja Anda menggunakan LoadRunner. Anda akan merasa lega jika Anda sudah menggunakan LoadRunner untuk kebutuhan pengujian kinerja Anda.

Perangkat lunak LoadRunner terintegrasi erat dengan Alat HP lainnya seperti Unified Functional Test (QTP) & ALM (Application Lifecycle Management) yang memberdayakan Anda untuk melakukan Proses Pengujian ujung ke ujung.

LoadRunner bekerja berdasarkan prinsip simulasi Pengguna Virtual pada aplikasi subjek. Pengguna Virtual ini juga disebut sebagai VUser, mereplikasi permintaan klien dan mengharapkan respons yang sesuai untuk meneruskan transaksi.

Mengapa Anda memerlukan Pengujian Kinerja?

Diperkirakan kerugian pendapatan sebesar 4.4 miliar dicatat setiap tahun karena kinerja web yang buruk.

Di era Web 2.0 saat ini, pengguna akan menutup situs web jika tidak ada respons dalam waktu 8 detik. Bayangkan Anda menunggu selama 5 detik saat mencari di Google atau mengajukan permintaan pertemanan di Facebook. Dampak dari waktu henti kinerja sering kali lebih dahsyat dari yang pernah dibayangkan. Kami memiliki contoh seperti yang baru-baru ini terjadi pada Perbankan Online Bank of America, Amazon Layanan Web, Intuit atau Blackberry.

Menurut Dunn & Bradstreet, 59% dari perusahaan Fortune 500 mengalami sekitar 1.6 jam waktu henti setiap minggu. Jika mempertimbangkan rata-rata perusahaan Fortune 500 dengan minimal 10,000 karyawan yang membayar $56 per jam, bagian biaya tenaga kerja dari waktu henti untuk organisasi tersebut akan menjadi $896,000 per minggu, yang berarti lebih dari $46 juta per tahun.

Hanya waktu henti Google.com selama 5 menit (19-Agustus-13) diperkirakan menyebabkan kerugian sebesar $545,000 bagi raksasa pencarian tersebut.

Diperkirakan perusahaan kehilangan penjualan senilai $1100 per detik karena kejadian baru-baru ini Amazon Gangguan Layanan Web.

Ketika sistem perangkat lunak diterapkan oleh suatu organisasi, sistem tersebut mungkin menghadapi banyak skenario yang mungkin mengakibatkan latensi kinerja. Sejumlah faktor menyebabkan kinerja melambat, beberapa contohnya meliputi:

• Peningkatan jumlah catatan yang ada dalam database
• Peningkatan jumlah permintaan simultan yang dibuat ke sistem
• lebih banyak pengguna yang mengakses sistem pada satu waktu dibandingkan sebelumnya

Apa itu LoadRunner Architekstur?

Secara umum, arsitektur HP LoadRunner rumit, namun mudah dipahami.

Misalkan Anda ditugaskan untuk memeriksa kinerja Amazon.com untuk 5000 pengguna

Dalam situasi kehidupan nyata, 5000 pengguna ini tidak akan berada di beranda tetapi di bagian lain situs web. Bagaimana kita bisa melakukan simulasi secara berbeda.

VUGen

VUGen atau Pengguna Virtual Generator adalah IDE (Integrated Development Environment) atau editor pengkodean yang kaya. VUGen digunakan untuk mereplikasi perilaku System Under Load (SUL). VUGen menyediakan fitur “perekaman” yang mencatat komunikasi ke dan dari klien dan Server dalam bentuk skrip berkode – juga disebut skrip VUser.

Jadi dengan mempertimbangkan contoh di atas, VUGen dapat merekam untuk mensimulasikan proses bisnis berikut:

1. Menjelajahi Halaman Produk Amazon.com
2. Pembayaran
3. Proses pembayaran
4. Memeriksa Halaman Akun Saya

pengawas

Setelah skrip VUser diselesaikan, Pengontrol adalah salah satu komponen LoadRunner utama yang mengontrol simulasi Beban dengan mengelola, misalnya:

• Berapa banyak VUser yang akan disimulasikan terhadap setiap proses bisnis atau VUser Group
• Perilaku VUsers (naik, turun, sifat simultan atau bersamaan, dsb.)
• Skenario Sifat Beban, misalnya Kehidupan Nyata atau Berorientasi Tujuan atau memverifikasi SLA
• Injektor mana yang digunakan, berapa banyak VUser terhadap setiap injektor
• Susun hasilnya secara berkala
• Pemalsuan IP
• Pelaporan kesalahan
• Pelaporan transaksi dll.

Mengambil analogi dari contoh pengontrol kami akan menambahkan parameter berikut ke Skrip VUGen

1) 3500 Pengguna adalah Menjelajahi Halaman Produk Amazon.com

2) 750 Pengguna masuk Pembayaran

3) 500 Pengguna adalah melakukan Pemrosesan Pembayaran

4) 250 Pengguna adalah Memeriksa Halaman Akun Saya HANYA setelah 500 pengguna melakukan Pemrosesan Pembayaran

Skenario yang lebih kompleks pun mungkin terjadi

1. Memulai 5 VUser setiap 2 detik hingga memuat 3500 VUser (berselancar Amazon halaman produk) tercapai.
2. Ulangi selama 30 menit
3. Tangguhkan iterasi untuk 25 VUser
4. Mulai ulang 20 VUSer
5. Memulai 2 pengguna (di Checkout, Pemrosesan Pembayaran, Halaman Akun Saya) setiap detik.
6. 2500 VUsers akan dihasilkan di Mesin A
7. 2500 VUsers akan dihasilkan di Mesin B

Agen Mesin/Beban Generators/Injektor

HP LoadRunner Controller bertanggung jawab untuk mensimulasikan ribuan VUser – VUser ini menggunakan sumber daya perangkat keras misalnya prosesor dan memori – sehingga memberikan batasan pada mesin yang melakukan simulasi. Selain itu, Pengontrol mensimulasikan VUser ini dari mesin yang sama (tempat Pengontrol berada) & karenanya hasilnya mungkin tidak tepat. Untuk mengatasi masalah ini, semua VUser tersebar di berbagai mesin, yang disebut Beban Generators atau Load Injector.

Sebagai praktik umum, Pengontrol berada di mesin yang berbeda dan beban disimulasikan dari mesin lain. Tergantung pada protokol skrip VUser dan spesifikasi mesin, sejumlah Load Injector mungkin diperlukan untuk simulasi penuh. Misalnya, VUser untuk skrip HTTP akan memerlukan 2-4MB per VUser untuk simulasi, maka 4 mesin dengan masing-masing RAM 4 GB akan diperlukan untuk mensimulasikan beban 10,000 VUser.

Mengambil Analogi dari kami Amazon Misalnya, keluaran dari komponen ini adalah

Analisis

Setelah skenario Load dijalankan, peran “Analisis” komponen LoadRunner masuk.

Selama eksekusi, Pengontrol membuat dump hasil dalam bentuk mentah & berisi informasi seperti, versi LoadRunner mana yang membuat dump hasil ini dan apa konfigurasinya.

Semua kesalahan dan pengecualian dicatat a Microsoft mengakses database, bernama, output.mdb. Komponen “Analisis” membaca file database ini untuk melakukan berbagai jenis analisis dan menghasilkan grafik.

Grafik ini menunjukkan berbagai tren untuk memahami alasan di balik kesalahan dan kegagalan saat memuat; sehingga membantu untuk mengetahui apakah optimasi diperlukan di SUL, Server (misalnya JBoss, Oracle) atau infrastruktur.

Di bawah ini adalah contoh dimana bandwidth dapat menyebabkan kemacetan. Katakanlah server Web memiliki kapasitas 1GBps sedangkan lalu lintas data melebihi kapasitas ini menyebabkan pengguna selanjutnya menderita. Untuk menentukan sistem memenuhi kebutuhan tersebut, Performance Engineer perlu menganalisis perilaku aplikasi dengan beban abnormal. Di bawah ini adalah grafik yang dihasilkan LoadRunner untuk memperoleh bandwidth.

Bagaimana Melakukan Pengujian Kinerja

Peta Jalan Pengujian Kinerja secara garis besar dapat dibagi menjadi 5 langkah:

• Perencanaan Uji Beban
• Buat Skrip VUGen
• Pembuatan Skenario
• Eksekusi Skenario
• Analisis Hasil (diikuti dengan penyesuaian sistem)

Sekarang setelah Anda menginstal LoadRunner, mari kita pahami langkah-langkah yang terlibat dalam proses satu per satu.

Langkah-langkah yang terlibat dalam proses Pengujian Kinerja

Langkah 1) Merencanakan Uji Beban

Perencanaan Pengujian Kinerja berbeda dengan perencanaan a SIT (Pengujian Integrasi Sistem) or UAT (Uji Penerimaan Pengguna). Perencanaan dapat dibagi lagi menjadi tahap-tahap kecil seperti dijelaskan di bawah ini:

Kumpulkan Tim Anda

Saat memulai Pengujian LoadRunner, yang terbaik adalah mendokumentasikan siapa yang akan berpartisipasi dalam aktivitas dari setiap tim yang terlibat selama proses tersebut.

Manajer Proyek:

Nominasikan manajer proyek yang akan memiliki aktivitas ini dan bertindak sebagai orang yang ditunjuk untuk eskalasi.

Fungsi Pakar/ Analis Bisnis:

Memberikan Analisis Penggunaan SUL & memberikan keahlian pada fungsi bisnis situs web/SUL

Pakar Pengujian Kinerja:

Membuat pengujian kinerja otomatis dan menjalankan skenario pemuatan

System Architek:

Memberikan cetak biru SUL

Pengembang Web dan UKM:

• Memelihara situs web & menyediakan aspek pemantauan
• Mengembangkan situs web dan memperbaiki bug

Administrator sistem:

• Mempertahankan server yang terlibat selama proyek pengujian

Garis besar aplikasi dan Proses Bisnis yang terlibat:

Sukses Pengujian beban mengharuskan Anda merencanakan untuk menjalankan proses bisnis tertentu. Proses Bisnis terdiri dari langkah-langkah yang didefinisikan dengan jelas sesuai dengan transaksi bisnis yang diinginkan – untuk mencapai tujuan pengujian beban Anda.

Metrik persyaratan dapat disiapkan untuk memperoleh beban pengguna pada sistem. Di bawah ini adalah contoh sistem absensi pada suatu perusahaan:

Pada contoh di atas, angka tersebut menyebutkan jumlah pengguna yang terhubung ke aplikasi (SUL) pada jam tertentu. Kita dapat mengekstrak jumlah maksimum pengguna yang terhubung ke proses bisnis pada jam berapa pun sepanjang hari yang dihitung di kolom paling kanan.

Demikian pula, kita dapat menyimpulkan jumlah total pengguna yang terhubung ke aplikasi (SUL) pada jam berapa pun sepanjang hari. Ini dihitung pada baris terakhir.

Gabungan 2 fakta di atas memberi kita jumlah total pengguna yang kita perlukan untuk menguji kinerja sistem.

Tentukan Prosedur Manajemen Data Uji

Statistik dan observasi yang diambil dari Performance Testing sangat dipengaruhi oleh berbagai faktor seperti yang dijelaskan sebelumnya. Mempersiapkan Data Uji untuk Pengujian Kinerja sangatlah penting. Terkadang, proses bisnis tertentu menggunakan kumpulan data dan menghasilkan kumpulan data yang berbeda. Ambil contoh di bawah ini:

• Pengguna 'A' membuat kontrak keuangan dan mengirimkannya untuk ditinjau.
• Pengguna lain 'B' menyetujui 200 kontrak sehari yang dibuat oleh pengguna 'A'
• Pengguna lain 'C' membayar sekitar 150 kontrak sehari yang disetujui oleh pengguna 'B'

Dalam situasi ini, Pengguna B perlu 'membuat' 200 kontrak di sistem. Selain itu, pengguna C memerlukan 150 kontrak sebagai "disetujui" untuk mensimulasikan beban 150 pengguna.

Ini secara implisit berarti Anda harus membuat setidaknya 200+150= 350 kontrak.

Setelah itu, setujui 150 kontrak untuk dijadikan data Uji bagi Pengguna C – 200 kontrak sisanya akan dijadikan Data Uji untuk Pengguna B.

Monitor Garis Besar

Berspekulasi setiap faktor yang mungkin dapat mempengaruhi kinerja suatu sistem. Misalnya, berkurangnya perangkat keras akan berdampak potensial pada kinerja SUL (System Under Load).

Daftarkan semua faktor dan siapkan monitor sehingga Anda dapat mengukurnya. Berikut beberapa contohnya:

• Prosesor (untuk Server Web, Server Aplikasi, Server Database, dan Injektor)
• RAM (untuk Server Web, Server Aplikasi, Server Database, dan Injektor)
• Server Web/Aplikasi (misalnya IIS, JBoss, Jaguar Server, Tomcat, dll)
• Server DB (ukuran PGA dan SGA jika Oracle dan MSSQL Server, SPs dll.)
• Pemanfaatan bandwidth jaringan
• NIC Internal dan Eksternal jika terjadi pengelompokan
• Penyeimbang Beban (dan mendistribusikan beban secara merata pada semua node kluster)
• Fluks data (hitung berapa banyak data yang berpindah ke dan dari klien dan server – lalu hitung apakah kapasitas NIC cukup untuk menyimulasikan X jumlah pengguna)

Langkah 2) Buat Skrip VUGen

Langkah selanjutnya setelah perencanaan adalah membuat Skrip VUser.

Langkah 3) Pembuatan Skenario

Langkah selanjutnya adalah membuat Skenario Beban Anda

Langkah 4) Eksekusi Skenario

Eksekusi skenario adalah saat Anda meniru beban pengguna pada server dengan menginstruksikan beberapa VUser untuk melakukan tugas secara bersamaan.

Anda dapat mengatur tingkat beban dengan menambah dan mengurangi jumlah VUser yang melakukan tugas pada waktu yang sama.

Eksekusi ini dapat mengakibatkan server mengalami stres dan berperilaku tidak normal. Inilah tujuan utama dari Pengujian kinerja. Hasil yang diambil kemudian digunakan untuk analisis rinci dan identifikasi akar permasalahan.

Langkah 5) Analisis Hasil (diikuti dengan penyesuaian sistem)

Selama pelaksanaan skenario, LoadRunner mencatat kinerja aplikasi di bawah berbagai beban. Statistik yang diambil dari pelaksanaan pengujian disimpan dan analisis detail dilakukan. Alat 'HP Analysis' menghasilkan berbagai grafik yang membantu mengidentifikasi akar penyebab di balik kelambatan kinerja sistem, serta kegagalan sistem.

Beberapa grafik yang diperoleh antara lain:

• Waktu ke buffer pertama
• Waktu Respons Transaksi
• Waktu Respons Transaksi Rata-rata
• Hit Per Detik
• Windows Sumber Daya
• Statistik Kesalahan
• Ringkasan Transaksi

Tanya Jawab