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

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

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

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

В общем случае ошибки ПО (которые являются результатом оплошности или недоработки программиста) должны быть обнаружены и исправлены на этапах тестирования, перечисленных в табл. 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. Различия между характеристиками обработки ошибок,  исключений и нежелательных условий

Обработка ошибок

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