Тестирование итераций

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

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

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

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

3. неправильное влияние одного модуля на другой;

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

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

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

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

1. нисходящее тестирование;

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

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

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

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

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

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

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

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

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

5. Выполняется возврат на шаг два до тех пор, пока не будет протестирована вся структура.

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

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

Существует три пути борьбы с этим недостатком:

1. откладывать некоторые тесты до замещения заглушек реальными модулями;

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

3. подключать модуль движением снизу вверх.

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

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

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

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

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

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

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

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

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

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

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

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

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

3. имеет высокую цикломатическую сложность;

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

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