⚙️ 🖇️ 🚽 Alih-alih 100 peluncuran aplikasi - satu autotest, atau cara menyelamatkan insinyur QA 20 tahun kehidupan 🧔🏻 🌛 🈺

Halo semuanya, nama saya Evgeny Demidenko. Selama beberapa tahun terakhir, saya telah mengembangkan sistem pengujian game otomatis di Pixonic. Hari ini saya ingin berbagi pengalaman dalam mengembangkan, mendukung, dan menggunakan sistem seperti itu pada proyek Robot Perang.

Untuk memulainya, kami akan mencari tahu apa yang kami otomatisasi dengan sistem ini.

Pertama-tama, ini adalah pengujian UI regresi, pengujian gameplay-inti dan otomatisasi tolok ukur. Ketiga sistem secara keseluruhan memungkinkan untuk mengurangi beban pada departemen QA sebelum rilis, lebih percaya diri dalam refactoring skala besar dan mendalam, dan terus-menerus memelihara penilaian keseluruhan kinerja aplikasi, serta bagian-bagiannya masing-masing. Poin lain yang ingin saya perhatikan adalah otomatisasi rutin, misalnya - pengujian hipotesis apa pun.

gambar

Saya akan memberikan beberapa angka. Sekarang lebih dari 600 tes UI dan sekitar 100 tes inti telah ditulis untuk Robot Perang. Pada proyek ini saja, kami membuat sekitar satu juta peluncuran skrip pengujian kami, yang masing-masing membutuhkan waktu sekitar 80 detik. Jika kami memeriksa skenario ini secara manual, kami akan menghabiskan setidaknya lima menit masing-masing. Selain itu, kami meluncurkan lebih dari 700 ribu tolok ukur.

Dari platform, kami menggunakan Android dan iOS - hanya 12 perangkat di taman. Dua programmer terlibat dalam pengembangan dan dukungan sistem, dan satu insinyur QA sedang menulis dan menganalisis tes.

Adapun tumpukan perangkat lunak, kami menggunakan NUnit dalam database kami, tetapi tidak untuk pengujian unit, tetapi untuk pengujian integrasi dan sistem. Untuk gameplay inti dan membangun pengujian verifikasi, kami menggunakan solusi bawaan dari Unity - Unity Test Tools. Untuk menulis dan menganalisis laporan setelah pengujian ini, Laporan Uji Daya Tarik dari Yandex digunakan, serta TeamCity - sebagai sistem integrasi berkelanjutan untuk pembuatan aplikasi, penyebaran server, dan menjalankan tes. Kami menggunakan Repositori Nexus dan database PostgreSQL untuk menyimpan artefak kami.

Bagaimana Anda membuat, menganalisis, dan menjalankan tes

Misalkan kita ingin menulis tes sederhana yang di jendela pengaturan permainan akan memeriksa ikon untuk menghidupkan dan mematikan suara.

Jadi, kami menulis tes dan berkomitmen untuk cabang tertentu di repositori pengujian kami. Kami memilih tes yang ingin kami jalankan, memilih build untuk dijalankan, atau mungkin komit tertentu, yang akan membangun assemble. Sekarang jalankan tes, tunggu sebentar dan dapatkan hasilnya.

Dalam hal ini, 575 tes diluncurkan, di mana 97% berhasil. Kami membutuhkan sekitar tiga jam untuk menyelesaikan semua tes. Sebagai perbandingan, tes yang sama, jika dilakukan secara manual, akan membutuhkan setidaknya 50 jam operasi berkelanjutan.

Jadi apa yang terjadi pada 3% tes yang gagal?

Kami membuka tes tertentu dan melihat pesan bahwa terjadi kesalahan saat mencocokkan tangkapan layar.

Lalu kami membuka tangkapan layar, yang pada saat itu ada di perangkat, dan kami melihat bahwa zona yang tidak sesuai dengan aslinya ditandai dengan piksel merah. Sebagai perbandingan, kami memberinya.

Secara alami, setelah ini, insinyur QA harus membuat bug bahwa perilaku build tidak sesuai dengan dokumen desain game, atau memperbarui tangkapan layar asli, karena dokumen desain game telah berubah, dan sekarang elemen-elemen ini tidak akan ada dalam game.

Itu terlihat keren. Mengapa semua ini perlu?

Beberapa waktu yang lalu, pada proyek Robot Perang, kami perlu melakukan satu refactoring kecil. Itu terdiri dari menulis ulang beberapa potong kode untuk menembakkan senjata - khususnya, senapan mesin.

Selama pengujian, kami menemukan satu nuansa yang menarik: laju senapan mesin bergantung langsung pada FPS. Bug seperti itu akan tidak realistis untuk dideteksi selama pengujian manual: pertama, karena fitur perhitungan jaringan kerusakan pada proyek, dan kedua, karena fakta bahwa aplikasi War Robots dioptimalkan dengan cukup baik dan pada saat itu berjalan pada semua perangkat dengan FPS yang kira-kira sama - 30 frame / s. Tentu saja, ada penyimpangan kecil, tetapi mereka tidak cukup untuk melihat peningkatan kerusakan akibat menembakkan senjata selama pengujian manual. Kemudian kami bertanya pada diri sendiri: berapa banyak bug yang masih kita miliki dan berapa banyak yang dapat muncul selama refactoring?

Karena kami tidak ingin mengurangi jumlah tes, tetapi lebih meningkatkannya, karena kami telah merencanakan pembaruan besar dan peningkatan jumlah konten, kami tidak ingin tumbuh secara horizontal dan menambah jumlah karyawan departemen QA. Sebaliknya, kami merencanakan pertumbuhan vertikal dengan mengurangi rutinitas karyawan saat ini dan membuat hidup mereka lebih mudah selama pengujian integrasi konten baru.

Alat apa yang kita gunakan

Ketika kami pertama kali mulai mengotomatisasi tes, pertama-tama kami menarik perhatian ke Unity Integration Test Tools, yang dibangun pada saat itu di Unity pada saat itu. Kami menulis beberapa UI dan tes inti, menyelesaikan refactoring yang kami mulai sebelumnya, dan puas dengan itu, karena solusinya sudah bekerja, yang berarti bahwa asumsi kami benar, dan kami harus melanjutkan. Satu-satunya negatif dari solusi ini, tetapi sangat penting bagi kami, adalah bahwa tes tidak dapat dijalankan pada perangkat seluler.

Jadi, kami datang dengan ide untuk menggunakan kerangka kerja Appium. Ini adalah fork dari kerangka pengujian terkenal lainnya - Selenium. Pada gilirannya, ini mungkin merupakan kerangka kerja paling terkenal untuk menguji aplikasi web, konsep utamanya adalah bekerja dengan elemen UI, mendapatkan koordinatnya dan mengatur input ke dalam elemen UI ini. Appium mengadopsi konsep ini dan, di samping driver web yang ada di Selenium, juga menambahkan driver iOS dan Android: mereka menggunakan kerangka uji asli untuk masing-masing platform ini.

Karena tidak ada elemen UI asli di Unity, dan hanya ada satu elemen UI di mana gambar diberikan, saya harus menambahkan selain Appium UnityDriver, yang memungkinkan Anda untuk bekerja dengan hierarki adegan, mendapatkan objek adegan, dan banyak lagi.

Pada saat itu, seorang insinyur QA sudah muncul di proyek, hal-hal mulai mengalir, jumlah skenario pengujian mulai tumbuh secara signifikan, yang secara bertahap kami otomatiskan. Kami mulai meluncurkannya di perangkat, dan secara umum, pekerjaan kami sudah terlihat seperti yang kami inginkan.

Di masa depan, selain tes UI, lebih banyak uji inti dan alat lain berdasarkan sistem kami mulai muncul, sebagai akibatnya kami mengalami kinerja dan kualitas kerja pada berbagai perangkat, menambahkan dukungan untuk beberapa perangkat lagi, tes paralel, dan juga mengabaikan Appium di manfaat kerangka kerja Anda sendiri.

Satu-satunya masalah yang tetap ada pada kami - dan sampai sekarang - adalah hierarki UI. Karena jika hierarki berubah dalam adegan karena UI refactoring atau bekerja di tempat kejadian, ini perlu didukung dalam pengujian.

Setelah inovasi dan revisi berikutnya, arsitektur seluruh sistem mulai terlihat sebagai berikut.

Kami mengambil build Robot Perang, mengambil tes kami, yang berada di repositori terpisah, menambahkan beberapa parameter untuk dijalankan di sana yang memungkinkan kami untuk mengkonfigurasi peluncuran tes dalam setiap kasus, dan mengirimkan semuanya ke agen TeamCity pada PC jarak jauh. Agen TeamCity meluncurkan pengujian kami, memberikan mereka parameter pembuatan Robot dan meluncurkan, setelah itu tes mulai bekerja dan "berkomunikasi" secara mandiri dengan perangkat yang terhubung ke agen TeamCity melalui kabel: memasang build di atasnya, menjalankannya, menjalankan skrip tertentu, menghapus membangun, memulai ulang aplikasi dan sebagainya.

Karena tes dan aplikasi itu sendiri berjalan pada perangkat yang berbeda secara fisik - pada ponsel dan Mac mini - kami perlu mengimplementasikan komunikasi antara kerangka kerja kami, War Robots API dan Unity API. Kami telah menambahkan server UDP kecil ke aplikasi, yang menerima perintah dari kerangka kerja dan berkomunikasi dengan API aplikasi dan Persatuan melalui penangan.

Tugas utama kerangka kerja kami adalah mengatur pekerjaan pengujian: persiapan, penyelesaian, dan pengelolaan perangkat yang benar. Secara khusus, paralelisasi untuk mempercepat pekerjaan, pilihan perangkat dan tangkapan layar yang tepat, komunikasi dengan build. Setelah menyelesaikan tes, kerangka kerja kami harus menyimpan semua artefak yang dihasilkan dan menghasilkan laporan.

Kiat untuk memilih perangkat

Secara terpisah, saya ingin memperhatikan pilihan perangkat untuk pengujian.

Perhatian yang cukup harus diberikan kepada hub. Jika Anda ingin menjalankan benchmark pada perangkat Anda - terutama jika itu adalah perangkat Android - mereka akan kehabisan daya. Hub harus menyediakan daya yang diperlukan untuk perangkat yang digunakan. Ada fitur lain yang sangat halus: beberapa hub memiliki daya aktif, dan daya ini mati setelah daya melonjak, setelah itu dihidupkan hanya dengan menekan tombol fisik. Kami memiliki hub seperti itu, dan ini sangat merepotkan.

Jika Anda ingin menjalankan pengujian UI regresi dan menguji logika pada perangkat, jangan gunakan perangkat yang berbeda. Ambil perangkat yang sama - lebih baik yang paling produktif yang Anda mampu, karena dengan cara ini Anda akan menghemat waktu pada rem perangkat, kenyamanan bekerja dengan mereka, dan perilaku aplikasi pada semua perangkat akan sama.

Masalah terpisah adalah penggunaan cloud farms. Kami belum menggunakannya, meskipun kami telah melakukan penelitian tentang mereka: apa itu, berapa biayanya dan bagaimana menjalankan tes kami pada mereka - tetapi sejauh ini kami memiliki cukup perangkat taman internal kami untuk memenuhi permintaan kami.

Pelaporan Tes

Setelah tes selesai, kami menghasilkan laporan daya pikat, yang mencakup semua artefak yang dibuat selama pengujian kami.

"Pekerja keras" utama untuk menganalisis apa yang terjadi dan mengidentifikasi penyebab kecelakaan selama tes adalah log. Pertama-tama, kami mengumpulkannya dari kerangka kerja kami, yang memberi tahu kami tentang keadaan naskah dan apa yang terjadi dalam naskah ini. Kami membagi log ke dalam sistem (lebih detail) dan log untuk QA (lebih ringkas dan nyaman untuk analisis). Kami juga mengumpulkan log sistem dari perangkat (misalnya, logcat) dan log dari aplikasi Unity.

Selama musim gugur pengujian, kami juga mengambil tangkapan layar untuk memahami apa yang terjadi pada perangkat pada saat musim gugur, merekam video untuk memahami apa yang terjadi sebelum kecelakaan, dan mencoba mengumpulkan informasi maksimum tentang status perangkat, seperti ping server kami dan informasi di ifconfig untuk memahami apakah perangkat memiliki IP. Anda akan terkejut, namun, jika Anda meluncurkan aplikasi secara manual 50 kali, semuanya akan baik-baik saja dengan itu, tetapi jika Anda menjalankannya 50 ribu kali dalam mode otomatis, Anda akan menemukan bahwa Internet pada perangkat mungkin hilang, dan itu tidak akan jelas selama pengujian, apakah ada koneksi sebelum dan sesudah jatuh.

Kami juga mengumpulkan daftar proses, daya baterai, suhu, dan umumnya semua yang dapat kami capai.

Apa tangkapan layar dan video yang bagus

Beberapa waktu lalu, insinyur QA kami menyarankan, selain mengambil tangkapan layar di musim gugur, di tempat-tempat tertentu dalam pengujian untuk membandingkan tangkapan layar ini dengan templat yang ada di repositori kami. Dengan demikian, ia mengusulkan penghematan waktu pada jumlah uji coba dan mengurangi ukuran basis kode. Yaitu, dengan satu tes kita dapat memeriksa logika dan bagian visual. Dari sudut pandang konsep pengujian unit, ini tidak terlalu benar, karena dalam satu pengujian kita tidak boleh menguji beberapa hipotesis. Tetapi ini adalah langkah yang disengaja: kami tahu bagaimana menganalisis semua ini dengan benar, jadi kami memberanikan diri untuk menambahkan fungsionalitas serupa.

Pertama-tama, kami berpikir tentang menambahkan perpustakaan untuk mencocokkan tangkapan layar, tetapi kami menyadari bahwa menggunakan gambar dengan resolusi yang berbeda tidak terlalu dapat diandalkan, jadi kami berhenti pada perangkat dengan resolusi yang sama dan hanya membandingkan gambar dengan ambang tertentu piksel demi piksel.

Efek yang sangat menarik menggunakan pencocokan tangkapan layar adalah bahwa jika beberapa proses sulit untuk diotomatisasi, kami akan mengotomasinya sejauh ternyata, dan kemudian kami cukup melihat tangkapan layar secara manual. Inilah yang kami lakukan dengan lokalisasi uji. Kami menerima permintaan untuk menguji pelokalan aplikasi kami, jadi kami mulai melihat perpustakaan yang memungkinkan pengenalan teks - tetapi kami menyadari bahwa itu agak tidak dapat diandalkan, dan sebagai hasilnya kami menulis beberapa skrip yang “berjalan” melintasi layar yang berbeda dan menyebabkan pop-up yang berbeda. up, dan saat ini tangkapan layar dibuat. Sebelum memulai skrip semacam itu, kami mengubah lokal di perangkat, menjalankan skrip, mengambil tangkapan layar, mengubah lokal lagi dan menjalankan skrip lagi. Dengan demikian, semua tes dijalankan pada malam hari,sehingga pada pagi hari insinyur QA dapat melihat 500 tangkapan layar dan segera menganalisis jika ada masalah dengan lokalisasi di suatu tempat. Ya, tangkapan layar masih harus diawasi, tetapi ini jauh lebih cepat daripada secara manual melewati semua layar pada perangkat.

Kadang-kadang tangkapan layar dan log tidak cukup: sesuatu yang aneh mulai terjadi pada perangkat, tetapi karena mereka terletak jauh, Anda tidak dapat pergi dan mengevaluasi apa yang terjadi di sana. Selain itu, kadang-kadang tidak jelas apa yang terjadi secara harfiah beberapa saat sebelum tes jatuh. Oleh karena itu, kami menambahkan rekaman video dari perangkat, yang dimulai dengan awal pengujian dan disimpan hanya jika jatuh. Dengan bantuan video seperti itu, sangat mudah untuk melacak aplikasi macet dan macet.

Apa lagi yang bisa dilakukan sistem kami?

Beberapa waktu lalu, dari departemen pengujian QA, kami menerima permintaan untuk mengembangkan alat untuk mengumpulkan metrik selama playtests manual.

Untuk apa ini?

Ini diperlukan agar insinyur QA, setelah playtest manual, juga dapat menganalisis perilaku FPS dan konsumsi memori dalam aplikasi, sekaligus melihat tangkapan layar dan video yang mencerminkan apa yang terjadi pada perangkat ini.

Sistem yang kami kembangkan bekerja sebagai berikut. Insinyur QA meluncurkan War Robots pada perangkat, menyalakan rekaman sesi playbench - analog kami dari gamebench - memainkan playtest, lalu mengklik "akhiri sesi playbench", laporan yang dihasilkan disimpan dalam repositori, setelah itu insinyur dengan data untuk playtest ini dapat mencapai pekerjaannya mesin dan melihat laporan: apa saja kekurangan pada FPS, apa konsumsi memori, apa yang terjadi pada perangkat.

Kami juga secara otomatis meluncurkan tolok ukur pada proyek Robot Perang, pada dasarnya hanya membungkus tolok ukur yang ada dalam peluncuran otomatis. Hasil benchmark biasanya satu digit. Dalam kasus kami, ini biasanya FPS rata-rata per tolok ukur. Selain peluncuran otomatis, kami memutuskan untuk menambahkan sesi playbench lain dan dengan demikian menerima tidak hanya angka tertentu, bagaimana tolok ukur bekerja, tetapi juga berkat informasi yang kita dapat menganalisis apa yang terjadi pada tolok ukur pada saat itu.

Kami juga harus menyebutkan tes permintaan tarik. Kali ini lebih untuk membantu tim pengembangan klien, daripada QA-engineer. Kami menjalankan uji verifikasi build yang disebut untuk setiap permintaan tarik. Anda dapat menjalankan keduanya di perangkat dan di editor Unity untuk mempercepat pekerjaan memeriksa logika. Kami juga menjalankan serangkaian uji inti di cabang terpisah, tempat semacam pendesainan ulang beberapa elemen atau kode refactoring berlangsung.

Dan fitur berguna lainnya

Pada akhirnya, saya ingin membahas beberapa kasus menarik yang telah kami temui dalam beberapa tahun terakhir.

Salah satu kasus paling menarik yang muncul baru-baru ini bersama kami adalah tolok ukur selama berkelahi dengan bot.

Untuk proyek baru, Pixonic Dino Squad mengembangkan sistem di mana insinyur QA dapat memainkan tes bermain dengan bot, agar tidak menunggu rekan-rekannya, tetapi untuk menguji beberapa hipotesis. Insinyur QA kami, pada gilirannya, diminta untuk menambahkan kemampuan tidak hanya bermain dengan bot, tetapi juga agar bot dapat bermain satu sama lain. Jadi, kami cukup meluncurkan aplikasi, dan saat ini bot mulai bermain dengan bot lain. Pada saat yang sama, semua interaksi adalah jaringan, dengan server nyata, hanya sebagai gantinya pemain bermain komputer. Semua ini dibungkus dengan tolok ukur dan sesi playbench dengan pemicu untuk memulai malam. Jadi, pada malam hari kami memulai beberapa pertempuran antara bot dan bot, saat ini FPS dan konsumsi memori ditulis, tangkapan layar diambil, dan video direkam. Di pagi hari, insinyur QA datang dan bisa melihat,apa playtests diadakan dan apa yang terjadi pada mereka.

Yang juga patut dicoba adalah kebocoran tekstur. Ini adalah semacam sub-analisis penggunaan memori - tetapi di sini kita terutama memeriksa penggunaan, misalnya, tekstur garasi dalam pertempuran. Oleh karena itu, dalam pertempuran tidak boleh ada atlas yang digunakan di garasi, dan ketika kita keluar dari pertempuran, tekstur yang digunakan dalam pertempuran tidak harus tetap dalam ingatan.

Efek samping yang menarik dari sistem kami adalah bahwa hampir sejak awal penggunaannya, kami melacak waktu pemuatan aplikasi. Dalam kasus War Robot, kali ini tidak kuat, tetapi terus berkembang, karena konten baru sedang ditambahkan, dan kualitas konten ini meningkat - tetapi kita dapat menjaga parameter ini di bawah kendali dan selalu menyadari ukurannya.

Alih-alih sebuah kesimpulan

Pada akhirnya, saya ingin menarik perhatian pada masalah yang kita miliki yang kita ketahui dan yang ingin kita pecahkan sejak awal.

Yang pertama dan paling menyakitkan adalah perubahan UI. Karena kami bekerja dengan kotak hitam, kami tidak menanamkan apa pun dalam aplikasi War Robots, kecuali untuk server kami - yaitu, kami menguji semuanya dengan cara yang sama seperti yang akan diuji oleh insinyur QA. Tapi entah bagaimana kita perlu mengakses elemen-elemen dalam adegan. Dan kami menemukan mereka di sepanjang jalan absolut. Jadi, ketika sesuatu berubah di atas panggung, terutama pada tingkat hierarki yang tinggi, kita harus mendukung perubahan ini dalam sejumlah besar tes. Sayangnya, kami tidak dapat melakukan apa pun dengan ini sekarang. Tentu saja, ada beberapa solusi, tetapi mereka membawa masalah tambahan mereka.

Masalah besar kedua adalah infrastruktur. Seperti yang saya katakan, jika Anda menjalankan aplikasi Anda 50 kali dengan tangan Anda, Anda tidak akan melihat sebagian besar masalah yang akan terungkap jika Anda menjalankan aplikasi Anda 50 ribu kali. Masalah-masalah yang dapat dengan mudah diselesaikan dalam mode manual - misalnya, menginstal ulang build atau me-restart Internet - akan menjadi masalah nyata dalam otomatisasi, karena semua masalah ini harus ditangani dengan benar, pesan kesalahan ditampilkan, dan asalkan semuanya dapat terjadi. Secara khusus, kita perlu menentukan mengapa tes jatuh: karena logika yang tidak berfungsi atau beberapa jenis masalah infrastruktur, atau karena alasan lain. Ada banyak masalah dengan perangkat low-end: mereka tidak memiliki build, Internet jatuh, perangkat membeku, crash, tidak menyala, cepat habis, dan sebagainya.

Saya juga ingin berinteraksi dengan UI asli, tetapi sejauh ini kami tidak memiliki kesempatan seperti itu. Kami tahu bagaimana melakukan ini, tetapi keberadaan permintaan lain untuk fungsi tidak memungkinkan kami untuk melakukan ini.

Dan secara pribadi, keinginan saya adalah untuk mematuhi standar yang ada di industri, tetapi ini juga dalam rencana untuk masa depan, bahkan mungkin tahun ini.

Alih-alih 100 peluncuran aplikasi - satu autotest, atau cara menyelamatkan insinyur QA 20 tahun kehidupan