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

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

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

Я проверил документацию по Ruby on Rails для их классификации этих типов тестирования, и теперь это полностью меня бросило.

Можете ли вы дать мне краткое академическое описание интеграционного теста на примере реального мира?

На данный момент мне нравится это высказывание: «Не важно, как вы это называете, а как оно действует», сделанное Гойко Адзичем в этой статье .

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

Есть много людей, имеющих разные взгляды, в зависимости от их роли.

Для тестировщиков общепринятая методика тестирования в Нидерландах - TMap . TMap делает следующее различие.

• модульный тест
• модульный тест
• системный тест
• тест системной интеграции
• приемочные испытания (все виды / уровни)
• функциональный приемочный тест
• пользовательский приемочный тест
• приемочные испытания продукции

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

Википедия также имеет хороший обзор .

Книга прагматический программист говорит:

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

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

• кто вообще тестирует
• что проверено

• какова цель теста

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

Мой список выше - это только начало и предложение, но я действительно думаю: «Не важно, как вы это называете, но что это делает»

Надеюсь это поможет.

26-10-2016 Редактировать: Совсем недавно очень хорошее введение было размещено на юнит-тестах YouTube против интеграционных тестов - Musings MPJ - FunFunFunction # 55

интеграционный тест, оказывается приемочный тест

Очевидно.

Эти два почти одно и то же. Но в определении теста есть несколько несколько разные измерения.

Интеграция == система в целом.

Приемка == система в целом.

Единственная разница - и это неуловимо - это определение контрольных примеров.

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

Приемка == контрольные примеры для использования только 80% набора функций, ориентированных на конечного пользователя. Не все крайние и угловые случаи. Тестовые случаи, как правило, нетехнические, написанные конечными пользователями.

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

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

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

Таким образом, я привык делать следующие различия:

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

В определении интеграционного теста под внешним я имел в виду систему, которая выходит за рамки моего диапазона разработки : я не могу сразу изменить то, как они себя ведут, по любой причине. Это может быть библиотека, компонент системы, который нельзя изменить (т. Е. Он используется совместно с другими проектами в компании), DBMS и т. Д. Для этих тестов мне нужно настроить что-то очень похожее на реальную среду системы будет работать в: внешняя система должна быть инициализирована и установлена ​​в определенное состояние; реалистичные данные должны быть зарегистрированы в БД; и т.п.

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

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

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

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

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

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

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

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

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

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

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

Например: когда мы составляем письмо (один модуль) и отправляем его по какому-то действительному идентификатору пользователя (второй модуль), интеграционное тестирование должно проверить, есть ли отправленная почта в отправленных элементах.

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

Например:

• Файловая система
• Сеть
• База данных
• Внешний API

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

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

Хотя существуют интеграционные тесты, это определение не охватывает (поэтому я и назвал это практическим определением), но я думаю, что они гораздо менее распространены / полезны.

NB Строго говоря, да, это определение будет также охватывать системные / сквозные тесты. В моей философии они являются формой «экстремального» интеграционного теста, поэтому их имена подчеркивают другой аспект. В другом направлении модульный тест можно считать интегральным тестом нулевых компонентов, т. Е. Можно считать, что все тесты лежат где-то в спектре интеграции, интегрируя между 0-n компонентами :-)