Apa itu Alat Uji HP LoadRunner? Senibina, Komponen

Apa itu LoadRunner?

LoadRunner adalah alat Uji Prestasi yang dipelopori oleh Mercury pada tahun 1999. LoadRunner kemudiannya diambil alih oleh HPE pada tahun 2006. Pada tahun 2016, LoadRunner diambil alih oleh MicroFocus.

LoadRunner menyokong pelbagai alat pembangunan, teknologi dan protokol komunikasi. Sebenarnya, ini adalah satu-satunya alat di pasaran yang menyokong sebilangan besar protokol untuk melakukan Ujian Prestasi. Hasil Ujian Prestasi yang dihasilkan oleh perisian LoadRunner digunakan sebagai penanda aras berbanding alat lain

Dalam tutorial ini, anda akan belajar-

• Mengapa LoadRunner?
• Mengapa anda memerlukan Ujian Prestasi?
• Apakah Arkitek LoadRunner?
• Peta Jalan Ujian Prestasi: Langkah Terperinci
• Soalan Lazim

Mengapa LoadRunner?

LoadRunner bukan hanya alat perintis dalam Pengujian Prestasi, tetapi masih menjadi peneraju pasaran dalam paradigma Pengujian Prestasi. Dalam penilaian baru-baru ini, LoadRunner mempunyai sekitar 85% bahagian pasaran dalam industri Testing Performance.

Secara amnya, alat LoadRunner menyokong RIA (Aplikasi Internet Kaya), Web 2.0 (HTTP / HTML, Ajax, Flex dan Silverlight dll.), Mudah Alih, SAP, Oracle, MS SQL Server, Citrix, RTE, Mail dan di atas semua, Windows Socket. Tidak ada alat pesaing di pasar yang dapat menawarkan berbagai macam protokol yang terletak pada satu alat.

Apa yang lebih meyakinkan untuk memilih LoadRunner dalam ujian perisian adalah kredibiliti alat ini. Alat LoadRunner telah lama membina reputasi kerana anda akan sering menemui pelanggan yang mengesahkan penanda aras prestasi anda menggunakan LoadRunner. Anda akan mendapat kelegaan jika anda sudah menggunakan LoadRunner untuk keperluan ujian prestasi anda.

Perisian LoadRunner diintegrasikan dengan erat dengan Alat HP lain seperti Ujian Fungsi Bersatu (QTP) & ALM (Pengurusan Kitaran Hidup Aplikasi) dengan memberi anda keupayaan untuk melakukan Proses Ujian akhir hingga akhir.

LoadRunner berfungsi pada prinsip mensimulasikan Pengguna Maya pada aplikasi subjek. Pengguna Maya ini juga disebut sebagai VUsers, meniru permintaan pelanggan dan mengharapkan tindak balas yang sesuai untuk melakukan transaksi.

Mengapa anda memerlukan Ujian Prestasi?

Anggaran kerugian 4.4 bilion pendapatan dicatatkan setiap tahun kerana prestasi web yang buruk.

Pada zaman Web 2.0 sekarang, pengguna mengklik jika laman web tidak bertindak balas dalam masa 8 saat. Bayangkan diri anda menunggu selama 5 saat ketika mencari Google atau membuat permintaan rakan di Facebook. Akibat penurunan prestasi sering kali lebih dahsyat daripada yang pernah dibayangkan. Kami mempunyai contoh seperti yang baru-baru ini melanda Bank of America Online Banking, Amazon Web Services, Intuit atau Blackberry.

Menurut Dunn & Bradstreet, 59% daripada syarikat Fortune 500 mengalami 1.6 jam waktu henti setiap minggu. Memandangkan syarikat Fortune 500 rata-rata dengan minimum 10.000 pekerja membayar $ 56 per jam, bahagian buruh dari waktu henti untuk organisasi seperti itu adalah $ 896,000 setiap minggu, yang berarti lebih dari $ 46 juta per tahun.

Hanya 5 minit waktu henti Google.com (19-Ogos-13) dianggarkan menelan belanja gergasi pencarian sebanyak $ 545,000.

Dianggarkan bahawa syarikat-syarikat kehilangan penjualan bernilai $ 1100 sesaat kerana Pemadaman Perkhidmatan Web Amazon baru-baru ini.

Apabila sistem perisian digunakan oleh organisasi, mungkin menghadapi banyak senario yang mungkin mengakibatkan latensi prestasi. Sejumlah faktor menyebabkan prestasi menurun, beberapa contoh termasuk:

• Peningkatan jumlah rekod yang terdapat dalam pangkalan data
• Peningkatan jumlah permintaan serentak yang dibuat ke sistem
• sebilangan besar pengguna mengakses sistem pada satu masa berbanding dengan masa lalu

Apakah Arkitek LoadRunner?

Secara umum, seni bina HP LoadRunner adalah kompleks, namun mudah difahami.

Katakan anda ditugaskan untuk memeriksa prestasi Amazon.com untuk 5000 pengguna

Dalam situasi kehidupan sebenar, semua 5000 pengguna ini tidak akan berada di laman utama tetapi di bahagian laman web yang berbeza. Bagaimana kita dapat mensimulasikan secara berbeza

VUGEN:

VUGen atau Penjana Pengguna Maya adalah IDE (Integrated Development Environment) atau penyunting pengkodan yang kaya. VUGen digunakan untuk meniru tingkah laku System Under Load (SUL). VUGen menyediakan fitur "rakaman" yang merekam komunikasi ke dan dari klien dan Server dalam bentuk skrip berkod - juga disebut skrip VUser.

Oleh itu, dengan mempertimbangkan contoh di atas, VUGen dapat merakam untuk mensimulasikan proses perniagaan berikut:

1. Melayari Laman Produk Amazon.com
2. Daftar keluar
3. Proses Pembayaran
4. Menyemak Halaman Akaun Saya

Pengawal

Setelah skrip VUser diselesaikan, Controller adalah salah satu komponen LoadRunner utama yang mengawal simulasi Load dengan menguruskan, misalnya:

• Berapa banyak pengguna yang perlu disimulasikan terhadap setiap proses perniagaan atau Kumpulan VUser
• Tingkah laku VUsers (ramp up, ramp down, sifat serentak atau serentak dll.)
• Senario sifat Beban seperti Kehidupan Sebenar atau Berorientasikan Matlamat atau mengesahkan SLA
• Penyuntik mana yang hendak digunakan, berapa banyak VU untuk setiap penyuntik
• Hasil gabungan secara berkala
• IP Spoofing
• Ralat melaporkan
• Pelaporan transaksi dll.

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

1) 3500 Pengguna melayari Laman Produk Amazon.com

2) 750 Pengguna berada di Checkout

3) 500 Pengguna melakukan Pemprosesan Pembayaran

4) 250 Pengguna Memeriksa Halaman MyAccount HANYA setelah 500 pengguna melakukan Pemprosesan Pembayaran

Senario yang lebih kompleks lagi mungkin

1. Mulakan 5 VUsers setiap 2 saat sehingga 3500 VUsers (melayari halaman produk Amazon) tercapai.
2. Ulangi selama 30 minit
3. Tangguhkan lelaran selama 25 VUsers
4. Mulakan semula 20 VUSER
5. Mulakan 2 pengguna (di Checkout, Pemprosesan Pembayaran, Halaman MyAccounts) setiap saat.
6. 2500 pengguna akan dihasilkan di Mesin A
7. 2500 VUsers akan dihasilkan di Mesin B

Mesin Ejen / Penjana Beban / Penyuntik

HP LoadRunner Controller bertanggungjawab untuk mensimulasikan ribuan VUsers - VUsers ini menggunakan sumber perkakasan misalnya pemproses dan memori - oleh itu meletakkan had pada mesin yang mensimulasikannya. Selain itu, Controller mensimulasikan VUsers ini dari mesin yang sama (di mana Controller berada) & oleh itu hasilnya mungkin tidak tepat. Untuk mengatasi masalah ini, semua VUser tersebar di pelbagai mesin, yang disebut Load Generator atau Load Injectors.

Sebagai amalan umum, Controller menggunakan mesin yang berbeza dan beban disimulasikan dari mesin lain. Bergantung pada protokol skrip VUser dan spesifikasi mesin, sejumlah Load Injector mungkin diperlukan untuk simulasi penuh. Sebagai contoh, VUser untuk skrip HTTP akan memerlukan 2-4MB per VUser untuk simulasi, oleh itu 4 mesin dengan RAM 4 GB setiap satu akan diperlukan untuk mensimulasikan muatan 10,000 VUser.

Mengambil Analogi dari Contoh Amazon kami, output komponen ini adalah

Analisis:

Setelah senario Load dilaksanakan, peranan komponen " Analisis " LoadRunner masuk.

Semasa pelaksanaan, Controller membuat dump hasil dalam bentuk mentah & mengandungi maklumat seperti, versi LoadRunner yang membuat dump hasil ini dan apa konfigurasi.

Semua kesalahan dan pengecualian dicatatkan dalam pangkalan data akses Microsoft, bernama, output.mdb. Komponen "Analisis" membaca fail pangkalan data ini untuk melakukan pelbagai jenis analisis dan menghasilkan grafik.

Grafik ini menunjukkan pelbagai trend untuk memahami alasan di sebalik kesilapan dan kegagalan di bawah beban; Oleh itu, membantu untuk mengetahui sama ada pengoptimuman diperlukan dalam SUL, Server (contohnya JBoss, Oracle) atau infrastruktur.

Di bawah ini adalah contoh di mana lebar jalur boleh membuat masalah. Katakan pelayan Web mempunyai kapasiti 1GBps sedangkan trafik data melebihi kapasiti ini menyebabkan pengguna seterusnya menderita. Untuk menentukan sistem memenuhi keperluan tersebut, Performance Engineer perlu menganalisis tingkah laku aplikasi dengan beban yang tidak normal. Di bawah ini adalah grafik yang dihasilkan LoadRunner untuk mendapatkan lebar jalur.

Peta Jalan Ujian Prestasi: Langkah Terperinci

Peta Jalan Uji Prestasi boleh dibahagikan kepada 5 langkah:

• Merancang Ujian Beban
• Buat Skrip VUGen
• Penciptaan Senario
• Pelaksanaan Senario
• Analisis Hasil (diikuti dengan tweak sistem)

Sekarang setelah anda memasang LoadRunner, mari kita fahami langkah-langkah yang terlibat dalam proses satu persatu.

Langkah-langkah yang terlibat dalam proses Pengujian Prestasi

Merancang Ujian Beban

Perancangan untuk Ujian Prestasi berbeza dengan merancang SIT (Uji Integrasi Sistem) atau UAT (Uji Penerimaan Pengguna). Perancangan dapat dibahagikan lagi kepada tahap kecil seperti yang dijelaskan di bawah:

Kumpulkan Pasukan Anda

Semasa memulakan Ujian LoadRunner, lebih baik mendokumentasikan siapa yang akan mengambil bahagian dalam aktiviti dari setiap pasukan yang terlibat semasa proses tersebut.

Pengurus projek:

Namakan pengurus projek yang akan memiliki aktiviti ini dan berperanan sebagai orang penting untuk peningkatan.

Pakar Fungsi / Penganalisis Perniagaan:

Berikan Analisis Penggunaan SUL & berikan kepakaran mengenai fungsi perniagaan laman web / SUL

Pakar Ujian Prestasi:

Membuat ujian prestasi automatik dan melaksanakan senario beban

Arkitek Sistem:

Menyediakan rangka tindakan SUL

Pembangun Web dan PKS:

• Menyelenggara laman web & menyediakan aspek pemantauan
• Membangunkan laman web dan memperbaiki pepijat

Pentadbir Sistem:

• Menyelenggara pelayan yang terlibat sepanjang projek ujian

Garis besar aplikasi dan Proses Perniagaan yang terlibat:

Ujian Beban yang Berjaya menghendaki anda merancang untuk menjalankan proses perniagaan tertentu. Proses Perniagaan terdiri daripada langkah-langkah yang ditentukan dengan jelas sesuai dengan transaksi perniagaan yang diinginkan - untuk mencapai objektif pengujian beban anda.

Metrik keperluan dapat disiapkan untuk mendapatkan beban pengguna pada sistem. Berikut adalah contoh sistem kehadiran di syarikat:

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 dengan proses perniagaan pada setiap jam sepanjang hari yang dikira di lajur paling kanan.

Begitu juga, kita dapat menyimpulkan jumlah pengguna yang terhubung ke aplikasi (SUL) pada setiap jam sepanjang hari. Ini dikira pada baris terakhir.

2 fakta di atas digabungkan memberi kami jumlah pengguna yang kami perlukan untuk menguji prestasi sistem.

Tentukan Prosedur Pengurusan Data Ujian

Statistik dan pemerhatian yang diambil dari Uji Prestasi sangat dipengaruhi oleh banyak faktor seperti yang telah dinyatakan sebelumnya. Penting untuk menyediakan Data Ujian untuk Ujian Prestasi. Kadang kala, proses perniagaan tertentu memakan satu set data dan menghasilkan satu set data yang berbeza. Ambil contoh di bawah:

• Pengguna 'A' membuat kontrak kewangan dan menyerahkannya untuk disemak.
• Pengguna lain 'B' meluluskan 200 kontrak sehari yang dibuat oleh pengguna 'A'
• Pengguna lain 'C' membayar kira-kira 150 kontrak sehari yang diluluskan oleh pengguna 'B'

Dalam keadaan ini, Pengguna B perlu mempunyai 200 kontrak 'dibuat' dalam sistem. Selain itu, pengguna C memerlukan 150 kontrak sebagai "diluluskan" untuk mensimulasikan jumlah 150 pengguna.

Ini secara tersirat bermaksud bahawa anda mesti membuat sekurang-kurangnya 200 + 150 = 350 kontrak.

Selepas itu, luluskan 150 kontrak untuk dijadikan data Ujian untuk Pengguna C - selebihnya 200 kontrak akan berfungsi sebagai Data Ujian untuk Pengguna B.

Monitor Garis Besar

Nyatakan setiap faktor yang mungkin mempengaruhi prestasi sistem. Sebagai contoh, pengurangan perkakasan akan berpotensi mempengaruhi prestasi SUL (System Under Load).

Masukkan semua faktor dan sediakan monitor supaya anda dapat mengukurnya. Berikut adalah beberapa contoh:

• Pemproses (untuk Pelayan Web, Pelayan Aplikasi, Pelayan Pangkalan Data, dan Penyuntik)
• RAM (untuk Pelayan Web, Pelayan Aplikasi, Pelayan Pangkalan Data, dan Penyuntik)
• Pelayan Web / Aplikasi (contohnya IIS, JBoss, Jaguar Server, Tomcat dll)
• Pelayan DB (saiz PGA dan SGA sekiranya Oracle dan MSSQL Server, SPs dll.)
• Penggunaan lebar jalur rangkaian
• NIC Dalaman dan Luaran sekiranya berlaku pengelompokan
• Load Balancer (dan ia mengagihkan beban secara merata pada semua nod kluster)
• Fluks data (hitung berapa banyak data bergerak ke dan dari klien dan pelayan - kemudian hitung jika kapasiti NIC mencukupi untuk mensimulasikan bilangan pengguna X)

Buat Skrip VUGen

Langkah seterusnya selepas merancang adalah membuat skrip VUser.

Penciptaan Senario

Langkah seterusnya adalah membuat Senario Beban anda

Pelaksanaan Senario

Pelaksanaan senario adalah di mana anda meniru beban pengguna di pelayan dengan memerintahkan beberapa pengguna untuk melakukan tugas secara serentak.

Anda boleh menetapkan tahap beban dengan meningkatkan dan mengurangkan jumlah pengguna yang melakukan tugas pada masa yang sama.

Pelaksanaan ini boleh menyebabkan pelayan mengalami tekanan dan berkelakuan tidak normal. Inilah tujuan Ujian prestasi. Hasil yang diambil kemudian digunakan untuk analisis terperinci dan pengenalan punca.

Analisis Hasil (diikuti dengan tweak sistem)

Semasa pelaksanaan senario, LoadRunner mencatat prestasi aplikasi di bawah beban yang berbeza. Statistik yang diambil dari pelaksanaan ujian disimpan dan analisis perincian dilakukan. Alat 'Analisis HP' menghasilkan pelbagai grafik yang membantu dalam mengenal pasti punca-punca di sebalik ketinggalan prestasi sistem, dan juga kegagalan sistem.

Beberapa grafik yang diperoleh merangkumi:

• Masa ke penyangga pertama
• Masa Respons Transaksi
• Masa Respons Transaksi Purata
• Hit Per Detik
• Sumber Windows
• Statistik Kesalahan
• Ringkasan Transaksi

Soalan Lazim

Aplikasi mana yang harus kita Uji Prestasi?

Uji Prestasi selalu dilakukan untuk sistem berasaskan pelayan pelanggan sahaja. Ini bermaksud, setiap aplikasi yang bukan seni bina berasaskan pelayan pelanggan, tidak mesti memerlukan Uji Prestasi.

Sebagai contoh, Kalkulator Microsoft tidak berasaskan pelayan pelanggan dan tidak menjalankan banyak pengguna; oleh itu ia bukan calon Ujian Prestasi.

Apakah perbezaan antara Ujian Prestasi & Kejuruteraan Prestasi

Adalah mustahak untuk memahami perbezaan antara Ujian Prestasi dan Kejuruteraan Prestasi. Pemahaman dikongsi di bawah:

Performance Testing adalah disiplin yang berkaitan dengan pengujian dan pelaporan prestasi terkini aplikasi perisian di bawah pelbagai parameter.

Kejuruteraan prestasi adalah proses di mana perisian diuji dan ditala dengan tujuan untuk merealisasikan prestasi yang diperlukan. Proses ini bertujuan untuk mengoptimumkan sifat prestasi aplikasi yang paling penting iaitu pengalaman pengguna.

Dari segi sejarah, ujian dan penalaan telah terpisah secara nyata dan sering bersaing. Namun, dalam beberapa tahun kebelakangan ini, beberapa kumpulan penguji dan pembangun telah bekerjasama secara bebas untuk membuat pasukan penyesuaian. Kerana pasukan ini telah mencapai kejayaan yang besar, konsep penggabungan pengujian prestasi dengan penalaan prestasi telah mulai berjalan, dan sekarang kami menyebutnya sebagai kejuruteraan prestasi.