Banyak pengembang tes iOS UI mungkin akrab dengan masalah waktu uji coba. Badoo menjalankan lebih dari 1.400 tes end-to-end untuk aplikasi iOS untuk setiap proses regresi. Ini lebih dari 40 jam pengujian yang lulus dalam 30 menit nyata.
Nikolai Abalov dari Badoo berbagi bagaimana ia berhasil mempercepat pelaksanaan tes dari 1,5 jam menjadi 30 menit; bagaimana mereka mengungkap tes terkait erat dan infrastruktur iOS dengan pergi ke server perangkat; bagaimana hal itu membuatnya lebih mudah untuk menjalankan tes secara paralel dan membuat tes dan infrastruktur lebih mudah untuk mendukung dan skala.
Anda akan belajar betapa mudahnya menjalankan tes secara paralel dengan alat-alat seperti fbsimctl, dan bagaimana memisahkan tes dan infrastruktur dapat membuatnya lebih mudah untuk meng-host, mendukung, dan skala tes Anda.
Awalnya, Nikolai mempresentasikan laporan di konferensi Heisenbug (Anda dapat menonton
video ), dan sekarang untuk Habr kami membuat versi teks dari laporan tersebut. Berikutnya adalah narasi orang pertama:
Halo semuanya, hari ini saya akan berbicara tentang penskalaan pengujian untuk iOS. Nama saya Nicholas, saya terutama berurusan dengan infrastruktur iOS di Badoo. Sebelum itu, ia bekerja untuk 2GIS selama tiga tahun, terlibat dalam pengembangan dan otomasi, khususnya, ia menulis Winium.Mobile - sebuah implementasi dari WebDriver untuk Windows Phone. Saya dibawa ke Badoo untuk bekerja pada otomatisasi Windows Phone, tetapi setelah beberapa saat bisnis memutuskan untuk menunda pengembangan platform ini. Dan saya ditawari tugas menarik untuk otomatisasi iOS, tentang ini saya akan sampaikan hari ini.
Apa yang akan kita bicarakan? Rencananya adalah sebagai berikut:
- Pernyataan masalah informal, pengantar alat yang digunakan: bagaimana dan mengapa.
- Pengujian paralel pada iOS dan bagaimana pengembangannya (khususnya, sesuai dengan sejarah perusahaan kami, sejak kami mulai mengerjakannya pada tahun 2015).
- Server perangkat adalah bagian utama dari laporan. Model baru kami untuk uji paralelisasi.
- Hasil yang kami raih dengan server.
- Jika Anda tidak memiliki 1500 tes, maka Anda mungkin tidak benar-benar membutuhkan server perangkat, tetapi Anda masih bisa mendapatkan hal-hal menarik darinya, dan kami akan membicarakannya. Mereka dapat diterapkan jika Anda memiliki 10-25 tes, dan ini masih akan memberikan akselerasi atau stabilitas tambahan.
- Dan akhirnya, tanya jawab.
Alat-alatnya
Yang pertama adalah sedikit tentang siapa yang menggunakan apa. Tumpukan kami sedikit tidak standar, karena kami menggunakan Calabash dan WebDriverAgent (yang memberi kami kecepatan dan ruang belakang Calabash ketika mengotomatiskan aplikasi kami dan pada saat yang sama akses penuh ke sistem dan aplikasi lain melalui WebDriverAgent). WebDriverAgent adalah implementasi Facebook dari WebDriver untuk iOS yang digunakan secara internal oleh Appium. Dan Calabash adalah server tertanam untuk otomatisasi. Kami menulis tes sendiri dalam bentuk yang dapat dibaca manusia menggunakan Mentimun. Artinya, di perusahaan kami pseudo-BDD. Dan karena kami menggunakan Ketimun dan Calabash, kami mewarisi Ruby, semua kode tertulis di sana. Ada banyak kode, dan Anda harus terus menulis di Ruby. Untuk menjalankan tes secara paralel, kami menggunakan
parallel_cucumber , alat yang ditulis oleh salah satu rekan saya di Badoo.
Mari kita mulai dengan apa yang kita miliki. Ketika saya mulai menyiapkan laporan, ada 1.200 tes. Pada saat mereka selesai, itu 1300. Ketika saya tiba di sini, sudah ada tes 1400. Ini adalah tes end-to-end, bukan tes unit dan tes integrasi. Mereka membuat 35-40 jam waktu komputer di satu simulator. Mereka lewat lebih awal dalam satu setengah jam. Saya akan memberi tahu Anda bagaimana mereka mulai berlalu dalam 30 menit.
Kami memiliki alur kerja di perusahaan kami dengan cabang, ulasan, dan menjalankan tes di cabang-cabang ini. Pengembang membuat sekitar 10 permintaan ke repositori utama aplikasi kami. Tetapi juga memiliki komponen yang dibagi dengan aplikasi lain, jadi kadang-kadang ada lebih dari sepuluh. Hasilnya, setidaknya 30 tes berjalan per hari. Karena pengembang mendorong, maka mereka menyadari bahwa mereka mulai dengan bug, memuat ulang, dan semua ini memulai regresi penuh, hanya karena kita dapat menjalankannya. Pada infrastruktur yang sama, kami meluncurkan proyek tambahan, seperti Liveshot, yang mengambil tangkapan layar aplikasi dalam skrip pengguna utama dalam semua bahasa, sehingga penerjemah dapat memverifikasi kebenaran terjemahan, apakah cocok di layar dan sebagainya. Hasilnya, sekitar satu setengah ribu jam waktu mesin saat ini keluar.
Pertama-tama, kami ingin pengembang dan penguji mempercayai otomatisasi dan mengandalkannya untuk mengurangi regresi manual. Agar hal ini terjadi, perlu untuk mencapai operasi yang cepat dan, yang paling penting, stabil dan dapat diandalkan dari otomatisasi. Jika tes lulus dalam satu setengah jam, pengembang akan bosan menunggu hasilnya, ia akan mulai melakukan tugas lain, fokusnya akan beralih. Dan ketika beberapa tes jatuh, dia akan sangat tidak senang bahwa dia harus kembali, mengalihkan perhatiannya dan memperbaiki sesuatu. Jika tes tidak dapat diandalkan, maka seiring waktu, orang mulai menganggapnya hanya sebagai penghalang. Mereka terus-menerus jatuh, meskipun tidak ada bug dalam kode. Ini adalah tes Flaky, semacam penghalang. Oleh karena itu, dua poin ini telah diungkapkan dalam persyaratan ini:
- Tes harus memakan waktu 30 menit atau lebih cepat.
- Mereka harus stabil.
- Mereka harus dapat diskalakan sehingga kita dapat menambahkan setengah jam untuk menambahkan seratus tes lagi.
- Infrastruktur harus mudah dipelihara dan dikembangkan.
- Pada simulator dan perangkat fisik, semuanya harus dimulai dengan cara yang sama.
Kami terutama menjalankan tes pada simulator, dan bukan pada perangkat fisik, karena lebih cepat, lebih stabil, dan lebih mudah. Perangkat fisik hanya digunakan untuk tes yang benar-benar memerlukan ini. Misalnya, kamera, pemberitahuan push dan sejenisnya.
Bagaimana memenuhi persyaratan ini dan melakukan semuanya dengan baik? Jawabannya sangat sederhana: kami menghapus dua pertiga dari tes! Solusi ini cocok dalam 30 menit (karena hanya sepertiga dari tes yang tersisa), skala mudah (lebih banyak tes dapat dihapus), dan meningkatkan keandalan (karena hal pertama yang kami hapus adalah tes yang paling tidak dapat diandalkan). Itu semua untuk saya. Pertanyaan?
Tapi serius, ada beberapa kebenaran dalam setiap lelucon. Jika Anda memiliki banyak tes, maka Anda perlu memeriksanya dan memahami mana yang membawa manfaat nyata. Kami memiliki tugas yang berbeda, jadi kami memutuskan untuk melihat apa yang bisa dilakukan.
Pendekatan pertama adalah tes penyaringan berdasarkan cakupan atau komponen. Yaitu, pilih tes yang sesuai berdasarkan perubahan file dalam aplikasi. Saya tidak akan membicarakan hal ini, tetapi ini adalah salah satu tugas yang sedang kami selesaikan saat ini.
Pilihan lain adalah mempercepat dan menstabilkan tes itu sendiri. Anda mengikuti tes tertentu, lihat langkah-langkah mana yang paling memakan waktu di dalamnya dan apakah mereka dapat dioptimalkan entah bagaimana. Jika beberapa dari mereka sangat tidak stabil sangat sering, Anda memperbaikinya, karena itu mengurangi tes restart, dan semuanya berjalan lebih cepat.
Dan, akhirnya, tugas yang sama sekali berbeda - memparalelkan tes, mendistribusikannya ke sejumlah besar simulator dan menyediakan infrastruktur yang skalabel dan stabil sehingga ada banyak hal yang dapat diparalelkan.
Pada artikel ini kita akan berbicara terutama tentang dua poin terakhir dan pada akhirnya, dalam tips & trik, kita akan menyentuh titik tentang kecepatan dan stabilisasi.
Pengujian paralel untuk iOS
Mari kita mulai dengan sejarah pengujian paralel untuk iOS secara umum dan Badoo pada khususnya. Untuk memulainya, aritmatika sederhana, di sini, bagaimanapun, ada kesalahan dalam rumus jika kita membandingkan dimensi:
Ada 1.300 tes untuk satu simulator, ternyata 40 jam. Kemudian Satish, pemimpin saya, datang dan mengatakan bahwa dia membutuhkan setengah jam. Anda harus menciptakan sesuatu. X muncul dalam rumus: berapa banyak simulator untuk dijalankan, sehingga semuanya berjalan dalam setengah jam. Jawabannya adalah 80 simulator. Dan segera muncul pertanyaan, di mana harus menempatkan 80 simulator ini, karena mereka tidak cocok di mana saja.
Ada beberapa opsi: Anda dapat pergi ke cloud seperti SauceLabs, Xamarin atau AWS Device Farm. Dan Anda bisa memikirkan semuanya di rumah dan melakukannya dengan baik. Mengingat artikel ini ada, kami melakukan semuanya dengan baik di rumah. Kami memutuskan demikian, karena cloud dengan skala seperti itu akan cukup mahal, dan ada juga situasi ketika iOS 10 keluar dan Appium merilis dukungan untuk itu selama hampir sebulan. Ini berarti bahwa dalam SauceLabs selama sebulan kami tidak dapat secara otomatis menguji iOS 10, yang sama sekali tidak cocok untuk kami. Selain itu, semua awan tertutup, dan Anda tidak dapat memengaruhi mereka.
Jadi, kami memutuskan untuk melakukan semuanya di rumah. Kami memulai suatu tempat di tahun 2015, kemudian Xcode tidak dapat menjalankan lebih dari satu simulator. Ternyata, ia tidak dapat menjalankan lebih dari satu simulator di bawah satu pengguna pada mesin yang sama. Jika Anda memiliki banyak pengguna, maka Anda dapat menjalankan simulator sebanyak yang Anda suka. Rekan saya, Tim Bawerstock, datang dengan model yang kami jalani cukup lama.
Ada agen (TeamCity, Jenkins Node dan sejenisnya), itu menjalankan parallel_cucumber, yang hanya pergi ke mesin jarak jauh melalui ssh. Gambar menunjukkan dua mobil untuk dua pengguna. Semua file yang diperlukan seperti tes disalin dan dijalankan di mesin jarak jauh melalui ssh. Dan tes sudah menjalankan simulator secara lokal di desktop saat ini. Agar ini berfungsi, Anda harus terlebih dahulu pergi ke setiap mesin, membuat, misalnya, 5 pengguna, jika Anda ingin 5 simulator, buat satu pengguna login otomatis, buka berbagi layar untuk yang lain, sehingga mereka selalu memiliki desktop. Dan konfigurasikan daemon ssh sehingga memiliki akses ke proses di desktop. Sedemikian sederhana, kami mulai menjalankan tes secara paralel. Tetapi ada beberapa masalah dalam gambar ini. Pertama, tes mengontrol simulator, mereka berada di tempat yang sama dengan simulator itu sendiri. Artinya, mereka harus selalu dijalankan pada bunga poppy, mereka memakan sumber daya yang bisa dihabiskan untuk menjalankan simulator. Akibatnya, Anda memiliki lebih sedikit simulator pada mesin dan harganya lebih mahal. Poin lain adalah Anda harus pergi ke setiap mesin, mengkonfigurasi pengguna. Dan kemudian Anda tersandung ke dalam global ulimit. Jika ada lima pengguna dan mereka meningkatkan banyak proses, maka pada titik tertentu deskriptor akan berakhir di sistem. Setelah mencapai batas, pengujian akan mulai turun ketika mencoba membuka file baru dan memulai proses baru.
Pada 2016-2017, kami memutuskan untuk beralih ke model yang sedikit berbeda. Kami menyaksikan
laporan oleh Lawrence Lomax dari Facebook - mereka menyajikan fbsimctl, dan sebagian mengatakan bagaimana infrastruktur bekerja di Facebook. Ada juga
laporan oleh Viktor Koronevich tentang model ini. Gambarannya tidak jauh berbeda dari yang sebelumnya - kami baru saja menyingkirkan pengguna, tetapi ini adalah langkah besar ke depan, karena sekarang hanya ada satu desktop, lebih sedikit proses yang diluncurkan, simulator menjadi lebih murah. Ada tiga simulator dalam gambar ini, bukan dua, karena sumber daya telah dibebaskan untuk meluncurkan satu lagi. Kami hidup dengan model ini untuk waktu yang sangat lama, hingga pertengahan Oktober 2017, ketika kami mulai beralih ke server perangkat jarak jauh kami.
Jadi itu terlihat seperti besi. Di sebelah kiri adalah kotak dengan macbook. Mengapa kami menjalankan semua tes pada mereka adalah cerita besar yang terpisah. Menjalankan tes pada macbook yang kami masukkan ke dalam kotak besi bukanlah ide yang baik, karena di suatu sore mereka mulai terlalu panas, karena panasnya tidak keluar dengan baik ketika mereka berada di permukaan. Tes menjadi tidak stabil, terutama ketika simulator mulai mogok saat memuat.
Kami memutuskannya secara sederhana: kami meletakkan laptop “di tenda”, area aliran udara meningkat dan stabilitas infrastruktur tiba-tiba meningkat.
Jadi kadang-kadang Anda tidak harus berurusan dengan perangkat lunak, tetapi berkeliling memutar laptop.
Tetapi jika Anda melihat gambar ini, ada beberapa kabel yang berantakan, adaptor, dan umumnya timah. Ini adalah bagian besi, dan itu masih bagus. Dalam perangkat lunak, jalinan tes lengkap dengan infrastruktur sedang berlangsung, dan tidak mungkin untuk terus hidup seperti itu.
Kami mengidentifikasi masalah berikut:
- Fakta bahwa tes tersebut berkaitan erat dengan infrastruktur, meluncurkan simulator dan mengelola seluruh siklus hidup mereka.
- Ini membuat penskalaan menjadi sulit, karena menambahkan simpul baru tersirat pengaturannya untuk kedua tes dan menjalankan simulator. Misalnya, jika Anda ingin memperbarui Xcode, Anda harus menambahkan solusi langsung ke tes, karena mereka berjalan di berbagai versi Xcode. Beberapa jika tumpukan muncul untuk menjalankan simulator.
- Tes diikat ke mesin tempat simulator berada, dan ini membutuhkan biaya yang sangat besar, karena harus dijalankan dengan bunga poppy alih-alih * nix, yang lebih murah.
- Dan itu selalu sangat mudah untuk mempelajari simulator. Dalam beberapa tes, kami pergi ke sistem file simulator, menghapus beberapa file di sana atau mengubahnya, dan semuanya baik-baik saja sampai dilakukan dengan tiga cara berbeda dalam tiga tes yang berbeda, dan kemudian tiba-tiba yang keempat mulai crash jika tidak beruntung untuk memulai setelah mereka bertiga.
- Dan saat terakhir - sumber daya tidak mencari-cari dengan cara apa pun. Misalnya, ada empat agen TeamCity, lima mesin terhubung ke masing-masing, dan tes hanya dapat dijalankan pada lima mesin mereka. Tidak ada sistem manajemen sumber daya terpusat, karena ini, ketika hanya satu tugas datang, itu berjalan di lima mesin, dan semua 15 lainnya menganggur. Karena itu, pembuatan membutuhkan waktu yang sangat lama.
Model baru
Kami memutuskan untuk beralih ke model baru yang indah.
Menghapus semua tes pada satu mesin, di mana agen TeamCity. Mesin ini sekarang dapat di * nix atau bahkan di Windows jika diinginkan. Mereka akan berkomunikasi melalui HTTP dengan beberapa hal yang kami sebut server perangkat. Semua simulator dan perangkat fisik akan ditempatkan di suatu tempat di sana, dan tes akan berjalan di sini, meminta perangkat melalui HTTP dan terus bekerja dengannya. Diagram ini sangat sederhana, hanya ada dua elemen dalam diagram.
Pada kenyataannya, tentu saja, ssh dan banyak lagi tetap berada di belakang server. Tapi sekarang tidak mengganggu siapa pun, karena orang-orang yang menulis tes berada di bagian atas dalam diagram ini, dan mereka memiliki beberapa jenis antarmuka khusus untuk bekerja dengan simulator lokal atau jarak jauh, sehingga semuanya baik-baik saja. Dan sekarang saya bekerja di bawah, dan saya memiliki segalanya seperti sebelumnya. Kita harus hidup dengannya.
Apa yang diberikannya?
- Pertama, pembagian tanggung jawab. Pada titik tertentu dalam pengujian otomatisasi, Anda harus menganggapnya sebagai perkembangan normal. Ini menggunakan prinsip dan pendekatan yang sama yang digunakan pengembang.
- Hasilnya adalah antarmuka yang sangat jelas: Anda tidak dapat langsung melakukan sesuatu dengan simulator, untuk ini Anda perlu membuka tiket di server perangkat, dan kami akan mencari tahu bagaimana melakukan ini secara optimal tanpa melanggar tes lain.
- Lingkungan pengujian menjadi lebih murah karena kami menaikkannya dalam * nix, yang jauh lebih murah daripada bunga poppy layanan.
- Dan pembagian sumber daya muncul, karena ada satu lapisan yang digunakan semua orang untuk berkomunikasi, ia dapat merencanakan distribusi mesin yang terletak di belakangnya, yaitu. berbagi sumber daya antar agen.
Di atas digambarkan, seperti sebelumnya. Di sebelah kiri adalah satuan waktu konvensional, katakanlah, puluhan menit. Ada dua agen, 7 simulator terhubung ke masing-masing, pada saat 0 build masuk dan membutuhkan waktu 40 menit. Setelah 20 menit, yang lain tiba, dan membutuhkan waktu yang sama. Segalanya tampak hebat. Tapi di sana, dan ada kotak abu-abu. Itu berarti bahwa kami kehilangan uang karena kami tidak menggunakan sumber daya yang tersedia.
Anda dapat melakukan ini: build pertama datang dan melihat semua simulator gratis, didistribusikan, dan tes dipercepat dua kali. Tidak ada yang bisa dilakukan. Pada kenyataannya, ini sering terjadi karena pengembang jarang mendorong brunch mereka pada saat yang sama. Meskipun kadang-kadang ini terjadi, dan "catur", "piramida" dan sejenisnya dimulai. Namun, dalam kebanyakan kasus, akselerasi gratis dua kali dapat diperoleh dengan hanya menginstal sistem manajemen terpusat untuk semua sumber daya.
Alasan lain untuk beralih ke ini:
- Tinju hitam, yaitu, sekarang server perangkat adalah kotak hitam. Ketika Anda menulis tes, Anda hanya memikirkan tes dan berpikir bahwa kotak hitam ini akan selalu berfungsi. Jika tidak berhasil, Anda hanya pergi dan mengetuk siapa pun yang harus melakukannya, yaitu saya. Dan saya harus memperbaikinya. Bukan hanya saya, pada kenyataannya, beberapa orang terlibat dalam seluruh infrastruktur.
- Anda tidak dapat merusak bagian dalam simulator.
- Anda tidak harus meletakkan jutaan utilitas pada mesin untuk memulai semuanya - Anda hanya menempatkan satu utilitas yang menyembunyikan semua pekerjaan di server perangkat.
- Menjadi lebih mudah untuk memperbarui infrastruktur, yang akan kita bicarakan di suatu tempat pada akhirnya.
Sebuah pertanyaan yang masuk akal: mengapa tidak Selenium Grid? Pertama, kami memiliki banyak kode lawas, 1.500 tes, 130 ribu baris kode untuk platform yang berbeda. Dan semua ini dikendalikan oleh parallel_cucumber, yang menciptakan siklus hidup simulator di luar tes. Yaitu, ada sistem khusus yang memuat simulator, menunggu untuk siap dan memberikannya untuk ujian. Agar tidak menulis ulang semuanya, kami memutuskan untuk mencoba untuk tidak menggunakan Selenium Grid.
Kami juga memiliki banyak tindakan non-standar, dan kami sangat jarang menggunakan WebDriver. Bagian utama tes pada Calabash, dan WebDriver hanya tambahan. Selenium .
, , , , . , , , , . , Ruby, device server Kotlin. Ruby, Kotlin.
Device server
device server, . , :
- xcrun simctl fbsimctl — ( Apple, Facebook, )
- WebDriverAgent, Facebook, , push- -
- ideviceinstaller, - .
, device server, . , fbsimctl , xcrun simctl ideviceinstaller, , fbsimctl WebDriverAgent. - . : - , Facebook . , fbsimctl . :
, .
, .
? , curl list, :
JSON, , . , .
, approve — , . open deep links . , , fbsimctl. , :
, . - . : . , , .
- — . liveshot' iPhone X, iPhone 5S, iPhone 6s. .
- - WebDriverAgent XCUI- , .
- . - iOS 8 , , . device server iOS 8, , , - . fbsimctl.
- , cookies , , , .
- — . , device server , , , , . , . , .
, - , . — , . — , , , .
: Test Runner, ; Device Provider, Device Server, ; Remote Device — ; Device Server — -. , - - fbsimctl WebDriverAgent.
? Test Runner capability, iPhone 6. Device Provider, device server, , - , , , . Device Server . RemoteDevice .
, fbsimctl. , , headless-. , , headless-. - , . , , , syslog SpringBoard .
, XCTest, WebDriverAgent, healthCheck, WebDriverAgent , . , «ready» . healthCheck. , .
fbsimctl. . , WebDriverAgent, . .
— , device server, , , . (release), , , . . , device server , Test Runner . , -, , - .
— . . 30 60. , . , 30 . : , ?
. — . , .
. , , . Separation of Concerns — , , .
. , , Xcode 9, . Xcode 9.2, , — . , - .
Test Runner, rsync, ssh . - *nix, Docker-.
: device server
( GitHub ) , ssh, . device server, ssh, .
Tips & tricks
Sekarang yang paling penting adalah segala macam trik dan hanya hal-hal berguna yang kami temukan saat membuat server perangkat dan infrastruktur ini.
Yang pertama adalah yang paling sederhana. Seperti yang Anda ingat, kami memiliki MacBook Pro, semua tes dijalankan pada laptop. Sekarang kami meluncurkannya di Mac Pro.
Berikut ini dua konfigurasi. Ini sebenarnya adalah versi teratas dari masing-masing perangkat. Di MacBook, kami bisa menjalankan 6 simulator secara paralel. Jika Anda mencoba memuat lebih banyak pada saat yang sama, simulator mulai gagal karena fakta bahwa mereka memuat prosesor banyak, mereka memiliki kunci timbal balik dan sebagainya. Anda dapat menjalankan 18 di Mac Pro - sangat mudah untuk menghitung, karena alih-alih 4 ada 12 core. Kami kalikan tiga - Anda mendapatkan sekitar 18 simulator. Faktanya, Anda dapat mencoba berlari sedikit lebih banyak, tetapi mereka entah bagaimana harus dipisahkan dalam waktu, Anda tidak dapat, misalnya, berlari dalam satu menit. Meskipun akan ada trik dengan 18 simulator ini, itu tidak begitu sederhana.
Dan ini harga mereka. Saya tidak ingat berapa harganya dalam rubel, tetapi jelas harganya sangat mahal. Biaya setiap simulator untuk MacBook Pro harganya hampir £ 400, dan untuk Mac Pro hampir £ 330. Ini sudah sekitar £ 70 penghematan pada setiap simulator.
Selain itu, macbook ini harus dipasang dengan cara tertentu, mereka harus mengisi daya pada magnet, yang harus direkatkan ke tape, karena kadang-kadang jatuh. Dan Anda harus membeli adaptor untuk menghubungkan Ethernet, karena begitu banyak perangkat di dekat kotak besi di Wi-Fi sebenarnya tidak berfungsi, itu menjadi tidak stabil. Adaptor juga berharga sekitar £ 30, ketika Anda membaginya dengan 6, maka Anda akan mendapatkan £ 5 untuk setiap perangkat. Tetapi, jika Anda tidak memerlukan super-paralelisasi ini, Anda hanya memiliki 20 tes dan 5 simulator, sebenarnya lebih mudah untuk membeli MacBook, karena Anda dapat menemukannya di toko mana pun, dan Anda harus memesan dan menunggu Mac Pro top-end. Omong-omong, harganya sedikit lebih murah, karena kami mengambilnya dalam jumlah besar dan ada semacam diskon. Anda juga dapat membeli Mac Pro dengan memori kecil, dan kemudian tingkatkan diri Anda, lebih hemat.
Tetapi dengan Mac Pro ada satu trik. Kami harus memecah mereka menjadi tiga mesin virtual, menempatkan ESXi di sana. Ini adalah virtualisasi bare metal, yaitu hypervisor yang dipasang pada mesin kosong, dan bukan pada sistem host. Dia adalah tuan rumahnya sendiri, jadi kita bisa menjalankan tiga mesin virtual. Dan jika Anda menginstal semacam virtualisasi normal pada macOS, misalnya Parallels, maka Anda hanya akan dapat menjalankan 2 mesin virtual karena batasan lisensi Apple. Saya harus memecahnya karena CoreSimulator, layanan utama yang mengelola simulator, ternyata memiliki kunci internal, dan pada saat yang sama lebih dari 6 simulator tidak dimuat, mereka mulai menunggu sesuatu dalam antrian, dan waktu muat total 18 simulator menjadi tidak dapat diterima. Ngomong-ngomong, ESXi harganya £ 0, selalu menyenangkan ketika sesuatu tidak bernilai apa-apa, tetapi berfungsi dengan baik.
Kenapa kita tidak melakukan pooling? Sebagian karena kami mempercepat reset simulator. Misalkan tes macet, Anda ingin benar-benar membersihkan simulator sehingga yang berikutnya tidak macet karena sisa file tidak jelas dalam sistem file. Solusi paling sederhana adalah dengan mematikan simulator, hapus secara eksplisit (hapus) dan boot (boot).
Sangat sederhana, satu baris, tetapi membutuhkan 18 detik. Dan enam bulan atau setahun yang lalu, butuh hampir satu menit. Terima kasih kepada Apple untuk mengoptimalkan ini, tetapi Anda bisa melakukannya lebih sulit. Unduh simulator dan salin direktori kerjanya ke folder cadangan. Dan kemudian Anda mematikan simulator, menghapus direktori kerja dan menyalin cadangan, mulai simulator.
Ternyata 8 detik: unduhan dipercepat lebih dari dua kali. Pada saat yang sama, tidak ada yang rumit yang harus dilakukan, yaitu, dalam Ruby-code dibutuhkan dua baris. Dalam gambar saya memberikan contoh pada bash sehingga dapat dengan mudah diterjemahkan ke bahasa lain.
Trik selanjutnya. Ada aplikasi Bumble, mirip dengan Badoo, tetapi dengan konsep yang sedikit berbeda, jauh lebih menarik. Di sana Anda harus masuk melalui Facebook. Dalam semua pengujian kami, karena kami menggunakan pengguna baru dari kumpulan setiap kali, kami harus keluar dari yang sebelumnya. Untuk melakukan ini, menggunakan WebDriverAgent, kami membuka Safari, pergi ke Facebook, klik Keluar. Tampaknya bagus, tetapi dibutuhkan hampir satu menit dalam setiap tes. Seratus tes. Seratus menit ekstra.
Selain itu, Facebook terkadang suka melakukan tes A / B, sehingga mereka dapat mengubah pencari, teks pada tombol. Tiba-tiba, banyak tes akan jatuh, dan semua orang akan sangat tidak bahagia. Oleh karena itu, melalui fbsimctl kami membuat list_apps, yang menemukan semua aplikasi.
Temukan MobileSafari:
Dan ada jalur ke DataContainer, dan memiliki file biner dengan cookie:
Kami hanya menghapusnya - dibutuhkan 20 ms. Tes mulai berlalu 100 menit lebih cepat, menjadi lebih stabil, karena mereka tidak dapat jatuh karena Facebook. Jadi paralelisasi terkadang tidak diperlukan. Anda dapat menemukan tempat untuk optimasi, mudah dikurangi 100 menit, tidak ada yang perlu dilakukan. Dalam kode, ini adalah dua baris.
Berikutnya: bagaimana kita menyiapkan mesin host untuk menjalankan simulator.
Dengan contoh pertama, banyak yang meluncurkan Appium sudah terbiasa dengan menonaktifkan keyboard keras. Simulator memiliki kebiasaan menghubungkan keyboard perangkat keras pada komputer saat memasukkan teks dalam simulator, dan benar-benar menyembunyikan yang virtual. Dan Appium menggunakan keyboard virtual untuk memasukkan teks. Oleh karena itu, setelah debug uji input lokal, tes lain mungkin mulai gagal karena kurangnya keyboard. Dengan perintah ini Anda dapat menonaktifkan keyboard keras, dan kami melakukan ini sebelum mengangkat setiap test node.
Paragraf berikutnya lebih relevan bagi kita, karena aplikasi tersebut terkait dengan geolokasi. Dan sangat sering Anda perlu menjalankan tes sehingga awalnya dinonaktifkan. Anda dapat mengatur 3101 di LocationMode. Mengapa demikian? Dulu ada artikel dalam dokumentasi Apple, tetapi kemudian mereka menghapusnya karena suatu alasan. Sekarang ini hanya konstanta ajaib dalam kode yang kita semua doakan dan harap tidak rusak. Karena begitu rusak, semua pengguna akan berada di San Francisco, karena fbsimctl menempatkan lokasi seperti itu saat memuat. Di sisi lain, kita akan dengan mudah mengetahuinya, karena semua orang akan berada di San Francisco.
Yang berikutnya adalah menonaktifkan Chrome, bingkai di sekitar simulator yang memiliki berbagai tombol. Saat menjalankan autotest, itu tidak diperlukan. Sebelumnya, mematikannya memungkinkan Anda menempatkan lebih banyak simulator dari kiri ke kanan untuk melihat bagaimana semuanya berjalan secara paralel. Sekarang kami tidak melakukan itu, karena semuanya tanpa kepala. Berapa banyak yang tidak masuk ke dalam mobil, simulator itu sendiri tidak akan terlihat. Jika ini diperlukan, maka Anda dapat melakukan streaming dari simulator yang diinginkan.
Ada juga serangkaian opsi berbeda yang dapat Anda nyalakan / matikan. Dari jumlah tersebut, saya hanya akan menyebutkan SlowMotionAnimation, karena saya memiliki hari kedua atau ketiga yang sangat menarik di tempat kerja. Saya menjalankan tes, dan semuanya mulai jatuh dalam batas waktu. Mereka tidak menemukan unsur-unsur di inspektur, meskipun dia. Ternyata saat itu saya memulai Chrome, menekan cmd + T untuk membuka tab baru. Pada titik ini, simulator menjadi aktif dan mencegat tim. Dan baginya, cmd + T adalah perlambatan dari semua animasi sebanyak 10 kali untuk men-debug animasi. Opsi ini juga harus selalu dimatikan secara otomatis jika Anda ingin menjalankan tes pada mesin yang dapat diakses orang, karena mereka dapat secara tidak sengaja memecahkan tes dengan memperlambat animasi.
Mungkin hal yang paling menarik bagi saya, karena saya melakukan ini belum lama ini, adalah pengelolaan semua infrastruktur ini. 60 host virtual (sebenarnya 64 + 6 agen TeamCity) tidak ada yang mau secara manual diluncurkan. Kami menemukan utilitas
xcversion - sekarang ini adalah bagian dari fastlane, permata Ruby yang dapat digunakan sebagai utilitas baris perintah: sebagian mengotomatiskan instalasi Xcode. Kemudian kami mengambil Ansible, menulis buku pedoman, untuk menggulung fbsimctl di mana-mana dari versi yang diinginkan, Xcode dan menyebarkan konfigurasi untuk server perangkat itu sendiri. Dan memungkinkan untuk menghapus dan memperbarui simulator. Ketika kami beralih ke iOS 11, kami meninggalkan iOS 10. Tetapi ketika tim pengujian mengatakan bahwa itu sepenuhnya meninggalkan pengujian otomatis pada iOS 10, kami hanya perlu melalui Ansible dan membersihkan simulator yang lama. Kalau tidak, mereka mengambil banyak ruang disk.
Bagaimana cara kerjanya? Jika Anda hanya mengambil xcversion dan menyebutnya di masing-masing dari 60 mesin, itu akan memakan banyak waktu, karena masuk ke situs web Apple dan mengunduh semua gambar. Untuk memperbarui mesin yang ada di taman, Anda harus memilih satu mesin yang berfungsi, jalankan instalasi xcversion di atasnya dengan versi Xcode yang diperlukan, tetapi jangan menginstal apa pun atau menghapus apa pun. Paket instalasi akan diunduh ke cache. Hal yang sama dapat dilakukan untuk semua versi simulator. Paket instalasi ditempatkan di ~ / Library / Caches / XcodeInstall. Kemudian Anda memuat semuanya dengan Ceph, dan jika tidak ada, mulai beberapa jenis server web dalam direktori ini. Saya sudah terbiasa dengan Python, jadi saya menjalankan server Python Python pada mesin.
Sekarang, pada mesin pengembang atau penguji lainnya, Anda dapat menginstal xcversion dan menentukan tautan ke server yang terangkat. Ini akan mengunduh xip dari mesin yang ditentukan (jika jaringan area lokal cepat, maka ini akan terjadi hampir secara instan), membongkar paket, mengkonfirmasi lisensi - secara umum, itu akan melakukan segalanya untuk Anda. Akan ada Xcode yang berfungsi penuh di mana dimungkinkan untuk menjalankan simulator dan tes. Sayangnya, kami tidak melakukannya dengan nyaman dengan simulator, jadi Anda harus melakukan curl atau wget, unduh paket dari server itu ke mesin lokal Anda di direktori yang sama, jalankan xcversion simulator - install. Kami menempatkan panggilan ini di dalam skrip Ansible dan memperbarui 60 mesin dalam sehari. Waktu utama diambil dengan menyalin file jaringan. Selain itu, kami bergerak pada saat itu, yaitu, beberapa mobil dimatikan. Kami memulai kembali Kemungkinan dua atau tiga kali untuk mengejar ketinggalan dengan mobil yang tidak ada selama perjalanan.
Sedikit tanya jawab. Pada bagian pertama: menurut saya prioritas itu penting. Artinya, pertama-tama Anda harus memiliki stabilitas dan keandalan tes, dan kemudian kecepatan. Jika Anda hanya mengejar kecepatan, mulai memparalelkan semuanya, maka tes akan bekerja dengan cepat, tetapi tidak ada yang akan melihatnya, mereka hanya akan memulai kembali semuanya sampai semuanya tiba-tiba berlalu. Atau bahkan skor pada tes dan dorong ke master.
Poin berikutnya: otomatisasi adalah pengembangan yang sama, jadi Anda bisa mengambil pola yang sudah Anda pikirkan untuk kami dan menggunakannya. Jika sekarang infrastruktur Anda terhubung erat dengan tes dan penskalaan direncanakan, maka ini adalah saat yang tepat untuk membagi dulu, dan kemudian untuk skala.
Dan poin terakhir: jika tugasnya adalah mempercepat tes, maka hal pertama yang terlintas dalam pikiran adalah menambahkan lebih banyak simulator untuk membuatnya lebih cepat oleh beberapa faktor. Bahkan, sangat sering Anda tidak perlu menambahkan, tetapi hati-hati menganalisis kode dan mengoptimalkan semuanya dengan beberapa baris, seperti dalam contoh dengan cookie. Ini lebih baik daripada paralelisasi, karena 100 menit disimpan dengan dua baris kode, dan untuk paralelisasi Anda harus menulis banyak kode dan kemudian mendukung bagian besi dari infrastruktur. Untuk uang dan sumber daya, biayanya lebih mahal.
Mereka yang tertarik dengan laporan ini dari konferensi Heisenbug mungkin juga tertarik dengan Heisenbug berikut: akan diadakan di Moskow pada 6-7 Desember, dan situs web konferensi sudah berisi deskripsi sejumlah laporan (dan, omong-omong, penerimaan aplikasi untuk laporan masih terbuka).