Перейти к содержанию
    

Испытания надёжности программы

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

 

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

 

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

 

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

Изменено пользователем Дон Амброзио

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Функциональность

Соответствие назначению

Точность

Способность взаимодействовать со средой

Соответствие нормам

Безопасность (защита от взлома данных и других преступных посягательств)

Надежность

Зрелость ("обкатанность")

Отказоустойчивость

Способность восстанавливаться после сбоев

Пригодность к использованию

Понимаемость

Изучаемость

Удобство и простота в работе

Эффективность

Быстродействие и время отклика

Потребление ресурсов

Сопровождаемость

Анализируемость (диагностика причин ошибок и сопоставление с исходным кодом)

Пригодность к изменениям

Стабильность

Тестируемость

Переносимость

Адаптируемость

Легкость инсталляции

Соответствие нормам по переносимости и инсталляции

Заменяемость (способность заменить аналоги?)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

 

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

Изменено пользователем Дон Амброзио

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Показателя (численного) надёжности ПО не существует.

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

Изменено пользователем asonika

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну, это не совсем так (вернее, совсем не ТАК!) Посмотрите ГОСТы Р серии 51901: «Менеджмент риска» ...

Можно определить к чему приведёт ошибка в ПО: катастрофической ситуации, аварийной ...

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

Кстати, это справедливо вообще к ошибкам в проектировании.

Если я не прав, то подскажите Справочник, аналогичный Справочнику "Надёжность ЭРИ", для ПО.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Изменено пользователем i-mir

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

 

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

 

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

 

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

Изменено пользователем Ильдус

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

На сколько я понимаю, сейчас имеются три подхода к оценке ПО:

1. Чистая комбинаторика, где анализируется возможность написания кода с ошибками,

которые могут быть логическими, синтаксическими. Как результат получаем эффективность

различных языков в области допущения ошибок.

2. Статистический подход, где принимается например нормальный закон наличия ошибок

в ПО и анализируется динамика работы над ошибками.

3. Технологический подход, где анализируются методы и инструменты создания ПО.

Он в большей степени основан на том, что качественная организация процесса

в результате приведет к качественному ПО.

 

Наверняка есть что-либо еще.

В свое время теория надежности пошла по пути выявления фактов несоответствия

требуемому КД, привлекла на свою сторону статистику и теперь у нас общая основа

расчетов есть экспоненциальный закон не привязанный к железу.

А могло быть и другое развитие - на принципе потерь энергии в системе.

Например не оптимальные узлы схемы потребляют излишнюю энергию - нужно задуматься

и уменьшить надежность такого узла и т.д. ...

Аналогично с ПО - например каждая ветка имеет свои тайминги - сравниваем с общепринятыми

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

процессорное время.

Нашли баг, сделали коррекцию алгоритма, время выполнения увеличилось - это сигнал к анализу

и поиску внесенной "ненадежности".

 

 

 

 

Изменено пользователем i-mir

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...