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

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

пример

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

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

• Информация не должна быть потеряна при загрузке в базу данных.

• Только завершенные транзакции должны быть сохранены, и все незавершенные операции должны быть прерваны приложением.

• Авторизация доступа к базе данных должна быть сохранена. Не следует предоставлять несанкционированный или несанкционированный доступ к пользовательской информации.

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

Информация не должна быть потеряна при загрузке в базу данных.

Только завершенные транзакции должны быть сохранены, и все незавершенные операции должны быть прерваны приложением.

Авторизация доступа к базе данных должна быть сохранена. Не следует предоставлять несанкционированный или несанкционированный доступ к пользовательской информации.

Зачем вам нужно проводить тестирование базы данных?

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

Ниже приведены некоторые общие причины для тестирования базы данных —

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

• Эти хранимые процедуры и представления содержат важные задачи, такие как вставка сведений о клиенте (имя, контактная информация и т. Д.) И данных о продажах. Эти задачи необходимо протестировать на нескольких уровнях.

• Тестирование черного ящика на внешнем интерфейсе важно, но затрудняет выявление проблемы. Тестирование в бэкэнд-системе повышает надежность данных. Вот почему тестирование базы данных выполняется на внутренней системе.

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

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

Эти хранимые процедуры и представления содержат важные задачи, такие как вставка сведений о клиенте (имя, контактная информация и т. Д.) И данных о продажах. Эти задачи необходимо протестировать на нескольких уровнях.

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

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

Тестирование базы данных против внешнего тестирования

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

Тестирование базы данных	Тестирование пользовательского интерфейса
Тестирование базы данных называется проверкой данных и проверкой целостности или внутренним тестированием.	Тестирование пользовательского интерфейса или внешнего интерфейса также называется тестированием приложений или тестированием графического интерфейса.
Тестирование базы данных включает тестирование внутренних компонентов, которые не видны пользователям. Это включает в себя компоненты базы данных и системы СУБД, такие как My SQL, Oracle.	Тестирование пользовательского интерфейса включает проверку функциональности приложения и его компонентов, таких как формы, графики, меню, отчеты и т. Д. Эти компоненты создаются с использованием внешних средств разработки, таких как VB.net, C #, Delphi и т. Д.
Тестирование базы данных включает в себя проверку хранимых процедур, представлений, схем в базе данных, таблиц, индексов, ключей, триггеров, проверки данных и проверки целостности данных.	Тестирование пользовательского интерфейса включает проверку функциональности приложения, кнопок, форм и полей, календаря и изображений, навигации от одной страницы к другой и общей функциональности приложения.
Чтобы выполнить тестирование БД, тестировщику необходимы глубокие знания концепции базы данных — например, процедур и функций, представлений, индексов, ключей и хорошего практического SQL.	Чтобы выполнить тестирование пользовательского интерфейса, тестер должен хорошо понимать бизнес-требования, функциональные знания приложения, кодирование и т. Д.
Данные поступают из нескольких разнородных источников данных через веб-приложения, интранет-приложения и различные другие приложения.	Данные вводятся вручную в приложения. Он включает функциональное тестирование интерфейсных приложений.

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

Тестирование пользовательского интерфейса или внешнего интерфейса также называется тестированием приложений или тестированием графического интерфейса.

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

Это включает в себя компоненты базы данных и системы СУБД, такие как My SQL, Oracle.

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

Эти компоненты создаются с использованием внешних средств разработки, таких как VB.net, C #, Delphi и т. Д.

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

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

Чтобы выполнить тестирование БД, тестировщику необходимы глубокие знания концепции базы данных — например, процедур и функций, представлений, индексов, ключей и хорошего практического SQL.

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

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

Данные вводятся вручную в приложения. Он включает функциональное тестирование интерфейсных приложений.

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

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

• Структурное тестирование базы данных — это тестирование таблиц и столбцов, тестирование схемы, тестирование хранимых процедур и представлений, проверка триггеров и т. Д.

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

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

Структурное тестирование базы данных — это тестирование таблиц и столбцов, тестирование схемы, тестирование хранимых процедур и представлений, проверка триггеров и т. Д.

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

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

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

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

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

Тестирование схемы / картографии

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

В тестировании схемы —

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

• Требуется найти несопоставленные объекты в базе данных, такие как таблицы, представления, столбцы и т. Д.

Иногда случается, что объекты приложения конечного пользователя неправильно сопоставлены или не совместимы с объектами базы данных. Следовательно, требуется проверка правильности различных форматов схемы, связанных с базами данных.

Требуется найти несопоставленные объекты в базе данных, такие как таблицы, представления, столбцы и т. Д.

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

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

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

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

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

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

• Если это позволяет требуемые триггеры быть выполнены, как ожидалось.

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

• Если есть какие-либо неиспользуемые хранимые процедуры в базе данных.

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

• Проверка общей интеграции модулей хранимых процедур в соответствии с требованиями тестируемого приложения.

• Следуют механизмы исключения и обработки ошибок.

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

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

Если есть какие-либо неиспользуемые хранимые процедуры в базе данных.

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

Проверка общей интеграции модулей хранимых процедур в соответствии с требованиями тестируемого приложения.

Следуют механизмы исключения и обработки ошибок.

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

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

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

• Соблюдаются ли правила кодирования во время фазы кодирования триггеров.

• Смотреть выполненные триггеры соответствует требуемым условиям.

• Правильно ли обновляет триггер данные после их выполнения.

• Проверка функциональности триггеров обновления / вставки / удаления в тестируемом приложении.

Соблюдаются ли правила кодирования во время фазы кодирования триггеров.

Смотреть выполненные триггеры соответствует требуемым условиям.

Правильно ли обновляет триггер данные после их выполнения.

Проверка функциональности триггеров обновления / вставки / удаления в тестируемом приложении.

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

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

• Проверка типов данных в базе данных по значениям полей в клиентском приложении.

• Проверка длины поля данных в базе данных по длине типов данных в приложении.

• Проверка наличия в базе данных не отображенных таблиц или столбцов из объектов поля приложения.

• Соглашения об именах таблиц и столбцов базы данных проверяются, если они соответствуют бизнес-требованиям или нет.

• Проверка ключей и индексов в базе данных, т. Е. Первичных и внешних ключей в таблицах, определяется в соответствии с требованиями.

• Проверьте, совпадают ли первичные ключи и соответствующие им внешние ключи в двух таблицах.

• Проверка уникальных и ненулевых характеристик ключей сохраняется.

• Длина и тип данных ключей и индексов поддерживаются согласно требованию.

Проверка типов данных в базе данных по значениям полей в клиентском приложении.

Проверка длины поля данных в базе данных по длине типов данных в приложении.

Проверка наличия в базе данных не отображенных таблиц или столбцов из объектов поля приложения.

Соглашения об именах таблиц и столбцов базы данных проверяются, если они соответствуют бизнес-требованиям или нет.

Проверка ключей и индексов в базе данных, т. Е. Первичных и внешних ключей в таблицах, определяется в соответствии с требованиями.

Проверьте, совпадают ли первичные ключи и соответствующие им внешние ключи в двух таблицах.

Проверка уникальных и ненулевых характеристик ключей сохраняется.

Длина и тип данных ключей и индексов поддерживаются согласно требованию.

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

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

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

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

• Если авторизация пользователя поддерживается в соответствии с требованием.

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

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

Если авторизация пользователя поддерживается в соответствии с требованием.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нагрузочное тестирование

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

В нагрузочном тестировании тестер проверяет —

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

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

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

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

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

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

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

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

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

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

• Настройте среду
• Запустить тест
• Проверьте результат теста
• Подтвердить в соответствии с ожидаемыми результатами
• Сообщить о результатах соответствующим заинтересованным сторонам

Различные операторы SQL используются для разработки тестовых случаев. Наиболее распространенным оператором SQL, который используется для тестирования БД, является оператор Select . Помимо этого, могут использоваться различные операторы DDL, DML, DCL.

Пример — создание, вставка, выбор, обновление и т. Д.

Этапы тестирования базы данных

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

Ключевые этапы тестирования базы данных:

• Проверка исходного состояния
• Тестовый забег
• Подтверждение результата согласно ожидаемому результату
• Генерация результатов

Первый этап тестирования БД — проверка исходного состояния базы данных перед началом процесса тестирования. Затем поведение базы данных проверяется для определенных тестовых случаев. В соответствии с полученными результатами тестовые случаи настраиваются индивидуально.

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

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

• Настроить Fixture — это включает в себя ввод данных в базу данных и проверки текущего состояния базы данных.

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

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

Настроить Fixture — это включает в себя ввод данных в базу данных и проверки текущего состояния базы данных.

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

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

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

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

Как упоминалось ранее, это включает в себя тестирование каждого объекта в схеме.

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

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

Проверка таблиц, столбцов, правил типов столбцов

Проверьте пункты, приведенные ниже, чтобы узнать различия между фактическими и примененными настройками.

• Наименование всех таблиц в базе данных

• Имена столбцов для каждой таблицы

• Типы столбцов для каждой таблицы

• Значение NULL проверено или нет

• Привязан ли по умолчанию к правильным столбцам таблицы

• Определения правил для исправления имен таблиц и прав доступа

Наименование всех таблиц в базе данных

Имена столбцов для каждой таблицы

Типы столбцов для каждой таблицы

Значение NULL проверено или нет

Привязан ли по умолчанию к правильным столбцам таблицы

Определения правил для исправления имен таблиц и прав доступа

Ключ и Индексы

Проверьте Ключ и индексы в каждой таблице —

• Первичный ключ для каждой таблицы

• Внешние ключи для каждой таблицы

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

Первичный ключ для каждой таблицы

Внешние ключи для каждой таблицы

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

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

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

• Имя хранимой процедуры

• Имена параметров, типы параметров и т. Д.

• Вывод — содержит ли вывод много записей. Выполняются нулевые строки или извлекается только несколько записей.

• Какова функция хранимой процедуры и что не должна делать хранимая процедура?

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

• Параметры хранимой процедуры — вызов хранимой процедуры с граничными данными и с действительными данными. Сделайте каждый параметр недействительным один раз и запустите процедуру.

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

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

Имя хранимой процедуры

Имена параметров, типы параметров и т. Д.

Вывод — содержит ли вывод много записей. Выполняются нулевые строки или извлекается только несколько записей.

Какова функция хранимой процедуры и что не должна делать хранимая процедура?

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

Параметры хранимой процедуры — вызов хранимой процедуры с граничными данными и с действительными данными. Сделайте каждый параметр недействительным один раз и запустите процедуру.

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

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

Триггерные тесты

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

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

Сценарии установки сервера

Два типа испытаний должны быть выполнены —

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

Интеграционные тесты SQL Server

Интеграционные тесты должны выполняться после завершения тестирования компонентов.

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

• Любые конфликты между схемой и триггерами.

• Любые конфликты между хранимыми процедурами и схемой.

• Любые конфликты между хранимыми процедурами и триггерами.

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

Любые конфликты между схемой и триггерами.

Любые конфликты между хранимыми процедурами и схемой.

Любые конфликты между хранимыми процедурами и триггерами.

Метод функционального тестирования

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

• Тип 1 — В тестировании Типа 1 выясните особенности проекта. Для каждой основной функции найдите схему, триггеры и хранимые процедуры, ответственные за реализацию этой функции, и поместите их в функциональную группу. Затем протестируйте каждую группу вместе.

• Тип 2 — В тестировании типа 2 граница функциональных групп в бэкэнде не очевидна. Вы можете проверить поток данных и посмотреть, где вы можете проверить данные. Начните с внешнего интерфейса.

Тип 1 — В тестировании Типа 1 выясните особенности проекта. Для каждой основной функции найдите схему, триггеры и хранимые процедуры, ответственные за реализацию этой функции, и поместите их в функциональную группу. Затем протестируйте каждую группу вместе.

Тип 2 — В тестировании типа 2 граница функциональных групп в бэкэнде не очевидна. Вы можете проверить поток данных и посмотреть, где вы можете проверить данные. Начните с внешнего интерфейса.

Происходит следующий процесс —

• Когда служба запрашивает или сохраняет данные, некоторые хранимые процедуры будут вызваны.

• Процедуры обновят некоторые таблицы.

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

Когда служба запрашивает или сохраняет данные, некоторые хранимые процедуры будут вызваны.

Процедуры обновят некоторые таблицы.

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

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

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

• Напишите тестовые сценарии, чтобы попробовать эти функции, и каждая функция должна проверяться хотя бы один раз за полный цикл.

• Выполните тестовые сценарии снова и снова в течение определенного периода времени.

• Проверка файлов журнала для проверки любых взаимоблокировок, сбоя в памяти, повреждения данных и т. Д.

Напишите тестовые сценарии, чтобы попробовать эти функции, и каждая функция должна проверяться хотя бы один раз за полный цикл.

Выполните тестовые сценарии снова и снова в течение определенного периода времени.

Проверка файлов журнала для проверки любых взаимоблокировок, сбоя в памяти, повреждения данных и т. Д.

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

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

• Производительность системного уровня
• Определите наиболее часто используемые функции / функции
• Сроки — максимальное время, минимальное время и среднее время выполнения функций
• Объем доступа

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

Бэк-энд-баг также иногда можно найти, выполнив тестирование на стороне. Вы можете выполнить простые шаги, приведенные ниже, чтобы обнаружить ошибки с помощью внешнего тестирования.

• Напишите запросы из внешнего интерфейса и выполните поиск.

• Выберите существующую запись, измените значения в некоторых полях и сохраните запись. (Он включает в себя оператор UPDATE или обновление хранимых процедур и триггеры обновления.)

• Вставьте новый пункт меню в интерфейсное окно. Заполните информацию и сохраните запись. (Это включает операторы INSERT или хранимые процедуры вставки и триггеры удаления.)

• Выберите существующую запись, нажмите кнопку УДАЛИТЬ или УДАЛИТЬ и подтвердите удаление. (Это включает в себя оператор DELETE или хранимые процедуры удаления и триггеры удаления.)

• Повторите эти контрольные примеры с неверными данными и посмотрите, как база данных отвечает.

Напишите запросы из внешнего интерфейса и выполните поиск.

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

Вставьте новый пункт меню в интерфейсное окно. Заполните информацию и сохраните запись. (Это включает операторы INSERT или хранимые процедуры вставки и триггеры удаления.)

Выберите существующую запись, нажмите кнопку УДАЛИТЬ или УДАЛИТЬ и подтвердите удаление. (Это включает в себя оператор DELETE или хранимые процедуры удаления и триггеры удаления.)

Повторите эти контрольные примеры с неверными данными и посмотрите, как база данных отвечает.

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

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

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

Общие сценарии базы данных в отношении тестирования структурированных баз данных приведены ниже —

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

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

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

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

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

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

Функциональное тестирование базы данных

Общие сценарии тестирования базы данных в отношении функционального тестирования базы данных :

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

• Проверьте поток данных и посмотрите, где вы можете проверить данные. Начните с внешнего интерфейса.

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

Проверьте поток данных и посмотрите, где вы можете проверить данные. Начните с внешнего интерфейса.

Нефункциональное тестирование базы данных

Общие сценарии тестирования базы данных в отношении нефункционального тестирования базы данных :

• Напишите тестовые сценарии для проверки основных функций, и каждая функция должна проверяться хотя бы один раз за полный цикл.

• Выполните тестовые сценарии снова и снова в течение определенного периода времени.

• Проверка файлов журнала для проверки любой тупиковой ситуации, сбоя в памяти, повреждения данных и т. Д.

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

• Вставьте новый пункт меню в интерфейсное окно. Заполните информацию и сохраните запись. (Это включает операторы INSERT или хранимые процедуры вставки, триггеры удаления.)

• Выберите существующую запись, нажмите кнопку УДАЛИТЬ или УДАЛИТЬ и подтвердите удаление. (Это включает в себя оператор DELETE или хранимые процедуры удаления, триггеры удаления.)

• Повторите эти контрольные примеры с неверными данными и посмотрите, как база данных отвечает.

Напишите тестовые сценарии для проверки основных функций, и каждая функция должна проверяться хотя бы один раз за полный цикл.

Выполните тестовые сценарии снова и снова в течение определенного периода времени.

Проверка файлов журнала для проверки любой тупиковой ситуации, сбоя в памяти, повреждения данных и т. Д.

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

Вставьте новый пункт меню в интерфейсное окно. Заполните информацию и сохраните запись. (Это включает операторы INSERT или хранимые процедуры вставки, триггеры удаления.)

Выберите существующую запись, нажмите кнопку УДАЛИТЬ или УДАЛИТЬ и подтвердите удаление. (Это включает в себя оператор DELETE или хранимые процедуры удаления, триггеры удаления.)

Повторите эти контрольные примеры с неверными данными и посмотрите, как база данных отвечает.

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

Схемы , таблицы , хранимые процедуры и триггеры являются ключевыми объектами базы данных. Мы уже поделились типами тестирования БД и сценариями тестирования для этих объектов базы данных.

Schemas

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

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

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

Схемы обычно хранятся в словаре данных. Хотя схема определяется на языке текстовой базы данных, этот термин часто используется для обозначения графического изображения структуры базы данных. Другими словами, схема — это структура базы данных, которая определяет объекты в базе данных.

Типичные схемы, используемые в хранилище данных:

• Схема звезды
• Схема снежинок
• Галактика Схема

Таблицы в базе данных

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

Пример . Таблица Customer содержит такую ​​информацию, как идентификатор клиента, адреса, номера телефонов и т. Д. В виде ряда столбцов.

Каждый отдельный фрагмент данных представляет собой поле в таблице. Столбец состоит из всех записей в одном поле, таких как номера телефонов всех клиентов. Поля организованы в виде записей, которые представляют собой полные наборы информации (например, набор информации о конкретном клиенте), каждый из которых содержит строку.

Хранимые процедуры

Хранимая процедура — это серия операторов SQL, хранящихся в базе данных в скомпилированной форме, и несколько программ могут использовать ее совместно. Использование хранимых процедур может быть полезным для поддержания целостности данных, контроля доступа к данным и повышения производительности.

Триггеры

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

Тестирование базы данных — целостность данных

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

Для проверки целостности данных вам необходимо выполнить следующие операции:

• Вам необходимо проверить основные столбцы в каждой таблице и проверить, существуют ли какие-либо неверные данные. (Символы в поле имени, отрицательный процент и т. Д.)

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

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

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

Вам необходимо проверить основные столбцы в каждой таблице и проверить, существуют ли какие-либо неверные данные. (Символы в поле имени, отрицательный процент и т. Д.)

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

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

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

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

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

Эта информация приводится в спецификации требований к программному обеспечению или бизнес-требований SRS / BRS. Если отображение не предусмотрено, то вам нужно проверить часть кодирования.

Когда вы выполняете какое-либо действие в приложении переднего плана, вызывается соответствующее действие CRUD, и тестировщик должен проверять, каждое ли вызванное действие успешно или нет.

Ключевые аспекты отображения данных

Ниже приведены ключевые аспекты отображения данных —

• Для проверки полей в формах пользовательского интерфейса / внешнего интерфейса и сопоставления с соответствующей таблицей БД. Эта картографическая информация определена в документах с требованиями, как указано выше.

• Для любого действия, выполняемого во внешнем интерфейсе приложения, соответствующее действие CRUD «Создать, извлечь, обновить и удалить» инициируется на внутреннем конце.

• Тестер должен будет проверить, было ли вызвано правильное действие, и само по себе вызванное действие успешно или нет.

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

Для любого действия, выполняемого во внешнем интерфейсе приложения, соответствующее действие CRUD «Создать, извлечь, обновить и удалить» инициируется на внутреннем конце.

Тестер должен будет проверить, было ли вызвано правильное действие, и само по себе вызванное действие успешно или нет.

Шаги в тестировании отображения данных

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

• Шаг 1 — Сначала проверьте синтаксическую ошибку в каждом скрипте.

• Шаг 2 — Далее необходимо проверить соответствие таблиц, столбцов и типов данных.

• Шаг 3 — Проверьте соответствие данных поиска.

• Шаг 4 — Запустите каждый скрипт, если записи не существуют в таблицах назначения.

• Шаг 5 — Запустите каждый скрипт, когда записи уже существуют в таблицах назначения.

Шаг 1 — Сначала проверьте синтаксическую ошибку в каждом скрипте.

Шаг 2 — Далее необходимо проверить соответствие таблиц, столбцов и типов данных.

Шаг 3 — Проверьте соответствие данных поиска.

Шаг 4 — Запустите каждый скрипт, если записи не существуют в таблицах назначения.

Шаг 5 — Запустите каждый скрипт, когда записи уже существуют в таблицах назначения.

Тестирование базы данных — производительность

Приложение с большим временем отклика и низкой производительностью может привести к огромным проблемам. Тестирование нагрузки на базу данных используется для выявления проблем с производительностью до развертывания приложений базы данных для конечных пользователей.

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

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

Нагрузочное тестирование

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

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

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

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

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

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

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

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

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

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

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

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

Наиболее распространенными инструментами стресс-тестирования являются LoadRunner и WinRunner .

Тестирование базы данных — Инструменты

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

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

Sr.No	Категория и описание	Примеры
1	Инструменты для нагрузочного тестирования Эти инструменты используются для загрузки вашей базы данных с высокой нагрузкой, что позволяет определить, соответствует ли ландшафт вашей системы требованиям вашего бизнеса.	Веб-производительность Rad View Меркурий
2	Инструменты безопасности данных Эти инструменты используются для реализации соответствия и стандартов в соответствии с правилами информационной безопасности.	IBM Optim Data Privacy
3	Инструменты Генератора тестовых данных Тестировщик использует эти инструменты для генерации тестовых данных для системы баз данных. Это в основном требуется, когда у вас есть огромный объем данных, и вам нужен образец для выполнения тестирования БД. Обычно используется для нагрузочного и стресс-тестирования.	Фабрика данных DTM генератор данных Турбо-данные
4	Инструмент управления тестовыми данными Эти инструменты используются для контроля версий для тестовых данных. Вы должны определить ожидаемые результаты, а затем сравнить их с фактическими результатами тестов.	IBM Optim Test Data Management
5	Инструменты для выполнения модульного тестирования Эти инструменты используются для проведения регрессионного тестирования вашей базы данных.	SQLUnit TSQLUnit DBFit DBUnit

Инструменты для нагрузочного тестирования

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

Веб-производительность

Rad View

Меркурий

Инструменты безопасности данных

Эти инструменты используются для реализации соответствия и стандартов в соответствии с правилами информационной безопасности.

IBM Optim Data Privacy

Инструменты Генератора тестовых данных

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

Фабрика данных

DTM генератор данных

Турбо-данные

Инструмент управления тестовыми данными

Эти инструменты используются для контроля версий для тестовых данных. Вы должны определить ожидаемые результаты, а затем сравнить их с фактическими результатами тестов.

IBM Optim Test Data Management

Инструменты для выполнения модульного тестирования

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

SQLUnit

TSQLUnit

DBFit

DBUnit

Тестирование базы данных — Резервное копирование

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

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

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

Типы резервных копий данных

Существует два типа резервного копирования, которые можно использовать:

• Физическое резервное копирование. Физическое резервное копирование включает резервное копирование с использованием сторонних инструментов резервного копирования, таких как Veritas Net Back, IBM Tivoli Manager или резервное копирование менеджера пользователей с использованием утилит ОС.

• Логическое резервное копирование. Логическое резервное копирование базы данных включает резервное копирование логических объектов, таких как таблицы, индексы, процедуры и т. Д.

Физическое резервное копирование. Физическое резервное копирование включает резервное копирование с использованием сторонних инструментов резервного копирования, таких как Veritas Net Back, IBM Tivoli Manager или резервное копирование менеджера пользователей с использованием утилит ОС.

Логическое резервное копирование. Логическое резервное копирование базы данных включает резервное копирование логических объектов, таких как таблицы, индексы, процедуры и т. Д.

Пример. Одним из распространенных инструментов резервного копирования данных является Oracle Recovery Manager (RMAN), который является утилитой Oracle для резервного копирования базы данных.

RMAN состоит из двух компонентов —

• Целевая база данных, для которой требуется резервное копирование.

• Клиент RMAN используется для запуска команд для резервного копирования данных.

Целевая база данных, для которой требуется резервное копирование.

Клиент RMAN используется для запуска команд для резервного копирования данных.

BACKUP VALIDATE используется, чтобы проверить, можете ли вы сделать правильную резервную копию файлов базы данных. Это обеспечивает —

• Имеется ли резервная копия для физических или логических объектов базы данных.
• Если регулярные резервные копии созданы для бесценных данных.
• Если средство резервного копирования соответствует требованиям резервного копирования организации.

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

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

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

Вы можете выполнить следующие проверки для восстановления базы данных —

• Любые ошибки или ошибки в программном обеспечении для резервного копирования, и вам необходимо решить эти проблемы на более ранней стадии.

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

• Вам необходимо проверить потребности в тестировании восстановления, чтобы спланировать эффективную стратегию восстановления.

• Вы также должны знать, как вы можете восстановить документы.

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

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

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

Вы также должны знать, как вы можете восстановить документы.

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

• Промежуток времени, когда изменения или модификации происходят в системе базы данных.

• Период, к которому вы хотите, чтобы ваш план восстановления проводился.

• Чувствительность данных в системе баз данных. Чем важнее данные, тем чаще вы будете тестировать программное обеспечение.

Промежуток времени, когда изменения или модификации происходят в системе базы данных.

Период, к которому вы хотите, чтобы ваш план восстановления проводился.

Чувствительность данных в системе баз данных. Чем важнее данные, тем чаще вы будете тестировать программное обеспечение.

Общие шаги в резервном копировании базы данных и тестировании восстановления

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

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

• Тестирование системы баз данных
• Тестирование файлов SQL
• Тестирование частичных файлов
• Тестирование резервного копирования данных
• Тестирование инструмента резервного копирования
• Тестирование резервных копий журнала

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

Тестирование безопасности базы данных проводится для выявления лазеек в механизмах безопасности, а также для выявления уязвимостей или слабых мест системы базы данных.

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

Ниже приведены основные задачи тестирования безопасности базы данных.

• Аутентификация
• авторизация
• конфиденциальность
• Доступность
• целостность
• упругость

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

SQL-инъекция

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

Повышение привилегий в базе данных

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

Отказ в обслуживании

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

Несанкционированный доступ к данным

Другой тип атаки — получение несанкционированного доступа к данным в приложении или системе баз данных. Несанкционированный доступ включает в себя —

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

Подмена личности

В Identity Spoofing хакер использует учетные данные пользователя или устройства для запуска атак на сетевые узлы, кражи данных или обхода контроля доступа к системе базы данных. Предотвращение этой атаки требует смягчения IT-инфраструктуры и сетевого уровня.

Манипуляция данными

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

Методы тестирования безопасности баз данных

Проверка на проницаемость

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

Поиск рисков

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

SQL инъекционный тест

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

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

Проверка SQL-инъекций может выполняться для скобок, запятых и кавычек.

Взлом пароля

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

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

Аудит безопасности системы баз данных

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

Примером наиболее распространенных стандартов безопасности являются ISO 27001, BS15999 и т. Д.

Инструменты тестирования безопасности баз данных

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

Zed Attack Proxy

Это инструмент для тестирования на проникновение для поиска уязвимостей в веб-приложениях. Он предназначен для использования людьми с широким спектром опыта в области безопасности и поэтому идеально подходит для разработчиков и функциональных тестеров, впервые знакомых с тестированием на проникновение. Обычно используется для Windows, Linux, Mac OS.

Парос

Все данные HTTP и HTTPS между сервером и клиентом, включая файлы cookie и поля формы, могут быть перехвачены и изменены с помощью этих сканеров. Он используется для кроссплатформенности, Java JRE / JDK 1.4.2 или выше.

Инструментарий социального инженера

Это инструмент с открытым исходным кодом, и на него нападают человеческие элементы, а не системный элемент. Это позволяет отправлять электронные письма, Java-апплеты и т. Д., Содержащие код атаки. Предпочитается для Linux, Apple Mac OS X и Microsoft Windows.

Skipfish

Этот инструмент используется для сканирования их сайтов на наличие уязвимостей. Отчеты, созданные с помощью этого инструмента, служат основой для профессиональной оценки безопасности веб-приложений. Он предпочтителен для Linux, FreeBSD, MacOS X и Windows.

Вега

Это мультиплатформенный инструмент веб-безопасности с открытым исходным кодом, который используется для обнаружения случаев внедрения SQL-кода, межсайтового скриптинга (XSS) и других уязвимостей в веб-приложениях. Предпочитается для Java, Linux и Windows.

вапити

Wapiti — это инструмент с открытым исходным кодом и веб-инструмент, который сканирует веб-страницы веб-приложения и проверяет наличие сценариев и форм, в которые он может вводить данные. Он построен на Python и может обнаруживать ошибки обработки файлов, инъекции базы данных, XSS, LDAP и CRLF, обнаружение выполнения команд.

Веб скарабей

Он написан на Java и используется для анализа приложений, которые обмениваются данными по протоколам HTTP / HTTPS. Этот инструмент в первую очередь предназначен для разработчиков, которые могут сами писать код. Этот инструмент не зависит от ОС.

Тестирование базы данных — проблемы

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

Объем тестирования слишком велик

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

Когда у вас есть список объектов для тестирования, следует оценить усилия, необходимые для разработки тестов и выполнения тестов для каждого тестового элемента. В зависимости от их структуры и размера данных выполнение некоторых тестов базы данных может занять много времени.

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

Уменьшенная база тестовых данных

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

Изменения в структуре базы данных

Это одна из распространенных проблем при тестировании БД. Иногда бывает, что вы разрабатываете или выполняете тест, и структура базы данных в это время была изменена. Это необходимо для того, чтобы вы были в курсе изменений, внесенных в базу данных во время тестирования.

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

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

Комплексные планы испытаний

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

Хорошее понимание SQL

Чтобы протестировать базу данных, вы должны хорошо знать SQL-запросы и необходимые инструменты управления базой данных.

Тестирование базы данных — вопросы интервью

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

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

Вот некоторые из распространенных причин, по которым нужно проводить тестирование базы данных:

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

Эти хранимые процедуры и представления содержат важные задачи, такие как вставка сведений о клиенте (имя, контактная информация и т. Д.) И данных о продажах. Эти задачи необходимо протестировать на нескольких уровнях.

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

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

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

На основании функций и структуры базы данных тестирование БД можно разделить на следующие категории:

Структурное тестирование базы данных — это тестирование таблиц и столбцов, тестирование схемы, тестирование хранимых процедур и представлений, проверка триггеров и т. Д.

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

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

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

Соединения используются для логического соединения двух или более таблиц. Распространенные типы объединений включают в себя: Внутреннее объединение, Неэквиджоин, Внешнее объединение, Самостоятельное объединение и Перекрестное объединение.

Вы можете присоединить одну таблицу к себе. В этом случае вы используете одну и ту же таблицу дважды.

Шаг 1 — Подключение к базе данных

Шаг 2 — Выполнить запрос базы данных —

Шаг 3 — Отключите соединение с базой данных, используя

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

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

Далее выполните следующие задачи —

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

Выполните процедуру с TOAD или MySQL или Query Analyzer.

Повторно выполните доступные процедуры, отправив различные параметры, и сравните результаты с ожидаемыми значениями.

Завершая процесс, автоматизируйте тесты с помощью WinRunner.

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

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

У нас есть три типа операторов SQL —

Операторы DDL используются для определения структуры или схемы базы данных. Некоторые примеры —

CREATE — для создания объектов в базе данных

ALTER — изменяет структуру базы данных

DROP — удалить объекты из базы данных

Операторы используются для указания условий в операторе SQL и в качестве союзов для нескольких условий в операторе.

Объединение используется для объединения результатов двух или более операторов Select. Однако это устранит дубликаты строк. Союз является оператором множества.

Объединение используется для объединения результатов двух или более операторов Select. Однако это устранит повторяющиеся строки

Операция « Объединение всех» аналогична операции «Объединение», но в ней также отображаются дубликаты строк.

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

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

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

Тестирование БД включает тестирование внутренних компонентов, которые не видны пользователям. Он включает компоненты базы данных и системы СУБД, такие как MySQL и Oracle.

Фронтальное тестирование включает в себя проверку функциональности приложения и его компонентов, таких как формы, графики, меню, отчеты и т. Д. Эти компоненты создаются с использованием инструментов фронтальной разработки, таких как VB.net, C #, Delphi и т. Д.

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

Различные операторы SQL используются для разработки тестовых случаев. Наиболее распространенным оператором SQL, который используется для тестирования БД, является оператор select. Помимо этого могут также использоваться различные операторы DDL, DML, DCL.

Пример — создание, вставка, выбор, обновление и т. Д.

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

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

Он определяет представления пользователей и их сопоставления с концептуальной схемой.

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

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

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

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

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

PL / SQL использует курсоры для всех операторов доступа к информации базы данных. Язык поддерживает использование двух типов курсоров — неявных и явных.

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

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

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

Подзапрос SQL — это способ запроса двух или более таблиц одновременно. Сам подзапрос — это оператор SQL SELECT, содержащийся в предложении WHERE другого оператора SQL SELECT и разделенный заключением в скобки. Некоторые подзапросы имеют эквивалентные структуры соединения SQL, но коррелированные подзапросы не могут дублироваться соединением

В таком случае вам необходимо проверить следующие аспекты —

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

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

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

Повторное тестирование также называется Data Driven Testing с небольшой разницей —

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

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

Существует четыре типа тестирования данных:

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

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

Промежуток времени, когда изменения или модификации происходят в системе базы данных.

Период, к которому вы хотите, чтобы ваш план восстановления проводился.

Чувствительность данных в системе баз данных. Чем важнее данные, тем чаще вы будете тестировать программное обеспечение.

Следующие инструменты используются для генерации тестовых данных —

Существует два типа резервного копирования, которые можно использовать:

Физическое резервное копирование. Физическое резервное копирование включает в себя резервное копирование с использованием сторонних инструментов резервного копирования, таких как Veritas net back, IBM Tivoli Manager или резервное копирование менеджера пользователей с использованием утилит ОС.

Логическое резервное копирование. Логическое резервное копирование базы данных включает резервное копирование логических объектов, таких как таблицы, индексы, процедуры и т. Д.

Распространенным инструментом резервного копирования данных является Oracle Recovery Manager (RMAN), который является утилитой Oracle для резервного копирования базы данных.

В тестировании восстановления базы данных выполняются следующие действия:

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

Тестирование безопасности базы данных выполняется для проверки следующих аспектов:

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

Для тестирования безопасности базы данных можно использовать следующие инструменты: Zed Attack Proxy, Paros, Social Engineer Toolkit, Skipfish, Vega, Wapiti и Web Scarab.

Общие проблемы, с которыми сталкиваются при выполнении тестирования базы данных, следующие: