В чём разница между регрессионным и функциональным тестированием?

Question

deepseek-v3.2 · Accepted Answer

## Разница между регрессионным и функциональным тестированием

**Функциональное тестирование** — это вид тестирования, направленный на проверку соответствия программного продукта его функциональным требованиям. Его цель — удостовериться, что каждая функция системы работает **правильно**, в соответствии с техническим заданием или спецификацией. Основной вопрос: "Система делает то, что должна?".

**Регрессионное тестирование** — это вид тестирования, цель которого — убедиться, что внесённые в приложение изменения (например, исправление дефекта, добавление новой функциональности, настройка) **не сломали** уже существующую, ранее работоспособную функциональность. Основной вопрос: "Осталось ли старое поведение корректным после внесения изменений?".

---

### Ключевые различия в сравнительной таблице

---

### Пример для иллюстрации

Представьте себе интернет-магазин с корзиной покупок.

**Функциональное тестирование новой функции "Применить промокод":**
*   Проверяем, что валидный промокод применяется и корректно пересчитывает сумму.
*   Проверяем, что невалидный промокод отклоняется с понятным сообщением.
*   Проверяем граничные условия: промокод с истёкшим сроком, промокод на другую категорию товаров.
*   Проверяем интеграцию с расчётом доставки после применения скидки.

```gherkin
# Пример тест-кейса в формате Gherkin (функциональное тестирование)
Feature: Применение промокода
  Scenario: Успешное применение валидного промокода
    Given Пользователь добавил товар в корзину
    When Пользователь вводит валидный промокод "SUMMER2024"
    Then Сумма в корзине уменьшается на 15%
    And В интерфейсе отображается сообщение "Промокод применён"
```

После реализации этой функции и исправления связанных с ней багов, команда добавляет на сайт новую функцию **"Быстрая покупка в один клик"**. Теперь необходимо провести **регрессионное тестирование**:

**Регрессионное тестирование после внедрения "Быстрой покупки":**
*   **Проверяем, не сломалась ли старая функциональность "Применить промокод":**
    *   Можно ли по-прежнему применить промокод в обычной корзине?
    *   Корректно ли пересчитывается сумма после скидки?
    *   Не "протекают" ли данные между новой формой "быстрой покупки" и старой корзиной?
*   Проверяем другие критические функции, которые могли быть затронуты косвенно:
    *   Добавление товара в корзину.
    *   Оформление заказа через стандартный процесс.
    *   Расчёт стоимости доставки.

```java
// Упрощённый пример автоматизированного регрессионного теста (псевдокод)
@Test
public void test_ApplyPromoCode_Regression_AfterNewFeature() {
    CartPage cart = new CartPage(driver);
    cart.addItem("SKU-12345");
    cart.applyPromoCode("SUMMER2024");

// Это проверка РЕГРЕССИИ: та же логика, которая работала раньше
    assertThat(cart.getTotalPrice()).isEqualTo(calculateExpectedPriceWithDiscount(850, 0.15));
    assertThat(cart.getPromoCodeMessage()).contains("применён");
    // Дополнительная проверка: новая функция не влияет на старую
    assertThat(cart.isStandardCheckoutButtonEnabled()).isTrue();
}
```

---

### Стратегии и взаимосвязь

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

**Регрессионное тестирование** может быть:
*   **Полным** (редко из-за ресурсов) — повторение всех существующих тестов.
*   **Избирательным** — тестирование модулей, наиболее тесно связанных с изменениями.
*   **Автоматизированным** — идеальный и наиболее эффективный вариант, основанный на наборе ранее написанных функциональных тестов.

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

Критерий	Функциональное тестирование	Регрессионное тестирование
Основная цель	Проверить корректность работы функций "с нуля".	Проверить, что старые функции не сломались после изменений.
Объект проверки	Новая или изменённая функциональность.	Ранее протестированная, стабильная функциональность.
Идеальный момент	При первом внедрении функции (приёмочное, smoke, тестирование новой фичи).	После любых изменений в коде или среде (после исправления багов, обновлений, слияния веток).
Глубина и объём	Может быть глубоким и детальным (позитивные/негативные сценарии, граничные значения).	Чаще является избирательным, направленным на "зону риска" вокруг изменений.
Что является входом?	Требования, пользовательские истории, спецификации.	Изменения в коде (дельта), история дефектов, карта существующей функциональности.

В чём разница между регрессионным и функциональным тестированием?

Комментарии (2)

Разница между регрессионным и функциональным тестированием

Ключевые различия в сравнительной таблице

Пример для иллюстрации

Стратегии и взаимосвязь