УМК ВиН correp / ЛН / Надежность программ

4

Существующие и описанные в литературе методы расчета надежности (Н) традиционно ориентировались на учет аппаратных отказов.

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

О программной надежности

Без программного обеспечения вычислительная система – «мертвый» набор аппаратных средств. Именно сбои в программном обеспечении были причиной многих известных аварий, в частности, в полетах космических кораблей, работе энергосистем…

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

Программа может быть не согласована с объемом памяти ЭВМ, со входными данными (не только с их диапазоном значений, но и с частотой поступления); может иметь место несогласованность времени обращения к ячейкам памяти (то есть одновременное обращение из разных источников), могут быть просто ошибочно указаны адреса, неверно обозначены символы… А как проверить все программные «маршруты», то есть возможные сочетания команд, встречающихся в тех или ситуациях функционирования объекта?

Целесообразно выделять две стороны надежности программно управляемого объекта:

- программную надежность объекта (то есть способность объекта выполнять заданные функции в зависимости от самого замысла программ);

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

Тести́рование программного обеспечения (далее приводится материал доклада студентов гр. 346 Барычева С.Г., ЛапшинойВ.А., Милиневского А.Ю., Суворова П.А.)

Тестирование (testing) – любой вид деятельности, в рамках которой путем реального выполнения каких-либо задач проверяется работа системы в целом либо ее составной части.

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

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

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

Качество приложений обычно сильно отличается в различных системах, но есть несколько общих критериев качества программного обеспечения, таких как: надёжность, стабильность, переносимость, удобство обслуживания, простота использования (usability).

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

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

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

• Модульное тестирование (юнит-тестирование) — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволит достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, т.е. к появлению ошибок в уже написанных и оттестированных местах программы, а также облегчает локализацию и устранение таких ошибок. Юнит-тестирование помогает устранить сомнения по поводу отдельных модулей и может быть использовано для подхода к тестированию «снизу вверх»: сначала тестируются отдельные части программы, затем программа в целом. Важно понимать, что юнит-тестирование не выловит все ошибки. По определению, оно тестирует только модули сами по себе. Тем самым, вы не выявите ошибки интеграции, проблемы производительности или любые другие проблемы системы в целом. Кроме того, довольно трудно предугадать все варианты исходных данных, которые могут быть переданы модулю в реальной работе. Юнит-тестирование будет эффективным только при использовании совместно с другими способами тестирования.

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

• Системное тестирование — тестируется интегрированная система на её соответствие исходным требованиям

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

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

Существуют следующие способы тестирования:

Тестирование белого и черного ящика

При тестировании белого ящика (англ. white-box testing, также говорят — прозрачного ящика), разработчик теста имеет доступ к исходному коду и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определенной степени.

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

Любое ПО разрабатывается для работы в каких-то определенных программных (а иногда и аппаратных) конфигурациях (окружениях). Обычно набор этих конфигураций определяется сразу при установке рамок проекта и записывается в нефункциональные требования. А раз есть требование, то оно должно быть протестировано. Если какая-то функция работает под одной конфигурацией, то не факт что в разных окружениях все будет работать одинаково и правильно. А раз так, то значит что надо выполнить ВСЕ тесты для КАЖДОЙ конфигурации, чтобы быть стопроцентно уверенным в точном выполнении требований. Количество конфигурационных тестов равно произведению числа поддерживаемых конфигураций каждого типа. Так, для приведенного примера, если ПО имеет некоторые две кастомизированные версии, которые должны работать под операционными системами WinXP и Win2K и поддерживать браузеры IE и NN, то количество конфигурационных тестовых сценариев будет равно четырём.

Также можно выделить другие виды тестирования:

Разрушительные (Краш) тесты

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

Тестирование совместимости с другими модулями и системами

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

Нагрузочное тестирование

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

Таким образом тестирование ПО в некоторой степени подобно испытаниям ЭВС.

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

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