Bisakah kita menjamin suatu program tidak akan salah?

Kami punya sistem di sini. Baru-baru ini ada perhitungan yang salah di salah satu nomor dalam laporan yang dihasilkan oleh sistem. Sepanjang pengalaman kami, kami tidak pernah menemukan masalah / kesalahan dalam sistem ini selama beberapa tahun.

Karena penulis sistem ini sudah pergi, kita hampir tidak dapat melacak program. Tetapi kami telah memverifikasi data input, pengaturan dan mereka benar.

Sekarang pertanyaan saya adalah, apakah program komputer tiba-tiba salah tanpa alasan logis? Jika saya membanting mesin server, akankah salah satu angka yang dihitung komputer, menjadi nomor lain dan membuat perhitungan salah?

Saya setuju ide saya ada yang cukup gila, tapi saya hanya ingin tahu, bagaimana kita bisa tahu masalahnya bukan disebabkan oleh program dan input, tetapi beberapa faktor lainnya?

PS Sistem gila ini tidak memiliki log.

Saya akan mengatakan tidak!

Secara teori jawabannya tidak, kita hanya dapat menguji untuk: -

• sejumlah lingkungan terbatas.
• beberapa skala waktu terbatas.
• sejumlah kasus uji terbatas.

Ini jauh lebih kecil dari jumlah total kemungkinan lingkungan, waktu dan kasus yang mungkin dihadapi program dalam masa pakainya. Kami juga memiliki sedikit pengetahuan tentang masa depan haruskah Anda memprogram mengatasi inflasi 10.000%, haruskah program Anda mengatasi arsitektur 31 bit baru yang super duper?

Teori ini didukung oleh pengalaman yang saya pribadi temui: -

• Program rusak ketika dipindahkan ke lokal yang berbeda. Memeriksa "MEI" ketika bulan itu "MAI".
• Program gagal tes pada versi baru dari kompiler, Bug di versi sebelumnya bersama dengan bug di program menghasilkan hasil yang benar.
• Program melanggar rilis OS baru. Ketika Solaris meningkatkan jumlah entri direktori default, SMALLINT yang dikembalikan oleh ftok () selalu mengembalikan nol untuk file pertama dalam direktori.
• program melanggar karena ini adalah pertama kalinya mereka menemukan kombinasi input tertentu, yang valid dan tidak terduga dan tidak akan pernah diuji untuk - suku bunga negatif pada deposito, nol item berat yang akan dikirim, item bernilai rendah sehingga PPN tidak bisa dihitung dll. Dll

Secara teori, jika Anda mulai dengan keadaan identik, hasilnya akan sama. Pada kenyataannya, memastikan keadaan awal yang identik dalam peralatan "berukuran server" hampir tidak mungkin.

Ambil variabel yang tidak diinisialisasi. Lihatlah kode ini:

  short i;

  if(i==-1)
  {
        //do something special
  }
  else
  {
        i=0;
        //do something else
  }

Ini akan menghasilkan hasil yang tidak terduga satu kali dalam 65536 berjalan. Dan kecuali Anda memastikan memori akan berada dalam kondisi yang sama sebelum setiap kali dijalankan, iakan sepenuhnya acak.

Ada ratusan cara serupa untuk kesalahan yang muncul mengikuti elemen tak terduga dari keadaan awal seseorang lupa untuk menimpa, atau kasus perbatasan yang jarang terjadi - kondisi balapan di lingkungan multi-threaded, akses array di luar batas, disk IO pada sistem file yang rusak, dan begitu seterusnya.

Jika Anda dapat membuktikan bahwa program tersebut bebas bug, hanya ada sinar kosmik yang dapat memecahkannya. Tetapi bukti matematis tentang kebenaran dari sesuatu yang lebih kompleks dari dua loop bersarang cukup banyak di luar ruang lingkup sistem terbesar (dan biayanya kecil), dan untuk semua yang lain Anda hanya bisa berharap.

Sekarang pertanyaan saya adalah, apakah program komputer tiba-tiba salah tanpa alasan logis?

Jika Anda memiliki lingkungan komputasi yang sama persis, maka diberi input X untuk suatu program akan selalu menghasilkan hasil yang sama R. Dalam praktiknya, jarang ada satu program yang dijalankan secara terpisah. Aplikasi paling sederhana saat ini berjalan dalam sistem operasi dan berbagi memori dengan program lain yang mungkin 'dimuat' dalam memori pada saat bersamaan. Program-program ini dapat mengubah memori dengan cara yang membuat kerusakan program yang diberikan. Ini adalah masalah terkenal dengan variabel tipe 'pointer' misalnya. Biasanya kesalahan tersebut menyebabkan perilaku sistem tidak normal dan tidak salah hasil perhitungan.

Dalam kasus Anda, saya berasumsi bahwa masalahnya mungkin (dan biasanya) bukan seperti yang saya jelaskan di atas. Masalahnya mungkin:

• program menggunakan tipe data yang salah untuk menghitung hasilnya, kesalahan itu hanya memanifestasikan dirinya ketika nilai-nilai khusus digunakan.
• program mengalami kesalahan dalam perhitungan (karena kondisi logis) tetapi tidak menangani kesalahan dan masih menghasilkan hasilnya. (mis. mencampur aritmetika float dan integer)
• aturan bisnis atau kondisi logis tidak dikodekan dengan benar, data yang dimasukkan mewakili kondisi ini tetapi perhitungan yang salah digunakan. (mis. kurangi jumlah dari jumlah akun sebelum memeriksa jumlah di akun terlebih dahulu).
• menggunakan rumus yang hanya berlaku untuk rentang angka tertentu tetapi data mengandung rentang yang berbeda. (mis. menghitung suku bunga berdasarkan rentang nilai)

Karena alasan di atas dan banyak alasan orang perangkat lunak menghabiskan begitu banyak sumber daya dalam upaya untuk membuat perangkat lunak yang benar, namun, kesalahan perangkat lunak masih terjadi, tetapi kesalahannya 'logis' dan punya alasan, hanya saja alasannya tidak jelas. untuk beberapa tanpa penelitian yang baik. Jadi, secara umum perangkat lunak yang diuji dapat diprediksi dan tidak menghasilkan hasil acak. Karena kompleksitas beberapa program, dan faktor-faktor lain, bahkan program yang diuji dapat salah tetapi ketika itu terjadi, kesalahan adalah karena alasan logis.

Jika saya membanting mesin server, akankah salah satu angka yang dihitung komputer, menjadi nomor lain dan membuat perhitungan salah?

Jawabannya tidak secara umum, perangkat lunak tidak rapuh dalam arti itu.

Apa yang dapat Anda lakukan adalah mengisolasi kasus-kasus di mana kesalahan terjadi, menemukan kesamaan antara set data ini yang menyebabkan kesalahan dan menemukan perbedaan antara set tesis dan set lainnya yang menghasilkan hasil yang benar. Anda mungkin dapat mengidentifikasi serangkaian nilai spesifik yang menyebabkan masalah. Misalnya, Anda mungkin menemukan bahwa setiap kali suatu variabel memiliki nilai negatif, hasilnya salah.

Informasi terbaru tentang kesalahan kerusakan memori: Silakan lihat Korupsi Memori

Bisakah Anda menjamin suatu program tidak memiliki bug dan tidak akan pernah salah? Tidak, sayangnya tidak.

Dapatkah Anda menunjukkan bahwa suatu program memiliki jumlah bug yang cukup kecil sehingga biaya untuk menemukan dan memperbaikinya jauh melebihi manfaat dari tindakan itu? Bagi saya, sepertinya sudah Anda miliki.

Mengutip pepatah statistik lama, semua program salah, tetapi beberapa program bermanfaat.

Saya cenderung mengatakan tidak , Anda tidak dapat membuktikan bahwa suatu program tidak akan salah atau memberikan hasil yang salah, bahkan jika Anda dapat menerima input yang sempurna.

Raku menyebutkan bukti formal kebenaran. Itu satu hal yang perlu dipertimbangkan, tetapi kecuali saya benar-benar salah, itu masih harus mengasumsikan lingkungan eksekusi yang sempurna. Jadi, dengan sejumlah waktu dan usaha, Anda mungkin dapat membuktikan bahwa program itu benar , tetapi itu tidak selalu membuktikan bahwa itu akan selalu menghasilkan hasil yang benar , bahkan diberikan masukan yang sempurna. Lingkungan eksekusi penting. Dan saya akan berhati-hati dalam mengasumsikan bahwa inputnya selalu sempurna.

Inilah sebabnya mengapa, dalam situasi ketersediaan tinggi tertentu, banyak, implementasi sepenuhnya independen dan lingkungan eksekusi digunakan, dan hasilnya dibandingkan untuk memastikan bahwa mereka berada dalam margin kesalahan yang dapat diterima dari satu sama lain. Dalam beberapa situasi, margin itu mungkin nol. Bahkan di tahun 1960-an, ini dianggap cukup penting untuk memasukkan perangkat komputasi terpisah dalam pesawat ruang angkasa. Bahkan jika pelepasan statis yang salah, sinar kosmik atau apa pun yang mempengaruhi kedua komputer secara bersamaan, kemungkinan bahwa keduanya akan terpengaruh dengan cara yang sama (terutama jika keduanya masih bekerja dan menghasilkan hasil yang tampak valid) sangat kecil. Peluang bug yang sama merayap ke dalam dua implementasi yang sepenuhnya terpisah juga sangat kecil. Dan seterusnya.

Kebanyakan komputasi (standar) bersifat deterministik, saya pikir.

Jika memungkinkan, atur untuk melakukan batch 1000 atau 10000, dll., Iterasi dengan data input yang sama, dan verifikasi bahwa hasilnya keluar sama.

Pastikan nilai saat ini yang masuk ke dalam perhitungan akan menyebabkan over-atau underflow di mana saja (jika ini adalah sistem yang lebih lama mungkin tidak dimaksudkan untuk digunakan selama ini).

Y2K11 siapa saja?

Kecuali jika Anda dapat mengontrol setiap bit di mesin, dan setiap bit impuls listrik mengalir melalui sirkuit, maka Anda tidak dapat menjamin dengan kepastian mutlak bahwa ada sesuatu yang tidak akan salah dengan program Anda. Modul memori gagal, CPU bisa kepanasan dan menyebabkan kesalahan, hard drive dapat mengacak data, dan catu daya dapat menimbulkan gangguan pada sistem. Semakin mahal perangkat keras, dan semakin banyak perangkat keras, semakin kecil kemungkinan hal-hal ini akan terjadi, tetapi pada titik tertentu perangkat keras dapat gagal.

Kemudian Anda memiliki sistem operasi, dengan bug yang dapat digelitik dengan cara paling misterius yang bisa dibayangkan. Kompiler juga mungkin memiliki bug yang tidak jelas, hanya menunggu untuk dengan cekatan mengubah kode asli Anda menjadi bug yang sulit dilacak. Itu hutan di luar sana, dan perangkat lunak Anda yang buruk rentan terhadap semua ini. MENCARI!

Dan dalam pengalaman saya, lebih sering daripada tidak, setiap kali ada bug dalam perhitungan, kita tidak perlu menggali sejauh itu untuk menemukan pelakunya. Secara umum, hampir semua bug yang saya lihat di dunia korporat mudah ditemukan dengan alat debugging yang tepat, dan beberapa minyak siku.

Dengan kata lain, sementara perangkat keras dan OS mungkin tidak sempurna, Anda mungkin tidak perlu khawatir tentang tingkat detailnya. Temukan saja seseorang yang mengerti bahasa tersebut, dan berguna dengan debugger, dan gali.

"Penjelasan yang lebih sederhana adalah, hal-hal lain dianggap sama, umumnya lebih baik daripada yang lebih kompleks." - Summarization dari Occam's Razor.

Ya, memukul suatu sistem dapat menekuk dan / atau menggerakkan bagian yang cukup untuk menyebabkan korsleting sementara (atau mungkin korsleting, meskipun kemungkinan kecil).

Komputer pertama yang saya miliki adalah Altair 8080 dengan memori 256 Bytes. Input berasal dari sakelar konsol dan output berasal dari beberapa lampu yang berkedip. Jika Anda melarang sinar kosmik dan kegagalan perangkat keras, saya yakin saya dapat membuktikan bahwa beberapa program yang saya jalankan akan selalu menghasilkan hasil yang sama.

Sejak itu, tidak.

Pengujian menunjukkan keberadaan, bukan tidak adanya bug (Edsger W. Dijkstra)

Jika Anda mencoba membuktikan bahwa program Anda bekerja dengan benar dengan pengujian, itu tidak akan berhasil.

Namun, ada beberapa pendekatan dalam ilmu komputer teoretis di mana Anda mengembangkan bukti formal dari perangkat lunak yang Anda tulis. Tergantung pada kompleksitas sistem Anda, ini bisa menjadi proses yang membosankan. Namun, jika sistem Anda bekerja pada serangkaian perintah terbatas, Anda bisa berhasil dengan pendekatan ini.

Lingkungan perangkat keras dan perangkat lunak selalu berubah-ubah. Komponen bergerak, listrik, suhu, debu, dan perubahan kode OS adalah contohnya.

Oleh karena itu saya tidak berpikir itu mungkin atau diharapkan bahwa program perangkat lunak komputer akan selalu berperilaku sama karena lingkungan selalu berubah.

Perangkat lunak dapat berjalan untuk waktu yang lama seperti yang diharapkan, tetapi pada akhirnya perubahan kecil pada perangkat lunak host OS akan berubah yang akan mempengaruhi program yang dipermasalahkan atau perangkat keras akan menghargai.

Saya berbicara tentang komputer saat ini.

Sekarang pertanyaan saya adalah, apakah program komputer tiba-tiba salah tanpa alasan logis? Jika saya membanting mesin server, akankah salah satu angka yang dihitung komputer, menjadi nomor lain dan membuat perhitungan salah?

Jawaban atas pertanyaan itu tidak diketahui. Mustahil untuk membuktikan bahwa segala sesuatu selalu benar tentang alam semesta tempat kita hidup. Sebaliknya kita membuat asumsi dan membuktikan bahwa jika asumsi itu berlaku, maka beberapa sifat rumit juga akan berlaku. Inilah yang dijamin oleh program yang diverifikasi secara formal. Sebagian besar program tidak diverifikasi secara formal, mereka malah mencoba membangun kepercayaan diri dengan memberikan tes. Tes-tes ini memberi Anda jaminan bahwa asalkan tes melakukan apa yang dirancang untuk dilakukan dan bahwa asumsi yang Anda miliki berlaku, program yang Anda gunakan akan bekerja setidaknya beberapa waktu.

Hampir tidak mungkin masalah disebabkan oleh kegagalan RAM, tetapi ini relatif (sangat) tidak mungkin. Jalankan tes memori, tetapi bersiaplah untuk melihat kode.