Являются ли регрессионные тесты полным набором тестов или образцом тестов?

Question

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

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

В том же документе также сказано:

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

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

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

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

Answer 7

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

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

Answer 8

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