Тестирование бд. Тестирование базы данных. Тестирование защиты и управления доступом

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

Пример запроса: Вывести список книг, взятых конкретным учеником. ФИО задать как параметр.

Пример запроса: Вывести список книг конкретного автора с указанием мест хранения в библиотеке. ФИО автора задать как параметр.

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

Рис. 15. Запрос 3. «Найти ученика по №читательского билета и определить в каком классе он учится»

Пример запроса: Определить по ФИО_Ученика в каком классе учится задолжник и кто его классный руководитель.

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

Рис. 17. Кнопочная форма базы данных

ЗАКЛЮЧЕНИЕ

Выпускная квалификационная работа выполнена на актуальную тему «Разработка информационной системы для сельской школьной библиотеки».

Цель дипломного проектирования разработать информационную систему для школьной библиотеки Саратовской области Федоровского района МОУ СОШ п. Солнечный достигнута.

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

Рассмотреть библиотеку как элемент образовательной среды;

Изучить правительственную концепцию поддержки и развития детского чтения;

Проанализированы технологии работы библиотек общеобразовательных учреждений;

Описана предметная область на основе проведенного обследования;

-разработано техническое задание на разработку информационной системы для библиотеки сельской школы;

-построена функциональная модель деятельности школьной библиотеки;

- описание входные и выходные потоки информации;

разработана информационная система на основе СУБД Acc е ss ;

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

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

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

Выбор СУБД как среды разработки определялся техническими возможностями сельской библиотеки. В результате на основе СУБД Access построено ядро информационной системы – база данных.

Для удобства работы пользователей разработан кнопочный интерфейс.

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

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

Многие примеры модульного тестирования начального и среднего уровня на любом языке программирования предполагают, что с помощью простых тестов можно легко протестировать логику приложения. Для приложений, ориентированных на базы данных, это далеко от реальности. При начале использования, например, WordPress, TYPO3 или Symfony с Doctrine или Propel, вы легко столкнётесь с серьёзными проблемами с PHPUnit: просто потому, что база данных тесно связана с этими библиотеками.

Убедитесь, что у вас PHP-расширение pdo и расширения для баз данных, например pdo_mysql , установлены. В противном приведённые ниже примеры не будут работать.

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

  1. Метод, который вы хотите протестировать довольно большую операцию JOIN и затем использует полученные данные для вычисления некоторых важных результатов.
  2. В вашей бизнес-логике выполняются целый рад операторов SELECT, INSERT, UPDATE и DELETE.
  3. Вам необходимо настроить тестовые данные (возможно, значительное количество) в более двух таблиц для получения подходящих первоначальных данных для тестируемых методов.

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

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

В настоящее время DbUnit поддерживает MySQL, PostgreSQL, Oracle и SQLite. За счёт интеграции в Zend Framework или Doctrine 2 это расширение имеет доступ к другим системам управления баз данных (СУБД), таким как IBM DB2 или Microsoft SQL Server.

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

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

  • Схема и таблицы базы данных
  • Вставка строк, необходимых для теста, в эти таблицы
  • Проверка состояния базы данных после того, как тест был пройден
  • Очистка базы данных для каждого нового теста

Поскольку многие API баз данных, такие как PDO, MySQLi или OCI8, громоздкие в использовании и многословные при написании, выполнение этих шагов вручную может стать настоящим кошмаром.

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

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

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

DbUnit помогает упростить все эти проблемы при тестировании с базой данных элегантным способом.

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

Например, набор тестов проекта Doctrine 2 в настоящее время содержит около 1000 тестов, где почти половина из которых использует базу данных и при этом всём выполнение тестов укладывается в 15 секунд, используя базу данных MySQL на стандартом настольном компьютере.

Четыре этапа теста базы данных

В своей книге «Шаблоны тестирования xUnit» (xUnit Test Patterns) Джерард Месарош (Gerard Meszaros) перечисляет четыре этапа (стадии) модульного тестирования:

    Настройка фикстуры

    Выполнение системы тестирования (System Under Test)

    Проверка результата

    Очистка (teardown)

    Что такое фикстура?

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

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

1. Очистка базы данных

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

2. Настройка фикстуры

Затем PHPUnit выполнит итерацию по всем указанным строкам фикстуры и вставит их в соответствующие таблицы.

3–5. Запуск теста, проверка результата и очистка

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

В вашем тесте используйте специальное утверждение assertDataSetsEqual() для целей проверки, однако, это совершенно необязательно. Эта возможность будет объяснена в разделе «Утверждения базы данных».

Конфигурация PHPUnit Database TestCase

Обычно при использовании PHPUnit ваши тесты наследуются от PHPUnit\Framework\TestCase следующим образом:

assertSame(2, 1 + 1); } }

Если вы хотите протестировать код, который использует базу данных, установка такого теста будет немного посложнее, потому что вам нужно отнаследоваться от другого абстрактного класса TestCase, требующего реализацию двух абстрактных методов getConnection() и getDataSet() :

createDefaultDBConnection($pdo, ":memory:"); } /** * @return PHPUnit\DbUnit\DataSet\IDataSet */ public function getDataSet() { return $this->createFlatXMLDataSet(dirname(__FILE__)."/_files/guestbook-seed.xml"); } }

Реализация getConnection()

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

В предыдущем примере мы создаём подключение SQLite в памяти и передаём его в метод createDefaultDBConnection , который оборачивает экземпляр PDO и второй параметр (имя базы данных) в очень простой уровень абстракции с базой данных типа PHPUnit\DbUnit\Database\Connection .

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

Реализация getDataSet()

Метод getDataSet() определяет, каким должно быть первоначальное состояние базы данных перед выполнением каждого теста. Состояние базы данных абстрагируется с помощью двух концепций - DataSet и DataTable, которые представлены интерфейсами PHPUnit\DbUnit\DataSet\IDataSet и PHPUnit\DbUnit\DataSet\IDataTable соответственно. В следующем разделе будет подробно описано, как эти концепции работают и в чём их преимущества при использовании их в тестировании базы данных.

Для реализации нам нужно только знать, что метод getDataSet() вызывается только один раз во время setUp() для извлечения набора данных фикстуры и вставки его в базу данных. В этом примере мы используем фабричный метод createFlatXMLDataSet($filename) , который представляет собой набор данных на основе XML-представления.

Как насчёт схемы базы данных (Database Schema, DDL)?

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

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

  1. Если вы используете базу данных с постоянным соединением (не SQLite в оперативной памяти), вы можете легко настроить базу данных один раз с помощью таких инструментов, как phpMyAdmin для MySQL, и повторно использовать базу данных при каждом запуске теста.
  2. Если вы используете такие библиотеки как Doctrine 2 или Propel , вы можете использовать их API для создания схемы базы данных, который понадобиться всего один раз до запуска тестов. Вы можете использовать возможности первоначальной (bootstrap) загрузки PHPUnit и конфигурации для выполнения этого кода каждый раз при выполнении тестов.

PHPUnit Database TestCase

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

conn === null) { if (self::$pdo === null) { self::$pdo = new PDO("sqlite::memory:"); } $this->conn = $this->createDefaultDBConnection(self::$pdo, ":memory:"); } return $this->conn; } }

Однако это соединение с базой данных жёстко закодировано в соединении PDO. PHPUnit имеет одну удивительную возможность, которая поможет сделать этот тестовый класс ещё более универсальным. Если вы используете XML-конфигурацию, вы можете сделать подключение к базе данных настраиваемым для каждого запуска теста. Сначала давайте создадим файл «phpunit.xml» в тестовом каталоге tests/ приложения со следующим содержимым:

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

conn === null) { if (self::$pdo === null) { self::$pdo = new PDO($GLOBALS["DB_DSN"], $GLOBALS["DB_USER"], $GLOBALS["DB_PASSWD"]); } $this->conn = $this->createDefaultDBConnection(self::$pdo, $GLOBALS["DB_DBNAME"]); } return $this->conn; } }

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

$ user@desktop> phpunit --configuration developer-a.xml MyTests/ $ user@desktop> phpunit --configuration developer-b.xml MyTests/

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

Понимание DataSets и DataTables

Ключевой концепцией расширения базы данных PHPUnit являются DataSets и DataTables. Вы должны попытаться понять эту простую концепцию для освоения тестирования с использованием базы данных с помощью PHPUnit. DataSet и DataTable - это уровни абстракции вокруг строк и столбцов баз данных. Простой API скрывает основное содержимое базы данных в структуре объекта, который также может быть реализован другими источниками, отличными от базы данных.

Эта абстракция необходима для сравнения текущего содержимого базы данных с ожидаемым. Ожидаемое содержимое может быть представлено в виде файлов формата XML, YAML, CSV или массива PHP, например. Интерфейсы DataSet и DataTable позволяют сравнивать эти концептуально разные источники путём эмуляции хранилища реляционных баз данных в семантически подобном подходе.

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

  • Указать одну или более таблиц в базе данных по имени таблицы (фактический набор данных)
  • Указать ожидаемый набор данных в предпочтительном формате (YAML, XML, ..)
  • Проверить утверждение, что оба представления набора данных равны друг другу (эквивалентны).

Утверждения это не единственный вариант использования для DataSet и DataTable в расширении базы данных PHPUnit. Как показано в предыдущем разделе, они также описывают первоначальное содержимое базы данных. Вы вынуждены определять набор данных фикстуры в Database TestCase, который затем используется для:

  • Удаления всех строк из таблиц, указанных в наборе данных.
  • Записи всех строк в таблицы данных в базе данных.

Доступные реализации

Существует три различных типов наборов данных/таблиц данных:

  • DataSets и DataTables на основе файлов
  • DataSet и DataTable на основе запросов
  • Фильтр и объединение DataSets и DataTables

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

Flat XML DataSet

Наиболее распространённый набор называется Flat XML. Это очень простой (flat) XML-формат, где тег внутри корневого узла представляет ровно одну строку в базе данных. Имена тегов соответствуют таблице, куда будут добавляться строки (записи), а атрибуты тега представляют столбцы записи. Пример для приложения простой гостевой книги мог бы выглядеть подобным образом:

Это, очевидно, легко писать. В этом примере - имя таблицы, в которую добавляются две строки с четырьмя столбцами «id», «content», «user» и «created» с соответствующими им значениями.

Однако за эту простоту приходиться платить.

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

Обработка значений NULL в простых наборах данных XML утомительна. Значение NULL отличается от пустого строкового значения почти в любой базе данных (Oracle - исключение), что трудно описать в обычном формате XML. Вы можете представить значение NULL, опуская атрибут из строки (записи). Если наша гостевая книга разрешает анонимные записи, представленные значением NULL в столбце «user», гипотетическое состояние таблицы гостевой книги может быть таким:

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

Обычный набор данных XML делает сейчас решающе важное предположение, объявляя, что атрибуты в первой определённой строке таблицы определяют столбцы этой таблицы. В предыдущем примере это означало бы, что «id», «content“, «user» и «created» будет столбцами таблицы гостевой книги. Для второй строки, где пользователь («user») не определён, в базу данных в столбец «user» будет вставлено значение NULL.

Когда первая запись гостевой книги удаляется из набора данных, только «id», «content» и «created» будут столбцами таблицы гостевой книги, поскольку столбец «user» не определён.

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

В свою очередь, если вы укажете только подмножество столбцов таблицы в наборе данных Flat XML, все пропущенные значения будут установлены в значения по умолчанию. Это приведёт к ошибкам, только если один из пропущенных столбцов определён как «NOT NULL DEFAULT NULL».

В заключение я могу только посоветовать использовать наборы данных Flat XML, только если вам не нужны значения NULL.

Вы можете создать экземпляр обычного набора данных XML внутри Database TestCase, вызвав метод createFlatXmlDataSet($filename) :

createFlatXmlDataSet("myFlatXmlFixture.xml"); } }

XML DataSet

Есть ещё один структурированный набор данных XML, который немного более многословный при записи, но не имеет проблем с NULL-значениями из набора данных Flat XML. Внутри корневого узла вы можете указать теги

, , , и . Эквивалентный набор данных для ранее определённой гостевой книги с использованием Flat XML, будет выглядеть так:

idcontentusercreated 1 Привет, дружище! joe 2010-04-24 17:15:23 2 Мне нравится это! 2010-04-26 12:14:20

Любой определённый тег

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

Вы можете создать экземпляр набора данных XML внутри Database TestCase, вызвав метод createXmlDataSet($filename) :

createXMLDataSet("myXmlFixture.xml"); } }

MySQL XML DataSet

Этот новый XML-формат специально предназначен для сервера баз данных MySQL . Его поддержка была добавлена в PHPUnit 3.5. Файлы в этом формате могут быть сгенерированы с помощью утилиты mysqldump . В отличие от наборов данных CSV, которые mysqldump также поддерживает, один файл в этом XML-формате может содержать данные для нескольких таблиц. Вы можете создать файл в этом формате, запустив mysqldump следующим образом:

$ mysqldump --xml -t -u --password= > /path/to/file.xml

Этот файл можно использовать в вашем Database TestCase, путём вызова метода createMySQLXMLDataSet($filename) :

createMySQLXMLDataSet("/path/to/file.xml"); } }

YAML DataSet

Кроме того, вы можете использовать набор данных YAML для примера гостевой книги:

guestbook: - id: 1 content: "Привет, дружище!" user: "joe" created: 2010-04-24 17:15:23 - id: 2 content: "Мне нравится это!" user: created: 2010-04-26 12:14:20

Этот формат прост и удобен, а главное он решает проблему с NULL в похожем наборе данных Flat XML. NULL в YAML - это просто имя столбца без указанного значения. Пустая строка указывается таким образом - column1: "" .

В настоящее время набор данных YAML не имеет фабричного метода в Database TestCase, поэтому вам необходимо создать его самим:

CSV DataSet

Ещё один файловый набор данных на основе формата CSV. Каждая таблица набора данных представлена одним CSV-файлом. Для нашего примера с гостевой книгой мы определяем файл guestbook-table.csv:

Id,content,user,created 1,"Привет, дружище!","joe","2010-04-24 17:15:23" 2,"Мне нравится это!","nancy","2010-04-26 12:14:20"

Хотя это очень удобно для редактирования через Excel или OpenOffice, вы не можете указать значения NULL в наборе данных CSV. Пустой столбец приведёт к тому, что в столбец в базе данных будет вставлено пустое значение.

Вы можете создать CSV DataSet следующим образом:

addTable("guestbook", dirname(__FILE__)."/_files/guestbook.csv"); return $dataSet; } }

Array DataSet

В расширении базы данных PHPUnit не существует (пока) массива на основе DataSet, но мы может легко реализовать свой собственный. Пример гостевой книги должен выглядеть так:

[ [ "id" => 1, "content" => "Привет, дружище!", "user" => "joe", "created" => "2010-04-24 17:15:23" ], [ "id" => 2, "content" => "Мне нравится это!", "user" => null, "created" => "2010-04-26 12:14:20" ], ], ]); } }

DataSet PHP имеет очевидные преимущества перед всеми другими наборами данных на основе файлов:

  • Массивы PHP, очевидно, могут обрабатывать значения NULL .
  • Вам не нужны дополнительные файлы для утверждений, и вы можете непосредственно использовать их в TestCase.

Чтобы этот набор выглядел как Flat XML, CSV или YAML, ключи первой указанной строки определяют имена столбцов таблицы, в предыдущем случае это были бы «id», «content», «user» и «created».

Реализация массива DataSet проста и понятна:

$rows) { $columns = ; if (isset($rows)) { $columns = array_keys($rows); } $metaData = new DefaultTableMetaData($tableName, $columns); $table = new DefaultTable($metaData); foreach ($rows as $row) { $table->addRow($row); } $this->tables[$tableName] = $table; } } protected function createIterator($reverse = false) { return new DefaultTableIterator($this->tables, $reverse); } public function getTable($tableName) { if (!isset($this->tables[$tableName])) { throw new InvalidArgumentException("$tableName не является таблицей в текущей базе данных."); } return $this->tables[$tableName]; } }

Query (SQL) DataSet

Для утверждений базы данных вам нужен не только набор данный на основе файлов, но также набор данных на основе запросов (Query)/SQL, содержащий фактическое содержимое базы данных. Здесь показан Query DataSet:

getConnection()); $ds->addTable("guestbook");

Добавление таблицы просто по имени - это неявный способ определения таблицы данных со следующим запросом:

getConnection()); $ds->addTable("guestbook", "SELECT * FROM guestbook");

Вы можете использовать его, указав произвольные запросы для своих таблиц, например, ограничивая количество строк, столбцов или добавление предложение ORDER BY :

getConnection()); $ds->addTable("guestbook", "SELECT id, content FROM guestbook ORDER BY created DESC");

В разделе «Утверждения базы данных» будет приведена подробная информация о том, как использовать Query DataSet.

Database (DB) Dataset

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

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

createDefaultDBConnection($pdo, $database); } public function testGuestbook() { $dataSet = $this->getConnection()->createDataSet(); // ... } public function testFilteredGuestbook() { $tableNames = ["guestbook"]; $dataSet = $this->getConnection()->createDataSet($tableNames); // ... } }

Замена DataSet

Я говорил о проблемах с NULL в наборах данных Flat XML и CSV, но есть несколько сложное обходное решение для получения обоих наборов данных, работающих с NULL.

Замена DataSet - декоратор для существующего набора данных, позволяющий заменять значения в любом столбце набора данных другим заменяющим значением. Для получения примера нашей гостевой книги, работающим со значениями NULL, мы указываем файл следующим образом:

Затем мы оборачиваем Flat XML DataSet в Replacement DataSet:

createFlatXmlDataSet("myFlatXmlFixture.xml"); $rds = new PHPUnit\DbUnit\DataSet\ReplacementDataSet($ds); $rds->addFullReplacement("##NULL##", null); return $rds; } }

DataSet Filter

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

getConnection()->createDataSet(); $filterDataSet = new PHPUnit\DbUnit\DataSet\DataSetFilter($dataSet); $filterDataSet->addIncludeTables(["guestbook"]); $filterDataSet->setIncludeColumnsForTable("guestbook", ["id", "content"]); // .. } public function testExcludeFilteredGuestbook() { $tableNames = ["guestbook"]; $dataSet = $this->getConnection()->createDataSet(); $filterDataSet = new PHPUnit\DbUnit\DataSet\DataSetFilter($dataSet); $filterDataSet->addExcludeTables(["foo", "bar", "baz"]); // only keep the guestbook table! $filterDataSet->setExcludeColumnsForTable("guestbook", ["user", "created"]); // .. } }

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

Составной DataSet

Составной DataSet очень полезен для объединения (агрегирования) нескольких уже существующих наборов данных в один набор данных. Когда несколько наборов данных содержат одну и ту же таблицу, строки добавляются в указанном порядке. Например, если у нас есть два набора данных - fixture1.xml :

и fixture2.xml :

Используя составной DataSet, мы можем объединить оба файла фикстуры:

createFlatXmlDataSet("fixture1.xml"); $ds2 = $this->createFlatXmlDataSet("fixture2.xml"); $compositeDs = new PHPUnit\DbUnit\DataSet\CompositeDataSet(); $compositeDs->addDataSet($ds1); $compositeDs->addDataSet($ds2); return $compositeDs; } }

Остерегайтесь внешних ключей

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

Реализация собственного DataSets/DataTables

Для понимания внутренностей DataSets и DataTables, давайте взглянем на интерфейс DataSet. Вы можете пропустить эту часть, если не планируете реализовать собственный DataSet или DataTable.

Общедоступный интерфейс используется внутри утверждения assertDataSetsEqual() в Database TestCase для проверки качества набора данных. Из интерфейса IteratorAggregate IDataSet наследует метод getIterator() для итерации по всем таблицах набора данных. Обратный итератор позволяет PHPUnit очистить строки таблицы, противоположные порядку их создания для удовлетворения ограничений внешнего ключа.

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

Таблица также представлена следующим интерфейсом:

За исключением метода getTableMetaData() , который говорит сам за себя. Используемые методы необходимы для различных утверждений расширения базы данных, которые поясняются в следующей главе. Метод getTableMetaData() должен возвращать реализацию интерфейса PHPUnit\DbUnit\DataSet\ITableMetaData , который описывает структуру таблицы. В нём содержится следующая информация:

  • Имя таблицы
  • Массив имён столбцов таблицы, упорядоченных по их появлению в результирующем наборе.
  • Массив столбцов первичных ключей.

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

Использование API подключения к базе данных

В интерфейсе Connection есть три интересных метода, которые необходимо вернуть из метода getConnection() в Database TestCase:

  1. Метод createDataSet() создаёт набор данных базы данных (Database (DB) DataSet), как описано в разделе реализации DataSet.
getConnection()->createDataSet(); } }

2. Метод createQueryTable() может использоваться для создания экземпляров QueryTable, передавая им имя результат и SQL-запроса. Это удобный метод, когда дело доходит до утверждений результата/таблицы, как будет показано в следующем разделе «API утверждений базы данных».

getConnection()->createQueryTable("guestbook", "SELECT * FROM guestbook"); } }

3. Метод getRowCount() - это удобный способ получения доступа к количеству строк в таблице, необязательно отфильтрованное дополнительным предложением where. Это можно использовать с простым утверждением равенства:

assertSame(2, $this->getConnection()->getRowCount("guestbook")); } }

API утверждений базы данных

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

Утверждение количество строк таблицы

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

assertSame(2, $this->getConnection()->getRowCount("guestbook"), "Pre-Condition"); $guestbook = new Guestbook(); $guestbook->addEntry("suzy", "Hello world!"); $this->assertSame(3, $this->getConnection()->getRowCount("guestbook"), "Inserting failed"); } }

Утверждение состояния таблицы

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

Для этого нам нужно определить экземпляр таблицы запроса (Query Table), который выводит содержимое по имени таблицы и SQL-запроса и сравнивает его с набором данных на основе файлов/массивов:

addEntry("suzy", "Hello world!"); $queryTable = $this->getConnection()->createQueryTable("guestbook", "SELECT * FROM guestbook"); $expectedTable = $this->createFlatXmlDataSet("expectedBook.xml") ->getTable("guestbook"); $this->

Теперь для этого утверждения мы должны создать обычный XML-файл expectedBook.xml :

Это утверждение будет успешным только в том случае, если оно будет запущено точно в 2010–05–01 21:47:08 . Даты представляют собой особую проблему при тестировании с использованием базы данных, и мы может обойти эту ошибку, опуская столбец «created» в утверждении.

Скорректированный файл Flat XML expectedBook.xml , вероятно, теперь должен выглядеть следующим образом для прохождения утверждения:

Мы должны исправить вызов таблицы запроса (Query Table):

getConnection()->createQueryTable("guestbook", "SELECT id, content, user FROM guestbook");

Утверждение результата запроса

Вы также можете утверждать результат сложных запросов с помощью подхода Query Table, просто указав имя результата с запросом и сравнивая его с набором данным:

getConnection()->createQueryTable("myComplexQuery", "SELECT complexQuery..."); $expectedTable = $this->createFlatXmlDataSet("complexQueryAssertion.xml") ->getTable("myComplexQuery"); $this->assertTablesEqual($expectedTable, $queryTable); } }

Утверждение состояния нескольких таблиц

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

  1. Вы можете использовать базу данных (Database, DB) DataSet из Connection и сравнить её с набором данных на основе файлов.

getConnection()->createDataSet(["guestbook"]); $expectedDataSet = $this->createFlatXmlDataSet("guestbook.xml"); $this->assertDataSetsEqual($expectedDataSet, $dataSet); } }

2. Вы можете создать DataSet самостоятельно:

    addTable("guestbook", "SELECT id, content, user FROM guestbook"); // additional tables $expectedDataSet = $this->createFlatXmlDataSet("guestbook.xml"); $this->assertDataSetsEqual($expectedDataSet, $dataSet); } }

Часто задаваемые вопросы

Будет ли PHPUnit (повторно) создавать схему базу данных для каждого теста?

Нет, PHPUnit требует, чтобы все объекты базы данных были доступны при запуске набора. Перед запуском набора тестов необходимо создать базу данных, таблицы, последовательности, триггеры и представления.

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

Производительность БД является решающим фактором эффективности управленческих и коммерческих приложений. Если поиск или запись данных выполняется медленно – способность к нормальной работе приложения падает. Существует единственный путь выяснить причину плохой производительности – выполнить количественные измерения и определить, что является причиной проблемы производительности.
Проблемы выявления узких мест производительности баз данных напрямую связаны с метриками, методами измерений производительности и технологией их выполнения. Для крупных корпораций и БД больших объемов проблема определения производительности баз данных имеет еще один очень важный аспект: определения ИТ инфраструктуры для длительной промышленной эксплуатации приложений. Это в итоге приводит к более точному определению первоначальных инвестиций в оборудование и базовое ПО. Так как высокая производительность БД сильно зависит от платформы и оборудования, а они закупаются и эксплуатируются на долгосрочную перспективу.
Наиболее важными метриками измерения производительности БД являются:

  • число транзакций за период времени (различного типа транзакции);
  • число операций в/в (прочитанных строк) на транзакцию и время ее выполнения;
  • число прочитанных строк для каждой таблицы на транзакцию;
  • среднее число операций в/в на транзакцию по диапазонам;
  • операторы SQL высокой рабочей стоимостью времени использования CPU (пользователя, системного)
  • время начала и конца выполнения оператора
  • время выполнения операций сортировки (числа сортировок, числа переполнений сортировок, времени выполнения сортировок), наивысшего использования времени elapsed и наименьшей эффективности использования индексов.

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

Что еще проверять при тестировании БД?

Data mapping

Убедитесь, что связи в БД соответствуют проектной документацией. Для всех операций CRUD проверьте, что соответствующие таблицы и записи обновляются, когда пользователь нажимает «Сохранить», «Обновить», «Поиск» или «Удалить» из графического интерфейса приложения.

ACID свойства транзакций

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

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

Учтите, что разные модули приложения (например, экраны и формы) по-разному используют те же данные и выполняют CRUD операции. Поэтому нужно убедиться, что последнее состояние данных отражается везде одинаково. Система должна показывать обновленные значения на всех формах и экранах. Это называется целостностью данных.

Точность реализации бизнес логики

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

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

Написание SQL запросов

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

Просмотр данных в таблицах

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

Помощь разработчика

Тестировщик выполняет любые операции CRUD с графическим интерфейсом и проверяет их результаты путем выполнения соответствующих SQL-запросов, написанных разработчиком. Данный способ не требует ни хороших знаний SQL, ни хорошего знания структуры БД приложения.Метод кажется простым и хорошим выбором для тестирования БД. Но его недостатком является хаос. Что делать, если запрос, написанный разработчиком семантически неверный или не выполняет требования пользователя правильно? В этом случае тестирование не дает никаких гарантий о качестве продукта.

Пример методики тестирования целостности данных БД

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

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

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

Оракулы (эвристический механизм, который помогает определить проблему) Наметьте одну или несколько стратегий, которые можно использовать в методике для правильного наблюдения результатов теста. Оракул сочетает элементы и метода, посредством которого можно выполнить наблюдение, и характеристики определенного результата, которые указывают на возможный успех или неудачу. В идеале, оракулы будут выполнять самопроверку, допуская начальную оценку успеха или неудачи автоматизированными тестами. Однако следует учитывать риски, связанные с автоматическим определением результатов.
Необходимые инструменты Для данной методики требуются следующие инструменты:
  • Инструмент автоматизации сценариев тестирования
  • Инструмент создания образов и восстановления базовой конфигурации
  • Инструменты резервного копирования и восстановления
  • Инструменты мониторинга установки (реестр, жесткий диск, CPU, память и так далее)
  • Утилиты и инструменты SQL базы данных
  • Инструменты генерации данных
Критерии успешности Эта методика поддерживает тестирование всех основных методов и процессов доступа к базе данных.
Специальная информация Для тестирования может потребоваться среда разработки DBMS или драйверы для ввода или изменения данных непосредственно в базе данных.

Процессы следует вызывать вручную.

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

Несколько лет назад оказалось, что SQL внезапно устарел. И начали появляться и множиться NoSQL-решения, отбросившие язык SQL и реляционную модель хранения данных. Основные аргументы в поддержку такого подхода: возможность работы с большими данными (те самые Big Data), хранения данных в самых экзотичных структурах и, самое главное, возможность все это делать очень быстро. Давай посмотрим, насколько это получается у самых популярных представителей мира NoSQL.

За счет чего достигается скорость в NoSQL? В первую очередь, это следствие совсем другой парадигмы хранения данных. Парсинг и трансляция SQL-запросов, работа оптимизатора, объединение таблиц и прочее сильно увеличивают время ответа. Если взять и выкинуть все эти слои, упростить запросы, читать с диска прямо в сеть или хранить все данные в оперативной памяти, то можно выиграть в скорости. Уменьшается как время обработки каждого запроса, так и количество запросов в секунду. Так появились key-value БД, самым типичным и широко известным представителем которых является memcached. Да, этот кеш, широко применяемый в веб-приложениях для ускорения доступа к данным, тоже является NoSQL.

Типы NoSQL

Можно выделить четыре основные категории NoSQL-систем:

  • Ключ - значение (key-value). Большая хеш-таблица, где допустимы только операции записи и чтения данных по ключу.
  • Колоночные (column). Таблицы, со строками и колонками. Вот только в отличие от SQL количество колонок от строки к строке может быть переменным, а общее число колонок может измеряться миллиардами. Также каждая строка имеет уникальный ключ. Можно рассматривать такую структуру данных как хеш-таблицу хеш-таблицы, первым ключом является ключ строки, вторым - имя колонки. При поддержке вторичных индексов возможны выборки по значению в колонке, а не только по ключу строки.
  • Документо-ориентированные (document-oriented). Коллекции структурированных документов. Возможна выборка по различным полям документа, а также модификация частей документа. К этой же категории можно отнести поисковые движки, которые являются индексами, но, как правило, не хранят сами документы.
  • Графовые (graph). Специально предназначены для хранения математических графов: узлов и связей между ними. Как правило, позволяют задавать для узлов и связей еще и набор произвольных атрибутов и выбирать узлы и связи по этим атрибутам. Поддерживают алгоритмы обхода графов и построения маршрутов.

Для теста мы взяли представителей первых трех категорий:

Как проводился тест

В распоряжении у нас было четыре серверных машинки. В каждой: восьмиядерный Xeon, 32 Гб ОЗУ, четыре интеловских SSD по 120 Гб каждый.

Тестировали мы с помощью YCSB (Yahoo! Cloud Serving Benchmark). Это специальный бенчмарк, выпущенный командой Yahoo! Research в 2010 году под лицензией Apache. Бенчмарк специально создан для тестирования NoSQL баз данных. И сейчас он остается единственным и довольно популярным бенчмарком для NoSQL, фактически стандартом. Написан, кстати, на Java. Мы добавили к оригинальному YCSB драйвер для Aerospike, слегка обновили драйвер для MongoDB, а также несколько подшаманили с выводом результатов.

INFO

Кроме YCSB, тестировать производительность NoSQL БД можно с помощью, например, JMeter.

Для создания нагрузки на наш маленький кластер потребовалось восемь клиентских машин. По четырехъядерному i5 и 4 Гб ОЗУ на каждой. Одного (и двух, и трех, и четырех...) клиентов оказалось недостаточно, чтобы загрузить кластер. Может показаться странным, но факт.

Все это шевелилось в одной гигабитной локальной сети. Пожалуй, было бы интереснее в десятигигабитной сети, но такого железа у нас не было. Интереснее, потому что, когда количество операций в секунду начинает измеряться сотнями тысяч, мы утыкаемся в сеть. При пропускной способности в гигабит в секунду (10^9 бит/c) сеть может пропустить килобайтных пакетов (~10^4 бит) лишь около 100 000 (10^5) штук. То есть получаем лишь 100k операций в секунду. А нам вообще-то хотелось получить миллион:).

Сетевые карты тоже имеют значение. Правильные серверные сетевухи имеют несколько каналов ввода-вывода, соответственно, каждый с собственным прерыванием. Вот только по умолчанию в линуксе все эти прерывания назначены на одно ядро процессора. Только ребята из Aerospike озаботились этой тонкостью, и их скрипты настройки БД раскидывают прерывания сетевых карт по ядрам процессора. Посмотреть прерывания сетевых карт и то, как они распределены по ядрам процессора, можно, например, такой командой: «cat /proc/interrupts | grep eth».

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

Настраиваем SSD

В частности, SSD требуют действий, называемых непереводимым словом overprovisioning. Дело в том, что в SSD присутствует слой трансляции адресов. Адреса блоков, видные операционной системе, совсем не соответствуют физическим блокам во флеш-памяти. Как ты знаешь, число циклов перезаписи у флеш-памяти ограничено. К тому же операция записи состоит из двух этапов: стирания (часто - сразу нескольких блоков) и собственно записи. Поэтому, для обеспечения долговечности накопителя (равномерного износа) и хорошей скорости записи, контроллер диска чередует физические блоки памяти при записи. Когда операционная система пишет блок по какому-то адресу, физически запись происходит на некий чистый свободный блок памяти, а старый блок помечается как доступный для последующего (фонового) стирания. Для всех этих манипуляций контроллеру диска нужны свободные блоки, чем больше, тем лучше. Заполненный на 100% SSD может работать весьма медленно.

Свободные блоки могут получиться несколькими способами. Можно с помощью команды hdparm (с ключом "-N") указать количество секторов диска, видимых операционной системой. Остальное будет в полном распоряжении контроллера. Однако это работает не на всяком железе (в AWS EC2, например, не работает). Другой способ - оставить не занятое разделами место на диске (имеются в виду разделы, создаваемые, например, fdisk). Контроллер достаточно умен, чтобы задействовать это место. Третий способ - использовать файловые системы и версии ядра, которые умеют сообщать контроллеру о свободных блоках. Это та самая команда TRIM. На нашем железе хватило hdparm, мы отдали на растерзание контроллеру 20% от общего объема дисков.

Для SSD важен также планировщик ввода-вывода. Это такая подсистема ядра, которая группирует и переупорядочивает операции ввода-вывода (в основном записи на диск) с целью повысить эффективность. По умолчанию линукс использует CFQ (Completely Fair Queuing), который старается переставить операции записи так, чтобы записать как можно больше блоков последовательно. Это хорошо для обычных вращающихся (так и говорят - spinning:)) дисков, потому что для них скорость линейного доступа заметно выше доступа к случайным блокам (головки нужно перемещать). Но для SSD линейная и случайная запись - одинаково эффективны (теоретически), и работа CFQ только вносит лишние задержки. Поэтому для SSD-дисков нужно включать другие планировщики, например NOOP, который просто выполняет команды ввода-вывода в том порядке, в каком они поступили. Переключить планировщик можно, например, такой командой: «echo noop > /sys/block/sda/queue/scheduler», где sda - твой диск. Справедливости ради стоит упомянуть, что свежие ядра сами умеют определять SSD-накопители и включать для них правильный планировщик.

Любая СУБД любит интенсивно писать на диск, а также интенсивно читать. А Linux очень любит делать read-ahead, упреждающее чтение данных, - в надежде, что, раз ты прочитал этот блок, ты захочешь прочитать и несколько следующих. Однако с СУБД, и особенно при случайном чтении (а этот как раз наш вариант), этим надеждам не суждено сбыться. В результате имеем никому не нужное чтение и использование памяти. Разработчики MongoDB рекомендуют по возможности уменьшить значение read-ahead. Сделать это можно командой «blockdev --setra 8 /dev/sda», где sda - твой диск.

Любая СУБД любит открывать много-много файлов. Поэтому необходимо заметно увеличить лимиты nofile (количество доступных файловых дескрипторов для пользователя) в файле /etc/security/limits.conf на значение сильно больше 4k.

Также возник интересный вопрос: как использовать четыре SSD? Если Aerospike просто подключает их как хранилища и как-то самостоятельно чередует доступ к дискам, то другие БД подразумевают, что у них есть лишь один каталог с данными. (В некоторых случаях можно указать и несколько каталогов, но это не предполагает чередования данных между ними.) Пришлось создавать RAID 0 (с чередованием) с помощью утилиты mdadm. Я полагаю, что можно было бы поиграть с LVM, но производители СУБД описывают только использование mdadm.

Естественно, на всех машинах кластера (как серверных, так и клиентских) часы должны быть синхронизированы с помощью ntpd. Ntpdate тут не годится, потому что требуется бóльшая точность синхронизации. Для всех распределенных систем жизненно важно, чтобы время между узлами было синхронизировано. Например, Cassandra и Aerospike хранят время изменения записи. И если на разных узлах кластера найдутся записи с разным таймстампом, то победит та запись, которая новее.

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

Проще всего настраивается Couchbase. У него есть веб-консоль. Достаточно запустить сервис на всех узлах кластера. Затем на одном из узлов создать bucket («корзину» для ключей-значений) и добавить другие узлы в кластер. Все через веб-интерфейс. Особо хитрых параметров настройки у него нет.

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

Сложнее всего с MongoDB. У других БД все узлы равнозначны. У Mongo это не так. Мы хотели поставить все БД по возможности в одинаковые условия и выставить у всех replication factor в 2. Это означает, что в кластере должно быть две копии данных, для надежности и скорости. В других БД replication factor - это лишь настройка хранилища данных (или «корзины», или «семейства колонок»). В MongoDB количество копий данных определяется структурой кластера. Грамотно настроить кластер MongoDB можно, только дважды прочтя официальную документацию, посвященную этому:). Говоря кратко, нам нужны shards or replica-sets. Шарды (ну ты наверняка слышал термин «шардинг») - это подмножества всего набора данных, а также узлы кластера, где каждое подмножество будет хранится. Реплика-сеты - это термин MongoDB, обозначающий набор узлов кластера, хранящих одинаковые копии данных. В реплика-сете есть главный узел, который выполняет операции записи, и вторичные узлы, на которые осуществляется репликация данных с главного узла. В случае сбоев роль главного узла может быть перенесена на другой узел реплика-сета. Для нашего случая (четыре сервера и желание хранить две копии данных) получается, что нам нужно два шарда, каждый из которых представляет собой реплика-сет из двух серверов с данными. Кроме того, в каждый реплика-сет нужно добавить так называемый арбитр, который не хранит данные, а нужен для участия в выборах нового главного узла. Число узлов в реплика-сете для правильных выборов должно быть нечетным. Еще нужна маленькая конфигурационная БД, в которой будет храниться информация о шардах и о том, какие диапазоны данных на каком шарде хранятся. Технически это тоже MongoDB, только (по сравнению с основными данными) очень маленькая. Арбитры и конфигурационную БД мы разместили на клиентских машинах. И еще на каждом клиенте нужно запустить демон mongos (mongo switch), который будет обращаться к конфигурационной БД и маршрутизировать запросы от каждого клиента между шардами.

У каждой NoSQL БД свой уникальный способ представления данных и допустимых операций над ними. Поэтому YCSB пошел по пути максимального обобщения любых БД (включая и SQL).

Набор данных, которыми оперирует YCSB, - это ключ и значение. Ключ - это строка, в которую входит 64-битный хеш. Таким образом, сам YCSB, зная общее количество записей в БД, обращается к ним по целочисленному индексу, а для БД множество ключей выглядит вполне случайным. Значение - десяток полей случайных бинарных данных. По умолчанию YCSB генерирует записи килобайтного размера, но, как ты помнишь, в гигабитной сети это ограничивает нас лишь в 100k операций в секунду. Поэтому в тестах мы уменьшили размер одной записи до 100 байт.

Операции над этими данными YCSB осуществляет тоже простейшие: вставка новой записи с ключом и случайными данными, чтение записи по ключу, обновление записи по ключу. Никаких объединений таблиц (да и вообще подразумевается лишь одна «таблица»). Никаких выборок по вторичным ключам. Никаких множественных выборок по условию (единственная проверка - совпадение первичного ключа). Это очень примитивно, но зато может быть произведено в любой БД.

Непосредственно перед тестированием БД нужно наполнить данными. Делается это самим YCSB. По сути, это нагрузка, состоящая лишь из операций вставки. Мы экспериментировали с двумя наборами данных. Первый гарантированно помещается в оперативную память узлов кластера, 50 миллионов записей, примерно 5 Гб чистых данных. Второй гарантированно не помещается в ОЗУ, 500 миллионов записей, примерно 50 Гб чистых данных.

Сам тест - выполнение определенного набора операций - производится под нагрузкой разного типа. Важным параметром является соотношение операций - сколько должно быть чтений, а сколько обновлений. Мы использовали два типа: интенсивная запись (Heavy Write, 50% чтений и 50% обновлений) и в основном чтение (Mostly Read, 95% чтений и 5% обновлений). Какую операцию выполнить, каждый раз выбирается случайно, проценты определяют вероятность выбора операции.

YCSB может использовать различные алгоритмы выбора записи (ключа) для выполнения операции. Это может быть равномерное распределение (любой ключ из всего множества данных может быть выбран с одинаковой вероятностью), экспоненциальное распределение (ключи «в начале» набора данных будут выбираться значительно чаще) и некоторые другие. Но типичным распределением команда Yahoo выбрала так называемое zipfian. Это равномерное распределение, в котором, однако, отдельные ключи (небольшой процент от общего количества ключей) выбираются значительно чаще, чем другие. Это симулирует популярные записи, скажем в блогах.

YCSB стартует с несколькими потоками, запуская цикл выполнения операций в каждом из них, и все это на одной машине. Имея лишь четыре ядра на одной клиентской машине, довольно грустно пытаться запускать там более четырех потоков. Поэтому мы запускали YCSB на восьми клиентских машинах одновременно. Для автоматизации запуска мы использовали fabric и cron (точнее, at). Небольшой скрипт на Python формирует необходимые для запуска YCSB команды на каждом клиенте, эти команды помещаются в очередь at на одно и то же время на ближайшую минуту в будущем на каждом клиенте. Потом срабатывает at, и YCSB успешно (или не очень, если ошиблись в параметрах) запускается в одно и то же время на всех восьми клиентах. Чтобы собрать результаты (лог файлы YCSB), снова используется fabric.

Результаты

Итак, исходные результаты - это логи YCSB, с каждого клиента. Выглядят эти логи примерно так (показан финальный кусочек файла):

Operations, 1187363 , Retries, 0 , AverageLatency(us), 3876.5493619053314 , MinLatency(us), 162 , MaxLatency(us), 278190 , 95thPercentileLatency(ms), 12 , 99thPercentileLatency(ms), 22 , Return=0, 1187363 , Reconnections, 0.0 , RunTime(ms), 303574.0 , Operations, 1249984.0 , Throughput(ops/sec), 4117.5594747903315

Как видишь, здесь есть количество операций определенного типа (в данном примере - чтения), средняя, минимальная и максимальная задержки, задержка, в которую уложились 95 и 99% операций, количество успешных операций (код возврата 0), общее время теста, общее количество всех операций и среднее количество операций в секунду. Нас больше всего интересует средняя задержка (AverageLatency) и количество операций в секунду (Throughput).

С помощью очередного скрипта на Python данные из кучи логов собирали в табличку, а по табличке строили красивые графики.





Выводы

NoSQL БД разделились на две группы: быстрые и медленные. Быстрыми, как, собственно, и ожидалось, оказались key-value БД. Aerospike и Couchbase сильно опережают соперников.

Aerospike действительно очень быстрая БД. И нам почти получилось дойти до миллиона операций в секунду (на данных в памяти). Aerospike весьма неплохо работает и на SSD, особенно если учитывать, что Aerospike в этом режиме не использует кеширование данных в памяти, а на каждый запрос обращается к диску. Значит, в Aerospike действительно можно поместить большое количество данных (пока хватит дисков, а не ОЗУ).

Couchbase быстр, но быстр только на операциях в памяти. На графиках с тестами SSD показана скорость работы Couchbase на объеме данных лишь чуть больше объема ОЗУ - всего 200 миллионов записей. Это заметно меньше 500 миллионов, с которыми тестировались другие БД. В Couchbase просто не удалось вставить больше записей, он отказывался вытеснять кеш данных из памяти на диск и прекращал запись (операции записи завершались с ошибками). Это хороший кеш, но лишь для данных, помещающихся в ОЗУ.

Cassandra - единственная БД, которая пишет быстрее, чем читает:). Это оттого, что запись в ней успешно завершается (в самом быстром варианте) сразу после записи в журнал (на диске). А вот чтение требует проверок, нескольких чтений с диска, выбора самой свежей записи. Cassandra - это надежный и довольно быстрый масштабируемый архив данных.

MongoDB довольно медленна на запись, но относительно быстра на чтение. Если данные (а точнее, то, что называют working set - набор актуальных данных, к которым постоянно идет обращение) не помещаются в память, она сильно замедляется (а это именно то, что происходит при тестировании YCSB). Также нужно помнить, что у MongoDB существует глобальная блокировка на чтение/запись, что может доставить проблем при очень высокой нагрузке. В целом же MongoDB - хорошая БД для веба.

PS

Давай немного отвлечемся от вопросов производительности и посмотрим на то, как будут развиваться дальше SQL- и NoSQL-решения. На самом деле то, что мы видим сейчас, - это повторение хорошо знакомой истории. Все это уже было в шестидесятых и семидесятых годах двадцатого века: до реляционных БД существовали иерархические, объектные и прочие, и прочие. Потом захотелось стандартизации, и появился SQL. И все серьезные СУБД, каждая из которых поддерживала свой собственный язык запросов и API, переключились на SQL. Язык запросов и реляционная модель стали стандартом. Любопытно, что сейчас тоже пытаются привить SQL к NoSQL, что приводит к созданию как оберток поверх существующих NoSQL, так и совершенно новых БД, которые называют NewSQL.

Если NoSQL решили отказаться от «тяжелого наследия» SQL, пересмотреть подходы к хранению данных и создали совершенно новые решения, то термином NewSQL называют движение по «возрождению» SQL. Взяв идеи из NoSQL, ребята воссоздали SQL-базы на новом уровне. Например, в мире NewSQL часто встречаются БД с хранением данных в памяти, но с полноценными SQL-запросами, объединениями таблиц и прочими привычными вещами. Чтобы все же хранить много данных, в эти БД встраивают механизмы шардинга.

К NewSQL причисляют VoltDB, TokuDB, MemDB и другие. Запомни эти имена, возможно, скоро о них тоже будут говорить на каждой ИТ-конференции.

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

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

Database Benchmark

Database Benchmark — это.NET инструмент, предназначенный для стресс-тестирования баз данных большими потоками данных. Приложение выполняет два основных тестовых сценария: вставку большого количества случайно сгенерированных записей с последовательными или случайными ключами и чтение вставленных записей, упорядоченных по их ключам. Он обладает широкими возможностями по генерации данных, графическими отчётами и конфигурированием возможных видов отчётов.

Поддерживаемые базы: MySQL, SQL Server, PostgreSQL, MongoDB и многие другие.

Database Rider

Database Rider предназначен, чтобы тестирование базы данных было было не сложнее юнит-тестирования. Данная тула базируется на Arquillian и поэтому в Java проекте нужна лишь зависимость для DBUnit. Также возможно использование аннотаций, как в JUnit , интеграция с CDI через интерсепторы, поддержка JSON, YAML, XML, XLS и CSV, конфигурация через те же аннотации или yml файлы, интеграция с Cucumber , поддержка нескольких баз данных, работа с временными типами в датасетах .

DbFit

DbFit — фреймворк для разработки базы данных через тестирование. Написан он поверх FitNesse , который является зрелым и мощным инструментом с большим сообществом. Тесты пишутся на основе таблиц, что делает их более читабельными, чем обычные юнит — тесты . Запустить их можно с IDE, с помощью командной строки, или средствами CI — инструментов.

Поддерживаемые базы: Oracle, SQL Server, MySQL, DB2, PostgreSQL, HSQLDB и Derby.

dbstress

dbstress — инструмент для перфоманс и стресс-тестирования баз данных, написанный на Scala и Akka. Используя специальный JDBC -драйвер, он выполняет параллельно запросы определённое количество раз (возможно даже и к нескольким хостам) и сохраняет итоговый результат в csv файле.

Поддерживаемые базы: все те же, что и в JDBC .

DbUnit

— это расширение JUnit (также используемое с Ant), которое между тестами может возвращать базу данных в нужное состояние. Данная возможность позволяет избежать зависимости между тестами, если один тест не пройдёт и при этом нарушит базу, то следующий тест начнётся с чистого листа. DbUnit имеет возможность трансфера данных между базой данных и XML документом. Есть и возможность работы с большими датасетам в потоковом режиме. Также можно проверить совпадает ли полученная база данных определённому эталону.

Поддерживаемые базы: все те же, что и в JDBC .

DB Test Driven

DB Test Driven представляет собой инструмент для unit — тестирования базы данных. Данная утилита весьма легковесная, работает с нативным SQL и устанавливается прямо в базу. Легко интегрируется с инструментами непрерывной интеграции, а версия для SQL Server имеет возможность оценить покрытие кода тестами.

Поддерживаемые базы: SQL Server, Oracle.

HammerDB

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

JdbcSlim

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

Поддерживаемые базы: Oracle, SQL Server, PostgreSQL, MySQL и другие.

JDBDT (Java DataBase Delta Testing)

JDBDT — это Java-библиотека для тестирования (на базе SQL) приложений баз данных. Библиотека предназначена для автоматизированной установки и проверки базы данных тестах. JDBDT не имеет зависимостей от сторонних библиотек, что упрощает её интеграцию. По сравнению с существующими библиотеаками для тестирования баз данных, JDBDT концептуально отличается возможностью использования δ-утверждений.

Поддерживаемые базы: PostgreSQL, MySQL, SQLite, Apache Derby, H2 and HSQLDB.

NBi

NBi по сути является аддоном для NUnit и предназначен больше для Business Intelligence сферы. Кроме работы с реляционными базами данных возможна работа с OLAP платформами (Analysis Services, Mondrian и т.д.), ETL и системами отчётов (Microsoft technologies). Основная цель данного фреймворка — создание тестов с помощью декларативного подхода основанного на XML. Вам не надо будет писать тесты на C# и использовать Visual Studio для компиляции тестов. Вам всего лишь надо создать xml-файл и интерпретировать с помощью NBi, дальше тесты можно запускать. Кроме NUnit можно портировать и на другие тестовые фреймворки.

Поддерживаемые базы: SQL Server, MySQL, PostgreSQL, Neo4j, MongoDB, DocumentDB и другие.

NoSQLMap

NoSQLMap написан на Python, чтобы проводить аудит на устойчивость sql — инъекциям и различным эксплойтам в конфигурации базы данных. А также для оценки устойчивости веб — приложения, использующего NoSQL базы, к такому роду атак. Основными целями приложения являются предоставление инструмента для тестирования серверов MongoDB и развеяние мифа, что приложения NoSQL неприступны для SQL-инъекции.

Поддерживаемые базы: MongoDB.

NoSQLUnit

NoSQLUnit — это расширение для JUnit предназначенное для написания тестов в Java — приложениях, которые используют NoSQL базы данных. Цель NoSQLUnit — управлять жизненным циклом NoSQL. Данный инструмент поможет вам поддерживать тестируемые базы данных в известном состоянии и стандартизировать способ написания тестов для приложений использующих NoSQL.

Поддерживаемые базы: MongoDB, Cassandra, HBase, Redis и Neo4j.

ruby-plsql-spec

ruby-plsql-spec фреймворк для юнит — тестирования PL/SQL с помощью Ruby. Он базируется на двух других библиотеках:

  • ruby-plsql – Ruby API для вызова PL/SQL процедур;
  • RSpec – фреймворка для BDD.

Поддерживаемые базы: Oracle

SeLite

SeLite является расширением из семейства Selenium. Основная суть — иметь базу данных, базирующуюся на SQLite , изоллированно от приложения. Вы сможете обнаруживать ошибки web — сервера и шарить скрипты между тестами, работать со снэпшотами и т.д.

Поддерживаемые базы: SQLite, MySQL, PostgreSQL.

sqlmap

sqlmap — инструмент для тестирования на проникновение, с помощью которого можно автоматизировать процесс обнаружения и использования SQL-инъекций и захвата серверов баз данных. Он оснащен мощным механизмом обнаружения и множеством нишевых функций пентестерования.

Поддерживаемые базы: MySQL, Oracle, PostgreSQL, SQL Server, DB2 и другие.

    Опенсорсные инструменты для тестирования баз данных

    https://сайт/wp-content/uploads/2018/01/data-base-testing-150x150.png

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



Оценка статьи:
1 звезда2 звезды3 звезды4 звезды5 звезд (Пока оценок нет)
Загрузка...
Поделиться с друзьями:
Похожие публикации