Перейти на PRO

Какие основные методики тестирования баз данных существуют?

Тип вопроса: Базы данных и SQL Вероятность: 10% Категория: QA Тестировщик

Ответ

Тестирование БД включает несколько ключевых направлений:

  1. Тестирование целостности данных:

    • Проверка ограничений (PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, CHECK).
    • Валидация связей между таблицами. 
      -- Пример: Проверка отсутствия "битых" ссылок (orphaned records)
SELECT * FROM orders o
WHERE NOT EXISTS (
SELECT 1 FROM customers c WHERE c.id = o.customer_id
);

  2. Тестирование транзакций:

    • Проверка ACID-свойств (Атомарность, Согласованность, Изолированность, Долговечность).
    • Тестирование откатов (rollback) и конкурентного доступа (deadlocks).

  3. Тестирование производительности:

    • Анализ и оптимизация запросов (EXPLAIN PLAN).
    • Проверка эффективности индексов.
    • Нагрузочное тестирование (объем данных, количество соединений).

  4. Тестирование миграций и обновлений:

    • Проверка скриптов обновления схемы БД (DDL).
    • Тестирование миграции данных и отката (rollback) на предыдущую версию.

  5. Тестирование безопасности:

    • Проверка на уязвимости (например, SQL-инъекции).
    • Валидация прав доступа пользователей и ролей (GRANT/REVOKE).

  6. Тестирование резервного копирования и восстановления:

    • Проверка процедур бэкапа.
    • Восстановление данных из резервной копии и проверка их целостности.

Ответ 18+ 🔞

А, так вот ты о чём, про базы данных! Ну, слушай, это ж целая наука, блядь, не просто так таблички нарисовать. Ёпта, народ думает — создал табличку users, вставил пару записей и всё, работает. А потом приходит пиздец с орфан-рекордами и дедлоками, и волосы дыбом, в рот меня чих-пых!

В общем, если по-человечески, то вот на что надо смотреть, чтобы не обосраться в итоге:

  1. Целостность, мать её, данных. Это святое, блядь. Ты ж не хочешь, чтобы заказ висел в воздухе, а клиента, который его сделал, уже нет в системе? Вот именно. Поэтому все эти ключи — PRIMARY, FOREIGN — должны работать как швейцарские часы, а не как мои старые костыли. И ограничения (NOT NULL, UNIQUE) — чтобы дурака не пропустить, который попробует впихнуть ерунду.

    -- Вот смотри, классика жанра: ищем потеряшек, которые ссылаются в никуда.
SELECT * FROM orders o
WHERE NOT EXISTS (
    SELECT 1 FROM customers c WHERE c.id = o.customer_id
);

    Если этот запрос что-то вернёт — пиши пропало, связь поехала. Надо чинить, блядь.

  2. Транзакции, ёперный театр. Тут главное — ACID. Атомарность, чтобы либо всё выполнилось, либо нихуя. Представь: перевод денег. Списали с одного счёта, а на второй не зачислили — и деньги улетели в черную дыру. Согласованность, чтобы после транзакции база не превратилась в бред сумасшедшего. Изолированность — чтобы десять потоков одновременно не начали друг другу мозги ебать. И долговечность — чтобы после слова «готово» данные не испарились от чиха сервера. И да, дедлоки — это когда два процесса схватили друг друга за горло и ждут, пока кто-то первый сдохнет. Красота!

  3. Производительность, или «Почему всё тормозит?» Тут, чувак, начинается магия. Запрос выполняется три часа? Пора смотреть EXPLAIN PLAN и видеть, как СУБД сама себя ебёт полной табличной сканией на миллионе записей. Индексы — они как костыли для быстрого поиска, но если их наставить как попало, то при вставке будет такая жесть, хуй в горле встанет. А нагрузочное тестирование — это когда ты пытаешься понять, сдохнет ли всё, если пользователей станет не десять, а десять тысяч.

  4. Миграции и обновления. О, это отдельный вид искусства, блядь. Накатил скрипт на прод — а он, сука, все данные к хуям собачьим стёр. Или откат на предыдущую версию не работает. Поэтому миграции тестируют в песочнице до посинения, проверяя и вперёд, и назад. Правило простое: если нет отката — нет и обновления, иди нахуй со своим скриптом.

  5. Безопасность, а то проебём всё. SQL-инъекции — это когда какой-то умник через форму входа может сделать ' OR '1'='1 и зайти как админ. Надо тестировать, что все входные данные экранируются так, что хоть волком вой. И права доступа (GRANT/REVOKE) — чтобы уборщица через веб-интерфейс не могла всю базу дропнуть, потому что ей «показалось».

  6. Бэкапы и восстановление. Самый важный и самый похуистичный пункт, пока не случится пиздец. Бэкапы делаются? Отлично. А работают ли? А сможем ли мы из этой кучи файлов собрать живущую систему? Проверять это надо не тогда, когда сервак уже лёг, а заранее. Восстановились, проверили целостность — и только тогда можно спать спокойно. Или не спать, потому что всегда найдётся, что ещё потестировать.

Вот так вот, если коротко. А то некоторые думают, что тестирование БД — это запустить пару запросов и посмотреть, не падает ли. Не, ребята, это целая вселенная, где один недосмотр может стоить овердохуища нервов и денег.

© ХакСобесов, 2026
support@hacksobesov.com