Учебники

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

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

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

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

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

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

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

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

В этом уроке мы будем изучать

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

Руководство по тестированию баз данных (данных) с примерами тестовых случаев

 

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

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

Этот тип тестирования также называется тестированием графического интерфейса пользователя или интерфейсным тестированием. Этот тип тестирования также известен как Back-end Testing или тестирование данных.
Этот тип тестирования в основном касается всех тестируемых элементов, которые открыты для пользователя для просмотра и взаимодействия, таких как формы, презентации, графики, меню, отчеты и т. Д. (Созданные с помощью VB, VB.net, VC ++, Delphi — Frontend Tools ) Этот тип тестирования в основном касается всех тестируемых элементов, которые обычно скрыты от пользователя для просмотра. К ним относятся внутренний процесс и хранилище, например, Assembly, СУБД, например, Oracle, SQL Server, MYSQL и т. Д.
Этот тип тестирования включает проверку

текстовых полей,

выбор раскрывающихся списков,

календарей и кнопок,

навигацию с одной страницы на другую,

отображение изображений, а также

внешний вид всего приложения.

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

схемы,

таблиц базы данных,

столбцов,

ключей и индексов,

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

триггеров,

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

проверку дублирования данных,

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

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

Руководство по тестированию баз данных (данных) с примерами тестовых случаев

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

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

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

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

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

Схема тестирования

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

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

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

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

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

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

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

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

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

          столбцов серверной базы данных и столбцов в приложении.

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

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

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

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

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

  1. Проверьте, действительны ли ссылки на внешние ключи.
  2. Проверьте, совпадают ли тип данных первичного ключа и соответствующих внешних ключей в двух таблицах.
  3. Проверьте, соблюдаются ли требуемые соглашения об именах для всех ключей и индексов.
  4. Check the size and length of the required fields and indexes.
  5. Whether the required
  • Clustered indexes
  • Non Clustered indexes

         have been created on the required tables as specified by the business requirements.

Stored procedures testing

The list of the most important things which are to be validated for the stored procedures.

  1. Whether the development team did adopt the required
  • coding standard conventions
  • exception and error handling

          for all the stored procedures for all the modules for the application under test.

  1. Whether the development team did cover all the conditions/loops by applying the required input data to the application under test.
  2. Whether the development team did properly apply the TRIM operations whenever data is fetched from the required tables in the Database.
  3. Whether the manual execution of the Stored Procedure provides the end user with the required result
  4. Whether the manual execution of the Stored Procedure ensures the table fields are being updated as required by the application under test.
  5. Whether the execution of the Stored Procedures enables the implicit invoking of the required triggers.
  6. Validation of the presence of any unused stored procedures.
  7. Validation forAllow Null condition which can be done at the database level.
  8. Validation of the fact that all the Stored Procedures and Functions have been successfully executed when the Database under test is blank.
  9. Validation of the overall integration of the stored procedure modules as per as the requirements of the application under test.

Some of the interesting tools for testing stored procedures are LINQ , SP Test tool etc.

Trigger testing

  1. Whether the required coding conventions have been followed during the coding phase of the Triggers.
  2. Check whether the triggers executed for the respective DML transactions have fulfilled the required conditions.
  3. Whether the trigger updates the data correctly once they have been executed.
  4. Validation of the required Update/Insert/Delete triggers functionality in the realm of the application under test.

Database server validations

Руководство по тестированию баз данных (данных) с примерами тестовых случаев

  1. Check the database server configurations as specified by the business requirements.
  2. Check the authorization of the required user to perform only those levels of actions which are required by the application.
  3. Check that the database server is able to cater to the needs of maximum allowed number of user transactions as specified by the business requirement specifications.

Functional database testing

The Functional database testing as specified by the requirement specification needs to ensure most of those transactions and operations as performed by the end users are consistent with the requirement specifications.

Following are the basic conditions which need to be observed for database validations.

  • Whether the field is mandatory while allowing NULL values on that field.
  • Whether the length of each field is of sufficient size?
  • Whether all similar fields have same names across tables?
  • Whether there are any computed fields present in the Database?

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

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

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

Следующие проверки важны

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

 

Логин и безопасность пользователя

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Руководство по тестированию баз данных (данных) с примерами тестовых случаев

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

  1. Тестирование базы данных требует большого опыта, и это очень утомительная работа
  • Реальность: Эффективное и действенное тестирование базы данных обеспечивает долгосрочную функциональную стабильность всего приложения, поэтому за ним необходимо приложить немало усилий.
  1. Тестирование базы данных добавляет дополнительное узкое место работы
  • Реальность. Напротив, тестирование базы данных повышает ценность всей работы, выявляя скрытые проблемы и тем самым активно помогая улучшить общее приложение.
  1. Тестирование базы данных замедляет общий процесс разработки
  • Реальность: Значительный объем тестирования базы данных помогает в общем улучшении качества приложения базы данных.
  1. Тестирование базы данных может быть чрезмерно дорогостоящим
  • Реальность: Любые расходы на тестирование базы данных — это долгосрочные инвестиции, которые приводят к долгосрочной стабильности и надежности приложения. Таким образом, расходы на тестирование базы данных необходимы.

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

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

Оформить заказ — Тестирование базы данных Интервью Вопросы и ответы