В наши дни мобильные и веб-приложения становятся все более сложными благодаря таким технологиям, как Android, а также из-за наличия множества приложений для смартфонов. Чем сложнее фронтенд, тем более запутанным становится бэкенд.
Поэтому так важно иметь навык эффективного тестирования баз данных, чтобы обеспечить их безопасность и качество. В этом руководстве вы узнаете все о тестировании данных: зачем, как и что тестировать.
БЕСПЛАТНО СКАЧАТЬ QA КНИГИ можно в телеграм канале "Библиотека тестировщика"
База данных – одна из обязательных частей любого ПО.
Неважно, идет ли речь о клиент-серверном, одноранговом (P2P), десктопном, мобильном или веб-приложении, корпоративном или частном бизнесе – база данных необходима для любого бэкенда.
Аналогично, будь то сфера здравоохранения, финансов, лизинг, ритейл, почтовые рассылки или управление космическим кораблем – база данных всегда выполняет свою работу за кадром.
По мере увеличения сложности приложений возникает необходимость в более мощной и безопасной базе данных (БД). А для приложений с высокой частотой транзакций (например, банковские или финансовые приложения), возникает необходимость в полнофункциональном инструменте управления БД.
В настоящее время существуют Большие данные, которые являются настолько сложными, что традиционные базы данных не могут с ними справиться.
На рынке доступно несколько инструментов для работы с базами данных, например, MS-Access, MS SQL Server, SQL Server, Oracle, Oracle Financial, MySQL, PostgreSQL, DB2, Toad, Admirer и др. Эти инструменты различаются по стоимости, надежности, возможностям и безопасности. Каждый из них имеет свои преимущества и недостатки.
Содержание
- Зачем тестировать базу данных?
- Контрольный список тестирования баз данных
- Мероприятия по тестированию данных
- Как протестировать базу данных (пошаговый процесс)
- Некоторые практические советы
- Заключение
Зачем тестировать базу данных?
Ниже мы рассмотрим, почему необходимо проверять те или иные аспекты баз данных.
1. Маппинг данных
В программных системах данные часто перемещаются туда-сюда от пользовательского интерфейса к внутренней базе данных и наоборот. На некоторые вещи обязательно следует обратить внимание:
- Проверьте, сопоставлены ли поля в формах пользовательского интерфейса с соответствующими полями в таблице БД. Обычно правила сопоставления определяются в документах с требованиями.
- Всякий раз, когда определенное действие выполняется во фронтенде приложения, в бэкенде вызывается соответствующее действие CRUD (Create, Retrieve, Update и Delete). Тестировщик должен проверить, правильное ли действие было вызвано, и завершилось ли оно успешно.
2. Проверка свойств ACID
К свойствам ACID (atomicity, consistency, isolation, durability) относятся атомарность, непротиворечивость, изоляция, устойчивость. Каждая транзакция, выполняемая БД, должна соответствовать этим четырем свойствам.
- Атомарность означает, что транзакция завершается либо успешно, либо ошибочно. Это предполагает, что если хотя бы одна часть транзакции не прошла, вся транзакция должна считаться неуспешной. Обычно это называется правилом “все или ничего”.
- Непротиворечивость. Результатом транзакции всегда будет валидное состояние БД.
- Изоляция. Если есть несколько транзакций и они выполняются одновременно, результат/состояние БД должно быть таким же, как если бы они выполнялись одна за другой.
- Устойчивость. Как только транзакция была выполнена, никакие внешние факторы, такие как потеря питания или краш ПО, не должны быть в состоянии изменить её.
3. Целостность данных
Для любой из операций CRUD на всех формах и экранах должны отображаться самые последние обновленные значения/статусы данных. Недопустима ситуация, когда значения на одном экране обновились, а на другом отображаются старые.
Когда приложение находится в процессе выполнения, конечный пользователь в основном использует операции CRUD:
- C: Create – Когда пользователь “сохраняет” любую новую запись в БД, выполняется операция “Create”.
- R: Retrieve – Когда пользователь “ищет” или “просматривает” любую сохраненную запись БД, выполняется операция “Retrieve”.
- U: Update – Когда пользователь “редактирует”‘ или “изменяет” уже существующую запись БД, выполняется операция “Update”.
- D: Delete – Когда пользователь “удаляет” любую запись из БД, выполняется операция “Delete”.
Любая операция с базой данных, выполняемая конечным пользователем, всегда является одной из четырех вышеперечисленных.
Поэтому стоит разрабатывать тест-кейсы проверки БД таким образом, чтобы они включали в себя проверку данных во всех частях ПО, где они отображаются, чтобы убедиться, что они неизменны и одинаковы.
4. Соответствие бизнес-правилам
Большие и сложные БД содержат более сложные компоненты, такие как реляционные ограничения, триггеры, хранимые процедуры и т.д. Поэтому тестировщикам нужно создавать соответствующие SQL-запросы для проверки этих сложных объектов.
Контрольный список тестирования баз данных
1. Транзакции
При тестировании транзакций важно убедиться, что они удовлетворяют свойствам ACID.
Обычно используются следующие команды:
- BEGIN TRANSACTION TRANSACTION#
- END TRANSACTION TRANSACTION#
Команда отката гарантирует, что база данных останется в целостном состоянии.
- ROLLBACK TRANSACTION#
После выполнения этих команд используйте Select, чтобы убедиться, что необходимые изменения отображаются.
- SELECT * FROM TABLENAME <таблицы, с которыми связаны транзакции>
2. Схемы баз данных
Схема базы данных – это не что иное, как формальное определение того, как данные будут организованы внутри БД. Чтобы проверить схему:
- Определите требования, на основании которых работает база данных. Пример требований:
- Первичные ключи должны быть созданы до создания любых других полей.
- Внешние ключи должны быть полностью проиндексированы для удобства поиска и извлечения информации.
- Имена полей начинаются или заканчиваются определенными символами.
- Поля имеют ограничения, согласно которым определенные значения могут или не могут быть сохранены.
- Используйте один из следующих методов в зависимости от ситуации:
- SQL-запрос
DESC <имя таблицы>для проверки схемы. - Регулярные выражения для проверки имен отдельных полей и их значений.
- Инструменты типа SchemaCrawler.
- SQL-запрос
3. Триггеры
Когда определенное действие происходит в определенной таблице, часть кода (триггер) должна быть выполнена автоматически.
Например, в школу поступил новый ученик. Ученик посещает 2 предмета: математику и естественные науки. Ученик добавлен в таблицу “Student table”. Триггер может выполнить операцию добавления ученика в соответствующие таблицы предметов, как только он будет добавлен в “Student table”.
Стандартный подход тестирования – сначала самостоятельно выполнить SQL-запрос, встроенный в триггер, и отследить результат. Затем следует вызвать триггер целиком и сравнить результаты.
Тестирование БД проводится как методом “черного ящика”, так и методом “белого ящика”.
Тестирование “белого ящика”
Для вставки, обновления или удаления данных используются заглушки и драйверы, которые приведут к вызову триггера. Основная идея заключается в том, чтобы протестировать БД отдельно, еще до интеграции с внешним интерфейсом (UI).
Тестирование “черного ящика”
Если интеграция UI и БД реализована, мы можем вставлять/удалять/обновлять данные во фронтенде таким образом, чтобы вызвался триггер. После этого можно использовать операторы Select для получения данных из БД, чтобы проверить, успешно ли триггер выполнил соответствующую операцию.
Второй способ тестирования – это непосредственная загрузка данных, которые вызовут триггер, и проверка того, работает ли он так, как задумано.
4. Хранимые процедуры
Хранимые процедуры более или менее похожи на определяемые пользователем функции. Они могут быть вызваны с помощью команд Call Procedure/Execute Procedure. Вывод обычно представлен в виде наборов результатов.
Процедуры хранятся в реляционных СУБД и доступны для внешних приложений.
Процедуры также тестируются в процессе работы:
- Методом “белого ящика”: для вызова хранимых процедур используются заглушки, а затем результаты проверяются на соответствие ожидаемым значениям.
- Методом “черного ящика”: операция выполняется с помощью UI приложения, а затем оцениваются результаты.
5. Ограничения полей
Следует проверить значения по умолчанию, уникальные значения и внешние ключи:
- Выполните внешнюю операцию, результат выполнения которой проверяется на какие-либо условия в качестве объекта базы данных.
- Проверьте результат с помощью SQL-запроса.
Проверить значение по умолчанию для определенного поля довольно просто. Это часть проверки бизнес-правил. Вы можете сделать это вручную или использовать такие инструменты, как QTP. Вручную можно добавить для поля значение, отличное от значения по умолчанию, через интерфейс тестируемого ПО и проверить, не приведет ли это к ошибке.
Пример кода на VBScript:
Function VBScriptRegularexpressionvlaidation(pattern , string_to_match) Set newregexp = new RegExp newregexp.Pattern = “&lt;Default value as required by the business requirements&gt;” newregexp.Ignorecase = True newregexp.Global = True VBScriptRegularexpressionvlaidation = newregexp.Test(string_to_match) End Function Msgbox VBScriptRegularexpressionvlaidation(pattern , string_to_match)
Результатом приведенного выше кода будет значение True, если значение по умолчанию существует, или False, если его нет.
Проверку уникального значения можно выполнить точно так же, как мы делали это для значений по умолчанию. Попробуйте ввести значения из пользовательского интерфейса, которые будут нарушать это правило, и проверьте, появится ли ошибка.
Код для автоматизации на VBScript:
Function VBScriptRegularexpressionvlaidation(pattern , string_to_match) Set newregexp = new RegExp newregexp.Pattern = “&lt;Unique value as required by the business requirements&gt;” newregexp.Ignorecase = True newregexp.Global = True VBScriptRegularexpressionvlaidation = newregexp.Test(string_to_match) End Function Msgbox VBScriptRegularexpressionvlaidation(pattern , string_to_match)
Для проверки ограничения внешних ключей используйте загрузку данных, которые нарушают это ограничение, и посмотрите, валидирует их приложение или нет. Наряду с загрузкой данных на бэкенд, выполните эти же операции из пользовательского интерфейса и проверьте, отображается ли соответствующая ошибка.
Мероприятия по тестированию данных
Тестировщик баз данных должен сосредоточиться на следующих видах тестирования.
1. Обеспечение качества маппинга данных
Маппинг данных – один из ключевых аспектов в БД, и он должен быть тщательно проверен тестировщиком.
Убедитесь, что отображение данных на различных формах или экранах ПО в схемах БД не только точное, но и соответствует проектной документации (SRS/BRS) или коду. По сути, вам необходимо проверить соответствие между каждым полем внешней формы и соответствующим полем внутренней базы данных.
Для всех операций CRUD проверьте, что соответствующие таблицы и записи обновляются, когда пользователь нажимает “Сохранить”, “Обновить”, “Поиск” или “Удалить” из графического интерфейса приложения.
Нужно проверить:
- Маппинг таблиц, столбцов и типов данных.
- Поиск (Lookup) для данных БД.
- Вызывается ли корректная CRUD-операция для каждого действия пользователя в пользовательском интерфейсе.
- Успешно ли выполняется операция CRUD.
2. Обеспечение ACID-свойств транзакций
При тестировании БД обязательно нужно должным образом проверить ACID-свойства. Необходимо убедиться, что каждая отдельная транзакция удовлетворяет всем свойствам базы данных.
Давайте рассмотрим простой пример со следующим кодом:
CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));
Тестовая таблица ACID будет иметь два столбца – A и B. Существует ограничение целостности, согласно которому сумма значений в A и B всегда должна быть равна 100.
Тест на атомарность проверяет, что любая транзакция, выполняемая с этой таблицей, удовлетворяет свойству “все или ничего”. Т.е. что ни одна запись не будет обновлена, если какой-либо этап транзакции провален.
Тест на согласованность гарантирует, что при каждом обновлении значения в столбце A или B сумма всегда будет равна 100. Он не позволит вставить/удалить/обновить значение в A или B, если сумма будет отлична от 100.
Тест изолированнность гарантирует, что если две транзакции выполняются в одно и то же время и пытаются изменить данные тестовой таблицы ACID, то эти транзакции выполняются изолированно.
Тест на надежность гарантирует, что после осуществления транзакции таблица останется в прежнем состоянии, даже в случае потери питания, сбоев или ошибок ПО.
Эта область требует более строгого, тщательного и внимательного тестирования, если ваше приложение использует распределенную базу данных.
3. Обеспечение целостности данных
Учтите, что разные модули (т.е. экраны или формы) приложения используют одни и те же данные разными способами и выполняют различные операции CRUD над этими данными.
Протестируйте, что везде отображается последнее актуальное состояние данных. Система должна показывать обновленные и самые последние значения или состояния общих данных на всех формах и экранах. Это называется целостностью данных.
Тест-кейсы для проверки целостности данных БД:
- Проверьте, все ли триггеры установлены для обновления записей таблицы.
- Проверьте, нет ли некорректных данных в основных столбцах каждой таблицы.
- Попробуйте внести некорректные данные в таблицы и проследите, не произойдет ли сбой.
- Проверьте, что произойдет, если вы попытаетесь внести данные в дочернюю таблицу до вставки этих данных в родительскую (попробуйте поиграть с первичными и внешними ключами).
- Проверьте, произойдет ли сбой, если вы удалите запись, на которую все еще ссылаются данные в любой другой таблице.
- Проверьте, синхронизированы ли реплицированные серверы и базы данных.
4. Обеспечение точности установленных бизнес-правил
Сегодня базы данных предназначены не только для хранения записей. Фактически, они превратились в чрезвычайно мощные инструменты, которые предоставляют разработчикам широкую поддержку для реализации бизнес-логики на уровне БД.
Простыми примерами мощных функций являются “ссылочная целостность”, реляционные ограничения, триггеры и хранимые процедуры.
Таким образом, используя эти и многие другие возможности, предлагаемые БД, разработчики реализуют бизнес-логику на уровне БД. Тестировщик должен убедиться, что реализованная бизнес-логика корректна и работает точно.
Приведенные выше пункты являются наиболее важными при тестировании БД. Теперь давайте перейдем к более подробной инструкции.
Как протестировать базу данных (пошаговый процесс)
Общий процесс тестирования базы данных не сильно отличается от тестирования любого другого приложения.
Ниже перечислены основные шаги:
- Настройте тестовое окружение.
- Выполните тесты.
- Проверьте результаты каждого теста.
- Провалидируйте полученные результаты в соответствии с ожидаемыми.
- Сообщите о результатах соответствующим заинтересованным сторонам.
Обычно для разработки тестов используются SQL-запросы. Наиболее часто используемой командой является SELECT.
Помимо SELECT, в SQL есть еще 3 важных типа команд:
- DDL: язык описания данных
- DML: язык манипулирования данными
- DCL: язык управления данными
Давайте рассмотрим синтаксис наиболее часто используемых команд.
DDL использует CREATE, ALTER, RENAME, DROP и TRUNCATE для работы с таблицами (и индексами).
DML включает в себя операторы для добавления, обновления и удаления записей.
DCL имеет дело с предоставлением пользователям прав для манипулирования данными и доступа к ним. Используются два оператора – Grant и Revoke.
Синтаксис Grant:
Grant select/update On <table name> To <user id1, user id2…useridn>;
Синтаксис Revoke:
Revoke select/update on <table name> from<user id1, user id2…useridn>;
Некоторые практические советы
1. Пишите запросы самостоятельно
Для более точного тестирования базы данных тестировщик должен очень хорошо знать команды SQL (Structured Query Language) и DML (Data Manipulation Language). Он также должен знать внутреннюю структуру БД.
Вы можете объединить проверки GUI и проверки данных в соответствующих таблицах для лучшего тестового покрытия. Если вы используете SQL-сервер, можно применить SQL Query Analyzer для написания запросов, их выполнения и получения результатов. Это довольно надежный способ тестирования базы данных, если приложение имеет небольшой или средний уровень сложности.
Если приложение очень сложное, то тестировщику может быть трудно или вовсе невозможно написать все необходимые SQL-запросы. Для сложных запросов вы можете обратиться за помощью к разработчикам, тем самым вы сможете также улучшить свои навыки по SQL.
2. Контролируйте данные в каждой таблице
Вы можете выполнить проверку данных, тестируя результаты выполнения операций CRUD. Это можно сделать вручную с помощью пользовательского интерфейса приложения, если реализована его интеграция с БД. Но когда в разных таблицах базы данных хранятся огромные данные, это может быть утомительной задачей.
Для ручного тестирования данных тестировщик должен хорошо знать структуру таблиц базы данных.
3. Получение готовых запросов от разработчиков
Это самый простой способ тестирования базы данных. Выполните любую CRUD-операцию из графического интерфейса и проверьте ее результат, выполнив соответствующие SQL-запросы, который вам предоставил разработчик. Это не требует глубоких знаний SQL и структуры БД приложения.
Однако этот метод следует использовать с осторожностью. Что, если запрос разработчика семантически неверен или не соответствует требованиям пользователя? Такой запрос просто не сможет корректно проверить данные.
4. Используйте инструменты автоматизации тестирования баз данных
Существует несколько инструментов, используемых для процесса тестирования данных. Вы должны выбрать подходящий в соответствии с вашими потребностями и использовать его в своих задачах.
Заключение
С ростом количества и сложности функционала, факторов и процессов, которые необходимо протестировать в базе данных, растет спрос на тестировщиков, которые имеют экспертизу в ключевых концепциях баз данных. Несмотря на некоторые негативные мнения о том, что тестирование баз данных замедляет процессы разработки и требует больших дополнительных расходов, эта область тестирования имеет сегодня большое значение и пользуется спросом.
Перевод статьи “Database Testing Complete Guide (Why, What, And How To Test Data)”