Чи можемо ми гарантувати, що програма ніколи не помилиться?

У нас тут є система. Останнім часом відбувається неправильний підрахунок однієї з цифр у звіті, згенерованих системою. Зважаючи на наш досвід, ми ніколи не стикалися з жодними проблемами / помилками в цій системі протягом декількох років.

Оскільки автор цієї системи вже пішов, ми навряд чи можемо простежити програми. Але ми перевірили вхідні дані, налаштування і вони правильні.

Тепер моє запитання полягає в тому, чи несподівано комп’ютерна програма раптом піде не так, без логічної причини? Якщо я грюкну на серверній машині, чи стане одне з числа, яке обчислює комп'ютер, стане іншим числом і зробить обчислення неправильним?

Я погоджуюсь, що моя ідея там досить божевільна, але я просто хочу знати, як ми можемо знати, що проблема викликана не програмою та вхідними даними, а деякими іншими факторами?

PS Ця божевільна система не має журналу.

Я б сказав: ні!

Теоретично відповідь - ні, ми можемо перевірити лише:

• деяка обмежена кількість середовищ.
• деяка обмежена кількість часових масштабів.
• деяка обмежена кількість тестових випадків.

Це значно менше загальної можливої ​​кількості середовищ, часу та випадків, з якими програма може зіткнутися протягом свого життя. Крім того, ми маємо мало знань про майбутнє, чи потрібно ви програмі справлятися з інфляцією на 10 000%, чи повинна ваша програма справлятися із супер-пупер новою 31-бітовою архітектурою?

Ця теорія підкріплена досвідом, з яким я особисто стикався: -

• Програми, які розбиваються при переміщенні в інший локальний пункт Перевірка "МАЙ", коли місяць був "МАЙ".
• Програми з відмовою від тестів на новій версії компілятора. Помилка в попередній версії спільно з помилкою в програмі дала правильний результат.
• Програми, які виходять з нового випуску ОС. Коли Solaris збільшила за замовчуванням кількість записів каталогів, SMALLINT, повернений ftok (), завжди повертав нуль для першого файлу в каталозі.
• програми порушуються, оскільки вперше вони зіткнулися з певною комбінацією вхідних даних, які були як дійсними, так і несподіваними і ніколи б не були перевірені - негативні процентні ставки за депозитами, позиції з нульовою вагою, що підлягають відвантаженню, предмети такої низької вартості, що ПДВ не можна нарахувати тощо. Тощо.

Теоретично, якщо ви почнете з однакового стану, результат буде ідентичним. Насправді, забезпечити однаковий початковий стан обладнання "розміром з сервером" - це майже неможливо.

Візьміть неініціалізовані змінні. Подивіться на цей код:

  short i;

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

Це дасть неочікувані результати один раз у 65536 пробігів. І якщо ви не запевняєте, що пам'ять буде перебувати в одному стані перед кожним запуском, iбуде абсолютно випадковою.

Існує сотні подібних способів помилок, що з’являються після непередбачуваних елементів початкового стану, які хтось забув переосмислити, або випадки межі, які трапляються рідко - умови перегонів у багатопотоковому середовищі, поза межами масиву доступу, диск IO у пошкодженій файловій системі та так далі.

Якщо ви можете довести, що програма відсутня помилок, є лише космічні промені, які можуть її порушити. Але математичне підтвердження правильності чого-небудь складнішого, ніж дві вкладені петлі, значно виходить за рамки найбільших систем (і коштує малого статку), і на все інше ви можете лише сподіватися.

Тепер моє запитання полягає в тому, чи несподівано комп’ютерна програма раптом піде не так, без логічної причини?

Якщо у вас точно однакове обчислювальне середовище, то при введенні X в програму завжди буде видаватися однаковий результат R. На практиці рідко є одна програма, що виконується ізольовано. Найпростіший додаток сьогодні працює в операційній системі і ділиться пам’яттю з іншими програмами, які можуть одночасно «завантажуватися» в пам’ять. Ці програми можуть змінювати пам'ять таким чином, що дана програма не працює. Це, наприклад, відома проблема зі змінними типу 'pointer'. Зазвичай такі помилки викликають ненормальну поведінку системи та невірні результати обчислення.

У вашому випадку я припускаю, що проблема може бути (і зазвичай є) не такою, яку я описав вище. Проблема може полягати в тому, що:

• програма використовувала неправильні типи даних для обчислення результату, ця помилка виявляється лише тоді, коли використовуються спеціальні значення.
• програма зіткнулася з помилкою в обчисленні (через логічну умову), але не впоралася з помилкою і все-таки видала результат. (наприклад, змішування поплавця та цілої арифметики)
• правило бізнесу або логічна умова не були закодовані правильно, дані, які були введені, представляють цю умову, але був використаний неправильний розрахунок. (наприклад, відняти суму від суми рахунку, перш ніж перевірити суму на рахунку).
• використовуючи формули, які застосовуються лише до певного діапазону чисел, але дані містять різний діапазон. (наприклад, обчислення процентної ставки на основі діапазону значень)

Через вищезазначене та багато інших причин програмне забезпечення витрачає стільки ресурсів на спробу створити правильне програмне забезпечення, проте, помилки в програмному забезпеченні все-таки трапляються, але помилки є "логічними" і мають причину, просто причина не очевидна для деяких без хороших досліджень. Отже, загалом тестоване програмне забезпечення є передбачуваним і не дає випадкових результатів. Через складність деяких програм та інших факторів навіть перевірені програми можуть піти не так, але коли це трапляється, помилки виникають з логічної причини.

Якщо я грюкну на серверній машині, чи стане одне з числа, яке обчислює комп'ютер, стане іншим числом і зробить обчислення неправильним?

Відповідь взагалі ні, програмне забезпечення в цьому сенсі не тендітне.

Що можна зробити, - виділити випадки, коли виникає помилка, знайти схожість між цими наборами даних, що спричиняють помилку, і знайти різницю між наборами тез та іншими наборами, які дають правильний результат. Можливо, ви зможете визначити конкретний набір значень, що викликають проблему. Наприклад, ви можете виявити, що кожен раз, коли змінна має негативне значення, результат є неправильним.

Оновлена ​​інформація про помилки з пошкодженням пам’яті: див. Пошкодження пам’яті

Чи можете ви гарантувати, що програма не має помилок і ніколи не помилиться? Ні, на жаль, ні.

Чи можете ви продемонструвати, що програма має достатньо малу кількість помилок, що вартість пошуку та виправлення їх значно перевищує вигоду від цієї дії? Мені це звучить так, як у вас уже є.

Якщо перефразовувати стару максимум статистики, всі програми помиляються, але деякі програми корисні.

Я схильний сказати " ні" , ви не можете довести, що програма ніколи не помилиться або не дасть неправильного результату, навіть якщо ви можете вважати, що ідеальний вклад.

Раку згадав формальне підтвердження коректності. Це одне, що слід враховувати, але, якщо я абсолютно не помиляюся, це все одно доведеться мати ідеальне середовище виконання. Отже, доклавши певного часу та зусиль, ви, можливо, можете довести, що програма правильна , але це не обов’язково доводить, що вона завжди дасть правильні результати , навіть даючи ідеальний вклад. Середовище виконання має значення. І я б насторожено припускав, що вхід завжди ідеальний.

Ось чому в певних ситуаціях з високою доступністю використовуються кілька, повністю незалежних середовищ реалізації та виконання, і результати порівнюються, щоб переконатися, що вони знаходяться в межах допустимого похибки один від одного. У деяких ситуаціях цей запас може бути нульовим. Ще в 60-х роках це було визнано досить важливим для включення в космічні апарати окремих наборів обчислювальної техніки. Навіть якщо забруднення статичного розряду, космічний промінь або будь-яке інше мали б впливати на обидва комп'ютери одночасно, шанси на те, що обидва будуть впливати однаково (особливо, якщо вони ще працюють і дають дійсні результати), є мізерними. Шанси одного і того ж помилки, що повзе в дві абсолютно окремі реалізації, також надзвичайно малі. І так далі.

Думаю, більшість (стандартних) обчислень детерміновані.

Якщо можливо, встановіть його для виконання партії 1000 або 10000 тощо, ітерацій з тими ж вхідними даними та переконайтеся, що результати виходять однаковими.

Переконайтесь, що поточні значення, що надходять у обчислення, спричинили б переповнення або переповнення в будь-якому місці (якщо це старіша система, вона, можливо, не використовувалася так довго).

Y2K11 кому?

Якщо ви не зможете керувати кожним бітом в машині та кожним шматочком електричного імпульсу, що протікає по схемі, ви не можете гарантувати з абсолютною впевненістю, що щось не піде не так у вашій програмі. Модулі пам'яті виходять з ладу, процесори можуть перегріватися та вводити помилки, жорсткі диски можуть перебирати дані, а джерела живлення можуть вносити шум у систему. Чим дорожче обладнання, і чим зайве обладнання, тим менше ймовірність того, що ці речі будуть відбуватися, але в певний момент обладнання може вийти з ладу.

Тоді у вас є операційна система, з помилками, які можна відмітити самими таємними засобами, які можна уявити. У компіляторів також можуть бути незрозумілі помилки, які просто чекають, щоб спритно перетворити ваш незайманий код у важко відстежувані помилки. Це джунглі там, і ваше бідне програмне забезпечення є вразливим до всього цього. ШУКАЙТЕ!

І з мого досвіду, частіше за все, щоразу, коли виникає помилка в підрахунку, нам ніколи не доведеться копати майже так далеко, щоб знайти винуватця. Взагалі кажучи, майже всі помилки, які я бачив у корпоративному світі, легко знаходять за допомогою правильних інструментів налагодження, а також деяких локоть-мастил.

Іншими словами, хоча апаратне забезпечення та ОС можуть бути не ідеальними, вам, ймовірно, ніколи не доведеться турбуватися про цей рівень деталізації. Просто знайдіть когось, хто знає мову та зручний з налагоджувачем, і викопайте.

"простіші пояснення - інші речі при рівності, як правило, краще, ніж більш складні". - Узагальнення бритви Оккама.

Так, удари по системі можуть зігнути та / або перемістити деталі достатньо, щоб викликати тимчасове відкрите замикання (або, можливо, коротке замикання, хоча це, мабуть, менш вірогідно).

Першим комп'ютером, яким я володів, був Altair 8080 з 256 байтами пам'яті. Вхід здійснювався від консольних вимикачів, а вихід - від кількох миготливих вогнів. Якщо ви забороните космічні промені та апаратні збої, я вважаю, що міг би довести, що деякі програми, на які я працював, завжди давали б однакові результати.

Відтоді ні.

Тестування показує наявність, а не відсутність помилок (Edsger W. Dijkstra)

Якщо ви намагаєтесь довести, що програма працює правильно, тестуючи, вона не працюватиме.

Однак є деякі підходи в теоретичній інформатиці, де ви розробляєте формальне підтвердження написаного програмного забезпечення. Залежно від складності вашої системи, це може бути нелегким процесом. Якщо ваша система, однак, працює на обмеженому наборі команд, ви можете досягти успіху при такому підході.

Апаратне та програмне середовище знаходяться в постійному потоці. Приклади переміщення деталей, електрики, температури, пилу та змін ОС - приклади.

Тому я не думаю, що це навіть вірогідне чи очікуване, що програма для комп'ютерного програмного забезпечення завжди поводитиметься однаково, оскільки середовище завжди змінюється.

Програмне забезпечення може працювати тривалий час, як очікувалося, але з часом або невелика зміна програмного забезпечення хост-ОС зміниться, що вплине на програму, про яку йдеться, або апаратне забезпечення буде цінним.

Я говорю про комп’ютери поточного дня.

Тепер моє запитання полягає в тому, чи несподівано комп’ютерна програма раптом піде не так, без логічної причини? Якщо я грюкну на серверній машині, чи стане одне з числа, яке обчислює комп'ютер, стане іншим числом і зробить обчислення неправильним?

Відповідь на це питання невідома. Неможливо довести, що завжди існує все, що стосується Всесвіту, в якому ми живемо. Натомість ми робимо припущення і доводимо, що якщо припущення є дотриманими, то якась складна властивість також буде дотримуватися. Саме це гарантує офіційно перевірені програми. Однак більшість програм офіційно не підтверджені, вони намагаються створити впевненість, надаючи тести. Ці тести дають вам впевненість, що за умови тестів робити те, що вони були розроблені, і що припущення, які ви виконали, програма, яку ви використовуєте, буде працювати принаймні деякий час.

Навряд чи можливо, що проблема викликана збоєм оперативної пам'яті, але це відносно (дуже) малоймовірно. Проведіть тест пам'яті, але будьте готові переглянути код.