Бьерн Страуструп. Язык программирования С++

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

Программа, которая не прошла тестирование, не работает. Идеал, чтобы

после проектирования и (или) верификации программа заработала с

первого раза, недостижим для всех, за исключением самых тривиальных

программ. Следует стремиться к идеалу, но не заблуждаться, что

тестирование простое дело.

"Как проводить тестирование?" - на этот вопрос нельзя ответить

в общем случае. Однако, вопрос "Когда начинать тестирование?" имеет

такой ответ - на самом раннем этапе, где это возможно. Стратегия

тестирования должна быть разработана как часть проекта и включена

в реализацию, или, по крайней мере, разрабатываться параллельно

с ними. Как только появляется работающая система, надо начинать

тестирование. Откладывание тестирования до "проведения полной

реализации" - верный способ выйти из графика или передать версию

с ошибками.

Всюду, где это возможно, проектирование должно вестись так,

чтобы тестировать систему было достаточно просто. В частности,

имеет смысл средства тестирования прямо встраивать в систему.

Иногда это не делается из-за боязни слишком объемных проверок на

стадии выполнения, или из-за опасений, что избыточность, необходимая

для полного тестирования, излишне усложнит структуры данных.

Обычно такие опасения неоправданы, поскольку собственно программы

проверки и дополнительные конструкции, необходимые для них,

можно при необходимости удалить из системы перед ее поставкой

пользователю. Иногда могут пригодится утверждения о свойствах

программы (см. $$12.2.7).

Более важной, чем набор тестов, является подход, когда

структура системы такова, что есть реальные шансы убедить себя

и пользователей, что ошибки можно исключить с помощью определенного

набора статических проверок, статического анализа и тестирования.

Если разработана стратегия построения системы, устойчивой к ошибкам

(см.$$9.8), стратегия тестирования обычно разрабатывается как

вспомогательная.

Если вопросы тестирования полностью игнорируются на этапе

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

поставки и сопровождением системы. Лучше всего начать работать

над стратегией тестирования с интерфейсов классов и их

взаимозависимостей (как предлагается в $$12.2 и $$12.4).

Трудно определить необходимый объем тестирования. Однако,

очевидно, что проблему представляет недостаток тестирования,

а не его избыток. Сколько именно ресурсов в сравнении с проектированием

и реализацией следует отвести для тестирования зависит от

природы системы и методов ее построения. Однако, можно предложить

следующее правило: отводить больше ресурсов времени и человеческих

усилий на тестирование системы, чем на получения ее первой реализации.

11.3.6 Сопровождение

"Сопровождение программного обеспечения" - неудачный термин. Слово

"сопровождение" предлагает неверную аналогию с аппаратурой. Программы

не требуют смазки, не имеют движущихся частей, которые изнашиваются

так, что требуют замены, у них нет трещин, в которые попадает

вода, вызывая ржавчину. Программы можно воспроизводить в точности

и передавать в течении минуты на длинные расстояния. Короче,

программы это совсем не то, что аппаратура. (В оригинале:

"Software is not hardware").

Деятельность, которая обозначается, как сопровождение программ,

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

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

Если в проекте учтены вопросы расширяемости, гибкости и переносимости,

то обычные задачи сопровождения решаются естественным образом.

Подобно тестированию задачи сопровождения не должны решаться

вне основного направления развития проекта и их не следует откладывать

на потом.

11.3.7 Эффективность

Д. Кнуту принадлежит утверждение "Непродуманная оптимизация - корень

всех бед". Некоторые слишком хорошо убедились в справедливости этого

и считают вредными все заботы об оптимизации. На самом деле вопросы

эффективности надо все время иметь в виду во время проектирования и

реализации. Это не означает, что разработчик должен заниматься

задачами локальной оптимизации, только задача оптимизации на самом

глобальном уровне должна его волновать.

Лучший способ добиться эффективности - это создать ясный и

простой проект. Только такой проект может остаться относительно

устойчивым на весь период развития и послужить основой для

настройки системы с целью повышения производительности. Здесь

важно избежать "гаргантюализма", который является проклятием

больших проектов. Слишком часто люди добавляют определенные

возможности системы "на всякий случай" (см. $$11.3.3.2 и $$11.4.3),

удваивая, учетверяя размер выполняемой программы ради завитушек.

Еще хуже то, что такие усложненные системы трудно поддаются

анализу, а по этому трудно отличить избыточные накладные расходы

от необходимых и провести анализ и оптимизации на общем уровне.

Оптимизация должна быть результатом анализа и оценки производительности

системы, а не произвольным манипулированием с программным кодом,

причем это особенно справедливо для больших систем, где интуиция

разработчика или программиста не может служить надежным указателем

в вопросах эффективности.

Важно избегать по сути неэффективных конструкций, а так же

таких конструкций, которые можно довести до приемлемого уровня

выполнения, только затратив массу времени и усилий. По этой же

причине важно свести к минимуму использование непереносимых по

своей сути конструкций и средств, поскольку их наличие препятствует

работе системы на других машинах (менее мощных, менее дорогих).