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

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

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

Установка

Прежде чем начать тестировать базу данных, нужно правильно её установить. Потому что обычная установка из .exe файла с помощью установщика Windows бесполезна для проведения каких-либо тестов. Нам нужно произвести установку в режиме отладки, так называемый debug mode. Я хотел бы показать это на платформе Windows, которая является одной из самых распространённых в мире.

Для этого нам нужно три составляющие, а именно:

Visual C++ (при установке Visual Studio обязательно добавьте компонент «Desktop Development with C++«),
CMake
Git

Если у вас есть все эти три компонента на вашем ПК, вы сможете начать непосредственную установку. Нужно создать папку для MariaDB и перейти в неё. В командной строке переходим в созданную папку и затем выполняем команды:

mkdir Test cd Test git init git clone -b mariadb-10.5.15 https://github.com/MariaDB/server.git

Теперь вы скачали исходный код из репозитория. А затем нужно перейти в папку server, создать новую папку bld и перейти в нее:

cd server mkdir bld cd bld

Таким образом уже почти всё подготовлено и осталось только выполнить CMake как кроссплатформенный генератор системы сборки с помощью следующей команды:

cmake ..

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

cmake --build . --config Debug

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

А теперь самая захватывающая часть нашей статьи. Давайте создадим наш первый тест. Это не так просто, но и не так сложно, как кажется. Вот некоторые правила, которые вы должны знать.

Вы должны использовать расширение .test при сохранении своего теста и сохранять его необходимо и сохранять его нужно в папке, которая находится вот по такому пути c:\Test\server\mysql-test\main

Но запускать наши тесты мы будем из папки, которая находится вот по этому пути c:\Test\server\bld\mysql-test

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

А теперь открываем любой текстовый редактор, например Notepad и пишем наш первый тест:

--echo # --echo # Test #00001: avarage --echo # create table t1 ( pk int primary key, height int ); insert into t1 values (0,9), (1,5), (2,4); show create table t1; select avg(height) from t1; drop table t1;

Теперь нам нужно сохранить этот файл с расширением .test, в моем случае я назвал его sergei.test

В этом тесте мы создаем таблицу с тремя строками и вычисляем среднюю высоту.

Запускаем наш тест командой:

mysql-test-run.pl sergei.test

Наш тест пройден успешно, потому что в MariaDB в этом тестовом сценарии нет ошибок и нет ошибок в тестовом скрипте.

Иногда нам нужно записывать наши результаты. Это сделать достаточно просто. Надо запустить тест с опцией записи:

mysql-test-run.pl sergei.test --record

При этом создастся другой файл с расширением .result в том же каталоге, что и тестовый файл с тем же именем. В моем случае это sergei.result

Заключение

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

Схема
Таблицы базы данных
Столбцы
Ключи и индексы
Хранимые процедуры
Триггеры
Проверка сервера базы данных
Проверка дублирования данных

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

Какие нужны базовые знания, чтобы стать инженером по тестированию ПО? Что необходимо выучить, чтобы получить первую работу? У кого больше шансов сменить работу и попасть в IT? Приглашаю вас на бесплатный урок, где обсудим, кто и как приходит в технологии через профессию тестировщик программного обеспечения. Урок подойдет тем, кто желает стать тестировщиком, получить новую профессию, работать удаленно.

database development
testing

Блог компании OTUS
Тестирование IT-систем
Тестирование веб-сервисов

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

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

Абсолютное большинство современных приложений и сайтов зависят от баз данных, поэтому тестирование БД является важным, необходимым этапом.

Чаще всего (особенно при экспресс-проверках) проводится путем создания и выполнения какого-то количества ключевых проверочных запросов: также проводится нагрузочное и стресс-тестирование БД.

Быстрый пример

Например, есть приложение, собирающее данные о пользователях и их действиях (транзакциях), и передающее эти данные в БД. Протестировать такое приложение нужно следующим образом (проверяя следующее):

Данные о транзакциях должны корректно сохраняться в БД и корректно возвращаться приложению
Корректные данные не должны теряться «в процессе»
Сохраняются только завершенные (то есть корректные) транзакции; а некорректные, то есть незавершенные, прерываются приложением
Доступ к БД должен даваться только после авторизации; неавторизованный доступ к данным пользователей должен быть запрещен

Необходимость тестирования БД

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

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

Отличия между тестированием БД и тестированием интерфейса

Тестирование БД	Тестирование интерфейса
Валидация данных и проверка их целостности. Подразумевает тестирование компонентов, недоступных пользователям, в том числе систем управления БД типа Oracle или MySQL	Проверка визуального интерфейса. Только компоненты, видимые и доступные пользователям: меню, кнопки и прочие компоненты интерфейса, создаваемые средствами например «визуального программирования» на C# или Qt
Тестирование процедур, представлений БД, схем, индексов, ключей, триггеров	Функциональность кнопок, форм, полей ввода, меню, изображений, навигации, и в целом функциональность «с точки зрения пользователя»
Команда должна хорошо разбираться в базах данных вообще и в языке SQL, а также хорошо понимать архитектуру приложения и БД	Хорошо понимать бизнес-требования, функциональные и нефункциональные требования, иметь опыт в тестировании юзабилити
БД получает данные из разных источников, как от пользователя, так и от других приложений и ОС	Пользователь вводит данные вручную

Типы тестирования БД

Тестирование структуры БД — проверка таблиц и колонок, схем, процедур и представлений, триггеров и ключей
Функциональное— тестирование основных функций БД; по методу черного или белого ящика
Нефункциональное — в основном тестирование производительности: нагрузочное, стрессовое и другие виды

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

Выполняется администраторами БД и/или членами QA-команды с хорошими скиллами SQL (об SQL в QA подробнее здесь, или в ТГ-канале). Проверяют структурные (архитектурные) компоненты БД.

Тестирование схемы БД (маппинга)

Проверка корректности сопоставления (маппинга) объектов БД с данными пользователей
Валидация различных форматов схем
Поиск «потерянных» объектов в БД (таблиц, представлений, колонок, ключей и т.п.)

Для тестирования схем существуют инструменты, например в Microsoft SQL Server, где можно валидировать схему простыми запросами.

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

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

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

Часто применяемые инструменты: LINQ, SP Test tool

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

Соблюдаются ли требования по качеству и оформлению кода (coding conventions) что касается триггеров
Соответствуют ли триггеры условиям
Правильно ли обновляются данные при срабатывании триггеров
Валидация триггеров Update/Insert/Delete

Тестирование таблиц и колонок в БД

Валидация соответствия типов данных в БД — типам данных в полях ввода в приложении
Валидация соответствия длины полей данных в БД — длине полей данных в приложении
Проверка наличия таблиц/колонок, не привязанных к объектам в приложении
Соблюдение правил именования таблиц и колонок, их соответствие бизнес-требованиям
Проверка индексов и ключей, их соответствие требованиям
Проверка ключей на Unique и NOT NULL
Проверка длины и типа данных индексов и ключей, их соответствия требованиям

Тестирование сервера БД

Способен ли сервер БД обрабатывать ожидаемый и максимальный объемы транзакций, описанные в бизнес-требованиях
Соответствует ли конфигурация сервера БД бизнес-требованиям
Соответствует ли требованиям процесс авторизации пользователей

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

Проводится с точки зрения конечных пользователей. Отвечает ли бизнес-требованиям функциональность БД (операций и транзакций).

Черный ящик

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

Преимущества:

Простое и доступное тестировщикам начального уровня, проводится на ранних стадиях разработки продукта
Стоимость разработки тест-кейсов небольшая, меньше чем при тестировании белого ящика

Недостатки:

Нельзя охватить все дефекты
Часто неизвестны масштаб и длительность такого тестирования

Белый ящик

Проводится с пониманием тестировщиками структуры БД.

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

Часто применяемые техники белого ящика: покрытие условий, покрытие решений, покрытие операторов, и так далее. Далее передача на рефакторинг.

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

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

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

Проверка, как одновременное выполнение множества транзакций влияет на производительность БД.

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

Примеры

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

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

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

В основном для стресс-тестирования применяются инструменты LoadRunner и конечно JMeter.

Пример

Имеем например CRM-приложение автоматизации продаж, которое может выдержать максимально 50000 одновременных пользователей. А если увеличить нагрузку до 51000, параллельно выполняя транзакции обновления или добавления записей в БД? После каждой транзакции приложение должно синхронизироваться с БД. Если все прошло без проблем, нагрузка увеличивается до 52000, и т.п.

Процессы тестирования БД

Процесс тестирования БД в целом более-менее стандартный:

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

В тестировании БД применяются стандартные SQL-операторы, чаще всего Select, а также операторы типов DDL, DML, DCL — Create, Insert, Update и т.п.

Этапы тестирования БД

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

Первый этап состоит в проверке начального состояния БД, ее целостности. Далее БД проверяется на готовность к определенным тест-кейсам, и при неготовности настраивается.

Чистка базы данных — если в БД есть важные настоящие данные, нужно удалить
Настройка фикстур (фиксированных значений) — ввод фиксированных данных в БД и проверка ее состояния
Выполнение тестов, верификация результатов и генерация репортов

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

Техники тестирования БД

Тестирование схемы БД

Тестируются все объекты в Схеме.

Верификация названий баз данных
Верификация девайсов для хранения логов и дампов
Проверка свободного места по каждой БД
Проверка важных параметров БД

Проверка таблиц и колонок

Проверяется следующее в каждой БД:

Названия таблиц
Названия колонок
Типы колонок
NULL-значения
Дефолтные значения
Права доступа

Ключи и индексы

Верифицируются в каждой таблице:

Первичные (primary) ключи
Внешние (foreign) ключи
Соответствие типов данных внешнего ключа колонки и колонки в другой таблице
Индексы: кластерные и некластерные, уникальные и неуникальные

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

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

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

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

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

Сценарии настройки сервера

Настройки БД с нуля
Изменения настроек существующей БД

Интеграционные тесты SQL-сервера

Выполняются обычно после юнит-тестирования.

Проверяются хранимые процедуры, операциями select, insert, update, delete
В таблицах ищут конфликты и несовместимости, а именно:
Между схемой и тригерами
Между схемой и хранимыми процедурами
Между триггерами и хранимыми процедурами

Пример методики функционального тестирования БД

Одна из методик состоит в разделении БД на части (модули) по их функциональности:

Тип 1. Основная функциональность продукта. По каждой важной функции определяют схему, триггеры и хранимые процедуры, отвечающие за имплементации этой функциональности, и выносят в первую группу. Далее тестируют первую отдельно от второй.
Тип 2. Менее важная функциональность. Тестируют data flow и корректность обработки данных, где это кажется нужным, начиная с фронтенда.

Когда сервис делает запрос на передачу/сохранение данных из/в БД, вызываются хранимые процедуры
Эти процедуры вызовут обновления в каких-то таблицах
Эти процедуры и будут тестироваться, а результаты будут видны в таблицах

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

Оно предполагает составление списка главных функций БД и связанных с ними хранимых процедур. Выполняются следующие действия:

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

Бенчмарк-тестирование

Даже в хорошо спроектированной системе, более-менее свободной от багов и проблем с данными, есть смысл протестировать производительность БД «на будущее».

Производительность системы в целом
Производительность наиболее активно используемых функций
Особенно их тайминги: максимальное, минимальное и средневзвешенное время выполнения самых важных функций системы
А также объемное тестирование

Тестирование БД через фронтенд

Дефекты на бекенде можно определить, тестируя фронтенд.

Написать запросы из фронтенда к БД
Выбрать запись в БД, поменять значение в нужных полях, и сохранить запись, применяя UPDATE или обновляя хранимые процедуры
Вставить новый элемент на фронтенде, заполнив данные, и сохранить запись в БД — через INSERT или вставку хранимых процедур
Выбрать имеющуюся запись в БД, нажать кнопку DELETE (REMOVE), подтвердить удаление — через DELETE, или через удаление хранимых процедур
Повторить эти тест-кейсы с невалидными данными и проверить состояние БД

Сценарии тестирования БД

Распространенные сценарии тестирования БД:

Тестирование структуры БД

Проверка имени БД, верификация устройств хранения данных, логов и дампов, проверка наличия свободного места и параметров БД
Имена таблиц в БД, имена колонок и их типов, нулевые значения
Ключи и индексы, первичные и внешние
Соответствие типов данных колонок, кластеризация, уникальность

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

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

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

Создание тестовых сценариев для главных функций; каждая функция должна быть протестирована хотя бы по разу
Повторное выполнение сценариев до достижения результата ( = найдены проблемы)
Изучение лог-файлов на предмет проблем, узких мест, бесконечных циклов, утечек памяти, повреждения данных и т.п.
Как и в примере выше, поиск проблем, начиная от фронтенда
Повторение тест-кейсов с невалидными данными

Тестирование объектов в БД

Объект проверки: схема, таблица, хранимая процедура, триггер.

Схемы

Схема БД — описание структуры БД в формате удобном для управления БД. Представляет собой набор формул, описывающих целостность и совместимость БД.

Схема реляционной базы данных состоит из таких объектов: таблица, поле данных, представление (view), индекс, процедура (в том числе хранимые), триггер, функция, синоним, ссылки между БД, и другие элементы.

Схемы хранятся в словаре (data dictionary). Когда говорят о схеме, зачастую имеют в виду графическое отображение структуры БД.

Схемы могут иметь следующий вид:

Таблицы

Таблицы в БД структурируются по строкам и колонкам.

Пример. В таблице Клиенты может быть номер и ID клиента, его адрес и телефон, пожелания и особенности, и так далее. Данные в таблице хранятся в полях (в самом малом элементе БД). Колонка по какому-то признаку объединяет все элементы этой группы, например все номера телефонов в колонке Телефоны. Строки содержат данные, например по одному клиенту на строку. Поля в БД также называются записями.

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

Сгруппированные серии SQL-операторов, скомпилированные для скорости, доступные нескольким (внешним) программам; предназначены для удобства обслуживания БД, проверки данных, контроля доступа, и улучшения эффективности.

Триггеры

Триггер по определению активируется в результате какого-то события. В основном предназначен для контроля целостности БД.

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

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

Операции тестирования целостности БД:

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

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

Маппинг, или соответствие (сопоставление) данных, является одним из важных скиллов тестировщика на SQL среднего уровня. Стандартная задача: проверить соответствие полей в пользовательском интерфейсе — со связанными с ними полями в бэкенде, то есть в БД. Обычно такие требования содержатся в спецификациях продукта или бизнес-требованиях (SRS/BRS). Если такой маппинг не прописан в требованиях явно, приходится проверять код.

При действиях пользователя в фронтенде происходят соответствующие CRUD-операции в БД в бекенде, и это нужно будет протестировать.

Ключевые аспекты маппинга данных

Проверка в пользовательском интерфейсе на фронтенде, а именно в формах, связаны ли они (то есть имеют ли маппинг) с соответствующими объектами в БД
Проверка действий пользователя и последующих CRUD-операций на бекенде
Проверка правильности действий и их последовательности

Этапы тестирования маппинга

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

Тестирование производительности БД

Плохая производительность, большое время отклика приводят к большим проблемам с продуктом. Во избежание, базы данных тестируются на производительность; это делается до развертывания приложения, превентивно. Это позволяет повысить производительность, надежность и масштабируемость. В рамках тестирования производительности проводится нагрузочное тестирование, а также тестирование расширяемости (масштабируемости). Моделируется нагрузка большим количеством одновременных пользователей, изучается поведение БД.

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

Цель состоит в проверке БД большим количеством одновременных транзакций (то есть эмулированных пользователей). Проверяют:

Среднее время отклика при выполнении транзакции
Углубленно изучается совокупность самых важных транзакций — их производительность
В дополнение к этому, стандартные и менее важные транзакции,
Показатели общей, baseline-производительности системы
Время, нужное на обработку записи

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

Определяет «критические точки» системы. Система нагружается запросами, и в какой-то момент («в точке поломки», breakpoint) выходит из строя; поэтому также называется тестированием на усталость или тестированием на выносливость (fatigue testing). Стресс-тестирование может быть достаточно затратным по времени и усилиям, поэтому нужно тщательное планирование времени и ресурсов.

Инструменты для тестирования производительности БД

На рынке существует достаточно широкий выбор инструментов тестирования БД, особенно что касается нагрузочного тестирования.

Нагрузочное тестирование — Проверка баз данных большой нагрузкой, для определения ее соответствия требованиям	GTmetrixRADviewMercury
Тестирование безопасности — В соответствие требованиям в части безопасности, а также соблюдение регуляторных требований	IBM Optim Data Privacy
Генераторы тестовых данных — Для тестирования производительности, в особенности объемного и стресс-тестирования, скорее всего понадобятся генераторы тестовых данных (отдельный наш материал, посвященный этой теме)	DTM Data Generator
Управление тестовыми данными — Инструменты управления версиями тестовых данных	IBM Optim Test Data Management
Инструменты юнит-тестирования — Для точечного регрессионного тестирования БД	SQLUnitTSQLUnitDBFitDBUnit

Тестирование бэкапа (резервного копирования)

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

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

Типы резервного копирования

Физический бэкап — на физических девайсах типа Veritas Net Back, IBM Tivoli Manager
Логический бэкап, то есть резервные копии логических объектов: таблиц, индексов, хранимых процедур и т.п.

Например, может применяться распространенный Oracle Recovery Manager, состоящий из исходной базы данных из которой будет сделана резервная копия, и RMAN-клиента для работы с копиями.

Резервное тестирование бэкапа проводится путем валидации процессов:

Сделана ли резервная копия физических логических объектов БД
Выполняется ли резервное копирование очень важных данных, и как регулярно
Соответствуют ли процессы бэкапа сформулированным требованиям (если они есть)

Тестирование восстановления

Проверка восстановления базы данных после возможного сбоя: работает ли БД и приложение корректно, восстановились ли данные, есть ли методология восстановления.

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

Лучше проводить тестирование восстановления БД на раннем этапе проекта.

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

Общий порядок действий при тестировании резервного копирования и восстановления

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

Тестирование БД
Тестирование SQL файлов
Тестирование резервного копирования
Тестирование инструментов бэкапа
Тестирование резервного копирования логов, при необходимости

Тестирование безопасности БД

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

Тестируются следующие вещи:

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

Угрозы безопасности БД, по типам:

SQL-инъекции

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

Несанкционированное повышение уровня доступа

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

Отказ из-за перегрузки запросами (DoS)

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

Неразрешенный доступ к данным

Еще один способ — несанкционированный доступ к БД:

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

Подмена идентичности пользователя (спуфинг идентификации)

Злоумышленник получает доступ к учетным данным пользователя и начинает атаки — ворует данные или обходит контроль доступа к БД. Для предотвращения нужно совершенствовать ИТ-инфраструктуру и хорошо контролировать уровни доступа.

Манипуляция данными

Хакер манипулирует данными (чаще всего подменяя их), чтобы выкрасть или подменить.

Техники тестирования безопасности БД

Пенетрационное тестирование

Или «пентест», тест на возможность проникновения. Тестировщик ищет дыры в безопасности, которыми кто-то мог бы воспользоваться.

Оценка рисков

Или поиск рисков. «Исследовательская» техника, базируется на оценке потенциальных рисков и возможных потерь. Подразумевает митинги, обсуждения, анализ.

Тестирование SQL-инъекций

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

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

Подбор паролей

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

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

Аудит безопасности

Комплексная оценка политик безопасности компании, проводимая регулярно. Оценивается соблюдение принятых в данной сфере стандартов безопасности, а также стандартов, упомянутых в бизнес-требованиях к продукту. Принятые стандарты, это чаще всего ISO 27001, BS 15999.

Инструменты тестирования безопасности БД

Zed Attack Proxy

Средство для пентестов веб-приложений. Рассчитано на тестировщиков как с большим опытом в тестировании безопасности, так и на начинающих, которым дали небольшое задание. Есть версии для MacOS, Windows и Linux.

Paros

Перехватывает данные HTTP(S)-трафика между сервером и клиентом, в том числе кукисы и данные из форм. Кроссплатформенный.

Social Engineering Toolkit

Открытый бесплатный инструмент для анализа скорее социальных взаимодействий, чем собственно безопасности. Отправляет письма и java-апплеты с атакующим кодом. Есть версии для всех 3 основных платформ.

Skipfish

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

Vega

Открытый мультиплатформенный инструмент тестирования безопасности сайтов. Находит уязвимости SQL-инъекций, XSS и другие.

Wapiti

Веб-инструмент сканирования страниц сайтов и проверки уязвимости скриптов и форм что касается инъекций. Написан на Python. Обнаруживает ошибки с файлами, уязвимости в базах данных, LDAP и CRLF.

Web Scarab

Java-инструмент для анализа коммуникации по протоколу HTTP(S). Рассчитан на высокий уровень скиллов.

Сложности при тестировании БД

Требования

Приступая к тестированию БД, персонал QA-департамента должен получить требования из всех релевантных источников, особенно функциональные. Часто бывает малое количество требований, или требования не детализированы. Тестирование БД — достаточно сложная задача, требующая опыта и подготовки.

Большая область тестирования

Часто объем тестирования, или точнее область тестирования, оказывается слишком велика. Поэтому нужно предварительно уточнить в плане, что будет объектами тестирования, иначе уйдет много лишнего времени на второстепенные задачи.

Когда будет создан список объектов, нужно оценить количество усилий (времени) на дизайн тестов и их выполнение. Некоторые типы тестирования БД, особенно нагрузочное, могут быть достаточно длительными. Размер БД бывает очень большим, что тоже следует учитывать при нагрузочном тестировании.

Несоответствие тестовой и реальной БД

Часто QA-департаменту для тестирования предоставляется «урезанная» копия реальной БД, содержащая мало данных, которых достаточно только для не очень глубокой проверки. Нужно гарантировать производительность и безопасность всех БД в системе, учитывая неполноту и несоответствие тестовых БД.

Постоянные изменения структуры БД

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

Сложность составления тест-плана

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

Знание SQL

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

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

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

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

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

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

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

Ниже приведены некоторые общие причины для тестирования базы данных:

Чтобы облегчить сложность вызовов бэкэнд базы данных, разработчики увеличивают использование View и хранимых процедур.
Эти Хранимые процедуры и представления содержат важные задачи, такие как вставка сведений о клиенте (имя, контактная информация и т. д.) И данные о продажах. Эти задачи необходимо тестировать на нескольких уровнях.
Тестирование Black-box, выполняемое на интерфейсе, важно, но затрудняет выделение проблемы. Тестирование в бэкэнд-системе повышает надежность данных. Вот почему тестирование базы данных выполняется на задней системе.
В базе данных данные поступают из нескольких приложений, и существует вероятность того, что в базе данных хранятся вредоносные или неправильные данные. Поэтому необходимо регулярно проверять компоненты базы данных. Кроме того, необходимо регулярно проверять целостность и согласованность данных.

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

Тестирование базы данных отличается от тестирования интерфейсного интерфейса. В следующей таблице приведены основные отличия —

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

Тестирование пользовательского интерфейса или тестирование интерфейса также называют тестированием приложений или графическим интерфейсом.

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

Это включает компоненты базы данных и СУБД, такие как My SQL, Oracle.

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

Эти компоненты создаются с использованием интерфейсных инструментов разработки, таких как VB.net, C #, Delphi и т. д.

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

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

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

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

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

Данные вводятся вручную в приложения. Это включает функциональное тестирование интерфейсных приложений.

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

⠀
Иногда мне задают вопрос «зачем тестировщику знать базы данных?»
⠀
Постараюсь ответить.
Практически любое коммерческое приложение — это может быть интернет-магазин, игры, социальная сеть, почта, мобильное приложение, так или иначе содержит базу данных, чтобы хранить данные, например, о ваших постах, никнеймах, паролях, друзьях, покупках и тд. Чтобы эти данные были доступны у вас в любой точке мира вне зависимости от устройства, с которого вы их просматриваете и нужны базы данных.
Кроме хранения вы можете эти данные использовать, просматривать списки своих друзей, удалять или добавлять в них кого-то, редактировать информацию о себе и многое другое.
Именно такие операции позволяют выполнять БД (базы данных). Данные в них структурируются, индексируются, а также есть возможность обращаться к ним с помощью специального языка запросов.
⠀
Перейдём к тому, зачем тестировщику нужно уметь с ними работать? Для того, чтобы
иметь возможность сравнить реально существующие данные в базе с теми, которые отображаются в приложении, которое мы тестируем. Ведь отображение это дополнительная прослойка, плюс запрос в коде может быть реализован некорректно;
Иметь возможность напрямую загружать свои тестовые данные в БД, чтобы проверить какие-то сценарии. Например, если создание данных ещё не реализовано или для ускорения тестирования (быстрее добавить напрямую, чем через возможности приложения);
Иметь возможность данные удалять и редактировать напрямую в БД.
⠀
Как при ручном тестировании, так и при автоматическом могут использоваться прямые запросы в БД. Именно поэтому нужно уметь с ними работать.
В дополнение скажу, что знание особенностей работы различных баз данных позволяет вывести тестирование на совершенно другой профессиональный уровень.
Стоит отметить ещё, что есть разработчики и тестировщики баз данных. А иногда, мы можем тестировать базу данных отдельно от всего приложения, как отдельный компонент системы.
⠀
Кстати, на базовом курсе по тестированию мы учимся работать с БД и SQL запросами.