Программист-прагматик. Путь от подмастерья к мастеру

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

Кроме того, осознание, что вы прошли тест, дает вам большую степень уверенности в том, что этот фрагмент программы "готов".

Подсказка 63: Программа не считается написанной, пока не пройдет тестирование

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

Необходимо рассмотреть три основных аспекта тестирования в масштабе всего проекта: что тестировать, как тестировать и когда тестировать.

Что тестировать

Существует несколько видов процедур тестирования программного обеспечения, которые вам приходится выполнять:

• Модульное тестирование

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

• Подтверждение правильности и верификация

• Тестирование в условиях нехватки ресурсов, ошибки и их исправление

• Тестирование производительности

• Тестирование удобства использования

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

Модульное тестирование

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

Как только все соответствующие модули прошли индивидуальное тестирование, вы готовы к новому этапу. Вам придется проверить, как модули используют друг друга и взаимодействуют между собой по всей системе.

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

Комплексное тестирование показывает, что основные подсистемы, из которых состоит проект, работают и нормально взаимодействуют друг с другом. При наличии удачных и хорошо проверенных контрактов обнаружить любые проблемы интеграции не составляет особого труда. В противном случае интеграция становится благодатной почвой для размножения дефектов. Фактически в многих случаях она является единственным и самым крупным источником дефектов в системе.

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

Подтверждение правильности и верификация

Как только в вашем распоряжении появляется рабочий пользовательский интерфейс или прототип, вам приходится отвечать на существенный вопрос: пользователи сказали вам, что они хотели бы увидеть, но то ли это на самом деле?

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

Тестирование в условиях нехватки ресурсов, ошибки и их исправление.

Теперь вы понимаете, что система будет вести себя корректно в идеальных условиях, вам придется испытать, как она ведет себя в реальных условиях. В реальном мире ресурсы ваших программ не безграничны – они исчерпываются. Ваша программа может столкнуться со следующими ограничениями:

• Объем памяти

• Объем дискового пространства

• Мощность процессора

• Тактовая частота

• Скорость дискового обмена

• Пропускная способность сети

• Цветовая палитра

• Разрешающая способность экрана

Вы можете реально проверить нехватку дискового пространства или объема памяти, но как часто вы проверяете другие ограничения? Будет ли ваше приложение работать на экране с разрешением 640*480 и 256 цветами? Может ли оно выполняться на экране с разрешением 1600*1280 с 24-битным цветом и при этом не быть размером с почтовую марку? Завершится ли пакетное задание до момента запуска программы архивации?

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