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

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

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

Тестирование базы данных проверяет схему базы данных, таблицы и триггеры. Оно подвергает базу данных нагрузке и может включать в себя выполнение сложных запросов для тщательной проверки её возможностей и отзывчивости. Также тестируются системы управления базами данных (СУБД), такие как Oracle и SQL Server.

Что такое схема базы данных?

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

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

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

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

1. Некоторые баги можно найти только с помощью этого вида тестирования.

2. Определённые условия использования могут быть протестированы только в базе данных.

3. Тестирование БД повышает стабильность и безопасность.

4. Тестирование БД обеспечивает согласованность.

Пример функции базы данных

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

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

2. Ничего из ваших данных (то есть деньги) не потерялось по дороге.

3. Приложение не вышло из строя, а закончило перевод успешно.

4. Транзакция прошла безопасно.

5. Ваши деньги теперь спокойно лежат на вкладе (поздравляем!)

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

Снаружи всё выглядит хорошо, но внутри — это катастрофа.

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

Слово «принципы» может звучать скорее как «почему», чем как «как». Поверьте мне, это две важные практические концепции.

1. Свойства ACID

   • Атомарность (Atomicity)

   • Согласованность (Consistency)

   • Изолированность (Isolation)

   • Устойчивость / долговечность (Durability)

2. Целостность данных

Что такое свойства ACID?

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

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

Принципы ACID

• Атомарность (A, Atomicity) подразумевает, что каждая транзакция рассматривается как атомарная единица. Это означает, что каждая транзакция должна быть завершена полностью, иначе она потерпит неудачу. Такое отношение к каждой транзакции позволяет избежать неприятной ситуации, когда денежный перевод завершается наполовину. Звучит тревожно, правда? При атомарности, если транзакция завершается наполовину, когда что-то идёт не так — вся транзакция терпит неудачу. Деньги возвращаются. И никакого стресса.

• Согласованность (C, Consistency) подразумевает, что база данных остаётся согласованной после транзакции. Ни одна транзакция не может негативно повлиять на другие данные в базе. Если вы положите деньги на свой банковский счет, они не будут сняты с чужого счета.

• Изолированность (I, Isolation) предотвращает пересечение потоков. Она гарантирует, что в случае одновременного проведения нескольких транзакций каждая из них будет рассматриваться так, как будто это единственная транзакция в базе данных. Ничья информация с чужой не смешивается.

• Устойчивость (D, Durability) подразумевает, что база данных достаточно устойчива, чтобы сохранить все последние транзакции, даже если произойдет сбой в системе. Опять же, есть практические причины требовать от базы данных такой устойчивости. Например, если вы сделаете денежный перевод, а через десять минут база данных выйдет из строя, как вы узнаете, что нужно сделать перевод ещё раз? Наличие таких строгих требований предотвращает путаницу со стороны конечных пользователей.  

Целостность данных

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

• поддаются проверке

• можно восстановить

• являются точными

• являются полными

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

Как отметил Хью Прайс в эпизоде The QA Lead Podcast под названием Your Data Quality Sucks, обеспечение работы систем на высококачественных и безопасных данных становится всё более важным, поскольку всё больше компаний создают собственные банки данных.

Язык управления базами данных

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

Команды DML обычно используются в сочетании с языком DDL, который служит для создания и изменения объектов базы данных — таких как таблицы, представления и индексы. DDL и DML составляют основные компоненты системы баз данных, позволяя пользователям создавать, изменять и манипулировать данными безопасным, эффективным и надёжным способом. Использование DML в управлении базами данных позволяет организациям хранить, управлять и анализировать большие объёмы данных, что делает его важнейшим инструментом для бизнеса в современном мире, основанном на данных.

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

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

Есть три типа тестирования БД:

1. Структурное

2. Функциональное

3. Нефункциональное 

Внутри этих трёх типов есть свои подтипы. О них я тоже расскажу.

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

Структурное тестирование проверяет элементы хранилища данных, которые используются для хранения данных. Эти элементы скрыты от конечных пользователей и происходят полностью «за кулисами». Тестировщики выполняют эти тесты путём написания SQL-запросов.

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

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

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

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

• Oracle Data Integrator

• Microsoft SQL Server

• IBM InfoSphere

• webMethods

• CloverDX

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

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

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

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

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

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

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

Тестирование «чёрного ящика» (Black Box)

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

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

Тестирование «белого ящика» (White Box)

Это полная противоположность тестированию «чёрного ящика». При тестировании «белого ящика» тестировщик полностью понимает внутреннюю структуру тестируемого программного обеспечения.

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

Модульное (юнит) тестирование 

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

Модульные тесты для баз данных обычно включают в себя написание автоматизированных тестов, которые выполняют определённые SQL-команды для объекта или модуля базы данных и проверяют, что возвращаются ожидаемые результаты. Например, модульный тест для хранимой процедуры может включать передачу процедуре набора входных параметров и проверку правильности выходных данных. Используя модульные тесты таким образом, разработчики могут убедиться, что каждый объект базы данных работает так, как ожидается, и что любые изменения в схеме базы данных или коде приложения не приведут к непредвиденным последствиям или ошибкам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В заключение приглашаем всех начинающих тестировщиков на открытые уроки:

• 3 апреля: «Какая роль функционального тестировщика в команде разработки ПО?» > Записаться

• 17 апреля: «Как составить баг-репорт, чтобы коллеги сказали вам “спасибо”» > Записаться