[ Тематический план ] [ Тестирование программного обеспечения в процессе внедрения и эксплуатации ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, порядок тестирования комплекса К (см. рис. 2) при нисходящем тестировании может быть таким, как показано в примере 3, где тестовый набор, разработанный для модуля M_i, обозначен как XY_i = (X, Y)_i.

1) К -> XY_k

2) М₁ -> XY₁

3)M₁₁->XY ₁₁

4) М₂ -> XY₂

5) М₂₂ -> XY ₂₂

6) M₂₁ -> XY₂₁

7) M₁₂-> XY ₁₂

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

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

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

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

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

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

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

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

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

1)М₁₁->ХУ₁₁

2) M₁₂ -> XY₁₂

3) М_i -> XY_i

4) М₂₁ -> XY₂₁

5) M₂(M₂₁, Stub(M₂₂)) -> XY₂

6) К(М₁ ,M₂(M₂₁, Stub(M₂₂)) -> XY_k

7) М₂₂ -> XY₂₂

8) М₂ -* XY₂

9) К -> XY_k

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

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

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