Пятнадцатая лекция

15. Надёжность программ

План

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

Критерии качества программного обеспечения.

Понятие о тестировании программного обеспеченя и его уровнях.

Способы тестирования программ.

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

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

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

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

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

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

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

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

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

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

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

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

2. Тестирование программного обеспечения.

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

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

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

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

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

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

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

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

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

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

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

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