Интересует как происходят испытания программ на надёжность (именно программ, а не "железа", которым эта программа управляет) и есть ли какой-то спец софт для испытания программ.

Я, например, слышал, что СИ исходники можно "испытать" какой-то программой не помню как называется, вроде LIM...Не помню точно.. Т.е. даёшь этому LIM-у свой исходник и он начинает его тестить...

Существуют ли какие-то ГОСТ-ы или другие регламентирующие документы о том, как должны происходить испытания программног обеспечения на надёжность и по каким критериям ставят заключение надёжна программа или нет

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

Вот, например, какую структуру характеристик качества предлагает стандарт ИСО-9126 [7] (да и то, в качестве нормативного приложения, как пример, оговариваясь, что фирмы могут применять совершенно другие наборы характеристик, лишь бы они удовлетворяли общим требованиям стандарта):

Функциональность
Соответствие назначению
Точность
Способность взаимодействовать со средой
Соответствие нормам
Безопасность (защита от взлома данных и других преступных посягательств)
Надежность
Зрелость ("обкатанность")
Отказоустойчивость
Способность восстанавливаться после сбоев
Пригодность к использованию
Понимаемость
Изучаемость
Удобство и простота в работе
Эффективность
Быстродействие и время отклика
Потребление ресурсов
Сопровождаемость
Анализируемость (диагностика причин ошибок и сопоставление с исходным кодом)
Пригодность к изменениям
Стабильность
Тестируемость
Переносимость
Адаптируемость
Легкость инсталляции
Соответствие нормам по переносимости и инсталляции
Заменяемость (способность заменить аналоги?)

я пишу для avr и тестирую прогу проходя по всем ветвям алгоритма с различными ситуациями.

Есть еще такой ГОСТ Р ИСО/МЭК 12119-2000 Информационная технология. Пакеты программ. Требования к качеству и тестирование

Список российских и основных международных стандартов по тестированию, оценке качества программных продуктов и смежным вопросам


А скачать кое что из приведённого списка можно тут

Показателя (численного) надёжности ПО не существует. Ошибка в ПО просто может быть. Для систем, отказ которых приводит к катастрофической ситуации , требуется резервирование (в гражданской авиации). При этом ПО резервов должны быть написаны независимыми группами программистов. Это требования квалификационных требований КТ178В (аутентичный перевод забугорного DO178B).

Ну, это не совсем так (вернее, совсем не ТАК!) Посмотрите ГОСТы Р серии 51901: «Менеджмент риска» (практически полный аналог стандартов МЭК начала 90-х годов прошлого века), а именно ГОСТ Р 51901.5-2005 (МЭК 60300-3-1:2003): «Менеджмент риска. Руководство по применению методов анализа надежности».

Можно определить к чему приведёт ошибка в ПО: катастрофической ситуации, аварийной ...
Но показателя (ЧИСЛЕННОГО) надёжности ПО не существует, т.е. невозможно ПРЕДсказать, например, что на миллион часов работы системы ошибка ПО проявится столько то раз. Или на сто страниц кода будет столько то ошибок.
Кстати, это справедливо вообще к ошибкам в проектировании.
Если я не прав, то подскажите Справочник, аналогичный Справочнику "Надёжность ЭРИ", для ПО.

А никто не проходил сертификацию софта в ФСБ на отстутствие закладок? Опишите как она происходит

Как и любая сертифмкация. Заключаете Договор с центром, имеющем соответсвующую лицензию, предоставляете ему исходный текст и получаете Заключение.

Хотя ТС говорил об этом давно, но идея стоит того. Не совсем так правда, но вариант сравнительного анализа ПО существует. Можно и на количественные цифры выйти при оценке надежности ПО, но для этого прийдется писать "парсер-анализатор" исходника, и время вычислений зависит от размера исходника в степени. Интересно кто-либо сталкивался еще с таким?

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

Не возможно. Ошибка в ПО может быть, и это не зависимо от количества обнаруженных ошибок, точно также, как может быть ошибка врача, шахматиста, сапёра... - и на старуху бывает проруха.

За бугром существует стандарт на создание ПО для гражданских самолётов DO-178B. У нас есть гармонизированный КТ-178В - Квалификационные требования. Эти документы определяют, как создавать и контролировать создание ПО с тем, что бы иметь удовлетворительную степень доверия к ПО. При этом оценку (не численную) делают эксперты EASA (Европейское Агенство по Авиационной Безопасности), у нас - АР МАК (Авиационный Регистр Межгосударственного Авиационного Комитета)

Для гражданских самолётов критические системы (способные привести к катастрофе) должны быть резервированы на разной элементной базе. Резервы разработаны независимыми разработчиками - схемная ошибка ни чем не отличается от ошибки в ПО. ПО должно быть разработано также независимыми разработчиками.

В авиации эти требования давно не обсуждаются, а выполняются.

На сколько я понимаю, сейчас имеются три подхода к оценке ПО:
1. Чистая комбинаторика, где анализируется возможность написания кода с ошибками,
которые могут быть логическими, синтаксическими. Как результат получаем эффективность
различных языков в области допущения ошибок.
2. Статистический подход, где принимается например нормальный закон наличия ошибок
в ПО и анализируется динамика работы над ошибками.
3. Технологический подход, где анализируются методы и инструменты создания ПО.
Он в большей степени основан на том, что качественная организация процесса
в результате приведет к качественному ПО.

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