Структурное проектирование
Такой метод хорошо согласуется с принципами структурного проектирования, требующими разбиения на логические и функциональные модули. Каждый из них проверяется индивидуально, но не изолированно. Тестирование, согласно общему принципу, производится сверху-вниз. На каждом этапе функции модулей более низкого уровня моделируются при тестировании данного модуля по всем его логическим ветвям. Как было показано в примере на рисунке,. число различных проверок, которые можно придумать (по одной для каждой логической ветви), в значительной степени определяется суммой ветвей каждого модуля, а не их произведением, которое тоже является важным фактором и определяет число комбинаций значений, передаваемых от одного модуля к другому.
Тестирование такой модульной программы начинается с головного модуля в среде, образуемой моделями остальных модулей. После проверки модуль может быть присоединен к программе и можно будет приступить к исследованию подчиненных ему модулей. Поэтому общая функция всей программы видна с самого начала и все фундаментальные проблемы выясняются на начальных этапах тестирования.
Нужно хорошо продумать данные для тестирования, обеспечивающие проверку каждого модуля по всем его логическим ветвям. Кроме данных, обеспечивающих выполнение операторов программы в требуемой последовательности, во входном наборе должны содержаться данные, проверяющие граничные условия. Например, переход, осуществляемый по условию превышает ли некоторое действительное число значение 10?, должен проверяться для значений, больших, меньших и равных 1.0. Кроме того, должно быть установлено, что выполнение шло по требуемой ветви. Это достигается введением в код соответствующих операторов трассировки, которые указывали бы на то, что выполнение прошло по заданной ветви.
После проверки кода эти операторы могут быть удалены. Некоторые компиляторы предоставляют возможность пользоваться отладочными операторами, которые могут вставляться или игнорироваться в зависимости от значений отладочных переключателей, задаваемых, например, в картах управления заданием. Альтернативный метод, позволяющий убедиться в том, что весь код проверен, состоит в тестировании программы, выполняемой под управлением служебной программы, которая подсчитывает число выполнений каждого оператора.
Как будет показано в следующем разделе, такие служебные (профилирующие) программы в первую очередь применяются для оценки и повышения эффективности программы. Однако данные, выдаваемые ими, применяются и на этапе тестирования не для определения частоты использования операторов, а чтобы показать, какие операторы при прогоне не были выполнены и, значит, не оттестированы.
Подготовку больших объемов данных для тестирования можно упростить, используя компилятор для форматирования или генерации соответствующих входных данных. Тестовые файлы, содержащие эти данные, могут быть записаны специальной программой или генератором общего назначения. Для проверки граничных условий к этому должны быть добавлены критические последовательности кодов и условия, приводящие к ошибкам. Для каждого набора входных данных должно быть определено, что считать правильным результатом. После завершения теста данные, выданные программой, должны быть сверены с предварительно вычисленными результатами. Должны быть выявлены все несоответствия, и, если программа выдала неверный результат, должны быть найдены и исправлены ошибки. Тестирование программы завершается, когда программа выдала правильный результат по всем логическим ветвям.