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

редактировать

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

Содержание

  • 1 Цели
  • 2 Типы тестов и процессов
    • 2.1 Черный ящик
    • 2.2 Белый ящик
    • 2.3 Подход WHODATE
  • 3 Четыре этапа
  • 4 Базовые методы
  • 5 См. Также
  • 6 Ссылки
  • 7 Внешние ссылки

Цели

Базы данных, совокупность взаимосвязанных файлов на сервере, хранящая информацию, может не иметь дело с одним и тем же типом данных, т.е. базы данных могут быть разнородными. В результате в больших системах баз данных могут возникать многие виды ошибок внедрения и интеграции , которые негативно влияют на производительность, надежность, согласованность и безопасность системы. Таким образом, важно протестировать, чтобы получить систему базы данных, которая удовлетворяет свойствам ACID (атомарность, согласованность, изоляция и долговечность) система управления базами данных.

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

  • Данные критически важны с точки зрения бизнеса. Такие компании, как Google или Symantec, которые связаны с хранилищем данных, должны иметь надежную и согласованную систему баз данных. Если операции с базой данных, такие как вставка, удаление и обновление, выполняются без предварительной проверки базы данных на согласованность, компания рискует вывести из строя всю систему.
  • Некоторые компании имеют разные типы баз данных, а также разные цели и миссии. Чтобы достичь уровня функциональности, соответствующего указанным целям, им необходимо протестировать свою систему баз данных.
  • Текущий подход к тестированию может быть недостаточным, когда разработчики формально тестируют базы данных. Однако этот подход недостаточно эффективен, поскольку разработчики баз данных могут замедлить процесс тестирования из-за недостатков связи. Представляется целесообразным создать отдельную группу по тестированию баз данных.
  • Тестирование баз данных в основном связано с поиском ошибок в базах данных для их устранения. Это улучшит качество базы данных или веб-системы.
  • Тестирование базы данных следует отличать от стратегий решения других проблем, таких как сбои базы данных, неправильные вставки, удаления или обновления. Здесь рефакторинг базы данных - это эволюционный метод, который может применяться.

Типы тестов и процессов

Тестирование черного и белого ящиков в тесте базы данных

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

Черный ящик

Тестирование черного ящика включает в себя тестирование интерфейсов и интеграцию базы данных, который включает в себя:

  1. Отображение данных (включая метаданные )
  2. Проверка входящих данных
  3. Проверка исходящих данных из функций запроса
  4. Различные методы, такие как метод построения графиков причинно-следственных связей, разделение эквивалентности и анализ граничных значений.

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

Плюсы и минусы тестирования черного ящика включают: Создание тестовых примеров при тестировании методом черного ящика довольно просто. Их создание полностью не зависит от разработки программного обеспечения и может быть выполнено в ранняя стадия развития. Как следствие, программист лучше знает, как проектировать приложение базы данных, и тратит меньше времени на отладку. Стоимость разработки тестовых примеров черного ящика ниже, чем разработка тестовых примеров белого ящика. Главный недостаток тестирования черного ящика заключается в том, что неизвестно, какая часть программы тестируется. Кроме того, некоторые ошибки не могут быть обнаружены.

Белый ящик

Тестирование белого ящика в основном касается внутренней структуры базы данных. Детали спецификации скрыты от пользователя.

  1. Он включает в себя тестирование триггеров базы данных и логических представлений, которые будут поддерживать рефакторинг базы данных.
  2. Он выполняет модульное тестирование функций базы данных, триггеров, представлений, SQL запросов и т. Д.
  3. Он проверяет таблицы базы данных, модели данных, схему базы данных и т. Д.
  4. Он проверяет правила ссылочной целостности.
  5. Он выбирает значения таблиц по умолчанию для проверки согласованности базы данных.
  6. При тестировании методом белого ящика используются следующие методы: покрытие условий, покрытие решений, покрытие операторов, цикломатическая сложность.

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

Подход WHODATE

Подход WHODATE для преобразования операторов SQL

При создании тестовых примеров для тестирования базы данных семантика оператора SQL должна быть отражена в тестовых примерах. Для этой цели используется метод, называемый техникой применения базы данных WHite bOx «(WHODATE)». Как показано на рисунке, операторы SQL независимо конвертируются в операторы GPL с последующим традиционным тестированием методом белого ящика для создания тестовых примеров, включающих семантику SQL.

Четыре этапа

  • Установить Fixture
  • Тест run
  • Проверка результата
  • Tear down

Набор фикстур описывает начальное состояние базы данных перед входом в тестирование. После настройки фикстур поведение базы данных проверяется для определенных тестовых случаев. В зависимости от результата тестовые примеры либо изменяются, либо сохраняются как есть. Этап «разрушения» приводит либо к прекращению тестирования, либо к продолжению других тестовых примеров.

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

  1. Очистка базы данных: если проверяемые данные уже присутствуют в базе данных, база данных должна быть очищена.
  2. Настроить Fixture: такой инструмент, как PHPUnit, затем перебирает фикстуры и выполняет вставки в базу данных.
  3. Запустить тест, проверить результат, а затем удалить: после сброса базы данных до пустой и перечисления приспособлений запускается тест и проверяется вывод. Если результат соответствует ожиданиям, следует процесс удаления, в противном случае тестирование повторяется.

Базовые методы

  • Анализатор запросов SQL - полезный инструмент при использовании Microsoft SQL Server.
  • Одна из часто используемых функций, create_input_dialog ["label"], используется для проверки вывода с помощью пользовательского ввода.
  • Дизайн форм для автоматического тестирования базы данных, внешнего и внутреннего интерфейса, полезен для базы данных обслуживающий персонал.
  • Данные нагрузочное тестирование :
    • Для нагрузочного тестирования данных требуются знания об исходной базе данных и целевой базе данных.
    • Рабочие проверяют совместимость между исходной базой данных и целевой базой данных, используя пакет DTS.
    • При обновлении исходной базы данных работники обязательно сравнивают ее с целевой базой данных.
    • При нагрузочном тестировании базы данных измеряется емкость сервера базы данных для обрабатывать запросы, а также время ответа сервера и клиента базы данных.
  • При тестировании базы данных такие вопросы, как атомарность, согласованность, Часто рассматриваются изоляция, надежность, целостность, выполнение триггеров и восстановление.
  1. Настройка для тестирования базы данных является дорогостоящей и сложной в обслуживании, поскольку системы баз данных постоянно меняются с ожидаемыми операциями вставки, удаления и обновления.
  2. Дополнительные накладные расходы необходимы для определения состояния транзакций базы данных.
  3. После очистки базы данных необходимо разработать новые тестовые сценарии.
  4. Для преобразования SQL необходим генератор SQL операторов, чтобы включить семантику SQL в тестовые примеры базы данных.

.

См. также

Ссылки

Внешние ссылки

Последняя правка сделана 2021-05-17 14:12:14
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте