+ lebih baik, tetapi versi sampulnya kurang lucu Cepat atau lambat, semua orang datang ke AT. Situasi ketika ini terjadi terlambat dapat dipahami, dan kapan itu awal? Dan bagaimana memahami apa yang sudah mungkin terjadi?Artikel ini didasarkan pada pengalaman satu tim: Saya akan memberi tahu Anda tentang prasyarat kami dan alasan untuk pengenalan autotesting, kriteria apa yang telah kami pilih untuk kesiapan AT dan alat apa yang kami gunakan pada akhirnya. Spoiler: pada akhirnya, beberapa Xamarin sukses dan tidak terlalu kasus.Tentang produk. , , , , , . offline.
-.
Apa kata teori itu
Pertimbangkan pendekatan otomatisasi menggunakan piramida tes sebagai contoh. Sebagai tingkat piramida, saya akan mengambil jenis pengujian yang kami gunakan. Yakni, tes unit, tes integrasi dan tes end-to-end (E2E).
Tes unit (unit test) memverifikasi operasi setiap bagian kecil dari sistem (fungsi, metode). Mereka kecil, lulus dengan cepat, tidak memerlukan biaya pengembangan dan pemeliharaan yang besar.Tes integrasi menguji operasi aplikasi dengan komponen eksternal. Misalnya dengan database atau berbagai layanan. Mereka membutuhkan lebih banyak waktu, baik untuk menulis dan mendukung tes, dan untuk menjalankan mereka. Untuk pengujian semacam itu, paling sering Anda perlu mengonfigurasi dan mendukung beberapa jenis lingkungan. Dalam hal ini, mereka sering menjadi lebih rapuh, karena lingkungan cenderung rusak.Tes end-to-end memverifikasi operasi sistem secara keseluruhan, meniru tindakan pengguna akhir. Paling sering mereka mengakses sistem melalui UI: mereka menekan tombol sebagai pengguna, mengisi kolom, dll. Tetapi mereka juga dapat digunakan dalam sistem tanpa antarmuka. Tes-tes ini jauh lebih mahal daripada yang dipertimbangkan di atas, karena membutuhkan lebih banyak waktu untuk mengembangkan dan mendukung tes itu sendiri dan seluruh lingkungan. Selain itu, mereka sangat rapuh, karena mereka dipengaruhi oleh perubahan di bagian mana pun dari sistem, dan perilaku tak terduga dari sebuah emulator atau peramban dapat memengaruhi hasil pengujian tertentu. Durasi menjalankan tes tersebut juga secara signifikan lebih tinggi daripada yang lain: untuk melakukan tindakan pengguna individu, Anda perlu membuat banyak tambahan. Misalnya, masuk atau buka item menu yang diinginkan.Menurut prinsip piramida, semakin mudah, lebih cepat dan lebih murah tes, semakin mereka harus dalam persentase dari total jumlah tes. Itu tes melalui seharusnya tidak memeriksa penugasan nilai yang berbeda untuk satu bidang (kecuali jika Anda perlu memeriksa operasi UI dalam kasus ini).Untuk semua jenis pengujian ini ditugaskan peran. Pada titik tertentu dalam siklus hidup aplikasi, muncul kebutuhan untuk satu atau beberapa tes otomatisasi. Produk Anda dapat dengan mudah dilakukan dengan hanya unit test, dan dapat dengan cepat berkembang menjadi kebutuhan untuk pengujian end-to-end. Hal utama ketika merencanakan otomatisasi adalah untuk memahami apa sebenarnya produk Anda saat ini akan mendapat manfaat, dan yang kemungkinan besar akan Anda buang waktu.Ketika menerapkan otomatisasi, jangan lupa tentang pengujian manual, bahkan dengan sejumlah besar otomatisasi, akan selalu ada hal-hal yang perlu diperiksa secara manual. Minimal, fungsionalitas baru yang tidak rasional untuk segera menulis tes.Tetapi semua otomatisasi, menurut pendapat saya, terutama harus ditujukan untuk mengurangi volume pengujian manual. Dan ketika merencanakan pengujian manual, ada baiknya mempertimbangkan kasus mana yang sudah otomatis.Bagaimana tes otomatis diselenggarakan dengan kami?
Setiap produk secara individual memiliki unit test, dijalankan pada setiap PR. Mereka adalah tanggung jawab pengembang.
Tes integrasi memverifikasi interaksi layanan web dengan EDMS.Mereka mensimulasikan operasi aplikasi klien. Mereka beralih ke metode layanan web untuk mendapatkan dan memodifikasi data EDS.Jalankan setelah setiap pembuatan versi baru dari sisi server.
Tes end-to-end mensimulasikan kinerja pengguna akhir. Mereka menekan tombol di antarmuka aplikasi seluler, dan aplikasi tersebut bekerja dengan EDMS melalui layanan web.Tes integrasi dan ujung ke ujung sekarang dilakukan oleh penguji.Mengapa kita membutuhkan aplikasi seluler AT end-to-end?
Sebelum memulai otomatisasi, ada baiknya mempertimbangkan masalah apa yang ingin Anda selesaikan dengan memperkenalkannya. Kecuali Anda memiliki tujuan tertentu, Anda tidak akan dapat menjelaskan kepada penyelia atau pemilik produk mengapa Anda harus menghabiskan waktu untuk autotest. Akan sulit untuk menilai manfaat dari penerapannya.Kami telah lama menguji aplikasi seluler secara manual. Meskipun ini adalah aplikasi dengan sedikit fungsionalitas, kami berhasil mengatasinya. Segala sesuatu yang dikembangkan adalah ± dalam satu area, dan pengujian manual dapat diatur sedemikian rupa sehingga dengan cepat dan mudah menguji semua fitur aplikasi.Tetapi setelah beberapa waktu, aplikasi mulai tumbuh dengan fitur-fitur baru, yang cukup independen dan membutuhkan lebih banyak perhatian. Ada masalah dengan bug di fungsi lama, yang hanya bisa kami temukan di tahap terakhir proyek.Oleh karena itu, tujuan awal memperkenalkan uji UI aplikasi seluler untuk kami adalah:- Cakupan AT kasus aplikasi utama;
- mengurangi jumlah bug dalam regresi sebelum dirilis.
Mencapai tujuan pertama harus secara otomatis mengarah pada pencapaian yang kedua, seperti pengujian rutin untuk fungsionalitas dasar di seluruh proyek harus menemukan bug pada tahap sebelumnya.Setelah beberapa waktu, tujuan lain ditambahkan - mengurangi jumlah tes regresi manual.Dan kapan saatnya untuk memperkenalkan otomasi ke dalam pengujian?
Sebelum memulai otomatisasi pengujian, Anda harus mengevaluasi kesiapan aplikasi Anda untuk otomatisasi. Dan juga kesiapan Anda untuk proses ini.Fungsionalitas yang stabil
Agar AT memiliki peluang untuk berguna, aplikasi harus memiliki fungsi yang stabil. Dan itu adalah nilainya untuk menutupi autotest. Jika tidak, Anda akan menghabiskan banyak waktu dan upaya untuk memperbarui dan memperbarui tes sebagai akibat dari perubahan aplikasi.Rencana pengembangan
Otomasi harus diimplementasikan hanya jika aplikasi Anda memiliki masa depan, rencana pengembangan untuk tahun-tahun mendatang. Mengapa autotest untuk aplikasi yang tidak berubah?Sumber daya
Anda harus memiliki sumber daya untuk mengembangkan tes, dan yang paling penting, untuk dukungan lebih lanjut mereka. Itu Ketika merencanakan implementasi otomatisasi, penting untuk dipahami bahwa sumber daya tidak hanya diperlukan untuk menulis tes. Tes pasti akan jatuh karena suatu alasan. Hasil dari run perlu dianalisis dan langkah-langkah diambil. Termasuk ubah sesuatu dalam tes. Nah, selain mendukung, jangan lupakan kebutuhan akan perkembangan mereka.Bagaimana cara memutuskan?
Saat memikirkan uji UI aplikasi seluler, kami segera membuat rak besar dengan perangkat atau peternakan tempat perangkat disewa. Ada banyak masalah dalam tes karena kebutuhan untuk memeriksa berbagai ukuran dan resolusi layar. Ya, dan tidak banyak pengalaman dalam pengembangan. Itu semua menakutkan dan terpaksa membatalkan rencana.Tujuan yang dirumuskan sebelumnya datang untuk menyelamatkan, dan yang utama adalah tes fungsional. Karena itu, kami mulai dari kecil.Hasilnya, tes kami:- berjalan sekali sehari (ini cukup untuk menemukan sumber masalah jika terjadi sesuatu);
- berjalan secara lokal di server kami;
- pada dua perangkat (iOS dan Android);
- untuk Android sekarang ada sekitar 50 tes, prosesnya memakan waktu sekitar satu jam (bersama dengan perakitan);
- untuk iOS - sekitar 40 tes, prosesnya memakan waktu sekitar 30 menit;
- tes ditulis menggunakan Xamarin.UITest;
- mereka diluncurkan secara otomatis oleh build di TFS, di tempat yang sama di TFS kami memantau hasil run.
Sedikit tentang Xamarin. Paling sederhana
Ini adalah kerangka kerja untuk pengujian UI otomatis untuk proyek-proyek di Xamarin.iOS dan Xamarin. Android (dukungan untuk Objective-C / Swift dan Java juga diumumkan). Tes ditulis dalam C # menggunakan NUnit. Proyek konten dapat dengan mudah diintegrasikan.Prinsip operasi kerangka kerja ini didasarkan pada dua komponen: mencari elemen (Permintaan) dan melakukan tindakan apa pun dengannya (Tindakan), misalnya, menekan atau menjalankan gesek.Di sini, misalnya, adalah tes yang memeriksa tampilan kesalahan saat memasukkan login yang tidak valid:public void ShowErrIncorrectLoginOrPassword_IfLoginIsWrong()
{
var wrongLogin = TestsSettings.UserLogin + "1";
app.EnterLoginAndPassword(wrongLogin, TestsSettings.UserPassword);
app.WaitForElement(Resources.Identifiers.ErrorMessage, "Login is incorrect, alert message wasn't shown.", TestsSettings.Delay);
Assert.AreEqual(CoreResources.ErrIncorrectLoginOrPassword, ErrorMessage);
}
private string ErrorMessage =>
app.Query(x => x.Marked(Resources.Identifiers.ErrorMessage)).First().Text;
Metode input kredensial yang digunakan di dalamnya:public static void EnterLoginAndPassword(this AndroidApp app, string login, string password)
{
app.WaitForElement(Resources.Identifiers.LoginEdit, TestsSettings.Delay);
app.EnterText(Resources.Identifiers.LoginEdit, login);
app.EnterText(Resources.Identifiers.PasswordEdit, password);
app.Tap(Resources.Identifiers.LoginButton);
}
Dalam contoh ini, metode kerangka kerja standar digunakan - menunggu elemen, memasukkan teks, mengklik elemen.Saat mengembangkan dan mendebug tes, akan lebih mudah untuk menggunakan utilitas konsol bawaan REPL (read-eval-print-loop), yang memungkinkan Anda untuk melihat susunan elemen yang ada sekarang di layar, serta melakukan metode kerangka kerja standar.Tidak terduga bagi kita
Mengatasi elemen antarmuka terkadang tidak mengarah ke apa yang kami harapkan.Misalnya, ketika jendela baru dalam aplikasi dibuka dengan sebuah fragmen dalam aktivitas yang sama, pengguna hanya melihat jendela baru ini di layar. Tetapi dalam kasus ini akan ada elemen-elemen di pohon elemen terlihat yang pengguna tidak melihat dengan matanya. Pencarian untuk elemen "tidak terlihat" seperti itu akan berhasil, dan Anda dapat melakukan tindakan dengannya. Itu hanya sebuah klik yang akan dieksekusi di jendela yang dilihat pengguna. Itu pada kenyataannya, itu akan menjadi positif palsu.Pohon dapat berisi beberapa elemen identik, secara default, tindakan akan dilakukan dengan elemen pohon pertama yang sesuai. Dan jika dalam tes Anda mengakses elemen melalui label, dan kemudian Anda memiliki elemen dengan label yang sama di suatu tempat, tes akan mulai turun (atau mungkin tidak jika elemen yang Anda butuhkan adalah yang pertama).Kami memiliki satu kasus ketika tes tertulis dan debug jatuh pada peluncuran pertempuran pertama. Karena tes dijalankan pada perangkat dengan ukuran layar yang berbeda. Dan elemen yang diklik pada perangkat ini muncul di bawah elemen antarmuka lain.
Folder Kotak keluar berada di bawah tombol Buat Tugas, dan mengklik folder dalam kasus ini menyebabkan mengklik tombol. Ini adalah situasi yang biasa bagi pengguna, ia hanya akan menggulir layar. Tetapi di pohon elemen overlay ini tidak terlihat.Masalah seperti itu menyebabkan ketidaknyamanan kecil dan membuat Anda memikirkan beberapa tes lebih hati-hati. Dan kadang-kadang kita hanya memasukkan data dalam database sehingga tidak ada yang mengganggu tes. Bagaimanapun, tujuan dalam contoh ini adalah untuk membuka folder, dan tidak memeriksa bahwa tidak ada yang mencegah pembukaannya.Kejutan dan kekecewaan lainnya adalah ketidakmampuan untuk menjalankan dan men-debug tes iOS dari Visual Studio untuk Windows. Fitur ini belum diterapkan. Saya harus bekerja di studio untuk MacOS.Beberapa hasil kapten
Terapkan otomasi jika masuk akal.Biarkan tes Anda dengan konfigurasi minimum, biarkan berjalan secara manual dan hanya sebulan sekali, tetapi jika itu menyelesaikan masalah Anda dan membantu Anda - mengapa tidak?Nah, jangan lupa tentang prinsip piramida.