Что такое юнит-тесты, интеграционные тесты, дымовые тесты и регрессионные тесты?

Что такое юнит-тесты, интеграционные тесты, дымовые тесты и регрессионные тесты? Каковы различия между ними и какие инструменты я могу использовать для каждого из них?

Например, я использую JUnit и NUnit для модульного тестирования и интеграционного тестирования. Существуют ли инструменты для тестирования дыма или регрессионного тестирования?

6.02.2009 12:08:34
Bill the Lizard 6.02.2009 12:57:32
Другие уже ответили хорошо, но я хотел бы добавить, что лично я считаю, что тесты дыма и регрессионного теста являются излишними. Они делают то же самое: тестируют, чтобы убедиться, что изменения в системе ничего не сломали.
Randolpho 9.03.2009 14:51:51
Я думаю, что они сильно отличаются от регрессионных тестов. Я думаю, что это преднамеренно «легкие» быстрые тесты, которые запускаются в начале, чтобы сэкономить время, потому что, если какой-либо из них окажется неудачным, вы знаете, что не стоит беспокоиться о каких-либо дополнительных тестах. Например, может ли клиент подключиться к базе данных, установлен ли .net, установлена ​​ли правильная версия ... Возможно, у вас также есть предварительное развертывание (мы обновляемся с версии v1 до версии 1.1, поэтому убедитесь, что версия v1 установлена) и после Развертывание дымовых испытаний.
AndyM 19.03.2010 13:18:27
Дымовые тесты соответствуют описанию AndyM. Но они также являются типом регрессионного теста.
kevin mcdonnell 6.06.2014 10:49:07
rogerdpack 4.08.2015 16:27:10
21 ОТВЕТ
РЕШЕНИЕ
  • Юнит-тест : Укажите и протестируйте одну точку контракта одного метода класса. Это должно иметь очень узкую и четко определенную область применения. Сложные зависимости и взаимодействия с внешним миром являются заглушкой или насмешкой .

  • Интеграционный тест : проверить правильность взаимодействия нескольких подсистем. Там есть целый спектр от тестирования интеграции между двумя классами до тестирования интеграции с производственной средой.

  • Дымовой тест (он же Sanity check) : простой интеграционный тест, где мы просто проверяем, что при вызове тестируемой системы она возвращается нормально и не взрывается.

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

К этому я добавлю:

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

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

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

1035
26.07.2018 16:15:21
Испытание дымом предшествует электронике на столетие и происходит от сантехники, когда система труб была заполнена настоящим дымом, а затем проверена визуально. Если он курил, это было дырявым.
SnakE 10.05.2012 12:52:57
Регрессионные тесты также используются для изменения функций, а не только для исправления ошибок. Ответ Никиты ниже - более полное определение.
BobRodes 13.12.2012 19:53:13
@AndyM Фон «Дымового теста» неточный. IIRC это происходит от водопровода, где дым выкачивается в систему труб после того, как он построен (и до того, как он подключен к водопроводу). При появлении дыма трубы не герметично закрыты. Это менее опасно, чем фактически позволить воде течь и посмотреть, есть ли какие-либо лужи (возможно повреждение стен / кладки в процессе). Это грубое приближение, что система не потерпит катастрофического отказа. Процесс разработки может быть: «Сборка» пройдена? => «Дымовой тест» пройден? => «Приемочный тест» передан => команде QA для детального тестирования.
Cristian Diaconescu 5.06.2013 11:58:35
Я полагаю, вы допустили ошибку, заявив, что «Регрессионный тест» действительно сокращенно для «Нерегрессионного теста»? Я скептически отношусь, отчасти потому, что это просто не интуитивно понятно и сбивает с толку (хотя есть много терминов), но в Википедии есть две отдельные статьи о регрессионных и нерегрессионных тестах. В статье о регрессионном тестировании даже говорится: « Контраст с нерегрессионным тестированием ... целью которого является проверка того, оказало ли изменение после введения или обновления данного программного приложения ожидаемый эффект».
Brian C 23.06.2016 17:56:16
@ddaa Тестирование на здравомыслие и тестирование на дым не одно и то же. Проверка работоспособности выполняется после того, как сборка прошла тест Smoke и была принята командой QA для дальнейшего тестирования. Проверка работоспособности проверяет основные функциональные возможности с более мелкими деталями.
Bharat 2.12.2016 06:43:45
  • Модульный тест : автоматический тест для проверки внутренней работы класса. Это должен быть отдельный тест, который не связан с другими ресурсами.
  • Интеграционный тест : автоматический тест, выполняемый в среде, похожей на модульные тесты, но с внешними ресурсами (дБ, доступ к диску)
  • Регрессионный тест : после внедрения новых функций или исправления ошибок вы повторно тестируете сценарии, которые работали в прошлом. Здесь вы рассматриваете возможность, в которой ваши новые функции нарушают существующие функции.
  • Дымовое тестирование : первые тесты, по которым тестировщики могут завершить тестирование, если они продолжат тестирование.
105
6.02.2009 12:13:56
Определение регрессионного теста на самом деле не совсем так. @ddaa определяет это правильно.
Robert Koritnik 11.10.2010 14:37:01
Определение Интеграционного теста определенно нечетко. Например, ответ здесь stackoverflow.com/a/4904533/32453 более определен как тестирование нескольких взаимодействий вашего кода, не обязательно требующих реальной БД (внешнего ресурса) ... хотя некоторые люди определяют это так, как вы описали ... ааа терминология. (Я немного предпочитаю предыдущее определение, FWIW, тестирование нескольких взаимодействий.)
rogerdpack 4.08.2015 16:31:48

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

  • Модульный тест: работает ли этот маленький (как можно более изолированный) элемент?
  • Интеграционный тест: работают ли эти два (или более) компонента вместе?
  • Испытание на дым: действительно ли вся эта система (настолько близкая к производственной системе) достаточно хорошо держится вместе? (то есть мы уверены, что это не создаст черную дыру?)
  • Регрессионный тест: случайно ли мы повторно представили ошибки, которые мы ранее исправили?
90
6.02.2009 12:15:07
Как вы размещаете свои интеграционные тесты относительно юнит-тестов? Если myprj это основной каталог проекта, и mypkgон находится в папке, у myprjменя есть модульные тесты myprj/tests/test_module1.py, а мой пакет - в папке myprj/mypkg. Это прекрасно работает для модульных тестов, но мне интересно, есть ли какое-либо соглашение, я должен следовать для того, где должны находиться интеграционные тесты?
alpha_989 15.02.2018 23:38:02
@ alpha_989: я не знаю, что будет за конвенция для Python. В настоящее время в .NET у меня есть производственный код, модульные тесты и интеграционные тесты в трех отдельных проектах, равные друг другу, но есть и много альтернатив.
Jon Skeet 16.02.2018 03:25:29
Хорошо, спасибо. Я мог бы найти стандартную рекомендацию, кроме как посмотреть на другой проект Python. но я буду следовать за
alpha_989 16.02.2018 04:04:22

апокрифические исторические мелочи: «тестирование дыма» происходит от подводной инженерии (унаследованной от сантехники), где буквальный дым будет закачиваться в корпус, чтобы посмотреть, не появится ли он снова, что было бы довольно серьезным провалом для подводной лодки!

19
6.02.2009 12:27:23

Некоторые хорошие ответы уже есть, но я хотел бы уточнить их:

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

Поэтому очевидно, что модульное тестирование - единственное тестирование белого ящика здесь

  • Модульное тестирование тестирует определенные куски кода. Обычно методы.
  • Тестирование интеграции проверяет, может ли ваша новая функциональная часть программного обеспечения интегрироваться со всем остальным.
  • Регрессионное тестирование. Это тестирование, чтобы убедиться, что вы ничего не сломали. Все, что раньше работало, должно работать.
  • Дымовое тестирование проводится как быстрый тест, чтобы убедиться, что все выглядит хорошо, прежде чем вы приступите к более активному тестированию.
1
6.02.2009 12:31:31
Модульное тестирование не обязательно белая коробка. Некоторые из лучших модульных тестов, которые я видел, по сути являются примерами, взятыми из требований, определяя ожидаемые результаты независимо от каких-либо концепций реализации.
joel.neely 6.02.2009 12:51:51
Кроме того, ваши модульные тесты включены в ваши регрессионные тесты, поэтому регрессионные тесты не являются тестами белого или черного ящика. Я бы даже сказал, что даже тесты на интеграцию и тестирование на дым могут быть тестами белого или черного ящика.
Lieven Keersmaekers 6.02.2009 13:29:27
Я бы не согласился с этим. Тестирование реализации шаблона проектирования является формой интеграционного тестирования и является тестом белого ящика.
Hazok 13.12.2012 05:25:26

Модульный тест: проверка того, что конкретный компонент (т. Е. Класс) создал или изменил функции в соответствии с назначением. Этот тест может быть ручным или автоматическим, но не выходит за пределы компонента.

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

Регрессионный тест: проверка того, что новые дефекты не внесены в существующий код. Эти тесты могут быть ручными или автоматизированными.

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

Набор инструментов будет в значительной степени зависеть от кодовой базы, но есть много инструментов с открытым исходным кодом для модульного тестирования (JUnit). HP (ртутный) QTP или Borland Silktest являются инструментами для автоматической интеграции и регрессионного тестирования.

9
4.03.2009 01:48:41

РЕГРЕССИЯ

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

7
21.10.2010 05:28:26
Откуда вы цитируете?
Daryl 22.03.2013 21:26:16
Согласно этой странице , эта цитата взята из статьи Википедии «Тестирование программного обеспечения», хотя кажется, что отрывок был изменен в какой-то момент с 2010 года.
Zach Lysobey 29.10.2013 15:58:26
В любом случае, WP не является действительным источником. Источники, на которые есть ссылки, могут быть действительными. Нет никаких действительных источников, на которые есть ссылки в WP, ни в статьях, ни на страницах обсуждения, которые бы поддержали утверждение, что «не» имеет какое-либо значение. Я сравнил фрагменты текста в списках результатов поисков в Google Книгах для обоих "regression test"и "non-regression test". Это то же самое.
Rainald62 24.07.2018 15:14:36

Новая категория тестов, о которой я только что узнал, это:

Канарейка тест

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

Примеры могут быть:

  • В LIVE появились данные, которые должны быть доступны только в DEV / TEST.
  • Не удалось запустить фоновый процесс
  • Может ли пользователь войти в систему
51
11.09.2013 03:47:51
Можно ли вообще пинговать сайт - достаточно того, что существует сервис Binary Canary.
Dan Dascalescu 23.02.2014 23:53:46
Название происходит от добычи угля: возьмите канарейку с собой "вниз по течению". Когда это поглотит это, убирайся быстрее. Канарские острова очень чувствительны к небольшим концентрациям вредного газа и могут умереть до того, как уровни концентрации станут токсичными для людей. Если Canary-тест не пройден, исправьте его быстро, потому что только LIVE потерпит неудачу.
Robino 3.09.2014 12:06:48
То, как мы используем тестирование Canary на моей работе, заключается в том, чтобы сначала перевести нескольких клиентов на новую версию, а не всех сразу. Если первые несколько клиентов выживут, мы можем добавить остальных. Те первые несколько канареек.
00prometheus 15.09.2016 19:23:42
@ 00promeheus, это бета-тестирование.
GregNash 19.01.2017 22:32:54
@HarveyLin, хотя тест Канарских островов - это обязательно тест, предотвращающий бедствие, конечно, он используется не только таким образом. Но эмпирическое правило гласит: «Проверь это работает, потому что это критично» Конечно, у каждого теста есть почти одна и та же цель, но концепция очень специфична. В вашем случае я бы не считал все тесты канарскими.
Charles Roberto Canato 19.07.2017 00:00:25

Модульный тест: проверка того, что конкретный компонент (т. Е. Класс) создал или изменил функции в соответствии с назначением. Этот тест может быть ручным или автоматическим, но не выходит за пределы компонента.

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

Регрессионный тест: проверка того, что новые дефекты не внесены в существующий код. Эти тесты могут быть ручными или автоматизированными.

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

3
17.09.2013 09:59:06

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

3
28.10.2013 21:19:35
Я согласен, но я подумал, что это будет полезным дополнением к вопросу, так же как и комментарий @AndyM о тестировании на Канарских островах. Если есть более открытый поток, где все типы тестирования программного обеспечения должны быть перечислены и определены, я не нашел бы это.
Jaime Gago 31.10.2013 07:54:06

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

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

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

регрессионное тестирование, выполняющее одни и те же тестовые примеры несколько раз, чтобы убедиться, что неизмененный модуль не вызывает никаких дефектов. РЕГРЕССИОННОЕ ИСПЫТАНИЕ проходит функциональное тестирование

8
26.04.2014 12:02:23
  • Интеграционное тестирование: интеграционное тестирование - это еще один элемент интеграции
  • Тестирование дыма: Тестирование дыма также известно как тестирование версии сборки. Тестирование дыма - это начальный процесс тестирования, выполняемый для проверки готовности / стабильности тестируемого программного обеспечения для дальнейшего тестирования.
  • Регрессионное тестирование: Регрессионное тестирование - это повторное тестирование. Внедрено ли новое программное обеспечение в другой модуль или нет.
  • Модульное тестирование: это тестирование белого ящика. В нем участвуют только разработчики
4
7.11.2014 12:22:42

Модульное тестирование: - Модульное тестирование обычно выполняется разработчиками, когда тестеры частично развиваются в этом типе тестирования, где тестирование проводится по частям. В java тестовых случаях Junit также можно проверить, идеально ли написан код или нет.

Интеграционное тестирование: - Этот тип тестирования возможен после модульного тестирования, когда все / некоторые компоненты интегрированы. Этот тип тестирования будет гарантировать, что, когда компоненты интегрированы, они влияют друг на друга на рабочие возможности или функциональные возможности.

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

Регрессионное тестирование: - Этот тип тестирования важен для проверки того, что непреднамеренные / нежелательные дефекты отсутствуют в системе, когда разработчик исправил некоторые проблемы. Это тестирование также гарантирует, что все ошибки успешно устранены, и поэтому никаких других проблем не возникает.

2
16.09.2014 10:50:07

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

Когда ваш тест вызывает более одного класса, это интеграционный тест .

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

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

5
7.11.2014 12:23:58

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

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

1
28.07.2015 16:36:50

Ответ одного из лучших сайтов по методам тестирования программного обеспечения:

Типы тестирования программного обеспечения - Полный список Нажмите здесь

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

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

Надеюсь, это будет полезно :)

11
4.08.2017 22:59:10

Модульное тестирование: разработчик всегда выполняет разработчик, чтобы выяснить проблему со стороны тестирования, прежде чем он подготовит какое-либо требование для обеспечения качества.

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

Тестирование дыма: тестер выполнил проверку системы для высокоуровневого тестирования и попытался обнаружить ошибку show stoppper перед изменениями или вводом кода в действие.

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

2
18.07.2017 12:29:27
Разве нам не нужно создавать тест перед тем, как приступить к разработке?
Vin Shahrdar 29.11.2017 15:55:00
@VinShahrdar, вы говорите о модульном тестировании?
Krunal 1.12.2017 10:24:03
да. Я обычно создаю свои модульные тесты перед написанием производственного кода. Вот как ты должен это делать, правильно?
Vin Shahrdar 2.12.2017 22:10:18
Да .. Но модульное тестирование также выполняется перед QA, с которым столкнулся разработчик. Перед развертыванием кода на QA-сервере разработчик всегда выполняет модульное тестирование
Krunal 6.12.2017 11:52:14

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

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

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

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

2
17.11.2017 11:58:04

Тест дыма уже объяснен и прост. Регрессионный тест проходит интеграционный тест.

Автоматизированные тесты можно разделить только на 2.

Модульный тест и интеграционный тест. (это все, что имеет значение)

Я бы назвал использование фразы «длинный тест» (LT) для всех тестов, таких как интеграционный тест, функциональный тест, регрессионный тест, тест пользовательского интерфейса и т. Д. И модульный тест как «короткий тест».

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

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

1
9.12.2017 08:45:56

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

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

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

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

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

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

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

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

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

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

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

источник: https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing

3
18.01.2019 09:53:59
Определение тестирования дыма здесь довольно плохое. Любой тест низкого уровня может быть «базовым тестом, который проверяет основные функциональные возможности приложения». Лучший кандидат для этого определения - юнит-тесты. Модульный тест проверяет единицу приложения (как следует из названия), и единица действительно является базовой функциональностью (в зависимости от определения функциональности). Лучшее определение, по-видимому, приведено @ddaa
yerlilbilgin 20.05.2019 07:14:44

Я просто хотел добавить и дать больше контекста о том, почему у нас есть эти уровни тестирования, что они на самом деле означают с примерами

Майк Кон в своей книге «Успех с Agile» придумал «Пирамиду тестирования» как способ приблизиться к автоматизированным тестам в проектах. Существуют различные интерпретации этой модели. Модель объясняет, какие виды автоматических тестов необходимо создавать, как быстро они могут дать отзыв о тестируемом приложении и кто пишет эти тесты. В принципе, для любого проекта необходимо 3 уровня автоматического тестирования, и они заключаются в следующем.

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

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

Исторически разработчик пишет эти тесты, так как они обычно пишутся на том же языке программирования, что и программное приложение. Для этой цели используются платформы модульного тестирования, такие как JUnit и NUnit (для java), MSTest (для C # и .NET) и Jasmine / Mocha (для JavaScript).

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

Тесты API / интеграции - они тестируют различные компоненты системы программного обеспечения вместе. Компоненты могут включать тестирование баз данных, API (Application Programming Interface), сторонних инструментов и сервисов вместе с приложением.

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

Исторически разработчик или технический QA писал бы эти тесты, используя различные инструменты, такие как Postman, SoapUI, JMeter и другие инструменты, такие как Testim.

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

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

Например - В приложении калькулятора сквозной поток может быть следующим: открытие браузера-> Ввод URL-адреса приложения калькулятора -> Вход в систему с именем пользователя / паролем -> Открытие приложения калькулятора -> Выполнение некоторых операций с калькулятором -> проверка этих результатов из пользовательского интерфейса -> Выход из приложения. Это может быть сквозной поток, который будет хорошим кандидатом для автоматизации пользовательского интерфейса.

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

Самое большое ограничение тестов пользовательского интерфейса, они относительно медленны по сравнению с тестами уровня и уровня API. Таким образом, он должен составлять всего 10-20% от всех автоматизированных тестов.

Следующие два типа тестов могут различаться в зависимости от вашего проекта, но идея заключается в том,

Тесты дыма

Это может быть комбинацией вышеуказанных 3 уровней тестирования. Идея состоит в том, чтобы запускать его во время каждой регистрации кода и гарантировать, что критические функции системы по-прежнему работают должным образом; после изменения нового кода объединяются. Как правило, они должны работать с 5 - 10 минут, чтобы получить более быструю обратную связь о сбоях

Регрессионные тесты

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

7
26.08.2019 14:36:40