Bisakah kita menjamin suatu program tidak akan salah?


10

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.


8
Salah satu modul RAM di PC saya memiliki tepat satu bit cacat, jadi program yang cukup disayangkan untuk menggunakan bit itu mungkin memberikan hasil yang salah. Menjalankan memtest86 pada mesin Anda mungkin merupakan cara sederhana untuk mengecualikan masalah semacam itu.
user281377

16
ya, dengan menghapusnya
Steven A. Lowe

6
Beberapa perangkat keras sebenarnya memiliki bug. Ini adalah bukti bagi pembuat chip pada hari itu bahwa mereka sangat sedikit. Saya akan mencurigai perangkat lunaknya terlebih dahulu.

Selalu ada alasan logis untuk suatu program salah. Membanting adalah alasan logis.
mouviciel

2
Anda dapat memiliki bom statistik, atau kompiler jahat, atau ram buruk, disk, atau virus yang dapat menulis ke ram Anda atau memodifikasi OS, atau bug OS, atau bug di perpustakaan di suatu tempat, atau bug semacam gabungan yang terkenal, atau ...
Ayub

Jawaban:


8

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

Saya bilang ya, dengan ketentuan - Jika Anda memiliki multi-threading. Pernah mendengar tentang "Kondisi Ras".
mattnz

6

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.


6

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


sedang memikirkan kesalahan pembulatan majemuk sendiri sebagai sumber masalah tersebut. Mereka mungkin tidak muncul untuk waktu yang lama, sampai kombinasi input yang benar (atau salah) mengarah pada mereka semua dan berakhir dengan hasil yang tidak sesuai dengan yang seharusnya.
jwenting

3
Sistem operasi modern tidak mengizinkan program untuk memodifikasi (atau bahkan membaca) memori yang dimiliki oleh program lain.
Péter Török

Ya, OS modern tidak mengizinkan hal semacam itu terjadi.
DeadMG

"Jika Anda memiliki lingkungan komputasi yang sama persis, maka diberi input X untuk sebuah program akan selalu menghasilkan hasil yang sama R" Saya tidak yakin ini benar. Bagaimana jika salah satu kait SR di komponen memori mendapat dua 1 karena beberapa korupsi sebelumnya? en.wikipedia.org/wiki/…
Yam Marcovic

@DeadMG dan Péter Török terima kasih atas tanggapan Anda, saya telah mengedit pesan dan menambahkan referensi ke halaman yang menjelaskan bahwa masalah ini masih dapat terjadi (saya tahu seperti yang disebutkan dalam teks, itu sangat tidak mungkin).
NoChance

5

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.


1
+1 untuk "semua program salah, tetapi beberapa program bermanfaat"
a CVn

Saya kira jawaban ini sebenarnya tidak relevan. Sepertinya dia bertanya apakah program yang benar kadang-kadang dapat beroperasi secara tidak terduga karena beberapa cacat lingkungan.
Yam Marcovic

Maksud saya adalah bahwa tidak ada program yang "benar". Semuanya selalu merupakan pekerjaan yang sedang berjalan, dan hanya benar sampai salah. Bagaimanapun, ilmu komputer adalah ilmu . Saya melihat apa yang Anda katakan, dan itu mungkin lebih di mana fokus pertanyaannya. Namun, saya pikir itu membuat jawaban saya lebih relevan, daripada kurang.
John N

@Hallainzil: Saya yakin saya telah berhasil menulis dengan benar, "Halo, Dunia!" program dan sejenisnya. Saya bahkan sudah menulis program bermanfaat yang benar (walaupun bukan yang besar).
David Thornley

2

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.


1

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?


Melakukan N iterasi dan memverifikasi hasilnya tidak membuktikan kebenaran. Paling-paling, itu membuktikan tidak adanya kesalahan dalam set sampel, dan bahkan itu dengan asumsi bahwa test case Anda (dan pelaksanaannya, serta pelaksanaannya) benar-benar benar. Meskipun pengujian sangat berguna, itu tidak mengatasi masalah OP.
CVn

@Michael Mungkin saya harus mengklarifikasi, saya tidak menyarankan mencoba untuk "membuktikan" apa pun dengan pendekatan ini, tetapi jika berjalan sekian iterasi lagi tanpa pernah menunjukkan kesalahan lagi, saya akan berpikir sunspot dan tidak integer overflow. Itu masih memberi Anda lebih banyak wawasan daripada tidak, IMHO.
jonsca

1

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.


0

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


0

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.


0

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.


Apakah Anda membaca pertanyaannya?
Winston Ewert

Saya lakukan dan saya katakan bahwa dia tidak dapat menggunakan tes untuk menjamin bahwa suatu program tidak akan pernah salah. Itulah yang judul pertanyaannya katakan, bukan?
Raku

Ya, judulnya sepertinya mengatakan itu. Tubuh jelas tidak.
Winston Ewert

0

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.


0

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.


-1

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


Untuk downvoter - saya telah melihat ini terjadi. Sekali.
James McLeod
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.