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

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

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

Давайте представим это визуально.

Есть продукт. Он состоит из множества различных частей.

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

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

Либо может быть ситуация, когда в продукте появляется новый функционал. И его работа может повлиять на старый.

То есть нам нужно проверить работу старого функционала после исправления старого кода и/или написания нового. В этом и заключается регрессионное тестирование.

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

 

Oct. 16, 2023, Источник

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

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

Включает следующие шаги:

1. Выбор тестовых случаев: Не всегда возможно или практично перезапускать все тесты. Поэтому выбираются те тестовые случаи, которые наиболее вероятно могут быть затронуты изменениями.
2. Автоматизация тестирования: Регрессионное тестирование часто автоматизируют, чтобы сэкономить время и ресурсы, поскольку оно должно выполняться многократно на протяжении всего цикла разработки.
3. Выполнение тестов: Запускаются выбранные (или все) тестовые случаи после внесения изменений в программу.
4. Анализ результатов: После выполнения тестов анализируются результаты на предмет выявления регрессий или новых ошибок, вызванных последними изменениями.

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

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

Feb. 22, 2024, easyoffer