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

110

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

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

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

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

Мартин Блор
источник
76
Кстати, когда у вас есть существительная фраза («Я и некоторые друзья»), вы должны быть осторожны с тем, какое имя первого лица вы используете. Вот тест. Оставь друзей и посмотри, все ли еще работает. «Я боролся» против «Я боролся». Этот тест говорит вам, что это «Я и мои друзья ...» И - чтобы быть вежливым - мы сначала перечислим других. "Я и мои друзья". Тестирование важно.
S.Lott
58
Я думаю, что С.Лотт только что дал вам тест интеграции грамматики -> общества.
Иордания

Ответы:

78

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

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

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

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

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

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

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

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

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

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

  • кто вообще тестирует
  • что проверено
  • какова цель теста

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

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

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

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

KeesDijk
источник
3
+1 За "не важно, как ты это называешь". К сожалению, нет универсального определения любого вида теста. Даже хороший старый юнит-тест немного изменчив. Считается ли тестирование DOM для веб-приложения модульным тестом? Некоторые говорят да, некоторые говорят нет.
Лоран Бурго-Рой
2
Ссылка на слово doc недоступна.
Поль Ружье
6
«Не важно, как вы это называете» применимо ко всей информатике, и фактически ко всем областям. Я нахожу, что многие горячие аргументы, в которые люди вступают, можно свести к «мы спорим об определении произвольной фразы».
садовник
+1 согласен с определениями: я был в месте, где «модульное тестирование» показало, что программист попробовал систему хотя бы с одним вводом выборки… вручную… и визуально проверил вывод, если он «показался правильным» , Нет контракта относительно того, что ожидалось, нет контролируемых входов и т. Д.
Newtopian
Ссылка на Гойко возвращается на 404. Вы можете получить доступ архив здесь: web.archive.org/web/20150104002755/http://gojko.net/2011/01/12/...
Эдуардо Copat
32

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

Очевидно.

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

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

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

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

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

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

С. Лотт
источник
7
Единственное, что я хотел бы добавить к этому, - это то, что интеграционные тесты могут также тестировать только часть системы, но более чем по одной части за раз. Каждый раз, когда вы ищете ошибки, вызванные двумя или более частями системы, работающими в унисон (объединенными вместе), вы проводите интеграционное тестирование. Интеграция запускается из двух реальных компонентов, а все остальное проверяется на совместимость всего набора приложений и может даже пойти на проверку интеграции с другими приложениями (например, «Как MS Office работает с Internet Explorer?»).
Этель Эванс
1
@ Этель Эванс: Хороший вопрос. Тест будет по-прежнему размытым между интеграцией и приемкой, даже если задействована только часть системы. Тестирование проводится на достаточно высоком уровне, чтобы принятие и интеграция ощущались одинаково.
S.Lott
3
Интеграционные тесты, конечно, не (и, вероятно, не должны) тестировать «систему в целом». Везде, где два или более компонента тестируются вместе, особенно при тестировании на внешних компонентах (база данных, сеть и т. Д.), Вы проводите интеграционное тестирование. Из-за высокой стоимости тестирования "всей системы" вы хотите, насколько это возможно, избежать этого, вместо этого попробуйте сделать больше тестов интеграции частичной системы (см. Пирамида тестирования
Schneider
1
@Schneider хорошо это говорит, интеграционные тесты не должны тестировать «систему в целом». Такие тесты будут рассматриваться как «сквозные тесты» или «системные тесты», в зависимости от того, какую область вы рассматриваете в своем проекте. Сквозные тесты могут охватывать поток данных «в целом», который выполняется через несколько систем, а системные тесты - только «одна система в целом».
RoyB
Вот как я их определяю, чтобы избежать путаницы вокруг широкого использования теста «Интеграция». Модульные тесты -> тестирует наименьшую единицу работы, метод в классе, который не вызывает какой-либо другой код вне этого метода (при необходимости вычеркивая зависимости). Интеграционные тесты -> тесты большего объема из модульных тестов, где они могут и должны тестировать слои приложения, работающие вместе, но НЕ целое приложение, развернутое где-либо.) Функциональные тесты / приемочный тест -> тесты, которые тестируют развернутую версию приложения
Kevin M
16

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

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


источник
4
Я согласен, за исключением того, что не нужно быть «полностью собранной» системой. Вы можете (и должны) проводить интеграционное тестирование с подмножествами полной системы, поскольку это обычно дешевле / проще.
Шнайдер
Интеграция между двумя устройствами / компонентами также может быть «проверена на интеграцию», в то время как остальные все еще проверяются. Следовательно, многие интегрированные интегрированные среды тестирования допускают насмешки :)
RoyB
1
У меня есть тесты в приложении Spring Boot, которое тестирует внешний интерфейс (контракт API) в контейнере Spring, но макетирует слой хранилища / данных. Таким образом, он использует фиктивные репозитории / данные, но объединяет уровень контроллера, выполняет маршалинг Джексона и т. Д. Интеграционный тест.
Кевин М,
8

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

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

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

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

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

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

Марко Чамброне
источник
6

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

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

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

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

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

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

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

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

введите описание изображения здесь

Christophe
источник
1

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

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

Анита
источник
3
Добро пожаловать в Программисты. Что добавляет ваш ответ, который еще не был предоставлен в существующих ответах? Programmers.SE не похож на традиционные форумы. Он сосредоточен на высококачественных вопросах и ответах, а не на болтовне. Пожалуйста, посмотрите на страницу тура для получения дополнительной информации о том, как работает сайт.
0

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

Например:

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

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

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

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

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

Schneider
источник
Когда у вас есть два модуля, вы тестируете каждый с помощью модульного теста. Когда эти два модуля интегрируются друг с другом, вы тестируете интеграцию с помощью интеграционного теста. Они не должны быть «вне процесса», и такого рода тесты чрезвычайно распространены.
Брайан Окли
Вы абсолютно правы - вещи не должны быть вне процесса, чтобы быть интеграционным тестом. Вот почему я постарался уточнить, что мой ответ был скорее «практическим правилом» (но, возможно, провалился). Я не согласен с тем, что интеграционные тесты между модулями "чрезвычайно распространены". Интеграционные тесты с внепроцессным тестированием гораздо чаще встречаются в моем опыте и часто очень ценны, поэтому в моем ответе подчеркивается этот аспект интеграционного тестирования.
Шнайдер