sql-practice

Набор SQL-запросов к тестовой базе интернет-магазина (users / orders / order_items). Идея простая: тестировщик постоянно лезет в базу руками, чтобы проверить, что в интерфейсе и в данных одно и то же. Здесь собраны 10 типовых таких проверок.

Где запускать

1. Открой https://www.db-fiddle.com
2. Слева вверху выбери PostgreSQL (любую версию, 13+ норм).
3. В левое окно (Schema SQL) вставь содержимое schema.sql.
4. В правое окно (Query SQL) вставляй любой запрос из папки queries/.
5. Жми Run.

Схему достаточно вставить один раз — дальше просто меняешь запрос справа.

Структура

sql-practice/
├── README.md
├── schema.sql          ← таблицы + тестовые данные
└── queries/
    ├── 01_active-users.sql
    ├── 02_duplicate-emails.sql
    ├── 03_user-orders.sql
    ├── 04_completed-sum.sql
    ├── 05_total-mismatch.sql
    ├── 06_users-without-orders.sql
    ├── 07_top-products.sql
    ├── 08_orders-by-status.sql
    ├── 09_recent-orders.sql
    └── 10_top-spender.sql

В каждом .sql сверху комментарий: что за задача и зачем она нужна в тестировании.

Что проверяет каждый запрос

#	Задача	Что должно получиться
01	Активные пользователи	4 строки. Петр (is_active = FALSE) выпадает — фильтр работает
02	Дубли email	Находит danila@test.com — он висит на двух юзерах. Это баг регистрации
03	Заказы юзера id = 1	2 заказа: completed на 1500 и pending на 300
04	Сумма completed-заказов	3250.49 (1500 + 750.50 + 999.99)
05	Расхождение позиций и total	0 строк — на этих данных всё бьётся, расхождений нет
06	Юзеры без заказов	Только Мария (id 4) — единственная без заказов
07	Топ-3 дорогих товара	Ноутбук 1200, Монитор 750.50, Чехол 500
08	Заказы по статусам	completed 3, cancelled 1, pending 1
09	Заказы за 30 дней	Все 5 — created_at ставится через NOW()
10	Кто потратил больше всех	Данила, 1800 (1500 + 300)

Заметки

Запрос 05 возвращает 0 строк — и это не ошибка. Сумма позиций в order_items у всех заказов совпадает с orders.total. Пустой результат здесь означает "расхождений не найдено" — ровно то, что хочет увидеть тестировщик. Нужно посмотреть, как выглядит пойманный баг — поменять в schema.sql цену любого товара (например, поставь Мыши 350 вместо 300) и перезапустить: заказ сразу всплывёт.

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

Запрос 10 считает и pending-заказы. У Данилы 1800 = 1500 (completed) + 300 (pending). Если под "потратил" понимать только оплаченное — добавь WHERE status = 'completed' (тогда выйдет 1500). Это сознательный выбор и хороший повод обсудить, что именно считается "тратой".

WHERE is_active = TRUE vs WHERE is_active. В PostgreSQL обе записи эквивалентны — это настоящий булев тип. В MySQL булева нет (там TINYINT), так что привычка писать = TRUE явно переносится без сюрпризов.

Проверено

Все 10 запросов прогнаны на PostgreSQL — выполняются без ошибок, результаты совпадают с таблицей выше. Воспроизвести можно в db-fiddle: вставить schema.sql в Schema SQL и выполнить любой запрос из queries/.