Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
125174f.doc
Скачиваний:
178
Добавлен:
08.06.2015
Размер:
386.05 Кб
Скачать

1.2 Интеграционное тестирование

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

В интеграционном тестировании участвуют модули, успешно прошедшие модульное тестирование. На рисунке 3 представлена структура комплекса программ K, состоящего из прошедших модульное тестирование блоков M1, M2, M11, M12, M21, M22, М23.

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

Рисунок 3. Пример структуры комплекса программных модулей.

Интеграционное тестирование используется при сборке оттестированных модулей в единый комплекс. При этом объединение модулей может происходить двумя способами:

1) одновременное объединение всех модулей в единый комплекс (монолитная сборка, «big bang integration»);

2) поэтапное наращивание комплекса программ с пошаговым тестированием собираемого комплекса (инкрементная сборка).

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

1) Снизу вверх (bottom up integration)

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

2) Сверху вниз (top down integration)

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

Для автоматизации интеграционного тестирования применяются системы непрерывной интеграции (CIS – Continuous Integration System).

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

Системное тестирование – это тестирование ПО, выполняемое на полной, интегрированной системе с целью проверки соответствия разработанного ПО заданным требованиям. Системному тестированию подвергается полностью разработанный программный продукт, который уже подвергался модульному и интеграционному тестированию.

Основой для системных тестов являются общие требования к программе (спецификация). При этом программная система рассматривается как «черный ящик», т.е. фактически с точки зрения конечного пользователя. На этом уровне исследуются поведенческие аспекты разработанной программной системы.

Принято выделять следующие типы системного тестирования:

  1. Функциональное тестирование

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

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

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

  1. Нагрузочное тестирование

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

  1. Тестирование конфигурации

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

  1. Тестирование безопасности

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

  1. Тестирование надежности и восстанавливаемости после сбоев

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

  1. Тестирование удобства использования

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

По времени проведения можно выделить следующие типы системного тестирования:

1) Альфа-тестирование 

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

2) Бета-тестирование

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

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

В таблице 1 приведены некоторые характеристики модульного интеграционного и системного тестирования [4].

Таблица 1. Характеристики модульного, интеграционного и системного тестирования

Модульное

Интеграционное

Системное

Типы дефектов

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

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

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

Необходимость в системе тестирования

Да

Да

Нет

Цена разработки системы тестирования

Низкая

Низкая до умеренной

Умеренная до высокой или неприемлемой

Цена процесса тестирования: разработки, прогона и анализа тестов

Низкая

Низкая

Высокая

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]