Бьерн Страуструп - Язык программирования С++. Главы 11-13
Страница 14. Тестирование



11.3.5 Тестирование

Программа, которая не прошла тестирование, не работает. Идеал, чтобы
после проектирования и (или) верификации программа заработала с
первого раза, недостижим для всех, за исключением самых тривиальных
программ. Следует стремиться к идеалу, но не заблуждаться, что
тестирование простое дело.
      "Как проводить тестирование?" - на этот вопрос нельзя ответить
в общем случае. Однако, вопрос "Когда начинать тестирование?" имеет
такой ответ - на самом раннем этапе, где это возможно. Стратегия
тестирования должна быть разработана как часть проекта и включена
в реализацию, или, по крайней мере, разрабатываться параллельно
с ними. Как только появляется работающая система, надо начинать
тестирование. Откладывание тестирования до "проведения полной
реализации" - верный способ выйти из графика или передать версию
с ошибками.
     Всюду, где это возможно, проектирование должно вестись так,
чтобы тестировать систему было достаточно просто. В частности,
имеет смысл средства тестирования прямо встраивать в систему.
Иногда это не делается из-за боязни слишком объемных проверок на
стадии выполнения, или из-за опасений, что избыточность, необходимая
для полного тестирования, излишне усложнит структуры данных.
Обычно такие опасения неоправданы, поскольку собственно программы
проверки и дополнительные конструкции, необходимые для них,
можно при необходимости удалить из системы перед ее поставкой
пользователю. Иногда могут пригодится утверждения о свойствах
программы (см. $$12.2.7).
    Более важной, чем набор тестов, является подход, когда
структура системы такова, что есть реальные шансы убедить себя
и пользователей, что ошибки можно исключить с помощью определенного
набора статических проверок, статического анализа и тестирования.
Если разработана стратегия построения системы, устойчивой к ошибкам
(см.$$9.8), стратегия тестирования обычно разрабатывается как
вспомогательная.
    Если вопросы тестирования полностью игнорируются на этапе
проектирования, возникнут проблемы с тестированием, временем
поставки и сопровождением системы. Лучше всего начать работать
над стратегией тестирования с интерфейсов классов и их
взаимозависимостей (как предлагается в $$12.2 и $$12.4).
    Трудно определить необходимый объем тестирования. Однако,
очевидно, что проблему представляет недостаток тестирования,
а не его избыток. Сколько именно ресурсов в сравнении с проектированием
и реализацией следует отвести для тестирования зависит от
природы системы и методов ее построения. Однако, можно предложить
следующее правило: отводить больше ресурсов времени и человеческих
усилий на тестирование системы, чем на получения ее первой реализации.

 
« Предыдущая статья   Следующая статья »