Selamat siang, para pembaca yang budiman.
Saya ingin berbicara tentang pengalaman membangun sistem otomasi pengujian ketika tidak ada pengujian sama sekali pada proyek, atau tingkatannya minimal.
Saya harap artikel ini akan bermanfaat bagi autotests pemula.
- Pada bagian pertama, kami mendukung pendekatan umum.
- Pada bagian kedua ( Bagian 1 ) dengan contoh-contoh kami akan membuat proyek autotest pada JAVA + mengajarkan cara cepat menguji API.
- Pada bagian ketiga, kami akan melengkapi proyek untuk pengujian UI, kami akan melakukan tes paralel.
Kapan melakukan autotest?
Jawaban singkatnya adalah sedini mungkin.
Lengkap akan terungkap di bawah ini. Bagaimanapun, ketika proyek bekerja selama 3 tahun, dan semuanya diperiksa secara manual, hidup menjadi sangat monoton. Dan armada 5000 skenario untuk diotomatisasi dalam satu atau dua bulan bermasalah. Sebagai aturan, dalam proyek seperti itu Anda harus mulai mengerjakan skrip lagi. Karena itu akan lebih cepat. Dan bukan fakta bahwa yang lama akan dapat diotomatisasi tanpa perubahan signifikan.
Mengapa
Karena autotets:
- Akumulasi skenario untuk regresi
- Tidak berkualitas
- Cepat
Skenario Akumulasi
Semakin besar armada skenario otomatis, semakin besar kemungkinan untuk menemukan regresi, terutama jika data berubah setiap kali dijalankan.
Jika uji otomatis lulus secara stabil dan jatuh pada beberapa cabang, maka mereka mengubah persyaratan, atau bug, atau infrastruktur gagal.
Ketidakberpihakan
Jika persyaratan diubah, autotest harus menuju perubahan bersama dengan perubahan fungsi utama. Itu sebabnya penguji mengambil bagian dalam persetujuan TK.
Jika tes berjalan secara otomatis menghubungkan ke suatu tugas, maka tidak ada yang bisa mengatakan bahwa itu belum diuji. Atau sebaliknya, dia bisa. Secara umum, pasti ada lebih sedikit masalah.
Kecepatan
Jika setiap tes memenuhi kondisi yang membosankan:
Prasyarat - Tes - Postkondisi
Tes semacam itu mudah diotomatisasi.
Dan kemudian mudah untuk diparalelkan. Karena mereka mandiri.
Jumlah utas - berapa banyak server uji yang dapat bertahan dan agar tidak mengganggu yang lain.
Poin kedua adalah kecepatan itu sendiri. Dalam mode manual, klik pada penciptaan produk, pencarian dan pembeliannya di toko online adalah 5 menit. 4 browser. Total 20 menit. Hanya dalam satu skenario kecil.
Autotest dalam skenario ini membutuhkan waktu 1,5 menit. Tetapi pada 8 browser. (Versi terbaru dan kedua dari belakang setiap browser).
Di mana untuk memulai?
Dengan skrip khusus.
Nilai tes atom turun setiap saat, terutama pada layanan microser. Secara umum, di dunia yang ideal, ini adalah area tanggung jawab programmer. Kesalahan semacam itu harus dideteksi pada tahap pengujian unit.
QA harus bekerja dari kisah pengguna. Karena programmer biasanya tidak mengenalnya, dan tidak mau tahu.
Dengan demikian, logika 1 uji - 1 kasus pengguna (skenario bisnis) paling dekat dengan kenyataan.
Tentu saja, ada kesulitan dengan persiapan data, misalnya, dalam kasus toko online, proses pembayaran kartu memerlukan kehadiran hal-hal dalam keranjang, dan baik data untuk pengguna baru, atau data otorisasi untuk yang sudah ada.
Ya, terkadang prasyarat membutuhkan waktu lebih lama daripada ujian, tetapi tidak sulit untuk menggunakan kembali skrip.
Script apa yang diotomatisasi
Paling tidak rentan terhadap perubahan dalam jangka pendek. Untuk otomatisasi setidaknya beberapa orang hidup.
Atau paling sering digunakan. Masuk akal untuk membantu pengujian manual dalam menghasilkan data uji. Misalnya, di papan buletin, masuk akal untuk mengotomatiskan pembuatan pengumuman, karena Selanjutnya, skenario apa pun membutuhkan iklan yang dibuat.
Apa yang sebenarnya dilakukan?
Biasanya dalam proyek di sana
- Backend
- Frontend
- Aplikasi seluler
- Kelenjar
Dan dua poin terakhir - biasanya hidup secara terpisah. Ponsel diuji pada skrip mereka sendiri, dan sedikit yang dapat mendekati debugging besi menurut JTAG tanpa persiapan.
Karena itu, saya mengusulkan untuk berurusan dengan Backend dan Front.
Pilih skenario
Katakanlah kita memiliki toko online.
Ada panel admin, ada klien dan admin depan.
Ada API yang melayani semua ini.
Di mana untuk memulai otomatisasi?
Mari kita tonton.
Ada pelanggan, ada karyawan.
Klien memiliki case pertama - melihat dan mencari produk, menambahkannya ke keranjang, dan desain.
Karyawan memiliki kasus yang paling umum - menambahkan kartu produk.
Kasing mana yang akan diotomatisasi terlebih dahulu? Dan bagaimana caranya?
Hal terpenting untuk toko adalah penjualan.
Oleh karena itu, sejarah pelanggan adalah yang paling penting untuk bisnis. Karena itu, menemukan barang, memasukkannya ke dalam keranjang dan menyelesaikan checkout dengan metode pembayaran apa pun adalah hal pertama yang harus dilakukan.
Dengan API. Tapi tanpa front. Di sini Anda bisa berdebat, tetapi kemungkinan besar desainnya akan berubah 2-3 kali lebih banyak, tetapi backend tidak mungkin. Jadi pada tahap 1, Anda harus memeriksa antarmuka secara manual.
Selanjutnya, lakukan pengecekan pada API yang mengedit kartu produk dan bagian depannya.
Dan kembali ke klien. Pada tahap ini, sudah akan ada statistik tentang tindakan pengguna yang paling sering, dan jalur klien yang paling sering. Ya, Metrik Yandex dan Webvisor juga membantu penguji.
Tidak masuk akal pada tahap pertama untuk memeriksa apakah fungsi pembayaran ke akun perusahaan melalui sistem pembayaran yang dihasilkan berfungsi jika 0,5% pengunjung menggunakan fungsi ini. Tentu saja, Anda dapat mengajukan pertanyaan kepada manajer mengapa ini diperlukan di sini, tetapi ini bukan tentang itu.
Misalkan kita memiliki 40% orang membayar di situs dengan kartu, uang tunai 30%, uang tunai 20% untuk pengiriman dan 10% semua metode lainnya.
Jenis pembayaran apa yang akan kita periksa pertama kali? Tentu saja petanya.
Artinya, kita harus memahami dengan jelas skenario mana yang paling penting untuk bisnis saat ini. Dan kualitasnya adalah yang pertama dan terutama.
Kondisi akhir
Kami menciptakan segalanya, semua yang ada dalam tes. Sampah. Anda perlu membersihkan diri sendiri. Adalah perlu untuk meramalkan sebelumnya di mana tes kita akan membersihkan setelah diri kita sendiri, dan di mana - tidak.
Jika barang dapat ditinggalkan di toko, dan tidak ada hal buruk yang akan terjadi, maka menambahkan hak administrator ke pengguna biasa perlu dikembalikan. Dan kemudian tes selanjutnya terkait dengan hak bisa jatuh. Atau lebih buruk - menjadi positif, meskipun seharusnya jatuh.
Keanehan
Ada pendekatan aneh ketika mereka mengotomatiskan skrip di mana pengguna menemukan bug. Biasanya ini adalah skenario yang sangat eksotis, dan menghabiskan sumber daya untuk itu tidak masuk akal. Ada situasi ketika fungsi memperbarui data bank rekanan rusak. Sinkronisasi dengan direktori BIC gagal.
Artinya, BIC baru tidak diperbarui. Tetapi bank baru mulai normal.
Apakah masuk akal untuk mengotomatiskan skenario ini? Jika kontraktor berubah setiap hari - mungkin. Dan kemudian itu adalah cacat dalam perencanaan.
Jika ini dilakukan 5-6 kali setahun, bisakah lebih baik melakukan tugas dengan prioritas lebih tinggi?
Apa yang akan terjadi selanjutnya?
Pada artikel selanjutnya saya akan memberi tahu Anda cara memulai pengujian API dengan cepat, sematkan pengujian ini dalam rilis, uji paralelisasi, cara memilih data untuk pengujian dan apa yang akan diberikan kepada kami.
Biarkan saya mengingatkan Anda tentang efek pestisida, dan cara menyinari seminimal mungkin.
Teknologi: Java + maven + testng + daya pikat + RestAssured + Pict.