Saat kita berbicara tentang CI&CD, kita sering kali membahas lebih dalam tentang alat dasar untuk mengotomatiskan pembuatan, pengujian, dan pengiriman aplikasi - dengan fokus pada alat, tetapi lupa untuk menutupi proses yang terjadi selama pemotongan dan stabilisasi rilis. Namun, tidak semua alat yang sudah jadi sama berguna, dan beberapa proses kustom tidak sesuai dengan cakupannya. Anda harus meneliti proses dan menemukan cara untuk mengotomatiskannya untuk mengoptimalkannya.
Di perusahaan kami, teknisi QA menggunakan Zephyr untuk melacak kemajuan regresi, karena kami tidak dapat mengganti pengujian manual dan eksplorasi dengan autotests. Namun meskipun demikian, autotest sering dikejar di sini dan dalam jumlah besar, jadi saya ingin menghilangkan beberapa pemeriksaan dangkal yang telah otomatis dan membiarkan penguji melakukan pekerjaan yang lebih produktif dan berguna.
Kami memiliki acara lari malam di mana suite pengujian penuh dikejar. Tetapi pada saat awal menguasai Zephyr, selama regresi, penguji kami harus mengunduh xcresult, atau bahkan plist sebelumnya, atau junit xml, dan kemudian meletakkan korespondensi tes hijau dan merah di marshmallow dengan tangan mereka. Ini adalah operasi yang agak rutin, dan membutuhkan banyak waktu untuk lulus 500-600 tes dengan tangan. Anda ingin meninggalkan hal-hal seperti itu pada belas kasihan mesin yang tidak berjiwa. Beginilah ZERG lahir.
Zerg lahir
Zephyr Enterprise Report Generator adalah utilitas kecil yang awalnya hanya mengetahui cara mencari kecocokan dalam laporan pengujian dan mengirim statusnya saat ini ke Zephyr. Nanti, utilitas menerima fungsi baru, tetapi hari ini kami akan fokus pada mencari dan mengirim laporan.
Di Zephyr, kita diminta untuk beroperasi dengan versi, loop, dan eksekusi kasus uji. Setiap versi berisi jumlah siklus yang berubah-ubah, dan setiap siklus berisi kasus yang lolos. Pass semacam itu berisi informasi tentang tugas (zephyr terintegrasi sempurna dengan jira dan kasus uji sebenarnya adalah tugas di jira), penulis, status kasus, serta siapa yang terlibat dalam kasus ini dan detail penting lainnya .
Untuk mengotomatiskan masalah yang kami uraikan di atas, penting bagi kami untuk memahami cara mengatur status kasus.
Bekerja dengan kode
Tapi bagaimana Anda menghubungkan tes kode dan tes marshmallow? Di sini kami telah mengambil pendekatan yang agak sederhana dan langsung: untuk setiap pengujian, kami menambahkan tautan ke tugas di jira di bagian komentar.
Parameter tambahan juga dapat ditempatkan di komentar, tetapi lebih dari itu nanti.
Jadi, satu tes dalam kode dapat mencakup beberapa tugas. Tetapi logika kebalikannya juga berfungsi. Beberapa tes dapat ditulis dalam kode untuk satu tugas. Status mereka akan diperhitungkan saat menyusun laporan.
Kita perlu melalui kode sumber, mengekstrak semua kelas pengujian dan pengujian, menautkan tugas dengan metode dan menghubungkannya dengan laporan kelulusan pengujian (xcresult atau junit).
Anda dapat bekerja dengan kode itu sendiri dengan berbagai cara:
- hanya membaca file dan mengambil informasi melalui ekspresi reguler
- gunakan SourceKit Bagaimanapun
, bahkan ketika menggunakan SourceKit, kita tidak dapat melakukannya tanpa ekspresi reguler untuk mengekstrak ID tugas dari tautan dalam komentar.
Pada tahap ini, kami tidak tertarik pada detailnya, jadi kami akan memagari diri kami dari mereka dengan protokol:
Kami perlu mendapatkan tes. Untuk melakukan ini, kami menjelaskan strukturnya:
Kemudian kami perlu membaca laporan kelulusan tes. ZERG lahir sebelum pindah ke xcresult, dan karenanya dapat mengurai plist dan junit. Kami masih belum tertarik dengan detail dalam artikel ini, mereka akan dilampirkan dalam kode. Oleh karena itu, kami akan memagari protokol
Yang tersisa hanyalah menghubungkan tes dalam kode dengan hasil tes dari laporan.
Kami memeriksa korespondensi berdasarkan nama kelas dan nama pengujian (kelas yang berbeda mungkin memiliki metode dengan nama yang sama) dan apakah pemfaktoran ulang diperlukan untuk pengujian. Jika Anda membutuhkannya, maka kami menganggapnya tidak dapat diandalkan dan membuangnya dari statistik.
Kami bekerja dengan marshmallow
Sekarang setelah kita membaca laporan pengujian, kita perlu menerjemahkannya ke dalam konteks zephyr. Untuk melakukan ini, Anda perlu mendapatkan daftar versi proyek, berkorelasi dengan versi aplikasi (agar ini berfungsi seperti ini, versi di marshmallow harus sesuai dengan versi di Info.plist aplikasi Anda , misalnya, 2.56), download loop dan pass. Dan kemudian menghubungkan pas dengan laporan kami yang ada.
Untuk melakukan ini, kita perlu mengimplementasikan metode berikut di ZephyrAPI:
Spesifikasinya dapat dilihat di sini: getzephyr.docs.apiary.io , dan implementasi klien ada di repositori kita.
Algoritme umum cukup sederhana:
Pada tahap pencocokan lewat dengan laporan, ada poin halus yang harus diperhitungkan: di zephyr api, paling mudah untuk mengirim pembaruan eksekusi dalam batch, di mana status umum dan daftar ID lulus dikirim . Kami perlu memperluas laporan tiket kami dan mempertimbangkan rasio nm. Untuk satu kasus di marshmallow, mungkin terdapat beberapa pengujian dalam kode. Satu tes dalam kode dapat mencakup beberapa kasus. Jika untuk satu kasus terdapat n tes dalam kode dan salah satunya berwarna merah, maka untuk kasus seperti itu status umum adalah merah, tetapi jika salah satu tes tersebut mencakup m kasus dan berwarna hijau, maka kasus lainnya harus tidak menjadi merah.
Oleh karena itu, kami beroperasi dengan set dan mencari persimpangan merah dan hijau. Apa pun yang jatuh ke persimpangan kami kurangi dari hasil hijau dan mengirim informasi yang diedit ke zephyr.
Perlu juga dicatat di sini bahwa dalam tim kami telah sepakat bahwa zerg tidak akan mengubah status lulus jika:
1. Status saat ini diblokir atau gagal (kami biasa mengubah status gagal, tetapi sekarang kami sudah menyerah latihan, karena kami ingin penguji memperhatikan autotest merah selama regresi).
2. Jika status saat ini adalah lulus dan itu ditetapkan oleh seseorang, bukan zerg.
3. Jika tes ditandai sebagai berkedip.
Minat Zephyr API
Saat meminta loop, kami menerima json, yang sekilas tidak dapat disistematisasikan untuk deserialisasi. Masalahnya adalah bahwa permintaan untuk mendapatkan loop untuk suatu versi, meskipun harus mengembalikan array loop, pada kenyataannya, mengembalikan satu objek, di mana setiap bidang unik dan disebut pengenal loop, yang terletak pada nilainya. Untuk menangani ini, kami menggunakan peretasan sederhana:
Status kelulusan pengujian ada di salah satu permintaan di sebelah objek permintaan. Tetapi mereka dapat dipindahkan terlebih dahulu ke enum:
Saat meminta loop, Anda harus meneruskan pengenal versi dan integer proyek ke parameter permintaan. Namun dalam permintaan pass untuk loop, pengidentifikasi proyek yang sama harus diteruskan dalam format string.
Bukan sebuah kesimpulan
Jika ada banyak pekerjaan rutin, maka kemungkinan besar sesuatu bisa otomatis. Sinkronisasi bagian tes otomatis dengan sistem manajemen tes adalah salah satu kasus seperti itu.
Jadi, setiap malam kami menjalankan pengujian penuh, dan selama regresi, laporan dikirim ke teknisi QA. Ini mengurangi waktu regresi dan memberikan waktu untuk pengujian eksplorasi.
Jika Anda mengimplementasikan parser sumber android dengan benar, maka itu bisa diterapkan dengan kesuksesan yang sama untuk platform kedua.
Zerg kami, selain membandingkan pengujian, juga dapat menganalisis dampak awal, tetapi lebih banyak tentang itu, mungkin lain kali.