Какой у вас опыт написания SQL-запросов для тестирования?

Question

Какой у вас опыт написания SQL-запросов для тестирования?

Тип вопроса: Базы данных и SQL Вероятность: 10% Категория: QA Тестировщик

Ответ

Активно использую SQL для проверки целостности и корректности данных в базах (MySQL, PostgreSQL) в ходе тестирования.

Основные сценарии применения:

Верификация данных после операций: Проверка, что запись создалась, обновилась или удалилась корректно.
Анализ сложных связей: Использование JOIN для проверки консистентности данных между связанными таблицами.
Подготовка тестовых данных: Наполнение БД специфичными данными для воспроизведения сценариев.
Проверка бизнес-логики: Написание запросов, реализующих сложные условия, которые должны быть отражены в приложении.

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

-- Найти пользователей, зарегистрированных после 1 января 2023, 
-- у которых более 5 заказов, и вывести детали
SELECT 
    u.id AS user_id,
    u.email,
    u.registration_date,
    COUNT(o.id) AS total_orders,
    SUM(o.amount) AS total_spent
FROM users u
INNER JOIN orders o ON u.id = o.user_id  -- Используем INNER JOIN, чтобы отсечь пользователей без заказов
WHERE u.registration_date > '2023-01-01'
GROUP BY u.id, u.email, u.registration_date
HAVING COUNT(o.id) > 5  -- Фильтрация по результату агрегации
ORDER BY total_spent DESC;

Оптимизация: Использование EXPLAIN для анализа плана выполнения запроса, создание индексов для ускорения проверок в больших базах.

Ответ 18+ 🔞

Вот же ж, ну и тема подъехала! А я-то, блядь, как раз из тех, кто в базах данных ковыряется не просто так, а с пристрастием. SQL — это ж моя вторая натура, ёпта! Не просто кнопки в интерфейсе тыкать, а лезть прямо в кишки базы и смотреть, что там творится.

Вот смотри, как это обычно бывает. Сидит разработчик, такой довольный: «Всё, фичу запилил, данные сохраняются!». А ты ему — «О, да? А ну-ка, блядь, проверим». Открываешь консоль, пишешь SELECT * FROM orders WHERE user_id = 666 и видишь, что сумма заказа -999999. И начинается: «Вообще-то это спецзначение для тестовых кредитов!». Да иди ты в пизду, чувак, с такими спецзначениями! Целостность данных — это святое, ебать мои старые костыли!

Так вот, где этот SQL у меня в работе вылезает:

После того как что-то сделали — проверить, что не накосячили. Нажали «Оплатить» — пошёл запрос, глянуть, а появилась ли запись в payments и сменился ли статус в orders. Без этого — вообще никуда.
Когда связи между таблицами сложные, как у мартышлюшки в джунглях. Тут без JOIN'ов — просто пиши пропало. Надо убедиться, что у каждого «заказа» есть «пользователь», а у каждой «позиции заказа» — реальный «товар», а не хуй с горы.
Чтобы воспроизвести баг, надо нужные данные в базу запихнуть. Иногда руками через интерфейс — это овердохуища времени. Проще написать INSERT с нужными параметрами и сразу получить идеальный кривой кейс.
Самое интересное — проверить бизнес-логику напрямую. Приложение говорит: «Пользователям с более чем 5 заказами — скидка». А мы возьмём и напишем запрос, который этих пользователей найдёт и посчитает их заказы. И если цифры не бьются — всё, пидары налетели, пошёл искать, где в коде дыра.

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

-- Ищем всех, кто зарегился недавно, но уже такой бодрый, что заказы пачками делает.
-- Подозрительно, ёпта!
SELECT 
    u.id AS user_id,
    u.email,
    u.registration_date,
    COUNT(o.id) AS total_orders,
    SUM(o.amount) AS total_spent
FROM users u
INNER JOIN orders o ON u.id = o.user_id  -- Берём только тех, у кого заказы вообще есть
WHERE u.registration_date > '2023-01-01'
GROUP BY u.id, u.email, u.registration_date
HAVING COUNT(o.id) > 5  -- Отфильтровываем всех, кто не дотягивает до статуса «постоянный клиент»
ORDER BY total_spent DESC; -- Смотрим, кто больше всех бабла оставил

И самое главное — производительность, блядь! Если такой запрос на продакшене с миллионом записей будет выполняться полчаса, то всем пипец. Поэтому всегда EXPLAIN ANALYZE в ход, смотрю, какие индексы не хватает, и требую их создания. Потому что тестирование — это не только найти баг, но и не угробить базу при этом, в рот меня чих-пых!

Короче, SQL для тестировщика — это не «ой, можно и без него». Это обязательный скилл, который отделяет того, кто просто кликает, от того, кто реально понимает, как данные живут и где они, сука, прячутся, когда ломаются.