Melanjutkan serangkaian abstrak dengan HL2018. Orang-orang dari Badoo (Vladimir
Yants vyants dan Nikolay Krapivny) membantu saya memeriksa ringkasan ini, yang saya ucapkan terima kasih banyak. Saya harap ini memiliki efek positif pada kualitas pesan laporan.
Fitur dari proses pengembangan:
Tanggung jawab pengembang tidak berakhir dengan rilis backend. Dia bertanggung jawab sebelum implementasi pada platform.
Ada pengujian manual, tetapi klien tidak siap pada saat rilis dan dirilis dengan penundaan (tidak dapat diprediksi). Kita sering tidak tahu kapan pelanggan akan mulai menerapkannya. Kadang-kadang (tidak sering) fitur mulai dilakukan setelah waktu yang lama. Karena itu, pengujian dengan tangan Anda sulit dan tidak semuanya mungkin. Oleh karena itu, diperlukan autotest.
Tes
Tes unit
Ditulis dalam phpunit.
Uji unit kecil. Mereka tidak pergi ke basis data atau ke layanan (mereka tidak boleh berinteraksi dengan apa pun).
Legacy masih memiliki dan mempersulit proses pengujian.
Mereka mengembangkan pustaka softMocks - itu mengaitkan semua termasuk / memerlukan dan menggantinya dengan yang diubah.
Anda dapat menemukan metode apa pun: statis, pribadi, final.
Perpustakaan tersedia dalam sumber terbuka.
Masalah: softmock rileks dan memungkinkan Anda untuk menulis kode yang tidak diuji (dan tutup dengan tes).
Menerima aturan:
- Kode baru harus mudah untuk diuji phpunit
- SoftMocks - kasing ekstrem (kode lama / panjang / mahal / rumit)
Kami melihat ulasan kode untuk aturan ini.
Kualitas tes
Pengujian Mutasi
- Ambil kodenya
- Ambil cakupan kode
- Kami mengurai kode dan menerapkan mutasi (ubah + => -; true => false, dll.)
- Untuk setiap mutasi, kami menjalankan serangkaian tes.
- Jika tes gagal, maka kira-kira. Jika tidak, mereka tidak cukup efektif. Kami mengerti, mengubah / menambah tes.
Ada solusi siap pakai (Humbug, Infection), tetapi mereka tidak cocok (tidak kompatibel dengan softmock, ada kesulitan dengan cakupan kode). Karena itu, mereka menulis sendiri.
Pengujian mutasi belum tersedia untuk pengujian manual. Tersedia untuk dijalankan secara manual, dari konsol. Sekarang kami menerapkannya dalam pipa CI, kami sedang membangun prosesnya. Hasilnya akan di Habr.
Tes integrasi
Menguji operasi beberapa komponen bersamaan; Kami memeriksa pekerjaan dengan pangkalan dan / atau layanan.
Pendekatan standar untuk pengujian basis data (DBUnit):
- Naikkan database uji
- Isi itu
- Jalankan tes
- Kami membersihkan database
Masalahnya:
- Hal ini diperlukan untuk mendukung datatables dan dataset (relevansi isi database)
- Butuh waktu untuk menyiapkan database
- Peluncuran paralel membuat tes tidak stabil dan menyebabkan kebuntuan
Solusi: Pustaka DBMocks (solusi sendiri)
Prinsip kerja:
- Metode driver DB dicegat menggunakan SoftMocks pada uji setUp
- Dari permintaan parsim db + table
- Tmpfs membuat tabel sementara dengan skema yang sama
- Semua kueri hanya pergi ke tabel sementara
- Pada TearDown, mereka dihapus.
Perpustakaannya kecil, tetapi belum terbuka di sumber terbuka.
Hasil:
- Tes tidak dapat merusak data dalam tabel asli
- Tes diisolasi satu sama lain (dapat dijalankan secara paralel)
- Menguji kompatibilitas kueri dengan versi MySQL
Tes API
- Tiru sesi klien
- Mampu mengirim permintaan backend
- Backend merespons hampir seperti pelanggan nyata
Biasanya, tes semacam itu membutuhkan pengguna yang diotorisasi. Itu harus dibuat sebelum tes dan dihapus setelah. Ini menimbulkan risiko tambahan (replikasi, tugas latar belakang).
Solusi: Kami membuat kumpulan pengguna uji. Mempelajari cara membersihkannya.
Pengguna uji berada di lingkungan yang sama dengan yang asli, karena devel! = Prod. Hal ini diperlukan untuk mengisolasi pengguna tes dan hidup.
Untuk isolasi, bendera is_test_user ditambahkan untuk pengguna. Dan para pengguna ini juga dikecualikan dari analitik dan hasil uji a / b.
Itu bisa dibuat lebih murah dengan mengirimkan pengguna uji "ke Antartika", di mana tidak ada yang akan melihatnya (kecuali penguin).
API QA
Alat untuk mempersiapkan lingkungan dalam pengujian api, sebenarnya merupakan pintu belakang di backend untuk mengubah pengaturan pengguna / lingkungan dengan cepat.
- Metode api yang didokumentasikan dengan baik
- Kelola data dengan cepat dan mudah.
- Pengembang menulis backend
- Hanya dapat diterapkan untuk menguji pengguna.
Mengizinkan pengguna mengubah data yang tidak dapat diubah (misalnya, tanggal pendaftaran).
Diperlukan perlindungan:
- Di tingkat jaringan (hanya tersedia dari jaringan kantor)
- Sebuah rahasia diteruskan dengan setiap permintaan, yang validitasnya diperiksa
- Metode hanya berfungsi dengan pengguna uji.
Ada program BugsBounty di HackerOne. Mereka membayar untuk kerentanan yang ditemukan. Satu cant dengan API QA ditemukan menggunakannya.
Mengolok-olok jauh
Moki untuk backend jarak jauh.
Kerjakan di atas dasar mock lembut. Tes meminta backend untuk menginisialisasi sesi mock. Setelah menerima permintaan, backend memeriksa daftar mox untuk sesi dan menerapkannya menggunakan SoftMock.
Contoh uji:
Tes API terlalu nyaman. Sangat menggoda untuk menulisnya alih-alih Unit. Tetapi tes API jauh lebih lambat.
Mengadopsi seperangkat aturan:
- Tujuan dari pengujian API adalah untuk menguji protokol dan integrasi
- Periksa aliran kompleks yang valid
- Variabilitas kecil tidak dapat diuji.
- Pada ulasan kode, kami menguji tes juga.
Tes Ui
Perintah backend tidak menulis.
Fitur ini dicakup oleh tes Ui saat stabil.
Digunakan oleh selenium untuk web. Untuk labu ponsel.
Uji coba
100.000 unit tes. 6.000 integrasi, 14.000 tes api.
Dalam 1 aliran, waktunya adalah 40 menit / 90 menit / 10 jam.
Made TestCloud - cloud untuk menjalankan tes.
Distribusi tes antara utas:
- Anda dapat sama (buruk, semua tes berbeda, ternyata tidak merata di bagian waktu)
- Jalankan lebih dari satu utas dan beri makan pengujian phpunit satu per satu (inisialisasi overhead. Panjang!)
Solusi:
- Pengumpulan statistik saat dijalankan.
- Layout tes sehingga potongan berjalan tidak lebih dari 30 detik
Masalah dengan tes api adalah waktu yang lama, banyak sumber daya dan tidak memungkinkan orang lain untuk mengeksekusi.
Untuk mengatasinya, kami membagi cloud menjadi 2 bagian:
- Hanya menjalankan tes cepat.
- Menjalankan kedua jenis tes.
Hasilnya adalah percepatan waktu untuk:
- Unit - 1 mnt
- Integrasi - 5 mnt
- API - 15 menit.
Menjalankan cakupan kode
Tes apa yang harus dilakukan? Akan menampilkan cakupan kode.
- Kami mendapatkan diff cabang
- Buat daftar file yang dimodifikasi
- Dapatkan daftar tes untuk file-file ini.
- kami menjalankan menjalankan suite hanya dari tes ini.
Cakupan dibentuk sekali sehari, pada malam hari, untuk cabang utama. Hasil (diff) ditambahkan ke database.
Pro:
- Kami menjalankan lebih sedikit pengujian: lebih sedikit beban perangkat keras dan umpan balik pengujian yang lebih cepat
- Anda dapat menjalankan tes untuk tambalan. Ini memungkinkan Anda untuk dengan cepat meluncurkan perbaikan terbaru. Di tambalan, kecepatan adalah yang paling penting.
Cons:
- Rilis backend 2 kali sehari. Setelah makan siang, cakupannya kurang relevan (tetapi saat mengalahkan, kami selalu mengendarai suite lengkap).
- Tes api menghasilkan cakupan yang luas. Bagi mereka, pendekatan ini tidak memberikan banyak penghematan.
Jika pengembang perlu segera melihat cakupan kode, yaitu alat yang dapat dijalankan di konsol dan segera mendapatkan metrik terbaru untuk cakupan file / komponen tertentu.
Itu dianggap rumit: data pada master coverege diambil, semua tes yang dimodifikasi ditambahkan, ternyata suite kecil di mana cakupan sudah dipertimbangkan.
Ringkasan
- Perlu semua level tes
- Kuantitas! = Kualitas. Lakukan Pemeriksaan Kode dan Pengujian Mutasi
- Pisahkan pengguna uji dari yang asli.
- Backends di backend menyederhanakan dan mempercepat tes menulis
- Kumpulkan statistik pada tes.
Referensi