SQL Lab
Тренажёр SQL для тестировщика: пишите запросы, проверяйте их и сверяйтесь с эталоном. Здесь вы отрабатываете навык, который пригодится каждый рабочий день — заглядывать в «источник правды» (базу) и сверять её с интерфейсом. Все задачи строятся вокруг трёх учебных таблиц: users(id, email, name, status, created_at), orders(id, user_id, status, total_amount, currency, created_at, paid_at) и payments(id, order_id, status, provider, external_id, created_at). Расширенные задания используют дополнительные QA-ориентированные таблицы: bugs(id, title, severity, status, created_by, created_at, module_id, sprint_id), test_cases(id, title, module_id, status), test_run_results(id, run_id, test_case_id, status, executed_at), sprints(id, name, start_date, end_date), order_items(id, order_id, product_id, quantity, price) и user_activity(id, user_id, action, created_at).
Теория перед практикой · 9 разделов
Зачем QA нужен SQL. Интерфейс — это витрина, а не правда: он может показать «Оплачено», пока в базе заказ висит в статусе pending. SQL даёт тестировщику прямой доступ к тому, что система реально сохранила, и превращает догадку «кажется, баг» в доказанный факт «в таблице orders запись ord_9001 имеет status=paid, но paid_at пуст». Это навык, который отличает поверхностную проверку от расследования по существу.
База как источник правды. Реляционная БД хранит данные в таблицах (строки = записи, столбцы = поля) и связывает их по ключам: orders.user_id ссылается на users.id, payments.order_id — на orders.id. Когда UI и база расходятся, прав почти всегда тот, у кого данные, а не тот, кто рисует экран. Поэтому при любом сомнении QA идёт в базу и сверяет конкретную запись по идентификатору.
Основа запроса: SELECT столбцы FROM таблица WHERE условие. SELECT перечисляет нужные поля (избегайте SELECT * в проверках — он хрупок к изменению схемы и тащит лишнее), FROM указывает таблицу, WHERE фильтрует строки по условию. Строки сравнивают в кавычках: WHERE status = 'paid'. Несколько условий объединяют через AND/OR, помня про приоритет и скобки.
NULL — это не ноль и не пустая строка, а «значение неизвестно/отсутствует». Любое сравнение с NULL через = или <> даёт не TRUE и не FALSE, а UNKNOWN, поэтому WHERE paid_at = NULL не вернёт ничего и обманет вас. Для проверки пустоты используйте IS NULL, для заполненности — IS NOT NULL. Это типовой инструмент поиска дефектов целостности: «оплачен, но даты оплаты нет».
JOIN соединяет таблицы по условию ON. INNER JOIN оставляет только совпавшие пары, LEFT JOIN сохраняет все строки левой таблицы и подставляет NULL там, где пары нет — это позволяет находить «сирот» (пользователей без заказов, заказы без платежей) комбинацией LEFT JOIN + IS NULL. Всегда явно указывайте условие соединения (ON o.user_id = u.id), иначе получите декартово произведение.
Агрегация сворачивает множество строк в числа. COUNT(*) считает строки, SUM/AVG/MIN/MAX — по столбцу. GROUP BY группирует строки по значению (например, по статусу) и считает агрегат внутри каждой группы; все негруппируемые столбцы в SELECT должны быть в GROUP BY. Фильтр по агрегату ставят в HAVING, а не в WHERE. ORDER BY сортирует результат (ASC/DESC), а LIMIT ограничивает число строк — удобно, чтобы достать «последнюю активность».
UI против DB. Самые ценные SQL-проверки QA рождаются из расхождений: на экране сумма заказа одна, а total_amount в orders другая; в личном кабинете «3 заказа», а COUNT по user_id даёт 4. Сценарий проверки прост — взять идентификатор из интерфейса, найти ту же запись в базе и сравнить поле за полем. Несовпадение — это баг, и теперь у вас есть его доказательство.
Read-only режим. На стендах для QA доступ к базе обычно даётся только на чтение. Команды UPDATE, DELETE, DROP, INSERT, ALTER, TRUNCATE изменяют или разрушают данные и в тестировании запрещены: одна ошибочная DELETE без WHERE может стереть таблицу, а UPDATE — испортить чужой тест. Задача тестировщика — наблюдать, а не менять. В этом тренажёре любая изменяющая команда блокируется проверкой, как и на реальном read-only стенде.
Из результата — в evidence. Запрос ценен не сам по себе, а как доказательство в баг-репорте. К дефекту прикладывают текст самого SELECT (чтобы разработчик повторил), результат с конкретными значениями полей и пояснение, какое поле не соответствует ожиданию. Формула evidence: «выполнил запрос X → получил строку Y → ожидалось Z». Это снимает споры «а у меня работает» и ускоряет починку.
Выборка пользователей
Начнём с базовой проекции. Нужно достать конкретные столбцы, а не всё подряд (SELECT * — антипаттерн в проверках).