Тестування бд. Тестування баз даних – практичні поради. Відносини та атрибути замикання

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

Продуктивність БД є вирішальним чинником ефективності управлінських та комерційних додатків. Якщо пошук або запис даних виконується повільно, здатність до нормальної роботи програми падає. Існує єдиний шлях з'ясувати причину поганої продуктивності – виконати кількісні виміри та визначити, що є причиною проблеми продуктивності.
Проблеми виявлення вузьких місць продуктивності баз даних безпосередньо пов'язані з метриками, методами вимірювань продуктивності та технологією їх виконання. Для великих корпорацій та БД великих обсягів проблема визначення продуктивності баз даних має ще один дуже важливий аспект: визначення ІТ-інфраструктури для тривалої промислової експлуатації додатків. Це в результаті призводить до більш точного визначення початкових інвестицій у обладнання та базове програмне забезпечення. Так як висока продуктивність БД сильно залежить від платформи та обладнання, а вони закуповуються та експлуатуються на довгострокову перспективу.
Найбільш важливими метриками вимірювання продуктивності БД є:

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

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

Що ще перевіряти під час тестування БД?

Data mapping

Переконайтеся, що зв'язки з БД відповідають проектної документації. Для всіх операцій CRUD перевірте, чи відповідні таблиці та записи оновлюються, коли користувач натискає "Зберегти", "Оновити", "Пошук" або "Видалити" з графічного інтерфейсу програми.

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

До ACID властивостями транзакцій відносяться атомарність, послідовність, ізоляція та міцність. У процесі тестування БД слід перевірити ці чотири властивості. Ця область вимагає ретельнішого тестування, якщо база даних розподілена.

Цілісність даних

Врахуйте, що різні модулі програми (наприклад, екрани та форми) по-різному використовують ті самі дані та виконують CRUD операції. Тому необхідно переконатися, що останній стан даних відбивається скрізь однаково. Система має відображати оновлені значення на всіх формах та екранах. Це називається цілісністю даних.

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

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

Як тестувати базу даних?

Написання SQL запитів

Для того щоб правильно організувати процес тестування БД, тестувальники повинні мати хороші знання SQL і DML (Data Manipulation Language) і мати чітке уявлення про внутрішню структуру БД. Це найкращий і надійний спосібтестування БД особливо для додатків із низьким та середнім рівнем складності. Але мають бути виконані дві описані передумови. Якщо програма є дуже складною, то для тестувальника буде важко або навіть неможливо написати всі необхідні SQL-запити самостійно. Тому у разі деяких складних запитів тестувальник може звернутися за допомогою до розробника. Даний метод не тільки дає впевненість, що тестування виконано якісно, ​​але також підвищує майстерність написання SQL-запитів.

Перегляд даних у таблицях

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

Допомога розробника

Тестувальник виконує будь-які операції CRUD з графічним інтерфейсом та перевіряє їх результати шляхом виконання відповідних SQL-запитів, написаних розробником. Цей спосібне вимагає ні хороших знань SQL, ні хорошого знання структури БД додатку. Метод здається простим і гарним виборомдля тестування БД Але його недоліком є ​​хаос. Що робити, якщо запит, написаний розробником семантично невірним чи не виконує вимоги користувача правильно? У цьому випадку тестування не дає жодних гарантій щодо якості продукту.

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

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

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

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

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

Тестування функцій

Тестування функцій мети тесту слід зосередити на вимогах, трасування яких можна провести безпосередньо до варіантів використання або функцій та правил бізнес-процесу. Метою цих тестів є перевірка правильного приймання, обробки та повернення даних, а також відповідної реалізації правил бізнес-процесу. Цей тип тестування заснований на методиках чорної скриньки, тобто перевірка програми та її внутрішніх процесів виконується шляхом взаємодії з додатком за допомогою Графічного інтерфейсу користувача (GUI) і аналізу висновків або результатів. У наведеній нижче таблиці визначається схема тестування, рекомендована для кожної програми.

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

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

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

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

Тестування інтерфейсу користувача

У тестуванні інтерфейсу користувача (UI) перевіряється взаємодія користувача з програмним забезпеченням.

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

Можливий доступ не до всіх властивостей об'єктів користувача та об'єктів інших фірм.

Профілювання продуктивності

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

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

Тестування навантаження

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

Профілювання продуктивності є тестом продуктивності, в якому вимірюються і оцінюються час відповідей, швидкість транзакцій та інші залежні від часу вимоги. Метою профілювання продуктивності є перевірка досягнення вимог продуктивності. Профілювання продуктивності реалізується та виконується для профілювання та доведення алгоритмів продуктивності мети тестування як функції умов, таких як робоче навантаження або конфігурація апаратного забезпечення.: Транзакції, наведені в наступній таблиці, належать до "логічних транзакцій бізнес-процесу".

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

Бази даних, що застосовуються для тестування навантаження, повинні мати фактичний розмір, або їх масштаб повинен бути змінений однаково.

Тестування напруг являє собою тип тесту продуктивності, що реалізується і виконується для того, щоб зрозуміти, як відбувається збій системи в умовах на кордоні або поза межами очікуваних допусків. Зазвичай у ньому є брак ресурсів чи конкуренція за ресурси. Умови браку ресурсів показують, як відбувається збій мети тестування, що не є очевидним за звичайних умов. Інші вади можуть бути результатом конкуренції за загальні ресурси, такі як блокування бази даних або пропускна спроможність мережі, хоча деякі з цих тестів зазвичай виконуються під час тестування функцій та навантаження.

Цілі методики:	Протестувати функції мети тестування в наступних умовах напруги з метою спостереження та реєстрації цільового алгоритму, який визначає та документує умови, за яких відбувається збійсистеми, щоб продовжувати роботу відповідним образом: невеликий обсяг пам'яті або відсутність вільної пам'яті на сервері (RAM та обсяг постійної пам'яті) максимально можлива фізично або фактично кількість підключених або імітованих користувачів кілька користувачів виконують одні й самі транзакції з ними і тими самими даними чи обліковими записами "надлишковий" обсяг транзакцій або суміш умов (див. вище розділ Профілювання продуктивності)
Методика:	Для тестування обмежених ресурсів тести слід виконувати в одній системі, а RAM та обсяг постійної пам'яті на сервері мають бути зменшені або обмежені. Для решти тестів напруг слід використовувати кілька клієнтів, які виконують одні й ті ж чи додаткові тести для створення найгіршого обсягу транзакцій чи їх суміші.
Оракули:	Намітьте одну або кілька стратегій, які можна використовувати у методиці для правильного спостереження результатів тесту. Оракул поєднує елементи та методу, за допомогою якого можна виконати спостереження, та характеристики певного результату, які вказують на можливий успіх чи невдачу. В ідеалі, оракули виконуватимуть самоперевірку, допускаючи початкову оцінку успіху чи невдачі автоматизованими тестами. Проте, слід враховувати ризики, пов'язані з автоматичним визначенням результатів.
Необхідні інструменти:	Для цієї методики потрібні такі інструменти: Інструмент автоматизації сценаріїв тестування інструмент планування та управління навантаженням транзакції інструменти моніторингу установки (реєстр, жорсткий диск, CPU, пам'ять тощо) Робочі навантаження слід протестувати у різних конфігураціях тестового середовища. інструменти генерації даних
Критерії успішності:	Ця методика підтримує тестування емуляції напруги. Систему можна успішно емулювати при одному або декількох умовах, визначених як умови напруги, і можна зафіксувати спостереження результуючого стану системи під час і після емуляції умови.
Спеціальна інформація:	Для створення напруги на мережу можуть знадобитися мережеві інструменти для завантаження мережі повідомленнями та пакетами. Постійну пам'ять, що використовується для системи, слід тимчасово зменшити, щоб обмежити доступний простір для збільшення бази даних. Слід синхронізувати одночасний доступ клієнтів до тих самих записів даних або облікових записів.

Тестування ємності

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

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

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

Тестування захисту та управління доступом зосереджено на двох ключових сферах захисту:

Захист на рівні програми, включаючи доступ до даних або функцій бізнес-процесу

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

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

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

Цілі методики:	Протестувати мету тестування в таких умовах з метою спостереження та реєстрації цільового алгоритму: Захист на рівні програми: суб'єкт має доступ тільки до тих функцій та даних, для яких користувач цього типу має права доступу. Захист на рівні системи: доступ до програм дозволено лише суб'єктам, які мають права доступу до системи та додатків.
Методика:	Захист на рівні програми: Визначити та перерахувати всі типи користувачів та функції та дані, доступ до яких дозволено користувачам кожного типу. Створення тестів для кожного типу користувачів та перевірки всіх прав доступу шляхом створення транзакцій, визначених для кожного типу користувачів. Зміна типу користувачів та перезапуск тестів для цих користувачів. У кожному випадку – перевірка того, що правильно дозволено чи відхилено доступ до додаткових функцій або даних. Доступ до системи: Див. наведену нижче Спеціальну інформацію.
Оракули:	Намітьте одну або кілька стратегій, які можна використовувати у методиці для правильного спостереження результатів тесту. Оракул поєднує елементи та методу, за допомогою якого можна виконати спостереження, та характеристики певного результату, які вказують на можливий успіх чи невдачу. В ідеалі, оракули виконуватимуть самоперевірку, допускаючи початкову оцінку успіху чи невдачі автоматизованими тестами. Проте, слід враховувати ризики, пов'язані з автоматичним визначенням результатів.
Необхідні інструменти:	Для цієї методики потрібні такі інструменти: Інструмент автоматизації сценаріїв тестування "Хакерські" інструменти тестування та пошуку проломів у захисті Інструменти адміністрування захисту ОС
Критерії успішності:	Ця методика підтримує тестування відповідних функцій та даних, на які впливають параметри захисту для кожного відомого типу користувачів.
Спеціальна інформація:	Доступ до системи повинен перевірятися та обговорюватися з адміністраторами відповідних систем чи мереж.

Це тестування може бути необхідним, оскільки може входити до функції адміністрування мереж чи систем.

Тестування відновлення після збоїв Тестування відновлення після збоїв дозволяє переконатися, що мета тестування може бути успішно відновлена ​​після різних апаратних збоїв іпрограмного забезпечення

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

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

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

Тестування конфігурації

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

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

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

Тестування установки має дві мети. Перша полягає в тому, щоб переконатися, що програмне забезпечення може бути встановлене (наприклад, нова установка, оновлення, а також повна або вибіркова установка) у різних стандартних та нестандартних умовах. До нестандартних умов входить недостатній обсяг дискової пам'яті, недостатні права доступу до створення каталогів тощо. Другою метою є перевірка того, що після інсталяції програмне забезпечення працює правильно. Зазвичай при цьому виконується ряд тестів, розроблених для тестування функцій.

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

: Як тестувати та налагоджувати бази даних

Автоматичне модульне тестування (unit test) коду програми – справа проста і зрозуміла. Як тестувати базу даних? Або додаток, який працює з базою даних. Адже база – це не просто програмний код, база даних – це об'єкт, що зберігає свій стан. І якщо ми почнемо в процесі тестування змінювати дані в базі (а без цього, яке ж у нас буде тестування?!), то після кожного тесту база буде змінюватися. Це може стати на заваді наступним тестам і необоротно зіпсувати базу даних.

Ключ до вирішення проблеми – транзакції. Одна з особливостей цього механізму полягає в тому, що доки транзакція не завершена, ви завжди можете скасувати всі зміни і повернути базу в стан на момент початку транзакції.

Алгоритм такий:

1. відкриваємо транзакцію;
2. якщо потрібно, виконуємо підготовчі дії для тестування;
3. виконуємо модульний тест (або просто запускаємо сценарій, роботу якого хочемо перевірити);
4. перевіряємо результат роботи сценарію;
5. скасовуємо транзакцію, повертаючи базу даних у вихідний стан.

Навіть якщо в коді, що тестується, залишаться незакриті транзакції, зовнішній 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: Дике Полювання».

Подібна інформація.