3.2. Тестирование модулей
Переход к большим программам требует специальных способов структурирования процесса тестирования.
Тестирование модулей (или блоков) представляет собой процесс тестирования отдельных подпрограмм или процедур программы. Здесь подразумевается, что прежде чем начинать тестирование программы в целом, следует протестировать отдельные небольшие модули, образующие эту программу. Такой подход мотивируется тремя причинами. Во-первых, появляется возможность активно управлять процессом тестирования, поскольку внимание первоначально концентрируется на небольших модулях программы. Во-вторых, облегчается задача отладки программы, т.е. обнаружения места ошибки и исправление текста программы. Наконец, в-третьих, допускается параллелизм, что позволяет одновременно тестировать несколько модулей.
Цель тестирования модулей - сравнение функций, реализуемых модулем, со спецификациями его функций или интерфейса. Проблема состоит не в том, чтобы установить соответствие модуля его спецификации, а в том, чтобы показать противоречие между ними.
Тестирование модулей в основном ориентировано на принцип белого ящика. Процедура создания набора тестов для тестирования модулей такова: анализируется логика отдельного модуля с помощью одного или нескольких методов белого ящика, а затем этот набор тестов применяется при тестировании методами черного ящика по спецификации модуля.
Реализация процесса тестирования модулей опирается на два ключевых положения: построение эффективного набора тестов и выбор способа, посредством которого модули комбинируются при построении из них рабочей программы. Второе условие является весьма важным, т.к. оно задает форму написания тестов модуля, типы средств, используемых при тестировании, порядок кодирования и тестирования модулей, стоимость генерации тестов и стоимость отладки.
Вообще говоря, процесс тестирования и отладки тесно связан с процессом проектирования системы. Порой ошибки, обнаруживаемые в отдельных модулях, бывают настолько фатальными, что приходится перепроектировать почти всю программу. Поэтому рассматривая в данном разделе методику тестирования и отладки программы “МРК ”, мы остановимся также и на некоторых аспектах его проектирования.
Очевидно, что первоначально целесообразно тестировать и отлаживать каждый компонент системы в отдельности, а затем переходить к испытаниям всего программного комплекса в целом.
Существует два подхода к комбинированию модулей: пошаговое и монолитное тестирование. В пошаговом тестировании в свою очередь существуют два способа: тестирование снизу вверх (восходящее) и тестирование сверху вниз (нисходящее).
Возникает вопрос: что лучше - выполнить по отдельности тестирование каждого модуля, а затем комбинируя их, сформировать рабочую программу или же каждый модуль для тестирования подключать к набору ранее оттестированных модулей?
Первый подход обычно называют монолитным методом тестирования, или методом "большого удара" при тестировании и сборке программы; второй подход известен как пошаговый метод тестирования или сборки.
Метод пошагового тестирования предполагает, что модули тестируются не изолированно друг от друга, а подключаются поочередно для выполнения теста к набору уже ранее оттестированных модулей.
Монолитное тестирование выгодно на начальном этапе тестирования, когда нет готового костяка программы и еще нельзя воспользоваться пошаговым методом. В этом случае монолитное тестирование очень похоже на пошаговое, в котором вместо оттестированных модулей одни заглушки.
Пошаговое тестирование имеет целый ряд преимуществ перед монолитным тестированием на среднем окончательном этапе тестирования:
1. Монолитное тестирование требует больших затрат труда, т.к. в этом случае для каждого тестируемого модуля программы требуется написать множество модулей-заглушек. В случае же пошагового тестирования вместо модулей-заглушек используются ранее оттестированные модули.
2. При пошаговом тестировании раньше обнаруживаются ошибки в интерфейсах между модулями, поскольку раньше начинается сборка программы. В противоположность этому при монолитном тестировании модули "не видят друг друга" до последней фазы процесса тестирования.
3. Отладка программ при пошаговом тестировании легче. Если есть ошибки в межмодульных интерфейсах, то при монолитном тестировании они могут быть обнаружены лишь тогда, когда собрана вся программа. В этот момент локализовать ошибку довольно трудно, поскольку она может находиться в любом месте программы. Напротив, при пошаговом тестировании ошибки такого типа в основном связаны с тем модулем, который подключается последним.
4. При монолитном тестировании модуля результаты ограничены только этим модулем. В случае пошагового тестирования модули, оттестированные ранее, затем используются в качестве заглушек для тестирования других модулей, и таким образом, подвергаются дополнительной проверке.
Убедившись в преимуществах пошагового тестирования перед монолитным, исследуем две возможные стратегии тестирования : нисходящее и восходящее тестирование.
Нисходящее тестирование.
Нисходящее тестирование начинается с верхнего головного модуля программы. Строгой, корректной процедуры подключения очередного последовательно тестируемого модуля не существует. Единственное правило, которым следует руководствоваться при выборе очередного модуля, состоит в том, что им должен быть один из модулей, вызываемых модулем, предварительно прошедшим тестирование.
При выборе последовательности тестирования модулей рекомендуется придерживаться двух основных правил:
1. Если в программе есть критические в каком либо смысле части, то целесообразно выбирать последовательность, которая включала бы эти части как можно раньше. Критическими могут быть сложный модуль, модуль с новым алгоритмом или модуль со значительным числом предполагаемых ошибок.
2. Модули, включающие операции ввода-вывода, также необходимо включать в последовательность тестирования как можно раньше.
Основным преимуществом нисходящего тестирования является то, что уже на ранней стадии имеется рабочая версия программы, выполняющая реальные операции ввода-вывода, в то время как часть внутренних функций имитируется заглушками. Эта рабочая версия позволяет выявить ошибки и проблемы, связанные с организацией взаимодействия с человеком; она дает возможность продемонстрировать программу пользователю.
В нашем случае когда окончательная версия программы предполагается не очень большой, состоящей из небольшого количества модулей такая стратегия подходит нам лучше других.
Восходящее тестирование
Данная стратегия предполагает начало тестирования с терминальных модулей (т.е. модулей, не вызывающих другие модули). Как и ранее, здесь нет такой процедуры для выбора модуля, тестируемого на следующем шаге, которой бы отдавалось предпочтение. Единственное правило состоит в том, чтобы очередной модуль вызывал уже оттестированные модули. Как и при нисходящем тестировании на последовательность тестирования влияет критичность модуля.
Такой подход мы применим на самом начальном отладочном этапе, когда стоит вопрос об исправности самых простых модулей программы, которые будут вызываться модулями, проходящими монолитное тестирование.