Bagaimana meyakinkan anggota tim tentang keberadaan "mandelbug"


20

Kami sedang mengembangkan aplikasi; itu termasuk perpustakaan yang dikembangkan oleh coder lain, perpustakaan ini berkomunikasi dengan server melalui beberapa koneksi jaringan, dan ini melibatkan banyak utas yang bekerja bersama. Kode sisi server cukup rumit, dan kami tidak memiliki akses ke kode sumber.

Baru-baru ini saya menemukan kadang-kadang mandelbug membuat crash aplikasi. Saya bisa mereproduksi sekali dan mendapat jejak tumpukan, jadi saya membuka laporan bug. Bug itu sendiri mudah diperbaiki (pengecualian web yang tidak tertangkap di salah satu utas latar belakang, yang membuat CLR menghentikan program).

Masalahnya adalah bahwa pengembang menolak untuk memperbaiki bug, karena "dia tidak yakin itu ada". Sayangnya bagi saya bos berpihak padanya dan mengatakan bug ini tidak dapat diperbaiki kecuali saya membuat "test case solid" untuk membuktikan keberadaan bug, dan untuk membuat unit test memverifikasi bahwa itu hilang. Apa yang pada dasarnya tidak mungkin karena sifat bug.

Ada saran?


12
Saya akan mengatakan itu sangat sederhana. Buat unit test yang membuktikan apa yang Anda katakan itu benar.
Charles Sprayberry

1
Sudahkah Anda menyimpan stacktrace dalam beberapa bentuk? Misalnya apakah Anda memiliki tangkapan layar IDE Anda yang menunjukkan stacktrace dari crash?
Giorgio

7
@ fithu: Anda sedikit terlalu yakin bahwa mereproduksi bug semacam itu tidak mungkin - mungkin sulit, tetapi jarang "mustahil". Dan bagaimana Anda bisa tahu bahwa bug itu "mudah diperbaiki" ketika Anda tidak memiliki akses ke kode sumber? Hanya menangkap pengecualian mungkin tidak benar-benar memperbaiki masalah. Atau apakah Anda berbicara tentang kode perpustakaan yang dapat Anda akses, dan Anda sudah menentukan dengan tepat baris tempat bug itu terjadi? Jika demikian, mengapa Anda tidak menyarankan perbaikan kode?
Doc Brown

2
@ fithu: judul asli Anda adalah semacam kata-kata kasar terhadap bos Anda. Saya mengubahnya dengan harapan itu mencegah penutupan pertanyaan Anda, kata-kata kasar tidak terlalu populer di situs ini. Jika judul baru tidak mencerminkan pertanyaan Anda dengan benar, silakan memperbaikinya lebih lanjut.
Doc Brown

4
@Giorgio: jejak stack adalah bukti bahwa suatu program dapat crash pada baris tertentu, itu tidak membuktikan bahwa baris ini adalah akar penyebab bug. Itu tampaknya fakta bahwa OP tampaknya telah salah paham, dan penyebab mengapa saya memiliki masalah untuk memahami beberapa detail pertanyaan.
Doc Brown

Jawaban:


35

Jika mungkin, mungkin perlu waktu untuk memeriksa apakah cacat ini dapat direproduksi dengan meletakkan beberapa tidur atau memblokir kode aplikasi Anda. Namun jangan terlalu banyak menghabiskan waktu. Karena masalah ini disebabkan oleh multi-theading (dan juga seperti yang Anda amati), kejadiannya jarang terjadi.

Saran saya adalah jangan terlalu memikirkan hal ini. Lanjutkan pekerjaan Anda. Setiap kali Anda menemukan kerusakan ini, perbarui laporan bug Anda dengan jejak tumpukan, mengatakan bahwa ini adalah kejadian berulang , dan mengubah pemilik menjadi pengembang perpustakaan. Biarkan manajemen / pemimpin memutuskan apakah akan memperbaiki atau tidak, tergantung pada frekuensinya.

Coba juga untuk memahami mentalitas pengembang. Anda mengatakan "pengecualian web yang tidak tertangkap". Pengembang pada tahap ini mungkin tidak sepenuhnya yakin apa yang akan menjadi efek lain dari penangkapan ini . Jadi dia mungkin enggan menyentuh kode tersebut.


10

Jadi, dari komentar klarifikasi Anda kurang lebih, saya mengerti seperti ini:

Anda yakin hanya ada pengecualian tambahan sederhana yang menangani masalah yang hilang, dan Anda sudah tahu baris kode mana di lib yang bermasalah dan bagaimana lib dapat diperbaiki.

Lalu mengapa Anda tidak menambahkan beberapa baris kode yang hilang ke lib sendiri, minta tim untuk menguji lib dengan perubahan itu? Pastikan itu adalah perubahan berisiko rendah, mudah dimengerti oleh dev yang bertanggung jawab atas lib. Hal terburuk yang bisa terjadi adalah seseorang harus mengembalikan perubahan itu di VCS Anda jika perbaikan Anda menyebabkan beberapa perilaku baru yang tidak terduga.

Kebanyakan orang lebih mudah diyakinkan ketika pekerjaan sudah dilakukan. Juga, mereka bereaksi lebih baik pada "ini solusi yang ditingkatkan", menentang "kode ini salah, perbaiki entah bagaimana".

EDIT: ketika dev masih menolak untuk menambahkan perubahan itu, opsi terbaik adalah mencoba untuk membuat kode bermasalah bekerja di dalam test harness yang terisolasi di mana Anda mensimulasikan kesalahan jaringan. Bekerja secara efektif dengan kode lama menjelaskan banyak teknik tentang cara mengatasi masalah seperti itu. Misalnya, Anda dapat membuat versi uji perpustakaan, termasuk hanya modul dan fungsi yang bermasalah, dan membuat "lingkungan tiruan" di sekitarnya tempat Anda dapat mensimulasikan "pengecualian jaringan" di bawah kondisi yang terkendali. Itu mungkin tampak terlalu banyak upaya pada pandangan pertama, tetapi begitu Anda memiliki lingkungan seperti itu, Anda dapat menambahkan banyak tes tambahan untuk itu (dan saya kira itu masuk akal, karena ketika penulis lib menolak untuk menambahkan yang hilang penanganan pengecualian di satu tempat,


Dia menolak untuk menggabungkan perubahan ini, karena "itu tidak perlu"
fithu

@ fithu: lihat edit saya.
Doc Brown

4
@DocBrown +1 untuk Mereka (orang) bereaksi lebih baik pada "ini solusi yang ditingkatkan", menentang "kode ini salah, perbaiki entah bagaimana caranya".
laika

2
@ Fithu: Jadi datang dengan test case yang memicu pengecualian tidak tertangani untuk dilemparkan. Yaitu mencari tahu paramaters yang memicu itu.
wirrbel

2

Untuk bug seperti ini, pengujian fuzz otomatis (juga disebut pengujian acak) mungkin membantu dalam mencoba mereproduksinya. Ini mengotomatiskan proses menemukan bug dengan mengacak satu set parameter (atau input) yang tetap ke dalam hal yang Anda uji. Setiap pengujian dijalankan, parameter dicatat ke file log, termasuk stempel waktu, dll. Sehingga ketika kerusakan terjadi, Anda dapat (secara teoritis) mengulang kembali pengujian, menggunakan parameter yang sama, untuk mereproduksinya.

Sejak terotomatisasi, proses pengujian dapat menjalankan banyak tes dalam waktu singkat. Seringkali dapat dibiarkan berjalan semalam, dan di pagi hari Anda dapat memeriksa file log untuk melihat apakah itu mereproduksi crash.


3
"hanya memutar ulang tes, menggunakan parameter yang sama, untuk mereproduksinya" - tidak mungkin untuk masalah threading / jaringan. Tapi saya suka ide itu.
fithu

2

Pengacara Setan menyarankan jalan lain.

Pengembang lain telah menyatakan, dengan tegas, bahwa tidak ada bug di sana.

Bisakah Anda menemukan cara untuk menekan keluar dari bug yang diduga tidak ada, dan menyebabkannya lebih sering crash?


2

Jejak tumpukan adalah bukti yang jelas bahwa bug itu ada, atau setidaknya memang ada di build tertentu. Apa yang tidak Anda miliki adalah bukti bahwa bug telah diperbaiki. Mereka bodoh mengabaikannya. Saya mengalami "tidak mungkin mereproduksi" bug setelah ratusan ribu percobaan otomatis pada beberapa sistem yang dipicu setiap saat pada sistem pelanggan.

Saya mendapatkan beberapa bug seperti itu per tahun, sebagian besar bahkan tanpa manfaat dari tumpukan jejak. Dalam hampir setiap kasus, meskipun saya tidak dapat mereproduksi sebelumnya, saya dapat dengan mudah membuat tes otomatis untuk itu setelah diperbaiki.

Sebagai contoh, beberapa bulan yang lalu saya memperbaiki bug yang hanya terjadi ketika pengguna mengetik lebih cepat dari 96 kata per menit. Sebelum saya memperbaikinya, yang saya tahu adalah bahwa bug itu terjadi "kadang-kadang." Tidak pernah terpikir oleh saya untuk menulis unit test untuk mengetik cepat. Namun, setelah saya tahu akar masalahnya, membuat tes untuk itu adalah sepele.

Bahkan dalam kasus-kasus langka di mana bug tidak dapat direproduksi bahkan setelah diperbaiki, Anda dapat menutupnya dengan inspeksi kode.


bagaimana Anda melakukan tes otomatis untuk hal-hal seperti itu? (untuk menghindari kesalahpahaman, semua yang Anda tulis sesuai dengan pengalaman dan keyakinan saya sendiri) Bug saya yang terbaru seperti itu adalah perlombaan data untuk akses bersamaan yang tidak disinkronkan, baik bug dan perbaikannya sangat mudah dibuktikan dengan inspeksi kode tetapi saya tidak bisa bayangkan cara andal uji otomatis itu. (Saya kebanyakan memiliki sedikit masalah merancang tes untuk hal-hal bersamaan tetapi tidak dapat menemukan kode tes untuk membuktikan tidak adanya perlombaan data)
Agas

1
Itu mungkin termasuk dalam pengecualian inspeksi kode saya, tetapi Anda juga dapat memicu kondisi balapan dengan memasukkan penundaan pada salah satu utas. Seringkali Anda dapat melakukan ini dengan menunda stimulus eksternal, atau kurang idealnya, Anda dapat menempatkan penundaan langsung ke dalam kode selama pengujian.
Karl Bielefeldt

Begitu ya, terima kasih. Kedengarannya menarik, saya perlu memikirkannya ...
Agas
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.