Sistem autotest E-commerce

Saya merasa seperti penemu sepeda. Dan dia sudah lama berpikir apakah pantas untuk menulis tentang apa yang menurutku sudah jelas. Tetapi sekali lagi saya menemukan fakta bahwa, dengan kegigihan yang layak untuk aplikasi yang lebih baik, mereka tidak melakukannya.

Jadi situasinya adalah: e-commerce di industri transportasi / pariwisata / perhotelan. Dirancang, dikembangkan, dan sekarang - proses bisnis ujung-ke-ujung, banyak sistem, semua seperti yang diharapkan dalam e-commerce besar.

gambar

Tapi di sini masalahnya:

  • Semua sistem besar terdiri dari beberapa sistem;
  • Masing-masing dikembangkan / diperbarui / didukung oleh pengembang terpisah;
  • Setiap pengembang memperbarui perangkat lunak rata-rata sebulan sekali dan secara independen mengontrol kualitas solusi mereka.

Dan siapa yang memberikan kualitas proses bisnis? Operator, sekali, dan kemudian yang lain, berteriak ketika membayar tagihan, dengan argumen: "agar sistem Anda bekerja, Anda tidak dapat menggunakannya."

Saya tidak merasa ingin menguji sekutu, tetapi saya ingin menyerah dan dibayar. Jadi kami mulai menulis sistem autotesting ujung ke ujung - pengujian bukan sistem, tetapi seluruh proses bisnis perdagangan elektronik (dengan partisipasi beberapa sistem, dari beberapa pemasok). Seperti sistem besar yang melewati end-to-end BP melihat ke semua sistem: dari konsol web, untuk membaca catatan dari database:

gambar

Dan inilah yang kami dapatkan:

Apa yang dapat dilakukan sistem:


1. Tes kompleks - memeriksa fungsionalitas semua e-commerce BP untuk:

  • Identifikasi kesalahan;
  • Pemeriksaan integrasi;
  • Penyimpangan parsing;

gambar

gambar

  • Pemeriksaan logika;
  • Verifikasi jumlah;

gambar

  • Analisis PNR dalam GDS;
  • Analisis catatan add. layanan dalam database;
  • Memeriksa tampilan elemen dalam bentuk layar.

gambar

2.

Memproses pelaporan screenshot:

  • Pengidentifikasi pesanan / status / langkah dalam nama file;
  • Mengelompokkan tangkapan layar dalam penyimpanan file berdasarkan bagian uji.

gambar

Set Laporan:

  • Laporan ringkasan tentang penyimpangan - dengan tautan ke langkah-langkah panduan, transkrip (format Excel)
  • Laporan ringkasan tentang penyimpangan non-kritis - decoding dan tautan ke deskripsi langkah-demi-langkah (format - Excel)
  • Laporan β€œCantik” untuk pelaporan, dengan penelusuran dan penyimpangan yang benar (format - Excel)

3. Tes beban - pengulangan massal jenis uji yang sama, dengan tujuan:

  • identifikasi kesalahan berkala;
  • simulasi beban.

gambar

4. Multithreading - uji kasus dilakukan dalam 3 utas, yang sangat penting karena fakta bahwa lebih disukai untuk menggunakan platform Windows sebagai server untuk pengujian.

Efek ekonomis


Volume uji:

  • 2 pasangan mata uang / bahasa. 4 izin. 4 browser. 8 situasi bisnis;
  • 12 * 4 * 4 * 8 = 1.536 kasus uji;
  • Bagian rata-rata dari test case oleh robot adalah 5 menit, reproduksi oleh seseorang (dengan banyak pengalaman) - 7-10 menit;
  • Biaya tenaga kerja untuk pengujian 1152 * 7 * 1.2 (tingkat gangguan pada lingkungan pengujian) = 12 902,4 menit / 215,04 jam untuk rilis;
  • Dalam sebulan ada 3 rilis pembaruan dari 3 pemasok = 645,12 jam kerja. Mengingat biaya pelaporan dan ketimpangan pengujian, 4, dan kemungkinan besar, 5 karyawan tetap;
  • Gaji seorang spesialis adalah 80.000 + pengurangan untuk PFR - 30%, untuk FSS - 2,9%, ke FFOMS - 5,1%.

Tabungan dengan autotest - 5-6 juta β‚½ per tahun (hanya gaji)

Teknologi


Pada prinsipnya, tidak ada yang istimewa, tetapi ini adalah sumber daya teknis ...

  • Java, kerangka kerja TestNG.
  • Selenium - satu set perpustakaan untuk mengelola browser web;
  • Selenide - metode untuk bekerja dengan objek web;
  • SoapUI - sarana untuk berinteraksi dengan berbagai protokol;
  • Selenium Grid - alat yang memungkinkan Anda untuk membangun cluster dan mendistribusikan tugas di berbagai server;
  • Jenkins adalah alat untuk mengelola pelaksanaan kasus uji dan bekerja dengan hasil tes.

All Articles