Dalam posting ini saya ingin berbagi tinjauan 15 laporan dari konferensi Heisenbug, untuk memberi tahu Anda apa yang menarik di stand perusahaan, dan juga untuk berbagi materi video dari laporan Artyom Eroshenko tentang membuat plugin tindakan untuk IntelliJ IDEA yang akan membantu Anda dengan cepat mengubah kode proyek uji.
Informasi tentang HeisenBug
Heisenbug - Konferensi Teknis untuk Spesialis Pengujian. Ini terutama menarik bagi penguji, insinyur pengembangan perangkat lunak dalam pengujian, dan spesialis dalam pengujian otomatis dan beban. Panitia adalah tim
JUG.RU , di belakangnya ada konferensi seperti Joker, HolyJS, SmartData, DevOops, DotNext, Mobius.
Tempat
Konferensi
kelima diadakan di hotel Slavyanskaya Radisson, stasiun metro Kievskaya, Moskow. Saat mendekati hotel, spanduk elektronik dengan logo konferensi terlihat. Selanjutnya, di pintu masuk lobi hotel, peserta didampingi oleh tanda-tanda ke meja check-in dan lemari pakaian. Tidak mungkin tersesat. Pendaftaran peserta dan pembicara berlangsung di lantai dasar, di lobi utama konferensi terdapat stand mitra, ruang konferensi, aula dengan rehat kopi dan makan siang. Tingkat penjaga keamanan senang, sehingga "kelinci gelap" tidak bisa mendapatkannya. Secara total, acara ini dihadiri oleh sekitar 500+ peserta, yang sebagian besar terdaftar dua minggu sebelum dimulainya.
Programnya
Programnya dapat ditemukan di
sini . Saya ingin mencatat bahwa
JUG.RU selalu berusaha untuk membuat program praktis, tanpa air tambahan dan dengan para ahli asing yang terkenal. Laporan dibagi menjadi simbol:
Jika ini adalah pertama kalinya Anda berencana untuk menjadi pembicara di Heisenbag, lihat
memo pembicara - ini berisi cukup banyak informasi berguna.
Komunikasi dan sukarela
Agar para peserta tidak ketinggalan sesuatu yang penting di konferensi, saluran telegram dan obrolan telegram diselenggarakan. Omong-omong, di yang terakhir mereka mencari relawan untuk menonton video, yang mereka berikan tiket konferensi gratis.
Jika Anda memutuskan untuk menjadi sukarelawan, tunjukkan keputusan Anda kepada penyelenggara sedini mungkin. Persiapan acara dilakukan jauh sebelum konferensi. Tergantung ketersediaan, Anda akan ditugaskan ke tim.
Perusahaan berdiri
Kali ini konferensi menampilkan lebih dari selusin stan perusahaan IT besar, seperti Deutsche Bank, Alfa-Bank, Raiffeisen, Badoo, Luxoft, Kontur SKB, Gett, dll. Masing-masing perusahaan mendekati organisasi interaksi dengan peserta acara dengan cara mereka sendiri. , jadi di sela-sela pertunjukan tidak harus bosan. Dimungkinkan untuk memecahkan masalah untuk suvenir berkesan kecil, bermain video dan permainan papan, dan berpartisipasi dalam lotere.
Raiffeisen menawarkan untuk melakukan pencarian online dengan solusi untuk semua jenis teka-teki, juga penikmat klasik awet muda dapat memainkan Mortal Kombat 3 di Sega. Rekan-rekan Alfa-Bank membuat bot telegram dengan tugas-tugas, ditambah satu set besar Lego Mindstorms dimainkan di lotre. Saya ingin memuji stan Deutsche Bank, di mana pengembang dalam komunikasi langsung memberikan tugas dan mengambil bagian dalam diskusi, tidak seperti semua stan lainnya, di mana mereka hanya memeriksa jawabannya.
Banyak perusahaan yang secara diam-diam memburu spesialis, membagikan buklet yang menjelaskan lowongan (tidak semua sama untuk melakukan amal).
Ikhtisar Laporan
1. Kami memiliki DevOps. Mari kita tembak semua penguji - Baruch Sadogursky.
Konferensi dibuka oleh Baruch Sadogursky, advokat pengembang dari JFrog, seorang pembicara terkenal di konferensi yang terkait dengan Java dan Devops. Dalam laporan tersebut, Baruch membahas masalah kualitas perangkat lunak dalam menghadapi rilis yang sering, yang disebabkan oleh permintaan bisnis yang terus berkembang, kompleksitas pengujian kode karena arsitektur yang buruk, dan modernisasi peran penguji dalam tim Agile modern. Laporan itu menarik untuk disimak dari awal hingga akhir, banyak humor, fakta menarik dan perbandingan.
Nah, pemikiran utama dari laporan ini dapat dimasukkan ke dalam satu slide, yang menggambarkan bahwa pengujian otomasi dan praktik DevOps mengurangi biaya waktu dari proses rutin dan memungkinkan Anda untuk mencurahkan lebih banyak waktu untuk pelaksanaan tugas-tugas baru.
2. Perlu memperbaiki proyek? Ada GAGASAN! - Artem Eroshenko.
Artyom dalam laporannya berbicara tentang membuat
tindakan plug-in untuk IntelliJ IDEA, yang akan membantu Anda dengan cepat mengubah kode proyek pengujian.
Dia memberikan penjelasan tentang kelas utama (AnAction, PsiClass, PsiAnnotation, AnActionEvent, JavaCodeStyleManager), yang merupakan titik input dari Tindakan Plugin.
Dianggap bagaimana menyelesaikan tugas-tugas berikut:
a) Apa yang otomatis pada proyek dan apa yang tidak. Sinkronisasi otomatis dengan Jira.
Menurut teks anotasi, @DisplayName pergi ke Jira, menerima tiket yang diperlukan dan meletakkan semua koneksi yang diperlukan menggunakan @TmsLink.
b) Secara otomatis membubuhkan @ Tag dari konteks Jira.
Ada label tertentu di
favorit ,
tiket regress . Kami pergi ke tes, ada penjelasan @TmsLink, kami menggunakan plugin dan kami memiliki penjelasan @ Tag baru, dan kemudian dengan bantuan Junit kita dapat menjalankan tes pada tag ini.
c) Apa yang diperiksa dalam tes?
Ada autotest, ada langkah-langkah, kami ekspor dan kami memiliki langkah-langkah dalam tes. Juga dalam video ada contoh untuk dua tes.
Artyom juga menunjukkan cara cepat beralih dari Allure 1 ke Allure 2.
Laporan yang sangat praktis bagi mereka yang berpikir untuk mengoptimalkan proses penulisan kode. Kode sumber plugin dapat ditemukan di
sini .
3. Proyek Java dan Reactor? - Tapi bagaimana dengan tesnya? - Kirill Merkushev.
Cyril berbagi pengalamannya dalam mengembangkan startup medis internasional Vivy. Dia mengatakan bagaimana masalah skalabilitas sistem monolitik diselesaikan menggunakan layanan microser dan perpustakaan Reactor. Banyak perhatian diberikan pada perpustakaan ini, prinsip-prinsip dasarnya, pendekatan untuk menguji sistem reaktif, fitur pembunuh (seperti pos pemeriksaan dan log dalam rantai permintaan, Hooks dan permintaan berulang (coba lagi).
Secara pribadi, saya tidak berurusan dengan pengujian sistem reaktif, jadi bagi saya itu baru dan menarik.
4. Saat kami menulis kerangka kerja Sealant untuk mencari kebocoran memori di JS , Sergey Dokuchaev.
Pembicaraan ini adalah tentang kebocoran memori (objek yang dapat diakses dari kode tetapi tidak lagi diperlukan) pada aplikasi web satu halaman. Sergey mengatur tugas untuk secara otomatis menemukan semua kebocoran memori kritis dalam versi produk yang dirilis. Dia berbicara tentang kesulitan menemukan kesalahan seperti itu dan bagaimana melakukannya secara manual menggunakan alat Google Chrome. Selanjutnya, saya memeriksa alat
SeaLant , di mana dia adalah penulisnya. SeaLant mengotomatiskan deteksi kebocoran dengan berinteraksi dengan proses Chrome menggunakan protokol Chrome DevTools. Laporan berakhir dengan fakta bahwa jika halaman dapat menjalankan skrip siklik (dari satu perangkat, dengan satu sesi, tanpa memuat ulang halaman), maka kemungkinan besar, dengan mengujinya, Anda dapat menghilangkan sebagian besar kebocoran memori.
5. Fitur pengujian visual dari antarmuka - Anton Usmansky, pengembang terkemuka alat Gemini (alat pengujian visual) dan Hermione (generasi, alat tujuan umum yang dapat melakukan pernyataan tangkapan layar).
Laporan ini bermanfaat bagi mereka yang berpikir untuk mengimplementasikan alat uji visual dalam proyek mereka. Mereka yang sudah menggunakan Gemini dan Hermione mungkin juga tertarik - ini memberikan pemahaman tentang bagaimana alat-alat diatur di dalam. Di beberapa tempat, penulis berurusan dengan hal-hal yang cukup mendasar.
6. Masalah di Selenium WebDriver - Alexey Barantsev.
Alexey berbicara tentang masalah proyek Selenium dan alasan kemunculannya. Dia berbagi detail perakitan mono-repositori menggunakan kolektor
Bazel . Dia menyentuh pada topik visibilitas elemen (dalam standar W3C WebDriver tidak ada operasi yang memeriksa apakah suatu elemen terlihat atau tidak) dan menjelaskan bagaimana fungsi getProperty, getDomAttriubute, getAttribute berbeda.
Mengetahui masalah akan memungkinkan pengguna untuk membedakan fitur dari bug dan mengembangkan "kruk" yang efektif dalam proyek pengujian mereka.
7. Resep untuk membuat dari awal dan pengembangan sistem pengujian beban - Anatoly Plaskovsky.
Anatoly mewakili kelompok riset kinerja Yandex.Money. Dalam laporannya, ia berbagi praktiknya tentang cara menentukan kebutuhan untuk studi kinerja, di mana menemukan orang untuk melakukan kegiatan ini, dan bagaimana membangun proses penelitian. Penulis berfokus pada fakta bahwa penelitian kinerja! = Muat pengujian, dan bahwa hanya pengujian pada produksi yang dapat menunjukkan hasil yang relevan. Pada saat yang sama, dimungkinkan untuk melakukan eksperimen tanpa masalah bagi pelanggan dengan memilih rute dan data uji, memantau dan memprediksi kemungkinan hasil skenario.
Anatoly menciptakan telegram chat loadland, yang membahas pengujian beban, dan tempat Anda dapat mengetuk bantuan dan saran.
8. Kegagalan
Epik produsen perangkat - Valentine Wylsacom Petukhov.
Hari pertama ditutup oleh laporan Wylsacom yang terkenal kejam, yang secara ambigu dirasakan oleh publik (dinilai dari obrolan para peserta heisenbag di telegram :)).
Bagi saya sendiri, saya tidak mengambil sesuatu yang menarik dari laporan pengujian beta perangkat dan aplikasi, tetapi mungkin para penggemar menyukainya. Area diskusi berbaris untuk foto, jadi PR sukses.
9. Pengujian integrasi elegan kebun binatang microservice menggunakan TestContainers dan JUnit 5 menggunakan contoh platform SMS global - Andrey Markelov.
Penulis mengatakan bagaimana layanan microser sedang diuji di perusahaannya menggunakan bundel Testontainers + Junit 5 + MockServer. Laporan itu terdengar menarik, tetapi skema semacam itu bukan untuk sejumlah besar layanan-mikro. Tautan ke
kode sumber.
10. Voyeurism dari tester, atau Bagaimana pemantauan pengguna akan membantu Anda - Antonina Khisametdinova.
Laporan yang sangat menarik, meskipun lebih terkait dengan desain web daripada pengujian. Ini berbicara tentang praktik dan perangkap UX untuk menghindari ketika merancang antarmuka klien.
Antonina mengidentifikasi kesalahan utama ketika mengamati pengguna dalam solusi UI seperti menonaktifkan tombol, menggunakan loader, tooltips, komponen yang sudah dikenal, dll.
Juga patut diperhatikan desain grafis laporan dengan contoh-contoh intuitif dari proyek nyata (sebagaimana layaknya laporan tentang UX).
11. Pengujian sistem dengan dependensi eksternal: masalah, solusi, Mountebank - Andrey Glazkov.
Penulis berbicara tentang evolusi tahap mengompol dalam proyeknya. Dianggap pro dan kontra dari mengolok-olok di tingkat kode. Dia berbagi pengalamannya dalam hal mana adalah baik untuk membuat implementasi layanan palsu. Tetapi jika Anda ingin layanan palsu dibangun kembali dengan cepat, diproksi dan pada saat yang sama log permintaan masuk akan dimasukkan, maka Andrey merekomendasikan untuk melihat lebih dekat pada alat
Mountebank .
Keuntungan utama:
- mounteBank - bekerja di level TCP;
- Injeksi JavaScript;
- keandalan dan kecepatan di luar kotak;
- dokumentasi yang sangat baik;
- dukungan kontainerisasi buruh pelabuhan.
Batasan alat yang diidentifikasi:
- sistem eksternal dengan penyimpanan data;
- WebSocket - tidak didukung;
- memuat tes (> 150 rps), tetapi Anda dapat menggunakan penyeimbang.
12. Mengapa uji profil ujung ke ujung aplikasi seluler - Vyacheslav Frolov.
Dalam laporannya, Vyacheslav berbicara tentang status autotest di Badoo, yaitu, bagaimana mereka memecahkan masalah untuk memparalelkan 1.500 tes UI seluler, yang membutuhkan waktu 30 jam mesin untuk dijalankan pada satu simulator. Hasilnya, mereka berhasil mencapai hasil 30 menit, yang memungkinkan mereka menjalankan 80 ribu tes per hari. Selain peningkatan daya linear, pengoptimalan diterapkan untuk menghapus cache aplikasi alih-alih memulai ulang simulator. Profiler juga disebutkan dalam laporan, dan bagaimana mereka digunakan untuk mendeteksi kasus-kasus khusus kemacetan dalam tes: misalnya, metode long_press () di ios 11.0 berjalan selama 5 detik, dan setelah optimasi mulai berjalan dalam sedetik, atau bagaimana dengan bantuan http-header. -alive "Anda dapat menghindari membangun kembali koneksi, sehingga secara signifikan mempercepat semua tes sekaligus. Penulis juga memberi tahu cara menampilkan hasil profiler menggunakan alat FlameGraph dan FlameChart.
13. Tes unit: dari teori ke praktik - Vadim Pushtaev.
Penulis membagikan pengalamannya dalam mengembangkan UnitTests. Laporan itu terdiri dari tiga bagian.
- Apa yang kita inginkan dari UT → Regression (Mengubah kode, memeriksa), Mempengaruhi arsitektur (Ketika pengembang menulis tes, kode menjadi lebih baik), Memahami (untuk berurusan dengan kode lama);
- Prinsip → Vadim ingat bahwa teori tidak sebagus praktik. Menolak prinsip "uji antarmuka, bukan implementasinya," karena mungkin ada banyak logika dalam implementasinya. Plus, prinsip "unit test bukan mekanisme pengujian." Dia menganggap ini semacam teknik arsitektur, kuat dan sangat berguna, tetapi ini bukan mekanisme untuk memeriksa dan memperbaiki kode.
- Implementasi → Cerita tentang metode teknis yang digunakan penulis dalam karya (untuk setiap kelas ada satu kelas tes, penciptaan gamer mereka sendiri, penggunaan dependensi eksternal, jika perlu, dll.).
14. Menguji dan menangis dengan Uji Boot Musim Semi - Kirill Tolkachev
Cyril memutuskan untuk mengembalikan kita ke dunia IoC, DI dan Spring dan memberi tahu cara menulis unit dan tes komponen menggunakan JUnit 5 dan SpringBoot.
Nilai tambah besar dari laporan ini adalah bahwa pembicara menulis sebagian besar tes secara real-time, yaitu jelas menunjukkan proses selangkah demi selangkah dari tes pembungkus dengan anotasi Spring. Namun, karena jumlah kode yang besar, sulit untuk menempatkan semua teknik yang ditampilkan di kepala saya. Cyril meninjau fitur Spring untuk bekerja dengan profil, Kacang Mock & Spy, serta pengaturan konfigurasi konteks. Bagi saya, Spring adalah kerangka kerja yang agak berat untuk tugas-tugas seperti itu dan hanya pengguna yang berpengalaman yang tidak dapat menginjak menyapu ketika mengembangkan tes unit.
15. Kami memompa autotest ponsel - Ekaterina Bateeva.
Dalam laporan tersebut, penulis memeriksa alat XCTest untuk mengotomatisasi aplikasi iOS. Menggandakan alat ini pada proyek lain tidak nyaman.
Yaitu, kerugian berikut diidentifikasi:
- sulit untuk membaca pengaturan startup;
- sulit untuk mengkonfigurasi majelis;
- sulit diintegrasikan dengan berbagai layanan;
- tidak nyaman untuk mengelola tangkapan layar;
- tidak nyaman untuk mengkonfigurasi uji ulang.
Selanjutnya, Catherine berbicara tentang kerangka kerja open-source
Fastlane , yang memecahkan masalah mereka.
Ringkasan
Secara umum, saya suka konferensi. Menerima muatan emosi dan jawaban atas pertanyaan yang menarik. Pada sesi BoF, sebagian besar peserta melepas "topeng" mereka dan melakukan diskusi hangat dalam kerangka topik BoF. Istirahat kopi dan makan malam sempurna, selalu ada sesuatu untuk dimakan. Saya juga ingin mencatat organisasi acara - tim JUG.RU setiap kali membuat Heisenbug lebih baik dan lebih baik. Akhirnya - pergi ke konferensi, berbagi pengetahuan yang diperoleh dan tingkatkan keterampilan Anda!
PS: Saya mengucapkan terima kasih kepada Alexei Rumyantsev untuk berpartisipasi dalam persiapan artikel dan kepada Artem Eroshenko untuk materi videonya.