全部产品
Search
文档中心

Performance Testing:Panduan teknis untuk pengujian kinerja

更新时间:Jul 02, 2025

Topik ini menguraikan persyaratan teknis utama untuk pelaksanaan pengujian kinerja. Persyaratan ini membantu pengguna Layanan Pengujian Kinerja (PTS) mencegah risiko teknis setelah sistem online, mengevaluasi kemampuan nyata dari sistem online, dan menguji kemampuan berdasarkan model bisnis untuk menangani risiko potensial terlebih dahulu.

Ruang lingkup aplikasi

Persyaratan teknis berlaku untuk semua proyek yang memerlukan pengujian kinerja. Persyaratan ini menganalisis teknologi penting dan kunci untuk pelaksanaan pengujian kinerja, termasuk lingkungan sistem, metrik pengujian, model bisnis, volume data, model pengujian, jenis pengujian, skrip (API), skenario, pemantauan, analisis hambatan, penyetelan, serta alat pengujian stres berbasis cloud terdistribusi yang digunakan dalam pengujian kinerja.

Lingkungan sistem

  1. Analisis

    Lingkungan sistem diklasifikasikan menjadi lingkungan produksi, lingkungan pengujian, dan lingkungan lainnya. Lingkungan produksi memberikan pengukuran yang lebih akurat dan referensi yang lebih dioptimalkan, namun Anda diharuskan membersihkan data uji penuh yang relevan atau menyaring data uji saat mengumpulkan statistik pada data Business Intelligence (BI). Solusi yang lebih efisien adalah pengujian stres sesi penuh yang disediakan oleh Alibaba Cloud. Untuk menghindari dampak negatif pada layanan produksi, kami sarankan melakukan pengujian stres di lingkungan produksi selama jam-jam sepi. Anda dapat mengendalikan risiko lingkungan pengujian, namun kesulitan membangun lingkungan pengujian dan biaya tinggi untuk mencapai skala yang sama dengan lingkungan produksi sering kali menjadi tantangan. Oleh karena itu, solusi umum adalah membangun lingkungan pengujian berdasarkan rasio seperti setengah, seperempat, atau seperdelapan dari lingkungan produksi, secara terpisah menerapkan kluster pengujian di beberapa aplikasi dalam lingkungan produksi, atau berbagi database. Selain itu, lingkungan pengujian perlu mengimpor data dasar yang disembunyikan dari lingkungan produksi, seperti data yang dihasilkan dalam enam atau dua belas bulan terakhir, untuk menjaga relevansi datanya. Hal ini penting untuk akurasi dan referensi pengujian stres yang dilakukan di lingkungan pengujian.

  2. Risiko

    Risiko lingkungan pengujian terutama terletak pada perbedaan dengan lingkungan produksi yang sesuai dengan lingkungan pengujian. Oleh karena itu, nilai referensi data uji di lingkungan pengujian terganggu. Anda dapat memilih metode yang tepat yang memenuhi kebutuhan Anda. Misalnya, jika Anda lebih memperhatikan verifikasi jaringan entri, Anda dapat berbagi entri antara lingkungan pengujian dan lingkungan produksi. Jika Anda tidak terbiasa dengan platform sistem operasi, middleware, dan database lingkungan pengujian, Anda tidak dapat dengan mudah menganalisis dan menyetel hambatan.

  3. Persyaratan

    1. Membangun Lingkungan Pengujian

      Setelah Anda memahami masalah di atas, Anda harus memenuhi persyaratan berikut untuk membangun lingkungan pengujian:

      • Pastikan arsitektur lingkungan pengujian sama dengan lingkungan produksi yang sesuai dengan lingkungan pengujian.

      • Pastikan model lingkungan pengujian sama dengan lingkungan produksi. Pastikan sumber daya berbasis cloud adalah instance Elastic Compute Service (ECS) atau kontainer dengan spesifikasi yang sama.

      • Pastikan versi perangkat lunak lingkungan pengujian sama dengan lingkungan produksi. Versi tersebut mencakup versi sistem operasi, versi middleware, versi database, dan versi aplikasi.

      • Pastikan parameter lingkungan pengujian sama dengan lingkungan produksi. Parameter tersebut mencakup parameter sistem operasi, parameter middleware, parameter database, dan parameter aplikasi.

      • Pastikan volume data dasar lingkungan pengujian berada dalam urutan besaran yang sama dengan lingkungan produksi.

      • Kurangi jumlah generator beban di lingkungan pengujian dan turunkan proporsional sumber daya lainnya di lingkungan pengujian.

      • Catat bahwa konfigurasi ideal lingkungan pengujian adalah setengah atau seperempat dari lingkungan produksi.

    2. Menyelidiki Lingkungan Pengujian

      Anda harus menyelidiki lapisan-lapisan berikut dari lingkungan pengujian:

      • Arsitektur sistem: Anda dapat menyelidiki komposisi sistem, fungsi lapisan, dan perbedaan dengan lingkungan produksi yang sesuai dengan lingkungan pengujian. Hasil-hasil ini terutama digunakan untuk analisis hambatan dan evaluasi kinerja lingkungan produksi.

      • Platform sistem operasi: Anda dapat menyelidiki platform sistem operasi untuk melakukan pemantauan alat.

      • Middleware: Anda dapat menyelidiki middleware di lingkungan pengujian untuk melakukan pemantauan alat dan lokasi hambatan.

      • Database: Anda dapat menyelidiki database di lingkungan pengujian untuk melakukan pemantauan alat dan lokasi hambatan.

      • Aplikasi: Anda dapat menyelidiki instans dan parameter yang dimulai di lingkungan pengujian untuk melakukan pencarian masalah dan lokasi hambatan.

      Anda dapat menggunakan Manajemen Kinerja Aplikasi (APM), seperti Application Real-Time Monitoring Service (ARMS), untuk menemukan masalah yang terjadi di lapisan middleware, database, atau aplikasi.

Metrik pengujian

  1. Analisis

    Metrik pengujian diklasifikasikan menjadi metrik bisnis, metrik sumber daya, metrik aplikasi, dan metrik frontend.

    • Metrik bisnis: mencakup jumlah pengguna konkuren, transaksi per detik (TPS), tingkat keberhasilan, dan waktu respons (RT).

    • Metrik sumber daya: mencakup utilisasi CPU, utilisasi memori, I/O, dan parameter kernel yang mencakup semaphore dan jumlah file terbuka.

    • Metrik aplikasi: mencakup jumlah thread idle, jumlah koneksi database, jumlah GC atau full heap GC, dan durasi fungsi.

    • Metrik frontend: mencakup waktu pemuatan halaman dan waktu jaringan yang mencakup durasi resolusi Domain Name Service (DNS), waktu koneksi, dan waktu transfer.

  2. Risiko

    Pengguna yang berbeda memerlukan berbagai jenis metrik dan memiliki harapan yang berbeda. Anda harus menyelidiki metrik dan menentukan ambang batas spesifik metrik untuk personel yang berbeda dengan peran yang berbeda terlebih dahulu untuk menguji kinerja sistem yang dapat dicapai di bawah ambang batas tersebut, menemukan hambatan, dan menyetel kinerja. Jika Anda tidak memperhatikan metrik pengujian terlebih dahulu, Anda mungkin mendapatkan hasil pengujian yang tidak valid yang tidak diperlukan oleh personel yang relevan.

  3. Persyaratan

    1. Metrik Bisnis

      • RT: Metrik ini umum untuk semua personel yang relevan. Departemen bisnis memiliki kebutuhan yang lebih tinggi untuk nilai spesifik dari metrik ini. Dalam kebanyakan kasus, nilai harapan RT bisnis bervariasi berdasarkan layanan sistem. Kami sarankan Anda menetapkan metrik ini pada nilai yang berada dalam 1 detik. Sebagai contoh, RT layanan sistem Taobao pada dasarnya berada dalam puluhan milidetik.

      • TPS: Metrik ini menunjukkan jumlah transaksi yang diproses oleh sistem per detik. Metrik ini adalah kunci untuk mengukur kemampuan pemrosesan sistem. Anda dapat merujuk pada TPS di sistem identitas yang sama dan bisnis Anda ketika Anda menentukan TPS untuk layanan Anda. TPS adalah 50 hingga 1.000 untuk usaha kecil dan menengah, 1.000 hingga 50.000 untuk bank, dan 30.000 hingga 300.000 untuk Taobao.

      • Tingkat Keberhasilan: Metrik ini mengukur tingkat keberhasilan permintaan di bawah beban kerja sistem yang tinggi. Dalam kebanyakan kasus, tingkat keberhasilan industri melebihi 99,6%.

    2. Metrik Sumber Daya

      Dalam kebanyakan kasus, metrik sumber daya sistem tidak boleh melebihi nilai hambatan. Sebagai contoh, Anda harus membatasi utilisasi CPU hingga 75% atau mencegah sistem Anda menggunakan partisi swap. Secara ideal, ketika kemampuan sistem tidak meningkat, sumber daya menjadi hambatan yang tidak disebabkan oleh hambatan lain dalam kebanyakan kasus. Dalam kasus ini, jika sumber daya ditambahkan, kemampuan sistem juga meningkat. Namun, kemampuan sistem tidak meningkat ketika banyak sumber daya pengujian kinerja sistem tidak mencapai hambatan dalam kebanyakan kasus.

Model bisnis

  1. Analisis

    Sistem memiliki banyak bisnis. Setiap logika bisnis dan volume bisnis tidak sama, dan jumlah sumber daya sistem yang dikonsumsi oleh setiap bisnis tidak sama. Oleh karena itu, jenis bisnis dan proporsi bisnis menentukan kemampuan pemrosesan sistem. Model bisnis memainkan peran kunci dalam pengujian kinerja. Sebagai contoh, dalam skenario e-commerce, bentuk promosi yang berbeda dan kategori utama menentukan rasio keseluruhan dari sumber daya yang berbeda. Oleh karena itu, lalu lintas akurat yang mendarat di PTS untuk pengujian stres dan mendapatkan hambatan sistem dapat sepenuhnya memanfaatkan sumber daya mesin untuk mencapai tujuan bisnis.

  2. Risiko

    Jika jenis bisnis dan proporsi bisnis yang tidak tepat dipilih untuk model bisnis dan memiliki perbedaan besar dengan lingkungan produksi, hasil pengujian tidak memiliki nilai referensi. Selain itu, Anda dapat salah memahami kemampuan sistem. Meskipun proporsi volume bisnis beberapa bisnis sangat rendah dalam sistem, mutasi adalah fatal bagi sistem. Oleh karena itu, Anda harus fokus pada bisnis dalam pengujian kinerja.

  3. Persyaratan

    Dalam kebanyakan kasus, Anda harus memilih bisnis dengan volume tinggi dan berisiko yang menyediakan frekuensi penggunaan tinggi dan memiliki potensi pertumbuhan di masa depan sebagai bisnis tipikal sistem Anda. Anda dapat mengevaluasi sistem yang telah diluncurkan berdasarkan volume bisnis historis dan kinerja lingkungan produksi selama jam-jam puncak. Untuk sistem yang akan segera diluncurkan, Anda dapat mengevaluasi sistem berdasarkan hasil investigasi dan konsumsi sumber daya dalam transaksi.

    1. Sistem Online

      • Kumpulkan jenis bisnis dan volume bisnis periode puncak yang berbeda dalam lingkungan produksi, dan tentukan apakah jenis bisnis dan volume bisnis setiap periode waktu sangat berbeda. Jika ada perbedaan besar, beberapa model bisnis harus digunakan. Jika ada perbedaan kecil, hanya satu model bisnis yang bisa digunakan.

      • Kumpulkan titik waktu di mana konsumsi sumber daya tinggi dan pengecualian sumber daya terjadi selama jam-jam puncak dalam lingkungan produksi, dan tangkap alasan konsumsi sumber daya tinggi dan pengecualian sumber daya.

      • Kumpulkan masalah produksi dan analisis mereka. Jika masalah disebabkan oleh bisnis dan bisnis tersebut diabaikan dalam pengujian kinerja sebelumnya, bisnis tersebut berisiko signifikan dan perlu ditambahkan ke model bisnis dalam pengujian kinerja berikutnya.

    2. Sistem Offline

      • Tentukan jenis bisnis dan proporsi bisnis dengan melakukan investigasi.

      • Tentukan apakah beberapa bisnis memiliki kemungkinan mutasi dalam promosi dan aktivitas lainnya dengan melakukan investigasi.

      • Tentukan konsumsi sumber daya setiap bisnis berdasarkan hasil pengujian. Jika beberapa bisnis yang memiliki proporsi rendah mengkonsumsi sejumlah besar sumber daya, Anda harus menyesuaikan proporsi bisnis tersebut.

Volume data

  1. Analisis

    Volume data terutama mencakup volume data dasar (volume data historis, volume data dasar, atau volume data yang ada di database) dan volume data parametrik. Volume data memainkan peran yang sangat penting dalam pengujian kinerja. Hasil kueri untuk beberapa entri sangat berbeda dengan kueri untuk jutaan entri. Seiring dengan meningkatnya volume bisnis, entri juga bertambah. Oleh karena itu, Anda harus menjaga urutan besaran volume data yang sama dengan lingkungan produksi yang sesuai dengan lingkungan pengujian kinerja ketika Anda menggunakan lingkungan pengujian. Jika Anda menyisipkan akun pengujian di lingkungan produksi, Anda dapat memastikan keotentikan lingkungan dan menjaga urutan besaran volume data dasar sampai batas tertentu. Pengujian stres sesi penuh yang disediakan oleh Alibaba Cloud juga memerlukan urutan besaran volume data dasar yang sama antara lingkungan pengujian dan produksi. Selain itu, kita juga perlu mempertimbangkan volume data parametrik dan distribusi data selama pengujian.

  2. Risiko

    Jika volume data dasar lingkungan pengujian tidak berada dalam urutan besaran yang sama dengan lingkungan produksi yang sesuai dengan lingkungan pengujian, nilai metrik yang relevan tidak benar. Sebagai contoh, waktu respons jauh lebih cepat daripada di lingkungan produksi, dan bahkan hasil pengujian tidak memiliki nilai referensi. Jika volume data parametrik terlalu kecil dan distribusi data tidak dipertimbangkan, hasil pengujian tidak benar dan tidak bermakna. Jika Anda ingin menyisipkan akun pengujian ke lingkungan produksi, Anda harus mempertimbangkan integritas persiapan data dan logika pembersihan. Pengujian stres sesi penuh yang disediakan oleh Alibaba Cloud memerlukan biaya transformasi yang besar dan melibatkan iterasi dan pemeliharaan berkelanjutan.

  3. Persyaratan

    1. Volume Data Dasar

      Volume data dasar lingkungan pengujian perlu berada dalam urutan besaran yang sama dengan lingkungan produksi yang sesuai dengan lingkungan pengujian. Dalam kebanyakan kasus, Anda harus mempertimbangkan tren pertumbuhan volume data dalam tiga tahun ke depan. Jika volume data meningkat dengan cepat, Anda harus membangun lebih banyak data di lingkungan pengujian.

    2. Volume Data Parametrik

      • Maksimalkan volume data parametrik. Jika perlu, Anda dapat membersihkan cache atau menyediakan volume data parametrik dengan menulis kode.

      • Distribusikan data parametrik dengan tepat. Jika sebuah bisnis memiliki karakteristik distribusi geografis yang jelas, Anda harus mempertimbangkan distribusi data.

Model pengujian

  1. Analisis

    Model pengujian berevolusi dari model bisnis. Dalam kebanyakan kasus, model pengujian dan model bisnis sama. Namun, karena kegagalan untuk mensimulasikan bisnis atau alasan keamanan, bisnis perlu dihapus dan proporsi bisnis perlu dihitung ulang.

  2. Risiko

    • Merujuk pada risiko model bisnis yang disebutkan sebelumnya.

    • Jika bisnis yang dihapus berisiko, Anda harus mengevaluasi risiko bisnis tersebut. Jika risikonya tinggi, Anda harus mengadopsi solusi lain.

  3. Persyaratan

    Merujuk pada persyaratan model bisnis yang disebutkan sebelumnya.

Jenis pengujian

  1. Analisis

    Jenis pengujian terutama diklasifikasikan menjadi pengujian beban dan pengujian stres. Jenis pengujian mencakup pengujian benchmark transaksi tunggal, pengujian beban, pengujian stres, pengujian beban transaksi campuran (pengujian kapasitas), pengujian mutasi bisnis, pengujian stabilitas transaksi campuran, pengujian keandalan transaksi campuran, pengujian batch, dan pengujian untuk dampak pengujian batch terhadap transaksi campuran. Setiap jenis pengujian melayani tujuan yang berbeda. Anda dapat memilih jenis pengujian yang tepat berdasarkan realitas sistem produksi Anda.

  2. Risiko

    Jika jenis pengujian hilang, beberapa skenario sistem produksi nyata tidak terdeteksi, yang menyebabkan risiko, seperti crash sistem dan RT lambat.

  3. Persyaratan

    Jika Anda memiliki waktu yang cukup, kami sarankan Anda menguji sebagian besar jenis pengujian. Anda juga dapat merujuk pada persyaratan berikut:

    • Pengujian benchmark transaksi tunggal: opsional.

    • Pengujian beban transaksi tunggal: opsional. Jika sistem offline, kami sarankan Anda melakukan pengujian beban untuk sistem untuk melihat konsumsi sumber daya.

    • Pengujian beban transaksi campuran (pengujian kapasitas): wajib.

    • Pengujian stres transaksi campuran: opsional.

    • Pengujian mutasi bisnis: opsional.

    • Pengujian stabilitas transaksi campuran: wajib.

    • Pengujian keandalan transaksi campuran: opsional.

    • Pengujian batch: opsional.

    • Pengujian untuk dampak pengujian batch terhadap transaksi campuran: opsional.

Sesi bisnis

  1. Analisis

    Sesi bisnis adalah himpunan berurutan yang terdiri dari API pengujian stres dengan makna bisnis. Sesiini mirip dengan transaksi. Sesi bisnis digunakan untuk mensimulasikan operasi bisnis yang Anda lakukan. Koreksi simulasi langsung memengaruhi kinerja sistem Anda. Saat mensimulasikan operasi bisnis, data yang diparameterisasi diperlukan. Untuk informasi lebih lanjut tentang distribusi dan volume data yang diparameterisasi, lihat Volume Data.

  2. Risiko

    Jika bisnis tidak berhasil atau logika bisnis sangat berbeda dari lingkungan produksi nyata, hasil pengujian tidak memiliki nilai referensi.

  3. Persyaratan

    • Orkestrasi sesi bisnis berdasarkan aturan bisnis di lingkungan produksi.

    • Verifikasi nilai balik server Anda di titik-titik kunci dan tambahkan checkpoint (assertion) ke API pengujian stres (permintaan pada klien yang dipicu oleh perilaku pengguna). Untuk informasi lebih lanjut, lihat Parameter Respons Antarmuka.

    • Parameterisasi data dan maksimalkan volume data sebanyak mungkin.

Skenario

  1. Analisis

    (Pengujian stres) skenario adalah kombinasi dari beberapa Uniform Resource Locator (URL) berbasis HTTP atau HTTPS atau API. Skenario digunakan untuk mensimulasikan skenario bisnis dalam lingkungan produksi nyata, termasuk mode tekanan, metode peningkatan tekanan, dan waktu berjalan. Skenario simulasi perlu konsisten dengan skenario dalam lingkungan produksi. Terutama dalam periode waktu tertentu, proporsi TPS yang diuji dari setiap bisnis perlu konsisten dengan proporsi bisnis selama jam-jam puncak dalam lingkungan produksi.

  2. Risiko

    Risiko skenario adalah bahwa proporsi TPS yang diuji dari bisnis tidak konsisten dengan proporsi bisnis dalam lingkungan produksi. Jika proporsi bisnis menyimpang serius dari proporsi TPS yang diuji, hasil pengujian tidak benar atau tidak valid dan tidak dapat mencerminkan skenario bisnis dalam lingkungan produksi.

  3. Persyaratan

    Proporsi TPS setiap bisnis dalam hasil pengujian harus konsisten dengan proporsi bisnis dari model bisnis dalam lingkungan produksi. Anda dapat menggunakan mode Requests Per Second (RPS) eksklusif PTS yang dapat menguji throughput untuk memastikan konsistensi. Sebagai contoh, jika antarmuka A dan B memiliki rasio 1:4 dan RT masing-masing 1 ms dan 100 ms, Anda hanya perlu menetapkan RPS untuk kedua antarmuka pada rasio 1:4 dalam pengujian stres dengan menggunakan PTS. Jika mode konkurensi tradisional digunakan, konkurensi kedua antarmuka perlu dikonversi untuk memastikan bahwa rasionya adalah 1:400. Dengan cara ini, model bisnis akhirnya konsisten dengan lingkungan produksi.

Pemantauan

  1. Analisis

    Pemantauan dirancang untuk melakukan analisis pengujian kinerja, memantau sistem secara komprehensif, dan menemukan hambatan dengan cara yang lebih efisien. Dalam kebanyakan kasus, sistem operasi, middleware, database, dan aplikasi perlu dipantau. Pastikan bahwa metrik yang dikonfigurasikan untuk setiap jenis pemantauan lebih komprehensif.

  2. Risiko

    Kurangnya pemantauan sistem yang komprehensif menyebabkan kegagalan untuk melakukan analisis kinerja, menemukan hambatan sistem, dan mengidentifikasi item penyetelan.

  3. Persyaratan

    • Fokus pada metrik berikut: Metrik spesifik sistem operasi: Utilisasi CPU yang dapat tercermin oleh metrik User, Sys, Wait, atau Idle, utilisasi memori (termasuk utilisasi partisi swap), disk I/O, jaringan I/O, dan parameter kernel.

    • Metrik spesifik middleware: pool thread, pool koneksi Java Database Connectivity (JDBC), dan JVM (termasuk ukuran GC, ukuran full heap GC, atau ukuran heap).

    • Metrik spesifik database: Pernyataan SQL yang tidak efisien, kunci, cache, sesi, dan jumlah proses.

    • Metrik spesifik aplikasi: durasi metode, sinkronisasi dan asinkronisasi, buffering, dan cache.

Analisis hambatan

  1. Analisis

    Penemuan hambatan dirancang untuk menganalisis titik hambatan dalam sistem dan mempersiapkan penyetelan. Titik hambatan kinerja sistem terutama didistribusikan di sumber daya sistem operasi, pengaturan parameter middleware, masalah database, dan algoritma aplikasi. Penyetelan yang ditargetkan berkontribusi pada peningkatan kinerja sistem.

  2. Risiko

    Jika titik hambatan sistem tidak dapat dianalisis, bisnis baru online atau bisnis inti berisiko, yang dapat menyebabkan pengalaman kinerja sistem yang buruk atau bahkan crash sistem selama jam-jam puncak.

  3. Persyaratan

    Fokus pada metrik berikut untuk analisis titik hambatan sistem:

    • Metrik konsumsi sumber daya sistem operasi: CPU, memori, disk I/O, dan jaringan I/O.

    • Metrik middleware: pool thread, pool koneksi JDBC, dan JVM (termasuk ukuran GC, ukuran full heap GC, atau ukuran heap).

    • Metrik database: Pernyataan SQL yang tidak efisien, tunggu kunci, deadlock, rasio hit cache, sesi, dan proses.

    • Aplikasi: durasi metode, algoritma, sinkronisasi dan asinkronisasi, cache, dan buffering.

    • Generator beban: konsumsi sumber daya generator beban. Dalam kebanyakan kasus, generator beban memiliki kemungkinan rendah menjadi titik hambatan. Generator beban yang digunakan dalam PTS memiliki mekanisme perlindungan dan penjadwalan tanpa perlu perhatian terpisah.

Penyetelan

  1. Analisis

    Penyetelan dirancang untuk meningkatkan kinerja sistem. Penyetelan dapat menganalisis titik hambatan sistem dan memverifikasi peningkatan kinerja sistem melalui pengujian.

  2. Risiko

    Setelah sistem yang tidak disetel online, pengalaman pengguna mungkin buruk, dan bahkan sistem mungkin crash.

  3. Persyaratan

    Penyetelan sistem mengikuti aturan berikut:

    • Penyetelan middleware: pool thread, pool koneksi database, JVM.

    • Penyetelan database: Pernyataan SQL yang tidak efisien, deadlock dan tunggu kunci, rasio hit cache, proses, dan parameter sesi.

    • Penyetelan aplikasi: durasi metode, algoritma, sinkronisasi dan asinkronisasi, cache, dan buffering.

    • Sumber daya sistem: Dalam kebanyakan kasus, konsumsi tinggi sumber daya sistem, seperti CPU, disebabkan oleh pengaturan aplikasi dan parameter yang tidak tepat bukan karena sumber daya yang tidak mencukupi.

Alat pengujian stres berbasis cloud terdistribusi yang digunakan dalam pengujian kinerja

  1. Ikhtisar

    PTS adalah platform pengujian kinerja berbasis Web sebagai layanan (SaaS) yang kuat dengan kemampuan pengujian stres terdistribusi yang kuat dan dapat mensimulasikan skenario bisnis nyata dari pengguna massal.

    PTS dapat mensimulasikan akses dari node Content Delivery Network (CDN) yang ditempatkan di ratusan kota dan berbagai operator di seluruh dunia. Dibandingkan dengan host cloud produk industri, PTS dengan cepat memulai pengujian stres di lebih banyak wilayah dan memberikan kemampuan regulasi denyut nadi dan trafik yang lebih kuat. PTS lebih memperhatikan orkestrasi halaman visual, memungkinkan pengujian stres interaktif kompleks tanpa coding, mendukung mode pengujian stres RPS, dan memberikan kemampuan untuk langsung berlaku setelah regulasi.

    PTS dirancang untuk terus menyederhanakan pekerjaan pengujian stres kinerja sehingga Anda dapat fokus lebih banyak pada bisnis dan masalah kinerja Anda. PTS dapat digunakan untuk membangun trafik interaktif kompleks yang paling dekat dengan skenario bisnis nyata dengan biaya tenaga kerja dan sumber daya rendah, dengan cepat mengukur status kinerja bisnis sistem Anda, dan memfasilitasi pelaksanaan lokasi masalah kinerja, penyelesaian pengaturan rasio kapasitas, konstruksi trafik pengujian stres sesi penuh, yang dapat lebih meningkatkan pengalaman pengguna, mendorong perkembangan bisnis, dan memaksimalkan nilai bisnis perusahaan Anda.

  2. Fitur

    1. Konstruksi Skenario Pengujian Stres

      PTS mendukung API yang menjalankan pengujian stres secara berurutan atau mengorkestrasi pengujian stres secara paralel, memungkinkan kombinasi yang diparameterisasi yang mencakup file data, fungsi sistem, string, dan parameter respons, menyediakan kompatibilitas tinggi dengan cookie, dan memberikan berbagai skenario ekstensi instruksi. Fitur debugging yang disediakan oleh PTS memungkinkan Anda dengan mudah memverifikasi aliran data dalam skenario kompleks.

    2. Regulasi Trafik Pengujian Stres

      PTS mendukung mode konkurensi dan RPS untuk dengan cepat memulai pengujian stres dalam hitungan menit. PTS mengurangi deviasi, mendukung mode otomatis dan manual murni, membuat penyesuaian trafik pengujian stres berlaku dalam hitungan detik, dan mengimplementasikan denyut nadi instan dari jutaan trafik, yang memastikan bahwa trafik pengujian stres berhenti tepat waktu.

    3. Pemantauan dan Laporan Pengujian Stres

      Data pengujian stres mencakup konkurensi, TPS, RT, dan log yang diambil sampel dari setiap API.

  3. Manfaat

    1. Stabilitas dan Keandalan

      • PTS menyediakan stabilitas teknis yang tinggi.

      • PTS cocok untuk berbagai industri, termasuk e-commerce, multimedia, keuangan dan asuransi, logistik ekspres, periklanan dan pemasaran, serta jejaring sosial.

    2. Fitur yang Kuat

      • PTS sepenuhnya berbentuk SaaS tanpa instalasi dan penyebaran tambahan.

      • PTS mencakup plug-in rekaman dari browser utama.

      • PTS berfungsi sebagai pabrik data yang memformat parameter permintaan API dan URL yang digunakan dalam pengujian stres melalui pengkodean sederhana.

      • PTS mengorkestrasi skenario kompleks dengan cara visualisasi penuh, mendukung berbagi status login, pengiriman parameter, dan asersi bisnis, serta menyediakan fitur instruksi yang dapat diperluas yang mendukung waktu berpikir multi-form dan regulasi trafik.

      • PTS mendukung berbagai mode pengujian stres, seperti RPS dan konkurensi.

      • PTS memungkinkan Anda menyesuaikan trafik secara dinamis dalam hitungan detik dan langsung memulai jutaan queries per second (QPS).

      • PTS menyediakan fitur pelaporan yang kuat yang menampilkan dan menghitung data real-time klien pengujian stres dalam berbagai dimensi, serta secara otomatis menghasilkan laporan untuk referensi setelah kejadian.

      • PTS memungkinkan Anda men-debug API dan skenario pengujian stres serta menanyakan log proses pengujian stres.

    3. Trafik Nyata

      • Trafik berasal dari ratusan kota di seluruh dunia dan mencakup semua operator. PTS benar-benar mensimulasikan sumber trafik pengguna akhir. Oleh karena itu, laporan dan data yang sesuai lebih dekat dengan pengalaman pengguna nyata.

      • PTS memberikan kemampuan stres yang kuat dan mendukung trafik pengujian stres dengan RPS tinggi.