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

Question

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

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

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

Answer 7

Упрощенно.

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

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

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

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

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

https://www.udemy.com/testes-de-integracao-com-spring-boot/?couponCode=TISB_ODESC2019

Answer 8

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

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

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

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

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

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

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

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

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

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

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

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

Answer 9

Испытание на дым уже объяснено здесь и является простым. Регрессионный тест проходит интеграционный тест.

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

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

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

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

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

Answer 10

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

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

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

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