🍞 👩‍⚖️ ☝🏼 Menguji Aplikasi Flutter: Alat, Manfaat, Tantangan 🥃 👂🏼 🤶🏼

Halo! Nama saya Maria Leshchinskaya, saya spesialis QA di Surf. Perusahaan kami telah mengembangkan aplikasi asli sejak 2011, dan sejak 2018 kami juga mengembangkan aplikasi Flutter.

Pada artikel ini, kami akan membandingkan kemampuan pengujian aplikasi asli dan lintas platform. Saya akan membagikan kesan saya bekerja dengan Flutter dan memberi tahu Anda alat apa yang kami gunakan di Surf saat menguji, mengapa Flutter nyaman dan masalah apa yang kami temui.

Kemampuan pengujian di Flutter setara dengan yang asli

Ketika perusahaan mengubah pendekatannya terhadap pengembangan atau teknologi baru muncul, penting bahwa kemampuan pengujian tidak terlalu terpengaruh. Idealnya, saat bekerja dengan bahasa atau kerangka kerja baru, spesialis QA terus menggunakan kumpulan alat dan teknologi yang telah terbukti dengan cara terbaik.

Saat menguji aplikasi asli, kami di Surf menggunakan tes otomatis dan membaca serta mengganti paket. Tidak ada tempat tanpa tes otomatis, terutama dengan regresi, dan tanpa bantuan proxy, variabilitas aplikasi dan cakupan banyak kasus menurun.

Penting bagi kami bahwa fitur yang sudah dikenal tetap ada saat menguji aplikasi Flutter.

Tes otomatis

Surf bekerja dengan kerangka kerja Calabash dan Ruby untuk menguji aplikasi asli secara otomatis. Saat Flutter muncul, hal pertama yang kami pikirkan adalah: apakah mungkin untuk tidak menggunakan Calabash, tetapi pada saat yang sama bekerja sepenuhnya dengan autotest seperti yang biasa kita lakukan - atau bahkan lebih keren.

Ternyata itu tidak hanya mungkin - tetapi bahkan tanpa layanan pihak ketiga: di Flutter, pengujian integrasi dan pengujian widget di konsol tersedia di luar kotak. Pengembang Flutter kami memberi tahu hal ini secara lebih mendetail di artikel tentang pengujian otomatis di Flutter .

Autotest di Flutter bersifat lintas platform dan native secara bersamaan: Anda dapat menulis pengujian di dalam proyek aplikasi, dan pengujian tersebut akan berfungsi di kedua platform. Ketika keseluruhan proyek ada di depan mata Anda, Anda dapat menambahkan id-schnicks yang hilang atau bahkan menemukan bug dan memperbaikinya - ini adalah kesempatan lain untuk meningkatkan kualitas aplikasi.

Flutter juga mendukung pendekatan Behavior Driven Development - BDD. Kami menggunakannya untuk tes UI. Kami memilih Gherkin sebagai bahasa: Anda dapat menggunakan file fitur di dalamnya, menulis skrip dalam bahasa Inggris dan Rusia. Dapat dimengerti, ia memiliki implementasi langkah-langkah skrip tanpa argumen tambahan di dalamnya atau dengannya, kemampuan untuk menyesuaikan peluncuran tes otomatis: misalnya, menjalankan beberapa skrip berdasarkan tag, dan tidak semua tes tertulis secara keseluruhan.

Untuk menggunakan Gherkin saat menguji aplikasi Flutter, kami menghubungkan kerangka kerja sumber terbuka flutter_gherkin .

Ketika kami menyadari bahwa ada autotest di Flutter, kami bertanya-tanya apa perbedaan antara teknologi Calabash dan Dart + Gherkin, pendekatan mana yang lebih baik. Mari kita bandingkan keduanya.

1. File fitur benar-benar identik untuk kedua pendekatan tersebut.

Misalnya, skrip untuk otorisasi dengan kode pin akan diinterpretasikan dengan benar di Dart dan Ruby menggunakan Calabash:

:        ( )

Kedua teknologi tersebut mendukung bahasa Rusia, Inggris, dan bahasa lainnya.

2. Langkah-langkah penerapannya berbeda.

Dart + flutter_gherkin Labu

class TapAnErrorButtonOnPinCodeScreen extends ThenWithWorld<FlutterWorld> {
  @override
  Future<void> executeStep() async {
    final elemFromReportAnErrorScreen = find.byValueKey('reportAnErrorButton');
    await FlutterDriverUtils.tap(world.driver, elemFromReportAnErrorScreen);
  }
  @override
  RegExp get pattern => RegExp(r"       -");
}

When(/^       -$/) do
wait_element("* id:'reportAnErrorButton'")
tap_on("* id:'reportAnErrorButton'")
end

Ini bukan untuk mengatakan mana yang lebih nyaman: struktur dalam teknologi tertentu tidak berubah, dan ini bagus.

3. Flutter menggunakan file .dart tambahan untuk mengonfigurasi dan bekerja dengan pengujian. Dengan Calabash, tidak ada file tunggal seperti itu.

Menurut pendapat kami, tidak mungkin untuk mengatakan bahwa ini adalah flutter di dalam Flutter atau Calabash - ini hanya spesifikasi cara bekerja dengan alat dan teknologi tertentu.

4.Untuk kenyamanan bekerja dengan elemen dalam aplikasi, setiap elemen harus memiliki id sendiri. Saat bekerja dengan tes otomatis dengan Calabash, Anda harus berhati-hati terlebih dahulu bahwa kedua platform memiliki id dalam aplikasi yang diuji. Di Dart, Anda dapat menambahkan id dalam proses penulisan autotests tanpa memuat ulang file aplikasi iOS dan Android secara terpisah - ini nyaman dan menghemat waktu.

Kesimpulan kami: autotests di Dart tidak kalah dengan autotest yang menggunakan framework Calabash.

Proksi

Untuk meningkatkan cakupan aplikasi berdasarkan kasus, Surf menggunakan program untuk membaca dan memalsukan lalu lintas, seperti Charles. Analisis interaksi klien-server memungkinkan:

Tentukan apakah ada interaksi nyata dengan backend.
Cari tahu di sisi mana masalahnya: di klien atau di server.
, .
: , , . Charles , , , .

Dart memiliki kliennya sendiri untuk bekerja dengan jaringan. Karena semua permintaan melewatinya, pengaturan yang diperlukan untuk bekerja dengan proxy harus dimasukkan di dalam aplikasi. Untuk kenyamanan penguji, semua pengaturan yang diperlukan ditempatkan pada layar terpisah: di Surf kami menggunakan Layar Debug, yang kami kembangkan sendiri.

Layar Debug adalah layar setelan tambahan yang hanya tersedia dari versi debug dan membantu pengujian. Di dalamnya, Anda dapat memilih server yang diperlukan, mengaktifkan penggunaan membaca dan menyimpan permintaan http dalam aplikasi, melihat token fcm perangkat, dan banyak lagi - ada banyak peluang untuk pengujian.

Debug Screen bersifat khusus: pengembang menambahkan elemen tambahan ke dalamnya atas permintaan penguji - misalnya, bidang untuk mengonfigurasi proxy dari aplikasi. Oleh karena itu, kami memiliki kesempatan penuh untuk bekerja dengan Charles: Anda dapat menyambungkan server proxy ke Debug Screen tanpa memulai ulang aplikasi.

Seperti yang Anda lihat, kemungkinan untuk menguji aplikasi Flutter tidak terbatas. Segala sesuatu yang biasa kami kerjakan saat native nyaman dan mudah digunakan. Ini kabar baik.

Masalah: bug kerangka kerja, kelemahan di pustaka pihak ketiga, perilaku asli yang diharapkan

Masalah yang kami hadapi saat menguji aplikasi Flutter juga asli. Tidak dapat dikatakan bahwa ini adalah kekurangan spesifik Flutter: dalam teknologi apa pun, pemecahan masalah tidak selalu jelas dan sederhana.

Mari beri tahu Anda apa yang harus dicari saat menguji aplikasi Flutter. Diperingatkan lebih dahulu.

Bug Flutter-framework

Selama pengujian, kami mengalami masalah saat menampilkan dan memformat font di iOS: jarak huruf di platform iOS terasa lebih lebar daripada di Android. Ini menyebabkan banyak bug visual.

Ternyata masalahnya ada pada kerangka itu sendiri. Ketika pengembang aplikasi seluler kami meminta orang-orang dari komunitas pengembang kerangka Flutter untuk memperbaiki bug yang tidak menyenangkan, kerangka kerja segera diperbarui dan tampilan teks di iOS telah diperbaiki.

Tentunya situasi seperti itu akan terulang kembali. Tapi ini tidak bisa disebut masalah besar: orang-orang dari komunitas Flutter dengan cepat menanggapi masalah, mendukung, dan mengembangkan kerangka kerja.

Kekurangan di pustaka pihak ketiga

Pada iOS versi 10 dan 11, kelemahan implementasi ditemukan di pustaka pihak ketiga. Misalnya, kami sedang memperbaiki bug ketika izin untuk mengakses notifikasi segera muncul saat aplikasi diluncurkan, dan bukan pada tombol, seperti yang direncanakan oleh spesifikasi teknis dan desain.

Masalah seperti itu dapat ditemui baik di lintas platform maupun asli. Mereka diselesaikan dengan perbaikan dalam proyek, atau bersama dengan pengembang perpustakaan.

Berurusan dengan Perilaku Asli yang Diharapkan

Dengan penggunaan jangka panjang dan pengujian aplikasi asli di iOS dan Android, mudah untuk memprediksi ekspektasi pengguna dari perilaku aplikasi yang berbeda. Jadi, misalnya, kembali dengan backwipe di iOS adalah gerakan standar. Dan di Android, Anda tidak membutuhkannya.

Dialog sistem di kedua platform berbeda: di iOS, Anda perlu meminta izin untuk mengakses notifikasi, dan di Android, akses ini diberikan secara default.

Bagian-bagian spesifik OS inilah yang sering kali harus diselesaikan secara manual. Dan terkadang - untuk memotong, jika tiba-tiba perilaku yang diharapkan untuk platform iOS bermigrasi ke Android, seperti halnya dengan backwipe.

Dalam aplikasi asli, masalah seperti memperbarui layar, kesalahan meminimalkan aplikasi, dan pengoperasian aplikasi yang tidak biasa untuk OS saat ini jarang terjadi: alat dan teknologi untuk mengembangkan aplikasi untuk platform tertentu jelas ditujukan untuk mencakup semua versi dan kemampuan sistem tertentu.

Saat menguji salah satu aplikasi Flutter, kami menghadapi situasi yang menarik: kemampuan untuk memperbarui layar tidak tersedia di perangkat iOS dengan poni - dimulai dengan iPhoneX dan lebih tinggi. Pada saat yang sama, perangkat iOS tanpa poni dan Android berfungsi dengan baik.

Kami menemukan bug lain di Android versi 6: ketika diminimalkan, aplikasi benar-benar dikeluarkan dari memori.

Bug seperti itu telah diperbaiki oleh pengembang kami di dalam proyek.

iOS sangat menyadari perangkat dan sistem mereka, chip apa yang mereka rilis dengan versi baru OS dan mana yang tidak lagi berfungsi di versi sebelumnya, apa yang harus difokuskan saat memperbarui Swift yang sama. Android memahami bahwa mereka harus menargetkan sejumlah besar perangkat dan ukuran layar yang sangat berbeda, dan mereka juga mengetahui spesifikasinya.

Saya ingin platform silang berisi semua seluk-beluk implementasi dari pengembangan asli. Tentu saja, ada beberapa kekurangan saat bekerja dengan Flutter, tetapi ini bukan masalah: Anda hanya perlu pendekatan Anda sendiri ke lintas platform.

Manfaat: satu basis kode, satu tim pengembangan

Basis kode tunggal mengurangi waktu pengujian. Penyebab bug bisa jadi karena spesifikasi teknis yang kabur, kurangnya status yang dirender dalam desain, kompatibilitas mundur saat memperbarui back-end. Lebih mudah membuat bug seperti itu, karena Anda perlu membuat tugas setengah dari jumlah yang ada, dan ini sudah menghemat waktu.

Anda dapat mencari bug dan memeriksa fitur di satu platform: dengan tingkat kemungkinan yang tinggi, bug tersebut berulang di kedua platform - bagaimanapun, hanya ada satu implementasi.

Logika fitur baru pada kedua platform juga sama, karena kode yang sama ditulis: pengujian proses kompleks dalam aplikasi dikurangi untuk mengujinya di satu platform dan mengkonfirmasinya di platform lain. Kami melakukan satu siklus penuh aktivitas pada satu platform: kami melakukan pengujian eksplorasi, fitur berjalan, asap / kewarasan / penuh, menganalisis umpan balik. Setelah itu, tinggal memastikan kualitas dengan pengujian eksplorasi di platform lain. Pendekatan ini menghemat waktu pengujian logika sekitar 1,3 kali.

, , , : , . , .

, (, iOS), , (Android), event .

Jika rakitan untuk kedua platform perlu dikirim ke pelanggan pada hari yang sama, rakitan tersebut keluar pada waktu yang sama dan hanya ada satu teknisi QA dalam proyek tersebut, mungkin tidak ada cukup waktu untuk verifikasi dalam pengembangan asli: siklus pengujian harus dilakukan pada kedua platform secara terpisah. Kami menghemat waktu dengan menguji aplikasi lintas platform: pengujian regresi kedua platform berlangsung dalam satu siklus.

Kami mencoba mengevaluasi secara kasar pengujian dua proyek serupa - satu di Android asli dan iOS, yang kedua di Flutter - dan membandingkannya secara apikal.

Analisis dan pengujian dilakukan pada satu perangkat iOS dan satu perangkat platform Android. Seperti yang Anda lihat dalam praktiknya, Flutter benar-benar memberi Anda keuntungan dalam waktu, meskipun tidak dua kali. Ini bisa dimengerti: Anda tidak bisa sepenuhnya menghapus pengujian pada salah satu dari dua platform. Apa pun yang dikatakan, mereka memiliki kekhususan dan fokus yang berbeda pada pengguna.

	IOS asli	Android Asli	Flutter Android + iOS
Pemulihan kata sandi	2 jam	2 jam	3j 20m
Otorisasi	1j 30m	1j 30m	2j 20m
Pemberitahuan push	2 jam	2 jam	4j

Saat menguji fitur siap pakai yang tidak sepenuhnya memengaruhi spesifikasi sistem operasi dan tidak ditulis khusus untuk setiap platform secara terpisah, waktu untuk memeriksa aplikasi Flutter di kedua platform berkurang sekitar 1,3-1,5 kali. Misalnya, fitur otorisasi dan pemulihan sandi yang tidak memiliki perilaku khusus pada platform yang berbeda mengurangi waktu pengujian versi Flutter sebanyak 1,3 kali.

Sedangkan untuk fitur yang membutuhkan perilaku kustom dari setiap platform, Anda tidak boleh mengharapkan pengurangan waktu. Perilaku untuk iOS dan Android diharapkan berbeda, yang berarti bahwa kedua platform perlu diuji secara lengkap dan terpisah satu sama lain. Misalnya, sering kali perlu menguji notifikasi push dalam siklus penuh pada kedua platform karena perbedaan izin, bekerja dengan koneksi notifikasi, pengaturan pendorong untuk mengirim notifikasi di iOS dan Android, serta kehalusan implementasi lainnya - untuk mempertahankan pekerjaan biasa pengguna dengan notifikasi. TK dan desain dihormati.

Lebih mudah untuk mengatur komunikasi dalam tim

Ketika ada banyak orang dalam proyek, sulit untuk mengatur prosesnya sehingga kehalusan terkecil pun tidak terlewat. Apalagi jika ada banyak perbaikan ke depan, implementasi fitur baru dan perubahan secara umum. Sebagian besar masalah terpecahkan jika tim pengembangan menjadi satu.

Pertama, lebih mudah menguji aplikasi dengan mengimplementasikan satu perintah daripada bekerja dengan dua implementasi berbeda di dua platform. Para profesional penjaminan mutu tentu saja tertarik untuk mengetahui informasi lengkap tentang status aplikasi, baik di platform iOS maupun di platform Android. Lebih mudah saat bekerja dengan Flutter.

Kedua, ada poin penting dalam pengembangan asli: tentang perubahan yang telah dipelajari dan diterima oleh satu platform, perlu untuk memberi tahu platform lain, yang terkadang terlupakan atau hilang dalam proses perubahan besar dan intensif. Tidak ada masalah seperti itu saat mengembangkan aplikasi Flutter: hanya ada satu tim - yaitu, satu tugas untuk revisi berlaku untuk kedua platform.

Kami senang menguji aplikasi Flutter

Menjadi bagian dari komunitas yang keren

Bagi kami, kerangka kerja baru adalah nilai tambah: memecahkan masalah non-standar, kami memperluas wawasan. Kami menemukan banyak bug menarik dan unik yang mengembangkan keterampilan dan kemampuan kami saat menguji aplikasi.

Pada saat yang sama, pengembang dari komunitas Flutter-framework dengan cepat memberikan umpan balik tentang masalah yang teridentifikasi, meningkatkan perpustakaan, dan memungkinkan kami berkontribusi pada proyek: kami bergerak maju bersama, dan itu menyenangkan.

Menjadi spesialis

Saat bekerja dengan aplikasi lintas platform, penting untuk diingat perbedaan dalam sistem operasi dan tidak kehilangan fokus pada kekhususan platform. Mencari dan melihat perbedaan yang semestinya minimal dalam teori, mempelajari sesuatu yang belum pernah Anda temui sebelumnya - pekerjaan seperti itu meningkatkan profesionalisme.

Saat mengembangkan dan menguji aplikasi asli, tidak mungkin membuat aplikasi iOS dari, misalnya, Android Studio atau Visual Studio Code. Saat bekerja dengan Flutter, IDE-nya sama untuk Android dan iOS. Itu keren.

Mandiri

Saat bekerja dengan Flutter, di Surf kami dihadapkan pada proyek yang sangat berbeda: dari e-commerce hingga perbankan. Praktik telah menunjukkan bahwa seorang insinyur QA dapat menguji kedua platform sendirian. Penting untuk menghubungkan spesialis lain hanya lebih dekat ke rilis, ketika kecepatan pekerjaan meningkat, dan waktu untuk menyelesaikan tugas hampir habis.

Flutter - selangkah lebih maju

Menguji aplikasi lintas platform tidaklah sulit. Kadang-kadang bahkan lebih cepat dan lebih nyaman daripada bekerja dengan yang asli. Semua kesulitan yang mungkin dihadapi seseorang tidak tumpang tindih dengan kenyamanan dan keuntungan.

Pengalaman dalam mengembangkan dan menguji aplikasi Flutter telah menunjukkan kepada Surf bahwa framework ini merupakan langkah maju yang besar.

Menguji Aplikasi Flutter: Alat, Manfaat, Tantangan

Kemampuan pengujian di Flutter setara dengan yang asli

Masalah: bug kerangka kerja, kelemahan di pustaka pihak ketiga, perilaku asli yang diharapkan

Manfaat: satu basis kode, satu tim pengembangan

Kami senang menguji aplikasi Flutter

Flutter - selangkah lebih maju

More articles: