Alat Pengujian LoadRunner: ArchiDiagram dan Komponen Struktur

Apa itu LoadRunner?

LoadRunner adalah sebuah Pengujian Kinerja alat yang dipelopori oleh Mercury LoadRunner Interactive didirikan pada tahun 1999. Kemudian, LoadRunner diakuisisi oleh HP pada tahun 2006, dan bisnis perangkat lunak HP bergabung dengan Micro Focus dalam kesepakatan yang diumumkan pada tahun 2016 dan diselesaikan pada tahun 2017.

Catatan merek: OpenText menyelesaikan akuisisi Micro Focus pada Januari 2023.Alat tersebut tidak lagi dijual dengan merek HP atau Micro Focus LoadRunnerLoadRunner Professional kini tersedia OpenText Rekayasa Kinerja Profesional, LoadRunner Enterprise adalah OpenText Rekayasa Kinerja Perusahaan, dan LoadRunner Cloud adalah OpenText Rekayasa Kinerja Inti. Nama-nama komponen di bawah ini — VuGen, Pengontrol, generator beban, dan Analisis — tidak berubah.

LoadRunner mendukung berbagai alat pengembangan, teknologi, dan protokol komunikasi. Perangkat lunak ini memiliki salah satu pustaka protokol terluas di pasaran untuk melakukan Pengujian Kinerja. Hasil Pengujian Kinerja yang dihasilkan oleh perangkat lunak LoadRunner digunakan sebagai tolok ukur terhadap alat lain.

Video LoadRunner

Tonton video di bawah ini untuk pengenalan singkat tentang LoadRunner sebelum mempelajari komponen-komponennya.

Mengapa LoadRunner?

LoadRunner bukan hanya alat pelopor dalam Pengujian Kinerja, tetapi juga tetap menjadi salah satu pemimpin pasar dalam paradigma Pengujian Kinerja dan masih menjadi titik acuan yang digunakan banyak perusahaan untuk melakukan benchmarking.

Cakupan protokol adalah alasan paling jelas mengapa tim memilihnya, seperti yang ditunjukkan oleh peta komponen di bawah ini.

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 Socket. Hanya sedikit alat pesaing yang menawarkan beragam protokol dalam satu alat, seperti yang diilustrasikan oleh daftar protokol di bawah ini.

Yang lebih meyakinkan untuk memilih LoadRunner dalam pengujian perangkat lunak adalah kredibilitas alat ini. Alat LoadRunner telah lama membangun reputasi yang baik, karena seringkali Anda akan menemukan klien yang memverifikasi ulang 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 perangkat lunak sejenis dalam rangkaian yang sama — Unified Functional Testing (sebelumnya QTP, sekarang dijual sebagai OpenText Pengujian Fungsional) dan ALM (Manajemen Siklus Hidup Aplikasi, sekarang OpenText ALM/Quality Center) — yang memberdayakan Anda untuk melakukan Proses Pengujian ujung ke ujung.

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

Mengapa Anda memerlukan Pengujian Kinerja?

Estimasi industri di bawah ini banyak dikutip dan berasal dari awal tahun 2010-an, tetapi pola yang mereka gambarkan tidak berubah: halaman yang lambat akan merugikan.

Diperkirakan kerugian pendapatan sebesar 4.4 miliar dolar AS tercatat setiap tahunnya akibat kinerja web yang buruk.

Di era Web 2.0 saat ini, pengguna akan langsung meninggalkan situs web jika situs tersebut tidak merespons dalam waktu 8 detik. Bayangkan Anda menunggu selama 5 detik saat mencari informasi. Google atau mengirim permintaan pertemanan di Facebook. Dampak dari gangguan kinerja seringkali lebih menghancurkan daripada yang pernah dibayangkan. Ada contoh-contoh terkenal seperti yang menimpa Bank of America Online Banking, Amazon Layanan Web, Intuit dan Blackberry.

Menurut Dun & Bradstreet, 59% perusahaan Fortune 500 mengalami perkiraan 1.6 jam waktu henti setiap minggu. Mengingat rata-rata perusahaan Fortune 500 dengan minimal 10,000 karyawan membayar $56 per jam, biaya tenaga kerja akibat waktu henti untuk organisasi tersebut akan mencapai $896,000 per minggu, atau lebih dari $46 juta per tahun.

Hanya butuh waktu henti selama 5 menit. GoogleAkuisisi .com pada Agustus 2013 diperkirakan menelan biaya hingga $545,000 bagi raksasa mesin pencari tersebut.

Diperkirakan bahwa perusahaan-perusahaan kehilangan penjualan senilai $1,100 per detik selama periode sebelumnya. 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
• Jumlah pengguna yang mengakses sistem secara bersamaan lebih banyak dibandingkan sebelumnya.

Namun, tidak setiap lamaran merupakan kandidat yang memenuhi syarat. Pengujian beban Aplikasi ini menargetkan sistem klien-server multi-pengguna, jadi utilitas desktop pengguna tunggal seperti yang di bawah ini tidak layak diuji performanya.

Apa itu LoadRunner Architekstur?

Secara garis besar, arsitektur LoadRunner kompleks, namun mudah dipahami. Diagram arsitektur LoadRunner di bawah ini menunjukkan bagaimana keempat komponen tersebut bekerja sama.

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

Dalam situasi nyata, ke-5000 pengguna ini tidak semuanya akan berada di halaman beranda — mereka akan tersebar di berbagai bagian situs web. Jadi, bagaimana kita mensimulasikan perbedaan tersebut?

VuGen

VuGen atau Pengguna Virtual Generator VuGen adalah IDE (Integrated Development Environment) atau editor kode yang canggih. 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 kode – juga disebut Skrip VUser.

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

• Menjelajahi Halaman Produk Amazon.com
• Pembayaran
• Proses pembayaran
• Memeriksa Halaman Akun Saya

Setelah skrip diputar ulang dengan lancar, nilai server dinamis biasanya harus ditangkap dengan korelasi sebelum dapat ditingkatkan skalanya.

pengawas

Setelah skrip VUser selesai dibuat, maka... pengawas merupakan salah satu komponen utama LoadRunner 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 kita, Controller akan menambahkan parameter berikut ke skrip VuGen:

1. 3500 Pengguna Sedang Mengunjungi Halaman Produk dari Amazon.com
2. 750 Pengguna sedang dalam proses pembayaran
3. 500 Pengguna sedang melakukan Pemrosesan Pembayaran
4. 250 pengguna memeriksa halaman Akun Saya HANYA setelah 500 pengguna menyelesaikan Pemrosesan Pembayaran

Skenario yang lebih kompleks pun dimungkinkan:

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

Agen Mesin/Beban Generators/Injektor

Pengontrol LoadRunner bertanggung jawab untuk mensimulasikan ribuan VUser – VUser ini mengkonsumsi sumber daya perangkat keras, misalnya prosesor dan memori – sehingga membatasi kemampuan mesin yang mensimulasikannya. Selain itu, Pengontrol mensimulasikan VUser ini dari mesin yang sama (tempat Pengontrol berada) dan oleh karena itu hasilnya mungkin tidak akurat. Untuk mengatasi masalah ini, semua VUser disebar ke berbagai mesin, yang disebut LoadRunnerController. 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 kita Amazon Sebagai contoh, output dari komponen ini adalah 5000 VUser yang dibagi ke dalam dua injector: 2500 VUser dihasilkan pada Mesin A dan 2500 pada Mesin B.

Sampel

Setelah skenario pemuatan dieksekusi, peran dari Sampel Komponen LoadRunner berperan di sini.

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 basis data bernama output.mdb. Komponen Analisis membaca file basis data 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.

Berikut adalah contoh di mana bandwidth dapat menciptakan hambatan. Katakanlah server web memiliki kapasitas 1 GBps, sedangkan lalu lintas data melebihi kapasitas ini sehingga menyebabkan pengguna selanjutnya mengalami masalah. Untuk menentukan apakah sistem tersebut mampu memenuhi kebutuhan tersebut, Insinyur Kinerja perlu menganalisis perilaku aplikasi dengan beban abnormal. Berikut adalah grafik yang dihasilkan LoadRunner untuk mendapatkan data bandwidth.

Bagaimana Melakukan Pengujian Kinerja

Peta jalan pengujian kinerja secara garis besar dapat dibagi menjadi 5 langkah, yang dirangkum dalam peta jalan di bawah ini:

1. Perencanaan Uji Beban
2. Buat Skrip VuGen
3. Pembuatan Skenario
4. Eksekusi Skenario
5. Analisis Hasil (diikuti dengan penyesuaian sistem)

Setelah LoadRunner terpasang, mari kita pahami langkah-langkah yang terlibat dalam proses tersebut satu per satu.

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 dengan LoadRunner, sebaiknya dokumentasikan siapa saja yang akan berpartisipasi dalam aktivitas dari setiap tim yang terlibat selama proses tersebut, seperti yang tertera pada bagan tim di bawah ini.

• Manajer Proyek: Nominasikan manajer proyek yang akan memiliki aktivitas ini dan bertindak sebagai orang yang ditunjuk untuk eskalasi.
• Pakar Fungsional / Analis Bisnis: Menyediakan analisis penggunaan SUL dan keahlian tentang fungsionalitas bisnis situs web atau SUL.
• Pakar Pengujian Kinerja: Membuat pengujian kinerja otomatis dan menjalankan skenario beban.
• System Architek: Menyediakan cetak biru SUL.
• Pengembang Web dan UKM: Bertanggung jawab atas pemeliharaan situs web, penyediaan aspek pemantauan, pengembangan situs web, dan perbaikan bug.
• Administrator sistem: Bertanggung jawab atas pemeliharaan server yang terlibat selama proyek pengujian.

Uraikan 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-angka tersebut menyebutkan jumlah pengguna yang terhubung ke aplikasi (SUL) pada jam tertentu. Kita dapat mengharapkantract adalah jumlah maksimum pengguna yang terhubung ke proses bisnis pada jam berapa pun dalam sehari, yang dihitung pada 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:

• Seorang pengguna 'A' membuat sebuah transaksi keuangan.tracdan mengirimkannya untuk ditinjau.
• Pengguna lain 'B' menyetujui 200 contracIni adalah hari yang dibuat oleh pengguna 'A'
• Pengguna lain 'C' membayar sekitar 150 contracts hari yang disetujui oleh pengguna 'B'

Dalam situasi ini, Pengguna B perlu memiliki 200 contracts 'dibuat' dalam sistem. Selain itu, pengguna C membutuhkan 150 contracts sebagai "disetujui" untuk mensimulasikan beban 150 pengguna.

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

Setelah itu, setujui 150 kontracts akan digunakan sebagai data uji untuk Pengguna C – 200 sisanyatracts akan berfungsi sebagai Data Uji untuk Pengguna B.

Monitor Garis Besar

Pertimbangkan setiap faktor yang mungkin memengaruhi kinerja suatu sistem. Misalnya, pengurangan perangkat keras berpotensi berdampak 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)
• Data flux (hitung berapa banyak data yang berpindah ke dan dari klien dan server – kemudian hitung apakah kapasitas NIC cukup untuk mensimulasikan sejumlah X pengguna)

Langkah 2) Buat Skrip VuGen

Langkah selanjutnya setelah perencanaan adalah membuat skrip VUser, menambahkan parameterisasi, transaksi, dan pengaturan waktu proses Seiring berjalannya naskah.

Langkah 3) Pembuatan Skenario

Langkah selanjutnya adalah membuat Skenario Beban Anda di Controller, dengan memilih antara skenario manual dan skenario berorientasi tujuan.

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 gangguan. tekanan dan berperilaku tidak normal. Inilah tujuan utama dari Pengujian Kinerja. Hasil yang diperoleh kemudian digunakan untuk analisis terperinci dan identifikasi akar penyebab.

Langkah 5) Analisis Hasil (diikuti dengan penyesuaian sistem)

Selama eksekusi skenario, LoadRunner merekam kinerja aplikasi di bawah beban yang berbeda. Statistik yang diperoleh dari eksekusi pengujian disimpan dan analisis terperinci dilakukan. Alat Analisis (dengan merek 'HP Analysis' pada rilis yang digunakan dalam panduan ini) menghasilkan berbagai grafik yang membantu mengidentifikasi akar penyebab di balik penurunan 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 Publikasi
• Statistik Kesalahan
• Ringkasan Transaksi

Pertanyaan Umum Demo Slot