Меню

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

вода в решете www.andreyolegovich.ru

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

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

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

Определение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Допустим, я соскучился по Коста-дель-Соль и хочу билет в Малагу , заполняю формы и нажимаю кнопку «Отели»

Наглядный пример интеграционного теста www.andreyolegovich.ru

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

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

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

Наглядный пример интеграционного теста www.andreyolegovich.ru

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

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

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

Наглядный пример интеграционного теста www.andreyolegovich.ru

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

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

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

Наглядный пример интеграционного теста www.andreyolegovich.ru

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Качественная крышка для люка www.andreyolegovich.ru

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

Что пишут в блогах

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

• Девять смертных грехов Scrum-мастера.

Подписаться

Онлайн-тренинги

Что пишут в блогах (EN)

Разделы портала

  • На главную
  • Новости
  • Блоги о тестировании
  • События
  • Библиотека
    • Тестирование
      • Общие вопросы
      • Функциональное тестирование
      • Тестирование производительности
      • Защищённость и надёжность
      • Другие виды тестирования
      • Тестовая лаборатория
      • Управление дефектами
      • Usability-тестирование
      • Начинающему тестировщику
      • Автоматизация тестирования
      • Тест-анализ и тест-дизайн
      • Тест-менеджмент
      • Тестирование мобильных приложений
      • Инструменты тестирования
    • Вокруг тестирования
    • Колонка редактора
    • Интервью
  • Литература
  • Рассылка по тестированию
  • О проекте

Про инструменты

Оригинальная публикация: http://automationpanda.com/2017/10/14/bdd-101-unit-integration-and-end-to-end-tests/

Перевод: Анна Радионова

Существует много видов ПО тестов. Практики BDD можно применять в любых аспектах тестирования, но BDD фреймворки используются далеко не во всех типах тестов. Поведенческие сценарии, по сути, являются функциональными тестами — они проверяют, что тестируемый продукт работает корректно. Для тестирования производительности могут использоваться инструменты, в то время как BDD фреймворки не предназначены для этих целей. Задача данной статьи, в основном, состоит в описании роли BDD автоматизации в Пирамиде Тестирования. Прочитайте статью BDD 101: Manual Testing для того, чтобы понимать как BDD применяется при ручном тестировании. (Всю информацию по BDD можно найти на странице Automation Panda BDD page)

Пирамида Тестирования

Пирамида Тестирования представляет собой подход к разработке тестов, который разделяет тесты на три слоя: юнит, интеграционные и end-to-end.

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

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

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

Ниже представлено графическое отображение Пирамиды Тестирования:

Пирамида Тестирования

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

Behavior-Driven юнит-тестирование

Тестовые BDD фреймворки не предназначены для написания юнит-тестов. Юнит-тесты являются низкоуровневыми, программными тестами для проверки отдельных функций или методов. Можно написать Gherkin тест в целях юнит-тестирования, но по факту это перебор. Гораздо лучше использовать уже существующие юнит-тест фреймворки как, например, JUnit, NUnit и pytest.

Тем не менее, BDD практики могут применяться для юнит-тестов. Каждый юнит-тест должен быть направлен на основную составляющую: один вызов, единичная вариация, определенная комбинация ввода; на поведение. В дальнейшем при разработке спецификация поведения фичи четко отделяет юнит тесты от тестов более высокого уровня. Разработчик функционала также ответственен за написание юнит-тестов, в то время как за интеграционные и end-to-end тесты несет ответственность другой инженер. Спецификация поведения является, своего рода, джентльменским соглашением о том, что юнит-тесты будут являться отдельной сущностью.

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

Тестовые BDD фреймворки наиболее ярко проявляют себя на интеграционных и end-to-end уровнях тестирования.

Поведенческие спецификации однозначно и лаконично описывают, на что именно ориентирован тест-кейс. Шаги могут быть написаны на интеграционном или end-to-end уровне. Тесты сервиса могут быть написаны с помощью поведенческих спецификаций, как, например в Karate. End-to-end тесты фактически представляют собой многошаговые интеграционные тесты. Обратите внимание на следующий пример, который, на первый взгляд, кажется базовой моделью взаимодействия с пользователем, но, по сути, является объемным end-to-end тестом:

Given a user is logged into the social media site
When the user writes a new post
Then the user’s home feed displays the new post
And the all friends’ home feeds display the new post

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

Длительные End-to-End тесты

Термины часто понимаются разными людьми по-разному. Когда люди говорят “end-to-end тесты,” они подразумевают продолжительные последовательные тесты: тесты, которые покрывают различное поведение продукта одно за другим. Это утверждение заставляет содрогнуться приверженцев BDD, т.к это противоречит основному правилу BDD: один сценарий, одно поведение. Конечно, с помощью BDD фреймворков можно составлять длительные end-to-end тесты, но нужно хорошо подумать, стоит ли это делать и как именно.

Существует пять основных принципов написания длительных end-to-end сценариев в BDD:

  1. Не стоит беспокоиться на этот счет. Если BDD процесс поставлен правильно, то каждое отдельное поведение уже полностью покрыто тестовыми сценариями. Каждый сценарий должен покрывать все классы эквивалентности вводимых и выводимых данных. Таким образом, длительные end-to-end сценарии будут являться, в основном, дублированием тестового покрытия. Вместо того, чтобы тратить время на разработку, лучше отказаться от автоматизации длительных end-to-end сценариев, как от тех, которые не представляют большой ценности и уделить больше времени ручному и исследовательскому тестированию.
  2. Объединить существующие сценарии в новые. Каждая When-Then пара представляет собой индивидуальное поведение. Шаги из существующих сценариев могут быть переопределены в другие сценарии и для этого потребуется лишь незначительный рефакторинг. Это нарушает хорошие практики Gherkin и может привести к появлению длительных сценариев, но это наиболее практичный способ переиспользовать шаги для обширных end-to-end сценариев. Большинство BDD фреймворков не поддерживают пошаговый порядок, а если поддерживают, то шаги должны быть переписаны, чтобы код работал. (Этот подход является наиболее практичным, но менее традиционным.)
  3. Встраивайте проверки в Given и When шаги. Данная стратегия позволяет избежать дуплицирования When-Then пар и убедиться, что проверки производятся. Корректность каждого шага проверяется на протяжении всего процесса с помощью Gherkin текста. Однако, может потребоваться ряд новых шагов.
  4. Воспринимайте последовательность поведений как уникальное отдельное поведение. Это наилучший способ обдумывания длительных end-to-end сценариев, т.к. он усиливает поведенческое мышление. Продолжительный сценарий имеет ценность только в том случае, если он расценивается как уникальное поведение. Сценарий должен быть написан с целью подчеркнуть эту уникальность. В противном случае это не тот сценарий, который стоит использовать. Такие сценарии часто являются декларативными и высокоуровневыми.
  5. Не используйте BDD фреймворки и пишите тесты исключительно с помощью средств автоматизации. Gherkin предназначен для совместной работы в отношении поведения, в то время как продолжительные end-to-end тесты решают проблемы интенсивности работы QA. Бизнес может предоставить поведенческие спецификации, но никогда не станет писать end-to-end тесты. Переписывание поведенческих спецификаций в длинные end-to-end сценарии может блокировать разработку. Гораздо лучшим решением является сосуществование: приемочные тесты могут быть написаны при помощи Gherkin, а продолжительные end-to-end тесты — средствами программирования. Для автоматизации обоих наборов тестов можно использовать одну и ту же базу кода, у них могут быть единые модули поддержки и даже методы определения шагов.
Читайте также:  Тест для госслужащих государственный язык

Выберите подход, наиболее подходящий вашей команде.

Источник

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

Блочное тестирование

Блочное (модульное, unit testing) тестирование наиболее понятное для программиста. Фактически это тестирование методов какого-то класса программы в изоляции от остальной программы.

Не всякий класс легко покрыть unit тестами. При проектировании нужно учитывать возможность тестируемости и зависимости класса делать явными. Чтобы гарантировать тестируемость можно применять TDD методологию, которая предписывает сначала писать тест, а потом код реализации тестируемого метода. Тогда архитектура получается тестируемой. Распутывание зависимостей можно осуществить с помощью Dependency Injection. Тогда каждой зависимости явно сопоставляется интерфейс и явно определяется как инжектируется зависимость — в конструктор, в свойство или в метод.

Для осуществления unit тестирования существуют специальные фреймворки. Например, NUnit или тестовый фреймфорк из Visual Studio 2008. Для возможности тестирования классов в изоляции существуют специальные Mock фреймворки. Например, Rhino Mocks. Они позволяют по интерфейсам автоматически создавать заглушки для классов-зависимостей, задавая у них требуемое поведение.

По unit тестированию написано много статей. Мне очень нравится MSDN статья Write Maintainable Unit Tests That Will Save You Time And Tears, в которой хорошо и понятно рассказывается как создавать тесты, поддерживать которые со временем не становится обременительно.

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

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

Если к нему подходить как к unit-тестированию, у которого в тестах зависимости не заменяются mock-объектами, то получаем проблемы. Для хорошего покрытия нужно написать много тестов, так как количество возможных сочетаний взаимодействующих компонент — это полиномиальная зависимость. Кроме того, unit-тесты тестируют как именно осуществляется взаимодействие (см. тестирование методом белого ящика). Из-за этого после рефакторинга, когда какое-то взаимодействие оказалось выделенным в новый класс, тесты рушатся. Нужно применять менее инвазивный метод.

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

Хорошая статья по интеграционному тестированию мне попалась лишь однажды — Scenario Driven Tests. Прочтя ее и книгу Ayende по DSL DSLs in Boo, Domain-Specific Languages in .NET у меня появилась идея как все-таки устроить интеграционное тестирование.

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

$SectionNames = Введение, Текст статьи, Заключение, Литература

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

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

Системное тестирование

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

Первый подход — это использовать вариацию MVC паттерна — Passive View (вот еще хорошая статья по вариациям MVC паттерна) и формализовать взаимодействие пользователя с GUI в коде. Тогда системное тестирование сводится к тестированию Presenter классов, а также логики переходов между View. Но тут есть нюанс. Если тестировать Presenter классы в контексте системного тестирования, то необходимо как можно меньше зависимостей подменять mock объектами. И тут появляется проблема инициализации и приведения программы в нужное для начала тестирования состояние. В упомянутой выше статье Scenario Driven Tests об этом говорится подробнее.

Второй подход — использовать специальные инструменты для записи действий пользователя. То есть в итоге запускается сама программа, но щелканье по кнопкам осуществляется автоматически. Для .NET примером такого инструмента является White библиотека. Поддерживаются WinForms, WPF и еще несколько GUI платформ. Правило такое — на каждый use case пишется по скрипту, который описывает действия пользователя. Если все use case покрыты и тесты проходят, то можно сдавать систему заказчику. Акт сдачи-приемки должен подписать.

Источник



End-to-end или E2E-процесс: что это? Сквозное тестирование

Сквозное тестирование, оно же End-to-end или E2E, — это процесс тестирования, при котором происходит подробная эмуляция пользовательской среды. То есть при данном тестировании имитируют:

нажатия на кнопки,

переходы по страницам и ссылкам,

и другие поведенческие факторы.

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

Е2Е-процесс — это конечный этап тестирования, после него никакого тестирования не проводят. Он самый трудозатратный и дорогой, именно поэтому находится на вершине пирамиды тестирования.

Е2Е-процесс — что это?

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

К примеру, компания Гугл при разработке своих продуктов следует правилу «70-20-10», цифры которого показывают процентное соотношение от общего количества тестов, то есть:

70% занимают юнит-тесты;

20% занимают интеграционные тесты;

10% занимают Е2Е-тесты.

Конечно, такая комбинация тестов не является эталонной. Для каждого проекта она будет своя. Но идея в том, что количество Е2Е-тестов должно быть куда меньше, чем остальных тестов. В некоторых проектах сквозного тестирования вообще может не быть, так как unit-тесты и интеграционные тесты покрывают все процессы программы. А иногда просто их нецелесообразно проводить из-за того, что проект небольшой и тестируемый функционал может быть еще много раз переписан. Поэтому можно сказать, что E2E — это процесс больших и сложных проектов.

Какие бывают Е2Е-тесты

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

Метод «черного ящика». Это специальный E2E-процесс тестирования, при котором само тестирование проводится только с интерфейсом пользователя. «Черным ящиком» называется, потому что тестировщика интересуют только проблемы интерфейса: работоспособность функций, ошибки при взаимодействии, ошибки при определенном поведении пользователей и т. д., и его абсолютно не интересует, как это все работает внутри программы. В большинстве случаев тестировщик даже не понимает, как с помощью кода получается тот или иной функционал. Такой тип тестирования считается самым распространенным.

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

Любой сквозной тест — это:

в первую очередь тестирование UI;

тяжелый и медленный тест;

применение метода «черного ящика» и найм сторонних тестировщиков, никак не связанных с разработкой программы;

тяжелый «отлов» найденной проблемы;

тестирование всех модулей и всех систем целиком, поэтому требуется сложный и эффективный софт или работа «руками»;

гарантия, что программа работает так, как задумано, или нет.

Заключение

Е2Е — это дорогой и сложный процесс тестирования, к которому нужно подготавливаться основательно. Давайте проведем аналогию с мостом. Мост через реку — это тестируемая программа. Так вот Е2Е-тестирование — это не просто проехать по мосту груженными КАМАЗами и смотреть издалека: выдержит или не выдержит. Е2Е — это куча всевозможных датчиков, расставленных по всему мосту, которые сигнализируют о каждом шаге и готовы фиксировать любой сценарий развития на «мосту»:

Читайте также:  Необходимая оборона как защищаться по закону

нагрузку на каждый трос или балку;

поведение моста при наводнении, землетрясении, пожаре или аварии на нем;

Нужен или нет Е2Е именно вашей компании/программе/разработке? Это дело индивидуальное и зависит только от поставленных целей и потребностей. Практика показывает, что до сквозного тестирования должно проводиться множество других более простых тестов и на основе полученных от них результатов решается, нужен ли проекту Е2Е-тест или нет.

Источник

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

Что пишут в блогах

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

• Девять смертных грехов Scrum-мастера.

Подписаться

Онлайн-тренинги

Что пишут в блогах (EN)

Разделы портала

  • На главную
  • Новости
  • Блоги о тестировании
  • События
  • Библиотека
    • Тестирование
      • Общие вопросы
      • Функциональное тестирование
      • Тестирование производительности
      • Защищённость и надёжность
      • Другие виды тестирования
      • Тестовая лаборатория
      • Управление дефектами
      • Usability-тестирование
      • Начинающему тестировщику
      • Автоматизация тестирования
      • Тест-анализ и тест-дизайн
      • Тест-менеджмент
      • Тестирование мобильных приложений
      • Инструменты тестирования
    • Вокруг тестирования
    • Колонка редактора
    • Интервью
  • Литература
  • Рассылка по тестированию
  • О проекте

Про инструменты

Оригинальная публикация: http://automationpanda.com/2017/10/14/bdd-101-unit-integration-and-end-to-end-tests/

Перевод: Анна Радионова

Существует много видов ПО тестов. Практики BDD можно применять в любых аспектах тестирования, но BDD фреймворки используются далеко не во всех типах тестов. Поведенческие сценарии, по сути, являются функциональными тестами — они проверяют, что тестируемый продукт работает корректно. Для тестирования производительности могут использоваться инструменты, в то время как BDD фреймворки не предназначены для этих целей. Задача данной статьи, в основном, состоит в описании роли BDD автоматизации в Пирамиде Тестирования. Прочитайте статью BDD 101: Manual Testing для того, чтобы понимать как BDD применяется при ручном тестировании. (Всю информацию по BDD можно найти на странице Automation Panda BDD page)

Пирамида Тестирования

Пирамида Тестирования представляет собой подход к разработке тестов, который разделяет тесты на три слоя: юнит, интеграционные и end-to-end.

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

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

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

Ниже представлено графическое отображение Пирамиды Тестирования:

Пирамида Тестирования

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

Behavior-Driven юнит-тестирование

Тестовые BDD фреймворки не предназначены для написания юнит-тестов. Юнит-тесты являются низкоуровневыми, программными тестами для проверки отдельных функций или методов. Можно написать Gherkin тест в целях юнит-тестирования, но по факту это перебор. Гораздо лучше использовать уже существующие юнит-тест фреймворки как, например, JUnit, NUnit и pytest.

Тем не менее, BDD практики могут применяться для юнит-тестов. Каждый юнит-тест должен быть направлен на основную составляющую: один вызов, единичная вариация, определенная комбинация ввода; на поведение. В дальнейшем при разработке спецификация поведения фичи четко отделяет юнит тесты от тестов более высокого уровня. Разработчик функционала также ответственен за написание юнит-тестов, в то время как за интеграционные и end-to-end тесты несет ответственность другой инженер. Спецификация поведения является, своего рода, джентльменским соглашением о том, что юнит-тесты будут являться отдельной сущностью.

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

Тестовые BDD фреймворки наиболее ярко проявляют себя на интеграционных и end-to-end уровнях тестирования.

Поведенческие спецификации однозначно и лаконично описывают, на что именно ориентирован тест-кейс. Шаги могут быть написаны на интеграционном или end-to-end уровне. Тесты сервиса могут быть написаны с помощью поведенческих спецификаций, как, например в Karate. End-to-end тесты фактически представляют собой многошаговые интеграционные тесты. Обратите внимание на следующий пример, который, на первый взгляд, кажется базовой моделью взаимодействия с пользователем, но, по сути, является объемным end-to-end тестом:

Given a user is logged into the social media site
When the user writes a new post
Then the user’s home feed displays the new post
And the all friends’ home feeds display the new post

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

Длительные End-to-End тесты

Термины часто понимаются разными людьми по-разному. Когда люди говорят “end-to-end тесты,” они подразумевают продолжительные последовательные тесты: тесты, которые покрывают различное поведение продукта одно за другим. Это утверждение заставляет содрогнуться приверженцев BDD, т.к это противоречит основному правилу BDD: один сценарий, одно поведение. Конечно, с помощью BDD фреймворков можно составлять длительные end-to-end тесты, но нужно хорошо подумать, стоит ли это делать и как именно.

Существует пять основных принципов написания длительных end-to-end сценариев в BDD:

  1. Не стоит беспокоиться на этот счет. Если BDD процесс поставлен правильно, то каждое отдельное поведение уже полностью покрыто тестовыми сценариями. Каждый сценарий должен покрывать все классы эквивалентности вводимых и выводимых данных. Таким образом, длительные end-to-end сценарии будут являться, в основном, дублированием тестового покрытия. Вместо того, чтобы тратить время на разработку, лучше отказаться от автоматизации длительных end-to-end сценариев, как от тех, которые не представляют большой ценности и уделить больше времени ручному и исследовательскому тестированию.
  2. Объединить существующие сценарии в новые. Каждая When-Then пара представляет собой индивидуальное поведение. Шаги из существующих сценариев могут быть переопределены в другие сценарии и для этого потребуется лишь незначительный рефакторинг. Это нарушает хорошие практики Gherkin и может привести к появлению длительных сценариев, но это наиболее практичный способ переиспользовать шаги для обширных end-to-end сценариев. Большинство BDD фреймворков не поддерживают пошаговый порядок, а если поддерживают, то шаги должны быть переписаны, чтобы код работал. (Этот подход является наиболее практичным, но менее традиционным.)
  3. Встраивайте проверки в Given и When шаги. Данная стратегия позволяет избежать дуплицирования When-Then пар и убедиться, что проверки производятся. Корректность каждого шага проверяется на протяжении всего процесса с помощью Gherkin текста. Однако, может потребоваться ряд новых шагов.
  4. Воспринимайте последовательность поведений как уникальное отдельное поведение. Это наилучший способ обдумывания длительных end-to-end сценариев, т.к. он усиливает поведенческое мышление. Продолжительный сценарий имеет ценность только в том случае, если он расценивается как уникальное поведение. Сценарий должен быть написан с целью подчеркнуть эту уникальность. В противном случае это не тот сценарий, который стоит использовать. Такие сценарии часто являются декларативными и высокоуровневыми.
  5. Не используйте BDD фреймворки и пишите тесты исключительно с помощью средств автоматизации. Gherkin предназначен для совместной работы в отношении поведения, в то время как продолжительные end-to-end тесты решают проблемы интенсивности работы QA. Бизнес может предоставить поведенческие спецификации, но никогда не станет писать end-to-end тесты. Переписывание поведенческих спецификаций в длинные end-to-end сценарии может блокировать разработку. Гораздо лучшим решением является сосуществование: приемочные тесты могут быть написаны при помощи Gherkin, а продолжительные end-to-end тесты — средствами программирования. Для автоматизации обоих наборов тестов можно использовать одну и ту же базу кода, у них могут быть единые модули поддержки и даже методы определения шагов.

Выберите подход, наиболее подходящий вашей команде.

Источник

Adblock
detector