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

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

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

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

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

5.4.1. ЧИСЛО ТЕСТОВЫХ ПРОГОНОВ

Само по себе число тестовых прогонов программы зачастую не является определяющим фактором. Дело в том, что программам не присуще явление старения, и поэтому, если некоторая программа выполняет сложение нескольких чисел правильно, то она будет выполнять его правильно и для других чисел, сколько раз ни производилась бы эта операция. Точно так же само по себе количество проверок не может гарантировать полноты проведенных испытаний. Если, например, вы обрабатываете 100 тестовых записей, содержащих некоторые реальные входные данные, то 90 из них будут вести себя одинаково, т. е. при этом проверяется лишь основная логическая ветвь программы. Остальные 10 записей, вероятно, позволят дополнительно испытать еще какие-нибудь две ветви, и, таким образом, 100 обработанных записей в данном случае представляют собой лишь три контрольных примера.

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

Очень часто прогон большого количества тестов просто позволяет убедиться, что программа хорошо выполняет одну и ту же совокупность операций над различными числами. Однако цель тести-рования состоит совсем не в этом, а в том, чтобы гарантировать живучесть триграммы. Мы всегда хотим, чтобы очередной тестовый прогон контролировал нечто такое, что не было проверено в предыдущих орогонах. И задача тестирования заключается в том, чтобы создать для программы предельно напряженный режим работы. А это требует от программиста хорошего воображения и недоверчивого отношения к своей программе.

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