Тестирование баз данных (Database)
База данных - представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ).
База данных является одной из неизбежных частей программного приложения. Неважно, будет ли это веб, настольный или мобильный, клиент-серверный, одноранговый, корпоративный или индивидуальный бизнес; База данных требуется везде на бэкенде. Точно так же, будь то здравоохранение, финансы, лизинг, розничная торговля, почтовое приложение или управление космическим кораблем; База данных всегда находится в действии за кулисами.
Зачем тестировать БД?
1. Отображение данных (Data Mapping)
В программных системах данные часто перемещаются туда и обратно из UI (пользовательского интерфейса) в серверную БД и наоборот. Итак, вот некоторые аспекты, на которые стоит обратить внимание:
Проверьте, сопоставляются ли поля в формах пользовательского интерфейса/внешнего интерфейса с соответствующими полями в таблице БД. Обычно эта информация о сопоставлении определяется в документах с требованиями;
Всякий раз, когда определенное действие выполняется во внешнем интерфейсе приложения, соответствующее действие CRUD (создание, извлечение, обновление и удаление) вызывается в бэкенде. Тестировщик должен будет проверить, вызывается ли правильное действие и является ли вызванное действие само по себе успешным или нет.
2. Проверка требований ACID (ACID Properties Validation)
Каждая транзакция, которую выполняет БД, должна соответствовать этим четырем свойствам:
Атомарность (Atomicity): гарантирует, что каждая транзакция будет выполнена полностью или не будет выполнена совсем. Не допускаются промежуточные состояния;
Согласованность (Consistency): транзакция, достигающая своего нормального завершения (EOT - end of transaction, завершение транзакции) и, тем самым, фиксирующая свои результаты, сохраняет согласованность базы данных. Другими словами, каждая успешная транзакция по определению фиксирует только допустимые результаты;
Изолированность (Isolation): во время выполнения транзакции параллельные транзакции не должны оказывать влияния на ее результат;
Постоянство/надежность (Durability): если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя.
3. Целостность данных (Data Integrity)
Для любой операции CRUD обновленные и самые последние значения/статус общих данных должны отображаться во всех формах и экранах. Значение не должно обновляться на одном экране и отображать более старое значение на другом.
Когда приложение находится в процессе выполнения, конечный пользователь в основном использует операции «CRUD».
CRUD - акроним, обозначающий четыре базовые функции, используемые при работе с базами данных: создание (англ. create), чтение (read), модификация (update), удаление (delete). В SQL этим функциям, операциям соответствуют операторы Insert (создание записей), Select (чтение записей), Update (редактирование записей), Delete (удаление записей). В системах, реализующих доступ к базе данных через API в стиле REST, эти функции реализуются зачастую (но не обязательно) через HTTP-методы PUT, POST, GET, PATCH, DELETE.
Любая операция с базой данных, выполняемая конечным пользователем, всегда является одной из четырех вышеперечисленных.
Поэтому разработайте свои тестовые примеры БД таким образом, чтобы включить проверку данных во всех местах, где они появляются, чтобы увидеть, постоянно ли они одинаковы.
4. Соответствие бизнес-правилам (Business Rule Conformity)
Более сложная база данных означает более сложные компоненты, такие как реляционные ограничения, триггеры, хранимые процедуры и т. д. Поэтому тестировщикам придется придумывать соответствующие SQL-запросы для проверки этих сложных объектов.
Что тестировать?
1. Транзакции
2. Схемы базы данных
Схема базы данных - это не что иное, как формальное определение того, как данные будут организованы внутри БД. Чтобы проверить это:
Определите требования, на основе которых работает база данных. Образец требований:
Первичные ключи должны быть созданы до создания любых других полей;
Внешние ключи должны быть полностью проиндексированы для легкого извлечения и поиска;
Имена полей, начинающиеся или заканчивающиеся определенными символами;
Поля с ограничением, что определенные значения могут или не могут быть вставлены.
Используйте один из следующих методов в зависимости от релевантности:
SQL-запрос для проверки схемы.
Регулярные выражения для проверки имен отдельных полей и их значений;
Такие инструменты, как SchemaCrawler.
3. Триггеры
Когда определенное событие происходит в определенной таблице, часть кода (триггер) может быть автоматически проинструктирована для выполнения.
Например, новый ученик присоединился к школе. Ученик посещает 2 класса: математику и естествознание. Ученик добавлен в таблицу учеников. Триггер может добавить учащегося в соответствующие предметные таблицы, как только он будет добавлен в студенческую таблицу.
Обычный метод тестирования состоит в том, чтобы сначала независимо выполнить SQL-запрос, встроенный в триггер, и сравнить фактический результат с ожидаемым.
Тестирование белого ящика : заглушки и драйверы используются для вставки, обновления или удаления данных, которые могут привести к срабатыванию триггера. Основная идея состоит в том, чтобы просто протестировать БД в одиночку еще до того, как будет выполнена интеграция с внешним интерфейсом (UI).
Тестирование черного ящика :
а) Начиная с UI и БД теперь доступна интеграция; мы можем вставлять/удалять/обновлять данные из внешнего интерфейса таким образом, чтобы вызывался триггер. После этого операторы Select можно использовать для получения данных БД, чтобы увидеть, успешно ли триггер выполнил намеченную операцию.
б) Второй способ проверить это - напрямую загрузить данные, которые вызовут триггер, и посмотреть, работает ли он так, как задумано.
4. Хранимые процедуры
Хранимые процедуры более или менее похожи на пользовательские функции. Они могут быть вызваны операторами вызова процедуры/выполнения процедуры, а выходные данные обычно представлены в виде наборов результатов.
Они хранятся в СУБД и доступны для приложений.
Тестирование белого ящика: заглушки используются для вызова хранимых процедур, а затем результаты проверяются на соответствие ожидаемым значениям.
Тестирование «черного ящика»: выполните операцию из внешнего интерфейса (UI) приложения и проверьте выполнение хранимой процедуры и ее результаты.
5. Ограничения полей
Значение по умолчанию, уникальное значение и внешний ключ (Default value, Unique value, and Foreign key):
Выполните интерфейсную операцию, которая проверяет условие объекта базы данных.
Подтвердите результаты с помощью SQL-запроса.
Проверить значение по умолчанию для определенного поля довольно просто. Это часть проверки бизнес-правил. Вы можете сделать это вручную или использовать такие инструменты, как QTP. Вручную вы можете выполнить действие, которое добавит значение, отличное от значения поля по умолчанию, из внешнего интерфейса и посмотреть, не приведет ли это к ошибке.
Проверка уникального значения может быть выполнена точно так же, как мы делали это для значений по умолчанию. Попробуйте ввести значения из пользовательского интерфейса, которые будут нарушать это правило, и посмотрите, не появится ли ошибка.
Для проверки ограничения внешнего ключа используйте загрузки данных, которые напрямую вводят данные, нарушающие ограничение, и посмотрите, ограничивает ли их приложение или нет. Наряду с загрузкой данных из серверной части выполняйте также операции пользовательского интерфейса фронтенда таким образом, чтобы нарушить ограничения, и посмотрите, отображается ли соответствующая ошибка.
Автоматизация
Автотесты в БД обычно пишутся на хранимые процедуры и джобы и похожи на автотесты API, только транспортный уровень - драйвер БД, и добавляются транзакции и роллбэки в тирдаун секции.
Источники:
Доп. материал:
Last updated