Учебное пособие по тестированию базы данных (данных)

Что такое тестирование базы данных?

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

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

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

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

Члены групп тестирования и разработки обычно уделяют больше всего внимания графическому пользовательскому интерфейсу, поскольку графический интерфейс пользователя является наиболее заметной частью приложения. Однако также важно проверить информацию, которая является основой приложения, т. е. БАЗЫ ДАННЫХ.

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

  1. Приложение сохраняет информацию о транзакциях в базе данных приложения и корректно отображает ее пользователю.
  2. Никакая информация в процессе не теряется.
  3. Нет частично выполненных или прерванных operaинформация сохраняется приложением.
  4. Ни одному неавторизованному лицу не разрешен доступ к информации пользователя.

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

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

Тестирование пользовательского интерфейса и тестирование данных

Тестирование пользовательского интерфейса Тестирование базы данных или данных
Этот тип тестирования также известен как тестирование графического пользовательского интерфейса или внешнее тестирование. Этот тип тестирования также известен как бэкэнд-тестирование или тестирование данных.
Этот тип тестирования в основном касается всех тестируемых элементов, которые открыты пользователю для просмотра и взаимодействия, таких как формы, презентации, графики, меню, отчеты и т. д. (созданные с помощью VB, VB.net, VC++, Delphi – Front- Конечные инструменты) Этот тип тестирования в основном касается всех проверяемых элементов, которые обычно скрыты от пользователя для просмотра. К ним относятся внутренние процессы и хранилище, такие как Assembly, СУБД типа OracleSQL Server, MYSQL, и т.д.

Этот тип тестирования включает в себя проверку

  • текст boxes
  • выбрать раскрывающиеся списки
  • календари и кнопки
  • Навигация по страницам
  • отображение изображений
  • Внешний вид приложения в целом

Этот тип тестирования включает в себя проверку:

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

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

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

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

  1. Структурное тестирование
  2. Функциональное тестирование
  3. Нефункциональное тестирование

В этом руководстве по тестированию базы данных мы рассмотрим каждый тип и его подтипы один за другим.

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

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

Что такое тестирование схемы?

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

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

  1. Проверка различных форматов схем, связанных с базами данных. Во многих случаях формат отображения таблицы может быть несовместим с форматом отображения, присутствующим на уровне пользовательского интерфейса приложения.
  2. В случае несопоставленных таблиц/представлений/столбцов необходима проверка.
  3. Также необходимо проверить, являются ли гетерогенныеneoНаши базы данных в среде соответствуют общему сопоставлению приложений.

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

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

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

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

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

  1. Совместимо ли сопоставление полей и столбцов базы данных во внутренней части с этими сопоставлениями во внешнем интерфейсе?
  2. Проверка длины и соглашения об именовании полей и столбцов базы данных в соответствии с требованиями.
  3. Проверка наличия любых неиспользуемых/несопоставленных таблиц/столбцов базы данных.
  4. Проверка совместимости
  • тип данных
  • длина поля

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

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

Тестирование ключей и индексов

Важные проверки ключей и индексов –

  1. Проверьте, требуется ли
  • Основной ключ
  • Внешний ключ

Для необходимых таблиц созданы ограничения.

  1. Проверьте, действительны ли ссылки на внешние ключи.
  2. Проверьте, совпадают ли типы данных первичного ключа и соответствующих внешних ключей в двух таблицах.
  3. Проверьте, соблюдены ли необходимые соглашения об именах для всех ключей и индексов.
  4. Проверьте размер и длину необходимых полей и индексов.
  5. Требуется ли
  • Clusterиндексы редактора
  • не Clusterиндексы редактора

были созданы в необходимых таблицах в соответствии с бизнес-требованиями.

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

Важными тестами для проверки хранимых процедур являются:

  1. Приняла ли команда разработчиков необходимые А) стандартные соглашения по кодированию и Б) обработку исключений и ошибок. Для всех хранимых процедур для всех модулей тестируемого приложения.
  2. Охватила ли команда разработчиков все условия/циклы, применив необходимые входные данные к тестируемому приложению?
  3. Правильно ли команда разработчиков применила TRIM operaкаждый раз, когда данные извлекаются из необходимых таблиц в базе данных?
  4. Предоставляет ли ручное выполнение хранимой процедуры конечному пользователю требуемый результат?
  5. Обеспечивает ли ручное выполнение хранимой процедуры обновление полей таблицы в соответствии с требованиями тестируемого приложения?
  6. Позволяет ли выполнение хранимых процедур неявно вызывать необходимые триггеры?
  7. Проверка наличия любых неиспользуемых хранимых процедур.
  8. Проверка условия Allow Null, которую можно выполнить на уровне базы данных.
  9. Проверка того факта, что все хранимые процедуры и функции были успешно выполнены, когда тестируемая база данных пуста.
  10. Проверка общей интеграции модулей хранимых процедур в соответствии с требованиями тестируемого приложения.

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

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

  1. Соблюдались ли необходимые соглашения по кодированию на этапе кодирования триггеров?
  2. Проверьте, выполнили ли триггеры, выполняемые для соответствующих транзакций DML, требуемые условия.
  3. Правильно ли триггер обновляет данные после их выполнения?
  4. Проверка требуемой функциональности триггеров обновления/вставки/удаления в области тестируемого приложения.

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

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

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

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

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

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

  • Является ли поле обязательным при использовании allowing Значения NULL в этом поле?
  • Имеет ли длина каждого поля достаточный размер?
  • Имеют ли все похожие поля одинаковые имена в таблицах?
  • Есть ли в базе данных какие-либо вычисляемые поля?

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

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

Проверка целостности и согласованности данных

Фоллоwing проверки важны

  1. Являются ли данные логически хорошо организованными?
  2. Верны ли данные, хранящиеся в таблицах, и соответствуют ли они бизнес-требованиям?
  3. Есть ли в тестируемом приложении ненужные данные?
  4. Были ли данные сохранены в соответствии с требованиями в отношении данных, которые были обновлены из пользовательского интерфейса?
  5. Является ли TRIM operaкакие действия выполняются с данными перед их вставкой в ​​тестируемую базу данных?
  6. Были ли транзакции выполнены в соответствии со спецификациями бизнес-требований и правильны ли результаты?
  7. Были ли данные правильно зафиксированы, если транзакция была успешно выполнена?
  8. Был ли выполнен успешный откат данных, если транзакция не была успешно выполнена конечным пользователем?
  9. Был ли выполнен откат данных, если транзакция не была выполнена успешно и несколько разнородныхneoамериканские базы данных участвовали в рассматриваемой транзакции?
  10. Все ли транзакции были выполнены с использованием необходимых процедур проектирования, указанных в бизнес-требованиях системы?

Вход и безопасность пользователя

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

  1. Препятствует ли приложение пользователю продолжить работу с приложением в случае
  • неверное имя пользователя, но действительный пароль
  • действительное имя пользователя, но неверный пароль.
  • неверное имя пользователя и неверный пароль.
  1. Разрешено ли пользователю выполнять только те конкретные operaпараметры, которые определяются бизнес-требованиями?
  2. Защищены ли данные от несанкционированного доступа?
  3. Существуют ли разные роли пользователей, созданные с разными разрешениями?
  4. Имеют ли все пользователи необходимые уровни доступа к указанной базе данных, как того требуют бизнес-спецификации?
  5. Убедитесь, что конфиденциальные данные, такие как пароли, данные кредитной карты, numbers зашифрованы и не хранятся в базе данных в виде обычного текста. Хорошей практикой является обеспечение того, чтобы все учетные записи имели пароли, которые являются общедоступными.plex и не так-то легко угадать.

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

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

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

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

испытание нагрузкой

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

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

Важными инструментами нагрузочного тестирования являются LoadRunner Профессиональный, выиграй бегун и JMeter.

Что такое стресс-тестирование базы данных?

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

Важными инструментами стресс-тестирования являются LoadRunner Профессиональный и JMeter.

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

A significant amount of overhead could be involved to determine the state of the database transactions

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

New test data have to be designed after cleaning up of the old test data.

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

An SQL generator is required to transform SQL validators in order to ensure the SQL queries are apt for handling the required database test cases.

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

The above mentioned prerequisite ensure that the set-up of the database testing procedure could be costly as well as time consuming.

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

Мифы и заблуждения, связанные с тестированием баз данных

Мифы

Database Testing requires plenty of expertise and it is a very tedious job

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

Database testing adds extra work bottleneck

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

Database testing slows down the overall development process

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

Database testing could be excessively costly

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

Лучшие практики

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

Также проверьте- Вопросы и ответы на собеседовании по тестированию базы данных