Студопедия

КАТЕГОРИИ:

АстрономияБиологияГеографияДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРиторикаСоциологияСпортСтроительствоТехнологияФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника


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




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

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

включая заглушки (Stub) на месте отсутствующих модулей.

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

 

На рис. 5.2 приведена структура комплекса программ К, состоящего из оттестированных на этапе модульного тестирования модулей М1, М,2 М11, М,12 М21, М22. Задача, решаемая методом интеграционного тестирования, — тестирование межмодульных связей, реализующихся при исполнении программного обеспечения комплекса К. Интеграционное тестирование использует модель «белого ящика» на модульном уровне.

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

 

 

Рис. 5.2. Пример структуры комплекса программ

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

Известны два метода сборки модулей:

монолитный, характеризующийся одновременным объединением всех модулей в тестируемый комплекс;

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

— «сверху вниз» и соответствующее ему восходящее тестирование;

— «снизу вверх» и соответственно нисходящее тестирование.

Особенности монолитного тестирования заключаются в следующем: для замены не разработанных к моменту тестирования модулей, кроме самого верхнего (К на рис. 5.2), необходимо дополнительно разрабатывать драйверы (test driver) и/или заглушки(stub) [9], замещающие отсутствующие на момент сеанса тестирования модули нижних уровней.

 

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

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

Пошаговое тестирование связано с меньшей трудоемкостью идентификации ошибок за счет постепенного наращивания объема тестируемого кода и соответственно локализации

добавленной области тестируемого кода.

Монолитное тестирование предоставляет большие возможности распараллеливания работ, особенно на начальной фазе тестирования.

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

Например, порядок тестирования комплекса К (см. рис. 5.2) при нисходящем тестировании может быть таким, как показано в примере 5.3, где тестовый набор, разработанный для модуля Mi, обозначен как XYi = (X, Y)i.

1) К -> XYk

2) М1 -> XY1

3)M11->XY 11

4) М2 -> XY2

5) М22 -> XY 22

6) M21 -> XY21

7) M12-> XY 12

Пример 5.1. Возможный порядок тестов при нисходящем тестировании (html, txt).

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

• проблема разработки достаточно «интеллектуальных» заглушек, т. е. заглушек, способных к использованию при моделировании различных режимов работы комплекса,

необходимых для тестирования;

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

• параллельная разработка модулей верхних и нижних уровней приводит к не всегда эффективной реализации модулей из-за подстройки (специализации) еще не

тестированных модулей нижних уровней к уже оттестированным модулям верхних уровней.

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

Например, порядок тестирования комплекса К (см. рис. 5.2) при восходящем тестировании может быть следующим (см. пример 5.4).

1)М11->ХУ11

2) M12 -> XY12

3) Мi -> XYi

4) М21 -> XY21

5) M2(M21, Stub(M22)) -> XY2

6) К(М1 ,M2(M21, Stub(M22)) -> XYk

7) М22 -> XY22

8) М2 -* XY2

9) К -> XYk

Пример 5.2. Возможный порядок тестов при восходящем тестировании.

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

• запаздывание проверки концептуальных особенностей тестируемого комплекса;

• необходимость в разработке и использовании драйверов [33].


Поделиться:

Дата добавления: 2015-04-11; просмотров: 225; Мы поможем в написании вашей работы!; Нарушение авторских прав





lektsii.com - Лекции.Ком - 2014-2024 год. (0.006 сек.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав
Главная страница Случайная страница Контакты