18c0693f

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


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

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


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

На Рис. 5.1 приведена структура комплекса программ K, состоящего из оттестированных на этапе модульного тестирования модулей M1, M2, M11, M12, M21, M22. Задача, решаемая методом интеграционного тестирования, - тестирование межмодульных связей, реализующихся при исполнении программного обеспечения комплекса K. Интеграционное тестирование использует модель "белого ящика" на модульном уровне. Поскольку тестировщику текст программы известен с детальностью до вызова всех модулей, входящих в тестируемый комплекс, применение структурных критериев на данном этапе возможно и оправдано.

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

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

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

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

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

1) K->XYK 2) M1->XY1 3) M11->XY11 4) M2->XY2 5) M22->XY22 6) M21->XY21 7) M12->XY12 Пример 5.3. Возможный порядок тестов при нисходящем тестированииНедостатки нисходящего тестирования:

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

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

1) M11->XY11 2) M12->XY12 3) M1->XY1 4) M21->XY21 5) M2(M21, Stub(M22))->XY2 6) K(M1, M2(M21, Stub(M22)) ->XYK 7) M22->XY22 8) M2->XY2 9) K->XYK Пример 5.4. Возможный порядок тестов при восходящем тестированииНедостатки восходящего тестирования: