Ответ
На проектах регрессионное тестирование проводилось по регламентированному графику и по событию.
Типичная частота:
| Тип регресса | Частота / Триггер | Объем |
|---|---|---|
| Smoke-тесты | При каждой сборке (CI) | Минимальный набор ключевых сценариев (5-10%) |
| Частичный регресс | После фикса дефекта или изменения модуля | Тесты затронутой функциональности (20-30%) |
| Полный регресс | Перед релизом или в конце спринта | Все или большинство регрессионных тестов (80-100%) |
Пример маркировки и запуска автоматизированных регрессионных тестов в pytest:
import pytest
@pytest.mark.regression
@pytest.mark.smoke
def test_user_login():
"""Ключевой сценарий входа. Запускается при каждой сборке."""
assert login("valid_user", "valid_pass") is True
@pytest.mark.regression
def test_order_creation_flow():
"""Расширенный бизнес-сценарий. Запускается в полном регрессе."""
user = login("valid_user", "valid_pass")
order = create_order(user, items=["item1", "item2"])
assert order.status == "CREATED"Вывод: Частота определяется балансом между необходимостью гарантировать стабильность и скоростью доставки изменений.
Ответ 18+ 🔞
А, ну смотри, тут про регресс-тесты, блядь, рассказывать — это как объяснять, почему нужно мыть руки после туалета. Вроде очевидно, а всё равно находятся те, кто пытается сэкономить на этом времени, а потом охуевают от сюрпризов в продакшене.
Так вот, на проектах у нас регрессионное тестирование было, как два сапога — пара. Или, точнее, как два хуя в одном тазу. Оно было по расписанию, чётко по календарю, и по событию — когда кто-то что-то накосячил и нужно срочно проверить, не развалилось ли всё к ебеням.
Как часто это происходило, ёпта:
| Тип регресса | Когда запускали / Что спровоцировало | Сколько всего тестов гоняли |
|---|---|---|
| Smoke-тесты (дымовые) | Каждую сборку, как только что-то закоммитили (CI) | Самый сок, минимальный набор, чтобы понять, не сгорело ли всё нахуй сразу (5-10%) |
| Частичный регресс | После того, как баг пофиксили или в одном модуле поковырялись | Только то, что рядом с местом происшествия, чтобы не тратить время зря (20-30%) |
| Полный регресс | Перед тем, как выкатить релиз, или в конце спринта, когда все уже без сил | Всё, что накопилось, полная прогонка, чтобы спать спокойно (80-100%) |
Вот, смотри, как это в коде выглядело, чтоб ты понимал масштаб распиздяйства, если этого не делать:
import pytest
@pytest.mark.regression
@pytest.mark.smoke
def test_user_login():
"""Ключевой сценарий входа. Запускается при каждой сборке."""
assert login("valid_user", "valid_pass") is True
@pytest.mark.regression
def test_order_creation_flow():
"""Расширенный бизнес-сценарий. Запускается в полном регрессе."""
user = login("valid_user", "valid_pass")
order = create_order(user, items=["item1", "item2"])
assert order.status == "CREATED"Итог, блядь: Частоту выбирали, балансируя на тонкой грани между желанием всё проверить досконально и необходимостью не тормозить процесс так, чтобы все, блядь, сдохли от ожидания. Идеал — это когда ты уверен, что ничего не сломал, и при этом не потратил на проверку полжизни.