Студопедия

Главная страница Случайная страница

Разделы сайта

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






Определение дефектов в зависимости от спецификаций ПО






 

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

 

Обработка ошибок или обработка исключительных ситуаций?

 

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

 

 

Таблица7.1. Типы тестирования, используемые в процессе разработки ПО
Tun тестирования
Описание
Блочное тестирование, или шстирование элементов (unit testing) ПО тестируется поэлементно. Под элементом может подразумеваться отдельный про г раммный модуль, коллекция модулей, функция, процедура, ал г оритм, объект, про г рамма или компонент
Проверка взаимодействия и функционирования компонентов системы (integration testing) Тестируется некоторая совокупность элементов. Элементы объединяются влогические группы, и каждая группатестирует-ся как единый блок (элемент). Эти группы могут подвергаться одинаковым проверкам. Если группа элементов проходит тест, ее присоединяют к тестируемой совокупности, которая в свою очередь должна быть протестирована с новым дополнением. Увеличение количества элементов, подлежащих тестированию, должно подчиняться формулам комбинаторики
Регрессивное теcmupoвaние (regression testing) Программные модули должны повторно тестироваться, если в них были внесены изменения. Регрессивное тестирование дает гарантию, что изменение любого компонента не приведет к потере функциональности
Испытания в утяже-ленном режиме (stress testing) Тестирование, которое проводится для компонента или всей системы при предельных и «запредельных» значениях входных параметров. Использование траничных условий позволяет определить, что может произойти с компонентом или системой в нештатных ситуациях
Эксплуатационные испытания (o p erational testing) Тестирование системы с полной нагрузкой. Для этого используется реальнал среда, создающая реальную нагрузку. Этот тип тестирования также применяется для определения производительности системы в совершенно незнакомой среде
Тестирование спецификации (s p ecification testing) Компонент проверяетс я при сравнении с исходными спецификаци я ми. Именно спецификаци я устанавливает, какие компоненты включены в систему и какие взаимоотношения должны быть между ними. Этот этап я вл я ется частью процесса верификации ПО
Приемочные испытания (acce p tance testing) Тестирование этого типа выполняется конечным пользователем модуля, компонента или системы для определения его (ее) производительности. Этот этап является частью процесса аттестации ПО
     

 

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

if < входные данные неприемлемы, то>

< повторно запрашиваем входные данные>

else

< выполняем нужную операцию> end if

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

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

 

 

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

 

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

 

  Рис. 7.3. Архитектура упрощенного компонента обработки ошибок

 

 

Компонент 1 на рис. 7.3— это простой компонент отображения (map), который содержит список номеров ошибок и их описания. Компонент 2 содержит объект, который преобразует номера ошибок в адреса переходов, функций или подсистем. По номеру ошибки компонент 2 определяет направление перехода. Компонент 3 преобразует номера ошибок в иерархическую структуру отчетов и логику отчетов. Иерархическая структура отчетов содержит данные о том, кого (или что) необходимо уведомить об ошибке. Логика отчетов определяет, что должно включать это уведомление. Компонент 4 содержит два объекта отображения. Первый преобразует номера ошибок в объекты, назначение которых — скорректировать некоторые ситуации сбоя (условия). Второй преобразует номера ошибок в объекты, которые возвращают систему в стабильное или хотя бы частично стабильное состояние. Упрощенный компонент обработки ошибок, показанный на рис. 7.3, можно применить к ПО любого размера и формы. Характер использования компонентов обработки ошибок и исключительных ситуаций определяется требуемой степенью надежности ПО.

 

Надежность ПО: простой план

 

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

• Вариант1. Завершить программу.

• Вариант 2. Возвратить значение, обозначающее «ошибку».

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

• Вариант 4. Вызвать функцию, предназначенную для вызова в случае ошибки.

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

Очевидно, что завершать программу при каждом обнаружении ошибки попросту неприемлемо. Здесь мы согласны со Страуструпом. В таких случалх следует поступать более изобретательно. Что касается варианта 2, то примитивный возврат значения ошибки действительно может помочь в некоторых ситуациях, но далеко не во всех. Не каждое возвращаемое значение может интерпретироваться как успешное или неудачное. Например, если значение, возвращаемое некоторой функцией, имеет вещественный тип, и область определения функции включает как отрицательные, так и положительные значения, то какое тогда значение функции можно использовать для представления ошибки? Другими словами, это не всегда возможно. С нашей точки зрения, вариант 3 также неприемлем. Ведь если «изготовитель» возвращает значение, обозначающее нормальное завершение, «потребитель» продолжит работу, предположив, что его запрос был выполнен, а это может вызвать еще большие проблемы. Осталось рассмотреть вариант 4. Он требует более внимательного подхода при обсуждении обработки как ошибок, так и исключительных ситуаций.

 

План А: модель возобновления, план Б: модель завершения

 

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

 

 






© 2023 :: MyLektsii.ru :: Мои Лекции
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав.
Копирование текстов разрешено только с указанием индексируемой ссылки на источник.