Как организовать тестирование на боевой базе данных с учетом ее размера и сложности

Что проверяют

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

Как отвечать

Разделите задачу на два случая. Нужны реалистичные данные, а не сам прод:

• копия с маскированием: снимок базы разворачивается на отдельном стенде, персональные данные обезличиваются до того, как копия попадёт к тестировщикам. В России этого требует 152-ФЗ, для PostgreSQL есть инструменты вроде Greenmask;
• подмножество: для функциональных тестов терабайт не нужен. Берут срез, например один процент клиентов со всеми их заказами, с сохранением ссылочной целостности (Jailer и аналоги);
• полный объём для производительности: миграции, тяжёлые отчёты и планы запросов проверяют на копии полного размера, на маленьком срезе планировщик выберет другой план;
• изоляция автотестов: свежая база в контейнере через Testcontainers и откат транзакции после каждого теста.

Проверка на проде неизбежна:

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

Где спотыкаются

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

Забывают про персональные данные: копия прода с настоящими телефонами и паспортами на тестовом стенде это инцидент, а не удобство.

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