Тестирование БД
Тема дорожной карты · QA-инженер
Тестирование баз данных — это процесс проверки того, что база данных корректно хранит, извлекает, преобразует и защищает данные, охватывающий целостность данных, ссылочные ограничения, хранимые процедуры, триггеры, производительность индексов и безопасность — как специализированный уровень в STLC, дополняющий API-тестирование и UI-автоматизацию. QA-инженеры, выполняющие тестирование баз данных, используют SQL-запросы для проверки состояния после операций: после вызова REST API POST /users, проверенного с REST Assured или Postman, запрос SELECT COUNT(*) FROM users WHERE email = 'test@example.com' подтверждает, что запись была сохранена; после вызова API DELETE запрос SELECT id FROM users WHERE id = 42 должен вернуть ноль строк. Тестирование баз данных также охватывает валидацию схемы — проверку типов столбцов, ограничений NOT NULL, уникальных индексов и отношений внешних ключей на соответствие спецификации — что защищает от незаметного дрейфа схемы, вносимого в ходе SDLC-миграций. Для приложений на MongoDB тестирование баз данных включает выполнение ассерций mongosh против структуры документов, проверку корректного заполнения встроенных массивов и верификацию результатов агрегационного пайплайна на соответствие ожидаемым вычисленным значениям. Аспекты производительности тестирования баз данных включают выполнение EXPLAIN ANALYZE для критических запросов, чтобы подтвердить использование индексов и укладывание времени выполнения в рамки SLA, дополняя нагрузочные тесты JMeter или k6 против полного стека приложения.
Как это работает
Тестирование БД — верификация целостности данных, корректности схемы, влияния кода на БД. Навыки: SQL (SELECT, JOIN, WHERE, GROUP BY), чтение explain-планов медленных запросов, знание существующих индексов, понимание транзакций + isolation levels с первого взгляда. Инструменты: SQL-клиент (DBeaver, DataGrip, psql), SQL на уровне "могу написать JOIN 3 таблиц и объяснить". Управление test data — часто самая сложная часть.
Когда применять
Выучите SQL достаточно для верификации, что UI-действие привело к ожидаемому изменению в БД — на data-слое живёт большинство багов. Для integration-тестов — реальные БД (Testcontainers), не моки. Reset/seed данных детерминированно между тестами. Следите за data-related side-effects: фича "работает", но портит другую строку в БД.
Типичные ошибки
Ловушки Тестирование БД: не проверяют DB-state после UI-действия (верифицируют только то, что показывает UI); ручная правка строк в prod "потестировать" (только в dev/staging); тесты зависят от ID строк конкретного запуска (auto-increment нестабилен); SELECT * в тестах, когда важна одна колонка (падения на изменении схемы).