Пошаговое тестирование — Тестирование модулей

ПОШАГОВОЕ ТЕСТИРОВАНИЕ

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

Возникает вопрос: «Что лучше — выполнить по отдельности тестирование каждого модуля, а затем, комбинируя их, сформи­ровать рабочую программу или же каждый модуль для тестиро­вания подключать к набору ранее оттестированных модулей?». Первый подход обычно называют монолитным методом, или ме­тодом «большого удара», при тестировании и сборке программы;

второй подход известен как пошаговый метод тестирования или сборки.

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

Детального разбора обоих методов мы делать не будем, при­ведем лишь некоторые общие выводы.

1.Монолитное тестирование требует больших затрат труда. При пошаговом же тестировании «снизу-вверх» затраты труда сокращаются.

2.Расход машинного времени при монолитном тестировании меньше.

3.Использование монолитного метода предоставляет большие возможности для параллельной организации работы на начальной фазе тестирования (тестирования всех модулей одновременно). Это положение может иметь важное значение при выполнении больших проектов, в которых много модулей и много исполнителей, поскольку численность персонала, участвующего в проекте, максимальна на начальной фазе.

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

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

6.Результаты пошагового тестирования более совершенны.

В заключение отметим, что п. 1, 4, 5, 6 демонстрируют пре­имущества пошагового тестирования, а п. 2 и 3 — его недостат­ки. Поскольку для современного этапа развития вычислительной техники характерны тенденции к уменьшению стоимости аппаратуры и увеличению стоимости труда, последствия ошибок в математическом обеспечении весьма серьезны, а стоимость уст­ранения ошибки тем меньше, чем раньше она обнаружена; пре­имущества, указанные в п. 1, 4, 5, 6, выступают на первый план. В то же время ущерб, наносимый недостатками (п. 2 и 3), неве­лик. Все это позволяет нам сделать вывод, что пошаговое тести­рование является предпочтительным.

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

Во-первых, термины «нисходящее тестирование», «нисходя­щая разработка», «нисходящее проектирование» часто исполь­зуются как синонимы. Действительно, термины «нисходящее тес­тирование» и «нисходящая разработка» являются синонимами (в том смысле, что они подразумевают определенную стратегию при тестировании и создании текстов модулей), но нисходящее проектирование — это совершенно иной и независимый процесс. Программа, спроектированная нисходящим методом, может тес­тироваться и нисходящим, и восходящим методами.

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

 

Популярные статьи

 

БАНКИ ДАННЫХ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ УПРАВЛЕНИЯ
ДОСТОИНСТВА И НЕДОСТАТКИ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ ОБРАБОТКИ ДАННЫХ
ВИДЫ ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ 
ОСНОВНЫЕ ПОНЯТИЯ ТЕОРИИ АЛГОРИТМОВ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ АВТОМАТИЗАЦИИ ОФИСА
КОМПЛЕКСНОЕ ТЕСТИРОВАНИЕ
КОМПОНЕНТЫ ИНФОРМАЦИОННОЙ ТЕХНОЛОГИИ АВТОМАТИЗАЦИИ ОФИСА
АВТОМАТИЗИРОВАННОЕ РАБОЧЕЕ МЕСТО СПЕЦИАЛИСТА
ЭТАПЫ РАЗВИТИЯ ИНФОРМАТИЗАЦИИ
ПОНЯТИЕ МУНИЦИПАЛЬНОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ 
РЕЖИМЫ ОБРАБОТКИ ИНФОРМАЦИИ
ФУНКЦИИ АВТОМАТИЗИРОВАННОЙ ИНФОРМАЦИОННОЙ ТЕХНОЛОГИИ
МЕТОДЫ ОБЕСПЕЧЕНИЯ НАДЕЖНОСТИ ПРОГРАММНЫХ СРЕДСТВ
ПРАВИЛА ЗАЩИТЫ ОТ КОМПЬЮТЕРНЫХ ВИРУСОВ
ДОКУМЕНТАЛЬНЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ
ПРОТОКОЛЫ ТЕСТИРОВАНИЯ
ДЕСТРУКТИВНЫЕ ВОЗМОЖНОСТИ ВИРУСОВ
КЛАССИФИКАЦИЯ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
КОНЦЕПТУАЛЬНАЯ, ЛОГИЧЕСКАЯ И ФИЗИЧЕСКАЯ МОДЕЛИ
КОМПЬЮТЕРНЫЕ ТЕХНОЛОГИИ ПОДГОТОВКИ ТЕКСТОВЫХ ДОКУМЕНТОВ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ ЭКСПЕРТНЫХ СИСТЕМ
ДИАЛОГОВЫЙ РЕЖИМ АВТОМАТИЗИРОВАННОЙ ОБРАБОТКИ ИНФОРМАЦИИ
ТЕХНИЧЕСКОЕ ОБЕСПЕЧЕНИЕ КОМПЬЮТЕРНЫХ СЕТЕЙ