Hai Saya ingin memberi tahu Anda bagaimana pengujian
bekerja di proyek
Autotech , layanan inspeksi mobil oleh VIN. Di bawah cut - about alat apa yang kami gunakan untuk menguji persyaratan, perencanaan sprint, bagaimana proses pengujian dalam proyek kami bekerja.
MindMap untuk tugas perawatan
Kami menggunakan scrum di Pusat Otomatis, karena ini adalah metodologi yang paling berhasil untuk tugas kami. Setiap minggu, kami mengadakan rapat di mana kami memprioritaskan, menentukan kerumitan, menguraikan tugas dari jaminan, dan menetapkan Definisi Siap dan Definisi Selesai untuk setiap tugas (Anda dapat membaca tentang mereka di
artikel yang luar biasa ini ). Proses ini disebut backlog grooming.
Untuk perawatan yang efektif, semua ketergantungan harus dipertimbangkan. Ketahui bagaimana pelaksanaan tugas dapat berdampak negatif terhadap proyek. Memahami fungsionalitas mana yang Anda butuhkan untuk mendukung dan mana yang harus dipotong. Mungkin, dalam proses pelaksanaan tugas, API untuk mitra mungkin menderita, atau Anda hanya perlu ingat untuk menerapkan metrik yang dengannya Anda dapat memahami efisiensi bisnis. Dengan pengembangan proyek apa pun, ada semakin banyak ketergantungan seperti itu, dan memperhitungkannya menjadi semakin sulit. Ini buruk: penting bagi tim pendukung untuk mencari tahu tentang semua fitur pada waktunya. Dan terkadang inovasi perlu dikoordinasikan dengan departemen pemasaran.
Sebagai hasilnya, saya mengusulkan solusi berdasarkan MindMap, yang mencerminkan hampir semua dependensi yang dapat mempengaruhi DoD, DoR dan evaluasi tugas.
Keuntungan dari pendekatan ini adalah representasi visual dari semua dependensi yang mungkin dalam gaya hirarkis, serta roti tambahan dalam bentuk ikon, pemilihan teks dan cabang multi-warna. Seluruh tim memiliki akses ke MindMap ini, yang memungkinkan Anda untuk selalu memperbarui peta. Saya menyebar kosong kartu seperti itu, yang dapat dianggap sebagai tengara, di sini -
melon . (Saya akan segera memesan bahwa ini hanya panduan, dan sangat diragukan untuk menggunakan kartu ini untuk tugas Anda tanpa menyelesaikan proyek.)
Analisis Kode Linty dan Static untuk Go
Dalam proyek kami, sejumlah besar kode golang, dan agar gaya kode memenuhi standar tertentu, diputuskan untuk menerapkan analisis kode statis. Tentang apa itu, ada
artikel bagus tentang Habré.
Kami ingin mengintegrasikan penganalisis ke dalam proses CI, sehingga pada setiap pembangunan proyek penganalisa dimulai, dan tergantung pada hasil verifikasi, pembangunan dilanjutkan atau jatuh dengan kesalahan. Secara umum, menggunakan gometalinter sebagai langkah Build terpisah di Teamcity akan menjadi solusi yang baik, tetapi melihat kesalahan dalam build log tidak terlalu nyaman.
Kami terus mencari dan menemukan Linty Bot, yang dikembangkan sebagai bagian dari
hackathon Avito
oleh Artemy
Flaker Ryabinkov.
Ini adalah bot yang memantau kode proyek dalam sistem kontrol versi kami dan meluncurkan penganalisis kode berbeda dengan setiap permintaan tarik. Jika kesalahan terjadi selama analisis, bot mengirimkan komentar ke PR ini ke baris kode yang diinginkan. Keuntungannya adalah kecepatan koneksi ke proyek, kecepatan pekerjaan, komentar pada permintaan tarik, dan penggunaan linter Gometalinter yang agak populer, yang secara default sudah berisi semua pemeriksaan yang diperlukan.
MockServer dan cara mendapatkan layanan untuk memberikan apa yang mereka butuhkan
Bagian selanjutnya adalah tentang stabilitas tes. Dealer mobil sangat tergantung pada sumber data (mereka berasal dari dealer, layanan pemerintah, stasiun layanan, perusahaan asuransi dan mitra lainnya), tetapi ketidakmampuan mereka tidak dapat menjadi dasar untuk menolak melakukan tes.
Kita harus memeriksa kumpulan laporan baik di sumber kerja maupun di ketidakmampuannya. Sampai baru-baru ini, kami menggunakan sumber data nyata di lingkungan pengembang, dan karenanya, bergantung pada kondisi mereka. Ternyata kami secara tidak langsung memeriksa sumber-sumber ini dalam tes UI. Akibatnya, mereka memiliki tes tidak stabil yang jatuh bersama dengan sumber dan menunggu survei sumber data, yang tidak berkontribusi pada kecepatan lulus tes otomatis.
Saya punya ide untuk menulis tiruan saya sendiri dan dengan demikian mengganti sumber Autotech. Tetapi pada akhirnya, solusi yang lebih sederhana ditemukan -
MockServer yang sudah jadi , pengembangan open-source di Jawa.
Prinsip kerjanya:
- menciptakan harapan
- cocok dengan permintaan yang masuk,
- jika kecocokan ditemukan - kirim tanggapan.
Contoh membuat tunggu menggunakan klien java:
new MockServerClient("localhost", 1080) .when( request() .withMethod("POST") .withPath("/login") .withBody("{username: 'foo', password: 'bar'}") ) .respond( response() .withStatusCode(302) .withCookie( "sessionId", "2By8LOhBmaW5nZXJwcmludCIlMDAzMW" ) .withHeader( "Location", "https://www.mock-server.com" ) );
Seperti yang dapat Anda lihat dari contoh, kami menggambarkan permintaan yang akan kami kirim dan respons yang ingin kami terima. MockServer menerima permintaan, mencoba membandingkannya dengan yang telah dibuat, dan jika ada kecocokan, ia akan mengembalikan respons. Jika permintaan tidak gagal, kami mendapatkan 404.
Untuk MockServer ada klien untuk Java dan JavaScript, dokumentasi yang sangat baik dan contoh penggunaan. Ada kemungkinan mencocokkan permintaan pada RegExp, detail logging di server dan sejumlah chip. Untuk kebutuhan kita, itu adalah kandidat yang ideal. Proses peluncuran dijelaskan secara rinci di situs, jadi menceritakannya kembali di sini tidak melihat intinya. Satu-satunya momen, versi terbaru adalah memori yang cukup bocor, jadi kami menggunakan versi 5.2.3. Berhati-hatilah. Kekurangan lainnya adalah Mockserver tidak memiliki dukungan SOAP di luar kotak.
Saat ini, MockServer telah bekerja bersama kami selama sekitar tiga bulan. Sebagai hasilnya, stabilitas pengujian, kecepatan eksekusi dan kemampuan untuk menerima data apa pun di lingkungan dev telah meningkat. Dan karenanya, ada lebih banyak peluang untuk pengujian.
Epilog
Teknologi ini adalah hal utama yang ingin saya bicarakan dalam artikel ini. Kalau tidak, kami menggunakan alat pengujian yang biasa: Tes API dengan bundel Kotlin + JUnit + RestAssured, tukang pos untuk kenyamanan mengakses API. Dalam artikel ulasan ini, saya tidak berbicara tentang pendekatan kami untuk tes UI. Kami menggunakan MBT dan
graphwalker . Kami berencana menyiapkan posting dengan kolega tentang hal ini.
Jika Anda memiliki pertanyaan, tanyakan di komentar, saya akan mencoba menjawab. Saya harap artikel ini bermanfaat bagi tim pengembangan. (Ngomong-ngomong, saat dia sedang bersiap untuk rilis, pekerjaan
pengembang QA muncul di tim kami, menunjukkan kepada mereka yang mungkin tertarik dengan itu).