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

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

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

Rice J. R. (ed.), Mathematical Software, Academic Press, New York, 1971, на стадии отладки программы, нелишне еще раз проверить правильность значений данных, передаваемых от одного модуля к другому, поскольку именно этот аспект функционирования программы является обычно источником затруднений. В связи с тем что взаимодействие между модулями ограничивается передачей известных параметров, тестирование большой программы, скомпонованной из модулей, легче, чем большой программы, не содержащей модулей. Однако обязательным условием должно быть отсутствие в модулях логических ошибок; если же такие ошибки выявляются на этапе тестирования всей программы, это значит, что тестирование модулей было несовершенным.

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

5.13.1,., ИМИТАЦИЯ РАБОТЫ МОДУЛЕЙ

Часто возникает ситуация, когда нужный модуль не готов к моменту завершения испытаний какого-либо другого модуля, и поэтому требуется имитировать работу первого. Это может быть осуществлено двумя способами: посредством фиктивного модуля и посредством замещающего модуля.

Фиктивный модуль — это такой модуль, который состоит только из одной точки входа и одной точки возврата. Используется для тестирования модулей более высокого уровня, если нужный реальный модуль еще не создан или не требуется. Часто оказывается полезным наличие в фиктивном модуле некоторого оператора, сигнализирующего об обращении к нему.

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

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

5.13.2. РЕКОМЕНДАЦИИ ПО ТЕСТИРОВАНИЮ МОДУЛЕЙ

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

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

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