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

Как бы тщательно вы ни проводили тестирование, создать программ% ный продукт, лишенный ошибок, вам не удастся – для написания тес% тового кода нужно потратить столько же сил и изобретательности, сколько для обычного кода. Некоторые ошибки неизменно проскаль% зывают сквозь самые строгие процедуры тестирования (исследования показывают, что наиболее тщательно протестированные продукты со% держат от 0.5 до 3 ошибок на 1000 строк кода) (Myers 86). На практике тестирование гарантирует не 100%процентную надежность программ, а лишь достаточную их адекватность решаемым задачам.

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

Типы тестирования

Есть много разновидностей программных тестов, и ни один из них не обладает превосходством над остальными. В каждом методе код рас% сматривается с определенной стороны и выполняется поиск опреде% ленного класса ошибок. Все тесты необходимы.

Блочное тестирование

Под блочным тестированием обычно понимают тестирование мо# дуля кода (например, библиотеки, драйвера устройства или стека протоколов), но в реальности это тестирование неделимых единиц, таких как классы или функции.

Блочное тестирование проводится строго изолированно. Любой нена% дежный внешний код, с которым взаимодействует блок, заменяется заглушкой, или имитатором; это обеспечивает поиск ошибок только в данном блоке, а не тех, которые обусловлены внешним влиянием.

Тестирование компонент

На следующем шаге – тестировании компонент – проверяется рабо% тоспособность одного или нескольких блоков в составе компонен% ты. Часто именно это подразумевают под блочным тестированием.

Комплексное тестирование

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

Регрессивное тестирование

Это повторное тестирование, проводимое после исправлений или модификации программного обеспечения или его окружения. Рег% рессивные тесты проверяют, что программное обеспечение работает

Альфа, бета, гамма…

А как насчет альфа% и бета%тестирования? Эти термины встреча% ются часто, но относятся к несколько другому кругу проблем, чем рассмотренные выше. Их задачей, скорее, является тестиро% вание окончательного продукта, а не отдельных участков кода. Тем не менее стоит остановиться на этих понятиях.

К счастью, формальных определений у них нет. У каждой компа% нии существуют свои представления о том, что означают альфа% или бета%состояния ее программного продукта. Но обычно про% граммы стадии «альфа» прочны, как лимонное желе, и взрыва% ются при попадании на них света. Альфа% и бета%программы час% то выпускают за пределы территории разработки для предвари% тельной оценки клиентами, чтобы получить первоначальные от% зывы и хоть какую%то уверенность в правильности направления.

Чаще всего термины интерпретируют так:

Альфа версия

Первая стадия «законченного кода». Может иметь бесчислен% ное количество ошибок и быть совершенно ненадежной. Аль% фа%версия дает хорошее представление о том, каким будет ко% нечный продукт, если не обращать внимания на очевидные недочеты.

Бета версия

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

Кандидат на выпуск

Это последняя стадия перед формальным выпуском программ% ного продукта. Кандидаты на выпуск проходят верификацию и тестирование качества (validation), перед тем как пойти в производство. Кандидаты на выпуск – это внутренние сбор% ки, обычно проверяемые только отделом контроля качества.

Альфа% и бета%версии, выпускаемые для публики, обычно имеют некоторые механизмы защиты (например, ограничение времени функционирования). Кандидаты на выпуск – это «чистые» сбор% ки без такого рода ограничений.

вится с написанием теста для кода, который сам разработал.

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

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

Существует инструментарий для модификации кода и замера ре% зультатов тестирования. Без такого инструментария метод белого ящика был бы вообще немыслим.

Время тестировать

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

1Если вы модифицируете исходный код, то фактически тестируете неокон%

чательный вариант, что вызывает некоторую тревогу.