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

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

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

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

Тестирование этого типа выполняется конечным пользователем модуля, компонента или системы для определения его (ее) производительности. Этот этап является частью процесса аттестации ПО

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