Верификация программного обеспечения (стр. 40 )

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

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

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

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

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

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

Сбои

Можно выделить следующие три вида сбоев, вызывающих отказные ситуации:

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

Для классификации сбоев по категориям выделим следующие параметры сбоя:

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

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

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

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

Таблица 8 Классификация типов сбоев системы

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

Отказы и аварии

Отказы вызывают длительное нарушение функционирования системы, или, по ГОСТ 27.002-89 [21] приводят ее в предельное состояние. Предельное состояние – это состояние, при котором дальнейшая эксплуатация системы недопустима или нецелесообразна, либо восстановление ее работоспособного состояния невозможно или нецелесообразно. Тем самым в ГОСТ 27.002-89 не делается разницы между отказом и аварией. Будем называть отказом состояние системы, при котором восстановление ее работоспособного состояния возможно.

Отказы классифицируются согласно ГОСТ 27.002-89 следующим образом:

По временным характеристикам:

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

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

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

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

По причинам:

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

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

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

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

По способу обнаружения

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