Какие знаешь ответы в БД?

Отличный и очень важный вопрос для QA. Понимание ответов (результатов) выполнения запросов в базе данных — это фундамент для тестирования работы с данными, проверки целостности и анализа проблем.

Основные типы ответов, которые возвращает СУБД, можно разделить на несколько категорий.

1. Результирующие наборы данных (Result Sets)

Это самый частый ответ на SELECT-запросы. Это таблица (виртуальная или материализованная), состоящая из строк и столбцов.

• Пустой набор (Empty Result Set): Запрос выполнился успешно, но не нашел ни одной строки, удовлетворяющей условию WHERE. Это НЕ ошибка, а валидный ответ. Например:

  SELECT * FROM users WHERE email = 'nonexistent@example.com';
  -- Возвращает 0 строк, пустой результат.
  

• Набор с данными: Одна или множество строк. Важно проверять сортировку (ORDER BY), лимит (LIMIT), группировку (GROUP BY), корректность агрегатных функций (COUNT, SUM, AVG).

2. Мета-информация о выполнении запроса

Это не сами данные, а информация о том, как запрос был выполнен. Ключевые показатели:

• Количество затронутых строк (Rows Affected): Возвращается после INSERT, UPDATE, DELETE, MERGE. Критически важно для проверки корректности операций изменения данных.

  UPDATE products SET price = price * 1.1 WHERE category = 'Electronics';
  -- Ответ БД: "Query OK, 15 rows affected".
  

    Здесь мы ожидаем конкретное число (например, 15). Если `0 rows affected`, это может означать, что условие `WHERE` не сработало.

• Время выполнения (Execution Time): Показатель для анализа производительности. Может возвращаться напрямую в клиенте (например, "Time: 0.125s").

3. Ответы, указывающие на успех операции

• Сообщения об успехе: Например, "Query OK", "CREATE TABLE", "COMMIT". Они подтверждают, что команда (DDL, DML) выполнена без ошибок.
• Сгенерированные ключи (Generated Keys): После INSERT в таблицу с автоинкрементным полем (например, AUTO_INCREMENT в MySQL, SERIAL в PostgreSQL, IDENTITY в SQL Server) БД возвращает сгенерированное значение. Это необходимо для последующих операций с этой записью.

  INSERT INTO orders (customer_id, amount) VALUES (123, 99.99);
  -- Ответ может быть: "Query OK, 1 row affected" + возврат ID = 457.
  

4. Ответы-ошибки (Error Responses)

Это одна из самых важных для QA категорий. Нам нужно не только проверять "счастливый путь", но и корректность реакции системы на ошибки БД.

• Синтаксические ошибки (Syntax Errors): SQLSTATE[42000]: Syntax error ... near 'FROMM users'.
• Ошибки целостности данных (Integrity Constraint Violations):

    *   **Нарушение уникальности (Duplicate Entry)**: `Duplicate entry 'test@mail.com' for key 'users.email_UNIQUE'`. Проверяем уникальные индексы и первичные ключи.
    *   **Нарушение внешнего ключа (Foreign Key Constraint Fails)**: `Cannot delete or update a parent row: a foreign key constraint fails`. Попытка удалить запись, на которую есть ссылки.
    *   **Ошибка NOT NULL**: `Column 'name' cannot be null`. Попытка вставить `NULL` в поле, где это запрещено.

• Ошибки доступа (Access Denied): ERROR 1045 (28000): Access denied for user 'reader'@'localhost'. Проверка прав пользователя/приложения.
• Ошибки "Не найдено" (Not Found): Иногда это не пустой результат, а явная ошибка, если запрос ожидает найти конкретную запись (в зависимости от логики приложения).
• Deadlock (Взаимоблокировка): Deadlock found when trying to get lock; try restarting transaction. Критическая ошибка параллельного доступа.

5. Прочие типичные ответы

• Подтверждение транзакции: COMMIT (успех), ROLLBACK (откат).
• Результат вызова хранимой процедуры/функции: Может быть как результирующий набор, так и выходные параметры, или скалярное значение.

Почему это важно для QA Engineer?

1. Верификация тестов: Мы сопоставляем фактический ответ БД с ожидаемым в тест-кейсе. Например, после теста "Удаление пользователя" мы выполняем SELECT и ожидаем пустой результат по этому ID.
2. Анализ логов и дефектов: Понимая сообщения об ошибках, мы можем точно локализовать проблему. "Ошибка дублирования email" сразу указывает на сценарий регистрации с существующим email.
3. Тестирование негативных сценариев: Мы специально создаем запросы, которые должны вызывать ошибки целостности, и проверяем, что приложение корректно их обрабатывает (показывает понятное сообщение пользователю, не падает).
4. Проверка производительности: Анализируя время выполнения и используя EXPLAIN (который сам возвращает специальный ответ — план запроса), мы находим "тяжелые" запросы.
5. Написание автотестов (API, E2E): В автотестах мы часто делаем проверки напрямую в БД. Например, после вызова API на создание заказа мы проверяем, что в таблице orders появилась одна новая запись (COUNT(*)), и ее статус равен 'pending'.

Пример в контексте тестирования:

-- Шаг теста: Попытка создать пользователя с email, который уже существует.
INSERT INTO users (email, name) VALUES ('existing@test.com', 'Duplicate User');

-- Ожидаемый ответ БД (для MySQL):
ERROR 1062 (23000): Duplicate entry 'existing@test.com' for key 'email_unique'

-- Действие QA:
-- 1. Проверить, что это сообщение об ошибке было корректно перехвачено бэкендом.
-- 2. Проверить, что фронтенд отобразил пользователю понятное сообщение (например, "Пользователь с таким email уже существует").
-- 3. Убедиться, что транзакция откатилась и в БД не создалась "битая" запись.

Таким образом, знание ответов БД — это не просто теория, а практический инструмент для построения эффективных проверок, глубокого анализа дефектов и обеспечения надежности данных в тестируемом приложении.