Нисходящее тестирование интеграций.
Здесь модули объединяются сверху вниз по управляющей иерархии, подчиненные модули добавляются в структуру или в результате поиска в глубину, или в результате поиска в ширину.
М1-М2-М5-М6-М8…– в глубину;
М1-М2-М3-М4-М5…– в ширину.
Возможные шаги процесса нисходящей интеграции:
Главный управляющий модуль используется как тестовый драйвер, если непосредственно подчинённые ему модули временно замещаются заглушками.
Одна из заглушек заменяется реальным модулем. Модуль выбирается поиском в ширину или в глубину.
После подключения каждого модуля и установки на нём заглушек проводится набор тестов, проверяющих полученную структуру.
Если в модуле-драйвере уже нет заглушек, производится смена модуля-драйвера поиском в ширину или в глубину.
Возврат к п.2 до тех пор, пока не будет построена целая структура.
Достоинство:
Ошибки в главной управляющей части системы выявляются в первую очередь.
Недостаток:
Трудности в ситуациях, когда для полного тестирования на верхнем уровне нужны результаты обработки с нижних уровней иерархии.
Восходящие тестирования интеграций.
Сборка и тестирование системы начинается с модулей атомов, располагаемых на нижнем уровне иерархии. Модули подключаются снизу вверх, подчиненные модули всегда доступны, заглушки не нужны.
Шаги методики восходящей интеграции:
Модули нижнего уровня объединяются в кластеры (несколько модулей, т.е. в группы), выполняющие определенные программные подфункции.
Для координации вводов-выводов тестового варианта имеется драйвер, управляющий тестированием кластеров.
Тестируется кластер.
Драйверы удаляются, а кластеры объединяются в структуру движениями вверх.
Сравнение нисходящего и восходящего тестирования.
Нисходящее тестирование основной недостаток: необходимость заглушек и связанных с ними трудностей.
Достоинство: возможность раннего тестирования главных управляющих функций.
Восходящее тестирование основной недостаток: система не существует как объект до тех пор, пока не будет добавлен последний модуль.
Достоинство: упрощается разработка тестовых вариантов, отсутствуют заглушки.
Замечание: возможен комбинированный подход: для верхних уровней иерархии применяют нисходящую стратегию, а для нижних уровней – восходящую стратегию. При проведении тестирования интеграций важно выявить критические модули.
Признаки критического модуля:
Реализует несколько требований к программной системе.
Имеет высокий уровень управления (находится достаточно высоко в программной структуре).
Имеет высокую сложность или склонность к ошибкам.
Имеет определенные требования производительности обработки.
Такие модули должны тестироваться как можно раньше. К ним должны применяться регрессивное тестирование (повторение выполненных тестов в полном или частичном объёме).
Тестирование правильности.
Цель: подтвердить, что функция, описанная спецификации требований к программной системе соответствует ожиданиям заказчика.
Используется метод чёрного ящика. Важнейшим элементом является проверка конфигурации программной системы.
Конфигурацией программной системы называют совокупность всех элементов информации, вырабатываемых в процессе конструирования программной системы (ПС).
Базовые элементы конфигурации ПС:
Системная спецификация.
План программного проекта.
Спецификация требований к ПС.
Предварительное руководство пользователя.
Спецификация проектирования.
Листинги исходных тестов программ.
План и методика тестирования, тестовые варианты и полученные результаты.
Руководства по работе и инсталляции.
Exe-код выполняемой программы.
Описание базы данных.
Руководство пользователя по настройке.
Документы сопровождения, отчёты о проблемах ПС, запросы сопровождения, отчёты о конструкторских изменениях.
Стандарты и методики конструирования.
Разработчик не может предугадать, как заказчик будет реально использовать ПС. Для обнаружения ошибок, которые будут найдены только конечным пользователем, используется процесс, включающий альфа и бетта-тестирования.
Альфа-тестирование проводится заказчиком в организации разработчика. Исполнитель фиксирует все выявленные заказчиком ошибки и проблемы использования.
Бетта-тестирование проводится конечным пользователем в организации заказчиков. Это реальное ПС в среде, которая не управляется разработчиком. Заказчик сам записывает все обнаруженные проблемы и сообщает о них разработчику. Бетта-тестирование проводится в течение фиксированного срока (примерно - год).