Тестирование модульных программ
Кроме тестирования логики программного модуля, существует проблема тестирования комплексирующих программ, состоящих из нескольких модулей, ибо объединение протестированных модулей не всегда позволяет получать работоспособную комплексирующую программу. Рассмотрим методику тестирования таких программ на примере, приведенной на рисунке 2.6.
А
B C D
E F
Рисунок 2.6. Структура модульной программы
Наиболее распространенным приемом тестирования модульных программ является пошаговое тестирование /1/. На практике применяют две его разновидности:
восходящее тестирование;
нисходящее тестирование.
Методика восходящего тестирования включает следующие щаги:
а) сначала тестируются ‘листья’ дерева структуры программы, т.е. модули Е,C,F. Поскольку это вызываемые программы, то для их тестирования программируются драйверы (в некоторых литературных источниках для таких программ применяют термин ‘отлаживающий модуль’) В функции драйвера входит формирование тестовых данных для отлаживаемого модуля и передача ему управления (вызов модуля). Очевидно, что формирование тестовых данных в большинстве случаев
будет ни чем иным, как присвоением конкретных значений входным данным отлаживаемого модуля;
б) затем аналогично тестируются модули вышележащего уровня совместно с уже оттестированными модулями нижележащего уровня. Применительно к рассматриваемому нами примеру проектируются драйверы для тестирования пар B-E и D-F;
в) пошаговый процесс продолжается до тех пор, пока не будет включен в процесс тестирования последний модуль (‘корень’ дерева структуры программы). Для нашего примера это будет модуль А. Для его тестирования совместно с вызываемыми программами нижележащего уровня драйвер разрабатывать не требуется.
Альтернативное нисходящее тестирование состоит из следующих действий:
а) тестирование начинается с вызывающего модуля программы (‘корня’ дерева структуры программы). Для модулей нижележащего уровня (вызываемых) программируются так называемые ‘заглушки’ ( в некоторых литературных источниках эти программы называются ‘имитаторы’. Термин ‘имитатор’ точнее отражает выполняемую программой функцию - работа модуля нижележащего уровня имитируется, т.е без выполнения самого модуля формируются результаты обработки входных данных);
б) после проверки ‘корня’ дерева структуры комплексирующей программы переходят к тестированию нижележащих модулей. Причем, формализованной процедуры подключения к вызывающему модулю нижележащих вызываемых модулей не существует. Единственное ограничение, которым руководствуются при выборе очередного претендента на тестирование, заключается в том, что этот модуль должен вызываться уже оттестированным модулем вышележащего уровня. Если очередной тестируемый модуль вызывает модули еще нижележащего уровня, то аналогично пункту а) для нижележащих модулей программируются ‘заглушки’;
в) процесс тестирования продолжается до тех пор, пока не будет оттестирован последний модуль из ‘листьев’ дерева структуры программы. Приведем две возможные последовательности тестирования модулей согласно этой методики для рассматриваемого примера:
A (B,C,D), A-B (E), A-B-E, A-C, A-D (F), A-D-F;
A (B,C,D), A-B (E), A-C, A-D (F), A-B-E, A-D-F.
В скобках указаны имена модулей, для которых должны быть запрограммированы ‘заглушки’. Через черточку указываются композиции тестируемых модулей.
Сравнительный анализ приведенных методик тестирования / /, показывает, что нисходящее тестирование ставит перед программистом много проблем, касающихся разработки ‘заглушек’ и интерпретации результатов тестирования. Там же /1/ приводится сравнительная таблица недостатков и преимуществ методов восходящего и нисходящего тестирования, из которой явствует, что меньшими недостатками обладает восходящее тестирование.