Что такое юнит-тест, интеграционный тест, дымовой тест, регрессионный тест?
Что такое модульный тест, интеграционный тест, дымовой тест, регрессионный тест и чем они отличаются? И какие инструменты я могу использовать для каждого из них?
Например, я использую JUnit и NUnit для модульного тестирования и интеграционного тестирования. Существуют ли инструменты для проверки дыма или регрессионного теста?
21 ответ
Модульный тест: Укажите и протестируйте одну точку контракта одного метода класса. Это должно иметь очень узкую и четко определенную область применения. Сложные зависимости и взаимодействия с внешним миром являются заглушкой или насмешкой.
Интеграционный тест: проверить правильность взаимодействия нескольких подсистем. Там есть целый спектр, от тестирования интеграции между двумя классами до тестирования интеграции с производственной средой.
Дымовой тест (он же Sanity check): простой интеграционный тест, в котором мы просто проверяем, что при вызове тестируемой системы она возвращается нормально и не взрывается.
- Дымовое тестирование - это аналогия с электроникой, где первый тест проводится при включении питания (если он курит, это плохо!)...
- ... и, видимо, с сантехникой, где система труб буквально заполняется дымом, а затем проверяется визуально. Если что-то курит, система протекает.
Регрессионный тест: тест, который был написан, когда ошибка была исправлена. Это гарантирует, что эта конкретная ошибка не возникнет снова. Полное название "Нерегрессионный тест". Это также может быть тест, выполненный до изменения приложения, чтобы убедиться, что приложение дает тот же результат.
К этому я добавлю:
Приемочный тест: проверка правильности реализации функции или варианта использования. Это похоже на интеграционный тест, но с акцентом на сценарии использования, а не на задействованные компоненты.
Системный тест: тестирует систему как черный ящик. Зависимости в других системах во время теста часто высмеиваются или заглушаются (иначе это было бы скорее интеграционным тестом).
Проверка перед полетом: тесты, которые повторяются в производственной среде, чтобы облегчить синдром "сборки на моей машине". Зачастую это достигается путем проведения приемочного или дымового испытания в производственной среде.
- Модульный тест: автоматический тест для проверки внутренней работы класса. Это должен быть отдельный тест, который не связан с другими ресурсами.
- Интеграционный тест: автоматический тест, выполняемый в среде, похожей на модульные тесты, но с внешними ресурсами (дБ, доступ к диску)
- Регрессионный тест: после внедрения новых функций или исправления ошибок вы повторно тестируете сценарии, которые работали в прошлом. Здесь вы раскрываете возможность, в которой ваши новые функции нарушают существующие функции.
- Дымовое тестирование: первые тесты, по которым тестировщики могут завершить, если они продолжат тестирование.
У каждого будут немного отличающиеся определения, и часто есть серые области. Тем не мение:
- Модульный тест: работает ли этот маленький (как можно более изолированный) элемент?
- Интеграционный тест: эти два (или более) компонента работают вместе?
- Испытание на дым: действительно ли вся эта система (настолько близкая к производственной системе) достаточно хорошо держится вместе? (то есть мы уверены, что это не создаст черную дыру?)
- Регрессионный тест: случайно ли мы повторно представили ошибки, которые мы ранее исправили?
Новая категория тестов, о которой я только что узнал, это:
Канарейка тест
Канарский тест - это автоматический, неразрушающий тест, который регулярно выполняется в среде LIVE, так что, если он когда-либо не проходит, происходит что-то действительно плохое.Примеры могут быть:
- В LIVE появились данные, которые должны быть доступны только в DEV / TEST.
- Не удалось запустить фоновый процесс
- Может ли пользователь войти
Апокрифические исторические мелочи: "тестирование дыма" происходит от подводной инженерии (унаследованной от сантехники), где буквальный дым будет закачиваться в корпус, чтобы посмотреть, не появится ли он снова, что было бы довольно драматическим провалом для подводной лодки!
Ответ с одного из лучших сайтов по методам тестирования программного обеспечения:
Типы тестирования программного обеспечения - Полный список Нажмите здесь
Это довольно длинное описание, я не буду его здесь вставлять, но оно может оказаться полезным для тех, кто хочет знать все методы тестирования.
Надеюсь, это будет полезно:)
модульное тестирование: тестирование отдельного модуля или независимого компонента в приложении, как известно, является модульным тестированием, модульное тестирование будет выполняться разработчиком.
интеграционный тест: объединение всех модулей и тестирование приложения для проверки правильности работы связи и обмена данными между модулями, это тестирование также проводится разработчиками.
Тест на дым В тесте на дым они проверяют приложение в мелкой и широкой манере. В тесте на дым они проверяют основную функциональность приложения, если в приложении есть какие-либо проблемы с блокировщиками, о которых они сообщают команде разработчиков, и команда разработчиков исправит это и устраните дефект и верните его команде тестирования, и теперь группа тестирования проверит все модули, чтобы убедиться, что изменения, сделанные в одном модуле, повлияют на другой модуль или нет. В тесте на курение тестовые случаи пишутся по сценарию
регрессионное тестирование, выполняющее одни и те же тестовые примеры несколько раз, чтобы убедиться, что неизмененный модуль не вызывает никаких дефектов. РЕГРЕССИОННОЕ ИСПЫТАНИЕ проходит функциональное тестирование
Модульный тест: проверка того, что конкретный компонент (т. Е. Класс) создал или изменил функции в соответствии с назначением. Этот тест может быть ручным или автоматическим, но не выходит за пределы компонента.
Интеграционный тест: проверка того, что взаимодействие отдельных компонентов функционирует так, как задумано. Интеграционные тесты могут выполняться на уровне устройства или на уровне системы. Эти тесты могут быть ручными или автоматизированными.
Регрессионный тест: проверка того, что новые дефекты не внесены в существующий код. Эти тесты могут быть ручными или автоматизированными.
В зависимости от вашего SDLC (водопад, разрыв, гибкость и т. Д.) Определенные тесты могут выполняться поэтапно или могут выполняться более или менее одновременно. Например, модульное тестирование может быть ограничено разработчиками, которые затем передают код тестерам для интеграции и регрессионного тестирования. Однако другой подход может заключаться в том, что разработчики проводят модульное тестирование и некоторый уровень интеграции и регрессионного тестирования (используя подход TDD наряду с непрерывной интеграцией и автоматизированными модульными и регрессионными тестами).
Набор инструментов будет в значительной степени зависеть от кодовой базы, но есть много инструментов с открытым исходным кодом для модульного тестирования (JUnit). HP (ртутный) QTP или Borland Silktest являются инструментами для автоматической интеграции и регрессионного тестирования.
Я просто хотел добавить и дать дополнительный контекст о том, почему у нас есть эти уровни тестирования, что они на самом деле означают с примерами.
Майк Кон в своей книге "Успех с помощью Agile" придумал "Пирамиду тестирования" как способ подхода к автоматизированному тестированию в проектах. Существуют различные интерпретации этой модели. Модель объясняет, какие автоматические тесты необходимо создать, насколько быстро они могут дать обратную связь по тестируемому приложению и кто пишет эти тесты. В основном для любого проекта необходимо 3 уровня автоматизированного тестирования, и они заключаются в следующем.
Модульные тесты - они тестируют самый маленький компонент вашего программного приложения. Это может быть буквально одна функция в коде, которая вычисляет значение на основе некоторых входных данных. Эта функция является частью нескольких других функций аппаратной / программной кодовой базы, составляющей приложение.
Например - возьмем веб-приложение-калькулятор. Самыми маленькими компонентами этого приложения, которые необходимо тестировать, могут быть функция, которая выполняет сложение, другая функция, выполняющая вычитание, и так далее. Все эти небольшие функции вместе составляют приложение-калькулятор.
Исторически разработчик пишет эти тесты, поскольку они обычно написаны на том же языке программирования, что и программное приложение. Для этой цели используются такие среды модульного тестирования, как JUnit и NUnit (для java), MSTest (для C# и.NET) и Jasmine/Mocha (для JavaScript).
Самым большим преимуществом модульных тестов является то, что они работают очень быстро под пользовательским интерфейсом, и мы можем быстро получить отзывы о приложении. Это должно составлять более 50% ваших автоматических тестов.
Тесты API/ интеграции - вместе тестируют различные компоненты программной системы. Компоненты могут включать в себя тестовые базы данных, API (интерфейс прикладного программирования), сторонние инструменты и службы вместе с приложением.
Например - в нашем примере с калькулятором выше веб-приложение может использовать базу данных для хранения значений, использовать API для выполнения некоторых проверок на стороне сервера и может использовать сторонний инструмент / службу для публикации результатов в облаке, чтобы сделать их доступными для разных платформы.
Раньше разработчик или технический специалист по контролю качества писал эти тесты, используя различные инструменты, такие как Postman, SoapUI, JMeter и другие инструменты, такие как Testim.
Они работают намного быстрее, чем тесты пользовательского интерфейса, поскольку они по-прежнему работают под капотом, но могут занимать немного больше времени, чем модульные тесты, поскольку они должны проверять связь между различными независимыми компонентами системы и обеспечивать их бесшовную интеграцию. Это должно составлять более 30% автоматизированных тестов.
Тесты пользовательского интерфейса. Наконец, у нас есть тесты, которые проверяют пользовательский интерфейс приложения. Эти тесты обычно пишутся для проверки сквозных потоков в приложении.
Например - В приложении калькулятора сквозной поток может быть следующим: открытие браузера -> Ввод URL-адреса приложения калькулятора -> Вход с именем пользователя / паролем -> Открытие приложения калькулятора -> Выполнение некоторых операций на калькуляторе -> проверка этих результатов из пользовательского интерфейса -> Выход из приложения. Это может быть непрерывный поток, который может стать хорошим кандидатом для автоматизации пользовательского интерфейса.
Исторически сложилось так, что тесты пользовательского интерфейса пишут технические или ручные тестировщики. Они используют фреймворки с открытым исходным кодом, такие как Selenium, или платформы тестирования пользовательского интерфейса, такие как Testim, для создания, выполнения и сопровождения тестов. Эти тесты дают больше визуальной обратной связи, поскольку вы можете видеть, как выполняются тесты, разницу между ожидаемыми и фактическими результатами с помощью снимков экрана, журналов, отчетов о тестах.
Самым большим ограничением тестов пользовательского интерфейса является то, что они относительно медленны по сравнению с тестами уровня Unit и API. Таким образом, он должен составлять лишь 10-20% от общего числа автоматизированных тестов.
Следующие два типа тестов могут отличаться в зависимости от вашего проекта, но идея заключается в следующем:
Дымовые испытания
Это может быть комбинация трех вышеуказанных уровней тестирования. Идея состоит в том, чтобы запускать его во время каждой проверки кода и гарантировать, что критически важные функции системы все еще работают должным образом; после объединения новых изменений кода. Обычно им требуется 5 - 10 минут, чтобы быстрее получать информацию о сбоях.
Регрессионные тесты
Обычно они запускаются не реже одного раза в день и охватывают различные функции системы. Они гарантируют, что приложение по-прежнему работает должным образом. Они содержат больше деталей, чем дымовые тесты, и охватывают больше сценариев приложения, включая некритичные.
РЕГРЕССИЯ
"Регрессионный тест повторно запускает предыдущие тесты с измененным программным обеспечением, чтобы убедиться, что изменения, внесенные в текущее программное обеспечение, не влияют на функциональность существующего программного обеспечения".
- Интеграционное тестирование: интеграционное тестирование - это еще один элемент интеграции
- Тестирование дыма: Тестирование дыма также называется версией сборки. Тестирование дыма - это начальный процесс тестирования, выполняемый для проверки готовности / стабильности тестируемого программного обеспечения для дальнейшего тестирования.
- Регрессионное тестирование: Регрессионное тестирование - это повторное тестирование. Внедрено ли новое программное обеспечение в другой модуль или нет.
- Модульное тестирование: это тестирование белого ящика. В нем участвуют только разработчики
Модульное тестирование направлено на наименьшую возможную реализацию. В Java это означает, что вы тестируете один класс. Если класс зависит от других классов, они являются поддельными.
Когда ваш тест вызывает более одного класса, это интеграционный тест.
Полные комплекты тестов могут занять много времени, поэтому после изменения многие команды проводят быстрые тесты для выявления значительных поломок. Например, вы взломали URI для основных ресурсов. Это тесты на дым.
Регрессионные тесты выполняются на каждой сборке и позволяют эффективно проводить рефакторинг, отслеживая то, что вы сломали Любой вид теста может быть регрессионным, но я считаю, что юнит-тесты наиболее полезны для поиска источника ошибки.
Одним из типов тестов, который, по-видимому, стоит упомянуть в этом потоке, являются стресс-тесты / тесты производительности / нагрузки, которые можно просто определить как выяснение пределов, за пределами которых нарушается определенная часть программного обеспечения. Обратите внимание, что с точки зрения инструментов важно точно определить объем того, что предлагается для стресс-тестов с точки зрения системы. Например, в случае "веб-приложения" стресс-тестирование может включать в себя само приложение веб-сервера, и поэтому инструменты могут вмешиваться с этой целью. Вот хороший пост о нагрузочном тестировании http
Проверка дыма и работоспособность выполняются после сборки программного обеспечения, чтобы определить, стоит ли начинать тестирование. Разумность может быть или не может быть выполнена после тестирования дыма. Они могут быть выполнены по отдельности или в одно и то же время - здравомыслие сразу после дыма.
Поскольку тестирование работоспособности является более глубоким и занимает больше времени, в большинстве случаев оно хорошо подходит для автоматизации.
Дымовое тестирование обычно занимает не более 5-30 минут для выполнения. Он носит более общий характер: он проверяет небольшое количество основных функциональных возможностей всей системы, чтобы убедиться, что стабильность программного обеспечения достаточно хороша для дальнейшего тестирования и что нет проблем, блокирующих выполнение запланированных тестовых случаев.
Проверка работоспособности более детальная, чем дым, и может занять от 15 минут до целого дня, в зависимости от масштаба новой сборки. Это более специализированный тип приемочного тестирования, выполняемый после прохождения или повторного тестирования. Он проверяет основные функции некоторых новых функций и / или исправлений ошибок, а также некоторые тесно связанные с ними функции, чтобы убедиться, что они функционируют в соответствии с требуемой операционной логикой, прежде чем регрессионное тестирование может быть выполнено в более широком масштабе.
Модульный тест: проверка того, что конкретный компонент (т. Е. Класс) создал или изменил функции в соответствии с назначением. Этот тест может быть ручным или автоматическим, но не выходит за пределы компонента.
Интеграционный тест: проверка того, что взаимодействие отдельных компонентов функционирует так, как задумано. Интеграционные тесты могут выполняться на уровне устройства или на уровне системы. Эти тесты могут быть ручными или автоматизированными.
Регрессионный тест: проверка того, что новые дефекты не внесены в существующий код. Эти тесты могут быть ручными или автоматизированными.
В зависимости от вашего SDLC (водопад, разрыв, гибкость и т. Д.) Конкретные тесты могут выполняться поэтапно или могут выполняться более или менее одновременно. Например, модульное тестирование может быть ограничено разработчиками, которые затем передают код тестерам для интеграции и регрессионного тестирования. Однако другой подход может заключаться в том, что разработчики проводят модульное тестирование и некоторый уровень интеграции и регрессионного тестирования (используя подход TDD наряду с непрерывной интеграцией и автоматизированными модульными и регрессионными тестами).
Модульное тестирование:- Модульное тестирование обычно выполняется на стороне разработчиков, так как тестеры частично развиваются в этом типе тестирования, где тестирование проводится по частям. В java тестовых случаях Junit также можно проверить, идеально ли написан код или нет.
Интеграционное тестирование:- Этот тип тестирования возможен после модульного тестирования, когда все / некоторые компоненты интегрированы. Этот тип тестирования будет гарантировать, что, когда компоненты интегрированы, они влияют друг на друга на рабочие возможности или функционеров.
Тестирование дыма:- Этот тип тестирования выполняется в последний раз, когда система успешно интегрирована и готова к работе на рабочем сервере. Этот тип тестирования будет гарантировать, что все важные функции от начала до конца работают нормально и система готова к развертыванию на рабочем сервере.
Регрессионное тестирование:- Этот тип тестирования важен для проверки того, что непреднамеренные / нежелательные дефекты отсутствуют в системе, когда разработчик исправил некоторые проблемы. Это тестирование также гарантирует, что все ошибки успешно устранены, и поэтому никаких других проблем не возникло.
Модульное тестирование: разработчик всегда выполняет разработчик, чтобы выяснить проблему со стороны тестирования до того, как он подготовит какое-либо требование для обеспечения качества.
Интеграционное тестирование: это означает, что тестер должен проверять верификацию модуля к субмодулю, когда некоторые выходные данные / функции передаются от одного модуля к другому модулю. Или в вашей системе, если вы используете сторонний инструмент, который использует ваши системные данные для интеграции.
Тестирование дыма: тестер выполнил проверку системы для высокоуровневого тестирования и попытался определить ошибку show stoppper до того, как изменения или код вступят в действие.
Регрессионное тестирование: Тестер выполнил регрессию для проверки существующей функциональности в связи с изменениями, внесенными в систему для нового улучшения или изменениями в системе.
Регрессионный тест - это тип SW-тестирования, в котором мы пытаемся скрыть или проверить исправление ошибки. функциональность вокруг исправления ошибки не должна изменяться или изменяться из-за предоставленного исправления. Проблемы, обнаруженные в таком процессе, называются проблемами регрессии.
Тестирование дыма: это своего рода тестирование, чтобы решить, принимать ли сборку / программное обеспечение для дальнейшего тестирования качества.
Модульное тестирование:
Модульное тестирование - это процесс разработки программного обеспечения, при котором самые маленькие тестируемые части приложения, называемые блоками, индивидуально и независимо проверяются на предмет правильной работы. Модульное тестирование часто автоматизировано, но его также можно выполнить вручную.
Интеграционное тестирование:
(иногда называемый интеграцией и тестированием, сокращенно I&T) - это фаза тестирования программного обеспечения, в которой отдельные программные модули объединяются и тестируются как группа. Это происходит после модульного тестирования и перед проверочным тестированием.
Тестирование системы:
Чаще всего это последний тест для проверки того, что поставляемая система соответствует спецификации и ее назначению.
Регрессионный тест:
после реализации новых функций или исправления ошибок вы повторно тестируете сценарии, которые работали в прошлом. Здесь вы раскрываете возможность, в которой ваши новые функции нарушают существующие функции.
Тестирование дыма:
Задача состоит не в том, чтобы провести исчерпывающее тестирование, а в том, чтобы убедиться, что критические функции системы работают нормально. Например, типичным тестом на дым является - Убедитесь, что приложение успешно запускается, Проверьте, что графический интерфейс реагирует, и т. Д.
Тест дыма уже объяснен здесь и прост. Регрессионный тест проходит интеграционный тест.
Автоматизированные тесты можно разделить только на 2.
Модульный тест и интеграционный тест. (это все, что имеет значение)
Я бы назвал использование фразы "длинный тест"(LT) для всех тестов, таких как интеграционный тест, функциональный тест, регрессионный тест, тест пользовательского интерфейса и т. Д. И модульный тест как "короткий тест".
Примером LT может быть автоматическая загрузка веб-страницы, вход в учетную запись и покупка книги. Если тест пройден, он, скорее всего, будет работать на работающем сайте таким же образом (отсюда и ссылка "лучший сон"). Long = расстояние между веб-страницей (начало) и базой данных (конец).
И это отличная статья, в которой обсуждаются преимущества интеграционного тестирования (длительного тестирования) по сравнению с модульным тестированием.
Некоторые хорошие ответы уже есть, но я хотел бы уточнить их:
Модульное тестирование является единственной формой тестирования белого ящика здесь. Остальные тестируют черный ящик. Тестирование белого ящика означает, что вы знаете входные данные, вы знаете внутреннюю работу механизма и можете проверить его, а также знаете выходные данные. При тестировании черного ящика вы знаете только, что является входным сигналом и каким должен быть выход.
Поэтому очевидно, что модульное тестирование - единственное тестирование белого ящика.
- Модульное тестирование тестирует определенные фрагменты кода. Обычно методы.
- Интеграционное тестирование позволяет проверить, может ли ваша новая функциональная часть программного обеспечения интегрироваться со всем остальным.
- Регрессионное тестирование. Это тестирование сделано, чтобы убедиться, что вы ничего не сломали. Все, что раньше работало, должно работать.
- Дымовое тестирование проводится как быстрый тест, чтобы убедиться, что все выглядит хорошо, прежде чем приступить к более активному тестированию.
Модульные тесты Модульные тесты очень низкого уровня, близки к источнику вашего приложения. Они состоят в тестировании отдельных методов и функций классов, компонентов или модулей, используемых вашим программным обеспечением. Модульные тесты, как правило, довольно дешевы для автоматизации и могут быть очень быстро запущены сервером непрерывной интеграции.
Интеграционные тесты Интеграционные тесты проверяют, что различные модули или сервисы, используемые вашим приложением, хорошо работают вместе. Например, это может быть проверка взаимодействия с базой данных или проверка совместимости микросервисов в соответствии с ожиданиями. Эти типы тестов более дороги в запуске, так как требуют, чтобы несколько частей приложения были запущены и работали.
Функциональные тесты Функциональные тесты фокусируются на бизнес-требованиях приложения. Они только проверяют вывод действия и не проверяют промежуточные состояния системы при выполнении этого действия.
Иногда возникает путаница между интеграционными тестами и функциональными тестами, поскольку для обоих требуется взаимодействие нескольких компонентов. Разница в том, что интеграционный тест может просто проверить, что вы можете запрашивать базу данных, в то время как функциональный тест будет ожидать получения определенного значения из базы данных, как это определено требованиями продукта.
Сквозное тестирование Сквозное тестирование копирует поведение пользователя с программным обеспечением в полной прикладной среде. Он проверяет, что различные пользовательские потоки работают должным образом и могут быть такими простыми, как загрузка веб-страницы или вход в систему, или гораздо более сложные сценарии проверки почтовых уведомлений, онлайн-платежей и т. Д.
Сквозные тесты очень полезны, но они дорогостоящие и их сложно поддерживать, когда они автоматизированы. Рекомендуется провести несколько ключевых сквозных тестов и больше полагаться на тесты более низкого уровня (модульные и интеграционные тесты), чтобы иметь возможность быстро выявлять критические изменения.
Приемочные испытания Приемочные испытания - это формальные испытания, выполняемые для проверки того, удовлетворяет ли система своим бизнес-требованиям. Они требуют, чтобы все приложение было запущено и работало и фокусировалось на репликации поведения пользователя. Но они также могут пойти дальше и измерить производительность системы и отклонить изменения, если определенные цели не достигнуты.
Тестирование производительности Тесты производительности проверяют поведение системы, когда она находится под значительной нагрузкой. Эти тесты не работают и могут иметь различную форму, чтобы понять надежность, стабильность и доступность платформы. Например, это может быть наблюдение за временем отклика при выполнении большого количества запросов или наблюдение за тем, как система ведет себя со значительными данными.
Тесты производительности по своей природе довольно дороги для внедрения и запуска, но они могут помочь вам понять, не повлияют ли новые изменения на вашу систему.
Тесты дыма Тесты дыма - это базовые тесты, которые проверяют основные функциональные возможности приложения. Они предназначены для быстрого выполнения, и их цель - дать вам уверенность в том, что основные функции вашей системы работают как положено.
Дымовые тесты могут быть полезны сразу после создания новой сборки, чтобы решить, можно ли запускать более дорогие тесты, или сразу после развертывания, чтобы убедиться, что их приложение работает правильно во вновь развернутой среде.
источник: https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing
Там было очень подробно различие между различными методами испытаний. Тем не менее, очень мало затронуло инструменты тестирования дыма или регрессионного теста.
Обычно, есть некоторые фреймворки в сочетании с языком / фреймворком, который использовался для разработки приложения. Разработав Angular, транспортир может быть хорошим выбором, для Java огурец или аркилиан могут быть другим выбором. В целом, чем больше языков / рамок, тем больше у вас есть выбора. Либо это?.
Я лично верил в декларативный язык, который подходит для всех языков и платформ для тестирования от начала до конца.
Endly - это самая первая сквозная среда тестирования и автоматизации, полностью декларативная, ее можно использовать в любых языковых тестах.
Упрощенно.
Модульное тестирование: тестирование отдельного фрагмента кода, алгоритма, класса или системы. Этот тест должен быть независимым, а зависимости должны быть смоделированы или заглушены.
Интеграционный тест: должен проверять, хорошо ли работают компонент, алгоритм, класс или система при использовании другими компонентами. Интеграционные тесты предназначены не для проверки работы (поведения) системы, а для проверки работоспособности системы.
Тест дыма: это очень маленький набор тестов, который должен сначала выполнить большой набор тестов, он просто гарантирует, что самые важные функции системы будут работать даже после обновления.
Регрессионный тест: это процесс тестирования изменений в компьютерных программах, чтобы убедиться, что старое программирование все еще работает с новыми изменениями. Это больший набор тестов, чем тесты дыма.
Если вы хотите узнать больше об интеграционном тесте, вы можете пройти этот курс в Udemy, он имеет хорошую скидку.
https://www.udemy.com/testes-de-integracao-com-spring-boot/?couponCode=TISB_ODESC2019