У наші дні База Даних є однією з невід’ємних частин майже кожної програми. Не має значення чи це веб-додаток, десктопна програма, мобільний додаток, клієнт-серверна аплікація або якесь індивідуальне бізнес-ріщення. Механізм Бази Даних працює усюди на Backend -і. Однаково не має значення, яка це життєва сфера: охорона здоров’я, фінанси, навчання, торгівля, автоматизація email розсилок чи керування космічним кораблем.

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

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

Для кращого розуміння далі  ➡ продовжуємо передмову перед основною темою…

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

C: Create (Створити) — операція ‘Create’ виконується, коли користувач зберігає будь-яку нову інформацію у Базі Даних.
R: Retrieve (Отримати) — операція ‘Retrieve’ виконується, коли користувач виконує пошук або перегляд вже збереженої інформації.
U: Update (Обновити) — операція ‘Update’ виконується, коли користувач редагує або змінює існуючий запис.
D: Delete (Видалити) — операція ‘Delete’ виконується, коли користувач видаляє  запис із системи Бази Даних.

    Не має значення, яка База Даних та інструментарій використовується і яка операція попередньо виконувалася з Базою Даних (з’єднання, запит або збереження).

ФАКТ, усі операції з БД, виконувані користувачем, з користувацького інтерфейсу будь-якого додатку, є CRUD операціями.

Тестуючи Базу Даних тест-інженеру слід зосереджувати увагу на наступному:

Що перевіряти в тестуванні Бази Даних?

1) Відображення даних:

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

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

До ACID властивостей транзакцій БД відносяться “Aтомарність”, “Послідовність”, “Ізоляція” і “Надійність”.

DB Testing

  • Атомарність — означає, транзакція “проходить” або “не проходить”. Якщо одна частина транзакції не виконується, наступна, логічно пов’язана частина — не буде виконана теж. Одним словом це називається правило “все-або-ніщо”.
  • Послідовність — результат успішної транзакції у БД, повинен бути валідним.
  • Ізоляція — якщо існує декілька транзакцій у Базі Даних, і вони виконуються одразу, їх результат повинен бути таким самим, якщо б їх виконати у іншій послідовності і різні корисувачі.
  • Надійність — означає, що дані у Базі Даних не можуть бути змінені без відома користувача цієї БД після пророблення ним певної дії (COMMIT -у), як от під впливом зовнішніх чинників, аварія, “нема світла”, хакерська атака тощо.

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

3) Цілісність даних, інтегрованість даних:

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

Кілька прикладів для тест-кейсів, які перевірятимуть цілісність Бази Даних при її тестуванні:

  • Перевірка наявності усіх тригерів для оновлення записів у таблицях.
  • Перевірити наявність неправильних або невірних даних у основних стовпцях кожної таблиці.
  • Спробувати ввести неправильні дані в таблиці та спостерігати, чи виникає якийсь збій?
  • Перевірити, що станеться, якщо спробувати вставити нащадка перед перед даними із батьківської категорії (пооперуйте Primary & Foreign keys для цього)
  • Перевірити, чи виникла якась помилка, якщо Ви видалите запис, до якого посилаються дані з іншої таблиці.
  • Перевірити, чи репліковані сервери та бази даних синхронізовані.

4) Точність реалізації бізнес-вимог:

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

Тестовий процес Тестування Бази Даних

В цілому Тестування Бази Даних не відрізняється від будь-якого іншого виду тестування програмного забезпечення:

Крок # 1 Підготувати тестове середовище
Крок # 2 Виконати тест
Крок # 3 Перевірити результати тесту
Крок # 4 Перевірити очікувані результати
Крок # 5 Повідомити про результати зацікавлені сторони

Steps Data Base Testing

Описані вище пункти відповідали на запитання “Що тестувати у БД? …у якій послідовності?” А зараз ми поговоримо “Як саме тестувати Бази Даних?” 

Як тестувати Бази Даних?

1) Написання SQL запитів тестувальником самостійно:

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

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

    Цей варіант Тестування Бази Даних пасує означити навіть тестуванням її методом Тестування Білої Скриньки (White Box Testing), кому логічніше Сірої Скриньки (Grey Box Testing).

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

    Але, повторимося, повинні бути виконані дві вище описані передумови. У іншому випадку цей метод тестування БД не підходить Вам.

Найчастіше тестувальники використовують у своїй роботі такі SQL команди:

  • Синтаксису DDL: Data Definition language  CREATE, ALTER, RENAME, DROP, INDEX, FOREIGN KEY, PRIMARY KEY.
  • Синтаксису DML: Data Manipulation language використовується щоб змінні ADD, UPDATE, DELETE у записах.
  • Синтаксису DCL: Data control language  пов’язаний з доступом до даних та маніпуляцією даних, SELECT, UPDATE, INSERT, WHERE, from, AND, OR, NOT тощо.

Хо-хо, стандартний найуживаніший та найелементарніший SQL -запит:

SELECT * FROM (tablename) WHERE (condition)

Тестування Схеми Бази Даних (Database Schema):

  • Тестуючи схему Бази Даних, перевіряється перш за все, чи правильно організовані дані всередині таблиці.
  • Попередньо обов’язково потрібно ознайомитися з вимогами, згідно яких працює База Даних.  FOREIGN KEY, PRIMARY KEY повинні бути повністю індексовані для кращого пошуку. Дані та імена полів потрібно вчитися сортувати використовуючи для цього регулярні вирази.
  • Знати слід про поняття SQL Aliases та Wildcard тощо.

Більш детальніше з питанням, що таке База Даних, SQL саме, як розпочати навчання SQL? пронуємо у наших дописах:

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

     Наступний варіант Тестування Бази Даних тестувальником це Тестування Чорної Скриньки (Black Box Testing): виконання операцій з інтерфейсу програми та перевірка виконання збереженої процедури та її результатів. Як саме відбувається Тестування Бази Даних Black Box методом, мова йтиме далі.

2) Дослідження даних у таблицях:

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

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

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

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

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

4) Вибір правильних інструментів:

Згідно поставленого завдання потрібно підбирати правильний інструмент який би щонайкраще: зручно та швидко протестував Базу Даних програми.

     Тут “прикол” полягає в тому, що База Даних є не шматком коду, а є об’єктом, який зберігає свій стан. І якщо не використовувати спеціалізованого інструментарію для тестування Бази даних, після кожного тесту База Даних буде змінюватися.

    Можна використовувати механізм транзакції, суть: доки транзакція не завершена, завжди зміни можна відкотити до початку транзакції. Використовувати засоби міграції даних — переносити, переливати дані з однієї Бази Даних в іншу. Складну структуру Бази Даних розподіляти між командою: тестером, розробником аби вони могли працювати з БД одночасно. Введення контрольних даних. Проводити тести запасу даних Performance тестування навантаження і т.п.

     Ось кілька DB Tool, які сьогодні популярні на ринку, обійдемося без версій 😆 : MS-Access, MS SQL Server , SQL Server 2008 R2, Oracle 12c, Oracle Financial, MySQL, PostgreSQL, DB2 тощо.  Кожна з наведених БД має свої переваги та недоліки. Ці інструменти різняться за вартістю, надійністю, функціоналом та безпекою.

    Наприклад, програма з графічним інтерфейсом: SQL Server Data Tools (SSDT) допомагає в збірці, налагодженні, обслуговуванні і реструктуруванні баз даних. Дозволяє працювати як з проектом Бази Даних, так і безпосередньо з підключеним екземпляром Бази Даних (на власному майданчику або в хмарі). Схожа програма Management Studio SQL Server.

     До речі, тестування баз даних автоматизується Selenium Web Driver. Вбудований DataBase семплер є у Jmeter.

     Узагалі інструментів тестування баз даних багато, і який обрати, і як тестувати Базу Даних — залежатиме від конкретного проекту!

Підсумок:

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

    Найважливіший момент:

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

Related posts

Leave a Comment

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.