4510

Сертификация и надежность программного обеспечения

Конспект

Информатика, кибернетика и программирование

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

Русский

2012-11-21

239.94 KB

63 чел.

Проблемы надежности ПО

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

Направления исследований в вопросе надежности ПО

  1. Обоснование интуитивного представления о надежности ПО.
  2. Разработка методов, обеспечивающих достижение заданного уровня надежности.

Основные типы комплексов программ

  1. Программы для решения инженерных и научно-исследовательских задач.

Характеристики:

  1. относительно небольшой жизненный цикл;
  2. неполное использование ресурсов вычислительной системы;
  3. небольшая длительность разработки;
  4. их эксплуатация носит эпизодический и кратковременный характер;
  5. отсутствие жестких ограничений на допустимую длительность ожидания результатов;
  6. практически всегда имеется возможность достаточно строго проконтролировать выходные данные и при необходимости поставить контрольные эксперименты.

К этому типу программ практически не применимы основные понятия теории надежности.

  1. Сложные комплексы программ для информационно–справочных систем, которые функционируют вне реального времени. Это системы организационного типа.


Характеристики:

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

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

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

Характеристики:

  1. обычно практически полностью используют ресурсы вычислительной системы;
  2. снабжаются подробной документацией;
  3.  эксплуатируются долгое время.

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

Факторы, позволяющие анализировать показатели надежности программ 2-го и 3-го типов

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


Взаимосвязь надежностных характеристик ПО и аппаратуры

Факторы надежности аппаратных средств

  1. Надежность элементов.
  2. Ошибки в конструировании, допущенные при проектировании или изготовлении.

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

С другой стороны надежность программных компонентов определяется теми же двумя факторами, однако степень их влияния иная.

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

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

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

Проблемы эталонов

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

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

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

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

Сбой – кратковременный отказ.

λ – интенсивность проявления отказов или ошибок.

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

Затраты на обеспечение надежности должны быть сопоставимы с ущербом в следствии отказа системы.

Основные этапы разработки ПО

Единственно важная причина ошибок в ПО – это неправильный перевод из одного представления в другое.

  1. Разработка описания реальной задачи в виде перечня требований пользователя (который в некоторых случаях пользователь составляет сам). Здесь имеются обширные возможности для появления ошибок. Например, пользователь не сумеет адекватно выразить свои потребности, они могут быть неверно поняты либо учтены не в полном объеме. Ошибки этого уровня обходятся чрезвычайно дорого.
  2. Перевод требований пользователя в цели программы. Ошибки на этом этапе возникают, когда неверно определяются требования.
  3. Шаг связан с преобразованием цели программы в ее внешние спецификации, т.е. поведение всей системы с точки зрения пользователей. По объему перевода это самый значительный этап, он больше всего подвержен ошибкам.
  4. Этот этап представляет собой несколько переводов от внешнего описания готового продукта до получения готового проекта, описывающего многие составляющие проекта-предложения, выполнение которых должно обеспечить поведение системы, соответствующее внешним спецификациям:
  5. перевод внешнего описания в структуру программы (например, модуль);
  6. перевод каждой из этих компонент в описание процедурных шагов (например, блок-схему).

Т.к. приходится иметь дело со все большим объемом информации шансы внесения ошибок очень высоки.

  1. Перевод описания логики программы в предложения языка программирования. На этом этапе Делается много ошибок, но они легко обнаруживаются и корректируются. На этом этапе есть еще один перевод – перевод текста программы на языке программирования в объектный код (выполняется компиляторами и трансляторами).
  2. В результате работы над программным проектом возникает как само ПО так и документы, описывающие его использование в виде руководств в бумажном или электронном виде. Если возникают ошибки при подготовке документации, то она не будет точно описывать поведение программы (если только на шагах 4 и 6 не сделаны идентичные ошибки). Прочитав руководство пользователь начнет работать с программой и обнаружит, что она ведет себя не так, как он ожидал – это и является, по определению, ошибкой в программе.
  3. Например разработчик операционной системы опирается на описание процессора (набор команд, прерывания, средства защиты и т.д.) и периферийного оборудования. Разработчики должны знать характеристики линий связи и т.д. Неправильное толкование этих данных может привести к ошибкам в программе.
  4. Прикладные программы взаимодействуют с базовым ПО (таким, например, как ОС). Неправильное понимание документации по базовому ПО – еще один источник ошибок.
  5. Готовая программа состоит из предложений хотя бы одного языка программирования. Непонимание синтаксиса и семантики языка – также причина ошибок.
  6. Есть две формы связи между пользователем и готовой программой – это руководство, описывающее использование и непосредственно работа с ним. Этот шаг представляет собой изучение пользователем руководств и перевод их содержания в его понимание того, как он желает применять программу.

Модель перевода входной информации в выходную

А – исходная информация.

В – результирующая информация.

ЧМ – читающий механизм (области мозга, управляющие зрением и слухом).

ПАМ – память.

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

  1. Человек получает информацию с помощью ЧМ.
  2. Человек запоминает информацию в своей памяти.
  3. Выбирает из памяти эту информацию, а также информацию, описывающую процесс перевода, выполняет перевод и посылает результат своему ПМ.
  4. Информация физически распространяется с помощью печати на терминале или с помощью речи.

Ошибки

  1. Одна из способностей человека – понимать входную информацию, сопоставляя ее с образами, созданными образованием и жизненным опытом. Этот принцип основывается на способности человека «читать между строк», понимать грамматически неправильные предложения и т.д. Эти способности могут вызывать неточности в переводе информации. Это возникает тогда, когда человек читает документ А и видит то, что хочет, а не то, что написано, пытается восстановить недостающие факты или не понимает информацию. Ошибки могут присутствовать в самом документе А.
  2. В большинстве случаев, чтобы правильно запомнить информацию надо ее понять. Ошибки появляются в результате неправильной интерпретации или полного непонимания входной информации. Информация может быть слишком сложной или двусмысленной, образовательный уровень человека может оказаться недостаточно высоким.
  3. Основной источник ошибок на этом этапе – забывчивость. Человек может забыть входную информацию А либо точные правила выполнения перевода. Слабость других умственных способностей, таких как четкость мышления, также способствует появлению ошибок.
  4. Многие не умеют ясно писать или выражать свои мысли, это затуманивает смысл их сообщений. Если количество выходной информации велико человека начинает раздражать разница между скоростью мышления и письма. Чтобы справиться с этим он использует сокращения либо предполагает, что факты будут интуитивно очевидны. Это увеличивает вероятность того, что следующий участник процесса разработки при переводе совершит ошибки.

Количественные характеристики надежности

Программа тестируется на всех компьютерах, выявляются ошибки. Через промежуток времени Δt фиксируются появления ошибок, собирается статистика.

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

– вероятность отказа

 

– количество прогонов

– количество прогонов, закончившихся ошибками за время t

– частота отказов


Задача

Проведено прогонов ПО.

Все прогоны начались в момент времени t = 0 (т.е. на нескольких компьютерах параллельно).

Δt = 500 часов.

Определить вероятность безотказной работы и частоту отказов .

, час.

0 – 500

145

0,855

0,00029

500 – 1000

86

0,769

0,000172

1000 – 1500

77

0,692

0,000154

1500 – 2000

69

0,623

0,000138

2000 – 2500

62

0,561

0,000124

2500 – 3000

56

0,505

0,000112

3000 – 3500

51

0,454

0,00102

3500 – 4000

45

0,409

0,00009

4000 – 4500

41

0,368

0,000082

4500 – 5000

37

0,331

0,000074

5000 – 5500

33

0,298

0,000066

5500 – 6000

35

0,263

0,00007

6000 – 6500

60

0,203

0,00015

6500 – 7000

75

0,128

0,00015

7000 – 7500

62

0,066

0,000124

7500 – 8000

42

0,024

0,000084

8000 – 8500

16

0,008

0,000032


Структурно-логические модели надежности ПО

Последовательная

Зависимость программ – отказ одной приводит к отказу всех последующих.

– вероятность безотказной работы всей системы.

– вероятность отказа всей системы.

– вероятность отказа одного элемента.

Это модель для неизбыточных систем.

Параллельная

При отказе одной подсистемы ее функции берет на себя одна из оставшихся. Пример: RAID-массив.

N – кратность резервирования (уровень избыточности).


– вероятность отказа всей системы.

– вероятность безотказной работы всей системы.

– вероятность безотказной работы одного элемента.

Параллельно-последовательная

             

– вероятность безотказной работы всей системы.

Мажоритарная

Система работает с одним и даже двумя отказавшими элементами.

– вероятность безотказной работы всей системы.

– вероятность безотказной работы одного элемента.

– вероятность отказа всей системы.

Экспоненциальная модель

– вероятность отказа одного элемента.

– вероятность безотказной работы одного элемента.

– интенсивность отказов i-ой подсистемы.

t – время.

Основные определения и понятия теории надежности

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

Программная ошибка имеет место тогда, когда программа работает не так, как предполагает пользователь, т.е. программная ошибка не является неотъемлемым свойством программного обеспечения. Наличие ошибки в программе – это функция от самой программы и от того, чего ждет от нее пользователь.

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

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

Ошибки ПО являются функцией от входной информации и состояния системы. Ошибки несут систематический характер.

Надежность ПО базируется на понятиях корректности и устойчивости.

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

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

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

Критерии надежности

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

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

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

Критерии:

  1. Детерминированные – оценка количества ошибок в программе на том или ином этапе работы.
  2. Вероятностные – вероятностная оценка свойств ПО.

Все ошибки носят детерминированный характер, но вероятностным оказывается процесс внесения ошибок. Проявление ошибок также носит вероятностный характер.


Примеры критериев:

  1. Корректность ПО.
  2. Число серьезных текущих ошибок в программе и время, необходимое для их устранения.
  3. Обслуживаемость системы – степень влияния ошибок ПО на обслуживаемость системы.
  4. Безопасность системы.
  5. Частота отказов.
  6. Вероятность безотказной работы за время t при условии времени отладки.
  7. Средняя наработка на программный отказ при условии исправления или не исправления обнаруженных отказов.

Верификация программ – процесс формального доказательства правильности программы, т.е. корректности.

Верификация:

  1. Статическая – программа рассматривается как материальный объект.
  2. Динамическая (частный случай – тестирование).

С учетом сложившейся практики выбора критериев оценки надежности необходимо принимать во внимание следующее:

  1. Разработанное ПО в начальной стадии эксплуатации может потребовать менее жестких критериев и большего времени для его совершенствования.
  2. После выпуска новой версии некоторое время потребуются также менее строгие критерии качества ПО.
  3. Имеют место разбросы, вызываемые различием в условиях применения и использования ПО.
  4. Эффективность работ по исправлению ошибок, проводимых разработчиками ПО, зависит от частоты проявления ошибок, что, в свою очередь, зависит от информации, поступающей от пользователей.
  5. Необходимость соблюдения ограничений по быстродействию и производительности, если таковые диктуются пользователями.

Характеристики ПО

  1. Количественные характеристики (оцениваются числом):
  2. объем программы;
  3. количество спряжений;
  4. количество ветвлений;
  5. точки входа/выхода;
  6. количество процедур;
  7. уровень вложения;
  8. количество комментариев;
  9. количество страниц документации;
  10. требуемое машинное время.
  11. Качественные характеристики (оцениваются числом):
  12. трудности проектирования;
  13. трудности в эксплуатации из-за ошибок;
  14. тип программ;
  15. данные о персонале (количество, коэффициент загруженности).
  16. Качественные характеристики, как объективное суждение.

Испытания

  1. Стендовые (многократные проверки прочности в реальных условиях).
  2. Приемосдаточные (подтверждение требуемых характеристик и передача в эксплуатацию).
  3. Системные (оценивают правильность взаимодействия с системой).
  4. Демонстрация в реальных условиях.
  5. Сертификационные испытания.

Основные параметры персонала

  1. Данные, характеризующие программиста.
  2. Данные, характеризующие выполнение конкретной работы.

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

Параметры программиста

Оценка

Оцениваемые

факторы

А

Уровень знаний

1 – 5

1) ОП=А+Б+В+Г

2) ОПКР=(20-Д)*ОП

ОПКР – оценка программиста и конкретной работы.

Б

Уровень способностей

1 – 5

В

Стиль работы

1 – 5

Г

Степень ответственности

1 – 5

Д

Параметры конкретной работы

0 – 10

Цель анализа программных ошибок при сертификации и оценке надежности ПО

  1. Определение структурных свойств программ и характеристик процесса их разработки, влияющих на надежность.
  2. Организация методов сбора данных о надежности.
  3. Категоризация возможных программных ошибок по их причинам и проявлениям.
  4. Выработка рекомендаций по совершенствованию бездефектных программ.
  5. Разработка моделей надежности ПО.

Извещения об ошибке

Исходная информация об ошибках может быть представлена в извещении об ошибке. В них указывается:

  1. Объект затруднения (подсистема, БД, ОС и т.д.).
  2. Дата и время ошибки.
  3. Пример или задача, на которой зафиксирована ошибка.
  4. Конфигурация активной структуры ПО.
  5. Содержание ошибки.
  6. В соответствие ставится извещение о закрытии ошибки, в котором содержится:
  7. информация о закрытии ошибки;
  8. генерация новой конфигурации;
  9. правильность распознавания объекта затруднения;
  10. существо ошибки.

Основные задачи в области надежности ПО

  1. Классификация ошибок
  2. Организация систем сбора данных
  3. Рекомендации по совершенствованию
  4. Построение модели
  5. Верификация программ
  6. статическая верификация
  7. Динамическая верификация
  8. Тестирование
  9. Выбор тестов
  10. Управление тестированием
  11. Защита информации
  12. Защита вычислительного процесса

Количественные характеристики надежности ПО

– вероятность безошибочной работы.

– вероятность появления ошибок.

– частота появления ошибок.

– интенсивность появления ошибок.

– среднее время между ошибками.

Программа испытывается на одном компьютере

(кси)

– статистическое среднее время между двумя ошибками.

Nобщее количество прогонов.

– обобщенный закон надежности (λ  const)

Классификация ошибок ПО

  1.  Где произошла ошибка?
  2. Персонал

Информация по категориям персонала включает структуру (1.1.1.) и процедуры (1.1.2.). Это операционные процедуры, правила кодирования и проверки, а также стандарты документирования.

  1. Структура
  2.  Технический – для конкретного модуля определяется имя, квалификация разработчика, а именно опыт программирования, знание языков и ответственность.
  3.  Административный – определяет администра-тивную информацию.
    1. Процедура
  4. Операционные процедуры включают информацию о рабочей среде, т.е. пакетный или интерактивный режим работы, свободный или ограниченный доступ.
  5. Правила кодирования и проверки. Они содержат информацию о степени использования, например, структурного программирования.
  6. Стандарты документации включают форматы и процедуры документирования данного модуля.

  7. Оборудование
    1. Компьютер

Перечень оборудования и интерфейсов

  1. Связь

Содержит информацию о внешнем оборудовании в комплекте ПК, включая линии связи с терминалами.

  1. Сопровождающее обеспечение

Информация обо всем оборудовании, подходящем для подготовки модуля и работы.

  1. ПО
    1. Внутреннее ПО

Языковой процессор, загрузчик, редактор связей, утилиты.

  1. Применение

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

  1.  На что похожа ошибка?
  2. ПО
    1. Внутреннее ПО

ОС, редактор связей, загрузчик, утилиты.

  1. Применение

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

  1. Функции

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

  1. Процедура

В процедурах ввода/вывода подразумевается наличие неправильных значений данных.

  1. Использование ресурса

При использовании ресурсов наиболее критичными ошибками являются:

  1. неправильное использование терминальных устройств;
  2. ошибки синхронизации;
  3. ошибки в описании форматов вводимой и выводимой информации.
  4. Ресурсы
    1. Имя
    2. Использование ресурса
  5. Область
    1. Структура программы
    2. Приложение
  6.  Как была сделана ошибка?
  7. Данные
    1. Входные
    2. Внутренние
  8. Процедуры
    1. Вычисление
    2. Контроль
    3. Интерфейс
  9.  Когда была сделана ошибка?
  10. Начальная разработка
  11. Внедрение
  12. Функционирование
  13.  Почему произошла ошибка?
  14. Механические причины
    1. Подстановка
    2. Путаница
    3. Пропуск
  15. Умственные причины
    1. Концептуализация
    2. Реализация
  16. Коммуникационные причины
    1. Персонал
    2. Документация

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


Модели надежности ПО

Классификация моделей надежности ПО

Экспоненциальная модель (модель Шумана)

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

Условия сводятся к следующему:

  1. Предполагается, что в начальный момент компоновки программных средств системы в них имеются небольшие ошибки (Е – количество ошибок). С этого времени отсчитывается время отладки , которое включает затраты времени на выявление ошибок с помощью тестов, на контрольные проверки и т.д. При этом время исправного функционирования системы не учитывается. В течение времени устанавливается ошибок в расчете на одну команду машинного языка. Т.о. удельное число ошибок на одну машинную команду, остающихся в системе после времени работы равно

I – общее число машинных команд.

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

C – коэффициент пропорциональности.

Тогда, если время работы системы t отсчитывается от момента времени  t0, а остается фиксированным (=const), то функция надежности или вероятность безотказной работы на интервале времени от 0 до t есть

Для нахождения С и Е используются принцип максимального правдоподобия (пропорция).

Модель Джелинского-Моранда

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

M – неизвестное первоначальное число ошибок

i – число обнаруженных ошибок, зависящих от времени t

k – константа

Частота обнаружения i-ой ошибки задается соотношением

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

Статистическая модель Миллса

Эту модель можно использовать для сертификации программных средств.

В модели не используются предположения о поведении функции риска . Эта модель строится на твердом статистическом фундаменте.

Сначала программа «засоряется» некоторым количеством известных ошибок. Эти ошибки вносятся в программу случайным образом, а затем делается предположение, что для ее собственных и внесенных ошибок вероятность обнаружения одинакова и зависит только от их количества. Тестируя программу в течении некоторого времени и отсортировывая собственные и внесенные ошибки можно оценить N – первоначальное число ошибок в программе.

Предположим, что в программу было внесено S ошибок. Пусть при тестировании обнаружено (n+V) ошибок.

n – число собственных ошибок

V – число внесенных ошибок

Тогда оценка для N по методу максимального правдоподобия будет следующей

В действительности N можно оценивать после каждой ошибки. Миллс предлагает во время всего периода тестирования отмечать на графике число найденных ошибок и текущие оценки для N.

Вторая часть модели связана с выдвижением и проверкой гипотез о N.

Примем, что программе имеется не более k собственных ошибок и внесем в нее еще S ошибок. Теперь программа тестируется, пока не будут обнаружены все внесенные ошибки. Причем подсчитывается число обнаруженных собственных ошибок n. Уровень значимости С вычисляется по формуле

С – мера доверия к модели – вероятность того, что модель будет правильно отклонять ложные предположения.

Формулы для N и C образуют полезную модель ошибок.


Минусы модели

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

Модификация формулы для С, если не все ошибки обнаружены:

j – найденные внесенные ошибки, j < S

Еще один график, который полезно строить во время тестирования – это текущее значение верхней границы k для некого доверительного уровня.

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

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

Простейшие интуитивные (эвристические) модели

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

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

N1, N2 – число обнаруженных каждой группой ошибок

N12 – число ошибок, обнаруженных дважды (обеими группами)

N – число ошибок в программе (неизвестное)

Е – эффективность тестирования

Предполагаем, что возможность обнаружения одинакова. Это серьезное предположение не лишенное смысла. Можно рассматривать каждое подмножество N как аппроксимацию всего пространства.

Например, если первая группа обнаружила 10% ошибок, то она должна было найти примерно 10% всякого случайным образом выбранного подмножества, например подмножества N2. Можно сказать, что

Если выполнить подстановку для N2 получим

Очевидно, самый простой способ оценки числа ошибок – сравнить оценки, основанные на исторических данных, в частности на среднем числе ошибок, приходящихся на 1 оператор в предыдущих проектах. В литературе есть сведения о частоте ошибок, но они не очень обширны. Имеющиеся данные ориентированы по отраслям и берутся как среднее значение по некоторому количеству операторов (например, 10 ошибок на 1000 операторов).

Пример: данные IBM для OS/360, OS/VS1, OS/VS2:

x – многократно исправляемый модуль или число модулей, которые потребовали 10 и более исправлений.

y – число модулей, потребовавших 1 или несколько исправлений.

z – полное число исправлений в модулях.

Из-за неопределенностей во всех рассмотренных модулях пока самый разумный подход – воспользоваться несколькими моделями и объединить их результаты. Например, данные по прежним проектам можно использовать для грубой оценки. Далее можно использовать модель с двумя параллельными группами. Далее – тестирование с искусственным внесением ошибок, определить достоверность С по модели Миллса, а также использовать другие модели.

Объединение результатов нескольких тестов:

  1.  Средняя величина ,
  2.  Минимальные оценки
  3.  Максимальные оценки
  4.  Интервальные оценки

  1.  

Имитационные модели

Такие модели, которые имитируют процессы появления ошибок, процесс обнаружения ошибок, процесс исправления ошибок с точки зрения надежности ПО.

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

Узлы – точки в которых части программы объединяются или разъединяются.

Дуги – последовательности линейных участков. В них размещаются команды.


Тестирование ПО. Испытания ПО при сертификации

Детерминированное тестирование при проектировании. Детерминированное испытание при сертификации

Принципы и задачи детерминированного тестирования

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

Диагностирование производится автоматическими человеко-машинными системами, в которых:

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

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


В зависимости от используемой при тестировании информации различают два метода:

  1. Метод проверки по исходным данным и результатам.

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

  1. Метод с учётом промежуточных результатов.

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

«Серый ящик» – частично структура известна, а частично – нет.

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

Процесс отладки программы при детерминированном тестировании подразделяется на следующие этапы:

  1. планирование отладки;
  2. составление тестов и задач на отладку и исполнение программы;
  3. информирование о результатах по задачам теста;
  4. анализ результатов, обнаружение и локализация ошибок;
  5. устранение ошибок и корректировка исходного текста программы.

Детерминированное тестирование включает:

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

Порядок тестирования может быть:

  1. безусловный, т.е. независимый от результатов исполнения предыдущих наборов;
  2. условным.


Методы тестирования

Восходящее тестирование

Программа собирается и тестируется снизу вверх, только модули самого нижнего уровня тестируются изолированно или автономно. После их тестирования вызов их должен быть также надёжен, как вызов встроенной функции языка. Затем тестируются модули, вызывающие уже проверенные. Эти модули тестируются не автономно, а вместе с уже протестированными.

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

Нисходящее тестирование (нисходящая разработка)

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


Возникают 2 проблемы

  1. Что делать, когда тестируемый модуль вызывает модуль более низкого уровня, которого в данный момент еще не существует?

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

  1. Как подаются тестовые данные?

Плюсы метода

  1. Метод совмещает тестирование модулей, тестирование сопряжений и частично тестирование внешних функций.
  2. Когда модули ввода/вывода уже подключены, тесты можно готовить в удобном виде.

Минусы метода

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

Нисходящий подход выгоден в тех случаях, когда есть сомнения в осуществлении программы в целом.

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

Модифицированный нисходящий метод

Еще один недостаток нисходящего метода – полнота тестирования. В методе также сложно проверять исключительные ситуации.

Модифицированный метод требует, чтобы каждый модуль прошел автономное тестирование перед подключением к программе. Этот метод решает перечисленные проблемы, но все равно нужны как драйверы, так и заглушки.

Метод большого скачка

Это самый распространенный подход в интеграции модулей. Каждый модуль тестируется автономно. По окончанию тестирования модулей они интегрируются в систему все сразу.

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

Метод «сэндвича»

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

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

Модифицированные метод «сэндвича»

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


 

А также другие работы, которые могут Вас заинтересовать

35293. Заболевание и аномалии наружного уха, характер нарушения слуха при этом 14.85 KB
  Аномалии развития ушной раковины могут заключаться в макротии (увеличение размера), микротии (уменьшение размера) вплоть до анотии (полного отсутствия раковины) и оттопыренности ушной раковины. Эти дефекты устраняются с помощью пластических операций.
35294. Мышцы губ, их подвижность, значение в артикуляции, иннервация 15.09 KB
  В области скул выделяют большую и малую скуловые мышцы. Обе мышцы сдвигают уголки рта вверх и в стороны. Точка начала располагается на скуловой кости и верхней челюсти. В месте крепления мышцы переплетаются с круговой мышцей рта и врастают в кожу угла рта.
35295. Три типа строения сосцевидного отростка. Антрит, мастоидит. Характер нарушения слуха при этих заболеваниях у детей 15.15 KB
  Мастоидит — воспаление слизистой выстилки пещеры (антрума) и ячеистых структур сосцевидного отростка височной кости. Развивается вследствие распространения инфекции на ячейки. Воспаление приводит к разрушению костных структур.
35296. Тема: Управління теками файлами і ярликами Мета: придбати уміння і навик роботи з теками і файлами а також с. 38 KB
  Відкрити вікно теки диска D: і створити в ній скажімо теку Petrenko букви латинські; 1 Відкрили диск D: і створили теку Petrenko. 2 Створити теку через FR натиснувши F7. Перейменувати теку Petrenko в теку Петренко букви кирилиці; 1 Перейменували теку Petrenko в теку Петренко натиснувши F2. 2 Виділити теку і відкривши контекстне меню натиснути перейменувати.
35297. Тема. Побудова багаточлена Лагранжа. 220.5 KB
  Побудова багаточлена Лагранжа. Навчитися будувати багаточлен Лагранжа скласти алгоритм. Індивідуальне завдання Знайти наближене значення функції при даному значенні аргументу за допомогою інтерполяційного багаточлена Лагранжа. Що називають вузлами інтерполяції і як вони Яка ідея методу інтерполяції за допомогою багаточлена Лагранжа.
35298. Тема. Знаходження коренів нелінійного рівняння методом хорд. 86.5 KB
  Знаходження коренів нелінійного рівняння методом хорд. навчитися відокремлювати корені рівняння графічно та уточнювати методом хорд. Індивідуальне завдання: Відокремити корінь 1 – ого рівняння графічно а 2 – ого аналітично та уточнити його методом хорд з точністю 0001. 1ше рівняння 2ге рівняння Контрольні питання: В яких випадках виникає необхідність застосовувати наближені способи вирішення рівняннь Скільки етапів вирішення рівняння наближеними методами Як відокремити корені графічно В чому суть методу хорд ...
35299. Методики исследования слуха (шепотной, разговорной речью, камертонами). Аудиометрия – пороговая, тональная и надпороговая (ФУНГ) 15.46 KB
  Тест Швабаха — камертон помещается на сосцевидный отросток. При патологии внутреннего уха и n.vestibularis время костной проводимости уменьшено или равно 0. При поражении среднего уха время костной проводимости увеличивается.