Что такое модульный тест, Интеграционный тест, Smoke-тест, Регрессионный тест?

https://stackoverflow.com/questions/520064

21-08-2019
|

Вопрос

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

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

Решение

Модульный тест:Укажите и протестируйте один пункт контракта для единственного метода класса.Это должно иметь очень узкую и четко определенную сферу применения.Сложные зависимости и взаимодействия с внешним миром - это оскорбленный или высмеянный.
Интеграционный тест:Проверьте правильность взаимодействия нескольких подсистем.Там представлен весь спектр, от тестирования интеграции между двумя классами до тестирования интеграции с производственной средой.
Тест на курение (он же проверка на вменяемость):Простой интеграционный тест, в котором мы просто проверяем, что при вызове тестируемой системы она возвращается нормально и не взрывается.
- Проверка на задымление - это аналогия с электроникой, где первая проверка проводится при включении питания в цепь (если она дымит, это плохо!)...
- ...и, очевидно, с сантехника, где система труб буквально заполняется дымом, а затем проверяется визуально.Если что-то дымится, значит, система негерметична.
Регрессионный тест:Тест, который был написан, когда была исправлена ошибка.Это гарантирует, что эта конкретная ошибка больше не повторится.Полное название - "нерегрессионный тест".Это также может быть тест, проведенный перед изменением приложения, чтобы убедиться, что приложение обеспечивает тот же результат.

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

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

Другие советы

Модульный тест: Автоматический тест для проверки внутренней работы класса. Это должен быть отдельный тест, который не связан с другими ресурсами.
Интеграционный тест: Автоматический тест, который проводится в среде, так же аналогично модульным тестам, но с внешними ресурсами (DB, доступ к диску)
Регрессионный тест: После реализации новых функций или исправлений ошибок вы повторно испытываете сценарии, которые работали в прошлом. Здесь вы охватываете возможность, когда ваши новые функции ломают существующие функции.
Тестирование дыма: Первые тесты, на которых тестировщики могут сделать вывод, будут ли они продолжать тестирование.

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

Единый тест: работает ли это немного (как можно более изолированным)?
Интеграционный тест: работают ли эти два (или более) компонента вместе?
Тест на дым: разумно ли эта система (как можно ближе к производственной системе) хорошо хорошо висит? (т.е. разумно ли мы уверены, что не создаст черную дыру?)
Регрессионный тест: Мы непреднамеренно внедрили какие-либо ошибки, которые мы ранее исправили?

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

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

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

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

Имеют данные, которые должны быть доступны только в Dev/Test, появились в Live.
Имеет фоновый процесс, не удалось запустить
Может ли вход в систему пользователя

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

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

Типы тестирования программного обеспечения - полный список Кликните сюда

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

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

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

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

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

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

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

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

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

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

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

Регрессионное тестирование-

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

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

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

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

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

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

Интеграционное тестирование: интеграционное тестирование - это интеграция другой элемент
Тестирование дыма: тестирование на дым также известно как тестирование версий сборки. Тестирование SMOKE - это начальный процесс тестирования, который осуществляется, чтобы проверить, готово ли тестирование программного обеспечения для тестирования/стабильнее для дальнейшего тестирования.
Регрессионное тестирование: регрессионное тестирование повторяется тестирование. Будет ли новое программное обеспечение в другом модуле или нет.
ЕДИНЦИОННЫЕ Тестирование: это белое тестирование. В нем участвуют только разработчики.

ЕДИНЦИОННЫЕ Тестирование:- Единое тестирование обычно проводится со стороны разработчиков, где в этом типе тестирования частично развиваются тестеры, где тестирование проводится блоком. В Java Junit тестовые примеры также могут быть возможны, чтобы проверить, является ли письменный код идеально разработан или нет.

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

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

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

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

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

Тестирование дыма: Тестер выполнялся для проверки системы для тестирования на высоком уровне и попытки выяснить ошибку Show Stopper, прежде чем изменения или код выйдут в эфир.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я просто хотел добавить и дать еще немного контекста о том, почему у нас есть эти уровни теста, что они действительно имеют в виду при примерах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тесты на дым

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow