Тестування баз даних (Database)
База даних - представлена в об'єктивній формі сукупність самостійних матеріалів (статей, розрахунків, нормативних актів, судових рішень та інших подібних матеріалів), систематизованих таким чином, щоб ці матеріали могли бути знайдені та оброблені за допомогою електронної обчислювальної машини (ЕОМ).
База даних одна із неминучих частин програмного докладання. Неважливо, чи це буде веб, настільний чи мобільний, клієнт-серверний, одноранговий, корпоративний чи індивідуальний бізнес; База даних потрібна скрізь на бекенді. Так само, будь то охорона здоров'я, фінанси, лізинг, роздрібна торгівля, поштовий додаток або управління космічним кораблем; База даних завжди перебуває у дії за лаштунками.
Навіщо тестувати БД?
1. Відображення даних (Data Mapping)
У програмних системах дані часто переміщуються туди і назад з UI (інтерфейсу користувача) в серверну БД і навпаки. Отже, ось деякі аспекти, на які варто звернути увагу:
Перевірте, чи порівнюються поля у формах інтерфейсу/зовнішнього інтерфейсу з відповідними полями в таблиці БД. Зазвичай ця інформація про зіставлення визначається документах з вимогами;
Щоразу, коли певна дія виконується у зовнішньому інтерфейсі програми, відповідна дія CRUD (створення, вилучення, оновлення та видалення) викликається в бекенді. Тестувальник повинен буде перевірити, чи викликається правильна дія і чи є викликана дія сама по собі успішною чи ні.
2. Перевірка вимог ACID (ACID Properties Validation)
Кожна транзакція, яку виконує БД, має відповідати цим чотирма властивостями:
Атомарність ( Atomicity ): гарантує, що кожну транзакцію буде виконано повністю або не буде виконано зовсім. Не допускаються проміжні стани;
Узгодженість ( Consistency ): транзакція, що досягає свого нормального завершення (EOT - end of transaction, завершення транзакції) і тим самим фіксує свої результати, зберігає узгодженість бази даних. Інакше кажучи, кожна успішна транзакція за визначенням фіксує лише допустимі результати;
Ізольованість ( Isolation ): під час виконання транзакції паралельні транзакції не повинні впливати на її результат;
Постійність/надійність ( Durability ): якщо користувач отримав підтвердження від системи, що транзакція виконана, він може бути впевнений, що зроблені ним зміни не будуть скасовані через будь-який збій.
3. Цілісність даних (Data Integrity)
Для будь-якої операції CRUD оновлені та останні значення/статус загальних даних повинні відображатися у всіх формах та екранах. Значення не повинно оновлюватися на одному екрані та відображати більш старе значення на іншому.
Коли програма перебуває у процесі виконання, кінцевий користувач переважно використовує операції «CRUD».
CRUD - акронім, що означає чотири базові функції, що використовуються під час роботи з базами даних: створення (англ. create), читання (read), модифікація (update), видалення (delete). У SQL цим функціям, операціям відповідають оператори Insert (створення записів), Select (читання записів), Update (редагування записів), Delete (видалення записів). У системах, що реалізують доступ до бази даних через API у стилі REST, ці функції реалізуються часто (але не обов'язково) через HTTP-методи PUT, POST, GET, PATCH, DELETE.
Будь-яка операція з базою даних, що виконується кінцевим користувачем, завжди є однією з чотирьох перерахованих вище.
Тому розробте свої тестові приклади БД таким чином, щоб увімкнути перевірку даних у всіх місцях, де вони з'являються, щоб побачити, чи вони однакові.
4. Відповідність бізнес-правилам (Business Rule Conformity)
Більш складна база даних означає більш складні компоненти, такі як реляційні обмеження, тригери, процедури, що зберігаються і т. д. Тому тестувальникам доведеться вигадувати відповідні SQL-запити для перевірки цих складних об'єктів.
Що тестувати?
1. Транзакції
2. Схеми бази даних
Схема бази даних - це не що інше, як формальне визначення того, як дані будуть організовані всередині БД. Щоб перевірити це:
Визначте вимоги, на основі яких працює база даних. Зразок вимог:
Первинні ключі мають бути створені до створення будь-яких інших полів;
Зовнішні ключі повинні бути повністю проіндексовані для легкого вилучення та пошуку;
Імена полів, що починаються або закінчуються певними символами;
Поля з обмеженням, що певні значення можуть або можуть бути вставлені.
Використовуйте один із таких методів залежно від релевантності:
SQL запит для перевірки схеми.
Регулярні вирази для перевірки імен окремих полів та їх значень;
Такі інструменти як SchemaCrawler.
3. Тригери
Коли певна подія відбувається у певній таблиці, частина коду (тригер) може бути автоматично проінструктована до виконання.
Наприклад, новий учень приєднався до школи. Учень відвідує 2 класи: математику та природознавство. Учень додано до таблиці учнів. Тригер може додати учня до відповідних предметних таблиць, як тільки він буде доданий до студентської таблиці.
Звичайний метод тестування полягає в тому, щоб спочатку виконати SQL-запит, вбудований в тригер, і порівняти фактичний результат з очікуваним.
Тестування білої скриньки: заглушки та драйвери використовуються для вставки, оновлення або видалення даних, які можуть спричинити спрацювання тригера. Основна ідея полягає в тому, щоб просто протестувати БД поодинці ще до того, як буде виконано інтеграцію із зовнішнім інтерфейсом (UI).
Тестування чорної скриньки:
а) Починаючи з UI та БД тепер доступна інтеграція; ми можемо вставляти/видаляти/оновлювати дані із зовнішнього інтерфейсу таким чином, щоб викликався тригер. Після цього оператори Select можна використовувати для отримання даних БД, щоб побачити, чи тригер виконав намічену операцію.
б) Другий спосіб перевірити це – безпосередньо завантажити дані, які викличуть тригер, і подивитися, чи працює він так, як задумано.
4. Збережені процедури
Збережені процедури більш-менш схожі на функції користувача. Вони можуть бути викликані операторами виклику процедури/виконання процедури, а вихідні дані зазвичай представлені як набори результатів.
Вони зберігаються в СУБД та доступні для додатків.
Тестування білої скриньки: заглушки використовуються для виклику збережених процедур, а потім результати перевіряються на відповідність очікуваним значенням.
Тестування «чорної скриньки»: виконайте операцію із зовнішнього інтерфейсу (UI) програми і перевірте виконання процедури, що зберігається, і її результати.
5. Обмеження полів
Значення за замовчуванням, унікальне значення та зовнішній ключ (Default value, Unique value, and Foreign key):
Виконайте інтерфейсну операцію, яка перевіряє умову об'єкта бази даних.
Підтвердьте результати за допомогою запиту SQL.
Перевірити значення за промовчанням для певного поля досить просто. Це частина перевірки бізнес-правил. Ви можете зробити це вручну або використовувати такі інструменти, як QTP. Вручну ви можете виконати дію, яка додасть значення, відмінне від значення поля за замовчуванням, із зовнішнього інтерфейсу і подивитися, чи це не призведе до помилки.
Перевірка унікального значення може бути виконана так само, як ми робили це для значень за замовчуванням. Спробуйте ввести значення з інтерфейсу користувача, які порушуватимуть це правило, і подивіться, чи не з'явиться помилка.
Для перевірки обмеження зовнішнього ключа використовуйте завантаження даних, які безпосередньо вводять дані, що порушують обмеження, і перегляньте, чи обмежує їх додаток чи ні. Поряд із завантаженням даних із серверної частини виконуйте також операції інтерфейсу фронтенда таким чином, щоб порушити обмеження, і подивіться, чи відображається відповідна помилка.
Автоматизація
Автотести в БД зазвичай пишуться на процедури, що зберігаються, і джоби і схожі на автотести API, тільки транспортний рівень - драйвер БД, і додаються транзакції і роллбеки в тирдаун секції.
Джерела:
Дод. матеріал:
Last updated