Saat ini, ketika setiap penduduk megalopolis memiliki komputer di sakunya yang dapat melakukan lebih dari terbang ke bulan , kami menggunakan aplikasi seluler setiap hari. Berita, cuaca, promosi, belanja - semua fungsi ini diimplementasikan dalam ratusan ribu aplikasi. Tetapi jika aplikasi favorit Anda macet atau mogok, itu dengan cepat berhenti menjadi favorit Anda.
Artikel ini ditulis oleh orang-orang dari
WaveAccess.Kami telah mengembangkan aplikasi seluler selama lebih dari 10 tahun, dan kami tidak mampu merilis produk yang ada di tangan pengguna. Itulah mengapa “memompa” tim penguji dan infrastruktur tidak kalah penting bagi kami daripada bidang lainnya.
Ratusan perangkat Android, iPhone dengan versi OS yang berbeda, dan perangkat diagonal yang berbeda membuat para insinyur QA bertugas untuk “menangkap” cacat pada perangkat seluler nyata dan pada versi sistem operasi yang berbeda. Tetapi hanya sedikit orang yang dapat menjalankan skrip manual yang sama pada 10, 20, 50 perangkat. Berkat tugas seperti itu, kami memompa keterampilan pengujian otomatis kami, terutama pada perangkat seluler. Tapi mari kita jujur: membuat dan memelihara infrastruktur bahkan dengan 20 perangkat nyata untuk menjalankan autotest adalah sakit kepala.
Dalam artikel ini kami ingin memberi tahu kami bagaimana kami mencoba layanan Microsoft App Center baru untuk memeriksa kualitas aplikasi yang kami kembangkan di kebun binatang perangkat nyata.
Mengapa timbul pertanyaan tentang menggunakan layanan ini
Sekarang kami sedang mengembangkan aplikasi untuk mendukung belanja. Proyek ini telah berlangsung lama: pelanggan terus-menerus menawarkan beberapa fitur baru, dia akan mengembangkan hanya untuk kita. Sudah ada puluhan layar dalam aplikasi, dari "membeli" ke berbagai opsi pesan, mendorong, "mengumpulkan busur Anda" fungsi. Dan selama ini, presentasi proyek kepada investor, diluncurkan di pusat perbelanjaan baru, berlangsung, sehingga semakin tinggi kecepatan rilis (tanpa penurunan kualitas produk) - semakin baik.
Sampai sekarang, kami menjalankan autotest pada sejumlah perangkat yang kami miliki (untuk proyek ini - sekitar 30 perangkat Android dan "apel"). Sekarang aplikasinya mencapai level baru, audiens telah berkembang, dan kualitasnya menjadi semakin kritis. Muncul pertanyaan tentang penggunaan layanan cloud untuk menjalankan autotes pada perangkat yang berbeda.
Dalam proses rilis, saya ingin menggunakan semua praktik pengembangan perangkat lunak yang modern dan terbukti: peninjauan silang, integrasi berkesinambungan, pengujian fungsional dan unit otomatis pada daftar besar perangkat di iOS + Android, kumpulan analitik dan crashlytics.
Kami telah menerapkan masing-masing praktik ini sebelumnya, baik secara individu maupun dalam kombinasi. Tetapi mengingat skala proyek dan ukuran besar tim, saya ingin mendapatkan solusi universal. Biarkan alat dapat melakukan semua hal di atas dan di satu tempat dapat memberikan kesempatan untuk mengelola keadaan pengembangan dan pengiriman aplikasi seluler untuk berbagai platform dan memantaunya.
Setiap peran dalam tim memiliki kondisi masing-masing: pengembang tidak ingin mengubah proses pengembangan yang sudah ada (repositori, alat pembangunan, dll.), Serta beralih ke alat yang terlalu baru dan tidak terverifikasi dalam produk. Para insinyur penguji bermimpi untuk mengurangi beban alat pengecekan di kebun binatang, para manajer dan pelanggan menginginkan antarmuka yang nyaman untuk memantau seluruh negara bagian dengan aliran transparan.
Studi analog adalah tahap yang agak penting dalam memilih alat. Kami melihat berbagai layanan yang menyediakan kemampuan seperti itu (untuk pengujian Appium, misalnya, BrowserStack). Dalam hal Microsoft App Center, kami diberi masa percobaan, jadi kami memiliki kesempatan untuk mencoba dan memahami apa yang akan terjadi pada proyek jika kami mencurahkan lebih banyak sumber daya untuk kualitas dan mengotomatiskan seluruh proses rilis aplikasi mobile untuk platform apa pun dengan satu layanan. Kami katakan bagaimana itu.
Cara mengatur aplikasi iOS
Jadi, menggunakan periode uji coba, yang tidak memberlakukan pembatasan pada fungsi, kami membuat aplikasi iOS kami di Microsoft App Center:
Pilih platform:
Tambahkan App Center SDK ke proyek:
pod 'AppCenter'
Setelah menginstal perapian, buka file AppDelegate.swift dan tambahkan baris berikut di bawah perintah impor Anda sendiri:
import AppCenter import AppCenterAnalytics import AppCenterCrashes
Dalam file yang sama, tambahkan baris berikut ke metode didFinishLaunchingWithOptions:
MSAppCenter.start("{Your App Secret}", withServices:[ MSAnalytics.self, MSCrashes.self ])
Proses serupa adalah untuk tujuan C, versi lengkap dari instruksi ada di sini .
Bangun!
Buka tab Bangun, pilih layanan SVC kami.
Konfigurasikan pembuatan. Jangan lupa untuk masuk, karena ini membuat kami file aplikasi format aplikasi yang dapat dijalankan di perangkat nyata:
Selesai! Klik tombol Bangun sekarang dan tunggu build.
Kisah serupa untuk aplikasi Android, instruksinya ada di sini .
Kami meluncurkan tes pertama untuk iOS
Tes unit dan asli untuk setiap platform dapat dimasukkan dalam perakitan (ada tanda centang). Kami memberi tahu tentang fungsionalitas AT pada perangkat yang berbeda di bawah ini.
Siapkan satu set iOS, perangkat Android, mengirimkan tes ke perangkat
Buka tab Test, Device Sets. Kami membuat satu set perangkat di mana kami akan mengarahkan pengujian kami. Ada lebih dari 250 perangkat Android untuk dipilih dan lebih dari 200 perangkat iOS yang berbeda (versi generasi + versi iOS). Daftar perangkat terperinci ada di sini .
Di sini agak mengecewakan bahwa jawaban resmi untuk pertanyaan, seberapa cepat setelah rilis akan muncul perangkat Apple baru, terdengar seperti "1-2 bulan setelah penjualan".
Kami menyiapkan tes untuk peluncuran di App Center (contoh untuk XCUITest) dan mengirimkannya untuk peluncuran. App Center memiliki kemampuan untuk membangun hanya aplikasi, jadi Anda masih harus membangun proyek uji secara lokal di mesin Anda atau di CI Anda.
Shell: # Generate an XCUITest bundle and your iOS application as described above. $ rm -rf DerivedData $ xcrun xcodebuild build-for-testing -derivedDataPath DerivedData -scheme YOUR_APP_SCHEME # Upload your test to App Center $ appcenter test run xcuitest \ --app "<app center username/<app name>" \ --devices DEVICE_SET \ --test-series "master" \ --locale "en_US" \ --build-dir DerivedData/Build/Products/Debug-iphoneos
Tes Appium
Perlu memastikan bahwa kerangka uji yang digunakan konsisten dengan yang didukung. Selain itu, Anda harus menggunakan driver yang disediakan oleh App Center, dan ini memberlakukan batasannya pada penggunaan kerangka kerja (misalnya, Google Giuce tidak dapat digunakan).
Membangun Proyek untuk Pengguna Maven
Langkah 1. Tambahkan repositori dan dependensi
Anda perlu menambahkan repositori JCenter ke file pom.xml.
XML <repositories> <repository> <id>jcenter</id> <url>https://jcenter.bintray.com/</url> </repository> </repositories>
Kemudian tambahkan ketergantungan untuk ekstensi tes Appium
XML <dependency> <groupId>com.microsoft.appcenter</groupId> <artifactId>appium-test-extension</artifactId> <version>1.3</version> </dependency>
Jadi, selama kompilasi, driver Android dan iOS yang diperluas akan tersedia (yang diperlukan, pertama-tama, untuk mengimplementasikan fitur "label"; lebih lanjut tentang ini di Langkah 4).
Langkah 2. Tambahkan profil boot
Salin cuplikan ke pom.xml Anda di <profil>. Jika bagian <profil> tidak ada dalam file pom, Anda harus membuatnya. Setelah aktivasi, profil mengemas kelas pengujian kami dan semua dependensi ke folder target / unggah, siap untuk diunggah ke TestCloud.
Bangun untuk Pengguna Gradle
Langkah 1. Repositori dan dependensi
Kami memastikan bahwa dalam build.gradle di folder root proyek repositori JCenter diaktifkan:
gradle allprojects { repositories { jcenter() } }
Tambahkan snippet berikut ke build.gradle di folder aplikasi:
gradle androidTestCompile('com.microsoft.appcenter:appium-test-extension:1.0')
Dimulai dengan Gradle 3.0, androidTestCompile sudah tidak digunakan lagi . Alih-alih, Anda membutuhkan androidTestImplementation.
Langkah 2. Otomatis pembuatan file pom
Agar pengunggah berfungsi, file pom.xml diperlukan. Tambahkan potongan berikut di build.gradle di folder aplikasi sehingga file pom dikumpulkan secara otomatis:
gradle apply plugin: 'maven' task createPom { pom { withXml { def dependenciesNode = asNode().appendNode('dependencies') //Iterate over the compile dependencies (we don't want the test ones), adding a <dependency> node for each configurations.testCompile.allDependencies.each { def dependencyNode = dependenciesNode.appendNode('dependency') dependencyNode.appendNode('groupId', it.group) dependencyNode.appendNode('artifactId', it.name) dependencyNode.appendNode('version', it.version) } def profilesNode = asNode().appendNode('profiles') profilesNode.append(new XmlParser().parse('https://raw.githubusercontent.com/Microsoft/AppCenter-Test-Appium-Java-Extensions/master/gradleuploadprofilesnippet.xml')) } }.writeTo("pom.xml")
Tes berubah
Langkah 1. Tambahkan Impor
Impor paket ke kelas tes Anda:
Java import com.microsoft.appcenter.appium.Factory; import com.microsoft.appcenter.appium.EnhancedAndroidDriver; import org.junit.rules.TestWatcher; import org.junit.Rule;
Langkah 2. Buat instance dari TestWatcher
Tambahkan ke setiap kelas uji JUnit Rule (atau kelas tes dasar):
Java @Rule public TestWatcher watcher = Factory.createWatcher();
Langkah 3. Ubah jenis driver
Ubah jenis driver ketika dideklarasikan, baik dari AndroidDriver <MobileElement> ke EnhancedAndroidDriver <MobileElement>, atau dari IOSDriver <MobileElement> menjadi EnhancedIOSDriver <MobileElement>
Java private static EnhancedAndroidDriver<MobileElement> driver;
Langkah 4. Memperbarui instans driver
Kami mengubah instance driver sehingga garis-garis bentuk:
Java driver = new AndroidDriver<MobileElement>(url, capabilities);
... berubah penampilan:
Java driver = Factory.createAndroidDriver(url, capabilities);
Menggunakan driver ini masih akan memungkinkan Anda untuk menjalankan tes secara lokal tanpa modifikasi tambahan, tetapi juga akan memungkinkan Anda untuk menambahkan "label" ke langkah-langkah dalam tes yang dapat dieksekusi menggunakan driver.label ("teks Anda"). Teks dan tangkapan layar dari perangkat akan tersedia dalam laporan pengujian di Test Cloud. Sangat disarankan agar Anda mengakses label melalui metode Setelah , karena ini akan menambahkan tangkapan layar status terakhir aplikasi ke laporan pengujian.
Tangkapan layar akan diambil bahkan jika pengujian gagal. Sebagai aturan, ada cukup informasi di dalamnya untuk memahami mengapa ini terjadi. Contoh implementasi dalam metode Setelah :
Java: @After public void TearDown(){ driver.label("Stopping App"); driver.quit(); }
Unduh ke uji App Center
Proses memuat adalah sebagai berikut:
- Hasilkan perintah unggahan Tes App Center. Dokumentasi (EN) - memulai uji coba .
- Kami mengemas kelas pengujian dan semua dependensi di folder target / unggah
kulit:
- mvn -DskipTests -P persiapkan-untuk-unggah paket
- Mengunduh dan menjalankan tes dimulai
Setelah selesai, kami dapat melihat hasil pada setiap perangkat dari daftar:
Layar dengan hasil, log, laporan
Di setiap perangkat iOS atau Android, Anda dapat melihat log terperinci dan tangkapan layar untuk mendiagnosis crash pengujian:
Serta statistik dari semua peluncuran selama interval waktu:
Benar, akses ke "perangkat" untuk debug dan inspeksi tidak disediakan. Jika ada yang salah dengan tes dan log tidak cukup - semuanya diputuskan hanya melalui dukungan. Dalam salah satu layanan populer untuk meluncurkan AT pada perangkat - BrowserStack - ada peluang seperti itu, dan itu dibangun ke Appium. Seseorang dapat memberikan URL dan port untuk membuat koneksi ke server perangkat.
Kesimpulan
Anehnya, seluruh proses rilis dari Continuous Integration ke Continuous Delivery aplikasi disediakan di satu tempat: Microsoft App Center menawarkan CI build, test, deploy to store, analytics, crashlytics.
Setelah mencoba kurang dari setengah fungsi yang diusulkan, tim membuat kesan yang baik. Dari nilai tambah yang jelas: Anda tidak perlu menulis dukungan untuk setiap perangkat dalam bentuk kode. Nah, barang lainnya tolong:
- Tidak perlu menaikkan server untuk kerumunan perangkat.
- Tidak perlu menghubungkan 100.500 perangkat ke server ini.
- Tidak perlu hidup dengan gangguan Android saat dihidupkan 24 \ 7.
- Tidak perlu merakit wadah untuk perangkat, tidak perlu mengelola wadah ini.
- Tidak perlu tahan dengan emulator terbatas.
Microsoft App Center mengatur kami sesuai dengan parameter awal: ia tidak terlalu menuntut dalam hal integrasi, tetapi ia menyediakan semua fungsi yang diminta, menghilangkan dukungan yang sulit. Kami berencana untuk menggunakan layanan pada proyek, karena ia menyelesaikan tugas alat sambil memastikan kualitas.