Можем ли мы гарантировать, что программа никогда не пойдет не так?

У нас есть система здесь. Недавно произошел неправильный расчет в одном из номеров в отчете, сгенерированном системой. Исходя из нашего опыта, мы никогда не сталкивались с какими-либо проблемами / ошибками в этой системе в течение нескольких лет.

Поскольку автор этой системы уже ушел, мы едва ли можем отследить программы. Но мы проверили входные данные, настройки и они правы.

Теперь мой вопрос: вдруг компьютер пойдет не так без логической причины? Если я нажму на серверный компьютер, станет ли один из чисел, которые вычисляет компьютер, другим, и сделает неправильный расчет?

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

PS У этой безумной системы нет логов.

Я бы сказал нет!

В теории ответ - нет, мы можем проверить только:

• некоторое ограниченное количество сред.
• ограниченное количество временных шкал.
• ограниченное количество тестовых случаев.

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

Теория подтверждается опытом, с которым я лично столкнулся:

• Программы ломаются при перемещении в другую локаль. Проверка на «MAY», когда месяц был «MAI».
• Программы, не прошедшие тестирование на новой версии компилятора. Ошибка в предыдущей версии в сочетании с ошибкой в ​​программе дала правильный результат.
• Программы ломаются на новую версию ОС. Когда Solaris увеличивал количество записей в каталоге по умолчанию, SMALLINT, возвращаемый функцией ftok (), всегда возвращал ноль для первого файла в каталоге.
• программы были прерваны, потому что они впервые столкнулись с определенной комбинацией входных данных, которые были как действительными, так и неожиданными и никогда бы не были проверены - отрицательные процентные ставки по депозитам, товары с нулевым весом, подлежащие отправке, товары с такой низкой стоимостью, что НДС не может быть рассчитан и т. Д.

Теоретически, если вы начнете с одинакового состояния, результат будет идентичным. В действительности, обеспечить идентичное начальное состояние в оборудовании «серверного размера» практически невозможно.

Возьмите неинициализированные переменные. Посмотрите на этот код:

  short i;

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

Это даст неожиданные результаты один раз в 65536 прогонов. И если вы не уверены, что память будет в одном и том же состоянии перед каждым запуском, iвсе будет совершенно случайно.

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

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

Теперь мой вопрос: вдруг компьютер пойдет не так без логической причины?

Если у вас точно такая же вычислительная среда, то ввод программы X всегда будет давать один и тот же результат R. На практике редко бывает, чтобы одна программа выполнялась изолированно. Самое простое на сегодняшний день приложение работает в операционной системе и совместно использует память с другими программами, которые могут одновременно загружаться в память. Эти программы могут изменять память таким образом, что это приводит к сбоям в работе данной программы. Это известная проблема с переменными типа указатель, например. Обычно такие ошибки вызывают ненормальное поведение системы, а не неправильные результаты расчетов.

В вашем случае я предполагаю, что проблема может быть (и обычно есть) не в том, что я описал выше. Проблема может быть в том, что:

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

Из-за вышеизложенного и многих других причин люди, занимающиеся программным обеспечением, тратят так много ресурсов в попытке создать правильное программное обеспечение, однако ошибки в программном обеспечении по-прежнему возникают, но ошибки являются «логическими» и имеют причину, просто причина не очевидна некоторым без хорошего исследования. Таким образом, в целом тестируемое программное обеспечение предсказуемо и не дает случайных результатов. Из-за сложности некоторых программ и других факторов даже протестированные программы могут работать неправильно, но когда это происходит, ошибки возникают по логической причине.

Если я нажму на серверный компьютер, станет ли один из чисел, которые вычисляет компьютер, другим, и сделает неправильный расчет?

Ответ, в общем-то, отрицательный, программное обеспечение не хрупкое в этом смысле.

Что вы можете сделать, это изолировать случаи, когда происходит ошибка, найти сходство между этими наборами данных, вызывающих ошибку, и найти разницу между наборами тезисов и другими наборами, которые дают правильный результат. Вы можете определить конкретный набор значений, вызывающих проблему. Например, вы можете обнаружить, что каждый раз, когда переменная имеет отрицательное значение, результат неверен.

Обновлена ​​информация об ошибках повреждения памяти: см. Повреждение памяти

Можете ли вы гарантировать, что программа не содержит ошибок и никогда не ошибется? Нет, к сожалению нет.

Можете ли вы продемонстрировать, что в программе имеется достаточно небольшое количество ошибок, что затраты на их поиск и исправление намного превышают выгоды от этого действия? Для меня это звучит так, как будто ты уже понял.

Перефразируя старый принцип статистики, все программы ошибочны, но некоторые программы полезны.

Я склонен сказать « нет» , вы не можете доказать, что программа никогда не будет работать неправильно или давать неправильный результат, даже если вы можете предполагать идеальный ввод.

Раку упомянул формальное доказательство правильности. Это одна вещь, которую нужно учитывать, но если я не ошибаюсь, все равно придется предполагать идеальную среду исполнения. Таким образом, потратив некоторое время и усилия, вы, возможно, сможете доказать, что программа правильная , но это не обязательно доказывает, что она всегда будет давать правильные результаты , даже при условии идеального ввода. Среда исполнения имеет значение. И я бы с осторожностью предположил, что ввод всегда идеален.

Вот почему в определенных ситуациях высокой доступности используются несколько полностью независимых реализаций и сред выполнения, и результаты сравниваются, чтобы убедиться, что они находятся в допустимых пределах погрешности друг от друга. В некоторых ситуациях этот запас вполне может быть нулевым. Еще в 1960-х годах это считалось достаточно важным, чтобы включать в космические корабли отдельные наборы вычислительной техники. Даже если ошибочный статический разряд, космические лучи или что-то еще влияют на оба компьютера одновременно, вероятность того, что оба будут затронуты одинаково (особенно если они все еще работают и дают достоверные результаты), ничтожна. Шансы на одну и ту же ошибку, попадающую в две совершенно разные реализации, также крайне малы. И так далее.

Я думаю, что большинство (стандартных) вычислений являются детерминированными.

Если возможно, настройте его на выполнение серии 1000 или 10000 и т. Д., Итераций с одними и теми же входными данными и убедитесь, что результаты получаются одинаковыми.

Убедитесь, что текущие значения, включенные в расчет, повлекут за собой переполнение или потерю значения в любом месте (если это старая система, возможно, она не была предназначена для такого длительного использования).

Y2K11 кто-нибудь?

Если вы не можете контролировать каждый отдельный бит в машине и каждый электрический импульс, протекающий по схеме, вы не сможете с абсолютной уверенностью гарантировать, что с вашей программой что-то пойдет не так. Модули памяти выходят из строя, процессоры могут перегреваться и приводить к ошибкам, жесткие диски могут шифровать данные, а блоки питания могут создавать помехи в системе. Чем дороже оборудование и чем избыточнее оборудование, тем меньше вероятность того, что это произойдет, но в какой-то момент оборудование может выйти из строя.

Тогда у вас есть операционная система, с ошибками, которые можно пощекотать самыми загадочными средствами. Компиляторы также могут иметь неясные ошибки, просто ожидающие, чтобы ловко превратить ваш первозданный код в трудно обнаруживаемые ошибки. Это джунгли, и ваше плохое программное обеспечение уязвимо для всего этого. БЫТЬ ОСТОРОЖНЫМ!

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

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

«Более простые объяснения при прочих равных условиях, как правило, лучше, чем более сложные». - Обобщение бритвы Оккама.

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

Первым моим компьютером был Altair 8080 с 256 байтами памяти. Вход был от консольных переключателей, а выход был от нескольких мигающих огней. Если вы запретите космические лучи и аппаратные сбои, я думаю, что смогу доказать, что некоторые программы, которые я запускал на нем, всегда давали одинаковые результаты.

С тех пор нет.

Тестирование показывает наличие, а не отсутствие ошибок (Эдсгер В. Дейкстра)

Если вы пытаетесь доказать, что ваша программа работает правильно, тестируя, она не будет работать.

Тем не менее, есть некоторые подходы в теоретической информатике, где вы разрабатываете формальное доказательство написанного вами программного обеспечения. В зависимости от сложности вашей системы, это может быть утомительным процессом. Однако, если ваша система работает с ограниченным набором команд, вы можете добиться успеха с этим подходом.

Аппаратные и программные среды постоянно меняются. Движущиеся части, электричество, температура, пыль и изменения кода ОС являются примерами.

Поэтому я не думаю, что это даже вероятно или ожидается, что компьютерная программа всегда будет вести себя одинаково, поскольку среда постоянно меняется.

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

Я говорю о компьютерах текущего дня.

Теперь мой вопрос: вдруг компьютер пойдет не так без логической причины? Если я нажму на серверный компьютер, станет ли один из чисел, которые вычисляет компьютер, другим, и сделает неправильный расчет?

Ответ на этот вопрос непостижим. Невозможно доказать, что что-то всегда верно для вселенной, в которой мы живем. Вместо этого мы делаем предположения и доказываем, что если предположения верны, то будет иметь место и некоторое сложное свойство. Это то, что официально проверенные программы гарантируют. Тем не менее, большинство программ формально не проверено, вместо этого они пытаются укрепить доверие, предоставляя тесты. Эти тесты дают вам уверенность в том, что при условии, что тесты выполнят то, для чего они были предназначены, и что принятые вами предположения, используемая вами программа будет работать, по крайней мере, некоторое время.

Едва ли возможно, что проблема вызвана сбоем оперативной памяти, но это относительно (очень) маловероятно. Запустите тест памяти, но будьте готовы просмотреть код.