Тестирование интеграций поддерживает сборку цельной программы.

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

Категории ошибок интерфейса:

­ потеря данных при прохождении через интерфейс;

­ отсутствие в модуле необходимой ссылки;

­ неблагоприятное влияние одного модуля на другой;

­ подфункции при объединении не образуют требуемую главную функцию;

­ отдельные допустимые неточности при интеграции выходят за допустимый уровень;

­ проблемы при работе с глобальными структурами данных.

Существует 2 варианта тестирования, поддерживающих процесс интеграции:

Ø нисходящее;

Ø восходящее.

Нисходящее тестирование интеграций.

Здесь модули объединяются сверху вниз по управляющей иерархии, подчиненные модули добавляются в структуру или в результате поиска в глубину, или в результате поиска в ширину.

М1

М4

М6

М8

М5

М3

М2

М7

М1-М2-М5-М6-М8…– в глубину;

М1-М2-М3-М4-М5…– в ширину.

Возможные шаги процесса нисходящей интеграции:

1. Главный управляющий модуль используется как тестовый драйвер, если непосредственно подчинённые ему модули временно замещаются заглушками.

2. Одна из заглушек заменяется реальным модулем. Модуль выбирается поиском в ширину или в глубину.

3. После подключения каждого модуля и установки на нём заглушек проводится набор тестов, проверяющих полученную структуру.

4. Если в модуле-драйвере уже нет заглушек, производится смена модуля-драйвера поиском в ширину или в глубину.

5. Возврат к п.2 до тех пор, пока не будет построена целая структура.

Достоинство:

Ошибки в главной управляющей части системы выявляются в первую очередь.

Недостаток:

Трудности в ситуациях, когда для полного тестирования на верхнем уровне нужны результаты обработки с нижних уровней иерархии.

Восходящие тестирования интеграций.

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

Шаги методики восходящей интеграции:

1. Модули нижнего уровня объединяются в кластеры (группы или блоки), выполняющие определенные программные подфункции.

2. Для координации вводов-выводов тестового варианта имеется драйвер, управляющий тестированием кластеров.

3. Тестируется кластер.

4. Драйверы удаляются, а кластеры объединяются в структуру движениями вверх.

Мс

Ма

Мb

D3

D2

D1

кластер 1

кластер 2

кластер 3

Сравнение нисходящего и восходящего тестирования.

Нисходящее тестирование основной недостаток: необходимость заглушек и связанных с ними трудностей.

Достоинство: возможность раннего тестирования главных управляющих функций.

Восходящее тестирование основной недостаток: система не существует как объект до тех пор, пока не будет добавлен последний модуль.

Достоинство: упрощается разработка тестовых вариантов, отсутствуют заглушки.

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

Признаки критического модуля:

1. Реализует несколько требований к программной системе.

2. Имеет высокий уровень управления (находится достаточно высоко в программной структуре).

3. Имеет высокую сложность или склонность к ошибкам.

4. Имеет определенные требования производительности обработки.

Такие модули должны тестироваться как можно раньше. К ним должны применяться регрессивное тестирование (повторение выполненных тестов в полном или частичном объёме).

Тестирование правильности.

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

Используется метод чёрного ящика. Важнейшим элементом является проверка конфигурации программной системы.

Конфигурацией программной системы называют совокупность всех элементов информации, вырабатываемых в процессе конструирования программной системы (ПС).

Базовые элементы конфигурации ПС:

1. Системная спецификация.

2. План программного проекта.

3. Спецификация требований к ПС.

4. Предварительное руководство пользователя.

5. Спецификация проектирования.

6. Листинги исходных тестов программ.

7. План и методика тестирования, тестовые варианты и полученные результаты.

8. Руководства по работе и инсталляции.

9. Exe-код выполняемой программы.

10. Описание базы данных.

11. Руководство пользователя по настройке.

12. Документы сопровождения, отчёты о проблемах ПС, запросы сопровождения, отчёты о конструкторских изменениях.

13. Стандарты и методики конструирования.

Разработчик не может предугадать, как заказчик будет реально использовать ПС. Для обнаружения ошибок, которые будут найдены только конечным пользователем, используется процесс, включающий альфа и бетта-тестирования.

Альфа-тестирование проводится заказчиком в организации разработчика. Исполнитель фиксирует все выявленные заказчиком ошибки и проблемы использования.

Бетта-тестирование проводится конечным пользователем в организации заказчиков. Это реальное ПС в среде, которая не управляется разработчиком. Заказчик сам записывает все обнаруженные проблемы и сообщает о них разработчику. Бетта-тестирование проводится в течение фиксированного срока (примерно - год).

Системное тестирование.

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

Проблема системного тестирования – указание причины. Она возникает, когда разработчик одного системного элемента обвиняет разработчика другого элемента в причине возникновения дефекта.

Для защиты от обвинений разработчик программного элемента должен:

1. Предусмотреть средства обработки ошибок, которые тестируют все вводы информации от других элементов системы.

2. Провести тесты, моделирующие неудачные данные или другие потенциальные ошибки интерфейса ПС.

3. Записать результаты тестов, чтобы использовать их как доказательства невиновности в случае указания причины.

4. Принятие участия в планировании и проектировании системных тестов, чтобы гарантировать адекватное тестирование программной системы.

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