SQL для тестировщика

← назад к разделу

Всё, что помнит приложение — покупатели, заказы, товары, — хранится в базе данных. Интерфейс показывает лишь часть этого и может показать неправильно: на экране «Оплачено», а платёж не записан. Чтобы проверить, что данные сохранились и именно такими, какими нужно, тестировщик смотрит прямо в базу. Язык, на котором с базой разговаривают, — SQL.

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

Что такое база и таблицы

База данных чаще всего устроена как набор таблиц — как листы в Excel: колонки (столбцы) и строки. Например, таблица customer (покупатели) с колонками id, email, first_name, а таблица orders (заказы) — с колонками id, customer_id, total_amount, status, paid_at.

Тестировщик обычно только читает данные, а не меняет их, и читающий запрос начинается со слова SELECT.

SELECT: показать данные

Базовый запрос — «покажи такие-то колонки из такой-то таблицы»:

живой пример

SELECT id, first_name, email FROM customer;

FROM называет таблицу, SELECT — колонки. Звёздочка * значит «все»:

живой пример

SELECT * FROM orders;

WHERE: отобрать нужные строки

WHERE — фильтр: «покажи только строки, где условие выполняется». Самое частое дело тестировщика — найти в базе запись, которую он только что создал через интерфейс.

живой пример

SELECT * FROM customer WHERE email = 'a.volkova@example.com';

«Покажи покупателя с таким e-mail»: зарегистрировались на сайте — выполнили запрос — убедились, что запись появилась с верным именем.

Условия комбинируют:

живой пример

SELECT * FROM orders WHERE customer_id = 'cus-01' AND status = 'PAID';

«Оплаченные заказы покупателя cus-01»: так проверяют, что после оплаты статус стал PAID, а не остался PENDING_PAYMENT. Текст в условии — в одинарных кавычках и ровно в том написании, в каком его хранит приложение: PAID и paid для базы обычно разные значения, и запрос с неверным регистром молча вернёт ноль строк.

Экран сказал «оплачено» — проверяем

Случай с картинки. Сначала смотрим сам заказ:

живой пример

SELECT id, status, paid_at FROM orders WHERE id = 'ord-06';

Статус PENDING_PAYMENT, paid_at пустой (NULL — «значения нет»). Дальше — таблица платежей:

живой пример

SELECT count(*) FROM payments WHERE order_id = 'ord-06';

Ноль. Оплата на экране была, платёж в базе не появился — и дефект формулируется уже не как «неправильная надпись», а как «платёж не записан».

Ещё пара полезных вещей

• Подсчёт строк: SELECT count(*) FROM orders WHERE customer_id = 'cus-01'; — сколько заказов у покупателя. Так проверяют, что создался один заказ, а не два от двойного нажатия.
• Сортировка: ORDER BY created_at DESC в конце — «сначала самые новые»: так находят только что созданную запись.
• JOIN (связка таблиц). Заказ хранит customer_id, а почта покупателя лежит в customer; JOIN соединяет таблицы, чтобы увидеть их вместе. Синтаксис подсматривают — на старте важно знать, что так можно.

Осторожно с боевой базой

Два правила безопасности:

• По возможности работайте с тестовой базой, а не с боевой, где реальные пользователи; если доступ есть только к боевой — не выполняйте ничего, в чём не уверены.
• Тестировщик почти всегда только читает (SELECT). Команды, которые меняют данные (UPDATE, DELETE), трогать без явной необходимости и понимания нельзя — можно испортить данные.

Где это применяется

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

Спотыкаются чаще всего на страхе: SQL кажется «программированием». На деле для проверок хватает SELECT ... WHERE — читается почти как обычная фраза.

Глубже: реляционные и NoSQL базырасширенное

База, с которой вы работали выше, реляционная: таблицы со строками и столбцами, связи по ключам, язык SQL, строгая схема, где у каждой колонки свой тип. Так устроены PostgreSQL, MySQL, Oracle и SQL Server, и в них живут заказы, платежи и всё, где важны связи и точность.

Нереляционные базы, NoSQL, хранят данные иначе. Документные, MongoDB, держат записи как JSON-документы с разной структурой, что удобно для карточек товаров с разными полями. Ключ-значение, Redis, это быстрый словарь в памяти для кэша, сессий и счётчиков. Поисковые, Elasticsearch, ищут по тексту. Колоночные, ClickHouse, считают отчёты по миллиардам строк. Для тестировщика разница практическая: в MongoDB нет JOIN и схема не защитит от лишнего поля, в Redis данные могут исчезнуть при перезапуске, если так настроено, а запрос пишут не на SQL, а на языке конкретной базы. Проверка «что реально сохранилось» нужна везде, меняется только инструмент.

Коротко

• Данные лежат в таблицах; тестировщику нужен один тип запросов — читающий SELECT.
• WHERE отбирает строки, и текст в нём — в одинарных кавычках и в том же написании, что в базе.
• Проверка «экран против базы» — два запроса: сам заказ и связанная с ним таблица платежей.
• NULL — не ноль и не пустая строка, а «значения нет»: пустой paid_at значит, что оплату не проставляли.
• count(*) ловит дубли от двойного нажатия: ждали одну строку, а их две.
• Реляционные базы это таблицы, ключи и SQL; документные хранят JSON без жёсткой схемы, ключ-значение это кэш и сессии, поисковые ищут текст; проверять сохранённое надо в любой.

Что почитать дальше

• SELECT: выбрать, отфильтровать, отсортировать — те же SELECT и WHERE, подробно и с задачами.
• JOIN: собрать данные из нескольких таблиц — как увидеть заказ вместе с покупателем.
• Что такое база данных и таблицы — начало цикла «SQL с нуля».
• Кроссбраузерное и мобильное тестирование — следующая тема раздела.