Dan lagi dalam rekaman "Kalender Tester" kami . Bulan ini, Marina Tretyakova, penguji proyek Kontur . Pengiriman , akan berbicara tentang mengoptimalkan tes. Marina akan menganalisis masalah khusus dan cara menyelesaikannya, dan juga akan menyarankan cara mengoptimalkan tes dan mengurangi waktu pengujian.

Pertama-tama, mari kita bagikan semua pengujian dengan tingkat otomatisasi untuk memeriksa lebih lanjut setiap jenis secara lebih rinci.

Menurut tingkat otomatisasi, pengujian dibagi menjadi:

1. Jinak
2. Otomatis.
3. Otomatis (tanpa campur tangan manusia, saat ini - bukan mitos daripada kenyataan).

Pendekatan untuk mengoptimalkan tes secara langsung tergantung pada tingkat otomatisasi.

Optimalisasi berlaku untuk semua jenis tes

Pengujian meliputi langkah-langkah:

• persiapan sistem pengujian
• persiapan input data
• pengujian (secara manual atau otomatis, kami akan pertimbangkan di bawah),
• pengumpulan dan analisis hasil.

Dipercayai bahwa regresi manual membutuhkan waktu paling banyak dari penguji. Namun, dalam banyak kasus hal ini tidak terjadi. Minimal, Anda tidak boleh mengatakan ini sampai masalah diukur dan dibuktikan.

Pertimbangkan solusi untuk masalah umum. Banyak tip mungkin tampak sangat jelas bagi Anda, tetapi seperti yang ditunjukkan oleh pengalaman konferensi dan pidato rekan-rekan dari perusahaan lain, kiat-kiat ini masih relevan dan telah membuktikan penerapan dan kegunaannya.

Masalahnya:

1. Persiapan panjang sistem uji

Pertanyaan yang penting untuk diajukan sebelum menerapkan optimasi:

• Lama tentang apa?
• Siapa yang terlibat dalam pelatihan ini (penguji, programmer ...)?
• Berapa kali Anda dapat mempersiapkan sistem pengujian selama hari kerja? Apakah angka ini sesuai dengan kebutuhan pengujian?
• Apa tahap terpanjang dalam persiapan dan mengapa?

Untuk menemukan penyebab masalah ini, penting untuk mengajukan pertanyaan yang tepat.
Perhatikan contoh-contoh berikut:

Kompilasi panjang semua modul sistem
Pertanyaan yang tepat adalah : apakah semua modul perlu dikompilasi?
Solusi : untuk mengkompilasi tidak semua modul sistem, tetapi hanya mereka yang terpengaruh dalam tugas, dan yang akan berpartisipasi dalam rilis.

Proses manual yang panjang untuk memperbarui seluruh sistem untuk "mesin virtual" yang berbeda di bangku tes
Pertanyaan yang benar adalah : pada titik mana dalam pembaruan itu diperlukan partisipasi manusia, dan pada titik apa?
Solusi : untuk mengotomatiskan proses perhitungan, untuk menggunakan alat dan layanan penyebaran khusus yang diluncurkan atau mendebug mekanisme rilis untuk "pertempuran", tetapi menggunakannya hanya untuk penyebaran ke pengujian.

Proses panjang "menumpahkan" kode sumber ke "mesin virtual" di bangku tes untuk kompilasi dan pengguliran lebih lanjut
Kemungkinan masalah : konektivitas jaringan.
Pertanyaan yang benar adalah : panjang mengenai apa (mengumpulkan pada mesin lokal, mengumpulkan pada jaringan lokal)?
Solusi : bangku tes dan tempat sumbernya berada di jaringan yang sama untuk meminimalkan interaksi jaringan.

Saya mengalami masalah ini dalam pekerjaan saya ketika saya memutuskan untuk mengubah lokasi pengujian di Yekaterinburg ke Moskow. Dan dalam proses mencoba "menata" situs, kami segera menyadari bahwa memperbarui dudukan mulai memakan waktu bukan 15 menit, tetapi hampir 15 menit. Alasannya adalah bahwa kode sumber dengan sejumlah besar file kecil ada di Yekaterinburg, dan stand berada di Moskow. Proses perhitungan "beristirahat" pada transfer jaringan file kecil untuk kompilasi lebih lanjut dan "perhitungan" di mimbar. Akibatnya, kode itu juga “pergi” ke Moskow :)

2. Pengumpulan panjang dan analisis hasil

Pertanyaan yang penting untuk diajukan sebelum menerapkan optimasi:

• Lama tentang apa?
• Apa saja tahapan proses pengumpulan dan analisis hasil? Tahap mana yang paling lama dan mengapa?
• Siapa yang menganalisis hasilnya?
• Siapa yang memutuskan rilis dan atas dasar apa? Berapa banyak waktu yang diperlukan untuk membuat keputusan?

Sebagai contoh :
Hasil pengujian dikeluarkan sesuai dengan templat, pendaftaran menurut templat mengambil sebagian besar waktu selama pengujian.

Solusi (terima kasih, Cap!) : Menolak untuk mengisi hasil templat atau membuat templat yang lebih mudah untuk diisi. Penting untuk mencapai kesepakatan dengan tim dan mencari tahu dari mereka yang membaca hasil ini (dan apakah mereka membacanya?), Apakah benar-benar ada kebutuhan untuk template semacam itu (risikonya adalah menulis hasil tes "di atas meja").

Optimalisasi berlaku untuk tes manual

Tes-tes ini dapat dibagi menjadi dua kelas besar:

1. dilakukan secara teratur, misalnya, sebelum rilis (pertimbangkan pengujian regresi),
2. jarang dilakukan dan hanya untuk menguji fungsionalitas baru.

Jika regresi sering dan manual, maka masuk akal untuk berpikir tentang otomatisasi dan pengembalian otomatisasi, tetapi dalam artikel ini kami tidak akan mempertimbangkan ROI otomasi.

Untuk tes manual (bukan regresi), seseorang harus berbicara bukan tentang pengujian otomatisasi , tetapi tentang dukungan pengujian instrumental (seperti yang disarankan Alexei Barantsev pada pelatihan yang kami lakukan di perusahaan kami). Dalam hal ini, autotests akan bertindak sebagai alat. Dalam konteks ini, logika dan pandangan autotest secara umum akan berubah.

Untuk pengujian manual, pertama-tama, Anda perlu mencari tugas rutin (tugas, bukan tes!), Dan sudah mengoptimalkannya (menggunakan otomatisasi atau mendistribusikan kembali sumber daya manusia).

Misalnya, rutinitas untuk tes adalah menyiapkan data tes. Ada berbagai cara untuk melakukan persiapan ini:

1. secara manual melalui UI,
2. secara manual melalui API,
3. dengan menjalankan autotest, maka data akan menjadi efek samping dari tes ini,
4. Otomatis melalui skrip / utilitas / alat khusus melalui API atau UI.

Jika Anda tidak pernah memikirkan berapa banyak waktu yang dibutuhkan untuk mempersiapkan data tes secara manual, lalu mungkin sudah waktunya untuk mengukurnya? Dan ternyata lebih efisien menggunakan setidaknya yang kedua, dan lebih disukai pendekatan ke-3 dan ke-4.

Optimalisasi berlaku untuk pengujian otomatis

Masalah mempersiapkan data pengujian di sini lebih akut daripada dengan pengujian manual. Persiapan data uji harus:

1. cepat
2. Tahan terhadap perubahan desain / tata letak,
3. tahan terhadap kemungkinan uji coba paralel,
4. Tahan terhadap perubahan arsitektur internal sistem.

Sangat diharapkan bahwa persiapan data tidak memerlukan keterampilan dan waktu tambahan dalam implementasi solusi.

Data uji dapat disiapkan secara otomatis:

1. melalui UI,
2. melalui permintaan API atau HTTP,
3. melalui permintaan basis data.

Pertimbangkan pro dan kontra dari pendekatan ini secara lebih rinci dalam tabel:

Persiapan data uji melalui permintaan API atau HTTP untuk kombinasi plus dan minus adalah yang paling optimal.

Ada beberapa optimasi yang paling umum yang berlaku untuk pengujian otomatis:

Uji paralelisme

Jika salah satu masalah dari tes ini adalah tepatnya waktu bagian mereka, sementara ada sumber daya komputasi, Anda dapat memparalelkan dan menjalankannya dalam salah satu dari tiga mode paralel:

1. Paralelisme pada satu komputer, paralelisme pada utas prosesor.
2. Paralelisme pada komputer yang berbeda.
3. Kombinasi metode pertama dan kedua, yaitu, jika ada beberapa mesin komputer, tes lulus secara paralel di sepanjang aliran pada masing-masing dan secara paralel di antara semua mesin.

Menghapus tes lama

Jika tes ditulis, mereka lulus, tetapi mereka tidak benar-benar memeriksa apa pun (misalnya, dulu ada logika bisnis, sekarang tidak ada dan tes pada dasarnya tidak memeriksa apa pun), maka tes tersebut harus dihapus dengan kejam, karena sebenarnya mereka tidak memiliki makna , mengambil waktu yang tidak perlu dari lari. Ada baiknya juga menghapus tes, hasil kelulusan yang tidak mempengaruhi keputusan tentang kemungkinan rilis.

Menggunakan teknik desain uji untuk mengoptimalkan set kasus uji

Untuk pengujian manual, untuk mengoptimalkan set kasus uji, perlu menerapkan berbagai teknik desain tes. Untuk autotest, metode pemisahan menjadi kelas kesetaraan, berpasangan, analisis batas, dan banyak teknik lain juga harus digunakan untuk mengoptimalkan set autotest.

Mentransfer tes dan verifikasi yang ada ke tingkat lain

Misalnya, ada tes peramban yang membuka bilah pencarian, memasukkan "apel", "apel", "apel", "apel" (dan seterusnya), dan terlihat bahwa saat menyelesaikan pencarian, ia menerima pemberitahuan tentang membeli apel di toko (tes melihat fakta menunjukkan pemberitahuan dan tidak lebih). Jadi, tes UI yang panjang pada dasarnya tidak memeriksa UI, itu memeriksa logika bahwa tes unit dapat menguji, jadi tes ini harus dihapus dan tes unit ditulis sebagai gantinya.

Dekomposisi pengujian yang benar pada level “modular - integrasi - sistem”

Saya akan memberi contoh. Ada skenario manual: pilih produk di toko online, masukkan ke keranjang dan lanjutkan checkout. Apa yang bisa dilakukan (dan itu akan salah): buat persis satu tes yang akan mencari produk, tambahkan ke keranjang dan lanjutkan ke desain.

Dalam hal ini adalah benar untuk membagi tes menjadi tiga sub-skenario: memilih produk, menambahkan produk ke keranjang, dan menempatkan pesanan. Kami akan membagi setiap skenario menjadi lebih banyak pemeriksaan atom.
Misalnya: "membuka toko - menampilkan berbagai kategori barang untuk seleksi" - satu tes; “Memilih kategori dari berbagai kategori produk” adalah tes lain. Kami memeriksa setiap tes secara lebih terperinci dan menentukan level tes apa yang diperlukan untuk itu, contoh sebelumnya dapat memberi tahu jenis tes apa yang lebih baik untuk segera dirancang sebagai unit test.

Skema koneksi populer dari sistem yang diuji dan pengujian untuk pengujian otomatis aplikasi web:

Untuk mengoptimalkan pengujian otomatis aplikasi web, disarankan untuk mempertimbangkan optimalisasi setiap interaksi dalam skema yang dijelaskan.

Untuk mempermudah, pertimbangkan untuk mengoptimalkan beberapa interaksi:

1) Interaksi "uji kasus - browser - database"
Menggunakan API tidak hanya untuk menyiapkan data untuk pengujian, tetapi juga untuk mengambil sejumlah langkah dalam pengujian.

Misalnya, jika tujuannya adalah untuk memeriksa UI di akhir rangkaian tindakan yang panjang, maka tidak perlu melakukan semua tindakan melalui UI. Lagi pula, jika ada sesuatu yang putus di tengah rantai di UI, tes tidak akan mencapai akhir dan target memeriksa. Penguji akan menebak, dan jika mereka memperbaiki tautan yang rusak ini di rantai, maka semua yang bekerja setelah itu? Jika dalam kasus ini, di seluruh rantai, selain tindakan terakhir, API digunakan, kemudian dengan penguraian UI dari tautan apa pun, penguji akan mengetahui apakah sistem akan berfungsi sebagaimana dimaksud jika pengembang memperbaiki tautan yang rusak.

2) Interaksi "uji kasus - SeleniumWebDriver - browser".

• Menutup tab tambahan setelah menyelesaikan tes, alih-alih menutup browser.
  Pada proyek saya, optimasi ini membantu menghemat 10 menit dalam menjalankan tes UI (alih-alih 1 jam 10 menit, tes mulai lulus dalam 1 jam). Optimalisasi ini terhubung dengan logika SeleniumWebDriver, yang digunakan pada proyek - ia memiliki persiapan yang sangat lama untuk membuka browser, tetapi tab penutupan terjadi hampir secara instan.
• Optimalisasi cache aplikasi dari sistem yang sedang diuji, sehingga tes lulus lebih cepat.
• Menggunakan browser tanpa kepala sehingga tidak ada biaya dalam merender elemen halaman web.

Kesimpulannya

Untuk optimasi apa pun, Anda perlu mengidentifikasi dengan jelas sendiri masalah saat ini dalam proses pengujian, memperluas poin-poin yang ada di dalamnya, menyajikan opsi yang mungkin (beberapa lebih baik!) Untuk menyelesaikannya. Setelah itu, diperlukan untuk menyuarakan mereka dalam tim, "menjual" ide dan saran mereka untuk solusi, dan hanya setelah persetujuan universal mendistribusikan upaya dan menyelesaikan tugas. Penilaian awal "Sebelum" dan penilaian "Setelah" akan membantu untuk mempertimbangkan semua keuntungan dari proses optimalisasi.

Dan sekali lagi saya ingin mengulangi: jangan mencari tes rutin, mencari tugas rutin, dan mengotomatisasi mereka!

Daftar artikel kalender:
Coba pendekatan yang berbeda
Pengujian pasangan yang wajar
Umpan balik: bagaimana itu terjadi
Optimalkan Tes
Baca buku
Pengujian analitik
Penguji harus menangkap bug, membaca Caner dan mengatur gerakan.
Muat layanan
Metrik Layanan QA
Uji keamanan
Kenali pelanggan Anda
Ambil backlog