Что происходит между сервером и базой данных: скрытая жизнь, о которой тестировщики редко знают? 2025

Когда мы тестируем API или веб‑приложение, кажется, что всё просто: клиент отправил запрос, сервер взял данные из базы и вернул ответ. Но на самом деле между сервером и базой кипит жизнь: соединения переиспользуются, данные проходят через кэш, транзакции скрывают обновления, а логи отстают от реальности. И если этого не понимать, легко попасть на «фантомные баги» — когда сегодня баг есть, а завтра его нет.

Рассказываю, что реально происходит под капотом, с чем я сталкивался на проектах, и что стоит учитывать тестировщику.

Миф: каждый запрос открывает новое соединение с базой.

Реальность: приложения используют пул соединений (HikariCP, PgBouncer). Соединения открываются один раз и переиспользуются — это сильно ускоряет работу. Что важно знать тестировщику: Если пул забит (например, утечка соединений), приложение перестанет отвечать — вы увидите 500‑ки или подвисание. В логах API вы не увидите причину — она в пуле. На нагрузочных тестах баги «утечки» проявляются через 5–10 минут, а не сразу. Кейс: на одном проекте нагрузочные тесты API «убивали» сервис через 8 минут — оказалось, что соединения с базой не закрывались, пул заполнялся, и сервер становился «немым».

Когда приложение делает несколько запросов к базе в рамках одной операции, они объединяются в транзакцию. До коммита никто, кроме этого соединения, изменений не видит. Почему это важно: Тест может «не увидеть» данные сразу после операции. Если уровень изоляции Read Committed — другие запросы не увидят «незакоммиченные» записи. На Repeatable Read можно получить «устаревшие» данные внутри одной транзакции. Практический совет: В автотестах API не полагайтесь на мгновенные проверки в БД — ждите коммит или проверяйте через Awaitility с ретраями.

В микросервисах часто используют мастер‑реплику: Мастер принимает записи. Реплики обслуживают чтение (для скорости). Подводный камень: реплика может отставать от мастера на 1–2 секунды. В итоге: API, читающее с реплики, отдаёт старые данные. Тесты начинают «падать» нестабильно: то проходят, то нет. Решение: В тестах проверяйте источник данных — если важна мгновенная проверка, то учитывайте лаг.

Часто между сервером и базой есть Redis/Memcached. Запрос сначала идёт в кэш, а не в базу. Если кэш не сбросили после обновления — клиент видит старое значение. Почему это важно: Тестировщик думает: «База обновилась, значит API тоже отдаёт новое». Но API отдаёт кэш. Практика: При расследовании бага проверяйте и базу, и кэш. Если API не обновилось — возможно, кэш не инвалидациили.

Логирование часто асинхронное: Ошибка произошла → в лог она попадёт через секунды. Или не попадёт вообще, если очередь логирования упала. Ловушка: тестировщик проверяет логи и думает: «Сервис работает нормально». А база уже в рассинхроне.

1. Знать архитектуру: мастер/реплики, наличие кэша, используемый пул соединений. 2. Ставить правильные ожидания: не полагаться на моментальные проверки после записи. 3. Использовать ретраи и Awaitility, а не Thread.sleep. 4. Проверять несколько источников: база, кэш, логи, очередь сообщений (RabbitMQ/Kafka). 5. Фиксировать в багрепортах не только поведение API, но и состояние БД/кэша.

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

Ставь лайк, если было полезно❤

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