Приведи пример работы с SQL

Пример работы с SQL: тестирование данных и проверка бизнес-логики

В качестве QA Engineer работа с SQL (чаще всего MySQL, PostgreSQL, или MS SQL Server) критически важна для проверки данных, валидации бизнесhttp://правил и создания тестовых сценариев. Рассмотрим практический пример из области тестирования банковского приложения.

Контекст задачи

Мы тестируем модуль переводов средств. Поступил bug report: «При переводе суммы 1000 рублей со счетом 5001 на счет 5002 в таблице transactions создается две записи вместо одной». Нам нужно проверить состояние данных в базе.

Шаг 1: Анализ структуры данных

Первым делом изучаем схему таблиц, используя DESCRIBE или запросы к метаданным.

-- Узнаем структуру таблицы transactions
DESCRIBE transactions;

-- Или более подробно (для PostgreSQL)
SELECT column_name, data_type, is_nullable 
FROM information_schema.columns 
WHERE table_name = 'transactions';

Шаг 2: Проверка данных по конкретному сценарию

Выполняем запрос для поиска записей, связанных с указанными счетами и суммой. Используем SELECT с фильтрацией (WHERE) и сортировкой (ORDER BY).

SELECT 
    id,
    from_account_id,
    to_account_id,
    amount,
    transaction_date,
    status
FROM transactions
WHERE (from_account_id = 5001 OR to_account_id = 5001)
    OR (from_account_id = 5002 OR to_account_id = 5002)
    AND amount = 1000
    AND transaction_date >= '2023-10-01'
ORDER BY transaction_date DESC;

Шаг 3: Глубокий анализ для поиска дубликатов

Если мы обнаружили несколько записей, нужно определить, являются они дубликатами или разными транзакциями. Используем агрегатные функции (COUNT, GROUP BY).

-- Проверяем количество транзакций по уникальным комбинациям ключевых полей
SELECT 
    from_account_id,
    to_account_id,
    amount,
    DATE(transaction_date) as trans_day,
    COUNT(*) as record_count
FROM transactions
GROUP BY from_account_id, to_account_id, amount, DATE(transaction_date)
HAVING record_count > 1;

Шаг 4: Проверка связанных данных и бизнес-правил

Перевод должен отражаться не только в transactions, но и в балансах счетов (accounts). Выполняем JOIN между таблицами.

-- Проверяем балансы счетов и последние транзакции
SELECT 
    acc.account_number,
    acc.current_balance,
    t.transaction_date,
    t.amount,
    t.status
FROM accounts acc
LEFT JOIN transactions t 
    ON t.from_account_id = acc.id OR t.to_account_id = acc.id
WHERE acc.account_number IN ('5001', '5002')
ORDER BY t.transaction_date DESC;

Шаг 5: Создание тестовых данных для воспроизведения бага

Чтобы воспроизвести проблему, иногда нужно создать чистые тестовые данные. Используем INSERT с осторожностью (лучше в тестовой базе).

-- Создаем тестовые записи (предварительно проверяем, что счета существуют)
INSERT INTO transactions (from_account_id, to_account_id, amount, transaction_date, status)
VALUES 
    (5001, 5002, 1000.00, NOW(), 'COMPLETED'),
    (5001, 5002, 1000.00, NOW(), 'COMPLETED'); -- Вторая запись для проверки дублирования

Шаг 6: Использование транзакций для безопасного тестирования

Чтобы не нарушить данные в продовой базе, сложные проверки выполняем внутри BEGIN TRANSACTION с последующим ROLLBACK.

BEGIN TRANSACTION;

-- Выполняем наши проверочные запросы или даже тестовые UPDATE
UPDATE accounts SET current_balance = current_balance - 1000 
WHERE account_number = '5001';

-- Проверяем результат
SELECT * FROM accounts WHERE account_number IN ('5001', '5002');

ROLLBACK; -- Все изменения отменяются

Ключевые навыки QA Engineer в работе с SQL:

• Написание сложных запросов для проверки данных (SELECT, JOIN, агрегатные функции).
• Понимание схемы данных и связей между таблицами (внешние ключи, индексы).
• Создание и очистка тестовых данных (INSERT, DELETE с использованием WHERE).
• Валидация бизнесhttp://правил через данные (например, проверка, что сумма перевода не превышает баланс).
• Работа в транзакциях для безопасного тестирования в production-like базах.
• Автоматизация проверок через SQL в тестовых скриптах (например, в Python с библиотекой sqlalchemy).

Для QA Engineer SQL — это не просто инструмент просмотра данных, а мощный способ проверки корректности реализации бизнесhttp://логики, обнаружения аномалий в данных и воспроизведения дефектов. Умение быстро и точно писать запросы значительно сокращает время на анализ багов и повышает качество тестирования.