его спецификации является дефектом. Чем выше качество спецификации, тем проще выявить дефекты и понять, где программист сделал ошибки. Если спецификация проекта расплывчата, с плохо определенными элементами и нечетко описанными требованиями, то определение протраммных дефектов для такого проекта представляет собой движущуюся мишень. Если спецификации неоднозначны, то трудно сказать, что дефектно, а что нет. Точно так же невозможно утверждать, прав ли был разработчик. Туманно определенные спецификации являются причиной так же туманно определяемых ошибок. В таких условиях создание отказоустойчивого и надежного ПО попросту невозможно.
Обработка ошибок или обработка исключительных ситуаций?
В общем случае ошибки ПО (которые являются результатом оплошности или недоработки программиста) должны быть обнаружены и исправлены на этапах тестирования, перечисленных в табл. 7.1.
| Таблица 7.1. Типы тестирования, используемые в процессе разработки ПО | |
| ПО тестируется поэлементно. Под элементом может подразумеваться отдельный про | |
| Тестируется некоторая совокупность элементов. Элементы объединяются влогические группы, и каждая группатестирует-ся как единый блок (элемент). Эти группы могут подвергаться одинаковым проверкам. Если группа элементов проходит тест, ее присоединяют к тестируемой совокупности, которая в свою очередь должна быть протестирована с новым дополнением. Увеличение количества элементов, подлежащих тестированию, должно подчиняться формулам комбинаторики | |
| Программные модули должны повторно тестироваться, если в них были внесены изменения. Регрессивное тестирование дает гарантию, что изменение любого компонента не приведет к потере функциональности | |
| Тестирование, которое проводится для компонента или всей системы при предельных и «запредельных» значениях входных параметров. Использование траничных условий позволяет определить, что может произойти с компонентом или системой в нештатных ситуациях | |
| Тестирование системы с полной нагрузкой. Для этого используется реальнал среда, создающая реальную нагрузку. Этот тип тестирования также применяется для определения производительности системы в совершенно незнакомой среде | |
| Компонент проверяетс | |
| Тестирование этого типа выполняется конечным пользователем модуля, компонента или системы для определения его (ее) производительности. Этот этап является частью процесса аттестации ПО | |
Во время процесса тестирования и отладки программные дефекты должны быть обнаружены и ликвидированы. Однако исключительные ситуации (исключения) обрабатываются во время выполнения программы. Следует различать исключительные и нежелательные условия. Например, если мы спроектировали программу, которая будет добавлять в список числа, вводимые пользователем, а пользователь будет вводить и числа, и символы, которые не являются числами, то такая ситуация относится к нежелательной, а не к исключительной. Мы должны проектировать программы, которые были бы робастными, т.е. устойчивыми к ошибкам, прелусматривал проверку корректности входных данных. Ввод данных в программу должен быть организован таким образом, чтобы пользователь был вынужден вводить данные, которые требуются нашей программе для надлежащего выполнения. Если, например, спроектированный нами компонент программы сохраняет информацию на внешнем устройстве, и программа попадает в ситуацию отсутствия свободного пространства на этом устройстве, то такие условия работы программы также можно назвать нежелательными, а не исключительными, или экстраординарными. Исключительные ситуации мы связываем с необычными условиями, а не с нежелательными. Методы обработки исключительных ситуаций предназначены для непредвиденных обстоятельств. Ситуации же, которые являются нежелательными, но вполне возможными и потому предсказуемыми, должны обрабатываться с применением обычной программной логики, например:
if <входные данные неприемлемы, то>
<повторно запрашиваем входные данные>
else
<выполняем нужную операцию> end if
Такая проверка условий — одна из основополагающих граней искусства программирования. Продемонстрированный стиль программирования позволяет не допустить возникновения многих проблем, но эта модель ситуации не «дотягивает» до определения исключительной. Существуют различия между дефектами и исключительными ситуациями, а также между исключительными ситуациями и
