Какие SQL запросы можно составить для получения данных из таблицы

Что проверяют

Может ли тестировщик сам проверить данные в базе, а не верить интерфейсу, и найти в таблице аномалии. Следом обычно дают две таблицы и просят найти заказы без клиента или дубли по email.

Как отвечать

Покажите основу и сразу привяжите её к задачам тестирования:

• выборка и фильтрация: SELECT с конкретными колонками, WHERE с =, IN, BETWEEN, LIKE, IS NULL. Так проверяют, что после действия в интерфейсе запись появилась с нужными значениями;
• сортировка и ограничение: ORDER BY created_at DESC LIMIT 10, чтобы найти последние созданные тестовые записи;
• агрегаты: COUNT, SUM, MIN, MAX, AVG. Например, сверить сумму в отчёте с данными таблицы;
• группировка: GROUP BY email HAVING COUNT(*) > 1 находит дубли, которые система не должна была допустить;
• соединения: INNER JOIN вернёт только строки с парой, LEFT JOIN сохранит все строки левой таблицы. LEFT JOIN customers c ... WHERE c.id IS NULL покажет заказы без клиента;
• подзапросы и EXISTS: например, пользователи, у которых есть хотя бы один оплаченный заказ.

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

Упомяните правила работы со стендом: чаще всего у QA доступ только на чтение, а изменения данных делаются в транзакции или по договорённости, чтобы не сломать чужие проверки.

Где спотыкаются

Пишут WHERE phone = NULL. Такое условие не вернёт ни одной строки, нужен IS NULL.

Путают COUNT(*) и COUNT(column): второй не считает строки, где в колонке NULL, и сверка расходится.

Используют LIMIT без ORDER BY и удивляются, что «последние записи» каждый раз разные. Без сортировки порядок строк база не гарантирует.