База для QA
К списку уроков
Блок 6 · Базы данных и SQL

Урок 19. Базы данных

Что хранится «под капотом» приложений

Темы урока

Реляционные БД (PostgreSQL/MySQL/MS SQL), таблицы/строки/столбцы/ключи/индексы, NoSQL (MongoDB/Redis/Elasticsearch), реляционные vs NoSQL

Видео урока

Пройти тест по уроку

Конспект урока

Главное за урок

База данных — источник правды приложения. UI может показать успех, API вернуть 200 — а запись в таблице так и не появится. Тестировщик, который понимает схему данных, быстрее отличает баг отображения от бага сохранения.

Реляционные БД хранят данные в таблицах со строгой схемой и связями через ключи. NoSQL дополняет их там, где нужна гибкость, скорость или специализированный поиск — в одном продукте часто живут и PostgreSQL, и Redis, и Elasticsearch.

Что такое база данных

База данных (БД) — организованное хранилище данных приложения. Доступ к ней идёт через СУБД (систему управления базами данных): PostgreSQL, MySQL, MongoDB и др.

Приложение → API / Backend → СУБД → Таблицы / Коллекции
Термин Значение
БД Совокупность данных
СУБД Программа, которая управляет БД (PostgreSQL, MySQL…)
Схема Структура таблиц, полей и связей
Запрос Команда на чтение или изменение данных (SQL — на следующем уроке)

Зачем QA заглядывает в БД

Сценарий Что проверяем в БД
Регистрация Появилась ли строка в users с корректным email
Создание заказа Есть ли запись в orders после «Оформить»
Удаление Удалилась ли строка или стоит deleted_at (soft delete)
Оплата Совпадают ли статусы в orders и payments
Промокод Не применился ли код дважды, не превышен ли лимит

QA не обязан администрировать сервер БД, но должен уметь прочитать схему и понять, где искать данные после действия в UI.

Реляционная модель: таблицы

Данные хранятся в таблицах — как лист Excel, но со строгими правилами.

Элемент Описание Пример
Строка (record, row) Один объект Один пользователь, один заказ
Столбец (column, field) Атрибут объекта email, status, created_at
Тип данных Формат значения INTEGER, VARCHAR, BOOLEAN, TIMESTAMP, DECIMAL

Пример таблицы users:

id email name created_at
1 anna@test.ru Анна 2026-05-01 10:00
2 ivan@test.ru Иван 2026-05-02 14:30

Primary Key (PK)

Primary Key — уникальный идентификатор каждой строки.

  • Обычно поле id — не повторяется между строками
  • AUTO INCREMENT — значение генерируется автоматически при вставке
  • Без PK нельзя однозначно сослаться на запись

В API поле "id": 12345 часто — это PK из базы.

Foreign Key (FK) и связи

Foreign Key — столбец, который ссылается на PK другой таблицы.

users (id) ←── orders (user_id)
orders (id) ←── order_items (order_id)
products (id) ←── order_items (product_id)

Связь один-ко-многим (1:N): один пользователь — много заказов; один заказ — много позиций.

Тип связи Пример
1:1 Пользователь — профиль
1:N Пользователь — заказы
N:M Заказы — продукты (через промежуточную таблицу order_items)

Типичный баг: заказ с user_id, которого нет в users — нарушение целостности данных.

Индексы

Индекс — структура, ускоряющая поиск по столбцу (email, phone, status).

Плюс Минус
Быстрый SELECT по индексированному полю INSERT/UPDATE медленнее — индекс тоже обновляется
Меньше «зависаний» при поиске Слишком много индексов — нагрузка на запись

QA не настраивает индексы, но понимает: медленный поиск может быть проблемой производительности, а не логики.

Популярные реляционные СУБД

СУБД Особенности Где встречается
PostgreSQL Open source, мощные типы, JSONB Стартапы, продуктовые команды
MySQL Классика веба, простой старт PHP/Laravel, legacy-проекты
MS SQL Server Корпоративный сегмент Windows, .NET, enterprise

Синтаксис SQL у них похож — на собесах важнее понимание принципов, чем знание всех диалектов.

ACID и транзакции

Транзакция — группа операций, которая выполняется целиком или откатывается.

Принцип Смысл для QA
Atomicity Либо списали деньги и создали заказ, либо ничего
Consistency Данные остаются валидными после операции
Isolation Параллельные операции не портят друг другу данные
Durability После commit данные сохранены

При тестировании оплаты проверяй и UI, и записи в orders + payments — оба должны совпасть.

NoSQL — когда реляционная модель не подходит

NoSQL — «Not Only SQL»: документы, key-value, графы, колоночные хранилища.

Используют когда:

  • нужна гибкая схема (разная структура документов);
  • критична скорость чтения (кэш);
  • нужен полнотекстовый поиск;
  • горизонтальное масштабирование важнее жёстких связей.

NoSQL не заменяет SQL — дополняет. В одном продукте: PostgreSQL + Redis + Elasticsearch — норма.

MongoDB — документная БД

Данные хранятся как JSON-подобные документы в коллекциях.

{
  "_id": "507f1f77bcf86cd799439011",
  "email": "anna@test.ru",
  "preferences": { "newsletter": true, "lang": "ru" }
}
Плюс Минус
Гибкая схема Сложнее гарантировать целостность связей
Удобно для каталогов, логов, CMS Не замена для транзакционных данных (заказы, платежи)

QA проверяет: документ создался, поля на месте, вложенные объекты корректны.

Redis — key-value in-memory

Redis хранит данные в памяти по ключу.

Use case Пример ключа
Сессии session:abc123
Кэш product:42:details
Корзина «на лету» cart:user:7
Rate limiting api:limit:ip:1.2.3.4
  • Данные могут иметь TTL (время жизни) — исчезнуть после рестарта это не всегда баг
  • Баг рассинхрона: корзина в Redis показывает старое, в PostgreSQL уже пусто

Elasticsearch — полнотекстовый поиск

Elasticsearch — поиск по тексту в больших объёмах данных.

  • «Найди пizza с анanasом» по каталогу из 10 000 позиций
  • Фильтры, автодополнение, релевантность результатов

QA проверяет: после добавления товара он появляется в поиске; после удаления — исчезает (с учётом задержки индексации).

Реляционные vs NoSQL

Критерий Реляционные (PostgreSQL) NoSQL
Структура Жёсткая схема, таблицы Гибкая или key-value
Связи FK, JOIN Вложенные документы / отдельные ключи
Транзакции ACID из коробки Зависит от продукта
Масштаб Вертикальный + реплики Горизонтальный шarding
Когда Пользователи, заказы, платежи Кэш, поиск, логи, каталоги

Схема на примере «Пиццаед»

users ──< orders ──< order_items >── products
              │
              └── promo_codes (FK promo_code_id)
Таблица Назначение
users Пользователи
orders Заказы (FK → users)
order_items Позиции заказа (FK → orders, products)
products Каталог пицц
promo_codes Промокоды

После «Оформить заказ» проверяй: строка в orders, позиции в order_items, статус и сумма.

Типичные баги через БД

Симптом в UI Что искать в БД
«Email уже занят», но регистрация прошла Дубликат в users
Заказ «оплачен», но деньги не списались orders.status = paid, payments пустая
Удалили аккаунт — заказы остались Soft delete vs hard delete, FK ON DELETE
Старые данные после обновления Кэш Redis не инвалидирован
Промокод применился дважды Нет UNIQUE или проверки лимита

Ключевые тезисы для теста

  • БД — источник правды; UI и API могут не совпадать с данными в таблицах
  • Строка — один объект, столбец — атрибут с фиксированным типом
  • Primary Key — уникальный id строки; Foreign Key — ссылка на PK другой таблицы
  • Связь 1:N — один пользователь, много заказов
  • Индекс ускоряет поиск, но замедляет запись
  • ACID — гарантии транзакций: атомарность, согласованность, изоляция, сохранность (подробно на уроке 20)
  • MongoDB — документы; Redis — кэш/key-value; Elasticsearch — поиск
  • NoSQL дополняет реляционные БД, не заменяет их для транзакционных данных
  • QA проверяет согласованность данных между UI, API и БД

Домашнее задание

Открой DB Lab → режим «Поиск багов».

В таблицах «Пиццаеда» намеренно заложено 5 проблем с данными. Найди все 5 и напиши в чат марафона:

Баг #N — таблица X: поле Y = Z. Это баг, потому что...

Как работать: нажимай «Проверить» у каждого баге — увидишь SQL-результат с подсветкой проблемных строк. Застрял — жми «Показать ответ».

Сдай ответы в чат марафона.

Полезные ссылки