С какими системами управления базами данных (СУБД) вы работали в контексте тестирования?

«С какими системами управления базами данных (СУБД) вы работали в контексте тестирования?» — вопрос из категории Базы данных и SQL, который задают на 24% собеседований AQA / Automation. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

В рамках тестирования я работал с различными СУБД для проверки корректности данных, выполнения бэкенд-тестов и настройки тестовых окружений.

Реляционные СУБД:

  • PostgreSQL / MySQL: Наиболее частые в моей практике. Я писал сложные SQL-запросы для подготовки тестовых данных, валидации результатов работы API (проверял, что данные корректно записались в БД) и очистки базы после тестов. Использовал транзакции в автотестах для изоляции тестовых данных.
  • SQLite: Применял для модульного тестирования слоя доступа к данным (DAO/Repository) в изоляции, благодаря её легкости и работе с файлами.

Пример SQL-запроса для валидации данных после теста API:

-- После вызова POST /api/orders проверяем, что заказ создался
SELECT 
    o.id, o.status, o.total_amount, u.email 
FROM 
    orders o
    JOIN users u ON o.user_id = u.id
WHERE 
    o.external_id = 'test_order_123' -- ID, переданный в API
    AND o.status = 'PENDING';
-- Ожидаем ровно одну запись с определенными значениями полей

NoSQL СУБД:

  • MongoDB: Тестировал приложения, работающие с документной моделью данных. Проверял корректность структуры документов после операций, работу агрегационных пайплайнов. Для автоматизации использовал драйвер pymongo в Python-скриптах.
  • Redis: Работал с ним как с кешем и брокером сообщений. Писал тесты, которые проверяли инвалидацию кеша, наличие определенных ключей после выполнения операций и корректность работы pub/sub механизмов.

Инструменты и подходы:

  • Миграции базы данных (Liquibase, Flyway): Использовал для приведения тестовой БД в нужное состояние перед запуском тестового набора.
  • Дампы и сиды: Подготавливал фиксированные наборы тестовых данных (fixtures) для воспроизводимости тестов.
  • Docker: Часто разворачивал изолированные контейнеры с нужной СУБД (например, postgres:15-alpine) для запуска автотестов в CI/CD пайплайне, чтобы избежать зависимостей от общей тестовой БД.

Пример Python-кода для проверки данных в PostgreSQL с использованием библиотеки psycopg2:

import psycopg2

def assert_order_in_db(order_external_id, expected_status):
    conn = psycopg2.connect(
        host="localhost",
        database="test_db",
        user="qa_user",
        password="qa_pass"
    )
    cursor = conn.cursor()
    query = """
        SELECT status FROM orders WHERE external_id = %s;
    """
    cursor.execute(query, (order_external_id,))
    result = cursor.fetchone()
    cursor.close()
    conn.close()

    assert result is not None, f"Order {order_external_id} not found in DB"
    actual_status = result[0]
    assert actual_status == expected_status, 
           f"Order status mismatch. Expected: {expected_status}, Actual: {actual_status}"

# Использование в тесте
test_order_id = "auto_test_987"
# ... вызов API, который создает заказ ...
assert_order_in_db(test_order_id, "CREATED")

Работа с БД — неотъемлемая часть тестирования бэкенда, требующая понимания как самой СУБД, так и способов её интеграции в автоматизированный процесс проверки.