Підручник з тестування бази даних (даних).

Члени команди тестування та розробки зазвичай приділяють найбільшу увагу графічному інтерфейсу користувача, оскільки графічний інтерфейс користувача є найпомітнішою частиною програми. Однак, що також важливо, так це перевірити інформацію, яка є серцевиною програми, так званої БАЗИ ДАНИХ.

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

1. Програма зберігає інформацію про транзакції в базі даних програми та правильно відображає її користувачеві.
2. Під час цього жодна інформація не втрачається.
3. Програма не зберігає інформацію про частково виконану або перервану операцію.
4. Жодна стороння особа не має доступу до інформації користувача.

Щоб забезпечити всі ці вищезазначені цілі, нам потрібно використовувати перевірку даних або тестування даних.

Відмінності між тестуванням інтерфейсу користувача та тестуванням даних

Тестування інтерфейсу користувача	Тестування бази даних або даних
Цей тип тестування також відомий як тестування графічного інтерфейсу користувача або фронт-енд тестування.	Цей тип тестування також відомий як бекенд-тестування або тестування даних.
Цей тип тестування в основному стосується всіх тестованих елементів, відкритих для перегляду та взаємодії, таких як форми, презентації, графіки, меню та звіти тощо (створені через VB, VB.net, VC++, Delphi – інтерфейсні інструменти)	Цей тип тестування в основному стосується всіх тестованих елементів, які зазвичай приховані від користувача для перегляду. До них належать внутрішні процеси та сховище Assembly, як СУБД Oracle, SQL Server, MYSQL тощо.
Цей тип тестування включає перевірку текстові поля виберіть спадні списки календарі та кнопки Навігація сторінкою відображення зображень Зовнішній вигляд програми в цілому	Цей тип тестування включає перевірку: схема таблиці бази даних стовпців ключі та індекси тригери збережених процедур перевірки сервера бази даних перевірка дублювання даних
Тестер повинен бути добре обізнаним щодо бізнес-вимог, а також використання інструментів розробки та використання фреймворків та інструментів автоматизації.	Щоб мати можливість виконувати бекенд-тестування, тестувальник повинен мати серйозний досвід роботи з сервером бази даних і концепціями мови структурованих запитів.

Типи тестування бази даних

Є 3 типи тестування бази даних

1. Структурне тестування
2. Функціональне тестування
3. Нефункціональне тестування

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

Що таке тестування схеми?

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

Давайте обговоримо найважливіші контрольні точки для тестування схеми.

1. Перевірка різних форматів схем, пов’язаних із базами даних. Часто формат відображення таблиці може бути несумісним із форматом відображення, присутнім на рівні інтерфейсу користувача програми.
2. Існує потреба у перевірці у випадку невідповідних таблиць/подання/стовпців.
3. Також необхідно перевірити, чи гетерогенні бази даних у середовищі узгоджуються із загальним відображенням програми.

Давайте також розглянемо деякі з цікавих інструментів тестування бази даних для перевірки схем бази даних.

• DBUnit, інтегрований з Ant, дуже підходить для тестування відображення.
• SQL Server дозволяє тестувальникам мати можливість перевіряти та запитувати схему бази даних шляхом написання простих запитів, а не через код.

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

Таблиця бази даних, Тестування стовпців

Давайте розглянемо різні перевірки для тестування бази даних і стовпців.

1. Чи відображення полів і стовпців бази даних у серверній частині сумісно з цими відображеннями у передній частині?
2. Перевірка довжини та правила іменування полів і стовпців бази даних відповідно до вимог.
3. Перевірка наявності будь-яких невикористаних/невідображених таблиць/стовпців бази даних.
4. Перевірка сумісності

• тип даних
• довжини поля

стовпців внутрішньої бази даних зі стовпцями, присутніми на інтерфейсі програми.

5. Чи дозволяють поля бази даних користувачеві вводити бажані користувачем дані відповідно до документів специфікації бізнес-вимог.

Тестування ключів та індексів

Важливі перевірки ключів та індексів –

1. Перевірте, чи потрібно

• Первинний ключ
• Зовнішній ключ

на необхідні таблиці створено обмеження.

2. Перевірте, чи дійсні посилання на зовнішні ключі.
3. Перевірте, чи збігаються тип даних первинного ключа та відповідних зовнішніх ключів у двох таблицях.
4. Перевірте, чи було дотримано необхідних правил іменування для всіх ключів та індексів.
5. Перевірте розмір і довжину необхідних полів та індексів.
6. Чи потрібно

• Clusterіндекси ред
• Чи не Clusterіндекси ред

були створені в необхідних таблицях, як визначено бізнес-вимогами.

Тестування збережених процедур

Важливими тестами для перевірки збережених процедур є:

1. Чи прийняла команда розробників необхідні: A) стандартні угоди кодування та B) обробку винятків і помилок. Для всіх збережених процедур для всіх модулів тестованої програми.
2. Чи команда розробників охопила всі умови/цикли, застосувавши необхідні вхідні дані до програми, що тестується?
3. Чи команда розробників належним чином застосовувала операцію TRIM щоразу, коли дані отримувалися з необхідних таблиць у базі даних?
4. Чи ручне виконання збереженої процедури забезпечує кінцевому користувачеві необхідний результат?
5. Чи ручне виконання збереженої процедури забезпечує оновлення полів таблиці відповідно до вимог програми, що тестується?
6. Чи дає змогу виконання збережених процедур неявний виклик необхідних тригерів?
7. Перевірка наявності будь-яких невикористаних збережених процедур.
8. Перевірка умови Allow Null, яку можна виконати на рівні бази даних.
9. Перевірка того факту, що всі збережені процедури та функції були успішно виконані, коли тестована база даних порожня.
10. Перевірка загальної інтеграції модулів збережених процедур відповідно до вимог програми, що тестується.

Деякі з корисних інструментів тестування бази даних для тестування збережених процедур: LINQ, інструмент SP Test тощо.

Тригерне ​​тестування

1. Чи були дотримані необхідні правила кодування під час фази кодування тригерів?
2. Перевірте, чи тригери, виконані для відповідних транзакцій DML, виконали необхідні умови.
3. Чи правильно тригер оновлює дані після їх виконання?
4. Перевірка необхідного оновлення/вставлення/видалення запускає функціональні можливості в області програми, що тестується.

Перевірки сервера баз даних

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

Тестування функціональної бази даних

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

Нижче наведено основні умови, яких необхідно дотримуватися для перевірки бази даних.

• Чи це поле є обов’язковим, але допускає значення NULL у цьому полі?
• Чи достатня довжина кожного поля?
• Чи всі подібні поля мають однакові імена в таблицях?
• Чи є в базі даних обчислювані поля?

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

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

Перевірка цілісності та узгодженості даних

Наступні перевірки важливі

1. Чи дані логічно добре організовані?
2. Чи дані, що зберігаються в таблицях, правильні та відповідають вимогам бізнесу?
3. Чи є непотрібні дані в тестованій програмі?
4. Чи дані зберігалися відповідно до вимог щодо даних, оновлених через інтерфейс користувача?
5. Чи виконувалися операції TRIM над даними перед вставленням даних у тестовану базу даних?
6. Чи транзакції були виконані відповідно до специфікацій бізнес-вимог і чи правильні результати?
7. Чи належним чином зафіксовано дані, якщо транзакцію було успішно виконано?
8. Чи було успішно відкочено дані, якщо транзакцію не було успішно виконано кінцевим користувачем?
9. Чи було зроблено відкат даних, якщо транзакцію не було виконано успішно та в транзакцію, про яку йдеться, було залучено кілька різнорідних баз даних?
10. Чи всі транзакції були виконані з використанням необхідних процедур проектування, як визначено системними бізнес-вимогами?

Вхід і безпека користувача

Під час перевірки логіна та облікових даних безпеки користувача необхідно враховувати наступне.

1. Чи заважає програма користувачеві продовжити роботу в програмі у випадку a

• недійсне ім'я користувача, але дійсний пароль
• дійсне ім'я користувача, але невірний пароль.
• неправильне ім'я користувача та пароль.

2. Чи дозволено користувачеві виконувати лише ті конкретні операції, які визначені бізнес-вимогами?
3. Чи захищені дані від несанкціонованого доступу?
4. Чи існують різні ролі користувачів, створені з різними дозволами?
5. Чи всі користувачі мають необхідні рівні доступу до вказаної бази даних відповідно до бізнес-специфікацій?
6. Переконайтеся, що конфіденційні дані, такі як паролі, номери кредитних карток, зашифровані та не зберігаються у базі даних у вигляді звичайного тексту. Рекомендується переконатися, що всі облікові записи мають складні паролі, які важко вгадати.

Нефункціональне тестування

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

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

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

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

Мета будь-якого випробування навантаженням має бути чітко зрозуміла та задокументована. Наступні типи конфігурацій є обов’язковими для тестування навантаження.

1. Транзакції користувача, які найчастіше використовуються, можуть вплинути на ефективність усіх інших транзакцій, якщо вони неефективні.
2. Принаймні одна транзакція користувача без можливості редагування повинна бути включена в остаточний набір тестів, щоб продуктивність таких транзакцій можна було відрізнити від інших більш складних транзакцій.
3. Слід включити більш важливі транзакції, які сприяють виконанню основних цілей системи, оскільки збій під навантаженням цих транзакцій має, за визначенням, найбільший вплив.
4. Слід включити принаймні одну трансакцію, яку можна редагувати продуктивністі таких операцій можна відмежувати від інших операцій.
5. Оптимальний час відгуку при величезній кількості віртуальних користувачів для всіх потенційних вимог.
6. Ефективний час для отримання різноманітних записів.

Важливими інструментами тестування навантаження є LoadRunner Professional, виграти бігун і JMeter.

Важливими інструментами стрес-тестування є LoadRunner Professional та JMeter.

Найчастіше виникають проблеми під час тестування бази даних

A significant amount of overhead could be involved to determine the state of the database transactions

Рішення: Загальне планування процесу та терміни повинні бути організовані таким чином, щоб не виникало проблем, пов’язаних із часом і витратами.

New test data have to be designed after cleaning up of the old test data.

Рішення: Має бути під рукою попередній план і методологія генерації тестових даних.

An SQL generator is required to transform SQL validators in order to ensure the SQL queries are apt for handling the required database test cases.

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

The above mentioned prerequisite ensure that the set-up of the database testing procedure could be costly as well as time consuming.

Рішення: Має бути баланс між якістю та загальною тривалістю графіка проекту.

Міфи або омани, пов’язані з тестуванням бази даних

Database Testing requires plenty of expertise and it is a very tedious job

реальність: Ефективне та результативне тестування бази даних у тестуванні програмного забезпечення забезпечує довгострокову функціональну стабільність загальної програми, тому необхідно докласти наполегливої ​​праці.

Database testing adds extra work bottleneck

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

Database testing slows down the overall development process

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

Database testing could be excessively costly

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

Кращі практики

• Усі дані, включаючи метадані, а також функціональні дані, необхідно перевірити відповідно до їх відображення в документах специфікації вимог.
• Перевірка дані тесту який було створено групою розробників / за консультацією з нею, необхідно перевірити.
• Перевірка вихідних даних за допомогою як ручних, так і автоматизованих процедур.
• Розгортання різних методів, таких як техніка побудови графіків причинно-наслідкових зв’язків, техніка розподілу еквівалентності та техніка аналізу граничних значень для створення необхідних умов тестових даних.
• Також необхідно перевірити правила перевірки посилальної цілісності для необхідних таблиць бази даних.
• Вибір значень таблиці за замовчуванням для перевірки узгодженості бази даних є дуже важливою концепцією. Чи були успішно додані події журналу в базу даних для всіх необхідних подій входу
• Чи виконуються заплановані завдання вчасно?
• Своєчасно створюйте резервні копії бази даних.

Також перевірте - Запитання та відповіді на співбесіді з тестування бази даних