Тестирование бд. Тестирование баз данных — практические советы. Отношения и атрибуты замыкания
Услуга тестирования базы данных, позволит минимизировать риски при внедрении системы в промышленную эксплуатацию. Вы заранее сможете проверить корректность и безопасность функционирования базы данных.
В процессе тестирования БД проверяется работа базы данных приложения на предмет соответствия функциональным и нефункциональным требованиям. Приложения, которые включают в свою архитектуру базу данных, требуют проведение процедуры тестирования БД, например: корпоративные информационные системы, мобильные и веб приложения.
Производительность БД является решающим фактором эффективности управленческих и коммерческих приложений. Если поиск или запись данных выполняется медленно – способность к нормальной работе приложения падает. Существует единственный путь выяснить причину плохой производительности – выполнить количественные измерения и определить, что является причиной проблемы производительности.
Проблемы выявления узких мест производительности баз данных напрямую связаны с метриками, методами измерений производительности и технологией их выполнения. Для крупных корпораций и БД больших объемов проблема определения производительности баз данных имеет еще один очень важный аспект: определения ИТ инфраструктуры для длительной промышленной эксплуатации приложений. Это в итоге приводит к более точному определению первоначальных инвестиций в оборудование и базовое ПО. Так как высокая производительность БД сильно зависит от платформы и оборудования, а они закупаются и эксплуатируются на долгосрочную перспективу.
Наиболее важными метриками измерения производительности БД являются:
- число транзакций за период времени (различного типа транзакции);
- число операций в/в (прочитанных строк) на транзакцию и время ее выполнения;
- число прочитанных строк для каждой таблицы на транзакцию;
- среднее число операций в/в на транзакцию по диапазонам;
- операторы SQL высокой рабочей стоимостью времени использования CPU (пользователя, системного)
- время начала и конца выполнения оператора
- время выполнения операций сортировки (числа сортировок, числа переполнений сортировок, времени выполнения сортировок), наивысшего использования времени elapsed и наименьшей эффективности использования индексов.
Метрики использования памяти для страниц табличных пространств и буферных пулов (для чтения данных, для чтения индексов), для выполнения сортировок, для работы утилит, для каталогов и пакетов кеш – памяти наряду с метриками измерения производительности, так же являются важными для настойки эффективного доступа к данным.
Что еще проверять при тестировании БД?
Data mapping
Убедитесь, что связи в БД соответствуют проектной документацией. Для всех операций CRUD проверьте, что соответствующие таблицы и записи обновляются, когда пользователь нажимает «Сохранить», «Обновить», «Поиск» или «Удалить» из графического интерфейса приложения.
ACID свойства транзакций
К ACID свойствам транзакций относятся атомарность, последовательность, изоляция и прочность. В процессе тестирования БД следует проверить эти четыри свойства. Эта область требует более тщательного тестирования, если база данных распределена.
Целостность данных
Учтите, что разные модули приложения (например, экраны и формы) по-разному используют те же данные и выполняют CRUD операции. Поэтому нужно убедиться, что последнее состояние данных отражается везде одинаково. Система должна показывать обновленные значения на всех формах и экранах. Это называется целостностью данных.
Точность реализации бизнес логики
Сегодня базы данных предназначены не только для хранения записей. Они превратились в очень мощные инструменты, которые предоставляют разработчикам широкие возможности для реализации бизнес-логики на уровне БД. Примерами мощных функций баз данных являются «ссылочная целостность», реляционные ограничения, триггеры и хранимые процедуры. Таким образом, используя эти и многие другие возможности, предлагаемые БД, разработчики реализуют бизнес-логику на уровне БД. Тестировщик должен убедиться, что реализованная бизнес-логика является правильной и работает точно.
Как тестировать базу данных?
Написание SQL запросов
Для того чтобы правильно организовать процесс тестирования БД, тестировщики должны обладать хорошими знаниями SQL и DML (Data Manipulation Language) и иметь ясное представление о внутренней структуре БД. Это самый лучший и надежный способ тестирования БД особенно для приложений с низким и средним уровнем сложности. Но должны быть выполнены две описанные предпосылки. Если приложение является очень сложным, то для тестировщика будет трудно или даже невозможно написать все необходимые SQL-запросы самостоятельно. Поэтому в случае некоторых сложных запросов, тестировщик может обратиться за помощью к разработчику. Данный метод не только даёт уверенность, что тестирование выполнено качественно, но также повышает мастерство написания SQL-запросов.
Просмотр данных в таблицах
Если тестировщик не знает SQL, то он может проверить результат выполнения операции CRUD с помощью графического интерфейса приложения, путем просмотра таблиц (отношений) базы данных. Этот способ проверки БД требует хороших знаний структуры таблиц и может быть немного утомительным и громоздким, особенно когда БД и таблицы имеют большой объем данных. Этот способ проверки БД может быть трудным для тестировщиков, если проверочные данные, находятся в нескольких таблицах.
Помощь разработчика
Тестировщик выполняет любые операции CRUD с графическим интерфейсом и проверяет их результаты путем выполнения соответствующих SQL-запросов, написанных разработчиком. Данный способ не требует ни хороших знаний SQL, ни хорошего знания структуры БД приложения.Метод кажется простым и хорошим выбором для тестирования БД. Но его недостатком является хаос. Что делать, если запрос, написанный разработчиком семантически неверный или не выполняет требования пользователя правильно? В этом случае тестирование не дает никаких гарантий о качестве продукта.
Пример методики тестирования целостности данных БД
Базы данных и процессы баз данных следует тестировать как независимую подсистему. При этом должны быть протестированы все подсистемы без целевого пользовательского интерфейса как интерфейса к данным. Следует выполнить дополнительное исследование в системе управления базами данных (DBMS) для определения инструментов и методик для поддержки тестирования, определенного в следующей таблице.
| Цели методики | Тестирование методов и процессов доступа к базам данных независимо от UI, так чтобы можно было наблюдать и регистрировать неправильно работающий целевой алгоритм или повреждения данных. |
| Методика | Вызов каждого метода или процесса доступа к базе данных, заполняя каждый из них верными и неверными данными или запросами данных.
Проверка базы данных, чтобы убедиться в том, что заполнение данными выполнено правильно и все события базы данных происходят соответствующим образом, либо проверка возвращаемых данных, чтобы убедиться в том, что при необходимости извлекаются правильные данные. |
| Оракулы (эвристический механизм, который помогает определить проблему) | Наметьте одну или несколько стратегий, которые можно использовать в методике для правильного наблюдения результатов теста. Оракул сочетает элементы и метода, посредством которого можно выполнить наблюдение, и характеристики определенного результата, которые указывают на возможный успех или неудачу. В идеале, оракулы будут выполнять самопроверку, допуская начальную оценку успеха или неудачи автоматизированными тестами. Однако следует учитывать риски, связанные с автоматическим определением результатов. |
| Необходимые инструменты | Для данной методики требуются следующие инструменты:
|
| Критерии успешности | Эта методика поддерживает тестирование всех основных методов и процессов доступа к базе данных. |
| Специальная информация | Для тестирования может потребоваться среда разработки DBMS или драйверы для ввода или изменения данных непосредственно в базе данных.
Процессы следует вызывать вручную. Небольшие базы данных или базы данных минимального размера (с ограниченным числом записей) следует использовать для расширения области видимости всех поврежденных событий. |
Базы данных и процессы баз данных следует тестировать как независимую подсистему. При этом должны быть протестированы все подсистемы без целевого пользовательского интерфейса как интерфейса к данным. Следует выполнить дополнительное исследование в системе управления базами данных (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, память и так далее) |
| Критерии успешности: |
Эта методика поддерживает тестирование установки разработанного продукта в одной или нескольких конфигурациях установки. |
| Специальная информация: |
Какие транзакции <имя проекта> следует выбрать для составления достоверного теста того, что приложение <имя проекта> было установлено успешно, и что не пропущены важные компоненты программного обеспечения? |
: Как тестировать и отлаживать базы данных
Автоматическое модульное тестирование (unit test) кода приложения - дело простое и понятное. А как тестировать базу данных? Или приложение, которое работает с базой данных. Ведь база - это не просто программный код, база данных - это объект, сохраняющий своё состояние. И если мы начнём в процессе тестирования изменять данные в базе (а без этого какое же у нас будет тестирование?!), то после каждого теста база будет изменяться. Это может помешать последующим тестам и необратимо испортить базу данных.
Ключ к решению проблемы - транзакции. Одна из особеностей этого механизма состоит в том, что до тех пор, пока транзакция не завершена, вы всегда можете отменить все изменения и вернуть базу в состояние на момент начала транзакции.
Алгоритм такой:
- открываем транзакцию;
- если нужно, выполняем подготовительные действия для тестирования;
- выполняем модульный тест (или просто запускаем сценарий, работу которого хотим проверить);
- проверяем результат работы сценария;
- отменяем транзакцию, возвращая базу данных в исходное состояние.
Даже если в тестируемом коде останутся незакрытые транзакции, внешний ROLLBACK всё равно откатит все изменения корректно.
Хорошо, если нам нужно протестировать SQL-сценарий или хранимую процедуру. А если мы тестируем приложение, которое само подключается к базе, открывая новое соединение? Кроме того, если мы занимаемся отладкой, то нам наверняка захочется посмотреть на базу глазами самого отлаживаемого приложения. Как быть в таком случае?
Не торопитесь сочинять распределённые транзакции, есть более простое решение! Штатными средствами SQL-сервера вы можете открыть транзакцию на одном соединении, а продолжить её на другом.
Для этого нужно подключиться к серверу, открыть транзакцию, получить маркер этой транзакции, а затем передать этот маркер тестируемому приложению. Оно в своём сеансе присоединится к нашей транзакции и с этого момента мы в своём отладочном сеансе будем видеть данные (а также чувствовать блокировки) точно так, как их видит тестируемое приложение.
Последовательность действий такова:
Начав транзакцию в отладочном сеансе мы должны узнать её идентификатор. Это уникальная строка, по которой сервер различает транзакции. Этот идентификатор надо каким-то образом передать в тестируемое приложение.
Теперь задача приложения - прежде, чем оно начнёт делать то, что ему положено, привязаться к нашей контрольной транзакции.
Затем приложение начинает работать, в том числе запускать свои хранимые процедуры, открывать свои транзакции, менять режим изоляции... Но наш отладочный сеанс всё это время будет находиться внутри той же транзакции, что и приложение.
Допустим, приложение блокирует таблицу и начинает изменять её содержимое. В этот момент никакие другие соединения заглянуть в заблокированную таблицу не могут. Но только не наш отладочный сеанс! Из него мы можем смотреть на базу точно так же, как это делает приложение, так как SQL-сервер считает, что мы находимся в одной транзакции.
В то время как для всех остальных сеансов действия приложения скрыты блокировками...
Наш отладочный сеанс спокойно проходит сквозь блокировки (сервер думает, что это наши собственные блокировки)!
Или представьте, что приложение начинает работать со своими версиями строк в режиме SNAPSHOT. Как заглянуть в эти версии? Даже это возможно, если вы связаны общей транзакцией!
Не забудьте в конце этого увлекательного процесса откатить контрольную транзакцию. Это можно сделать как из отладочного сеанса (если процесс тестирования завершится нормально), так и из самого приложения (если в нём случится что-то непредвиденное).
Подробнее об этом Вы сможете узнать на курсах
Перевод статьи 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-запросов, знаний о структуре БД и соответствующей подготовки.
Для того чтобы быть уверенным в эффективности тестирования, оно должно быть возложено на сотрудника, обладающего всеми этими четырьмя качествами. В противном случае, после поставки продукта, скорее всего, будут наблюдаться неправильное или непредусмотренное поведение приложения, ошибки, которые найдет заказчик.
1) Цели и задачи ……………………………………………………………... 3
2) Описание базы данных …………………………………………………... 4
3) Работа с базой данных …………………………………………………… 6
4) Нагрузочное тестирование базы данных ………………………………...11
5) Вывод ……………………………………………………………………....15
6) Литература ………………………………………………………………....16
Цели и задачи
Цель: создать базу данных эликсиров по игре Ведьмак 3, которая будет содержать в себе информацию о виде эликсиров, их свойствах, из чего они изготавливаются, местах где их можно найти и о чудовищах, против которых их можно применять. Создать оптимизированные запросы к данной базе данных и протестировать ее на нагрузку.
Задачи:
· Создать в MYSQL Workbench схему базы данных минимум с 5 сущностями. Описать эти сущности и их связи.
· Описать использование этой БД, расписать основные запросы, посмотреть на их время исполнения и сделать выводы
· Оптимизация БД
· Выполнить нагрузочное тестирование с помощью apache-jmeter. Использовать для него расширения для построения графиков.
Описание базы данных
В курсовой работе используется созданная база данных Witcher1, основными сущностями которой являются таблицы:
Рис.1 Схематическое отображение базы данных Witcher1
В таблице Ingridients содержатся необходимые ингредиенты для создания эликсиров в игре, которые описаны в таблице Elixirs. Для создания эликсира используется несколько ингредиентов, но каждый из них уникален для своего эликсира. Именно по этой причине между этими таблицами была установлена связь 1: n (один ко многим), что и показано на схеме базы данных (Рис.1).
Так же в таблице Ingridients содержится информация о названиях ингредиентов (Discription) и о том, где можно найти данный ингредиент (WhereFind). Колонка idElixirs является связующей колонкой для таблиц Ingridients и Elixirs.
В таблице Elixirs содержится информация о том, как использовать конкретный эликсир и название данного эликсира. Данная таблица является ключевой для остальных таблиц.
В таблице Locations содержится информация о том, в каком именно месте или около какого города можно найти конкретный ингредиент.
Таблица IL содержит объединённую информацию о том, где и как найти конкретный ингредиент в данной местности и что он из себя представляет. Между таблицами Ingridients и Locations была установлена связь n: m (многие ко многим), так как несколько ингредиентом могут быть найдены в нескольких локациях, о чем и указано в дочерней таблице IL.
В таблице Monsters содержится информация о видах чудовищ в
«Witcher 3», о том, как распознать то или иное чудовище и характерные для них имена.
Таблица ML является дочерней таблицей к объединению связью n: m таблиц Location и Monsters и содержит в себе конкретную информацию о том, как победить именно данное чудище и какие эликсиры для этого могут быть использованы, включая специальные ведьмачьи знаки, а так же в какой местности и по каким признакам искать именно этот вид чудища.
Работа с базой данных
База данных Witcher1 содержит в себе информацию о том, какие эликсиры против каких чудовищ необходимо использовать, специальную тактику для особо опасных чудовищ, таких как: Моровая дева, Черт, Бес, Леший и т.д. Анализировать информацию из каждой таблицы по порядку займет очень много времени, поэтому создадим специальные запросы к базе данных, которые максимально будут полезны для пользователя.
· Запрос о том, как найти конкретное чудище.
Данный запрос будет содержать в себе ключевое слово JOIN, благодаря которому и будет осуществляться обращение к таблицам ML и Monsters базы данных Witcher1.
Данный запрос будет выглядеть следующим образом:
ml JOIN monsters ON monsters.idMonsters=ml.idMonsters;
После выполнения запроса мы получим на выход достаточно объемную таблицу, которая является результатом объединения двух таблиц. Чтобы выводимая таблица не была столь огромной, можно задать по какому именно чудовищу выводить информацию. То есть, для, например, Хима, запрос будет выглядеть следующим образом:
monsters.MonstersName, monsters.MonstersDiscription,
ml.DiscriptionHowFind, ml.idLocations
ml JOIN monsters ON monsters.idMonsters=ml.idMonsters
where monsters.MonstersName=’Hym’;
Какому чудовищу соответствует тот или иной ID можно узнать из запроса к таблицам Monsters или ML. Запросы будут выглядеть следующим образом:
SELECT SELECT
IdMonsters, MonstersName idMonsters, MonstersName
FROM ml; FROM monsters;
Для проверки соответствия можно сделать запрос к обеим таблицам ML и Monsters, предварительно объединив их по idMonsters.
ml.idMonsters, monsters.MonstersName
ml JOIN monsters ON
ml.idMonsters=monsters.idMonsters
ORDER BY monsters.idMonsters;
· Запрос о том, какой эликсир подходит к данному чудовищу.
Для реализации данного запроса будет использован JOIN. Запрос будет обращен к двум таблицам Elixirs и Monsters и будет содержать в себе информацию о том, когда и какой эликсир выпить в борьбе с чудовищем:
monsters.MonstersName ,elixirs.ElixirName, elixirs.ElixirDiscription
elixirs JOIN monsters ON
elixirs.idElixirs=monsters.idElixirs;
· Запрос о том, какой ингредиент находится в той или иной местности.
Для реализации данного запроса будет использован JOIN. Запрос будет обращен к двум таблицам Ingridients и Locations и будет содержать в себе информацию о том, какой ингредиент в какой локации находится и информацию о его виде:
ingridients.Discription, locations.Discription, ingridients.WhereFind
ingridients JOIN locations ON
ingridients.idIngridients=locations.idIngridients
ORDER BY ingridients.Discription;
· Запросы UPDATE
Данный запрос реализуем для чудовища в таблице Monsters по имени Хим (Hym). Допустим, мы хотим поменять ему имя на Him:
monsters
SET MonstersName="Him"
where idMonsters=1;
Но, так как в английском варианте верно Hym то вернем все обратно:
monsters
SET MonstersName="Hym"
where idMonsters=1;
Рис.2. Реализация запросов UPDATE
· Запросы «агрегации». COUNT и COUNT(DISTINCT)
Функция COUNT подсчитывает количество не пустых строк (внутри них не NULL) в данной таблице. COUNT имеет оптимизированную версию для вывода количества строк, если она используется для 1 таблицы. Например:
Рис.3. Подсчет строк в таблицах Elixirs, Monsters и объединенной таблице Monsters JOIN elixirs.
Функция же COUNT(DISTINCT) используется для вывода количества не повторяющихся строк в таблицах и является более оптимизированной версией семейства функций COUNT:
Рис.4. Подсчет неповторяющихся эликсиров в таблице Monsters.
· Функция DELETE.
Добавим в таблицу Elixirs еще одну строчку, используя INSERT:
INSERT INTO elixirs VALUES (6,’ForDelete’,’DiscriptionDelete’);
Рис.5. Добавление строки в таблицу Elixirs.
Теперь сделаем запрос на удаление этой строки, так как нет необходимости в эликсире, который никак не поможет в борьбе с чудищами:
DELETE FROM elixirs WHERE idElixirs=6;
Рис.6. Удаление добавленной строки.
Нагрузочное тестирование базы данных
Теперь, когда выполнены запросы и обращение к базе данных налажено, её можно протестировать по нескольким параметрам:
· Response Times Over Time или Времена отклика в зависимости от времени – данная проверка отображает информацию для каждого запроса его среднее время отклика в миллисекундах.
· Response Times Distribution или Распределение времени отклика - данная проверка отображает количество ответов в определенный интервал времени, во время которого выполнялся запрос.
· Response Time Percentiles или Процентили времени отклика – данная проверка отображает процентили для значений времени отклика. На графике по оси X будут располагаться проценты, по оси Y- время отклика.
Для максимально правдоподобных тестов зададим определенные
параметры:
Рис.7. Параметры тестирования
Number of Threads(users) – Число виртуальных пользователей. В нашем случае поставим 1000, чтобы максимально нагрузить нашу базу данных.
Ramp-Up Period – период, в течение которого все пользователи будут задействованы.
Проверять будем все запросы JOIN на их быстродействие при одновременной их активации несколькими пользователями.
Последние 3 пункта – это графопостроители тех проверок, по которым мы будем тестировать базу данных.
· 
Проверка Response Times Over Time
Рис.7. Результат выполнения запросов при тесте Response Times Over Time
Как видно из графика, самый трудновыполнимый запрос был «Monsters&Locations» и потребовал больше всего времени на его отклик. Убедиться в причине длительного выполнения запроса можно выполнив запрос в консоли. Основная причина такой задержки объясняется тем, что и в таблице Monsters, и в таблице ML содержатся объемные пояснения к чудовищам или к местам, где их найти. Из-за этого запрос выполняется достаточно длительное время.
· 
Проверка Response Times Distribution
Рис.8. Результат выполнения запросов при тесте Response Times Distribution.
По данному графику можно сделать вывод, что количество ответов для каждого из наших запросов в один и тот же период времени одинаково.
· 
Проверка Response Time Percentiles
По оси ординат указано время выполнения, а по оси абсцисс размещены проценты от общего кол-ва. По графику можно заключить, что 90% запросов выполняются в интервал времени от 0 до 340 миллисекунд, причем с 5% до 15% количество запросов возрастает линейно, а далее по экспоненте с очень малым коэффициентом степени возрастания.
Оставшиеся 10% выполняются в интервал времени от 340 миллисекунд до 700 миллисекунд, благодаря чему можно сделать вывод, что осуществляется очень большая нагрузка на базу данных.
Вывод
В данной курсовой работы были выполнены все задачи. База данных была спроектирована, заполнена данными, показаны основные возможности ее использования в виде запросов и их результаты выполнения.
В конце, было выполнено тестирования и анализ его результатов, с последующими выводами.
Необходимо отметить, что сама БД была создана в качестве лишь учебной, поэтому она не столь объемна.
Еще одной важной характеристикой является безопасность: пароли, если будет создана такая таблица, нужно хранить в зашифрованном виде и оберегать от неправомерного доступа.
Литература
1. http://phpclub.ru/mysql/doc/ - интернет ресурс «MySQL - справочное руководство»
2. Шварц Б., Зайцев П., Ткаченко В. и др. - MySQL. Оптимизация производительности (2-е издание)
3. Талманн Л., Киндал М., Белл Ч. – «Обеспечение высокой доступности систем на основе MySQL»
4. Сапковский Анджей – «Ведьмак (большой сборник)», Количество страниц: 571
5. CD PROJECT RED, GOG COM. «Ведьмак 3: Дикая Охота».
Похожая информация.