Apa itu Alat Pengujian HP LoadRunner? Arsitektur, Komponen

Apa itu LoadRunner?

LoadRunner adalah alat Pengujian Kinerja yang dirintis 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 melakukan Pengujian Kinerja. Hasil Uji Kinerja yang dihasilkan oleh perangkat lunak LoadRunner digunakan sebagai tolok ukur terhadap alat lain

Dalam tutorial ini, Anda akan belajar-

• Mengapa LoadRunner?
• Mengapa Anda membutuhkan Pengujian Kinerja?
• Apa itu Arsitektur LoadRunner?
• Roadmap Pengujian Kinerja: Langkah Terperinci
• FAQ

Mengapa LoadRunner?

LoadRunner bukan hanya alat perintis dalam Pengujian Kinerja, tetapi 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 (Rich Internet Applications), Web 2.0 (HTTP / HTML, Ajax, Flex dan Silverlight dll.), Mobile, SAP, Oracle, MS SQL Server, Citrix, RTE, Mail dan yang terpenting, Windows Socket. Tidak ada alat pesaing di pasar yang dapat menawarkan berbagai macam protokol dalam satu alat.

Yang lebih meyakinkan untuk memilih LoadRunner dalam pengujian perangkat lunak adalah kredibilitas alat ini. Alat LoadRunner telah lama memiliki reputasi karena sering kali Anda akan menemukan klien yang 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 lain seperti Unified Functional Test (QTP) & ALM (Application Lifecycle Management) dengan 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 VUsers, mereplikasi permintaan klien dan mengharapkan respons yang sesuai untuk meneruskan transaksi.

Mengapa Anda membutuhkan Pengujian Kinerja?

Perkiraan kerugian pendapatan 4,4 miliar dicatat setiap tahun karena kinerja web yang buruk.

Di era Web 2.0 saat ini, pengguna mengklik jika situs web tidak merespons dalam 8 detik. Bayangkan diri Anda menunggu selama 5 detik saat mencari Google atau membuat permintaan pertemanan di Facebook. Dampak dari waktu henti kinerja seringkali lebih menghancurkan daripada yang pernah dibayangkan. Kami memiliki contoh seperti yang baru-baru ini menghantam Bank of America Online Banking, Amazon Web Services, Intuit atau Blackberry.

Menurut Dunn & Bradstreet, 59% dari perusahaan Fortune 500 mengalami perkiraan waktu henti 1,6 jam setiap minggu. Mempertimbangkan rata-rata perusahaan Fortune 500 dengan minimal 10.000 karyawan membayar $ 56 per jam, bagian tenaga kerja dari biaya waktu henti untuk organisasi semacam itu adalah $ 896.000 setiap minggu, yang berarti lebih dari $ 46 juta per tahun.

Hanya downtime 5 menit dari Google.com (19-Agustus-13) diperkirakan merugikan raksasa pencarian sebanyak $ 545.000.

Diperkirakan bahwa perusahaan kehilangan penjualan senilai $ 1.100 per detik karena Penghentian Layanan Web Amazon baru-baru ini.

Ketika sistem perangkat lunak digunakan oleh suatu organisasi, itu mungkin menghadapi banyak skenario yang mungkin mengakibatkan latensi kinerja. Sejumlah faktor menyebabkan kinerja melambat, beberapa contoh mungkin termasuk:

• Meningkatnya jumlah record yang ada di database
• Meningkatnya jumlah permintaan simultan yang dibuat ke sistem
• lebih banyak pengguna yang mengakses sistem pada satu waktu dibandingkan dengan sebelumnya

Apa itu Arsitektur LoadRunner?

Secara garis besar, arsitektur HP LoadRunner rumit, namun mudah dipahami.

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

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

VUGen:

VUGen atau Virtual User 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 merekam 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. Jelajahi Halaman Produk Amazon.com
2. Periksa
3. Proses pembayaran
4. Memeriksa Halaman Akun Saya

Kontroler

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 (ramp up, ramp down, sifat simultan atau bersamaan, dll.)
• Skenario Sifat Beban misalnya Kehidupan Nyata atau Berorientasi Sasaran atau memverifikasi SLA
• Injektor mana yang akan digunakan, berapa banyak VUser terhadap masing-masing injektor
• Kumpulkan hasil secara berkala
• Spoofing IP
• Pelaporan kesalahan
• Pelaporan transaksi dll.

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

1) 3500 Pengguna Menjelajahi Halaman Produk Amazon.com

2) 750 Pengguna sedang Checkout

3) 500 Pengguna sedang melakukan Pemrosesan Pembayaran

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

Skenario yang lebih kompleks dimungkinkan

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

Agen Mesin / Load Generator / Injector

HP LoadRunner Controller bertanggung jawab untuk mensimulasikan ribuan VUsers - VUsers ini menggunakan sumber daya perangkat keras seperti prosesor dan memori - sehingga membatasi mesin yang mensimulasikannya. Selain itu, Pengontrol mensimulasikan VUsers ini dari mesin yang sama (tempat Pengontrol berada) & karenanya hasilnya mungkin tidak tepat. Untuk mengatasi masalah ini, semua VUsers tersebar di berbagai mesin, yang disebut Load Generator atau Load Injector.

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

Mengambil Analogi dari Contoh Amazon kami, output dari komponen ini adalah

Analisis:

Setelah skenario Muat dijalankan, peran komponen " Analisis " dari 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 dalam database akses Microsoft, 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 beban; dengan demikian membantu untuk mengetahui apakah pengoptimalan diperlukan di SUL, Server (misalnya JBoss, Oracle) atau infrastruktur.

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

Roadmap Pengujian Kinerja: Langkah Terperinci

Roadmap Pengujian Kinerja secara garis besar dapat dibagi menjadi 5 langkah:

• Merencanakan Uji Beban
• Buat Skrip VUGen
• Pembuatan Skenario
• Eksekusi Skenario
• Analisis Hasil (diikuti dengan tweaker 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

Merencanakan Uji Beban

Perencanaan untuk Pengujian Kinerja berbeda dari perencanaan SIT (Pengujian Integrasi Sistem) atau UAT (Pengujian Penerimaan Pengguna). Perencanaan dapat dibagi lagi menjadi beberapa tahap kecil seperti yang 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.

Ahli Fungsi / Analis Bisnis:

Menyediakan Analisis Penggunaan SUL & menyediakan keahlian dalam fungsi bisnis situs web / SUL

Pakar Pengujian Kinerja:

Membuat tes kinerja otomatis dan menjalankan skenario beban

Arsitek Sistem:

Memberikan cetak biru SUL

Pengembang Web dan UKM:

• Menjaga 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:

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

Metrik persyaratan dapat disiapkan untuk mendapatkan beban pengguna pada sistem. Di bawah ini adalah contoh sistem absensi di sebuah perusahaan:

Dalam contoh di atas, angka tersebut menyebutkan jumlah pengguna yang terhubung ke aplikasi (SUL) pada jam tertentu. Kami dapat mengekstrak jumlah maksimum pengguna yang terhubung ke proses bisnis pada jam berapa pun dalam sehari yang dihitung di kolom paling kanan.

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

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

Tentukan Prosedur Manajemen Data Uji

Statistik dan pengamatan yang diambil dari Pengujian Kinerja sangat dipengaruhi oleh banyak faktor seperti yang dijelaskan sebelumnya. Ini sangat penting untuk mempersiapkan Data Uji untuk Pengujian Kinerja. Terkadang, proses bisnis tertentu menggunakan kumpulan data dan menghasilkan kumpulan data yang berbeda. Ambil contoh di bawah ini:

• Seorang 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 harus memiliki 200 kontrak yang 'dibuat' dalam sistem. Selain itu, pengguna C membutuhkan 150 kontrak sebagai "disetujui" untuk mensimulasikan beban 150 pengguna.

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

Setelah itu, setujui 150 kontrak untuk dijadikan sebagai data Uji untuk Pengguna C - sisa 200 kontrak akan berfungsi sebagai Data Uji untuk Pengguna B.

Monitor Garis Besar

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

Buat daftar semua faktor dan atur monitor agar Anda dapat mengukurnya. Berikut beberapa contohnya:

• Prosesor (untuk Server Web, Server Aplikasi, Server Database, dan Injector)
• RAM (untuk Server Web, Server Aplikasi, Server Database, dan Injector)
• Web / App Server (misalnya IIS, JBoss, Jaguar Server, Tomcat dll)
• Server DB (ukuran PGA dan SGA untuk Oracle dan MSSQL Server, SPs, dll.)
• Pemanfaatan bandwidth jaringan
• NIC Internal dan Eksternal dalam kasus pengelompokan
• Load Balancer (dan mendistribusikan beban secara merata di semua node cluster)
• Fluks data (hitung berapa banyak data yang berpindah ke dan dari klien dan server - lalu hitung apakah kapasitas NIC cukup untuk mensimulasikan X jumlah pengguna)

Buat Skrip VUGen

Langkah selanjutnya setelah perencanaan adalah membuat skrip VUser.

Pembuatan Skenario

Langkah selanjutnya adalah membuat Skenario Beban Anda

Eksekusi Skenario

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

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

Eksekusi ini dapat mengakibatkan server menjadi stres dan berperilaku tidak normal. Ini adalah tujuan utama dari Pengujian kinerja. Hasil yang diambil kemudian digunakan untuk analisis rinci dan identifikasi akar penyebab.

Analisis Hasil (diikuti dengan tweaker sistem)

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

Beberapa grafik yang diperoleh antara lain:

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

FAQ

Aplikasi mana yang harus kami uji kinerja?

Pengujian Kinerja selalu dilakukan untuk sistem berbasis klien-server saja. Ini berarti, aplikasi apa pun yang bukan arsitektur berbasis klien-server, tidak boleh memerlukan Pengujian Kinerja.

Misalnya, Microsoft Calculator tidak berbasis klien-server juga tidak menjalankan banyak pengguna; oleh karena itu, ini bukan kandidat untuk Pengujian Kinerja.

Apa perbedaan antara Pengujian Kinerja & Rekayasa Kinerja

Sangatlah penting untuk memahami perbedaan antara Pengujian Kinerja dan Rekayasa Kinerja. Pemahaman dibagikan di bawah ini:

Pengujian Kinerja adalah disiplin ilmu yang berkaitan dengan pengujian dan pelaporan kinerja saat ini dari aplikasi perangkat lunak di bawah berbagai parameter.

Rekayasa kinerja adalah proses di mana perangkat lunak diuji dan disetel dengan tujuan untuk mewujudkan kinerja yang diperlukan. Proses ini bertujuan untuk mengoptimalkan sifat kinerja aplikasi yang paling penting, yaitu pengalaman pengguna.

Secara historis, pengujian dan penyetelan telah terpisah dengan jelas dan sering kali merupakan ranah yang bersaing. Namun, dalam beberapa tahun terakhir, beberapa kantong penguji dan pengembang telah berkolaborasi secara independen untuk membuat tim tuning. Karena tim-tim ini meraih kesuksesan yang signifikan, konsep menggabungkan pengujian kinerja dengan penyetelan kinerja menjadi populer, dan sekarang kami menyebutnya rekayasa kinerja.