Министерство Образования Республики Молдова

Технический Университет Молдовы

Факультет Вычислительной Техники, Информатики и Микроэлектроники
Департамент Программной Инженерии и Автоматики

Реферат
по дисциплине: Тестирование программного обеспечения
Тема: «Интеграционное тестирование»

Выполнил: студент гр.TI-174 Чебан Андрей

Проверил: ст. преп. Скороходова Татьяна

Кишинёв – 2020
Содержание

Введение................................................................................................................3
1. Интеграционное тестирование........................................................................4
1.1 Виды интеграционного тестирования...........................................................4
1.2 Заглушки и драйвера.......................................................................................5
1.3 Разница между заглушками и драйверами..................................................5
1.4 Виды (категории) заглушек.............................................................................7
1.5 Виды (категории) драйверов..........................................................................7
1.6 Восходящее тестирование..............................................................................8
1.7 Нисходящее тестирование..............................................................................9
1.8 Смешанный подход.......................................................................................11
1.9 Большой взрыв (комплексный подход).......................................................12
2. Сравнительная характеристика методов тестирования..............................13
3. Автоматизации интеграционного тестирования..........................................14
4. Пример интеграционного тестирования.......................................................15
5. Инструменты для интеграционного тестирования.......................................16
Заключение..........................................................................................................18
Список использованных источников.................................................................19
Контрольные вопросы………………………………………………………….21

2
 Введение

Процесс тестирования является одним из важнейших этапов в жизненном

цикле разработки программного обеспечения, так как это позволяет
разработчикам устранить ошибки и баги. Именно через тестирование, они узнают
был ли код написан правильно, и то, что необходимо осуществить изменения, и
как они должны быть реализованы, таким образом, чтобы конечный продукт не
содержал ошибок и был удобен для пользователей.
Можно вынести следующую классификацию видов тестирования (рисунок
1). [8]
 блочное (Unit testing) — тестирование одного модуля в изоляции;
 интеграционное (Integration Testing) — тестирование группы
взаимодействующих модулей;
 системное (System Testing) — тестирование системы в целом.

Рисунок 1 – Уровни тестирования

Согласно отображенной хронологии на рисунке 1, процедура

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

Интеграционное тестирование – вид тестирования, при котором на

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

Так как модули соединяются между собой с помощью предусмотренных

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

1.1 Виды интеграционного тестирования

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

 Снизу-вверх. Сначала собираются и тестируются модули самих нижних

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

 Сверху-вниз. Данный подход предусматривает движение с

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

 Большой взрыв. Все модули всех уровней собираются воедино, а затем

тестируется. Данный метод экономит время, но требует тщательной
проработки тест кейсов (рисунок 4).

 Смешанный / сэндвич (англ. hybrid/sandwich approach) (рисунок 5).

1.2 Заглушки и драйвера

В процессе интеграционного тестирования используются такие техники

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

1.3 Разница между заглушками и драйверами

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

Рисунок 2 – Нисходящее тестирование

Действует правило: если вызываемый модуль ещё не готов, он заменяется

заглушкой (рисунок 3). [1]

Рисунок 3 – Вызов заглушки модулем при нисходящем тестировании

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

Рисунок 4 – Восходящее тестирование

Если модуль не до конца реализован или, но при этом вызывает другой

модуль, то вместо такого модуля используется драйвер (рисунок 5). [1]

Рисунок 5 – Вызов модуля, используя драйвер при восходящем тестировании

1.4 Виды (категории) заглушек

Когда дело доходит до разработки заглушек выбирается одна из следующих
категорий заглушек (рисунок 6):
a) заглушка А — отображает трассируемое сообщение;
b) заглушка В — отображает проходящий параметр;
c) заглушка С — возвращает величину из таблицы;
d) заглушка D — выполняет табличный поиск по ключу (входному
6
 параметру) и возвращает связанный с ним выходной параметр. [7]

Рисунок 6 – Категории заглушек

1.5 Виды (категории) драйверов

Рассмотрим различные типы драйверов:
a) драйвер А — вызывает подчиненный модуль;
b) драйвер В — посылает элемент данных из внутренней таблицы;
c) драйвер С — отображает параметр из подчиненного модуля;
d) драйвер D — является комбинацией драйверов В и С.

Очевидно, что драйвер А наиболее прост, а драйвер D наиболее сложен в

реализации. Различные типы драйверов представлены на рисунке 6. [7]

Рисунок 7 – Виды драйверов

7
 1.6 Восходящее тестирование

При восходящем подходе программа собирается и тестируется снизу-вверх.

Только модули самого нижнего уровня («терминальные» модули; модули, не
вызывающие других модулей) тестируются изолированно, автономно (рисунок 8).

Рисунок 8 – Терминальные модули при восходящем тестировании [3]

После того, как тестирование этих модулей завершено, вызов их должен

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

Рисунок 9 – Завершение процесса тестирования при восходящем тестировании.

[4]

При восходящем тестировании для каждого модуля необходим драйвер:

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

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

1.7 Нисходящее тестирование

Нисходящее тестирование не является полной противоположностью

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

Изолировано тестируется только головной модуль. После того, как

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

При этом подходе немедленно возникает два вопроса: что делать, когда
тестируемый модуль (1) вызывает модуль более низкого уровня (которого в
данный момент еще не существует - 2), и как подаются тестовые данные. Ответ на
первый вопрос состоит в том, что для имитации функций недостающих модулей
программируются модули-заглушки», которые моделируют функции
отсутствующих модулей (рисунок 10). [6]

Рисунок 10 – Интеграция модулей 1 и 2 при Нисходящем тестировании [3]

Заглушка редко сводится просто к оператору RETURN, поскольку

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

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

Преимуществом нисходящего способа является ранняя проверка основных

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

Недостатком нисходящего способа является то, что модуль редко

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

Так же этот подход может породить веру в возможность начать

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

1.8 Смешанный подход

Логики подходов «сверху-вниз» и «снизу-вверх» максимально объединены

в этот подход. А значит, его запросто можно считать смешанным, своего рода
гибридным методом в интеграционном тестировании. [5]

Рисунок 11 - Смешанный подход к интеграционному тестированию

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

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

1.9 Большой взрыв (комплексный подход)

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

другом, чтобы сформировать полную систему программного обеспечения, или
основную часть системы, а затем используются для тестирования интеграции. [9]

Рисунок 12 - Комплексный подход к интеграционному тестированию

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

12
 2 Сравнительная характеристика методов тестирования

В таблице1 приведена сравнительная характеристика подходов

интеграционного тестирования.

Таблица 1 – Сравнительная характеристика подходов интеграционного

тестирования
Название подхода Преимущества Недостатки
Сверху-вниз Top-Down 1. В первую очередь 1. Если в модули нижнего уровня
проверяются важные заложена важная логика, она не
модули, а лишь потом может быть протестирована в
модули нижнего первую очередь, пока не
порядка завершится работа над проверкой
2. По сравнению с верхних порядков.
другими подходами, 2. Использование «заглушек»
время на тестирование становится обязательным на всех
интеграции очень последующих проектах.
коротко.
Снизу-верх Down-Top 1.Легче обнаружить 1. Основная программа
ошибки фактически не существует, пока

2. Легко интегрировать последний модуль не

новый модуль так как интегрирован
тестирование самых 2. Общее время проверки всех
критических моментов модулей довольно долгое, так как
начинается с тестов
продукт не может быть
модулей нижнего
представлен в релиз пока не
порядка.
пройдет тестирование от самого
нижнего до самого верхнего
модулей.
Смешанный Sandwich 1. Подходит для 1. Высокая цена тестирования
больших проектов
Большой взрыв Big-Bang 1. Хороший подход для 1.Трудно обнаружить модуль,
небольших систем который вызывает ошибку.
2. Тестирование проводится
только один раз, что не оставляет
времени для тестирования
13
 критически важных модулей
изолированно.

3. Автоматизации интеграционного тестирования

Для автоматизации тестирования применяются системы непрерывной

интеграции (CIS), в частности Team City и Jenkins, который позволяет
производить мониторинг системы контроля версий, проводить ряд модульных и
других тестов, а также генерировать отчёты о проведенном тестировании.
При автоматизации тестирования используется Система непрерывной
интеграции.
Принцип ее действия заключается в следующем:
 Система непрерывной интеграции производит мониторинг системы
контроля версий.
 При изменении исходных кодов в репозитории производится
обновление локального хранилища.
 Выполняются необходимые проверки и модульные тесты.
 Исходные коды компилируются в готовые выполняемые модули.
 Выполняются тесты интеграционного уровня.
 Генерируется отчёт о тестировании.
Это позволяет тестировать систему сразу после внесения изменений, что
существенно сокращает время обнаружения и исправления ошибок.

14
 4 Пример интеграционного тестирования

Архитектура приложения рекламной компании для визуализации

статистики и выставления счетов соответствующим клиентам представлена на
рисунке 13.

Рисунок 13 - Архитектура приложения рекламной компании для визуализации

статистики и выставления счетов соответствующим клиентам

Рассмотрим назначение модулей приложения, представленные на рисунке 6.

UI — это модуль интерфейса пользователя, который виден конечному
пользователю, где даны все входы.
BL — это модуль Business Logic, в котором есть все методы расчётов и
бизнес-специфические методы.
VAL — это модуль проверки, который имеет все проверки правильности
ввода.
CNT — это модуль контента, который имеет все статическое содержимое,
специфичное для входов, введенных пользователем. Это содержимое
отображается в отчётах.
EN — это модуль Engine, который считывает все данные, поступающие из
модулей BL, VAL и CNT, извлекает запрос SQL и запускает его в базу данных.
Scheduler — это модуль, который планирует все отчёты на основе выбора
пользователя (ежемесячно, ежеквартально, раз в полгода и ежегодно).
БД — это база данных.

Теперь, рассматривая архитектуру всего веб-приложения как единого

модуля, в этом случае интеграционное тестирование будет сосредоточено на
потоке данных между модулями:

 В реальном мире передача данных осуществляется в формате XML.

Поэтому любые данные, которые пользователь вводит в
пользовательский интерфейс, преобразуются в формат XML.
15
  В нашем сценарии данные, введенные в модуль пользовательского
интерфейса, преобразуются в файл XML, который интерпретируется 3
модулями BL, VAL и CNT.
 Модуль EN считывает результирующий XML-файл, сгенерированный
этими 3 модулями, извлекает из него SQL и выполняет запросы в базу
данных.
 Модуль EN также получает набор результатов и преобразует его в файл
XML и возвращает его обратно в модуль пользовательского интерфейса,
который преобразует результаты в читаемую пользователем форму и
отображает их.

В середине у нас есть модуль планировщика - Scheduler, который получает

набор результатов от модуля EN, создает и планирует отчёты.

Интеграционное тестирование в данном случае заключается в следующем:

 Проверка правильности передачи информации / данных будет

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

Все эти вещи будут проверены как часть интеграционного тестирования.

16
 5 Инструменты для интеграционного тестирования

Citrus Integration Testing

Citrus — это тестовая среда, написанная на Java, которая помогает в
автоматизированном интеграционном тестировании приложений на основе
сообщений и форматов данных. Citrus проверяет данные запросов и ответов в
формате JSON, XML и текстовых сообщений.
Особенности:
 Citrus является открытым исходным кодом и лицензируется под Apache
License 2.0;
 установить последовательность сообщений;
 создать сообщения об ошибках;
 проверка заголовка сообщения;
 отправка и получение сообщений;
 дождитесь сообщения и вызовите другое сообщение;
 поддерживает интеграционное тестирование для транспортных
сообщений;
 проверка правильности ответа XML;
 проверить существование данных.

FitNesse
FitNesse полностью интегрирован, что делает его отличным инструментом
для сотрудничества с заинтересованными сторонами. FitNesse — это проект с
открытым исходным кодом, и база кода не принадлежит ни компании, ни
отдельным лицам. Много информации, которой поделилась сообщество FitNesse,
поскольку это инструмент с открытым исходным кодом.
Особенности:
 FitNesse является открытым исходным кодом;
 FitNesse не требует отдельной установки, только скачайте файл java jar и
он готов к использованию;
 он обеспечивает поддержку различных языков, таких как Java, C #,
Python;
 для любого программного проекта FitNesse позволяет проверить
требования с фактической реализацией программного обеспечения.

Validata
Validata Message Testing (MSG) предоставляет автоматизированную среду
тестирования и используется для тестирования SWIFT, SOA, ATM и
универсального интерфейса.

Validata MSG призвана упростить этап тестирования интеграции и

сократить усилия. Используя Validata MSG, сквозные сценарии могут быть
17
разработаны и протестированы на разных уровнях. Он также используется для
обеспечения содержания данных, отправки и получения поведения приложения.

Особенности:
 Validata MSG имитирует реальные бизнес-сценарии;
 он интегрирован с HP ALM;
 экономически эффективен благодаря возможности повторного
использования сценариев;
 с помощью многократного использования значительно улучшается
эффективность и производительность тестирования;
 возможность повторного использования помогает снизить общую
стоимость.

18
 Заключение

Интеграционное тестирование проводится после модульного тестирования,

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

19
Список использованных источников

1. Integration Testing – Big Bang, Top Down, Bottom Up & Hybrid

Integration [Электронный ресурс] – Режим доступа:
https://www.softwaretestingmaterial.com/integration-testing/
2. Нисходящее тестирование [Электронный ресурс] – Режим доступа:
https://studbooks.net/2252840/informatika/nishodyaschee_testirovanie
3. Top Down Integration Testing [Электронный ресурс] – Режим доступа:
https://www.tutorialspoint.com/software_testing_dictionary/top_down_integra
tion_testing.htm
4. Bottom Up Testing. [Электронный ресурс] – Режим доступа:
https://www.tutorialspoint.com/software_testing_dictionary/bottom_up_testin
g.htm
5. What Is Integration Testing (Tutorial With Integration Testing Example).
[Электронный ресурс] – Режим доступа:
https://www.softwaretestinghelp.com/what-is-integration-testing/
6. Integration Testing: What is, Types, Top Down & Bottom Up Example.
[Электронный ресурс] – Режим доступа:
https://www.guru99.com/integration-testing.html
7. Восходящее тестирование интеграции - [Электронный ресурс] –
режим
доступа: https://www.studall.org/all-110315.html
8. Виды тестирования и подходы к их применению [Электронный
ресурс] – Режим доступа: https://habr.com/ru/post/81226/
9. Big-Bang Testing Specifics. [Электронный ресурс] – Режим доступа:
https://qatestlab.com/resources/knowledge-center/big-bang-testing/

20
Контрольные вопросы

1. Определение интеграционного тестирования.

2. Какие существуют подходы интеграционного тестирования?
3. Комплексный подход к интеграционному тестированию и его
преимущества и недостатки.
4. Преимущества и недостатки смешанного подхода интеграционного
тестирования?
5. Как происходит автоматизация интеграционного тестирования?
6. После какого этапа тестирования выполняется интеграционное
тестирование?
7. Разница между драйверами и заглушками.
8. Виды заглушек.
9. Виды драйверов.
10. Преимущества и недостатки восходящего подхода интеграционного
тестирования.
11. Преимущества и недостатки нисходящего подхода интеграционного
тестирования.

21