Интеграционное тестирование
Что такое интеграционное тестирование
Предположим, что есть несколько небольших систем, каждая из которых
работает хорошо.
Разработчики провели модульное тестирование
и убедились, что все необходимые юнит тесты (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 |
|---|---|---|---|
| 1 | Проверить работу кнопки «ОТЕЛИ» | Перейти на страницу «Поиск отелей со скидками» нажав на кнопку «ОТЕЛИ» на главной странице | Показана страница поиска отелей на сайте Aviasales |
| 2 | Проверить интерфейс между сайтом aviasales.ru и сайтом booking.com | Перейти на сайт Booking.com нажав на кнопку «Найти отели» | Осуществлён переход на сайт Booking.com Aviasales указан в качестве партнёра. |
| 3 | Проверить интеграцию Booking.com с картами Google | Нажать кнопку «На карте» и убедиться, что отели видны. | Карта открыта и на ней можно увидеть отели |
Test Case ID - это номер теста. Test Case Objective - цель. Test Case Description - описание. Expected Result - ожидаемый результат.
Теперь разберём действия пошагово.
Нужно зайти на сайт
Aviasales
и выбрать какой-то маршрут.
Допустим, я соскучился по
Коста-дель-Соль
и хочу билет в
Малагу
,
заполняю формы и нажимаю кнопку «Отели»
Переход на новую страницу осуществлён, но я по-прежнему на том же сайте.
Нужно нажать кнопку «Найти отели»
Переход осуществлён, на сайте букинга есть упоминание Авиаcейлз. Интеграция
Aviasales - Booking работает.
Проверим интеграцию Booking - Google Maps. Нажимаем кнопку «На карте»
Отели видны на карте. Интеграция Booking - Google Maps работает.
Offtopic: интересно почему у Aviasales интеграция с Booking, когда у них есть
свой агрегатор отелей -
Hotellook
Надеюсь Вам стало чуть понятней, что такое интеграционное тестирование. Конечно, приведённый пример
очень сильно упрощён. В реальном мире тестировать пришлось бы гораздо детальнее.
Главное, на что был бы
сделан акцент это проверка прохождения комиссий то есть денег. А это гораздо сложнее чем прокликать вручную пару страниц.
Продолжим разбираться с интеграционным тестированием, сфокусировавшись на его различных видах.
Подходы, стратегии, методологии интеграционного тестирования
Подход Большой Взрыв
В подходе Большого взрыва большинство разработанных модулей соединяются вместе, образуя либо
всю необходимую систему либо её большую часть.
Затем начинается тестирование.
Преимущества
Если всё работает, то таким спобом можно сэкономить много времени.
Недостатки
Однако если что-то пошло не так, будет сложно наити причину. Особенно тяжело разбираться в
результатах большого взрыва когда тесты и/или их результаты не записаны достаточно подробно.
Весь процесс интеграции может стать гораздо более сложным чем при тестировании снизу вверх или сверху внизу.
Всё это может помешать достичь цели интеграционного тестирования в разумные сроки.
Из всего вышеперечисленного можно сделать вывод о том, что подход Большого взрыва это потенциально быстрый но
рискованный подход.
Инкрементальный подход
При таком подходе тестирование выполняется путем соединения двух или более логически связанных модулей.
Затем добавляются и проверяются на правильность функционирования другие соответствующие модули.
Процесс продолжается до тех пор, пока все модули не будут соединены и успешно протестированы.
Инкрементный подход, в свою очередь, осуществляется двумя различными методами:
Заглушки и драйверы
Инкрементный подход осуществляется с помощью фиктивных программ, называемых заглушками и драйверами. Заглушки и драйверы не реализуют всю логику программирования программного модуля, а просто имитируют передачу данных с вызывающим модулем.
Заглушка: вызывается тестируемым модулем.
Драйвер: вызывает модуль для тестирования.
Как делать заглушки?
Конечно, всё зависит от того, для чего Вы делаете заглушку. Кругому люку нужна круглая крышка.
Если Вам нужна заглушка для REST API Вы можете прочитать подробные инструкции в следующих статьях:
«Заглушки для REST API на Flask»
«Заглушки для REST API с помощью SOAP UI»
В SOAP UI для обозначения заглушек используется термин Mock Service
Подход Снизу Вверх
В восходящей стратегии каждый модуль на более низких уровнях тестируется с помощью
модулей следующего более высокого уровня
, пока не будут протестированы все модули.
Требуется помощь драйверов для тестирования
Преимущества
Локализовать ошибки намного проще. Сразу видно какой из-за какого модуля
проваливается тест.
Не тратится время на ожидание разработки всех модулей, в отличие от подхода Большого взрыва.
Для продвижения тестирования достаточно наличия только определённых модулей на один уровень выше.
Недостатки
Критические модули (на верхнем уровне архитектуры программного обеспечения),
которые контролируют поток приложения, тестируются последними и могут быть
подвержены дефектам.
То есть всё может работать хорошо, но небольшая ошибка в реализации бизнес логики
на верхнем уровке вынудит провести всё тестирование заново.
Ранний прототип невозможен поэтому если MVP Вам нужен быстро и наличие каких-то ошибок
некритично, то с Bottom-Up тестированием можно немного подождать и провести
хотя бы несколько тестов сразу на более высоком уровне.
Метод Сверху Вниз
При подходе сверху вниз тестирование выполняется сверху вниз, следуя потоку
управления программной системы.
Пользуется заглушками для тестирования.
Преимущества
Локализация неисправностей проще.
Возможность получить ранний прототип.
Критические Модули тестируются в соответствии с их приоритетом.
Основные недостатки дизайна могут
быть найдены и исправлены в первую очередь.
Ошибки в реализации бизнес-логики будут видны в самом начале тестирования.
Недостатки
Нужно много заглушек. Если на более низких уровнях реализованы ещё не все
модули, их нужно имитировать. Это дополнительная работа для разработчика
или тестировщика.
Модули на более низком уровне тестируются неадекватно. Какие-то ошибки
особенно в маловероятных сценариях и пограничных случаях (Corner Cases)
могут быть до определённого момента не видны.
Смешанный подход - сэндвич
Модуль самого высокого уровня тестируется отдельно.
Модули нижнего уровня тестируются по схеме снизу вверх.
Преимущества
Даёт уверенность в модулях нижнего уровня плюс сразу виден общий уровень готовности софта к релизу.
Хорош для больших проектов в которых нужно ставить реалистичные сроки выполнения.
Недостатки
Нужно дополнительно время на координацию и вовлечение потенциально большего числа участинков тестировани.
Как организовать интеграционное тестирование
Краткое описание интеграционных тест планов
Входные и выходные критерии интеграционного тестирования
Руководства и советы
Если остались вопросы - смело задавайте их в комментариях либо воспользуйтесь поиском по сайту
| Рекомендую наш хостинг beget.ru |
| Пишите на info@urn.su если Вы: |
| 1. Хотите написать статью для нашего сайта или перевести статью на свой родной язык. |
| 2. Хотите разместить на сайте рекламу, подходящуюю по тематике. |
| 3. Реклама на моём сайте имеет максимальный уровень цензуры. Если Вы увидели рекламный блок недопустимый для просмотра детьми школьного возраста, вызывающий шок или вводящий в заблуждение - пожалуйста свяжитесь с нами по электронной почте |
| 4. Нашли на сайте ошибку, неточности, баг и т.д. ... ....... |
| 5. Статьи можно расшарить в соцсетях, нажав на иконку сети:
|