Интеграционный тест: Интеграционное тестирование: что это? Виды, примеры.

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

Что такое интеграционное тестирование

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

Разработчики провели модульное тестирование
и убедились, что все необходимые юнит тесты (Unit Tests) пройдены.

Эти системы нужно объединить в одну. Логичный вопрос:

Будет ли новая большая система работать так же хорошо как и её части?

Чтобы ответить на него нужно провести тестирование системы (System Testing).

Оно обычно требует значительных ресурсов, поэтому появляются другие вопросы:

Есть ли смысл тестировать систему целиком в данный момент?

Взаимодействуют ли части между собой правильно?

Ответить на эти вопросы можно только после интеграционного тестирования (Integration Testing).

Лирическое отступление

Пропустить

Рассмотрим аналогию далёкую от IT. У Вас есть склад и два отряда новобранцев: пожарные и крестьяне. Нужно проверить насколько быстро пожарные
носят воду, а крестьене сеют пшеницу. Результатом будет, например тысяча литров в сутки и один гектар в день. Это аналог системного тестирования:
поле засеяно, вода перенесена.

Но что если подходя ко складу каждый пожарный будет брать сито вместо ведра а крестьянам придётся пользоваться оставшимися вёдрами?

Воду несут в решете, а сеют через ведро — есть ли смысл тратить сутки на такой тест? Даст ли он Вам какую-то полезную информацию? Думаю, ответ очевиден.

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

Это и будет интеграционным тестированием взаимодействия новобранцев со складом.

Определение

ИНТЕГРАЦИОННОЕ ТЕСТИРОВАНИЕ определяется как тип тестирования,
при котором программные модули интегрируются логически и тестируются как группа.

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

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

Интеграционное тестирование фокусируется на проверке обмена данными между этими модулями.
Следовательно, его также называют «I & T» (интеграция и тестирование), «тестирование строк» и
иногда «тестирование потоков».

Зачем делать интеграционное тестирование

Хотя каждый программный модуль проходит модульное тестирование (Unit Testing),
дефекты все еще
существуют по разным причинам, таким как:

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

Пример интеграционного тест кейса

Рассмотрим простой пример с картинками.

Допустим я тестировщик из

Aviasales

и хочу проверить как работает интеграция с сайтом

Booking.com

и заодно убедиться, что отели видно на карте.

Как будет выглядеть мой тест в упрощённом виде:

Test Case ID — это номер теста. Test Case Objective — цель. Test Case Description — описание. Expected Result — ожидаемый результат.

Теперь разберём действия пошагово.

Нужно зайти на сайт

Aviasales

и выбрать какой-то маршрут.

Допустим, я соскучился по

Коста-дель-Соль

и хочу билет в

Малагу

,
заполняю формы и нажимаю кнопку «Отели»

Изображение с сайта

Aviasales

Переход на новую страницу осуществлён, но я по-прежнему на том же сайте.

Нужно нажать кнопку «Найти отели»

Изображение с сайта

Aviasales

Переход осуществлён, на сайте букинга есть упоминание Авиаcейлз. Интеграция
Aviasales — Booking работает.

Проверим интеграцию Booking — Google Maps. Нажимаем кнопку «На карте»

Изображение с сайта

Booking.com

Отели видны на карте. Интеграция Booking — Google Maps работает.

Offtopic: интересно почему у Aviasales интеграция с Booking, когда у них есть
свой агрегатор отелей —
Hotellook

Изображение с сайта

Booking.com

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

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

Подходы, стратегии, методологии интеграционного тестирования

Подход Большой Взрыв

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

Затем начинается тестирование.

Преимущества

Если всё работает, то таким спобом можно сэкономить много времени.

Недостатки

Однако если что-то пошло не так, будет сложно наити причину. Особенно тяжело разбираться в
результатах большого взрыва когда тесты и/или их результаты не записаны достаточно подробно.

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

Всё это может помешать достичь цели интеграционного тестирования в разумные сроки.

Из всего вышеперечисленного можно сделать вывод о том, что подход Большого взрыва это потенциально быстрый но
рискованный подход.

Инкрементальный подход

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

Затем добавляются и проверяются на правильность функционирования другие соответствующие модули.

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

Инкрементный подход, в свою очередь, осуществляется двумя различными методами:

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

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

Заглушка: вызывается тестируемым модулем.

Драйвер: вызывает модуль для тестирования.

Как делать заглушки?

Конечно, всё зависит от того, для чего Вы делаете заглушку. Кругому люку нужна круглая крышка.

Изображение с сайта bestluki.ru

Если Вам нужна заглушка для REST API Вы можете прочитать подробные инструкции в следующих статьях:

«Заглушки для REST API на Flask»

«Заглушки для REST API с помощью SOAP UI»

В SOAP UI для обозначения заглушек используется термин Mock Service

Подход Снизу Вверх

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

Требуется помощь драйверов для тестирования

Преимущества

Локализовать ошибки намного проще. Сразу видно какой из-за какого модуля
проваливается тест.

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

Недостатки

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

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

Ранний прототип невозможен поэтому если MVP Вам нужен быстро и наличие каких-то ошибок
некритично, то с Bottom-Up тестированием можно немного подождать и провести
хотя бы несколько тестов сразу на более высоком уровне.

Метод Сверху Вниз

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

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

Преимущества

Локализация неисправностей проще.

Возможность получить ранний прототип.

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

Ошибки в реализации бизнес-логики будут видны в самом начале тестирования.

Недостатки

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

Модули на более низком уровне тестируются неадекватно. Какие-то ошибки
особенно в маловероятных сценариях и пограничных случаях (Corner Cases)
могут быть до определённого момента не видны.

Смешанный подход — сэндвич

Модуль самого высокого уровня тестируется отдельно.

Модули нижнего уровня тестируются по схеме снизу вверх.

Преимущества

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

Хорош для больших проектов в которых нужно ставить реалистичные сроки выполнения.

Недостатки

Нужно дополнительно время на координацию и вовлечение потенциально большего числа участинков тестировани.

Как организовать интеграционное тестирование

Краткое описание интеграционных тест планов

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

Руководства и советы

НОУ ИНТУИТ | Лекция | Интеграционное тестирование

Аннотация: Лекция является второй из трех рассматривающих уровни процесса верификации. Тема данной лекции — процесс интеграционного тестирования, его задачи и цели. Рассматриваются организационные аспекты интеграционного тестирования — структурная и временная классификации методов интеграционного тестирования, планирование интеграционного тестирования. Цель данной лекции: дать представление о процессе интеграционного тестирования, его технической и организационной составляющих

20.1. Задачи и цели интеграционного тестирования

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

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

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

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

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

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

20.2.1. Структурная классификация методов интеграционного тестирования

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

• восходящее тестирование;
• монолитное тестирование;
• нисходящее тестирование.

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

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

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

Однако, у восходящего метода тестирования есть существенный недостаток — необходимость в разработке драйвера и заглушек для модульного тестирования перед проведением интеграционного тестирования и необходимость в разработке драйвера и заглушек при интеграционном тестировании части модулей системы (Рис 20.1)

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

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

Монолитное тестирование имеет ряд серьезных недостатков.

• Очень трудно выявить источник ошибки (идентифицировать ошибочный фрагмент кода). В большинстве модулей следует предполагать наличие ошибки. Проблема сводится к определению того, какая из ошибок во всех вовлечённых модулях привела к полученному результату. При этом возможно наложение эффектов ошибок. Кроме того, ошибка в одном модуле может блокировать тестирование другого.
• Трудно организовать исправление ошибок. В результате тестирования тестировщиком фиксируется найденная проблема. Дефект в системе, вызвавший эту проблему, будет устранять разработчик. Поскольку, как правило, тестируемые модули написаны разными людьми, возникает проблема — кто из них является ответственным за поиск устранение дефекта? При такой «коллективной безответственности» скорость устранения дефектов может резко упасть.
• Процесс тестирования плохо автоматизируется. Преимущество (нет дополнительного программного обеспечения, сопровождающего процесс тестирования) оборачивается недостатком. Каждое внесённое изменение требует повторения всех тестов.

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

У разных специалистов в области тестирования разные мнения по поводу того, какой из методов более удобен при реальном тестировании программных систем. Йордан доказывает, что нисходящее тестирование наиболее приемлемо в реальных ситуациях [27], а Майерс полагает, что каждый из подходов имеет свои достоинства и недостатки, но в целом восходящий метод лучше [28].

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

Вне зависимости от применяемого метода интеграционного тестирования, необходимо учитывать степень покрытия интеграционными тестами функциональности системы. В работе [17] был предложен способ оценки степени покрытия, основанный на управляющих вызовах между функциями и потоках данных. При такой оценке код всех модулей на структурной диаграмме системы должен быть выполнен (должны быть покрыты все узлы), все вызовы должны быть выполнены хотя бы единожды (должны быть покрыты все связи между узлами на структурной диаграмме), все последовательности вызовов должны быть выполнены хотя бы один раз (все пути на структурной диаграмме должны быть покрыты) [10].

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

Интеграционное тестирование (в общем случае) — это вид тестирования, при котором проверяется взаимодействие модулей между собой, а также интеграция подсистем в одну общую систему.

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

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

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

Основная цель интеграционного тестирования — проверить интерфейсы между модулями.

Важно понимать, что в рамках интеграционного тестирования не проверяются end-to-end бизнес сценарии.

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

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

Различают два основных уровня интеграционного тестирования:

1. Компонентный;
2. Системный.

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

На системном уровне проверяется взаимодействие между разными системами после проведения системного тестирования.

Подходы к интеграционному тестированию

Снизу вверх (Bottom Up Integration)

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

В случае, представленном на изображении выше, модули B1C1, B1C2, B2C1 и B2C2 являются самыми «низкими» модулями и протестированы отдельно друг от друга с помощью модульного тестирования. Модули B1 и B2 еще не разработаны. В связи с тем, что разработка модулей B1 и B2 находится в процессе, то для тестирования необходима программа, которая обращалась бы к функциям модулей B1C1 и B2C2. Такие программы называются драйверами и представляют собой функции, которые обращаются к функциям более низких уровней. Драйверы необходимы для того, чтобы с помощью интерфейсов вызывать в рамках тестирования более низкие модули.

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

Подход «Снизу-Вверх» позволяет обнаружить дефекты на ранних этапах и позволяет просто локализовать сами дефекты и причины их возникновения.

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

Сверху вниз (Top Down Integration)

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

Большой взрыв («Big Bang» Integration)

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

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

В целом, для проведения хорошего интеграционного тестирования необходимо:

1. Знать архитектуру приложения;
2. понимать назначение модулей;
3. понимать, как данные передаются из одного модуля в другой;
4. определить условия, при которых происходит взаимодействие между модулями;
5. разрабатывать отдельные тесты на каждое из условий.

Контейнерно-ориентированное интеграционное тестирование / Блог компании Red Hat / Хабр

Интеграционное тестирование остается важной частью производственного цикла CI/CD, в том числе при разработке контейнерных приложений. Интеграционные тесты, как правило, представляют собой не очень продолжительные, но очень ресурсоемкие рабочие нагрузки. Посмотрим, как можно объединить технологии и инструменты интеграционного тестирования со средствами оркестрации контейнеров (в частности, с Red Hat OpenShift), чтобы ускорить тестирование, повысить его динамичность, и более эффективно использовать ресурсы.

Создадим интеграционные BDD-тесты (behavior-driven development – разработка через поведение) с помощью Cucumber, Protractor и Selenium и выполним их на платформе OpenShift, используя Zalenium.

BDD-тестирование

При разработке интеграционных тестов BDD позволяет создавать дефиниции интеграционных тестов бизнес-аналитикам (ВА), а не только программистам. Благодаря BDD процесс разработки можно организовать так, что функциональные требования и дефиниции интеграционной тестов готовятся одновременно, и при этом создаются они бизнес-аналитиками.

Это гораздо лучше традиционных подходов, когда вначале определяется бизнес-функционал приложения, а затем отдел контроля качества (QA) создает интеграционные тесты, как показано на диаграмме ниже:

А вот как все выглядит при использовании BDD:

Кроме того, в этой новой схеме каждая итерация, как правило, занимает меньше времени.

Бизнес-аналитики могут создавать дефиниции интеграционных тестов потому, что в BDD эти тесты описываются на простом и понятном языке Gherkin, главными ключевыми словами которого являются Given (При условии), When (Когда) и Then (Затем). Каждое утверждение на языке Gherkin в обязательном порядке должно начинается с одного из этих слов.

Например:

Given the user navigated to the login page (При условии, что пользователь зашел на страницу входа в систему)

When the user enters username and password (Когда пользователь вводит логин и пароль)

When username and password are correct (Когда логин и пароль верны)

Then the system logs them in (Затем система разрешает ему войти)

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

Стек технологий тестирования

Разберем процедуру тестирования на примере веб-приложения TodoMVC в реализации AngularJS. AngularJS – это популярный фреймворк для создания одностраничных приложений (Single-Page Applications, SPA).

Поскольку AngularJS – это JavaScript, мы будем использовать Cumcumber.js, привязку Cucumber к JavaScript.

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

И наконец, мы будем использовать Protractor, чтобы учесть нюансы эмуляции SPA-приложений, написанных на AngularJS. Protractor возьмет на себя проблемы с ожиданиями, чтобы представления внутри страницы загружались правильно.

Итак, наш стек тестирования выглядит следующим образом:

Процесс, представленный на этой диаграмме, описывается следующим образом:

• Когда запускается тест Cucumber, Cucumber читает определение теста из файла Gherkin.
• Затем он запускает вызов кода реализации тестового сценария.
• Код реализации тестового сценария использует Protractor, чтобы выполнить действия на веб-странице
• Когда это происходит, Protractor подключается к серверу Protractor и выдает команды Selenium’у через API-интерфейс.
• Selenium выполняет эти команды в экземпляре браузера.
• Браузер, при необходимости, подключается к веб-серверу (ам). В нашем примере используется SPA-приложение, поэтому такого подключения не происходит, поскольку приложение уже загрузилось при загрузке с сервера первой страницы.

Развертывание такого стека в неконтейнеризованной инфраструктуре – дело непростое. И не только из-за большого числа используемых процессов и фреймворков, но и потому, что запускать браузер на сервере без монитора всегда было затруднительно. К счастью, в контейнеризованном мире все это можно автоматизировать.

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

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

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

В идеале хотелось бы прогонять тесты параллельно.

В этом нам может помочь Selenium-Grid – решение, которое включает в себя брокер запросов Selenium Hub и один или несколько узлов, на которых эти запросы выполняются.

Каждый Selenium-узел, который обычно работает на отдельном сервере, можно сконфигурировать под определенную комбинацию клиентской ОС и браузера (в Selenium эти и другие характеристики узла называется capabilities – свойства). При этом Selenium Hub достаточно умен, чтобы отправлять запросы, для которых требуются определенные Selenium-свойства, тем узлам, у которых эти свойства есть.

Кластеры Selenium-Grid довольно сложны в установке и управлении, причем настолько, что на рынке даже появились компании, предлагающие соответствующие услуги. В частности, среди основных игроков можно назвать фирмы SauceLabs и BrowserStack.

Контейнерно-ориентированное интеграционное тестирование

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

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

Zalenium использует модифицированный Hub, который может создавать узлы по запросу и уничтожать их, когда они больше не нужны. В данный момент Zalenium поддерживает только браузеры Chrome и Firefox на платформе Linux. Но с появлением Windows-узлов для Kubernetes, возможно появится поддержка Explorer и Edge на Windows.

Если собрать все вместе, то технологический стек выглядит следующим образом:

Каждый овал на схеме – это отдельный под (pod) в Kubernetes. Поды тестового плейера и эмуляторов эфемерны и уничтожаются по завершении теста.

Выполнение интеграционных тестов в рамках конвейера CI/CD

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

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

Поскольку большинство подов эфемерны, одной из задач конвейера является сбор результатов тестирования. В Jenkins это можно делать с помощью примитивов archive и publishHTML.

А это пример отчета по результатам выполнения тестов (обратите внимание, что тесты прогонялись на двух браузерах):

Заключение

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

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

Если вы разрабатываете контейнерные приложения, попробуйте использовать этот подход в рамках конвейера CI/CD и посмотреть, поможет ли он упростить интеграционное тестирование.

Примеры кода из этой статьи можно найти на сайте GitHub по адресу redhat-cop/container-pipelinesh.

Автоматизация системного интеграционного тестирования / Хабр

Привет, Хабравчане!

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

Как же происходит тестирование интеграции? Самый короткий ответ — никак, хотя у нас больше сотни систем, которые взаимодействуют через интеграционную шину Oracle Service Bus(OSB). У этого продукта есть инструмент OSB Console, который позволяет послать тестовый запрос и отображает полученный ответ. После того как разработчик реализует на шине новый сервис, сервис вручную проверяется через OSB Console. Если проверка успешна, то сервис объявляется работающим и меняется, только если на него начинают жаловаться разработчики внешних систем.

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

Как мы себе это представляли

Картинка получилась простая и сразу всем понравилась.

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

Виртуализация сервисов (mocks, stubs)

Возник вопрос, а что использовать в нашем окружении в качестве back-end систем? Очевидно, что настоящая back-end система не годится по нескольким причинам:

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

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

Оказалось, что смотреть особо некуда, потому что таких продуктов на рынке всего 5:

Первые три продукта посмотреть не удалось, просто потому что их нельзя скачать и посмотреть. Нужно было заполнять длинные формы, оставлять телефоны, по которым с нами бы связались продажники, вобщем, все это могло тянуться месяцами. HP Service Virtualization в принципе тоже попадает в эту группу, но оказалось, что этот продукт у нас уже куплен. Однако, после недели мучений выяснилось, что использовать его не получится. Открытого API у этого продукта нет, а создать тысячи сервисов через визуальный редактор было нереально. Представитель HP сказал, что сервисы могут быть накликаны только вручную, а об автоматизации они не задумывались.

Большие надежды возлагались на Soap UI, который умеет запускать mock-сервисы, как web-приложение. Но, оказалось, что SOAP UI уж очень «UI». Во-первых, он не thread-safe, а во-вторых, использует очень много памяти и работает нестабильно.

В процессе исследований выяснилось, что в нашем банке уже есть аж четыре(!) самописных симулятора web-сервисов. Один из них оказался очень даже ничего, был взят за основу и по мере надобности дописан. Так в тестовом окружении у нас появился симулятор — web-приложение, которое по определенным HTTP-запросам возвращает определенные HTTP-ответы.

Каждый виртуальный сервис — это maven проект. В конфигурации проекта (service-descriptor.xml, response-selector.xml) написано как на основании HTTP-запроса определить, какой вызван сервис, какая нужна операция и по какому правилу вернуть HTTP-ответ.

После изменений исходников проект автоматически собирается на Jenkins и при помощи maven wagon деплоится в работающее приложения симулятора.

А теперь пишем тест

Следующим шагом нам нужно написать тест, который фактически будет симулятором front-end системы. То есть нам нужно написать web-service клиент.

Наш тест является maven проектом. Внутри проекта находятся пары файлов (запрос, ответ), которые собственно и являются исходниками. Билд проекта состоит в том, что наш самописный maven plugin вызывает web-сервис передает ему тестовый запрос, получает ответ и сравнивает его с тестовым ответом.

Тесты запускаются автоматически каждую ночь на Jenkins.

Создание тестовых данных

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

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

Что получилось

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

• Не все back-end системы работают через web-сервисы, нужны адаптеры для других протоколов.
• Есть требования тестировать не один сервис, а целый бизнес-процесс. В этом случае надо хранить согласованные наборы данных для нескольких сервисов.
• Написать симулятор, который поддерживает все, что умеет back-end — довольно большая работа. Мы не успели сделать поддержку REST-сервисов, асинхронные сообщения, а также разные методы аутентификации.

Самое главное, что реализованные тесты, обнаружили ошибки, которые бы произошли при миграции. А также обнаружили некоторые сервисы, которые в принципе не работали и не использовались. Так что наш опыт определенно положительный!

Планы на будущее

Нам понравилось, и мы будем продолжать. В ближайшем будущем планируется добавить симуляторы для JMS, поддержку бизнес-процессов и придумать, как проводить тесты производительности.

А вы тестируете интеграцию? Поделитесь, своим опытом!

Интеграционное тестирование — CoderLessons.com

Что такое интеграционное тестирование?

ИНТЕГРАЦИОННОЕ ТЕСТИРОВАНИЕ определяется как тип тестирования, при котором программные модули интегрируются логически и тестируются как группа. Типичный программный проект состоит из нескольких программных модулей, закодированных разными программистами. Целью данного уровня тестирования является выявление дефектов взаимодействия между этими программными модулями при их интеграции.

 Интеграционное тестирование фокусируется на проверке обмена данными между этими модулями. Следовательно, оно также называется  «I & T»  (интеграция и тестирование),  «тестирование строк» и иногда «тестирование потоков» .

Почему Интеграционное Тестирование?

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

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

Нажмите здесь, если видео не доступно

Пример интеграционного теста

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

Примеры тестовых примеров интеграции для следующего сценария: Приложение имеет 3 модуля, например «Страница входа», «Почтовый ящик» и «Удалить электронную почту», и каждый из них интегрирован логически.

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

Аналогично, почтовый ящик: проверьте его интеграцию с модулем удаления почты.

Подходы, стратегии, методологии интеграционного тестирования

Программная инженерия определяет различные стратегии для проведения интеграционного тестирования, а именно.

•  Подход Большого взрыва:
•  Инкрементальный подход: который далее делится на следующие
  •  Нисходящий подход
  •  Подход «снизу вверх
  •  Сэндвич-подход — комбинация сверху вниз и снизу вверх

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

Подход Большого взрыва:

Здесь все компоненты объединены вместе в один раз , а затем тестируют.

Преимущества:

• Удобно для небольших систем.

Недостатки:

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

Инкрементальный подход

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

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

• Вверх дном
• Сверху вниз

Что такое заглушка и драйвер?

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

Заглушка : вызывается тестируемым модулем.

Драйвер : вызывает модуль для тестирования.

Интеграция снизу вверх

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

Схематическое изображение :

Преимущества:

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

Недостатки:

• Критические модули (на верхнем уровне архитектуры программного обеспечения), которые контролируют поток приложения, тестируются последними и могут быть подвержены дефектам.
• Ранний прототип невозможен

Интеграция сверху вниз:

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

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

Схематическое изображение:

Преимущества:

• Локализация неисправностей проще.
• Возможность получить ранний прототип.
• Критические Модули тестируются на приоритет; основные недостатки дизайна могут быть найдены и исправлены в первую очередь.

Недостатки:

• Нужно много пней.
• Модули на более низком уровне тестируются неадекватно.

Интеграция гибрид / сэндвич

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

Как сделать интеграционное тестирование?

Процедура тестирования интеграции независимо от стратегий тестирования программного обеспечения (обсуждаемых выше):

1. Подготовьте план интеграционных тестов
2. Разработка тестовых сценариев, случаев и сценариев.
3. Выполнение тестовых случаев с последующим сообщением о дефектах.
4. Отслеживание и повторное тестирование дефектов.
5. Шаги 3 и 4 повторяются до успешного завершения интеграции.

Краткое описание планов интеграционных испытаний:

Включает в себя следующие атрибуты:

• Методы / Подходы к тестированию (как обсуждено выше).
• Области применения и вне областей Тестирование интеграции.
• Роли и обязанности.
• Предварительные условия для Интеграционного тестирования.
• Тестовая среда.
• Планы по снижению рисков и снижению рисков.

Критерии входа и выхода из интеграционного тестирования

Критерии входа и выхода на этапе тестирования интеграции в любой модели разработки программного обеспечения

Критерии входа:

• Модульные компоненты и модули
• Все ошибки с высоким приоритетом исправлены и закрыты
• Все модули должны быть заполнены и успешно интегрированы.
• Интеграционные тесты План, тестовый набор, сценарии, которые должны быть подписаны и задокументированы.
• Необходимая среда тестирования, которая будет настроена для тестирования интеграции

Критерии выхода:

• Успешное тестирование интегрированного приложения.
• Выполненные тестовые случаи задокументированы
• Все ошибки с высоким приоритетом исправлены и закрыты
• Технические документы должны быть представлены после выпуска Примечания.

Лучшие практики / рекомендации по интеграционному тестированию

• Сначала определите стратегию интеграционных тестов, которая может быть принята, а затем подготовьте тестовые наборы и соответственно протестируйте данные.
• Изучите Архитектурный дизайн Приложения и определите Критические Модули. Они должны быть проверены на приоритет.
• Получите проекты интерфейсов от команды Architectural и создайте контрольные примеры для проверки всех интерфейсов в деталях. Интерфейс к базе данных / внешнему оборудованию / программному обеспечению должен быть детально протестирован.
• После тестовых случаев именно тестовые данные играют решающую роль.
• Всегда имейте подготовленные данные перед выполнением. Не выбирайте тестовые данные во время выполнения тестовых случаев.

НОУ ИНТУИТ | Лекция | Интеграционное тестирование

Аннотация: Лекция является второй из трех рассматривающих уровни процесса верификации. Тема данной лекции — процесс интеграционного тестирования, его задачи и цели. Рассматриваются организационные аспекты интеграционного тестирования — структурная и временная классификации методов интеграционного тестирования, планирование интеграционного тестирования. Цель данной лекции: дать представление о процессе интеграционного тестирования, его технической и организационной составляющих

20.1. Задачи и цели интеграционного тестирования

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

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

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

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

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

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

20.2.1. Структурная классификация методов интеграционного тестирования

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

• восходящее тестирование;
• монолитное тестирование;
• нисходящее тестирование.

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

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

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

Однако, у восходящего метода тестирования есть существенный недостаток — необходимость в разработке драйвера и заглушек для модульного тестирования перед проведением интеграционного тестирования и необходимость в разработке драйвера и заглушек при интеграционном тестировании части модулей системы (Рис 20.1)

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

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

Монолитное тестирование имеет ряд серьезных недостатков.

• Очень трудно выявить источник ошибки (идентифицировать ошибочный фрагмент кода). В большинстве модулей следует предполагать наличие ошибки. Проблема сводится к определению того, какая из ошибок во всех вовлечённых модулях привела к полученному результату. При этом возможно наложение эффектов ошибок. Кроме того, ошибка в одном модуле может блокировать тестирование другого.
• Трудно организовать исправление ошибок. В результате тестирования тестировщиком фиксируется найденная проблема. Дефект в системе, вызвавший эту проблему, будет устранять разработчик. Поскольку, как правило, тестируемые модули написаны разными людьми, возникает проблема — кто из них является ответственным за поиск устранение дефекта? При такой «коллективной безответственности» скорость устранения дефектов может резко упасть.
• Процесс тестирования плохо автоматизируется. Преимущество (нет дополнительного программного обеспечения, сопровождающего процесс тестирования) оборачивается недостатком. Каждое внесённое изменение требует повторения всех тестов.

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

У разных специалистов в области тестирования разные мнения по поводу того, какой из методов более удобен при реальном тестировании программных систем. Йордан доказывает, что нисходящее тестирование наиболее приемлемо в реальных ситуациях [27], а Майерс полагает, что каждый из подходов имеет свои достоинства и недостатки, но в целом восходящий метод лучше [28].

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

Вне зависимости от применяемого метода интеграционного тестирования, необходимо учитывать степень покрытия интеграционными тестами функциональности системы. В работе [17] был предложен способ оценки степени покрытия, основанный на управляющих вызовах между функциями и потоках данных. При такой оценке код всех модулей на структурной диаграмме системы должен быть выполнен (должны быть покрыты все узлы), все вызовы должны быть выполнены хотя бы единожды (должны быть покрыты все связи между узлами на структурной диаграмме), все последовательности вызовов должны быть выполнены хотя бы один раз (все пути на структурной диаграмме должны быть покрыты) [10].

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

Что такое интеграционное тестирование

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

Разработчики провели модульное тестирование
и убедились, что все необходимые юнит-тесты (единичные тесты) пройдены.

Эти системы нужно объединить в одну. Логичный вопрос:

Будет ли новая большая система работать так же хорошо как и её части?

Чтобы ответить на него нужно провести тестирование системы (Системное тестирование).

Оно обычно требует значительных ресурсов, поэтому появляются другие вопросы:

Есть ли смысл тестировать систему целиком в данный момент?

Взаимодействуют ли части между собой правильно?

Ответить на эти вопросы можно только после интеграционного тестирования (Интеграционное тестирование).

Лирическое отступление

Пропустить

Рассмотрим аналогию далёкую от IT.У Вас есть склад и два отряда новобранцев: пожарные и крестьяне. Нужно проверить насколько быстро пожарные
носят воду, а крестьене сеют пшеницу. Результатом будет, например тысяча литров в сутки и один гектар в день. Это аналог системного тестирования:
поле засеяно, вода перенесена.

Но что если подходя ко складу каждый пожарный будет брать сито вместо ведра а крестьянам придётся пользоваться оставшимися вёдрами?

Воду несут в решете, а сеют через ведро — есть смысл тратить сутки на тест такой? Даст ли он Вам какую-то полезную информацию? Думаю, ответ очевиден.

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

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

Определение

ИНТЕГРАЦИОННОЕ ТЕСТИРОВАНИЕ определяет как тип тестирования,
при котором программные модули интегрируются логически и тестируются как группа.

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

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

Интеграционное тестирование фокус на проверке обмена данными между этим модулями.
Следовательно, его также называют «I&T» (интеграция и тестирование), «тестирование строк» ​​и
иногда «тестирование потоков».

Зачем делать интеграционное тестирование

Хотя каждый программный модуль проходит модульное тестирование (Unit Testing),
дефекты все еще
существуют по разным причинам, таким как:

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

Пример интеграционного тест кейса

Рассмотрим простой пример с картинками.

Допустим я тестировщик из

Aviasales

и хочу проверить как работает интеграция с сайтом

Booking.com

и заодно убедиться, что отели видно на карте.

Как будет мой тест в упрощённом виде:

ID тестового примера — это номер теста. Цель теста — цель. Описание тестового случая — описание. Ожидаемый результат — ожидаемый результат.

Теперь разберём действия пошагово.

Нужно зайти на сайт

Aviasales

и выбрать какой-то маршрут.

Допустим, я соскучился по

Коста-дель-Соль

и хочу билет в

Малагу

,
заполняю форму и нажимаю кнопку «Отели»

Изображение с сайта

Aviasales

Переход на новую страницу осуществлён, но я по-прежнему на том же сайте.

Нужно нажать кнопку «Найти отели»

Изображение с сайта

Aviasales

Переход осуществлён, на сайте букинга есть упоминание Авиаcейлз. Интеграция
Aviasales — Бронирование работает.

Проверим интеграцию Бронирование — Карты Google. Нажимаем кнопку «На карте»

Изображение с сайта

Бронирование.com

Отели видны на карте. Интеграция Booking — Google Maps работает.

Offtopic: интересно почему у Aviasales интеграция с Booking, когда у них есть
свой агрегатор отелей —
Hotellook

Изображение с сайта

Booking.com

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

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

Подходы, стратегии, методологии интеграционного тестирования

Подход Большой Взрыв

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

Затем начинается тестирование.

Преимущества

Если всё работает, то таким спобом можно сэкономить много времени.

Недостатки

Однако если что-то пошло не так, будет сложно наити причину. Особенно тяжело разбираться в
результаты большого взрыва когда тесты и / или их результаты не записаны достаточно подробно.

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

Всё это может помешать достижения цели интеграционного тестирования разумные сроки.

Из всего вышеперечисленного можно сделать вывод о том, что подход Большого взрыва это быстрый но
рискованный подход.

Инкрементальный подход

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

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

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

Инкрементный подход, в свою очередь, осуществляется двумя различными методами:

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

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

Заглушка: вызывается тестируемым модулем.

Драйвер: вызывает модуль для тестирования.

Как делать заглушки?

Конечно, всё зависит от того, для чего Вы делаете заглушку. Кругому люку нужна круглая крышка.

Изображение с сайта bestluki.ru

Если Вам нужна заглушка для REST API Вы можете прочитать подробные инструкции в следующих статьях:

«Заглушки для REST API на Flask»

«Заглушки для REST API с помощью SOAP UI»

В интерфейсе SOAP для обозначения заглушек используется термин Mock Service

Подход Снизу Вверх

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

Требуется помощь драйверов для тестирования

Преимущества

Локализовать ошибки намного проще. Сразу видно какой из-за какого модуля
провали тествается.

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

Недостатки

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

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

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

Метод Сверху Вниз

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

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

Преимущества

Локализация неисправностей проще.

Возможность получить ранний прототип.

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

Ошибки в реализации бизнес-логики будут видны в самом начале тестирования.

Недостатки

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

Модули на более низком уровне тестируются неадекватно. Какие-то ошибки
особенно в маловероятных сценариях и пограничных случаях (Угловые случаи)
могут быть до установленного момента не видны.

Смешанный подход — сэндвич

Модуль самого высокого уровня тестируется отдельно.

Модули нижнего уровня тестируются по схеме снизу вверх.

Преимущества

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

Хорошие для больших проектов в которых нужно ставить реалистичные сроки выполнения.

Недостатки

Нужно другое время на координацию и вовлечение тестиров большего числа участинковани.

Как организовать интеграционное тестирование

Краткое описание интеграционных тест планов

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

Руководства и советы

.

Интеграционное тестирование — CoderLessons.com

Что такое интеграционное тестирование?

ИНТЕГРАЦИОННОЕ ТЕСТИРОВАНИЕ определяется как тестируемый тип, при котором программные модули интегрируются логически и тестируются как группа. Типичный программный проект состоит из нескольких программных модулей, закодированных разными программистами. Целью данного уровня тестирования выявление дефектов выявления между этим программными модулями при их интеграции.

Интеграционное тестирование фокусируется на проверке данных между этими модулями. Следовательно, оно также называется «I&T» (интеграция и тестирование), «тестирование строк» ​​ и иногда «тестирование потоков» .

Почему Интеграционное Тестирование?

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

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

Нажмите здесь, если видео не доступно

Пример интеграционного теста

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

Примеры тестовых примеров интеграции для следующего сценария: Приложение имеет 3 модуля, например «Страница входа», «Почтовый ящик» и «Удалить электронную почту», и каждый из них интегрирован логически.

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

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

Подходы, стратегии, методологии интеграционного тестирования

Программная инженерия определяет различные стратегии для проведения интеграционного тестирования, а именно.

• Подход Большого взрыва:
• Инкрементальный подход: который далее делится на следующие
  • Нисходящий подход
  • Подход «снизу вверх

  »

  • Сэндвич-подход — комбинация сверху вниз и снизу вверх

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

Подход Большого взрыва:

Здесь все компоненты объединены вместе в один раз , а затем тестируют.

Преимущества:

• Удобно для небольших систем.

Недостатки:

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

Инкрементальный подход

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

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

• Вверх дном
• Сверху вниз

Что такое заглушка и драйвер?

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

Заглушка : вызывается тестируемым модулем.

Драйвер : вызывает модуль для тестирования.

Интеграция снизу вверх

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

Схематическое изображение :

Преимущества:

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

Недостатки:

• Критические модули (на верхнем уровне архитектуры), которые контролируют приложения, тестируются последними и могут быть подвержены дефектам.
• Ранний прототип невозможен

Интеграция сверху вниз:

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

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

Схематическое изображение:

.

Преимущества:

• Локализация неисправностей проще.
• Возможность получить ранний прототип.
• Критические Модули тестируются на приоритет; основные недостатки дизайна могут быть найдены и исправлены в первую очередь.

Недостатки:

• Нужно много пней.
• Модули на более низком уровне тестируются неадекватно.

Интеграция гибрид / сэндвич

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

Как сделать интеграционное тестирование?

Процедура тестирования независимо от стратегий тестирования (обсуждаемые выше):

1. Подготовьте план интеграционных тестов
2. Разработка тестовых сценариев, случаев и сценариев.
3. Выполнение тестовых случаев с последующим сообщением о дефектах.
4. Отслеживание и повторное тестирование дефектов.
5. Шаги 3 и 4 повторяются до полного завершения интеграции.

Краткое описание планов интеграционных испытаний:

Включает в себя следующие атрибуты:

• Методы / Подходы к тестированию (как обсуждено выше).
• Области применения и вне области Тестирование интеграции.
• Роли и обязанности.
• Предварительные условия для Интеграционного тестирования.
• Тестовая среда.
• Планы по снижению рисков и снижению рисков.

Критерии входа и выхода из интеграционного тестирования

Критерии входа и этапа тестирования интеграции в любой модели разработки программного обеспечения

Критерии входа:

• Модульные компоненты и модули
• Все ошибки с высоким приоритетом исправлены и закрыты
• Все модули должны быть заполнены и успешно интегрированы.
• Интеграционные тесты План, тестовый набор, сценарии, которые должны быть подписаны и задокументированы.
• Необходимая среда тестирования, которая будет настроена для тестирования интеграции

Критерии выхода:

• Успешное тестирование интегрированного приложения.
• Выполненные тестовые случаи задокументированы
• Все ошибки с высоким приоритетом исправлены и закрыты
• Технические документы должны быть представлены после выпуска Примечания.

Лучшие практики / рекомендации по интеграционному тестированию

• Сначала определите стратегию интеграционных тестов, которая может быть принята, а затем подготовьте тестовые наборы и протестируйте данные.
• Изучите Архитектурный дизайн Приложения и определите Критические Модули. Они должны быть проверены на приоритет.
• Получите проекты интерфейса от команды Архитектурные и создайте контрольные примеры проверки всех интерфейсов в деталях.Интерфейс к базе данных / внешнему оборудованию / программному обеспечению должен быть детально протестирован.
• После тестовых случаев именно тестовые данные играют решающую роль.
• Всегда имейте подготовленные данные перед выполнением. Не выбирайте тестовые данные во время выполнения тестовых случаев.

.

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

Интеграционное тестирование (в общем случае) — это тестирование вид, при котором проверяется взаимодействие модулей между собой, а также интеграция подсистем в одну общую систему.

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

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

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

Основная цель интеграционного тестирования — проверить интерфейс между модулями.

Важно понимать, что в интеграционного тестирования не проверяются сквозные бизнес-сценарии.

Тестирование выполняется методом «черного ящика».

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

Различают два основных уровня интеграционного тестирования:

1. Компонентный;
2. Системный.

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

На системном уровне проверяется взаимодействие между разными системами после проведения системного тестирования.

Подходы к интеграционному тестированию

Внизу вверх (интеграция снизу вверх)

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

В представленном на изображении выше, модули B1C1, B1C2, B2C1 и B2C2 являются самыми «низкими» модулями и протестированы отдельно друг от друга с помощью модульного тестирования. Модули B1 и B2 еще не разработаны. В связи с тем, что разработка модулей B1 и B2 находится в процессе, то для тестирования необходима программа, которая обращалась бы к функциям модулей B1C1 и B2C2.Такие программы называются драйверами и предоставляются функции, которые обращаются к функциям более низких уровней. Драйверы необходимы для того, чтобы с помощью интерфейса вызвать тестирование более низких модулей.

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

Подход «Снизу-Вверх» позволяет построить дефекты на ранних этапах и позволяет просто локализовать сами дефекты и причины их возникновения.

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

Сверху вниз (интеграция сверху вниз)

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

Большой взрыв (Интеграция «Big Bang»)

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

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

В целом, для проведения хорошего интеграционного тестирования необходимо:

1. Знать энергетуру приложения;
2. понимать назначение модулей;
3. понимать, как данные передаются из одного модуля в другой;
4. определить условия, при которых происходит взаимодействие между модулями;
5. разрабатывать отдельные тесты на каждый из условий.

.

Юнит, Интеграционные и Сквозные тесты

.