big bang тестирование что такое

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Определение

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

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

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

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

Ещё пара комментариев о том, что можно считать интеграционным тестированием:

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

Это по-прежнему юнит-тест, интеграционного тестирования здесь нет.

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

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

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

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

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

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

Допустим я тестировщик из Aviasales и хочу проверить как работает интеграция с сайтом Booking.com и заодно убедиться, что отели видно на карте.

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

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

Нужно зайти на сайт Aviasales и выбрать какой-то маршрут.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

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

Входные критерии :

Выходные критерии:

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

Источник

Построение Android приложений шаг за шагом, часть третья

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

Введение

В первой части статьи мы в два этапа создали простое приложение для работы с github. Архитектура приложения была разбита на две части: простую и сложную. Во второй части мы внедрили Dagger 2 и покрыли код unit тестами с помощью Robolectric, Mockito, MockWebServer и JaCoCo.

Все исходники вы можете найти на Github.

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

Интеграционное тестирование (Integration testing) — одна из фаз тестирования программного обеспечения, при которой отдельные программные модули объединяются и тестируются в группе.
Выделяется 3 подхода к интеграционному тестированию:

Снизу вверх (Bottom Up Integration)
Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.

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

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

Итеративный подход

Мы будем использовать итеративный подход, т.е будем подключать модули один за одним, снизу вверх. Сначала проверяем связку api + model, потом api + model + mapper + presenter, затем общую связку api + model mapper + presenter + view

Негативный и позитивный сценарий

Для интеграционных тестов мы должны рассмотреть 2 сценария ответа от сервера: нормальный ответ и ошибка. В зависимости от этого меняется поведение компонентов. Перед каждым тестом мы можем настраивать ответ от сервера (MockWebServer) и проверять результаты.

Схема интеграционного теста (api + model):

Пример интеграционного теста (api + model), мы проверяем взаимодействие модуля Retrfofit и ModelImpl:

Схема интеграционного теста (api + model + mapper + presenter):

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

Шаг 6. Функциональное тестирование

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

В рамках нашего Android приложения мы будем проверять работу приложения с точки зрения пользователя. Для начала составим пользовательскую карту приложения:

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

Шаг 7. TDD

Разработка через тестирование (Test-driven development) — техника разработки программного обеспечения, которая определяет разработку через написание тестов.

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

Если аббревиатура TDD для вас не знакома, рекомендуем почитать статью от наших коллег из iOS отдела или статьи из хаба TDD.

Существуют 3 закона TDD:

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

Презентеры

Начнем со списка репозиториев. Первым делом дополним интерфейсы:

Первый этап.

Сначала пишем тест, который проверит, что в случае нормальной загрузки был вызван метод showLoading у фрагмента:

Как только получили неработающий тест, пишем код, который пройдет его:

Рефакторить пока нечего.

На этом первая итерация разработки по TDD закончилась. Мы получили новую функциональность и тест для нее.

Второй этап.

Напишем тест, который проверит, что после нормальной загрузки был вызван метод hideLoading у фрагмента:

Пишем код, который пройдет тест:

Рефакторинг не требуется.

Третий и четвертый этапы.

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

Рефакторинг не требуется. Работа с Repo List Presenter завершена, теперь перейдем к Repo Info Presenter.

Repo Info Presenter

Аналогично предыдущему шагу, пишем тесты и код для корректной загрузки данных.

Рефакторинг.
Как видно, используется одинаковый код для двух презентеров (показать и скрыть индикатор загрузки, показать ошибку). Необходимо вынести его в общий базовый класс BasePresenter. Выносим методы showLoadingState() hideLoadingState() и showError(Throwable e) в BasePresenter

Рефакторим RepoInfoPresenter и проверим, что проходят все тесты. Не забываем сделать рефакторинг RepoListPresenter для работы с базовым классом.

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

На этом разработка презентеров закончена. Переходим к фрагментам.

Фрагменты

Progress bar, как общий элемент, будет лежать в activity, фрагменты будут вызывать у activity методы showProgressBar() и hideProgressBar(), которые покажут или спрячут progress bar. Для работы с activity используем интерфейс ActivityCallback. По опыту презентеров, можем сразу догадаться, что нам будет необходим общий базовый класс — BaseFragment. В нем будет содержаться логика взаимодействия с activity.

Сначала пишем тесты, а потом код, для взаимодействия базового фрагмента с activity:

Рефакторинг не требуется, переходим к activity.

Acitivity

Последним шагом реализуем интерфейс Activity. Мы будем изменять видимость (setVisibility) progressBar в зависимости от команды. В тестах необходимо проверить что progressBar найден и работу методов showProgressBar и hideProgressBar.

Сначала пишем тесты:

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

На этом мы закончим разработку progress bar с использованием техники TDD.

Шаг 8. Что дальше?

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

Android Clean Architecture
Android Clean Architecture — известная статья от Fernando Cejas, на основе Clean Architecture от Дядюшки Боба. Рассматривается взаимодействие между 3 слоями Presentation Layer, Domain Layer и Data Layer. Есть перевод на habrahabr.

VIPER
VIPER (View, Interactor, Presenter, Entity и Routing) становится все более популярен, познакомится с ним можно в статье Android VIPER на реактивной тяге от VikkoS. Основные принципы VIPER освещены в статьях и докладах наших коллег из отдела iOS.

Mosby
Mosby — популярная библиотека для создания MVP приложений. Содержит в себе все основные интерфейсы и базовые классы. Сайт: http://hannesdorfmann.com/mosby/ Github: https://github.com/sockeqwe/mosby

Android Application Architecture
Хорошая статья про архитектуру от Ribot team — Android Application Architecture. Рассматривается миграция c AsyncTask на RxJava. Совсем недавно вышел перевод на habrahabr.

Android Development Culture Document
Android Development Culture Document #qualitymatters от Artem_zin. Отличная статья и демонстрационный проект от Artem Zinnatullin. В статье рассматриваются 8 принципов разработки android приложений, подкрепляется все это примером на Github.

Заключение

В этом цикле статей мы прошли все этапы разработки приложения. Начали мы c простой архитектуры на основе MVP, усложняя ее по ходу добавления новых фич. Использовали современные библиотеки: RxJava и RxAndroid для реактивного программирования и избавления от callback-ов, Retrofit для удобной работы с сетью, Butterknife для быстрого и легкого поиска view. Dagger 2 управлял всеми зависимостями и оказал нам неоценимую поддержку при написании тестов. Сами тесты мы писали с помощью jUnit, Robolectric, Mockito и MockWebServer. А Espresso избавил наших тестировщиков от мук регрессионного тестирования.

Мы полностью покрыли наш проект тестами. Unit тесты изолированно проверяют каждый компонент, интеграционные тесты проверяют их общее взаимодействие, а функциональные тесты смотрят на все это со стороны пользователя. При дальнейшем изменении программы мы можем не бояться (ну или почти не бояться), что поломаем какие то компоненты, и что то отвалится, а баги пролезут в релиз. Благодаря TDD, большая часть нашего кода будет покрыта тестами (нет теста, нет и кода). Не будет проблемы частичного покрытия или “код написали, а на тесты времени не осталось”.

Источник

Интеграционное тестирование: основные понятия, характерные особенности и примеры

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

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

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

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

Проверка работоспособности ПО проводиться на разных уровнях. Базовыми среди них являются:

Уровни тестирования ПО

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

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

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

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

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

Типы интеграционного тестирования:

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

Может возникнуть вопрос: в чем разница между тестированием ПО в целом и интеграционным тестированием модулей? Все просто! Главное отличие в том, что при интеграционном тестировании работы проводятся исключительно с отдельными модулями, а при проверке всего ПО тестируются все системные параметры.

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

Метод большого взрыва

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

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

Недостатки:

Снизу вверх (англ. Bottom-Up Approach)

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

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

Подход снизу вверх

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

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

Недостатки:

Сверху вниз (англ. Top-Down Approach)

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

Большинство модулей нижнего уровня тестируются по отдельности, а затем выполняются проверки в совокупности реализованных модулей. По аналогии с подходом «снизу вверх», данный метод также зависим от вызова специальной связующей функции под названием «Функция-заглушка» (англ. Stubs).

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

Подход сверху вниз

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

Недостатки:

Смешанный / сэндвич (англ. Hybrid/Sandwich Approach)

Данный подход еще принято именовать как тестирование смешанной интеграции.

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

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

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

Недостаток:

Большие преимущества интеграционного тестирования

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

Интеграционные проверки могут использоваться на любой стадии разработки и тестирования ПО. По сравнению с другими видами тестов, данные проверки могут охватывать любые объемы программного кода за один спринт, ведь есть так называемые подходы «снизу вверх» и «сверху вниз».

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

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

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

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

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

Шаблонные примеры интеграционного тестирования

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

Итак, наша программа будет содержать такие структурные модули:

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

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

Вторым примером интеграционного тестирования может послужить такая ситуация:

Пользователь каждый день проверяет свою электронную почту. Все почтовые клиенты должны предоставлять собой один сформированный набор функциональных возможностей (ЛК-входящие/исходящие письма-папка спам-выход из аккаунта).

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

Итоги

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

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

Источник