database testing complete guide why
Повне керівництво з тестування баз даних з практичними порадами та прикладами:
Комп’ютерні програми сьогодні складніші з такими технологіями, як Android, а також з багатьма програмами для смартфонів. Чим складніше передні кінці, тим складнішими стають задні кінці.
Тому набагато важливіше дізнатись про тестування БД і мати можливість ефективно перевіряти бази даних для забезпечення безпеки та якості баз даних.
У цьому підручнику ви дізнаєтеся все про тестування даних - чому, як і що тестувати?
База даних є однією з неминучих частин Програмного Застосування.
Не має значення, Інтернет, настільний чи мобільний, клієнт-сервер, рівний-рівний, корпоративний чи індивідуальний бізнес; база даних потрібна скрізь у серверній системі.
Подібним чином, будь то програма охорони здоров’я, фінансів, лізингу, роздрібної торгівлі, поштової розсилки чи управління космічним кораблем; база даних завжди діє за кадром.
Зі збільшенням складності програми виникає потреба в більш надійній та безпечній базі даних. Так само для додатків з високою частотою транзакцій ( Наприклад, Банківська справа або Фінанси), пов'язана необхідність повнофункціонального інструмента баз даних.
У наш час ми маємо великі та великі дані, які традиційні бази даних не можуть з ними обробляти.
Їх декілька Інструменти бази даних доступні на ринку Наприклад, MS-Access, MS SQL Server, SQL Server, Oracle, Oracle Financial, MySQL, PostgreSQL, DB2, Toad, Admirer тощо. Ці інструменти відрізняються за вартістю, надійністю, функціональними можливостями та безпекою. Кожен з них має свої переваги та недоліки.
Що ви дізнаєтесь:
- Навіщо тестувати базу даних?
- Що тестувати (контрольний список тестування баз даних)
- Як протестувати базу даних (покроковий процес)
Навіщо тестувати базу даних?
Нижче ми побачимо, чому слід перевіряти такі аспекти БД:
# 1) Картування даних
У програмних системах дані часто переміщуються туди-сюди від інтерфейсу користувача (інтерфейсу користувача) до внутрішньої бази даних і навпаки. Ось деякі аспекти, на які слід звернути увагу:
- Перевірте, чи поля у формах інтерфейсу користувача / інтерфейсу співпадають з відповідними полями в таблиці БД. Зазвичай ця картографічна інформація визначається в документах вимог.
- Кожного разу, коли певна дія виконується на передньому кінці програми, відповідне дію CRUD (Створити, Отримати, Оновити та Видалити) викликається на задньому кінці. Тестувальнику доведеться перевірити, чи викликана правильна дія та чи є ця сама по собі успішною чи ні.
# 2) Перевірка властивостей кислоти
Атомність, послідовність, ізоляція та довговічність. Кожна транзакція, яку виконує БД, повинна дотримуватися цих чотирьох властивостей.
- Атомність означає, що транзакція або провалюється, або проходить. Це означає, що навіть якщо одна частина транзакції зазнає невдачі, це означає, що вся транзакція зазнала невдачі. Зазвичай це називається правилом 'все або нічого'.
- Послідовність : Транзакція завжди призведе до дійсного стану БД
- Ізоляція : Якщо є кілька транзакцій, і вони виконуються всі одночасно, результат / стан БД повинні бути однаковими, як якщо б вони виконувались одна за одною.
- Довговічність : Після того, як транзакція буде виконана та здійснена, ніякі зовнішні фактори, такі як втрата потужності або збій, не зможуть її змінити
Пропоноване читання = >> Підручник з транзакцій MySQL
# 3) Цілісність даних
Для будь-якого з Операції CRUD , оновлені та найновіші значення / статус спільних даних повинні відображатися на всіх формах та екранах. Значення не слід оновлювати на одному екрані, а на іншому відображати старіше значення.
Коли заявка знаходиться у виконанні, кінцевий користувач в основному використовує операції «CRUD», що сприяють інструменту DB .
C: Створити - Коли користувач «Зберегти» будь-яку нову транзакцію, виконується операція «Створити».
R: Отримати - Коли користувач 'Шукає' або 'Переглядає' будь-яку збережену транзакцію, виконується операція 'Отримати'.
U: Оновлення - Коли користувач «Редагувати» або «Змінити» наявний запис, виконується операція «Оновлення» БД.
D: Видалити - Коли користувач «Видаляє» будь-який запис із системи, виконується операція «Видалити» БД.
Будь-яка операція з базою даних, виконувана кінцевим користувачем, завжди є однією з чотирьох вищезазначених.
Тож розробіть свої тестові кейси БД таким чином, щоб вони включали перевірку даних у всіх місцях, які, як видається, на предмет того, чи вони постійно однакові.
# 4) Відповідність діловим правилам
Більша складність в базах даних означає складніші компоненти, такі як реляційні обмеження, тригери, збережені процедури тощо. Тож тестувальникам доведеться розробити відповідні запити SQL для перевірки цих складних об'єктів.
Що тестувати (контрольний список тестування баз даних)
# 1) Операції
Під час тестування транзакцій важливо переконатися, що вони відповідають властивостям кислоти.
Ось такі твердження, які зазвичай використовуються:
- ПОЧАТИ ОПЕРАЦІЮ ОПЕРАЦІЯ №
- ЗАКІНЧИТИ ОПЕРАЦІЮ
Заява про відкат гарантує, що база даних залишається у стабільному стані.
- ОПЕРАЦІЙНА ОПЕРАЦІЯ №
Після того, як ці оператори будуть виконані, скористайтесь клавішею «Вибір», щоб переконатися, що зміни були відображені.
- ВИБЕРІТЬ * З ТАБЛЕНИ
# 2) Схеми баз даних
Схема баз даних - це не що інше, як формальне визначення того, як дані будуть організовані всередині БД. Щоб перевірити це:
- Визначте вимоги, на основі яких працює База даних. Вимоги до зразка:
- Первинні ключі, які слід створити до створення будь-яких інших полів.
- Зовнішні ключі повинні бути повністю проіндексовані для зручного пошуку та пошуку.
- Назви полів, що починаються або закінчуються певними символами.
- Поля з обмеженням, що певні значення можна або не можна вставити.
- Використовуйте один із наступних методів відповідно до відповідності:
- SQL-запит DESC
для перевірки схеми.
- Регулярні вирази для перевірки імен окремих полів та їх значень
- Такі інструменти, як SchemaCrawler
# 3) Тригери
Коли певна подія відбувається за певною таблицею, фрагмент коду (тригер) може бути автоматично доручений виконанню.
Наприклад, до школи приєднався новий учень. Студент проходить 2 заняття: математику та природничі науки. Студент додається до «студентського столу». Тригер може додати студента до відповідних таблиць предметів, як тільки він буде доданий до таблиці студентів.
Найпоширеніший метод тестування - спочатку самостійно виконати SQL-запит, вбудований у тригер, і записати результат. Далі слід виконати тригер у цілому. Порівняйте результати.
Вони тестуються як на етапах тестування Black-box, так і White-box.
запитання інтерв'ю веб-служб у Java
- Тестування білої скриньки : Заглушки та драйвери використовуються для вставки, оновлення або видалення даних, що призведе до виклику тригера. Основна ідея полягає в тому, щоб просто протестувати БД окремо ще до того, як буде здійснено інтеграцію з інтерфейсом.
- Тестування чорної скриньки :
до) З моменту користувальницького інтерфейсу та БД тепер доступна інтеграція; ми можемо вставляти / видаляти / оновлювати дані з інтерфейсу таким чином, щоб викликався тригер. Після цього оператори Select можуть бути використані для отримання даних БД, щоб побачити, чи тригер успішно виконав задуману операцію.
б) Другий спосіб перевірити це - безпосередньо завантажити дані, які викликали б тригер, і перевірити, чи працює він належним чином.
# 4) Зберігаються процедури
Збережені процедури більш-менш схожі на визначені користувачем функції. Їх можна викликати за допомогою операторів виклику / виконання процедури, і вихід, як правило, має форму наборів результатів.
Вони зберігаються в СУБД і доступні для додатків.
Вони також перевіряються під час:
- Тестування білої скриньки: Заглушки використовуються для виклику збережених процедур, а потім результати перевіряються відповідно до очікуваних значень.
- Тестування чорної скриньки: Виконайте операцію з інтерфейсу додатка та перевірте виконання збереженої процедури та її результатів.
# 5) Польові обмеження
Значення за замовчуванням, Унікальне значення та Зовнішній ключ:
- Виконайте інтерфейсну операцію, яка здійснює стан об'єкта Бази даних
- Перевірте результати за допомогою SQL-запиту.
Перевірити значення за замовчуванням для певного поля досить просто. Це частина перевірки ділових правил. Ви можете зробити це вручну або скористатися такими інструментами, як QTP. Вручну ви можете виконати дію, яка додасть значення, крім значення за замовчуванням поля, з переднього кінця та перевірить, чи не спричинить це помилку.
Нижче наведено зразок коду VBScript:
Function VBScriptRegularexpressionvlaidation(pattern , string_to_match) Set newregexp = new RegExp newregexp.Pattern = “” newregexp.Ignorecase = True newregexp.Global = True VBScriptRegularexpressionvlaidation = newregexp.Test(string_to_match) End Function Msgbox VBScriptRegularexpressionvlaidation(pattern , string_to_match) Результатом наведеного вище коду є True, якщо значення за замовчуванням існує, або False, якщо цього немає.
Перевірку унікального значення можна зробити точно так само, як це було для значень за замовчуванням. Спробуйте ввести значення з інтерфейсу, які порушать це правило, і подивіться, чи відображається помилка.
Код сценарію автоматизації VB може бути:
Function VBScriptRegularexpressionvlaidation(pattern , string_to_match) Set newregexp = new RegExp newregexp.Pattern = “” newregexp.Ignorecase = True newregexp.Global = True VBScriptRegularexpressionvlaidation = newregexp.Test(string_to_match) End Function Msgbox VBScriptRegularexpressionvlaidation(pattern , string_to_match) ДляЗовнішній ключперевірка обмежень використовує навантаження даних, які безпосередньо вводять дані, що порушують обмеження, і перевіряють, обмежує їх програма чи ні. Разом із внутрішнім завантаженням даних виконуйте також операції з інтерфейсом інтерфейсу таким чином, щоб порушувати обмеження та перевіряти, чи відображається відповідна помилка.
Діяльність з перевірки даних
Тестер бази даних повинен зосередитись на наступних тестових заходах:
# 1) Переконайтеся, що картографування даних:
Зіставлення даних - один із ключових аспектів бази даних, і його слід ретельно перевіряти кожним тестувальником програмного забезпечення.
Переконайтеся, що відображення між різними формами або екранами AUT та його БД є не тільки точним, але і відповідно до проектних документів (SRS / BRS) або коду. По суті, вам потрібно перевірити відображення між кожним інтерфейсним полем з відповідним полем бази даних бекенда.
Для всіх операцій CRUD переконайтеся, що відповідні таблиці та записи оновлюються, коли користувач натискає «Зберегти», «Оновити», «Пошук» або «Видалити» з графічного інтерфейсу програми.
Що потрібно перевірити:
- Табличне відображення, відображення стовпців та відображення типів даних.
- Пошук картографічних даних.
- Правильна операція CRUD викликається для кожної дії користувача в UI.
- Операція CRUD успішно виконана.
# 2) Переконайтеся, що кислотні властивості транзакцій:
Властивості ACID транзакцій БД посилаються на ДО Tomicity ', ‘ C. наполегливість ',' Я заспокоєння 'та „ D зручність ’. Правильне тестування цих чотирьох властивостей повинно проводитися під час перевірки бази даних. Вам потрібно переконатися, що кожна окрема транзакція відповідає властивостям ACID бази даних.
Візьмемо простий приклад наведеного нижче коду SQL:
CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));Тестова таблиця ACID матиме два стовпці - A & B. Існує обмеження цілісності, згідно з яким сума значень в A і B завжди повинна бути 100.
Тест на атомність забезпечить, що будь-яка транзакція, виконана за цією таблицею, є всією або жодною, тобто жодні записи не оновлюються, якщо будь-який крок транзакції не вдався.
Перевірка консистенції гарантуватиме, що щоразу, коли значення в стовпці A або B оновлюється, сума завжди залишається 100. Це не дозволить вставляти / видаляти / оновлювати в A або B, якщо загальна сума не відрізняється від 100.
Ізоляційний тест забезпечить, що якщо дві транзакції відбуваються одночасно і намагаються змінити дані тестової таблиці ACID, то ці тяги виконуються ізольовано.
Випробування на міцність забезпечить, що як тільки транзакція над цією таблицею буде здійснена, вона залишиться такою, навіть у випадку втрати живлення, збоїв або помилок.
Ця область вимагає більш ретельного, ретельного та пильного тестування, якщо ваша програма використовує розподілену базу даних.
# 3) Забезпечте цілісність даних
Враховуйте, що різні модулі (тобто екрани або форми) програми використовують однакові дані по-різному і виконують усі CRUD-операції з даними.
У такому випадку переконайтеся, що найновіший стан даних відображається скрізь. Система повинна відображати оновлені та найновіші значення або статус таких спільних даних у всіх формах та на екранах. Це називається цілісністю даних.
Тестові випадки для перевірки цілісності даних бази даних:
- Перевірте, чи всі тригери на місці, щоб оновити записи довідкової таблиці.
- Перевірте, чи є в основних стовпцях кожної таблиці якісь неправильні / недійсні дані.
- Спробуйте вставити неправильні дані в таблиці та спостерігайте, чи трапляється якась помилка.
- Перевірте, що трапиться, якщо ви спробуєте вставити дитину перед тим, як вставити її батька (спробуйте пограти з основними та зовнішніми клавішами).
- Перевірте, чи не сталася помилка, якщо видалити запис, на який все ще посилаються дані в будь-якій іншій таблиці.
- Перевірте, чи реплікуються сервери та бази даних синхронізовані.
# 4) Забезпечте точність запроваджених правил ведення бізнесу:
Сьогодні бази даних призначені не лише для зберігання записів. Насправді Бази даних перетворилися на надзвичайно потужні інструменти, які надають розробникам широку підтримку для реалізації бізнес-логіки на рівні БД.
Деякі прості приклади потужних функцій - це „Референтна цілісність”, реляційні обмеження, тригери та збережені процедури.
Отже, використовуючи ці та багато інших функцій, пропонованих БД, розробники реалізують бізнес-логіку на рівні БД. Тестувальник повинен переконатися, що реалізована бізнес-логіка правильна і працює точно.
Вищевикладені пункти описують чотири найважливіші «Що робити» тестування БД. Тепер перейдемо до частини 'Як це зробити'.
Як протестувати базу даних (покроковий процес)
Загальна база даних тестування процесу тестування не сильно відрізняється від будь-якої іншої програми.
Нижче наведено основні кроки:
Крок 1) Підготуйте середовище
Крок No2) Запустіть тест
Крок No3) Перевірте результат тесту
Крок No4) Підтвердити відповідно до очікуваних результатів
Крок No5) Повідомте висновки відповідним зацікавленим сторонам
Зазвичай для розробки тестів використовують SQL-запити. Найчастіше використовується команда «Вибрати».
Виберіть * звідки
Крім Select, SQL має 3 важливі типи команд:
- DDL: мова визначення даних
- DML: мова обробки даних
- DCL: мова керування даними
Давайте побачимо синтаксис найбільш часто використовуваних тверджень.
Мова визначення даних Використовує CREATE, ALTER, RENAME, DROP і TRUNCATE для обробки таблиць (та індексів).
Мова маніпулювання даними Включає оператори для додавання, оновлення та видалення записів.
Мова управління даними: Має справу з наданням дозволу користувачам на маніпуляції та доступ до даних. Grant та Revoke - два вживані твердження.
Синтаксис надання:
Надайте вибір / оновлення
Увімкнено
До;Відкликати синтаксис:
Скасувати вибір / оновлення
на
від;Деякі практичні поради
# 1) Пишіть запити самостійно:
Для точного тестування бази даних тестувальник повинен добре знати твердження SQL та DML (мова маніпуляції даними). Тестер також повинен знати внутрішню структуру БД AUT.
Ви можете поєднати графічний інтерфейс та перевірку даних у відповідних таблицях для кращого охоплення. Якщо ви використовуєте SQL-сервер, тоді ви можете використовувати SQL Query Analyzer для написання запитів, їх виконання та отримання результатів.
Це найкращий і надійний спосіб тестування бази даних, коли додаток має невеликий або середній рівень складності.
Якщо програма дуже складна, тестеру може бути важко або неможливо написати всі необхідні запити SQL. Для складних запитів вам потрібна допомога розробника. Я завжди рекомендую цей метод, оскільки він дає вам впевненість у тестуванні, а також покращує ваші навички SQL.
# 2) Дотримуйтесь даних кожної таблиці:
Ви можете виконати перевірку даних, використовуючи результати операцій CRUD. Це можна зробити вручну, використовуючи інтерфейс програми, коли ви знаєте інтеграцію бази даних. Але це може бути нудним і громіздким завданням, коли в різних таблицях баз даних є величезні дані.
Для ручного тестування даних тестер бази даних повинен добре знати структуру таблиці бази даних.
# 3) Отримати запити від розробників:
Це найпростіший спосіб перевірки бази даних. Виконайте будь-яку операцію CRUD із графічного інтерфейсу та перевірте її вплив, виконавши відповідні запити SQL, отримані від розробника. Це не вимагає ні знання SQL, ні знань про структуру БД програми.
Але цим методом потрібно користуватися обережно. Що робити, якщо запит, наданий розробником, є семантично помилковим або не відповідає вимозі користувача правильно? Процес просто не зможе перевірити дані.
# 4) Скористайтеся засобами тестування автоматизації баз даних:
Існує кілька інструментів, доступних для процесу перевірки даних. Ви повинні вибрати правильний інструмент відповідно до своїх потреб і використати його якнайкраще.
=> Ось список ТОП-засобів тестування БД, які слід перевірити
Висновок
З урахуванням усіх цих функцій, факторів та процесів для тестування на базі даних, зростає попит на тестувальників щодо технічного володіння ключовими концепціями бази даних. Незважаючи на деякі негативні переконання, що тестування бази даних створює нові вузькі місця та багато додаткових витрат - це сфера тестування, яка привертає значну увагу та попит.
Пропоноване читання = >> Що таке тестування безпеки баз даних
Сподіваюсь, цей посібник допоміг зосередитись на тому, чому це так, а також надав вам основні подробиці того, що стосується тестування бази даних.
Будь ласка, повідомте нам свої відгуки, а також поділіться своїм особистим досвідом, якщо ви працюєте над тестуванням БД.
Рекомендована література
- Тестування баз даних за допомогою JMeter
- 40+ найкращих засобів тестування баз даних - Популярні рішення для тестування даних
- Простий підхід до тестування баз даних XML
- Підручник з тестування сховища даних ETL (повний посібник)
- Підручник з тестування міграції даних: Повне керівництво
- 10 найкращих інструментів проектування баз даних для побудови складних моделей даних
- Підручник з тестування сховища даних із прикладами | Посібник з тестування ETL
- Як перевірити базу даних Oracle
^
- SQL-запит DESC
