Несколько лет назад оказалось, что 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 и другие. Запомни эти имена, возможно, скоро о них тоже будут говорить на каждой ИТ-конференции.

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

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

Тестирование функций

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

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

Тестирование цикла бизнес-процесса

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

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

Тестирование пользовательского интерфейса

В тестировании пользовательского интерфейса (UI) проверяется взаимодействие пользователя с программным обеспечением. Цель тестирования UI состоит в том, чтобы убедиться, что UI обеспечивает пользователю соответствующий доступ и навигацию по функциям цели тестирования. Кроме этого, тестирование UI позволяет убедиться, что объекты в UI выполняют ожидаемые функции и соответствуют корпоративным или отраслевым стандартам.

Цели методики:	Протестировать следующее с целью наблюдения и регистрации соблюдения стандартов и целевой алгоритм: Навигацию по цели тестирования, отражающую функции и требования бизнес-процесса, включая методы окно-окно, поле-поле, и применение способов доступа (клавиши табуляции, перемещения мыши, быстрые клавиши). Можно протестировать объекты и характеристики окон - такие как меню, размер, расположение, состояние и фокусировка.
Методика:	Создание или изменение тестов для каждого окна для проверки правильной навигации и состояний объектов для каждого окна и объекта приложения.
Оракулы:	Наметьте одну или несколько стратегий, которые можно использовать в методике для правильного наблюдения результатов теста. Оракул сочетает элементы и метода, посредством которого можно выполнить наблюдение, и характеристики определенного результата, которые указывают на возможный успех или неудачу. В идеале, оракулы будут выполнять самопроверку, допуская начальную оценку успеха или неудачи автоматизированными тестами. Однако следует учитывать риски, связанные с автоматическим определением результатов.
Необходимые инструменты:	Для этой методики требуется инструмент автоматизации сценариев тестирования.
Критерии успешности:	Эта методика поддерживает тестирование каждого главного экрана или окна, которое будет широко использоваться пользователями.
Специальная информация:	Возможен доступ не ко всем свойствам пользовательских объектов и объектов других фирм.

Профилирование производительности

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

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

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

Тестирование нагрузки

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

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

Цели методики:	Выполнение обозначенных транзакций или вариантов бизнес-процесса в различных условиях рабочей нагрузки с целью наблюдения и регистрации целевого алгоритма и данных производительности системы.
Методика:	Применение в качестве основы сценариев тестов транзакций, разработанных для тестирования функций и циклов бизнес-процесса, однако необходимо удалить ненужные итерации и задержки. Изменение файлов данных для увеличения числа транзакций или тестов с целью увеличения числа выполнений каждой транзакции. Рабочие нагрузки должны включать - например, ежедневные, еженедельные и ежемесячные - пиковые нагрузки. Рабочие нагрузки должны представлять как средние, так и пиковые нагрузки. Рабочие нагрузки должны представлять как мгновенные, так и длительные пиковые нагрузки. Рабочие нагрузки следует протестировать в различных конфигурациях тестовой среды.
Оракулы:	Наметьте одну или несколько стратегий, которые можно использовать в методике для правильного наблюдения результатов теста. Оракул сочетает элементы и метода, посредством которого можно выполнить наблюдение, и характеристики определенного результата, которые указывают на возможный успех или неудачу. В идеале, оракулы будут выполнять самопроверку, допуская начальную оценку успеха или неудачи автоматизированными тестами. Однако следует учитывать риски, связанные с автоматическим определением результатов.
Необходимые инструменты:	Для данной методики требуются следующие инструменты: Инструмент автоматизации сценариев тестирования инструменты мониторинга установки (реестр, жесткий диск, CPU, память и так далее) инструменты, ограничивающие ресурсы; например, Canned Heat инструменты генерации данных
Критерии успешности:	Эта методика поддерживает тестирование эмуляции рабочей нагрузки, которая представляет собой успешную эмуляцию рабочей нагрузки без сбоев из-за неполадок реализации теста.
Специальная информация:	Тестирование нагрузки следует выполнять в выделенной системе либо в выделенное время. Это обеспечивает полное управление и точные измерения. Базы данных, применяемые для тестирования нагрузки, должны либо иметь фактический размер, либо их масштаб должен быть изменен одинаково.

Тестирование напряжений

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

Цели методики:	Протестировать функции цели тестирования в следующих условиях напряжения с целью наблюдения и регистрации целевого алгоритма, который определяет и документирует условия, при которых происходит сбой системы, для того чтобы продолжать работу соответствующим образом: небольшой объем памяти или отсутствие свободной памяти на сервере (RAM и объем постоянной памяти) максимально возможное физически или фактически число подключенных или имитируемых пользователей несколько пользователей выполняют одни и те же транзакции с обними и теми же данными или учетными записями "избыточный" объем транзакций или смесь условий (см. выше раздел Профилирование производительности)
Методика:	Для тестирования ограниченных ресурсов тесты следует выполнять в одной системе, а RAM и объем постоянной памяти на сервере должны быть уменьшены или ограничены. Для остальных тестов напряжений следует использовать несколько клиентов, выполняющих одни и те же или дополнительные тесты для создания наихудшего объема транзакций или их смеси.
Оракулы:	Наметьте одну или несколько стратегий, которые можно использовать в методике для правильного наблюдения результатов теста. Оракул сочетает элементы и метода, посредством которого можно выполнить наблюдение, и характеристики определенного результата, которые указывают на возможный успех или неудачу. В идеале, оракулы будут выполнять самопроверку, допуская начальную оценку успеха или неудачи автоматизированными тестами. Однако следует учитывать риски, связанные с автоматическим определением результатов.
Необходимые инструменты:	Для данной методики требуются следующие инструменты: Инструмент автоматизации сценариев тестирования инструмент планирования и управления нагрузкой транзакции инструменты мониторинга установки (реестр, жесткий диск, CPU, память и так далее) инструменты, ограничивающие ресурсы; например, Canned Heat инструменты генерации данных
Критерии успешности:	Эта методика поддерживает тестирование эмуляции напряжений. Систему можно успешно эмулировать при одном или нескольких условиях, определенных как условия напряжений, и можно зафиксировать наблюдения результирующего состояния системы во время и после эмуляции условия.
Специальная информация:	Для создания напряжения на сеть могут потребоваться сетевые инструменты для загрузки сети сообщениями и пакетами. Постоянную память, используемую для системы, следует временно уменьшить, чтобы ограничить доступное пространство для роста базы данных. Следует синхронизировать одновременный доступ клиентов к одним и тем же записям данных или учетным записям.

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

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

Цели методики:	Протестировать функции цели тестирования в следующих сценариях высокой емкости с целью наблюдения и регистрации целевого алгоритма: Максимальное (фактическое или физически возможное) число подключенных либо имитируемых клиентов, выполняющих одну и ту же (наихудшую с точки зрения производительности) функцию бизнес-процесса на протяжении длительного периода. Достигнут максимальный размер (фактический или в масштабе) базы данных, и одновременно выполняется несколько запросов или отчетных транзакций.
Методика:	Применяются тесты, разработанные для профилирования производительности или тестирования нагрузки. Следует использовать несколько клиентов, выполняющих одни и те же или дополнительные тесты для создания наихудшего объема транзакций или их смеси (см. тестирование напряжений) на протяжении длительного периода. Создан максимальный размер базы данных (фактической, в масштабе или заполненной репрезентативными данными), и для выполнения запросов и отчетных транзакций в течение продолжительного периода одновременно используется несколько клиентов.
Оракулы:	Наметьте одну или несколько стратегий, которые можно использовать в методике для правильного наблюдения результатов теста. Оракул сочетает элементы и метода, посредством которого можно выполнить наблюдение, и характеристики определенного результата, которые указывают на возможный успех или неудачу. В идеале, оракулы будут выполнять самопроверку, допуская начальную оценку успеха или неудачи автоматизированными тестами. Однако следует учитывать риски, связанные с автоматическим определением результатов.
Необходимые инструменты:	Для данной методики требуются следующие инструменты: Инструмент автоматизации сценариев тестирования инструмент планирования и управления нагрузкой транзакции инструменты мониторинга установки (реестр, жесткий диск, CPU, память и так далее) инструменты, ограничивающие ресурсы; например, Canned Heat инструменты генерации данных
Критерии успешности:	Эта методика поддерживает тестирование эмуляции емкости. Большое количество пользователей, данных, транзакций или других аспектов использования системы можно успешно эмулировать и зафиксировать наблюдение изменений состояния системы на протяжении тестирования емкости.
Специальная информация:

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

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

Защита на уровне приложения, включая доступ к данным или функциям бизнес-процесса

Защита на уровне системы, включая вход в систему или удаленный доступ к системе

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

Защита на уровне системы гарантирует, что только пользователи, имеющие права доступа к системе, имеют доступ к приложениям и только через соответствующие шлюзы.

Цели методики:	Протестировать цель тестирования в следующих условиях с целью наблюдения и регистрации целевого алгоритма: Защита на уровне приложения: субъект имеет доступ только к тем функциям и данным, для которых пользователь данного типа имеет права доступа. Защита на уровне системы: доступ к приложениям разрешен только субъектам, имеющим права доступа к системе и приложениям.
Методика:	Защита на уровне приложения: Определить и перечислить все типы пользователей и функции и данные, доступ к которым разрешен пользователям каждого типа. Создание тестов для каждого типа пользователей и проверка всех прав доступа путем создания транзакций, определенных для каждого типа пользователей. Изменение типа пользователей и перезапуск тестов для этих же пользователей. В каждом случае - проверка того, что правильно разрешен или отклонен доступ к дополнительным функциям или данным. Доступ на уровне системы: См. приведенную ниже Специальную информацию.
Оракулы:	Наметьте одну или несколько стратегий, которые можно использовать в методике для правильного наблюдения результатов теста. Оракул сочетает элементы и метода, посредством которого можно выполнить наблюдение, и характеристики определенного результата, которые указывают на возможный успех или неудачу. В идеале, оракулы будут выполнять самопроверку, допуская начальную оценку успеха или неудачи автоматизированными тестами. Однако следует учитывать риски, связанные с автоматическим определением результатов.
Необходимые инструменты:	Для данной методики требуются следующие инструменты: Инструмент автоматизации сценариев тестирования "Хакерские" инструменты тестирования и поиска брешей в защите Инструменты администрирования защиты ОС
Критерии успешности:	Эта методика поддерживает тестирование соответствующих функций и данных, на которые влияют параметры защиты, для каждого известного типа пользователей.
Специальная информация:	Доступ к системе должен проверяться и обсуждаться с администраторами соответствующих систем или сетей. Это тестирование может не являться необходимым, поскольку может входить в функции администрирования сетей или систем.

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

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

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

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

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

Тестирование конфигурации

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

Цели методики:	Проверка цели тестирования в требуемых конфигурациях аппаратного и программного обеспечения с целью наблюдения и регистрации целевого алгоритма в различных конфигурациях и определения различий в состоянии конфигурации.
Методика:	Применение тестов функций. Открытие и закрытие различного не являющегося целью тестирования связанного программного обеспечения, например, приложений Microsoft® Excel® и Microsoft® Word®, либо как части теста, либо до выполнения теста. Выполнение выбранных транзакций для имитации субъектов, взаимодействующих с целью тестирования и программным обеспечением, не являющимся целью тестирования. Повторение указанного выше процесса, минимизируя доступную основную память на клиентской рабочей станции.
Оракулы:	Наметьте одну или несколько стратегий, которые можно использовать в методике для правильного наблюдения результатов теста. Оракул сочетает элементы и метода, посредством которого можно выполнить наблюдение, и характеристики определенного результата, которые указывают на возможный успех или неудачу. В идеале, оракулы будут выполнять самопроверку, допуская начальную оценку успеха или неудачи автоматизированными тестами. Однако следует учитывать риски, связанные с автоматическим определением результатов.
Необходимые инструменты:	Для данной методики требуются следующие инструменты: инструмент создания образов и восстановления базовой конфигурации инструменты мониторинга установки (реестр, жесткий диск, CPU, память и так далее)
Критерии успешности:	Эта методика поддерживает тестирование одного или нескольких сочетаний целевых элементов теста, выполняемых в ожидаемых поддерживаемых средах разработки.
Специальная информация:	Какое не являющееся целью тестирования программное обеспечение требуется, доступно и к которому имеется доступ на рабочем столе? Какие приложения обычно используются? Какими данными оперируют приложения; например, большая электронная таблица, открытая в Excel, или содержащий 100 страниц документ в Word? В качестве части этого теста следует также задокументировать сеть, сетевые серверы и базы данных систем в целом.

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

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

Цели методики:	Выполнение установки цели тестирования в каждой необходимой конфигурации аппаратного обеспечения при следующих условиях с целью наблюдения и регистрации алгоритма установки и изменений состояния конфигурации: новая установка: новая система, в которой никогда ранее не устанавливалось <Имя проекта> обновление: система, в которой ранее было установлено <Имя проекта>, та же версия обновление версии: система, в которой ранее было установлено <Имя проекта>, более ранняя версия
Методика:	Разработка автоматизированных или выполняемых вручную сценариев для проверки условия целевой системы. новая: <имя проекта> никогда не устанавливалось <имя проекта> этой же или более ранней версии уже было установлено Запуск или выполнение установки. Применение определенного заранее подмножества сценариев тестирования функций, выполнение транзакций.
Оракулы:	Наметьте одну или несколько стратегий, которые можно использовать в методике для правильного наблюдения результатов теста. Оракул сочетает элементы и метода, посредством которого можно выполнить наблюдение, и характеристики определенного результата, которые указывают на возможный успех или неудачу. В идеале, оракулы будут выполнять самопроверку, допуская начальную оценку успеха или неудачи автоматизированными тестами. Однако следует учитывать риски, связанные с автоматическим определением результатов.
Необходимые инструменты:	Для данной методики требуются следующие инструменты: инструмент создания образов и восстановления базовой конфигурации инструменты мониторинга установки (реестр, жесткий диск, CPU, память и так далее)
Критерии успешности:	Эта методика поддерживает тестирование установки разработанного продукта в одной или нескольких конфигурациях установки.
Специальная информация:	Какие транзакции <имя проекта> следует выбрать для составления достоверного теста того, что приложение <имя проекта> было установлено успешно, и что не пропущены важные компоненты программного обеспечения?

Перевод статьи Rizwan Jafri

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

C : Create (Создать) — операция ‘Create’ выполняется, когда пользователь сохраняет любую новую транзакцию.
R : Retrieve (Получить) — операция ‘Retrieve’ выполняется, когда пользователь производит поиск или просмотр любой сохраненной транзакции.
U : Update (Обновить) — операция ‘Update’ выполняется, когда пользователь редактирует или изменяет существующую запись.
D : Delete (Удалить) — операция ‘Delete’ выполняется, когда пользователь удаляет любую запись из системы.

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

Laravel предоставляет множество полезных инструментов для тестирования ваших приложений, использующих БД. Во-первых, вы можете использовать вспомогательный метод PHP seeInDatabase () для проверки того, что данные в БД соответствуют определённому набору критериев. Например, если вы хотите проверить, что в таблице users есть запись с полем email равным [email protected] , вы можете сделать следующее:

PHP
{
// Осуществление вызова приложения...

$this -> seeInDatabase ("users" , [
"email" => "[email protected]"
]);
}

Само собой, такие методы как PHP seeInDatabase () созданы для удобства. Вы можете использовать любые встроенные методы проверки PHPUnit для дополнения своих тестов.

Сброс БД после каждого теста

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

Использование миграций

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

PHP

{
use DatabaseMigrations ;

/**
*
* @return void
*/

{
$this -> visit ("/" )
-> see ("Laravel 5" );
}
}

Использование транзакций

Другой способ сброса состояния БД - обернуть каждый тест-кейс в транзакцию БД. И для этого Laravel также предоставляет удобный типаж DatabaseTransactions , который автоматически сделает это для вас:

PHP

Use Illuminate \ Foundation \ Testing \ WithoutMiddleware ;
use Illuminate \ Foundation \ Testing \ DatabaseMigrations ;
use Illuminate \ Foundation \ Testing \ DatabaseTransactions ;

class ExampleTest extends TestCase
{
use DatabaseTransactions ;

/**
* Пример базового функционального теста.
*
* @return void
*/
public function testBasicExample ()
{
$this -> visit ("/" )
-> see ("Laravel 5" );
}
}

По умолчанию этот типаж будет оборачивать в транзакции только подключение к БД по умолчанию. Если ваше приложение использует несколько подключений к БД, вам надо определить свойство PHP $connectionsToTransact в классе вашего теста. Это свойство должно быть массивом имён подключений для выполнения транзакций над ними.

Создание фабрик

При тестировании вам может понадобиться вставить несколько записей в вашу БД перед выполнением теста. При создании этих данных Laravel позволяет вам вместо указания значений каждого столбца вручную определить стандартный набор атрибутов для каждой из ваших моделей Eloquent с помощью фабрик. Для начала посмотрите на файл database/factories/ModelFactory.php в вашем приложении. Изначально этот файл содержит определение одной фабрики:

PHP $factory -> define (App \ User ::class, function (Faker \ Generator $faker ) {
static $password ;

Return [
"name" => $faker -> name ,
"email" => $faker -> unique ()-> safeEmail ,
"password" => $password ?: $password = bcrypt ("secret" ),
"remember_token" => str_random (10 ),
];
});

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

Само собой, вы можете добавить свои собственные дополнительные фабрики в файл ModelFactory.php . Также вы можете создать дополнительные файлы фабрик для каждой модели для более понятной организации. Например, вы можете создать файлы UserFactory.php и CommentFactory.php в вашей папке database/factories . Все файлы в папке factories будут автоматически загружены Laravel.

Состояния фабрик

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

PHP $factory -> state (App \ User ::class, "delinquent" , function ($faker ) {
return [
"account_status" => "delinquent" ,
];
});

Использование фабрик

Создание моделей

После определения фабрик вы можете использовать глобальную функцию PHP factory () в своих тестах или файлах начальных данных для генерирования экземпляров модели. Итак, давайте рассмотрим несколько примеров создания моделей. Во-первых, мы используем метод PHP make () для создания моделей, но не сохраним их в БД:

PHP public function testDatabase ()
{
$user = factory (App \ User ::class)-> make ();

Также вы можете создать коллекцию моделей или создать модели определённого типа:

PHP $users = factory (App \ User ::class, 3 )-> make ();

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

PHP $users = factory (App \ User ::class, 5 )-> states ("delinquent" )-> make ();

$users = factory (App \ User ::class, 5 )-> states ("premium" , "delinquent" )-> make ();

Переопределение атрибутов

Если вы хотите переопределить некоторые из стандартных значений ваших моделей, вы можете передать массив значений в метод PHP make () . Будут заменены только указанные значения, а остальные будут заданы в соответствии с указанными в фабрике:

PHP $user = factory (App \ User ::class)-> make ([
"name" => "Abigail" ,
]);

Постоянные модели

Метод PHP create () не только создаёт экземпляры моделей, но также сохраняет их в БД с помощью метода Eloquent PHP save () :

PHP public function testDatabase ()
{
// Создание одного экземпляра App\User...
$user = factory (App \ User ::class)-> create ();

// Создание трёх экземпляров App\User...
$users = factory (App \ User ::class, 3 )-> create ();

// Использование модели в тестах...
}

Вы можете переопределить атрибуты модели, передав массив в метод PHP create () :PHP make ());
});

Отношения и атрибуты замыкания

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

PHP $factory ->
return [
"title" => $faker -> title ,
"content" => $faker -> paragraph ,
"user_id" => function () {
return factory (App \ User ::class)-> create ()-> id ;
}
];
});

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

PHP $factory -> define (App \ Post ::class, function ($faker ) {
return [
"title" => $faker -> title ,
"content" => $faker -> paragraph ,
"user_id" => function () {
return factory (App \ User ::class)-> create ()-> id ;
},
"user_type" => function (array $post ) {
return App \ User :: find ($post [ "user_id" ])-> type ;
}
];
});