Основываясь на функции и структуре базы данных, тестирование БД можно разбить на три категории:

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

Тестирование структурной базы данных

Структурная проверка базы данных включает проверку тех компонентов базы данных, которые не подвержены конечным пользователям. Он включает в себя все компоненты репозитория, которые используются для хранения данных и не изменяются конечными пользователями. Администраторы баз данных с хорошей командой над хранимыми процедурами SQL и другими концепциями обычно выполняют это тестирование.

Обсуждаются общие компоненты, проверенные в отношении структурного тестирования:

Тестирование схемы / сопоставления

Он включает в себя проверку объектов front-end-приложения при сопоставлении объектов базы данных.

При тестировании схемы:

  • Иногда бывает, что объекты приложения конечного пользователя неправильно отображаются или совместимы с объектами базы данных. Поэтому требуется проверка правильности различных форматов схем, связанных с базами данных.
  • Требуется найти необработанные объекты в базе данных, например таблицы, представления, столбцы и т. д.

На рынке существуют различные инструменты, которые можно использовать для выполнения сопоставления объектов в схемах.

Пример. В Microsoft SQL Server тестер может писать простые запросы для проверки и проверки схем в базе данных.

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

Тестирование хранимых процедур и просмотров

В этом тесте тестер гарантирует, что ручное выполнение хранимых процедур и представлений генерирует требуемый результат.

Тестер обеспечивает:

  • Если он разрешает выполнение необходимых триггеров, как ожидалось.
  • Если команда разработчиков покрыла все циклы и условия, передав входные данные приложениям в процедуры.
  • Если в базе данных есть неиспользуемые хранимые процедуры.
  • Операции TRIM применяются правильно, когда данные извлекаются из необходимых таблиц в базе данных.
  • Проверка общей интеграции модулей хранимой процедуры в соответствии с требованиями тестируемого приложения.
  • Исключены механизмы обработки ошибок и ошибок.

Наиболее распространенными инструментами, которые используются для тестирования хранимых процедур, являются LINQ , SP Test tool и т. д.

Тестирование триггеров

При тестировании триггеров тестер должен обеспечить следующее:

  • Независимо от того, соблюдаются ли правила кодирования во время фазы кодирования триггеров.
  • См. Выполняемые триггеры соответствуют требуемым условиям.
  • Будет ли триггер обновлять данные правильно, как только они будут выполнены.
  • Проверка функции обновления / вставки / удаления триггеров по тестируемому приложению.

Тестирование таблиц и столбцов

Ключевыми областями, охваченными этим тестированием, являются:

  • Проверка типов данных в базе данных на значения полей в интерфейсном приложении.
  • Проверка длины поля данных в базе данных на длину типов данных в приложении.
  • Проверка наличия каких-либо неотображаемых таблиц или столбцов в базе данных из объектов поля приложения.
  • Соглашения об именах таблиц и столбцов базы данных проверяются, если они соответствуют требованиям бизнеса или нет.
  • Проверка ключей и индексов в базе данных, т. е. Первичные и внешние ключи в таблицах определяются в соответствии с требованиями.
  • Проверьте, являются ли первичные ключи и их соответствующие внешние ключи одинаковыми в двух таблицах.
  • Проверяются уникальные и NOT NULL характеристики ключей.
  • Длина и тип данных ключей и индексов поддерживаются в соответствии с требованиями.

Проверка сервера базы данных

Проверка сервера базы данных включает проверку -

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

Функциональное тестирование

Функциональное тестирование выполняется с учетом точки зрения конечного пользователя; независимо от того, соответствуют ли требуемые транзакции и операции конечным пользователям спецификациям бизнеса.

Тестирование Black Box

Тестирование Black Box включает проверку интеграции базы данных для проверки функциональности. Тесты просты и используются для проверки входящих и исходящих данных из функции.

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

Его преимущества заключаются в следующем:

  • Это довольно просто и выполняется на ранних стадиях развития.
  • Стоимость разработки тестов меньше по сравнению с тестированием белого ящика.

Его недостатки заключаются в следующем:

  • Невозможно обнаружить несколько ошибок
  • Неизвестно, сколько программ нужно протестировать.

Тестирование белого ящика

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

Он выполняет модульное тестирование функций базы данных, триггеров, представлений, SQL-запросов и т. д. Этот тип тестирования проверяет таблицы базы данных, модели данных, схему базы данных и т. д. Он проверяет правила ссылочной целостности. Он выбирает значения таблицы по умолчанию для проверки согласованности базы данных.

Наиболее распространенными методами, используемыми для тестирования белого ящика, являются охват условий, охват решений, охват заявлений и т. д.

Ошибки кодирования могут быть обнаружены при тестировании с использованием белого ящика, поэтому внутренние ошибки в базе данных могут быть устранены. Ограничение тестирования белых ящиков заключается в том, что инструкции SQL не покрываются.

Нефункциональное тестирование

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

Тестирование нагрузки

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

При тестировании нагрузки тестер проверяет -

  • Время отклика для выполнения транзакций для нескольких удаленных пользователей.
  • Время, затрачиваемое базой данных на выбор конкретных записей.

Примеры нагрузочного тестирования в разных типах тестирования-

  • Выполнение большинства использованных транзакций неоднократно, чтобы увидеть производительность системы баз данных.
  • Загрузка серии больших файлов из Интернета.
  • Одновременное выполнение нескольких приложений на компьютере или сервере.

Стресс-тестирование

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

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

Наиболее часто используемые инструменты для тестирования напряжения - LoadRunner и WinRunner .

Возьмем пример стресс-тестирования. Приложение CRM может принимать максимальную нагрузку пользователя в 50000 одновременно работающих пользователей. Предположим, что вы увеличиваете нагрузку до 51000 и выполняете некоторые транзакции, такие как обновление записей или добавление записи. Как только вы выполните транзакцию, приложение может синхронизироваться с системой базы данных. Таким образом, следующий тест должен выполняться при нагрузке пользователя 52000. Иногда стресс-тестирование также называется усталостным тестированием .