Chúng tôi có thể đảm bảo một chương trình sẽ không bao giờ sai?

Chúng tôi có một hệ thống ở đây. Gần đây, có một tính toán sai trong một trong những số trong báo cáo được tạo bởi hệ thống. Qua kinh nghiệm của chúng tôi, chúng tôi chưa bao giờ gặp phải bất kỳ vấn đề / lỗi nào trong hệ thống này trong một số năm.

Bởi vì người viết hệ thống này đã biến mất, chúng tôi khó có thể theo dõi các chương trình. Nhưng chúng tôi đã xác minh dữ liệu đầu vào, cài đặt và chúng đúng.

Bây giờ câu hỏi của tôi là, một chương trình máy tính sẽ đột nhiên sai mà không có lý do hợp lý? Nếu tôi đập vào máy chủ, liệu một trong những số mà máy tính đang tính, trở thành một số khác và làm cho phép tính sai?

Tôi đồng ý ý tưởng của tôi khá điên rồ, nhưng tôi chỉ muốn biết, làm thế nào chúng ta có thể biết vấn đề không phải do chương trình và đầu vào gây ra, mà là một số yếu tố khác?

PS Hệ thống điên này không có nhật ký.

Tôi sẽ nói không!

Về lý thuyết, câu trả lời là không, chúng tôi chỉ có thể kiểm tra: -

• một số môi trường hạn chế
• một số giới hạn thời gian.
• một số trường hợp thử nghiệm hạn chế.

Đây là ít hơn đáng kể so với tổng số môi trường, thời gian và trường hợp có thể mà chương trình có thể gặp phải trong vòng đời của nó. Ngoài ra, chúng tôi có ít kiến ​​thức về tương lai, bạn có nên lập trình đối phó với lạm phát 10.000%, chương trình của bạn có nên đối phó với kiến ​​trúc 31 bit siêu mới không?

Lý thuyết được hỗ trợ bởi kinh nghiệm cá nhân tôi đã gặp: -

• Các chương trình bị phá vỡ khi chuyển đến một địa điểm khác. Kiểm tra "CÓ THỂ" khi tháng là "MAI".
• Các chương trình không kiểm tra phiên bản mới của trình biên dịch, Một lỗi trong phiên bản trước kết hợp với một lỗi trong chương trình đã tạo ra kết quả chính xác.
• Các chương trình phá vỡ bản phát hành mới của HĐH. Khi Solaris tăng số lượng mục nhập thư mục mặc định, SMALLINT được trả về bởi ftok () luôn trả về 0 cho tệp đầu tiên trong thư mục.
• các chương trình bị phá vỡ vì đây là lần đầu tiên họ gặp phải một sự kết hợp đầu vào cụ thể, cả hợp lệ và bất ngờ và sẽ không bao giờ được kiểm tra - lãi suất âm đối với tiền gửi, các mặt hàng không trọng lượng được vận chuyển, các mặt hàng có giá trị thấp như vậy Thuế VAT không thể được tính, vv

Về lý thuyết, nếu bạn bắt đầu với trạng thái giống hệt nhau, kết quả sẽ giống hệt nhau. Trong thực tế, việc đảm bảo trạng thái ban đầu giống hệt nhau trong thiết bị "cỡ máy chủ" là không thể.

Lấy các biến chưa được khởi tạo. Nhìn vào mã này:

  short i;

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

Điều này sẽ tạo ra kết quả bất ngờ một lần trong 65536 lần chạy. Và trừ khi bạn đảm bảo bộ nhớ sẽ ở trạng thái tương tự trước mỗi lần chạy, isẽ hoàn toàn ngẫu nhiên.

Có hàng trăm cách tương tự để các lỗi xuất hiện theo các yếu tố không thể đoán trước của trạng thái ban đầu mà ai đó quên ghi đè hoặc các trường hợp biên hiếm khi xảy ra - điều kiện chạy đua trong môi trường đa luồng, ngoài truy cập mảng, IO trên hệ thống tệp bị hỏng và Sớm.

Nếu bạn có thể chứng minh chương trình không có lỗi, chỉ có các tia vũ trụ có thể phá vỡ nó. Nhưng bằng chứng toán học về tính chính xác của bất cứ điều gì phức tạp hơn hai vòng lặp lồng nhau vượt quá phạm vi của các hệ thống lớn nhất (và tiêu tốn một gia tài nhỏ), và đối với tất cả những người còn lại bạn chỉ có thể hy vọng.

Bây giờ câu hỏi của tôi là, một chương trình máy tính sẽ đột nhiên sai mà không có lý do hợp lý?

Nếu bạn có cùng một môi trường điện toán chính xác, thì việc đưa X đầu vào vào một chương trình sẽ luôn tạo ra kết quả tương tự R. Trong thực tế, hiếm khi có một chương trình duy nhất thực hiện tách biệt. Ứng dụng đơn giản nhất hiện nay chạy trong một hệ điều hành và chia sẻ bộ nhớ với các chương trình khác có thể được 'tải' trong bộ nhớ cùng một lúc. Các chương trình này có thể thay đổi bộ nhớ theo cách làm cho một chương trình nhất định bị trục trặc. Đây là một vấn đề nổi tiếng với các biến loại 'con trỏ' chẳng hạn. Thông thường các lỗi như vậy gây ra hành vi hệ thống bất thường và kết quả tính toán không sai.

Trong trường hợp của bạn, tôi cho rằng vấn đề có thể (và thường là) không phải là những gì tôi đã mô tả ở trên. Vấn đề có thể là:

• chương trình đã sử dụng (các) kiểu dữ liệu sai để tính kết quả, lỗi đó chỉ tự biểu hiện khi sử dụng các giá trị đặc biệt.
• chương trình gặp lỗi trong tính toán (do điều kiện logic) nhưng không xử lý lỗi và vẫn tạo ra kết quả. (ví dụ: trộn float và số học số nguyên)
• một quy tắc kinh doanh hoặc một điều kiện logic không được mã hóa chính xác, dữ liệu được nhập đại diện cho điều kiện này nhưng tính toán sai đã được sử dụng. (ví dụ: trừ số tiền từ số tiền tài khoản trước khi kiểm tra số tiền trong tài khoản trước).
• sử dụng các công thức chỉ áp dụng cho phạm vi số nhất định nhưng dữ liệu chứa phạm vi khác nhau. (ví dụ: tính lãi suất dựa trên một loạt các giá trị)

Do những lý do trên và nhiều lý do khác, người dùng phần mềm tốn rất nhiều tài nguyên trong nỗ lực tạo phần mềm chính xác, tuy nhiên, lỗi phần mềm vẫn xảy ra, nhưng lỗi là 'logic' và có lý do, đó chỉ là lý do không rõ ràng đến một số mà không có nghiên cứu tốt. Vì vậy, nói chung phần mềm được kiểm tra là có thể dự đoán và không tạo ra kết quả ngẫu nhiên. Do sự phức tạp của một số chương trình và các yếu tố khác, ngay cả các chương trình được kiểm tra có thể sai nhưng khi điều đó xảy ra, lỗi là vì một lý do hợp lý.

Nếu tôi đập vào máy chủ, liệu một trong những số mà máy tính đang tính, trở thành một số khác và làm cho phép tính sai?

Câu trả lời là không nói chung, phần mềm không dễ vỡ theo nghĩa đó.

Những gì bạn có thể làm là cô lập các trường hợp xảy ra lỗi, tìm sự giống nhau giữa các bộ dữ liệu này gây ra lỗi và tìm sự khác biệt giữa các bộ luận án và các bộ khác tạo ra kết quả chính xác. Bạn có thể xác định bộ giá trị cụ thể gây ra sự cố. Ví dụ, bạn có thể thấy rằng mỗi khi một biến có giá trị âm, kết quả là sai.

Thông tin cập nhật về lỗi hỏng bộ nhớ: Vui lòng xem Tham nhũng bộ nhớ

Bạn có thể đảm bảo một chương trình không có lỗi và sẽ không bao giờ sai? Không, tiếc là không.

Bạn có thể chứng minh rằng một chương trình có một số lượng lỗi nhỏ đủ để chi phí tìm và sửa chúng vượt xa lợi ích từ hành động đó không? Nghe có vẻ như tôi đã có.

Để diễn giải một câu châm ngôn thống kê cũ, tất cả các chương trình đều sai, nhưng một số chương trình là hữu ích.

Tôi có xu hướng nói không , bạn không thể chứng minh rằng một chương trình sẽ không bao giờ sai hoặc cung cấp một kết quả không chính xác, ngay cả khi bạn có thể giả sử đầu vào hoàn hảo.

Raku đề cập đến bằng chứng chính thức của sự đúng đắn. Đó là một điều cần xem xét, nhưng trừ khi tôi hoàn toàn nhầm lẫn, điều đó vẫn sẽ phải đảm nhận một môi trường thực thi hoàn hảo. Vì vậy, với một lượng thời gian và nỗ lực, có lẽ bạn có thể chứng minh rằng chương trình là chính xác , nhưng điều đó không nhất thiết phải chứng minh rằng nó sẽ luôn tạo ra kết quả chính xác , thậm chí cho đầu vào hoàn hảo. Môi trường thực thi có vấn đề. Và tôi cũng sẽ cảnh giác khi cho rằng đầu vào luôn luôn hoàn hảo.

Đây là lý do tại sao, trong một số tình huống có tính sẵn sàng cao, nhiều môi trường thực thi và thực thi hoàn toàn độc lập được sử dụng và kết quả được so sánh để đảm bảo rằng chúng nằm trong phạm vi sai số chấp nhận được từ nhau. Trong một số tình huống, biên độ đó rất có thể bằng không. Ngay cả vào những năm 1960, điều này được coi là đủ quan trọng để bao gồm các bộ phần cứng máy tính riêng biệt trong tàu vũ trụ. Ngay cả khi phóng tĩnh điện, tia vũ trụ hoặc bất cứ thứ gì ảnh hưởng đến cả hai máy tính, thì tỷ lệ cả hai sẽ bị ảnh hưởng theo cùng một cách (đặc biệt nếu cả hai vẫn hoạt động và tạo ra kết quả trông hợp lệ) là rất nhỏ. Tỷ lệ của cùng một lỗi leo vào hai triển khai hoàn toàn riêng biệt cũng cực kỳ nhỏ. Và như thế.

Hầu hết (tiêu chuẩn) tính toán là xác định, tôi sẽ nghĩ.

Nếu có thể, hãy thiết lập nó để thực hiện một đợt 1000 hoặc 10000, v.v., lặp lại với cùng một dữ liệu đầu vào và xác minh rằng các kết quả có giống nhau không.

Hãy chắc chắn rằng các giá trị hiện tại đi vào tính toán sẽ gây ra tình trạng tràn hoặc tràn ở bất cứ đâu (nếu đó là một hệ thống cũ hơn thì nó có thể không được dự định sử dụng lâu như vậy).

Y2K11 có ai không?

Trừ khi bạn có thể điều khiển từng bit trong máy và từng bit xung điện chạy qua mạch điện, thì bạn không thể đảm bảo chắc chắn rằng có gì đó không ổn với chương trình của bạn. Các mô-đun bộ nhớ bị lỗi, CPU có thể bị quá nóng và gây ra lỗi, ổ cứng có thể làm xáo trộn dữ liệu và nguồn cung cấp năng lượng có thể đưa tiếng ồn vào hệ thống. Phần cứng càng đắt tiền và phần cứng càng dư thừa thì những điều này càng ít xảy ra, nhưng đến một lúc nào đó phần cứng có thể thất bại.

Sau đó, bạn có hệ điều hành, với các lỗi có thể được đánh dấu bằng cách phức tạp nhất có nghĩa là có thể tưởng tượng. Trình biên dịch cũng có thể có các lỗi tối nghĩa chỉ chờ để khéo léo biến mã nguyên sơ của bạn thành các lỗi khó theo dõi. Đó là một khu rừng rậm ngoài kia, và phần mềm nghèo nàn của bạn dễ bị tổn thương bởi tất cả những điều này. COI CHƯNG!

Và theo kinh nghiệm của tôi, thường xuyên hơn không, bất cứ khi nào có lỗi trong tính toán, chúng tôi không bao giờ phải đào gần đến mức đó để tìm ra thủ phạm. Nói chung, hầu hết tất cả các lỗi tôi thấy trong thế giới doanh nghiệp đều dễ dàng tìm thấy với các công cụ gỡ lỗi phù hợp và một số mỡ khuỷu tay.

Nói cách khác, trong khi phần cứng và HĐH có thể không hoàn hảo, bạn có thể sẽ không bao giờ phải lo lắng về mức độ chi tiết đó. Chỉ cần tìm một người biết ngôn ngữ và có ích với trình gỡ lỗi và đào sâu vào.

"giải thích đơn giản hơn, những thứ khác đều bằng nhau, thường tốt hơn những thứ phức tạp hơn." - Tóm tắt về Occam's Razor.

Có, đánh vào một hệ thống có thể uốn cong và / hoặc di chuyển các bộ phận đủ để gây ra một mạch hở tạm thời (hoặc có thể bị đoản mạch, mặc dù có lẽ ít khả năng hơn).

Máy tính đầu tiên tôi sở hữu là Altair 8080 với bộ nhớ 256 byte. Đầu vào là từ các công tắc điều khiển và đầu ra là từ một vài đèn nhấp nháy. Nếu bạn không cho phép các tia vũ trụ và lỗi phần cứng, tôi tin rằng tôi có thể chứng minh rằng một số chương trình tôi chạy trên nó sẽ luôn tạo ra kết quả tương tự.

Kể từ đó, không.

Thử nghiệm cho thấy sự hiện diện, không phải là không có lỗi (Edsger W. Dijkstra)

Nếu bạn đang cố chứng minh rằng chương trình của bạn hoạt động chính xác bằng cách thử nghiệm, nó sẽ không hoạt động.

Tuy nhiên, có một số cách tiếp cận trong khoa học máy tính lý thuyết nơi bạn phát triển một bằng chứng chính thức về phần mềm bạn đã viết. Tùy thuộc vào sự phức tạp của hệ thống của bạn, đây có thể là một quá trình tẻ nhạt. Tuy nhiên, nếu hệ thống của bạn hoạt động trên một nhóm lệnh bị hạn chế, bạn có thể thành công với phương pháp này.

Môi trường phần cứng và phần mềm luôn trong tình trạng thay đổi liên tục. Các bộ phận chuyển động, điện, nhiệt độ, bụi và thay đổi mã hệ điều hành là những ví dụ.

Do đó, tôi không nghĩ rằng thậm chí có thể xảy ra hoặc dự kiến ​​rằng một chương trình phần mềm máy tính sẽ luôn hoạt động giống nhau vì môi trường luôn thay đổi.

Phần mềm có thể chạy trong một thời gian dài như mong đợi, nhưng cuối cùng, một thay đổi nhỏ đối với phần mềm hệ điều hành máy chủ sẽ thay đổi sẽ ảnh hưởng đến chương trình được đề cập hoặc phần cứng sẽ có giá trị.

Tôi đang nói về máy tính ngày nay.

Bây giờ câu hỏi của tôi là, một chương trình máy tính sẽ đột nhiên sai mà không có lý do hợp lý? Nếu tôi đập vào máy chủ, liệu một trong những số mà máy tính đang tính, trở thành một số khác và làm cho phép tính sai?

Câu trả lời cho câu hỏi đó là không thể biết được. Không thể chứng minh rằng bất cứ điều gì luôn đúng với vũ trụ mà chúng ta đang sống. Thay vào đó chúng ta đưa ra các giả định và chứng minh rằng nếu các giả định giữ, thì một số tài sản phức tạp cũng sẽ nắm giữ. Đây là những gì chính thức xác nhận chương trình đảm bảo. Hầu hết các chương trình không được xác minh chính thức, thay vào đó, họ cố gắng xây dựng sự tự tin bằng cách cung cấp các bài kiểm tra. Các thử nghiệm này cung cấp cho bạn sự đảm bảo rằng cung cấp các thử nghiệm thực hiện những gì chúng được thiết kế để thực hiện và các giả định mà bạn đã thực hiện, chương trình bạn đang sử dụng sẽ hoạt động ít nhất một thời gian.

Vấn đề chỉ là do RAM bị hỏng, nhưng điều này tương đối (rất) không thể xảy ra. Chạy kiểm tra bộ nhớ, nhưng sẵn sàng xem qua mã.