Как создавал строчку в базе данных

Подход к созданию записи в базе данных с точки зрения QA Engineer

Создание записи (строчки) в базе данных — это операция INSERT, которая является фундаментальной для тестирования. Моя работа как QA Engineer заключается не в прямом выполнении SQL-команд в продакшн-среде (это ответственность разработчиков или DBA), а в верификации корректности этой операции в рамках тестирования приложения, API или ETL-процессов.

Основные аспекты, которые я проверяю при создании записи:

1. Функциональная корректность:

    *   Запись создается с корректными значениями полей, переданными от пользовательского интерфейса или API.
    *   Соблюдаются **ограничения целостности данных**: `PRIMARY KEY`, `FOREIGN KEY`, `UNIQUE` constraints.
    *   Обрабатываются обязательные (`NOT NULL`) и необязательные поля.
    *   Проверяется кодировка данных (кириллица, эмодзи).

1. Валидация бизнес-логики:

    *   Применяются ли триггеры (`TRIGGERS`) на вставку? Например, автоматическое проставление даты создания (`created_at`).
    *   Корректно ли рассчитываются вычисляемые поля.
    *   Синхронно ли обновляются данные в связанных таблицах (денормализованные данные или кэш).

1. Тестирование "граничных" случаев и ошибок:

    *   Попытка создать дубликат по уникальному полю — должно возвращаться ожидаемое сообщение об ошибке.
    *   Вставка `NULL` в обязательное поле.
    *   Передача данных, превышающих длину поля (`VARCHAR(255)`).
    *   Проверка обработки некорректных типов данных (строка вместо числа).
    *   Проверка отката транзакции (`ROLLBACK`) при ошибке в середине сложной операции.

Практические методы проверки:

• Прямые SQL-запросы в тестовой БД: Для предварительной проверки или когда UI/API еще не готовы.

  -- Пример INSERT-запроса для проверки
  INSERT INTO users (username, email, created_at)
  VALUES ('test_user', 'test@example.com', NOW());
  -- Затем проверяем, что запись появилась
  SELECT * FROM users WHERE username = 'test_user';
  

• Через пользовательский интерфейс приложения: Самый распространенный сценарий. Заполняю форму и нажимаю "Сохранить", затем проверяю, что данные отобразились в UI и корректно легли в БД.

• Через API (например, REST или GraphQL): Часто используется в автотестах.

  // Пример для REST API с использованием JavaScript (например, в тесте на Cypress или Supertest)
  cy.request('POST', '/api/v1/users', {
      username: 'qa_engineer',
      email: 'qa@company.com'
  }).then((response) => {
      expect(response.status).to.eq(201); // Проверка статуса Created
      expect(response.body.id).to.be.a('number'); // Проверка, что присвоен ID
  });
  

• Проверка в логах БД: Для отслеживания точного запроса, который отправляет приложение.

• Использование инструментов мониторинга: Например, проверка, что счетчик INSERT-операций в метриках (Prometheus) увеличился.

Критически важные нефункциональные проверки:

• Производительность: Сколько времени занимает вставка? Не деградирует ли время при росте объема данных (индексы, партиционирование).
• Безопасность: Защита от SQL-инъекций. Проверяю, что приложение корректно экранирует пользовательский ввод. Это можно проверить, попытавшись передать в поле username значение test'); DROP TABLE users;--.
• Блокировки (LOCK) и конкурентный доступ: Что произойдет, если два пользователя попробуют создать запись с одинаковым уникальным ключом одновременно? Проверяю, что приложение обрабатывает конфликты и deadlock'и адекватно, не "падает".
• Восстановление после сбоя: Как ведет себя система при недоступности БД в момент выполнения INSERT?

Таким образом, моя задача как QA — смоделировать все возможные сценарии создания записи: как штатные, так и исключительные. Я должен убедиться, что операция INSERT выполняется не только технически, но и в полном соответствии с бизнес-требованиями, обеспечивая целостность, безопасность и надежность данных в системе. Часто для этого я пишу автотесты (например, на Python с использованием pytest и библиотек для работы с БД), которые регулярно выполняются в CI/CD пайплайне, чтобы предотвратить регрессию.