Приведи пример тест кейса для тестирования баз данных

Пример тест-кейса для тестирования баз данных

Тестирование баз данных (Database Testing) — критически важная часть процесса обеспечения качества, особенно для систем, где данные являются ключевым активом. Это тестирование выходит за рамки простого UI и направлено на проверку правильности, целостности, консистентности и производительности данных в самой базе. Ниже приведен подробный пример тест-кейса для проверки функциональности CRUD (Create, Read, Update, Delete) операций над таблицей пользователей в системе.

Тест-кейс: Проверка операции UPDATE для поля email в таблице users

• ID: DB_FUNC_UPDATE_001
• Модуль: База данных / Функциональное тестирование
• Приоритет: Высокий
• Предусловия:

    1.  База данных подключена и доступна (например, PostgreSQL 14).
    2.  Таблица `users` существует и имеет структуру, соответствующую схеме ниже.
    3.  В таблице присутствует хотя бы одна запись с `id = 1` и исходным email `old_email@example.com`.

• Постусловие: Проверить, что изменения в данных соответствуют бизнес-логике и не нарушили связанные данные. В данном случае — проверить триггеры или связанные таблицы на консистентность.

Схема таблицы users:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    username VARCHAR(50) NOT NULL UNIQUE,
    email VARCHAR(100) NOT NULL UNIQUE,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    is_active BOOLEAN DEFAULT TRUE
);

---

Описание шагов тестирования и ожидаемых результатов:

1. Шаг: Получить исходное состояние записи id=1 перед изменением.

    *   **Действие:** Выполнить SQL-запрос `SELECT`.

```sql
SELECT id, username, email FROM users WHERE id = 1;
```

    *   **Ожидаемый результат:** Запись возвращается. Например: `(1, 'john_doe', 'old_email@example.com')`.

1. Шаг: Выполнить операцию UPDATE, изменяя email на новый, уникальный адрес.

    *   **Действие:** Выполнить SQL-запрос `UPDATE`.

```sql
UPDATE users SET email = 'new_email@example.com' WHERE id = 1;
```

    *   **Ожидаемый результат:** Запрос завершается успешно. Возвращается сообщение об успешном обновлении одной строки (например, `UPDATE 1`).

1. Шаг: Проверить, что данные были обновлены корректно в целевой таблице users.

    *   **Действие:** Выполнить `SELECT` для проверки измененного поля.

```sql
SELECT email FROM users WHERE id = 1;
```

    *   **Ожидаемый результат:** Возвращается новое значение email: `new_email@example.com`.

1. Шаг: Проверить соблюдение ограничения уникальности (UNIQUE CONSTRAINT) для поля email.

    *   **Действие:** Попытаться создать или обновить другую запись, используя тот же новый email.

```sql
-- Попытка обновить другого пользователя на уже занятый email
UPDATE users SET email = 'new_email@example.com' WHERE id = 2;
```

    *   **Ожидаемый результат:** Запрос завершается с **ошибкой**, нарушающей ограничение уникальности (например, `duplicate key value violates unique constraint "users_email_key"`). Это подтверждает, что бизнес-правило работает.

1. Шаг: Проверить интеграционную целостность (Data Integrity) (если есть связанные таблицы).

    *   **Предположим,** существует таблица `orders`, связанная по `user_id`.

```sql
CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    user_id INTEGER REFERENCES users(id),
    total_amount DECIMAL
);
```

    *   **Действие:** Проверить, что ссылки на `user_id = 1` в таблице `orders` остались корректными после UPDATE. UPDATE поля `email` не должен затрагивать связанные данные.

```sql
SELECT COUNT(*) FROM orders WHERE user_id = 1;
```

    *   **Ожидаемый результат:** Количество записей остается неизменным (например, `5`). Это подтверждает, что операция не нарушила **referential integrity**.

1. Шаг: Проверить производительность (Performance) операции (опционально, но важно для нагрузочного тестирования).

    *   **Действие:** Замерить время выполнения UPDATE запроса под нагрузкой (например, в цикле или при высокой конкуренции).
    *   **Ожидаемый результат:** Время выполнения остается в допустимых пределах (например, < 100ms для единичной операции), что говорит об эффективности индексов и отсутствии блокировок (**deadlocks**).

---

Ключевые аспекты тестирования баз данных, отраженные в этом кейсе:

• Проверка бизнес-правил: Ограничение UNIQUE является бизнес-правилом, которое должно строго соблюдаться.
• Проверка целостности данных: Мы убедились, что операция не "сломала" связи между таблицами.
• Проверка точности данных: Мы подтвердили, что запрос изменил именно то поле и именно у той записи, которую требовалось.
• Использование прямых SQL-запросов: Тестирование БД часто требует работы на уровне SQL, минуя интерфейс приложения, чтобы исключить влияние слоя приложения на результат.
• Взаимодействие с другими типами тестирования: Этот функциональный тест-кейс может быть расширен для нагрузочного тестирования (многопоточный UPDATE), тестирования безопасности (попытка UPDATE через инъекцию) или регрессионного тестирования после изменения схемы БД.

Таким образом, даже простой тест-кейс на UPDATE операцию должен быть многогранным и проверять не только сам запрос, но и его влияние на окружающую среду данных, ограничения и производительность системы.