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


732

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

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



2
Другие уже ответили хорошо, но я хотел бы добавить, что лично я считаю, что тесты дыма и тест регрессии являются излишними. Они делают то же самое: тестируют, чтобы убедиться, что изменения в системе ничего не сломали.
Рандольфо

15
Я думаю, что они сильно отличаются от регрессионных тестов. Я думаю, что это намеренно «легкие» быстрые тесты, которые запускаются в начале, чтобы сэкономить время, потому что, если какой-либо из них окажется неудачным, вы знаете, что не стоит беспокоиться о каком-либо дополнительном тестировании. Например, может ли клиент подключиться к базе данных, установлен ли .net, установлена ​​ли правильная версия ... Возможно, у вас также есть предварительное развертывание (мы обновляемся с версии v1 до версии 1.1, поэтому убедитесь, что версия v1 установлена) и после Развертывание дымовых испытаний.
AndyM

Дымовые тесты соответствуют описанию AndyM. Но они также являются типом регрессионного теста.
Кевин Макдоннелл

Ответы:


1044
  • Юнит-тест : Укажите и протестируйте одну точку контракта одного метода класса. Это должно иметь очень узкую и четко определенную область применения. Сложные зависимости и взаимодействия с внешним миром являются заглушкой или насмешкой .

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

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

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

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

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

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

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


250
Испытание дымом предшествует электронике на столетие и происходит от сантехники, когда система труб была заполнена настоящим дымом, а затем проверена визуально. Если он курил, это было дырявым.
SnakE

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

25
@AndyM Фон «Дымового теста» неточный. IIRC это происходит от водопровода, где дым выкачивается в систему труб после того, как он построен (и до того, как он подключен к водопроводу). При появлении дыма трубы не герметично закрыты. Это менее повреждает, чем фактически позволить воде течь и посмотреть, есть ли какие-либо лужи (возможно повреждение стен / кладки в процессе). Это грубое приближение, что система не потерпит катастрофического отказа. Процесс разработки может быть: «Сборка» пройдена? => «Дымовой тест» пройден? => «Приемочный тест» передан => команде QA для детального тестирования.
Кристиан Диаконеску

4
Я полагаю, вы допустили ошибку, заявив, что «Регрессионный тест» действительно сокращенно для «Нерегрессионного теста»? Я скептически отношусь, отчасти потому, что это просто не интуитивно и сбивает с толку (хотя есть много терминов, которые есть), но также в Википедии есть две отдельные статьи о регрессионных и нерегрессионных тестах. В статье о регрессионном тестировании даже говорится: « Контраст с нерегрессионным тестированием ... целью которого является проверка того, оказало ли изменение после введения или обновления определенного программного приложения ожидаемый эффект».
Брайан К

2
@ddaa Тестирование на здравомыслие и тестирование на дым не одно и то же. Проверка работоспособности выполняется после того, как сборка прошла тест Smoke и была принята командой QA для дальнейшего тестирования. Проверка работоспособности проверяет основные функциональные возможности с более мелкими деталями.
Бхарат

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

2
Определение регрессионного теста на самом деле не совсем так. @ddaa определяет это правильно.
Роберт Коритник

Определение Интеграционного теста определенно нечетко. Например, ответ здесь stackoverflow.com/a/4904533/32453 это более определено как тестирование нескольких взаимодействий вашего кода, не обязательно нуждающихся в реальной БД (внешнем ресурсе) ... хотя некоторые люди определяют это так, как вы описали ... ааа терминология. (Я немного предпочитаю предыдущее определение, FWIW, тестирование нескольких взаимодействий.)
rogerdpack

Пожалуйста, смотрите мой вопрос: stackoverflow.com/questions/61711739/…
milad salimi

Это соответствует названию, но не инструментам для последних двух типов тестов, для тестирования дыма или регрессионного тестирования .
Питер Мортенсен

90

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

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

Как вы размещаете свои интеграционные тесты относительно юнит-тестов? Если myprj это основной каталог проекта, и mypkgон находится в папке, у myprjменя есть модульные тесты myprj/tests/test_module1.py, а мой пакет - в папке myprj/mypkg. Это прекрасно работает для модульных тестов, но мне интересно, есть ли какое-либо соглашение, я должен следовать за тем, где должны находиться интеграционные тесты?
alpha_989

1
@ alpha_989: я не знаю, что будет за конвенция для Python. В настоящее время в .NET у меня есть производственный код, модульные тесты и интеграционные тесты в трех отдельных проектах, равные друг другу, но есть и много альтернатив.
Джон Скит

Хорошо, спасибо. Я мог бы найти стандартную рекомендацию, кроме как посмотреть на другой проект Python. но я буду следовать за
тобой

Пожалуйста, смотрите мой вопрос: stackoverflow.com/questions/61711739/…
milad salimi

@miladsalimi: Пожалуйста, не добавляйте посторонние комментарии только для того, чтобы привлечь внимание к другому вопросу. Я вижу, вы сделали это на четырех других постах - пожалуйста, не надо.
Джон Скит

51

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

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

  • Имеются ли данные, которые должны быть доступны только в разработке / тестировании, появились вживую ?
  • Не удалось запустить фоновый процесс?
  • Может ли пользователь войти в систему?

2
Можно ли вообще пинговать сайт - достаточно того, что существует сервис Binary Canary.
Дан Даскалеску

15
Название происходит от добычи угля: возьмите канарейку с собой "вниз по течению". Когда это поглотит это, убирайся быстрее. Канарские острова очень чувствительны к небольшим концентрациям вредного газа и могут умереть до того, как уровни концентрации станут токсичными для людей. Если Canary-тест не пройден, исправьте его быстро, потому что только LIVE потерпит неудачу.
Robino

1
То, как мы используем тестирование Canary на моей работе, - это сначала переключение нескольких клиентов на новую версию, а не всех сразу. Если первые несколько клиентов выживут, мы можем добавить остальных. Те первые несколько канареек.
00метр

2
@ 00promeheus, это бета-тестирование.
GregNash

1
@HarveyLin, хотя тест Канарских островов - это обязательно тест, предотвращающий бедствие, конечно, он используется не только таким образом. Но эмпирическое правило гласит: «Проверь это работает, потому что это критично». Конечно, у каждого теста есть почти одна и та же цель, но концепция очень специфична. В вашем случае я бы не считал все тесты канарскими.
Чарльз Роберто Канато

12

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

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

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

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


10

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

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

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

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

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


Это один из немногих ответов, который включает в себя что-то об инструментах.
Питер Мортенсен

8

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

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

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

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


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

7

РЕГРЕССИЯ

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


18
Откуда вы цитируете?
Дэрил

4
Согласно этой странице , эта цитата взята из статьи Википедии «Тестирование программного обеспечения», хотя кажется, что отрывок был изменен в какой-то момент с 2010 года.
Зак Лисобей,

В любом случае, WP не является действительным источником. Источники, на которые есть ссылки, могут быть действительными. Нет никаких действительных источников, на которые есть ссылки в WP, ни в статьях, ни на страницах обсуждения, которые бы поддержали утверждение, что «не» имеет какое-либо значение. Я сравнил фрагменты текста в списках результатов поиска в Google Книгах для обоих "regression test"и "non-regression test". Это то же самое.
Rainald62

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

7

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

Майк Кон в своей книге «Успех с 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 минут, чтобы получить более быструю обратную связь о сбоях

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

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


Этот ответ можно улучшить, ответив на вопрос об инструментах для тестирования дыма или регрессионного тестирования .
Питер Мортенсен

5

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

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

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

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


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

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

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

2

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

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

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

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


Разве нам не нужно создавать тест перед тем, как приступить к разработке?
Вин

@VinShahrdar, вы говорите о модульном тестировании?
Крунал

да. Я обычно создаю свои модульные тесты перед написанием производственного кода. Вот как ты должен это делать, правильно?
Вин

1
Да ... Но модульное тестирование также выполняется до того, как разработчик выполнит QA. Перед развертыванием кода на QA-сервере разработчик всегда выполняет модульное тестирование
Krunal

2

Модульное тестирование

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

Интеграционное тестирование:

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

Тестирование дыма

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

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

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

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


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

2

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

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

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

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


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

1

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

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

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

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

5
Модульное тестирование не обязательно белая коробка. Некоторые из лучших модульных тестов, которые я видел, по сути являются примерами, взятыми из требований, определяя ожидаемые результаты независимо от концепций реализации.
joel.neely

1
Кроме того, ваши модульные тесты включены в ваши регрессионные тесты, поэтому регрессионные тесты не являются тестами белого или черного ящика. Я бы даже сказал, что даже тесты на интеграцию и тестирование на дым могут быть тестами белого или черного ящика.
Ливен Керсмакерс

1
Я бы не согласился с этим. Тестирование реализации шаблона проектирования является формой интеграционного тестирования и является тестом белого ящика.
Хазок

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

1

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

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

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

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

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

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


1

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.