Bab 8.

Memilih Alat Uji Kanan Memilih alat uji yang tepat adalah penting untuk keberhasilan uji kinerja Anda. Anda tergantung pada kinerja alat untuk menangkap data yang dapat dipercaya dan berulang selama pengujian.Namun, tidak semua alat pengujian terbukti cocok untuk semua situasi pengujian. Bahkan, kadang-kadang kami menemukan alat jelas yangbenar-benar menghasilkan kinerja masalah! Dalam bab ini, kita membahas kriteria seleksi untuk alat uji kinerja. Sepertikita bahas pada Bab 7, kinerja alat yang paling datang dengan alat rekaman dan sering bahasa scriptingmereka sendiri. Oleh karena itu, memilih alat menyiratkan sebuah investasi tidak hanya dalam perangkat lunak alat,tetapi juga dalam script tes yang menghasilkan menggunakan alat. Memilih alat, baik yang kuat menghemat uang dalam biaya penggantian kemudian, dan juga dalam waktu diperlukan untuk membangun perpustakaan tes script Anda. Seperti yang akan kita bahas dalam Bab 11, tes sukses tergantung pada dua elemenpenting: P Simulasi lingkungan produksi diantisipasi P Mendapatkan pengukuran yang handal dan berulang Anda membutuhkan alat tes untuk mendukung kriteria keberhasilan. Kecuali tes Andacukup mensimulasikan diantisipasi lingkungan produksi, masalah mengakibatkan masalah produksi yang signifikansering tidak terdeteksi. Demikian juga, pengukuran dapat diandalkan dan berulang memungkinkan Anda untuk mengkorelasikan perubahan tuning dengan perbaikan daripada kesalahan pengukuran. Alat tes terus cepat meningkatkan kemampuan mereka. Untuk alasan ini, kami tidakmenyertakan fitur-tofeature perbandingan antara alat yang berbeda. Sebaliknya, kami menyediakan kerangkapersyaratan untuk menilai kinerja alat, dan mendiskusikan beberapa fitur kunci differentiators. Lampiran Cmencakup checklist meringkas persyaratan ini. Secara umum, Internet dan pasar keduanya mengandung banyak driver beban rendah-end, bebas, atau shareware, serta high-end driver beban. Beberapa low-end driver termasuk alat-alat seperti Apache Bench, Apache Banjir, Jmeter, atau Microsoft Web Kapasitas Alat Analisis (WCAT). Alat-alat inibiasanya bekerja terbaik untuk pengujian statis situs web atau situs dinamis sederhana. High-end driver beban berasal dari kualitasperangkat lunak terkemuka otomatis Alat vendor, termasuk Mercury Interaktif, Rasional, Segue, Compuware, Empirix, danRadView [1]. Tools di ini akhir pasar umumnya bekerja terbaik untuk situs web yang besar atau kompleks. Simulasi Produksi Persyaratan Sebuah alat kinerja mensimulasikan beban pengguna terhadap situs web Anda atau sistem tes. Ini kinerja otomatis alat bekerja lebih baik daripada penguji manusia dalam hampir semua kasus.Pertama-tama, Anda tidak bisa mengumpulkan seribu atau lebih manusia untuk menjalankan skenario uji terhadap sebuah situs web yang besar.Kedua, bahkan jika situs web Anda mendukung secara signifikan beban pengguna yang lebih kecil (20 atau 30 pengguna secara bersamaan,misalnya), penguji hidup biasanya tidak mensimulasikan dunia nyata pengguna dengan baik. Penguji hidup cenderung untuk mendapatkan "klik-senang"dan bergerak melalui situs web yang sangat cepat. Jadi, mereka biasanya menghasilkan kali berpikir jauh lebih pendek daripada yang ditemukandalam produksi. Sebuah alat otomatis memberi Anda lebih banyak kontrol atas simulasi, dan memungkinkan Anda untuk menguji beban yang lebih besar dengan sumber daya lebih sedikit.

Tes kinerja alat (kadang-kadang juga disebut driver beban) skrip pengujian Anda.Sebagaimana dibahas dalam Bab 7, driver beban yang paling memberikan kemampuan menangkap dan memutar ulang untuk sebagian mengotomatisasi penciptaan uji script. Teknologi ini memungkinkan Anda untuk "merekam" interaksi browser yangkhas dengan situs web Anda dan kemudian otomatis memutar ulang ini interaksi yang sama. Seperti ditunjukkan dalam Gambar 8.1, alat ini biasanya duduk antara browser dan server dan "mendengarkan" untuk arus lalu lintas untuk membuat script awal. Alat yang paling menyediakan beberapa jenis kemampuan merekam untuk awalnya membuat script. Namun, script direkambiasanya memerlukan tambahan kustomisasi memadai mensimulasikan pengguna yang sebenarnya. Membuatperubahan membutuhkan keterampilan pemrograman serta waktu. Figure 8.1. Script recording

Kinerja alat tes bervariasi secara signifikan dalam kemampuan dan harga. Untukmemilih alat yang tepat, mulailah dengan memahami fitur kunci dari situs Anda dan tujuan pengujian. Sebagai contoh, mari kitapikirkan kembali Bab 5 dan fitur yang membedakan untuk beberapa jenis situs web, seperti diringkas dalam Tabel 8.1. Mari peta beberapa perbedaan untuk menguji persyaratan alat untuksetiap jenis situs web utama. Table 8.1. Some Performance Characteristics of Common Web Site Types (Iki gambar table berroo)

Keuangan Situs Web Sebuah situs web keuangan pengalaman pengguna tekanan tinggi dan throughput tinggi. Situssitus web yang menerima besar jumlah pengguna, beberapa di antaranya tinggal di situs sepanjang hari, serta volumetransaksi besar. keamanan memainkan peran besar dalam situs tersebut. Oleh karena itu, alat simulasi beban untuk situs web keuangan harus mendukung berikut persyaratan: 1. Mensimulasikan banyak pengguna secara bersamaan 2. Mensimulasikan kedua sesi pengguna lama dan sejumlah besar pendek, sering dilihat 3. Mensimulasikan beban kerja campuran banyak pertanyaan dan sejumlah keciltransaksi membeli / menjual 4. Mensimulasikan transaksi yang aman 5. Mendukung transaksi throughput yang tinggi 6. Mensimulasikan lonjakan dalam lalu lintas B2B Situs Web Sebuah situs web B2B pengalaman pengguna tekanan tinggi tetapi dependensithroughput yang biasanya lebih rendah. Pengguna di B2B situs yang sering tinggal di sepanjang hari, dengan beberapa, tapi jarang, query daninteraksi update. Situs web mengamankan transaksi lalu lintas. Untuk mensimulasikan beban kerja B2B, mencari alat memuaskan persyaratan: 1. Mensimulasikan banyak log-on pengguna 2. Mensimulasikan sesi pengguna yang sangat panjang 3. Mensimulasikan beberapa transaksi dengan waktu menunggu lama 4. Mensimulasikan transaksi yang aman e-Commerce Web Site Sebuah situs e-Commerce menerima lebih banyak pengguna secara bersamaandan harus mendukung tingkat transaksi yang tinggi. pengguna biasanya mengunjungi situs tersebut secara singkat dan menganggap situs waktu responsangat penting. Browse rasio secara signifikan melebihi jumlah transaksi pembelian aktual. Situs ini memerlukan keamanan hanya untuk membeli dan akun terkait transaksi. Sebuah tool perlu dukungan berikut untuk mensimulasikan beban kerja e-Commerce: 1. Mensimulasikan banyak pengguna 2. Mensimulasikan campuran sesi pengguna pendek dan panjang 3. Mensimulasikan beban kerja campuran pertanyaan dan membeli / menjualtransaksi 4. Mensimulasikan transaksi yang aman 5. Mensimulasikan browsing / mencari database katalog besar item Jenis situs web yang didiskusikan disini berbagi beberapa persyaratan beban kerjasimulasi umum: Semua situs memerlukan cara untuk mensimulasikan sesi log-on pengguna, beban kerjacampuran membaca dan memperbarui transaksi, dan keamanan. Namun, tidak setiap situs terdaftar di sini saham setiap kebutuhan. Situs Anda jugamungkin

perlu kinerja khusus menguji fitur untuk memenuhi persyaratan. Misalnya, jika Anda uji kinerja situs eCommerce dengan besardatabase, Anda mungkin perlu alat yang mendukung pilihan mudah mengimpor dari database ini ke dalam script Anda. Mari kita mengambil pandangan mendalam pada beberapa pertimbangan alat yang berbeda untuk simulasi beban kerja. Pengguna Pengguna simulasi sangat penting untuk tes kinerja yang sukses. Setiap alat driver beban klaim kemampuan untuk mensimulasikan banyak pengguna. Namun, beberapa alat dapat mensimulasikan hanya sejumlah terbatas pengguna unik. Berdasarkan rencana uji Anda, menentukan berapa banyak pengguna yang Anda butuhkan untuk mensimulasikan, dan juga mempertimbangkan pengguna yang Anda butuhkan untuk masa pertumbuhan situs web. (Ingat, skrip pengujian merupakan suatu investasi. Pastikan perangkat Anda memenuhi pengujian beban proyeksi kebutuhan beberapa waktu ke depan.) Sebagai contoh, sebuah situs e-Commerce biasanya lebih simulasi kebutuhan pengguna dari situs B2B. Jumlah pengguna virtual diperlukan memberikan kontribusi signifikan terhadap biaya keseluruhan dari hardware dan software pengujian. Jelas, lebih realistis tes, semakin baik, namun simulasi semua pengguna diharapkan hanya mungkin terlalu banyak biaya. Differentiators utama antara alat simulasi tentang pengguna termasuk Pikirkan dukungan waktuP Pengguna ramp-up dan kontrol bebanP simulasi browser yang Akurat, termasuk cache browser yangP dukungan cookie Akurat, termasuk kemampuan untuk membuang cache cookie antara iterasi skripP Persyaratan Hardware dan dukungan platformP
Beberapa pembalap dukungan mesinP pikirkan Waktu Simulasi pengguna yang paling realistis termasuk berpikir simulasi waktu. Beberapaalat driver dasar beban, seperti Bench apache, tidak memberikan kemampuan untuk mensimulasikan berpikir waktu.Namun, hampir semua high-end menyediakan alat-alat berpikir dukungan waktu, meskipun mereka berbeda dalam fleksibilitas yang merekaberikan untuk menyesuaikan waktu tersebut. Jika simulasi berpikir waktu adalah kebutuhan prioritas tinggi untuk situs Anda, mencari alat yang memungkinkan Anda untuk mengubah berpikir kali tanpa manual memperbarui script Anda. Dalam rangka untuk biaya tes yang lebih rendah, Anda dapat mensimulasikan beban anda dengan menggunakan simulasi sedikit pengguna dengan sedikit atau tanpaberpikir waktu. Hal ini sering menghasilkan throughput yang diinginkan dengan sedikit lisensi pengguna. Misalnya, jika pasar Anda proyek penelitian 1.000 pengguna bersamaan, dan pengujian kegunaan Anda menunjukkan waktu berpikir rata-rata 10 detik, ini sama dengan 100 pengguna aktif pada setiap titik waktu. 1 request/10 detik / pengguna * 1.000 pengguna bersamaan = 100 permintaan pengguna / detik Dalam hal ini, menggunakan 100 klien tanpa berpikir waktu simulasi menghasilkanbeban aktif yang sama seperti 1.000 pengguna dengan berpikir waktu. Penting! Teknik ini terbukti efektif untuk banyak situs web menggunakan sesi HTTP dalam web

mereka aplikasi. Pada uji pertama, aplikasi Anda mengakses 1.000 sesi HTTP dalammemori, sedangkan pada tes kedua, ia mengakses hanya 100 sesi HTTP. Juga, HTTP sesi waktu keluar lebih cepat dengan menggunakan teknik ini daripada di tes pengguna penuh. Studi kasus pada Bab 14 memberikan contohpengujian dengan berpikir waktu berkurang. Tentu saja, jika Anda menggunakan teknik ini, mencari alat tes yang memungkinkanAnda untuk dengan mudah mengurangi atau menghilangkan berpikir kali selama pelaksanaan tes.
Kemampuan untuk Load Control Pengguna dan Ramp-Up Selain berapa banyak pengguna alat ini mendukung, juga mempertimbangkan jikaalat ini memungkinkan Anda untuk menambahkan pengguna simulasi selama tes lari. Menambahkan pengguna untuk tes berjalan membantu mensimulasikanlonjakan dalam pemuatan pengguna serta pola meningkatnya beban. Kebanyakan kinerja alat tes high-end memungkinkan Andauntuk menentukan berapa banyak pengguna untuk memulai dan kapan untuk menambahkan pengguna tambahan. Misalnya, ketika menjalankan tes 1.000pengguna, Anda mungkin mulai 100 pengguna dan menambahkan lain 100 pengguna setiap menit sampai mencapai 1.000 pengguna. Hal ini memberikan situs Anda bertahap "pemanasan" periode. Gambar 8.2 menunjukkan layar sampel LoadRunner kontroler. Dalam contoh ini, kita mendefinisikan LoadRunner untuk menjalankan "Ramp Up" jadwal, menambahkan 10 pengguna virtual setiap menit sampai mencapai total 100 pengguna. (LoadRunner memungkinkan kustomisasi ini ramp-up langkah dan jangka waktu) Tentu saja., jika beban alat driver Anda tidak memberikan fleksibilitas semacam ini manajemen pengguna, pertimbangkansimulasi ramp-up atau pola lonjakan dengan menggunakan beban sopir beberapa contoh. Sebagai contoh, mensimulasikan "spike" terhadapsebuah situs keuangan dengan memulai yang lain tes akhir tes untuk menghasilkan beban tambahan sistem. Namun, dengan menggunakan pendekatan ini membutuhkan panduan pengumpulan data yang dikembalikan dari kasus alat uji. Jangan meremehkankesulitan tugas ini.

Figure 8.2. Example LoadRunner ramp-up. 2002 Mercury Interactive Corporation.

Browser Simulasi dan Caching Selama perbandingan belanja Anda, pertimbangkan apakah alat benar mensimulasikan perilaku browser yang khas, termasuk kemampuan untuk menghapus item cache antara iterasi script. Beberapa alat menggunakan strategi cerdas untuk mensimulasikan cache browser. Misalnya, SilkPerformer tidak benar-benar menjaga cache browser (hanya berpikir berapa banyak ruang disk cache untuk setiap pengguna simulasi mungkin memerlukan), melainkan alat mengingat masing-masing pengguna "cache" item dengan nama, dan tidak meminta mereka lagi. Biasanya, alat high-end menyediakan pilihan beberapa membersihkan cache untuk pengguna simulasi yang berbeda. Jika situs web Anda berfokus pada dukungan untuk browser tertentu, memeriksa dukungan simulasi yang tepat untuk browser ini.

Jaringan Manajemen Alamat Jika situs Web Anda menggunakan load balancing, mencari alat yang kompatibel dengan penyeimbang beban Anda. Sebagaimana dibahas dalam Bab 3, solusi load balancing beberapa bergantung pada alamat IP klien. Selama tes beban, beban tunggal Generator dapat mensimulasikan ratusan klien yang berbeda. Jika masing-masing klien menerima alamat IP yang sama, Anda mengalahkan skema penyeimbang beban routing, dan semua lalu lintas Anda pergi ke mesin server yang sama dalam Anda tes cluster. Untuk bekerja di sekitar masalah ini, beberapa tim pengujian menggunakan mesin klien tes ganda, masing-masing dengan IP yang unik alamat. Juga, alat banyak kinerja mengelola pengguna simulasi di beberapa mesin klien secara otomatis dan menyediakan pelaporan konsolidasi dalam konfigurasi ini. Namun, alat-alat lain tidak, meninggalkan Anda untuk secara manual mengkonsolidasikan laporan dari setiap mesin klien. Jika Anda menguji beban balancing alamat IP untuk situs Anda, memberikan pertimbangan berhati-hati untuk membeli driver beban dengan IP alamat atau kemampuan simulasi dengan kemampuan untuk menyebar pengguna simulasi atas mesin beberapa klien.
Cookie Dukungan Jika aplikasi web Anda menggunakan cookies untuk mengasosiasikan pengguna dengan data sesi HTTP, pilih alat uji yang menangani cookie untuk setiap pengguna simulasi. [2] Juga, pastikan alat ini memungkinkan Anda untuk membuang tembolok cookie pengguna setelah setiap iterasi script. (Ini memungkinkan Anda untuk mensimulasikan sebuah user baru untuk setiap iterasi.) [2] Lihat Stephan Asboeck, Load Testing untuk eConfidence. Edisi saat ini alat tes yang paling mendukung cookie dalam beberapa mode.Pastikan Anda mendukung memenuhi kebutuhan dan membutuhkan kustomisasi sedikit atau tidak ada pada bagian Anda berfungsi dengan baik. Hardware dan Dukungan platform Jangan mengabaikan persyaratan perangkat keras untuk beban pengguna yang direncanakan simulasi Anda. Banyak alat memerlukan banyak hardware kapasitas, terutama memori. Sebagai aturan praktis, rencana driver klien sebanding dengan setiap pertandingan sistem di bawah tes (SUT) di lingkungan Anda. Sebagai contoh, jika sekelompok tes Anda berisi dua empat arah mesin server aplikasi, berencana untuk memasukkan dua empat arah mesin uji kinerja klien Anda konfigurasi. Tentu saja, menggunakan ini sebagai aturan umum, namun mengkonfirmasi perkiraan ini dengan yang sebenarnya rekomendasi yang diterbitkan oleh vendor alat tes kinerja Anda. Juga, perlu diingat bahwa pedoman ini bervariasi tergantung pada kompleksitas tes, data kembali, tingkat kesalahan pemeriksaan yang dilakukan oleh alat tes, dan faktor lainnya. Tanyakan penyedia alat Anda untuk bantuan dengan rekomendasi hardware. Anehnya, tes sederhana dengan transaksi throughput yang tinggi sering membutuhkan klien lebih kapasitas perangkat keras dari yang lebih kompleks tes (tes menghasilkan pengolahan server yang lebih per permintaan). Sebuah beban kerja terutama statis konten menghasilkan suatu tingkat throughput yang lebih tinggi dari beban kerja yang kompleks, berorientasi transaksi, yang menempatkan lebih stres pada mesin tes klien. Misalnya, beban kerja yang sebagian besar didasarkan statis dapat menghasilkan 2.000 transaksi per detik, sementara, kompleks berorientasi transaksi beban kerja yang berjalan pada hardware yang sama mungkin hanya menghasilkan 100 transaksi per detik. Simulator klien yang sama bekerja keras menangani 2.000 transaksi per detik maka tidak dengan hanya 100. Untuk alasan ini, persyaratan hardware klien sering meningkat jika Anda menguji logika situs web kurang kompleks. Untuk Misalnya, jika Anda menguji situs e-Commerce dengan banyak caching elemen statis, Anda mungkin perlu klien lebih keras daripada ketika menguji situs B2B dengan beban pengguna yang sama simulasi. Permintaan cepat dan tingkat pengembalian data statis dari situs e-Commerce berdiri untuk mengalahkan mesin uji klien.

Juga, saat Anda berbelanja untuk alat kinerja, pertimbangkan platform hardware mendukung. Alat uji kinerja biasanya mengeksekusi terhadap situs web pada platform apapun, sama seperti browser berinteraksi dengan situs web digunakan pada beberapa platform perangkat keras. Sebagai contoh, jika situs web Anda menggunakan platform berbasis UNIX, Anda tidak perlu alat untuk membatasi kinerja Anda untuk platform ini juga. Kemungkinan besar, alat kinerja menjalankan Microsoft Windows sistem berbasis bekerja sama dengan baik sebagai salah satu yang berjalan pada platform UNIX untuk menguji Anda situs web. Driver beban banyak menggunakan tes dan sistem pengendali agen untuk mensimulasikan beban pengguna. Banyak vendor hanya mendukung berbasis Microsoft Windows pengontrol tes sementara mendukung simulator agen di berbagai platform, termasuk Microsoft dan sistem UNIX. Misalnya, Mercury LoadRunner membutuhkan Microsoft Platform Windows untuk kontroler mereka, tetapi controller mengelola agen tes berjalan pada Microsoft Windows atau varian UNIX beberapa. Jauhkan persyaratan platform penting dalam pikiran ketika Anda merencanakan hardware dan keterampilan yang dibutuhkan untuk tes beban Anda.

Script Seperti yang telah disebutkan sebelumnya, script pengujian Anda merupakan investasi yang signifikan. Bila Anda memilih alat tes, mempertimbangkan bagaimana alat mendukung pengembangan naskah, kustomisasi, dan pemeliharaan sebagai bagian dari pilihan Anda kriteria. Ingat, tidak ada standar ada untuk tes script, sehingga script tidak port antara kinerja yang berbeda alat uji. Setelah Anda membuat investasi dalam pencatatan dan menyesuaikan script tes, beralih alat tes menjadi sulit. Differentiators utama antara mendukung script alat 'termasuk Data Dinamis dukunganP Substitusi parameterc Web Dinamis Halaman parsingc Scripting bahasa (kurva belajar dan tingkat keterampilan yang diperlukan untuk digunakan)P Kemampuan untuk membangun skenario dari script individu dan untuk menentukan pembobotan merekaP Kemampuan untuk menggunakan kembali skrip dalam pemantauan produksiP

Dynamic Data Support Kembali ke salah satu dari 7 Bab diskusi kami, yang ditulis dengan baik script tes mensimulasikan seleksi pengguna khasproses. Script ini juga menggabungkan variasi yang cukup dan dinamis pemilihan data untuk mensimulasikan luasnya konsisten dengan volume interaksi pengguna yang besar. Skrip berulang (misalnya, script mengendarai tunggal, URL permintaan tidak berubah lagi dan lagi) sering kehilangan pada aspek yang paling penting kinerja pengujian. Sebagai contoh, beberapa pengguna membaca dan menulis catatan yang berbeda dari tabel yang sama kadang-kadang menyebabkan pertengkaran database. Script berulang tidak pernah menghasilkan tingkat pertentangan, sehingga mereka tidak pernah mengungkapkan ini masalah yang berpotensi serius selama tes. Juga, script realistis benar berbagai latihan cache seluruh sistem. Lihatlah kemampuan alat itu untuk menambahkan parameter berdasarkan nomor acak atau file input. Low-end skrip driver biasanya drive urutan yang sama URL berulang-ulang, tetapi sering kekurangan dukungan yang diperlukan untuk sangat dinamis, sesi HTTP didorong situs. Penanganan data dinamis menandai salah satu differentiators kunci antara low-end dan kinerja alat tes high-end. Sebuah alat gratis seperti Apache Bench, yang unggul di mengemudi urutan URL, mudah digunakan, dan memerlukan hardware minimal.Banyak "shareware" memuat driver menunjukkan karakteristik serupa. Namun, alat gratis dengan cepat kehilangan daya tarik mereka ketika serius pengujian aplikasi yang dinamis. Sebagai contoh, jika situs Anda mendukung login pengguna, mencari driver beban yang mensimulasikan ID pengguna yang berbeda. Jika Anda berencana untuk menggunakan driver low-end, mempertimbangkan untuk mengembangkan logika aplikasi kustom untuk pengguna dinamis yang lebih baik simulasi. IBM menggunakan pendekatan ini dengan Contoh Kinerja benchmark WebSphere (Trade2). IBM TradeScenarioServlet dikembangkan untuk front-end proses aplikasi yang sebenarnya. Skenario ini servlet benar-benar melakukan generasi pengguna acak dan dinamis menghasilkan campuran beban kerja. Pendekatan ini memerlukan sumber daya tambahan untuk mengembangkan pemrograman setara dengan servlet skenario, tetapi menyederhanakan persyaratan generasi alat beban. (Juga, pendekatan ini membutuhkan sumber daya server-side untuk mendorong tes

beban) Alat Generasi beban kebutuhan untuk menangani cookie., tetapi tidak perlu data dinamis yang canggih kemampuan penanganan. IBM mengambil pendekatan ini untuk dengan mudah berbagi benchmark dengan pelanggan yang menggunakan berbeda beban generator. Tentu saja, high-end kinerja alat dukungan data dinamis kemampuan penanganancanggih. para highend alat melakukan fungsi yang sama dengan servlet skenario dalam pengolahan sisi-klien mereka. Secara umum, kami merekomendasikan menemukan alat uji kinerja yang menangani persyaratan dinamisdata Anda sebagai lawan tulisan Anda sendiri. Mengembangkan tes script dengan alat uji kinerja terkemukabiasanya memerlukan kurang investasi sumber daya dalam jangka panjang dan memungkinkan Anda untuk lebih mudah mengelola dan mengubah skrip uji selama waktu. Sebagian besar alat-alat beban sopir high-end menyediakan kemampuan yang diperlukan untuk aplikasi web script seperti Pet Store atau Trade2. Namun, script biasanya membutuhkan kustomisasi dalam rangka untukmenguji dinamis memadai kemampuan. Selama proses seleksi Anda alat, kami merekomendasikan sebenarnya script prototipe dengan yang berbeda alat di bawah pertimbangan untuk menentukan apakah mereka mendukungkebutuhan Anda.

Parsing Halaman Web Dinamis Halaman web dinamis sering kali berbeda dalam konten dan panjang tergantungpada parameter permintaan. Sebagai contoh, hanya seperti Pet Store, banyak situs web termasuk fungsi pencarian. Fungsi pencarianmengembalikan dihasilkan secara dinamis Halaman (biasanya link web) berdasarkan nilai search yang diajukan oleh pengguna.Setiap pencari berpotensi menghasilkan halaman hasil yang berbeda dengan nomor yang berbeda dari linkhasil. Halaman-halaman ini seringkali memerlukan script disesuaikan untuk memproses dan memilih dari link dinamis kembali. Bahkan,dalam Bab 7 kita menunjukkan Anda dua contoh pengolahan link dinamis menggunakan kedua SilkPerformer danLoadRunner. Jika Anda membutuhkan pemrosesan link dinamis, mengkonfirmasi kinerja alat yang Anda sedang mempertimbangkan mendukung fitur ini. Dalam pengalaman kami, masingmasing vendor menyediakan berbagai kemampuan di daerah ini, dan sering mendukung melibatkan kompleks dan sangat terampil skrip pemrograman. Terlepas dari alat yang Andapilih, mengambil kelas atau menggunakan konsultasi sumber daya untuk membantu dalam pengembangan awal script menggunakan fungsi ini. (Bahkan, untuk menghasilkan script untuk contoh, kami menerima bantuan dari kedua Mercury Interaktif dan Segueuntuk mengeksploitasi canggih mereka fitur.)
Scripting Bahasa dan Keterampilan Selain script merekam, alat uji kinerja paling menawarkan dukungan skripkustomisasi. Namun, tingkat keterampilan yang diperlukan untuk mencapai kustomisasi bervariasi antaravendor alat. Beberapa dukungan alat aplikasi sederhana kustomisasi menggunakan alat itu GUI; scripting aplikasi yang lebih canggih sering membutuhkan pemrograman script khusus. Bahasa scripting yang digunakan olehalat-alat bervariasi dari kepemilikan bahasa scripting untuk JavaScript atau C. Seperti yang telah disebutkan sebelumnya, standar tes skrip tidak ada. Ini meninggalkan vendor perangkat gratis untuk memilih atau membangun setiap bahasa scripting untuk script mereka. Sebelum Anda membeli alat uji kinerja, memahami upaya dan keterampilan yang diperlukan untuk menciptakan dan mempertahankan skrip uji.

Bangunan dan Pembobotan Skenario Sebagaimana kita bahas pada Bab 7, selama runtime script tes Anda harus mewakili penggunaan produksi aktual pola situs web Anda. Untuk sebuah situs web eCommerce, campuran beban kerja biasanya terdiri dari jauh lebih browsing yang pengguna dari pengguna melakukan pembelian. Kami mencerminkan campuran ini beban kerja yang sama ketika kita menguji e- Commerce. Simulasi beban kerja yang berbeda campuran adalah penting, terutama untuk situs web yang lebih besar. Low-end alat biasanya melaksanakan beban kerja tunggal untuk semua pengguna.Kebanyakan high-end alat memungkinkan Anda untuk menetapkan skrip yang berbeda untuk pengguna yang berbeda. Misalnya, jika Anda menjalankan tes 1.000 pengguna, menggunakan alat ini untuk menentukan 300 dari pengguna untuk menjalankan skenario pencarian, 750 pengguna untuk menjalankan skenario menelusuri, dan 50 untuk menjalankan skenario pembelian. Gambar 8.3 memberikan contoh mendefinisikan uji coba tertimbang menggunakan SilkPerformer.

Figure 8.3. Example of SilkPerformer V workload configuration. 2002 Segue Software, Inc.

Banyak dari alat-alat tes juga memberikan kemampuan untuk membangun scriptyang lebih kompleks dari yang lebih kecil, script individu. Sebagai contoh, beberapa alat memungkinkan Anda untuk menentukan serangkaianscript untuk log on, melakukan acak (atau ditentukan) jumlah menelusuri, dan membeli pilihan acak item. Kemampuan untuk mengisolasifungsi menjadi terpisah script membuat lebih mudah untuk mengoptimalkan jalur kritis. Untuk situs e-Commerce, jalan membeli mungkin merupakan persentase kecil dari beban kerja secara keseluruhan, namun rencana uji biasanyamenentukan waktu respon agresif target untuk jalan ini. Mengisolasi jalur membeli untuk script kecil atom memberikanAnda kontrol lebih baik atas pelaksanaannya dalam campuran beban kerja secara keseluruhan, dan, tergantung pada alat,pemantauan ketat kinerjanya.

Script menggunakan kembali Uji Produksi Sering, script yang sama digunakan untuk menguji performa situs web Anda juga berguna untuk pemantauan dan tips situs produksi Anda. Secara berkala, Anda mungkin menjalankan skripPencarian terhadap produksi Anda situs di bawah beban yang terbatas untuk memeriksa kinerja produksi jalan pencari.Beberapa vendor alat tes sekarang menawarkan alat pemantauan produksi yang menggunakan script yang samadikembangkan untuk pengujian beban. Lihat Lampiran C untuk informasi lebih lanjut tentang penawaran pemantauan produksi.
Otomasi dan Kontrol Terpusat Pertimbangkan seberapa baik alat tes mengelola pelaksanaan uji dan pengumpulanhasil. Berapa banyak dari proses ini tidak alat otomatis, dan berapa banyak tidak membutuhkan Anda untuk melakukansecara manual? Differentiators kunci untuk kontrol otomatis dan pusat termasuk P Mengendalikan driver beberapa klien dari lokasi pusat atau mesin P Konsolidasi hasil dari beberapa klien ke dalam satu laporan P Command line atau kontrol jarak jauh tes Meskipun differentiators tidak benar-benar mempengaruhi hasil tes, mereka membuat perbedaan besar dalam upaya diperlukan untuk menjalankan tes Anda. Jika alat tes Anda membutuhkan banyakintervensi manual untuk melaksanakan dan mengumpulkan hasil, overhead petunjuk ditambahkan mengurangi jumlah tes Anda mengeksekusi setiap hari. Bekerja lebih Anda lakukan, lama waktu yang diperlukan untuk menyelesaikan tes kinerja. Kecil tes kinerja(didefinisikan oleh tes kecil lingkungan, script beberapa tes, dan pengguna simulasi beberapa) umumnya tidakmemerlukan tes yang sangat otomatis runtime manajemen.

Mengontrol Driver Beberapa Klien Jika Anda membutuhkan mesin pengujian beberapa klien untuk mensimulasikanbeban pengguna, pertimbangkan alat tes dengan dukungan untuk mengelola pengguna simulasi didistribusikan ke mesin ini. Gambar8.4 menunjukkan sebuah lingkungan pengujian menggunakan empat mesin klien untuk menghasilkan beban uji. Generator beban mengirim permintaan pada jaringan terisolasi untuk sistem yang diuji. Alat uji kinerja menyediakan kontroler pusat untuk mengelola klienempat mesin. Komunikasi antara controller dan generator beban melintasi jaringan yang terpisah dari lalu lintas tes kinerja yang sebenarnya, sehingga tidak mengganggu hasil tes.
Figure 8.4. Testing environment

Biasanya, controller memberikan satu set script tes untuk satu set pengguna virtual, mulai para pengguna virtual pada didistribusikan mesin klien, dan memantau pengguna sebagai tes dijalankan. Setelah tes selesai, kontroler mengkonsolidasikan data dari semua pengguna simulasi. Kontrol terpusat adalah umum di high-end driver beban; yang paling low-end alat tidak menyediakan fungsi ini. Jika salah satu cukup mesin uji untuk pengujian Anda dalam masa mendatang, fungsi ini bukan keharusan. Namun, situs web yang paling besar memerlukan beberapa uji klien dan controller tes untuk mengelola ujian mereka berjalan.

Menjalankan Tes melalui Command Line atau jarak jauh Beberapa organisasi menjalankan tes kinerja mereka dari lokasi terpencil. Seringkalites kinerja dijalankan dari laboratorium mil dari server tes yang sebenarnya. Juga, banyak organisasi menulis skrip pengujian kontrol otomatis menggunakan antarmuka baris perintah alat tes untuk mengendalikan tes berjalanjauh atau off-pergeseran. Jika Anda membutuhkan ini kemampuan, periksa dengan seksama dengan vendor alat kinerja. Banyak high-endalat uji dukungan jarak jauh

eksekusi tetapi tidak menyediakan antarmuka baris perintah. (Highend GUImenggunakan alat canggih untuk mendukung fungsi mereka. Fungsi-fungsi ini tidak mudah diterjemahkan ke dalam antarmukabaris perintah.) Sebaliknya, banyak low-end menyediakan akses alat baris perintah. Namun, pastikanalat yang menyediakan semua fungsi yang Anda butuhkan untuk mendukung tes. Harga dan Lisensi Harga untuk alat driver beban berkisar dari tanpa biaya (seperti untuk alat Apache) untuk ratusan ribu dolar. Anda mungkin dalam untuk shock dengan harga dituntut untuk high-end bebanalat generasi. Sebuah Juli 2001 [3] studi yang membandingkan harga untuk alat-alat dari Quest, RadView, Segue,Mercury Interaktif, Empirix, dan Compuware menemukan bahwa entry level harga untuk 50 atau 100 pengguna virtual adalah antara $ 7.500 dan $ 33.075, ditambah tambahan biaya untuk mensimulasikan lebih banyak pengguna. Differentiators kunci untuk harga dan perizinan termasuk P Perizinan biaya (biaya flat atau berdasarkan pengguna simulasi per) P Kelompok berbagi pengguna di seluruh mesin beberapa kontroler P jangka pendek klien lisensi P ada hubungan penjual