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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• тип данных
• длина поля

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

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

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

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

1. Проверьте, требуется ли

• Основной ключ
• Внешний ключ

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

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

• Clusterиндексы редактора
• не Clusterиндексы редактора

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Препятствует ли приложение пользователю продолжить работу с приложением в случае

• неверное имя пользователя, но действительный пароль
• действительное имя пользователя, но неверный пароль.
• неверное имя пользователя и неверный пароль.

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

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

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

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

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

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

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

1. Наиболее часто используемые пользовательские транзакции могут повлиять на производительность всех остальных транзакций, если они неэффективны.
2. По крайней мере, одна нередактируемая пользовательская транзакция должна быть включена в окончательный набор тестов, чтобы производительность таких транзакций можно было отличить от других, более сложных транзакций.
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 Тестирование необходимо.

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

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

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