Регрессионные тесты - это весь набор тестов или набор тестов?

Меня учили, что регрессионный тест - это небольшая (достаточная только для того, чтобы доказать, что вы ничего не сломали с введением изменений или новых модулей) выборку общих тестов. Однако эта статья Рона Моррисона и Грэди Буча заставляет меня думать иначе:

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

В том же документе также говорится:

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

Описывая дымовые испытания, авторы говорят следующее:

Также важно, чтобы Smoke Test выполнял быструю проверку всей системы, а не только новых компонентов.

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

Я неправильно понял то, чему меня учили? Меня неправильно учили? Или существует несколько интерпретаций «регрессионного теста»?


testing regression-testing smoke-testing
person Thomas Owens    schedule 30.10.2008    source источник

Ответы (8)


arrow_upward
5
arrow_downward

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

Здесь применяется эмпирическое правило «если это возможно сломается, проверьте это». Если изменение в Foo может повлиять на Bar, запустите регрессию для обоих.

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

person Bill the Lizard    schedule 30.10.2008
comment
Что ж, я узнал, что регрессионные тесты должны делать две вещи. (1) Измененные компоненты должны быть тщательно протестированы. (2) Любые критические компоненты системы, даже те, которые не были изменены, должны быть протестированы с помощью регрессионного теста. - person Thomas Owens; 30.10.2008
comment
Это неплохое правило. Однако будьте осторожны, если каждый компонент внезапно станет критическим. - person Bill the Lizard; 30.10.2008
comment
Что ж, вы должны определить критическое. Но да. - person Thomas Owens; 30.10.2008

arrow_upward
5
arrow_downward

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

person Dave Costa    schedule 30.10.2008

arrow_upward
1
arrow_downward

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

person tloach    schedule 30.10.2008
comment
Вы описываете системное тестирование или тестирование системной интеграции. Регрессионные тесты просто проверяют, не завершились ли ранее пройденные тесты, и могут быть запущены в любое время. - person Bill the Lizard; 30.10.2008
comment
Тлоах и Эли описывают одно и то же, и я сомневаюсь, что они работают в одной компании. Здесь описывается модель первого запуска тестов с последующими исправлениями и т.п., а также заключительный этап регрессионного тестирования перед отправкой. Использование слова регрессия здесь совершенно справедливо. - person MrBoJangles; 30.10.2008
comment
Регрессия не означает всего набора тестов. Это означает повторный запуск существующих тестов, чтобы увидеть, не нарушил ли их новый код. Это не (обязательно) означает, что вам нужно запускать весь пакет, но это возможно. Я просто указываю на небольшую разницу. - person Bill the Lizard; 30.10.2008
comment
Хотя @BilltheLizard описал правильно, но я думаю, что это зависит от организации. В моей организации ВЛИЯНИЕ ОБЛАСТИ обычно проверяется регрессией. Но когда иногда высшее руководство настаивает, мы делаем полный регресс. - person a Learner; 26.08.2016

arrow_upward
1
arrow_downward

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

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

person Elie    schedule 30.10.2008
comment
Это системное (интеграционное) тестирование. - person Thomas Owens; 30.10.2008
comment
Нет, это не так. Системное (интеграционное) тестирование предназначено для новой функциональности. Регрессионное тестирование предназначено для того, что мы не изменили во время текущей сборки. Наш набор регрессионных тестов постоянно расширяется по мере добавления новых функций. - person Elie; 30.10.2008
comment
Регрессионное тестирование предназначено для проверки того, не нарушил ли новый код ранее пройденные тесты. Вы описываете системное тестирование. - person Bill the Lizard; 30.10.2008
comment
А теперь мы переходим к аргументам семантики. Это глупо. Эли совершенно права, те тесты считаются регрессионными там, где она работает, и там, где работал я, то же самое. Слова означают разные вещи, и часто одно и то же слово означает несколько вещей. - person MrBoJangles; 30.10.2008
comment
Регрессионное тестирование имеет более широкую область применения, чем модульное, интеграционное и системное тестирование. Это можно сделать на любом из этих уровней. Слова действительно имеют значение, и, поскольку это общественный форум, мы должны попытаться использовать наиболее широко распространенное определение. - person Bill the Lizard; 30.10.2008

arrow_upward
1
arrow_downward

Я понимаю термин «регрессионное тестирование»:

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

на практике лучше всегда запускать все существующие модульные тесты при внесении изменений. Единственный раз, когда я беспокоюсь о подмножестве тестов, это когда полный набор модульных тестов занимает «слишком много времени» для выполнения [где «слишком долго» довольно субъективно]

person Steven A. Lowe    schedule 30.10.2008

arrow_upward
0
arrow_downward

Начните с того, чего вы пытаетесь достичь. Затем сделайте то, что вам нужно для достижения этой цели. А затем используйте модное слово «бинго», чтобы обозначить словом то, что вы на самом деле делаете. Как и все :-) Точность не так уж и важна.

person Todd Hoff    schedule 30.10.2008
comment
Четкое общение важно. Помогает, если мы пользуемся одним и тем же словарем. - person Dave Costa; 30.10.2008

arrow_upward
0
arrow_downward

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

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

person KeyserSoze    schedule 30.10.2008

arrow_upward
0
arrow_downward

В общем, подмножество тестов функций для новой функции, представленной в версии X продукта, становится основой регрессионных тестов для версии X + 1, X + 2 и т. Д. Со временем вы можете сократить время, затрачиваемое на функциональные / регрессионные тесты стабильных функций, которые не страдали от регрессий. Если функция страдает от множества регрессий, может быть полезно усилить акцент на этой функции.

Я думаю, что статья, в которой говорится о «расширенном регрессионном тесте», означает запуск обширного набора (индивидуально простых) регрессионных тестов.

person Jonathan Leffler    schedule 30.10.2008