Что такое Unit test, Integration Test, Smoke test, регрессионный тест и каковы различия между ними? И какие инструменты я могу использовать для каждого из них?
Например, я использую JUnit и NUnit для тестирования модулей и тестирования интеграции. Существуют ли инструменты Smoke Test или регрессионного тестирования?
Unit тест: Укажите и протестируйте одну точку контракта одного метода класса. Это должно иметь очень узкую и четко определенную область применения. Сложные зависимости и взаимодействия с внешним миром являются заглушкой или насмешкой.
Интеграционный тест: проверить правильность взаимодействия нескольких подсистем. Там есть целый спектр, от тестирования интеграции между двумя классами до тестирования интеграции с производственной средой.
Дымовой тест (он же Sanity check): простой интеграционный тест, в котором мы просто проверяем, что при вызове тестируемой системы она возвращается нормально и не взрывается.
Регрессионный тест: тест, который был написан, когда ошибка была исправлена. Это гарантирует, что эта конкретная ошибка не возникнет снова. Полное название "Нерегрессионный тест". Это также может быть тест, выполненный до изменения приложения, чтобы убедиться, что приложение дает тот же результат.
К этому я добавлю:
Приемочный тест: проверка правильности реализации функции или варианта использования. Это похоже на интеграционный тест, но с акцентом на сценарии использования, а не на задействованные компоненты.
Системный тест: тестирует систему как черный ящик. Зависимости в других системах во время теста часто высмеиваются или заглушаются (иначе это было бы скорее интеграционным тестом).
Проверка перед полетом: тесты, которые повторяются в производственной среде, чтобы облегчить синдром "сборки на моей машине". Зачастую это достигается путем проведения приемочного или дымового испытания в производственной среде.
У каждого будут несколько разные определения, и часто есть серые области. Однако:
Новая тестовая категория, о которой я только что узнал, это:
Примеры могут быть:
апокрифические исторические мелочи: "тестирование дыма" происходит от инженерной подводной лодки (унаследованной от сантехники), где буквальный дым будет закачан в корпус, чтобы проверить, не вышло ли какое-либо из них, что было бы скорее драматическим сбоем для подводной лодки!
Ответ с одного из лучших сайтов по методам тестирования программного обеспечения:
Типы тестирования программного обеспечения - Полный список Нажмите здесь
Это довольно длинное описание, я не собираюсь его вставлять здесь, но оно может быть полезно для тех, кто хочет знать все методы тестирования.
Надеюсь, это будет полезно :)
Unit test: проверка того, что определенный компонент (т.е. класс) создал или изменил функции, как было разработано. Этот тест может быть ручным или автоматическим, но не выходит за границы компонента.
Тестирование интеграции: проверка того, что взаимодействие конкретных компонентов функционирует так, как было разработано. Интеграционные тесты могут выполняться на уровне устройства или на уровне системы. Эти тесты могут быть ручными или автоматическими.
Тест регрессии: проверка наличия новых дефектов в существующем коде. Эти тесты могут быть ручными или автоматическими.
В зависимости от вашего SDLC (водопад, rup, agile и т.д.) конкретные тесты могут выполняться в "фазах" или все они могут выполняться в более или менее одновременно. Например, модульное тестирование может быть ограничено разработчиками, которые затем передают код тестировщикам для тестирования интеграции и регрессии. Однако другой подход может заставить разработчиков выполнить единичное тестирование и некоторый уровень интеграции и регрессионного тестирования (с использованием подхода TDD наряду с непрерывной интеграцией и автоматическими блочными и регрессионными тестами).
Набор инструментов будет во многом зависеть от кодовой базы, но есть много инструментов с открытым исходным кодом для модульного тестирования (JUnit). HP (ртуть) QTP или Borland Silktest являются одновременно инструментами для автоматической интеграции и регрессионного тестирования.
unit test: тестирование отдельного модуля или независимого компонента в приложении, как известно, является модульным тестированием, модульное тестирование будет выполняться разработчиком.
интеграционный тест: объединение всех модулей и тестирование приложения для проверки связи и потока данных между модулями работают нормально или нет, это тестирование также выполняется разработчиками.
smoke test IN smoke test они проверяют приложение на мелкой и широкой основе. При тестировании дыма проверяют основные функции приложения, если в приложении есть какая-либо проблема с блокировщиками, они будут сообщать команде разработчиков, а команда разработчиков исправит ее и устранит дефект и вернет ее команде тестирования, и теперь группа тестирования проверит все модули, чтобы проверить, что изменения тата, сделанные в одном модуле, повлияют на другой модуль или нет. В ИСПЫТАНИИ КУРЕНИЯ тестовые примеры написаны сценарием
регрессионное тестирование повторяется несколько раз, чтобы гарантировать, что неизменный модуль не вызывает никаких дефектов. ТЕСТИРОВАНИЕ РЕГРЕССИИ входит в функциональное тестирование
"Тест регрессии повторяет предыдущие тесты с измененным программным обеспечением, чтобы гарантировать, что изменения, внесенные в текущее программное обеспечение, не влияют на функциональность существующего программного обеспечения".
Единичное тестирование направлено на наименьшую часть возможной реализации. В java это означает, что вы тестируете один класс. Если класс зависит от других классов, они подделываются.
Когда ваш тест вызывает более одного класса, его тест интеграции.
Полные комплекты тестов могут занять много времени, поэтому после изменения многие команды проводят несколько быстрых тестов для выявления значительных поломки. Например, вы нарушили URI для основных ресурсов. Это тесты дыма.
Регрессионные тесты выполняются на каждой сборке и позволяют эффективно реорганизовать, поймав то, что вы нарушаете. Любой тип теста может быть регрессионным тестом, но я считаю, что тесты модулей наиболее полезны для поиска источника ошибки.
Unit test: проверка того, что определенный компонент (т.е. класс) создал или изменил функции, как было разработано. Этот тест может быть ручным или автоматическим, но не выходит за границы компонента.
Тестирование интеграции: проверка того, что взаимодействие конкретных компонентов функционирует так, как было разработано. Интеграционные тесты могут выполняться на уровне устройства или на уровне системы. Эти тесты могут быть ручными или автоматическими.
Тест регрессии: проверка наличия новых дефектов в существующем коде. Эти тесты могут быть ручными или автоматическими.
В зависимости от вашего SDLC (водопад, rup, agile и т.д.) конкретные тесты могут выполняться в "фазах" или все они могут выполняться в более или менее одновременно. Например, модульное тестирование может быть ограничено разработчиками, которые затем передают код тестировщикам для тестирования интеграции и регрессии. Однако другой подход может заставить разработчиков выполнить единичное тестирование и некоторый уровень интеграции и регрессионного тестирования (с использованием подхода TDD наряду с непрерывной интеграцией и автоматическими блочными и регрессионными тестами).
Одним типом теста, который, по-видимому, стоит упомянуть в этом потоке, являются тесты на стресс/производительность/загрузка, которые можно просто поставить как выяснение пределов, за которыми ломается определенный фрагмент программного обеспечения. Обратите внимание, что с точки зрения оснастки важно точно определить масштаб того, что предлагается подвергнуть испытаниям с точки зрения системы. Например, в случае "веб-приложения" стресс-тестирование может включать в свой объем приложение веб-сервера, и поэтому инструмент может вмешаться с этой целью. Вот хороший пост о HTTP load testing
Единичное тестирование: - модульное тестирование обычно выполняется стороной разработчиков, где, поскольку тестеры частично развиваются в этом типе тестирования, где тестирование выполняется по единице. В java-тестах Junit также можно проверить, правильно ли написан письменный код или нет.
Тестирование интеграции: - Этот тип тестирования возможен после тестирования модуля, когда все/некоторые компоненты интегрированы. Этот тип тестирования гарантирует, что когда компоненты будут интегрированы, они влияют на работу других рабочих или функционалистов.
Тестирование дыма: - Этот тип тестирования выполняется в последний раз, когда система успешно интегрирована и готова к работе на производственном сервере. Этот тип тестирования гарантирует, что каждая важная функциональность от начала до конца работает нормально, и система готова к развертыванию на рабочем сервере.
Регрессионное тестирование: - Этот тип тестирования важен для проверки того, что непреднамеренные/нежелательные дефекты отсутствуют в системе, когда разработчик исправил некоторые проблемы. Это тестирование также гарантирует, что все ошибки будут успешно решены, и из-за этого не возникает никаких других проблем.
Unit Testing: он всегда выполняет разработчик после их разработки, чтобы выяснить проблему с их стороны тестирования, прежде чем они готовят любые требования к QA.
Тестирование интеграции: это означает, что тестировщик должен проверить модуль на подтверждение подкомплекта, когда какой-либо вывод данных/функций подключается к одному модулю к другому модулю. Или в вашей системе, если вы используете сторонний инструмент, который использует ваши системные данные для интеграции.
Тестирование дыма: тестер, выполненный для проверки системы для высокоуровневого тестирования и попытки обнаружить ошибку стоп-шоу до того, как изменения или код выйдет в прямом эфире.
Регрессионное тестирование: Тестер выполнил регрессию для проверки существующей функциональности из-за изменений, реализованных в системе для нового улучшения или изменений в системе.
Тестирование на дым и здравомыслие выполняются после сборки программного обеспечения, чтобы определить, следует ли начинать тестирование. Благополучие может быть или не быть выполнено после тестирования дыма. Они могут выполняться отдельно или в одно и то же время - здравомыслие сразу после курения.
Поскольку тестирование на чувствительность является более глубоким и занимает больше времени, в большинстве случаев оно хорошо автоматизировано.
Тестирование дыма обычно занимает не более 5-30 минут для выполнения. Он более общий: он проверяет небольшое количество основных функциональных возможностей всей системы, чтобы убедиться, что стабильность программного обеспечения достаточно хороша для дальнейшего тестирования и что нет проблем, блокирующих запуск запланированных тестовых случаев.
Испытание на чувствительность более подробно, чем дым, и может занять от 15 минут до целого дня, в зависимости от масштаба новой сборки. Это более специализированный тип приемочных испытаний, выполняемый после прогрессирования или повторного тестирования. Он проверяет основные функции некоторых новых функциональных возможностей и/или исправлений ошибок вместе с некоторыми тесно связанными с ними функциями, чтобы убедиться, что они функционируют в отношении требуемой оперативной логики, прежде чем регрессионное тестирование может быть выполнено в более крупном масштабе.
Я просто хотел добавить и дать больше контекста о том, почему у нас есть эти уровни тестирования, что они действительно имеют в виду с примерами
Майк Кон в своей книге "Успех с Agile" придумал "Пирамиду тестирования" как способ приблизиться к автоматизированным тестам в проектах. Существуют различные интерпретации этой модели. Модель объясняет, какие виды автоматических тестов необходимо создавать, как быстро они могут дать отзыв о тестируемом приложении и кто пишет эти тесты. В принципе, для любого проекта необходимо 3 уровня автоматического тестирования.
Единица измерения Tests- Они тестируют самый маленький компонент вашего программного приложения. Это может быть буквально одна функция в коде, которая вычисляет значение на основе некоторых входных данных. Эта функция является частью ряда других функций аппаратной/программной кодовой базы, составляющей приложение.
Например - Давайте возьмем веб-приложение калькулятора. Наименьшими компонентами этого приложения, которые должны быть проверены модулем, может быть функция, которая выполняет сложение, другая функция, которая выполняет вычитание и так далее. Все эти маленькие функции вместе взятые составляют приложение калькулятора.
Исторически разработчик пишет эти тесты, так как они обычно пишутся на том же языке программирования, что и программное приложение. Для этой цели используются модули модульного тестирования, такие как JUnit и NUnit (для java), MSTest (для С# и .NET) и Jasmine/Mocha (для JavaScript).
Самым большим преимуществом модульных тестов является то, что они работают очень быстро под пользовательским интерфейсом, и мы можем быстро получить отзыв о приложении. Это должно составлять более 50% ваших автоматических тестов.
API/интеграция Tests- Они тестируют различные компоненты системы программного обеспечения вместе. Компоненты могут включать тестирование баз данных, API (интерфейс прикладного программирования), сторонних инструментов и сервисов вместе с приложением.
Например - в нашем примере калькулятора, приведенном выше, веб-приложение может использовать базу данных для хранения значений, использовать API для выполнения некоторых проверок на стороне сервера и может использовать сторонний инструмент/службу для публикации результатов в облаке, чтобы сделать их доступными для разных платформы.
Исторически разработчик или технический QA писал бы эти тесты, используя различные инструменты, такие как Postman, SoapUI, JMeter и другие инструменты, такие как Testim.
Они выполняются намного быстрее, чем тесты пользовательского интерфейса, поскольку они все еще выполняются под капотом, но могут потребовать немного больше времени, чем модульные тесты, поскольку он должен проверять связь между различными независимыми компонентами системы и обеспечивать их бесшовную интеграцию. Это должно составлять более 30% автоматизированных тестов.
Пользовательский интерфейс Tests- Наконец, у нас есть тесты, которые проверяют пользовательский интерфейс приложения. Эти тесты обычно пишутся для тестирования сквозных потоков через приложение.
Например - В приложении калькулятора сквозной поток может быть следующим: browser-> Ввод URL-адреса приложения калькулятора → Вход в систему с именем пользователя/паролем → Открытие приложения калькулятора → Выполнение некоторых операций над калькулятор → проверка этих результатов из пользовательского интерфейса → выход из приложения. Это может быть сквозной поток, который будет хорошим кандидатом для автоматизации пользовательского интерфейса.
Исторически, технические QA или ручные тестеры пишут тесты пользовательского интерфейса. Они используют платформы с открытым исходным кодом, такие как Selenium или платформы тестирования пользовательского интерфейса, такие как Testim, для создания, выполнения и сопровождения тестов. Эти тесты дают больше визуальной обратной связи, поскольку вы можете увидеть, как проходят тесты, разницу между ожидаемыми и фактическими результатами с помощью скриншотов, журналов, отчетов о тестах.
Самое большое ограничение тестов пользовательского интерфейса, они относительно медленны по сравнению с тестами уровня и уровня API. Таким образом, он должен составлять всего 10-20% от общего количества автоматизированных тестов.
Следующие два типа тестов могут различаться в зависимости от вашего проекта, но идея is-
Тесты дыма
Это может быть комбинацией вышеуказанных 3 уровней тестирования. Идея состоит в том, чтобы запускать его во время каждой регистрации кода и гарантировать, что критические функции системы по-прежнему работают должным образом; после изменения нового кода объединяются. Как правило, они должны работать в течение 5–10 минут, чтобы получать более быстрые отзывы о сбоях
Регрессионные тесты
Они обычно запускаются как минимум раз в день и охватывают различные функции системы. Они гарантируют, что приложение все еще работает как ожидалось. Они более подробны, чем дымовые тесты, и охватывают больше сценариев применения, включая некритические.
Некоторые хорошие ответы уже есть, но я бы хотел их уточнить:
Единичное тестирование - единственная форма тестирования белого ящика. Другие - тестирование черного ящика. Проверка белого ящика означает, что вы знаете ввод, вы знаете внутреннюю работу механизма и можете его проверить, и вы знаете результат. При тестировании черного ящика вы знаете только, что такое вход и какой должен быть результат.
Так ясно, что единичное тестирование является единственным тестированием белого ящика здесь.
Регрессионный тест - это тип тестирования ПО, в котором мы пытаемся покрыть или проверить ошибку. функциональность вокруг исправления ошибок не должна изменяться или изменяться из-за предоставленного Fix. Проблемы, обнаруженные в этом процессе, называются регрессионными проблемами.
Тестирование дыма: проводится ли какое-либо тестирование, чтобы решить, следует ли принимать Build/Software для дальнейшего тестирования QA.
Тест дыма уже объяснен здесь и прост. Регрессионный тест проходит интеграционный тест.
Автоматизированные тесты можно разделить только на 2.
Unit тест и интеграционный тест. (это все, что имеет значение)
Я бы назвал фразу "длинный тест" (LT) для всех тестов, таких как интеграционный тест, функциональный тест, регрессионный тест, тестирование пользовательского интерфейса и т.д. И unit тест, как "короткий тест".
Примером LT может быть автоматическая загрузка веб-страницы, вход в учетную запись и покупка книги. Если тест пройден, он, скорее всего, будет работать на работающем сайте таким же образом (отсюда и ссылка "лучший сон"). Long = расстояние между веб-страницей (начало) и базой данных (конец).
И это отличная статья, в которой обсуждаются преимущества интеграционного тестирования (длительного тестирования) перед модульным тестированием.
Модульные тесты Модульные тесты очень низкого уровня, близки к источнику вашего приложения. Они состоят в тестировании отдельных методов и функций классов, компонентов или модулей, используемых вашим программным обеспечением. Модульные тесты, как правило, довольно дешевы для автоматизации и могут быть очень быстро запущены сервером непрерывной интеграции.
Интеграционные тесты Интеграционные тесты проверяют, что различные модули или сервисы, используемые вашим приложением, хорошо работают вместе. Например, это может быть проверка взаимодействия с базой данных или проверка совместимости микросервисов в соответствии с ожиданиями. Эти типы тестов более дороги в запуске, так как требуют, чтобы несколько частей приложения были запущены и работали.
Функциональные тесты Функциональные тесты фокусируются на бизнес-требованиях приложения. Они только проверяют вывод действия и не проверяют промежуточные состояния системы при выполнении этого действия.
Иногда возникает путаница между интеграционными тестами и функциональными тестами, поскольку для обоих требуется взаимодействие нескольких компонентов. Разница в том, что интеграционный тест может просто проверить, что вы можете запрашивать базу данных, в то время как функциональный тест будет ожидать получения конкретного значения из базы данных, как это определено требованиями продукта.
Сквозные тесты Сквозное тестирование копирует поведение пользователя с программным обеспечением в полной прикладной среде. Он проверяет, что различные пользовательские потоки работают должным образом и могут быть такими простыми, как загрузка веб-страницы или вход в систему, или гораздо более сложные сценарии проверки почтовых уведомлений, онлайн-платежей и т.д.
Сквозные тесты очень полезны, но они дорогостоящие, и их трудно поддерживать, когда они автоматизированы. Рекомендуется провести несколько ключевых сквозных тестов и больше полагаться на тесты более низкого уровня (модульные и интеграционные тесты), чтобы иметь возможность быстро выявлять критические изменения.
Приемочное тестирование Приемочные тесты - это формальные тесты, выполняемые для проверки соответствия системы бизнес-требованиям. Они требуют, чтобы все приложение было запущено и работало и фокусировалось на репликации поведения пользователя. Но они также могут пойти дальше и измерить производительность системы и отклонить изменения, если определенные цели не достигнуты.
Тестирование производительности Тесты производительности проверяют поведение системы, когда она находится под значительной нагрузкой. Эти тесты не работают и могут иметь различную форму для понимания надежности, стабильности и доступности платформы. Например, это может быть наблюдение за временем отклика при выполнении большого количества запросов или наблюдение за тем, как система ведет себя со значительными данными.
Тесты производительности по своей природе довольно дороги для внедрения и запуска, но они могут помочь вам понять, не повлияют ли новые изменения на вашу систему.
Тесты дыма Тесты дыма - это базовые тесты, которые проверяют основные функциональные возможности приложения. Они предназначены для быстрого выполнения, и их цель - дать вам уверенность в том, что основные функции вашей системы работают как положено.
Дымовые тесты могут быть полезны сразу после создания новой сборки, чтобы решить, можете ли вы запускать более дорогие тесты, или сразу после развертывания, чтобы убедиться, что их приложение работает правильно во вновь развернутой среде.
источник: https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing
Упрощенно.
Модульное тестирование: тестирование отдельного фрагмента кода, алгоритма, класса или системы. Этот тест должен быть независимым, а зависимости должны быть смоделированы или заглушены.
Интеграционный тест: должен проверять, хорошо ли работают компонент, алгоритм, класс или система при использовании другими компонентами. Интеграционные тесты предназначены не для проверки работы (поведения) системы, а для проверки работоспособности системы.
Дымовой тест: Это очень маленький набор тестов, который должен сначала выполнять большой набор тестов, он просто гарантирует, что самые важные функции системы будут работать даже после обновления.
Регрессионный тест: это процесс тестирования изменений в компьютерных программах, чтобы убедиться, что старое программирование все еще работает с новыми изменениями. Это больший набор тестов, чем тесты дыма.
Если вы хотите узнать больше об интеграционном тесте, вы можете пройти этот курс в Udemy, он имеет хорошую скидку.
https://www.udemy.com/testes-de-integracao-com-spring-boot/?couponCode=TISB_ODESC2019
Тестирование устройств:
Модульное тестирование - это процесс разработки программного обеспечения, в котором наименьшие тестируемые части приложения, называемые единицами, индивидуально и независимо проверяются для правильной работы. Модульное тестирование часто автоматизировано, но его также можно выполнять вручную.
Интеграционное тестирование:
(иногда называемый интеграцией и тестированием, сокращенный я & T) является фазой тестирования программного обеспечения, в которой отдельные программные модули объединяются и тестируются как группа. Это происходит после модульного тестирования и перед проверкой проверки.
Тестирование системы:
чаще всего является окончательным испытанием для проверки того, что поставляемая система соответствует спецификации и ее назначению.
Тест регрессии:
после внедрения новых функций или исправлений ошибок, вы повторно проверяете сценарии, которые работали в прошлом. Здесь вы раскрываете возможность, в которой ваши новые функции нарушают существующие функции.
Тестирование дыма:
Целью является не выполнение исчерпывающего тестирования, а проверка работоспособности критических функциональных возможностей системы. Например, типичный smoke test будет: - Убедитесь, что приложение успешно запущено, проверьте, что графический интерфейс реагирует и т.д.