Что тестировщику нужно знать о базах данных

В основе большинства современных приложений лежит клиент-серверная архитектура: клиент общается с сервером, который обрабатывает запросы и работает с базой данных. И именно в базе данных хранятся все важные данные, необходимые для работы приложения.

Даже если тестировщик занимается только UI или API, он всё равно фактически работает с базой данных - просто опосредованно, через пользовательский интерфейс или ответы от сервера. Именно из базы данных система берёт информацию для отображения пользователю, туда же сохраняет изменения, сделанные через интерфейс или API-запросы.

Поэтому важно не только проверить, что пользователь видит на экране или что приходит в ответе сервера, но и убедиться, что эти данные действительно корректно записаны и хранятся в базе. Несоответствие между отображаемыми данными и фактическим состоянием базы может привести к серьёзным багам, которые на первый взгляд могут быть незаметны.

Все базы данных можно разделить на две большие группы - реляционные (SQL) и нереляционные (NoSQL).

В большинстве случаев тестировщик работает с реляционными базами. Именно о них мы поговорим подробнее. Но полезно знать и что такое и нереляционные базы данных и зачем они нужны.

Нереляционные базы данных (или NoSQL) - это базы, в которых данные хранятся в виде списков, документов, наборов пар “ключ - значение” или даже как графы со связями.

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

Примеры: MongoDB, Redis, Cassandra.

Для тестировщика важно понимать, что в таких базах структура данных может быть разной для разных записей, нельзя использовать объединения данных (JOIN), данные могут обновляться не сразу (не всегда сразу же становятся видны во всех частях системы).

Такие базы данных встречаются далеко не на всех проектах. Чаще всего нужно уметь работать именно с реляционными базами. Разобраться в NoSQL вполне реально по ходу работы, когда они действительно встретятся в проекте. Главное понимать, что подход к работе с такими базами отличается, и быть к этому готовым.

Реляционные базы данных - это самый распространённый тип баз, с которыми чаще всего мы работаем. В таких базах данные хранятся в виде таблиц со строгой структурой: каждая таблица - это отдельная сущность (например, “Пользователи”, “Заказы”), каждая строка в таблице - отдельная запись (например, информация о пользователе, детали заказа), а столбцы описывают свойства этих записей. Структура таблицы задаётся заранее разработчиком при создании базы данных, что позволяет чётко контролировать, какие данные и в каком виде попадают в базу.

В реляционных базах важно не только хранить данные, но и правильно связывать их между собой. Например, заказ должен быть привязан к конкретному покупателю. Для этого используются:

• Первичный ключ (Primary Key) - уникальный идентификатор записи в таблице. Например, в таблице заказов это поле id.
• Внешний ключ (Foreign Key) - ссылка на запись в другой таблице, обеспечивает связь между таблицами. Например, в таблице заказов поле customer_id указывает на конкретного клиента в таблице Customers.

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

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

Чтобы тестировщик мог удобно просматривать и проверять данные в базе, чаще всего используют специальные графические клиенты - например, DBeaver, DataGrip, pgAdmin и другие.

Они позволяют подключиться к базе данных, посмотреть таблицы, быстро извлечь нужные данные, увидеть результат в табличной форме и даже вручную отредактировать данные (на тестовых стендах, конечно).

Самый популярный среди начинающих - DBeaver: он бесплатный, понятный и поддерживает большинство популярных баз (PostgreSQL, MySQL, Oracle и другие). С его помощью можно не только проверять данные, но и лучше понимать структуру проекта.

Например, можно визуально посмотреть как связаны между собой таблицы, используя диаграмму.

В настоящее время многие графические клиенты позволяют напрямую через интерфейс добавлять, удалять и редактировать данные в таблицах. Однако, это применимо только в случаях, когда нужно создать/удалить/отредактировать простые не связанные данные. Для всего остального нужен SQL.

SQL (Structured Query Language) - это язык, с помощью которого мы (и разработчики!) "общаемся" с базой данных. Он позволяет:

• посмотреть, что хранится в таблицах базы данных;
• добавить новые данные;
• изменить существующие;
• удалить лишнее.

Для тестировщика SQL - это один из главных инструментов. Даже с помощью самых простых запросов к базе данных мы можем сделать многое:

• проверить, сохранились ли данные после действий в интерфейсе,
• подготовить тестовые данные напрямую в базе,
• убедиться, что после выполнения запроса система изменила данные как нужно.

SQL несложный и логичный. Его можно начать использовать уже после знакомства с парой команд. А в более сложных случаях - например, когда нужно объединить данные из нескольких таблиц - можно подключать более продвинутые запросы.

Самые простые команды, с которых начинают все:
SELECT - посмотреть данные;
INSERT - добавить новые записи;
UPDATE - изменить данные;
DELETE - удалить данные.

Эти команды имеют множество опции: можно уточнить условия, сортировать, ограничивать результат и т.д.

Всё это делает SQL универсальным инструментом для работы с базой данных: от простой проверки данных до сложной аналитики.

А сейчас — перейдём к самому важному: что именно делает тестировщик в базе данных.

• Готовит тестовые данные

Для сложных сценариев тестирования часто требуются нестандартные или объёмные данные, которые сложно или долго заводить вручную через интерфейс. В таких случаях тестировщик может вставлять записи напрямую в базу данных с помощью SQL-запросов.

• Проверяет корректность сохранения и отображения данных

После выполнения действий в системе (например, оформление заказа, регистрация пользователя, изменение настроек профиля и т.д.) тестировщик может проверить, что введённые данные не только корректно отображаются на UI, но и действительно сохранились в базе данных без потерь и искажений. Это позволяет выявить ошибки в логике сохранения или преобразования данных на бэкенде.

• Проверяет корректность изменений после операций в системе

Действия пользователя могут затрагивать сразу несколько связанных таблиц (например, создание заказа, в котором создаются записи о клиенте, оплате, товарных позициях). Тестировщик проверяет, что все зависимые записи созданы или обновлены корректно, все связи между ними установлены, а данные согласованы между таблицами.

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

• Отлавливает баги, которые видны только через данные

Иногда некорректная работа системы не проявляется визуально - тестировщик может не заметить ошибку на уровне интерфейса, но данные в базе будут некорректными. Например, могут появляться задвоенные записи, когда одна и та же информация сохраняется в базу несколько раз. Это может происходить, например, если пользователь случайно несколько раз нажал кнопку “Сохранить”, а система не успела обработать предыдущий запрос. Или когда несколько частей системы одновременно пытаются записать одни и те же данные, и приложение не успевает правильно обработать одновременные изменения.

• Контролирует обновления базы

Когда выходит новая версия приложения или меняется структура базы данных, важно проверить, что все данные сохранились правильно, ничего не пропало и всё работает так же, как раньше.

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

Знание баз данных - это не про “уметь всё сразу”, а про умение понимать, где и зачем они применяются. Даже базовый SQL и общее понимание структуры реляционных баз позволяют тестировщику быть круче: быстрее искать ошибки, воспроизводить сложные сценарии и не теряться в данных.

Если ты только начинаешь - начни с простого: посмотри, как устроены таблицы, попробуй написать пару SELECT’ов, поэкспериментируй в DBeaver. А дальше всё придёт с опытом!

Наша команда уже более пяти лет занимается реализацией проектов на Java и усилением команд по направлениям

• DevOps;
• Java разработка;
• Тестирование.

За время существования компании, мы принимали участие в работе над более чем 100 проектами различного объема и длительности.

Если перед вами стоят вызовы, при которых вам может пригодится наша экспертиза, просто напишите нам,

• client@softwarecats.dev,
• https://t.me/alex_zarubin,
• или через любую форму на сайте.

Мы договоримся с вами об онлайн-встрече, чтобы подробнее обсудить ваш проект и вашу проблему.