Тестирование базы данных обычно состоит из многоуровневого процесса, включающего уровень пользовательского интерфейса (UI), бизнес-уровень, уровень доступа к данным и базу данных сам. Уровень пользовательского интерфейса занимается дизайном интерфейса базы данных, а бизнес-уровень включает базы данных, поддерживающие бизнес-стратегии.
Содержание
- 1 Цели
- 2 Типы тестов и процессов
- 2.1 Черный ящик
- 2.2 Белый ящик
- 2.3 Подход WHODATE
- 3 Четыре этапа
- 4 Базовые методы
- 5 См. Также
- 6 Ссылки
- 7 Внешние ссылки
Цели
Базы данных, совокупность взаимосвязанных файлов на сервере, хранящая информацию, может не иметь дело с одним и тем же типом данных, т.е. базы данных могут быть разнородными. В результате в больших системах баз данных могут возникать многие виды ошибок внедрения и интеграции , которые негативно влияют на производительность, надежность, согласованность и безопасность системы. Таким образом, важно протестировать, чтобы получить систему базы данных, которая удовлетворяет свойствам ACID (атомарность, согласованность, изоляция и долговечность) система управления базами данных.
Одним из наиболее важных уровней является уровень доступа к данным, который имеет дело с базами данных непосредственно во время процесса связи. Тестирование базы данных в основном происходит на этом уровне и включает стратегии тестирования, такие как контроль качества и обеспечение качества баз данных продуктов. Тестирование на этих различных уровнях часто используется для поддержания согласованности систем баз данных, что чаще всего можно увидеть в следующих примерах:
- Данные критически важны с точки зрения бизнеса. Такие компании, как Google или Symantec, которые связаны с хранилищем данных, должны иметь надежную и согласованную систему баз данных. Если операции с базой данных, такие как вставка, удаление и обновление, выполняются без предварительной проверки базы данных на согласованность, компания рискует вывести из строя всю систему.
- Некоторые компании имеют разные типы баз данных, а также разные цели и миссии. Чтобы достичь уровня функциональности, соответствующего указанным целям, им необходимо протестировать свою систему баз данных.
- Текущий подход к тестированию может быть недостаточным, когда разработчики формально тестируют базы данных. Однако этот подход недостаточно эффективен, поскольку разработчики баз данных могут замедлить процесс тестирования из-за недостатков связи. Представляется целесообразным создать отдельную группу по тестированию баз данных.
- Тестирование баз данных в основном связано с поиском ошибок в базах данных для их устранения. Это улучшит качество базы данных или веб-системы.
- Тестирование базы данных следует отличать от стратегий решения других проблем, таких как сбои базы данных, неправильные вставки, удаления или обновления. Здесь рефакторинг базы данных - это эволюционный метод, который может применяться.
Типы тестов и процессов
Тестирование черного и белого ящиков в тесте базы данных
На рисунке показаны области тестирования, задействованные во время различные методы тестирования базы данных, такие как тестирование черного ящика и тестирование белого ящика.
Черный ящик
Тестирование черного ящика включает в себя тестирование интерфейсов и интеграцию базы данных, который включает в себя:
- Отображение данных (включая метаданные )
- Проверка входящих данных
- Проверка исходящих данных из функций запроса
- Различные методы, такие как метод построения графиков причинно-следственных связей, разделение эквивалентности и анализ граничных значений.
С помощью этих методов можно тщательно протестировать функциональность базы данных.
Плюсы и минусы тестирования черного ящика включают: Создание тестовых примеров при тестировании методом черного ящика довольно просто. Их создание полностью не зависит от разработки программного обеспечения и может быть выполнено в ранняя стадия развития. Как следствие, программист лучше знает, как проектировать приложение базы данных, и тратит меньше времени на отладку. Стоимость разработки тестовых примеров черного ящика ниже, чем разработка тестовых примеров белого ящика. Главный недостаток тестирования черного ящика заключается в том, что неизвестно, какая часть программы тестируется. Кроме того, некоторые ошибки не могут быть обнаружены.
Белый ящик
Тестирование белого ящика в основном касается внутренней структуры базы данных. Детали спецификации скрыты от пользователя.
- Он включает в себя тестирование триггеров базы данных и логических представлений, которые будут поддерживать рефакторинг базы данных.
- Он выполняет модульное тестирование функций базы данных, триггеров, представлений, SQL запросов и т. Д.
- Он проверяет таблицы базы данных, модели данных, схему базы данных и т. Д.
- Он проверяет правила ссылочной целостности.
- Он выбирает значения таблиц по умолчанию для проверки согласованности базы данных.
- При тестировании методом белого ящика используются следующие методы: покрытие условий, покрытие решений, покрытие операторов, цикломатическая сложность.
Основным преимуществом тестирования белого ящика при тестировании базы данных является то, что обнаруживаются ошибки кодирования, поэтому внутренние ошибки в базе данных могут быть устраненным. Ограничение тестирования белого ящика заключается в том, что операторы SQL не покрываются.
Подход WHODATE
Подход WHODATE для преобразования операторов SQL
При создании тестовых примеров для тестирования базы данных семантика оператора SQL должна быть отражена в тестовых примерах. Для этой цели используется метод, называемый техникой применения базы данных WHite bOx «(WHODATE)». Как показано на рисунке, операторы SQL независимо конвертируются в операторы GPL с последующим традиционным тестированием методом белого ящика для создания тестовых примеров, включающих семантику SQL.
Четыре этапа
- Установить Fixture
- Тест run
- Проверка результата
- Tear down
Набор фикстур описывает начальное состояние базы данных перед входом в тестирование. После настройки фикстур поведение базы данных проверяется для определенных тестовых случаев. В зависимости от результата тестовые примеры либо изменяются, либо сохраняются как есть. Этап «разрушения» приводит либо к прекращению тестирования, либо к продолжению других тестовых примеров.
Для успешного тестирования базы данных обычно выполняется следующий рабочий процесс, выполняемый каждым отдельным тестом:
- Очистка базы данных: если проверяемые данные уже присутствуют в базе данных, база данных должна быть очищена.
- Настроить Fixture: такой инструмент, как PHPUnit, затем перебирает фикстуры и выполняет вставки в базу данных.
- Запустить тест, проверить результат, а затем удалить: после сброса базы данных до пустой и перечисления приспособлений запускается тест и проверяется вывод. Если результат соответствует ожиданиям, следует процесс удаления, в противном случае тестирование повторяется.
Базовые методы
- Анализатор запросов SQL - полезный инструмент при использовании Microsoft SQL Server.
- Одна из часто используемых функций,
create_input_dialog ["label"]
, используется для проверки вывода с помощью пользовательского ввода. - Дизайн форм для автоматического тестирования базы данных, внешнего и внутреннего интерфейса, полезен для базы данных обслуживающий персонал.
- Данные нагрузочное тестирование :
- Для нагрузочного тестирования данных требуются знания об исходной базе данных и целевой базе данных.
- Рабочие проверяют совместимость между исходной базой данных и целевой базой данных, используя пакет DTS.
- При обновлении исходной базы данных работники обязательно сравнивают ее с целевой базой данных.
- При нагрузочном тестировании базы данных измеряется емкость сервера базы данных для обрабатывать запросы, а также время ответа сервера и клиента базы данных.
- При тестировании базы данных такие вопросы, как атомарность, согласованность, Часто рассматриваются изоляция, надежность, целостность, выполнение триггеров и восстановление.
- Настройка для тестирования базы данных является дорогостоящей и сложной в обслуживании, поскольку системы баз данных постоянно меняются с ожидаемыми операциями вставки, удаления и обновления.
- Дополнительные накладные расходы необходимы для определения состояния транзакций базы данных.
- После очистки базы данных необходимо разработать новые тестовые сценарии.
- Для преобразования SQL необходим генератор SQL операторов, чтобы включить семантику SQL в тестовые примеры базы данных.
.
См. также
Ссылки
- Ambler, Scott W. (2006). «Тестирование базы данных: как провести регрессионное тестирование реляционной базы данных». Agiledata.org. Получено 4 декабря 2011 г. Внешняя ссылка в
| publisher =
() - Zeichick, Alan; et al. (14 августа 1989 г.). How We Tested Integrated Пакеты программного обеспечения. InfoWorld. Получено 4 декабря 2011 г.
Внешние ссылки