- Быстрый пример
- Почему нужно тестировать БД
- Отличия от тестирования UI
- Основные типы тестирования БД
- Процесс тестирования БД
- Тестирование триггеров
- Тестирование объектов БД
- Проверка целостности данных
- Маппинг
- Тестирование производительности БД
- Тестирование бекапа
- Тестирование восстановления
- Тестирование безопасности
- Сложности при тестировании баз данных
- Видео по теме
Определение
Проверка валидности данных в базах данных (далее для краткости БД), их целостности, производительности БД, проверка схем, ключей, индексов, таблиц, функций и триггеров.
Абсолютное большинство современных приложений и сайтов зависят от баз данных, поэтому тестирование БД является важным, необходимым этапом.
Чаще всего (особенно при экспресс-проверках) проводится путем создания и выполнения какого-то количества ключевых проверочных запросов: также проводится нагрузочное и стресс-тестирование БД.
Быстрый пример
Например, есть приложение, собирающее данные о пользователях и их действиях (транзакциях), и передающее эти данные в БД. Протестировать такое приложение нужно следующим образом (проверяя следующее):
- Данные о транзакциях должны корректно сохраняться в БД и корректно возвращаться приложению
- Корректные данные не должны теряться «в процессе»
- Сохраняются только завершенные (то есть корректные) транзакции; а некорректные, то есть незавершенные, прерываются приложением
- Доступ к БД должен даваться только после авторизации; неавторизованный доступ к данным пользователей должен быть запрещен
Необходимость тестирования БД
Существует объективная необходимость такого тестирования, в первую очередь проверки целостности данных, их достоверности, поскольку в бэкенде хранятся пользовательские данные, и данные необходимые для работы приложения.
- Для упрощения работы с бэкендом пользуются процедурами Просмотра и Хранимыми процедурами
- Эти процедуры касаются критически важных повседневных задач; в частности, вставка в БД пользовательских данных (имя, контакты), или финансовых данных (о продажах и ценах). Такие процедуры должны тестироваться неоднократно и на многих уровнях.
- Тестирование без знания кода (черный ящик) не всегда позволяет найти и изолировать источник проблемы на фронтенде; поэтому необходимо тестирование БД на бэкенде
- В БД могут загружаться данные из нескольких источников, в том числе не очень надежных, и всегда есть вероятность попадания в БД некорректных или вредоносных данных. Поэтому нужна регулярная проверка целостности и согласованности БД
Отличия между тестированием БД и тестированием интерфейса
| Тестирование БД | Тестирование интерфейса |
|---|---|
| Валидация данных и проверка их целостности. Подразумевает тестирование компонентов, недоступных пользователям, в том числе систем управления БД типа 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, а также уверенное владение инструментами управления БД.
