Урок за тестване на бази данни

Тестването на бази данни — понякога наричано backend или тестване на данни — е това, което поддържа невидимата половина на всяко приложение честна. Този урок разглежда какво обхваща, защо е важно, трите основни категории тестване, често срещаните клопки и най-добрите практики, които отличават солидните пакети от тези с пропуски.

Какво е тестване на база данни?

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

Защо тестването на бази данни е важно?

Тестването на базата данни е от решаващо значение в тестване на софтуер защото потвърждава, че стойностите, съхранени в базата данни и извлечени от нея, са валидни. Силното тестване на базата данни предотвратява загуба на данни, ограничава прекратените транзакции и блокира неоторизиран достъп до информация. Тъй като базата данни е сърцето на всяко бизнес приложение, тестерите трябва да са умели да работят със SQL.

Повечето екипи се фокусират върху графичния потребителски интерфейс (GUI), защото той е най-видимата част от приложението. Информацията под GUI е също толкова важна и валидирането ѝ е задача на тестването на базата данни. Да разгледаме банково приложение, в което потребител извършва транзакции. От гледна точка на тестването на базата данни, трябва да са спазени следните инварианти:

1. Приложението съхранява всяка транзакция в базата данни и я показва правилно на потребителя.
2. По време на операцията не се губи никаква информация.
3. Не се запазват частично завършени или прекратени операции.
4. Никое неупълномощено лице няма достъп до информацията на потребителя.

Потвърждаването на всеки от тези инварианти е целта на валидирането на базата данни и тестването на данните.

Разлики между тестване на потребителски интерфейс и тестване на данни

Тестване на потребителски интерфейс	Тестване на база данни / данни
Известно още като тестване на графичен потребителски интерфейс (GUI) или front-end тестване.	Известно още като бекенд тестване или тестване на данни.
Отнася се за елементи, видими за потребителя и с които той взаимодейства — формуляри, презентации, графики, менюта и отчети (създадени с VB, VB.NET, VC++, Delphi и подобни инструменти за интерфейс).	Отнася се за елементи, скрити от потребителя — вътрешни процеси и хранилища, като например СУБД (Oracle, SQL сървър, MySQL).
Включва валидиране на текстови полета, падащи менюта, календари, бутони, навигация на страници, показване на изображения и цялостния външен вид.	Включва валидиране на схеми, таблици, колони, ключове и индекси, съхранени процедури, тригери и конфигурация на сървъра на базата данни.
Тестерът се нуждае от познания в бизнес областта, както и от познаване на инструменти за разработка и рамки за автоматизация.	Тестерът се нуждае от солиден опит в сървъри за бази данни и език за структурирани заявки (SQL).

Видове тестване на бази данни

Тестването на бази данни се разделя на три категории от най-високо ниво. Всяка от тях проверява различен слой от стека на базата данни.

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

Тестване на структурна база данни

Тестване на структурна база данни валидира елементите в хранилището за данни, които се използват за съхранение, но не се манипулират директно от крайните потребители. Валидирането на сървъри на бази данни е част от структурното тестване. Успешното изпълнение изисква силни SQL умения.

Какво е тестване на схема?

Тестване на схема валидира форматите на схемата, свързани с базата данни, и проверява дали картатаping от таблици, изгледи и колони съответства на картатаping очаквано от потребителския интерфейс. Целта е да се гарантира, че картата на схематаping между фронт-енда и бек-енда е последователно. Тестване на схемата се нарича още картаping тестване.

Ключови контролни точки за тестване на схемата:

1. Валидирайте всеки формат на схемата, свързан с базата данни. Картаping Форматите на ниво таблица често се различават от тези на ниво потребителски интерфейс.
2. Проверете наличието на несъпоставени таблици, изгледи или колони.
3. Проверете дали хетерогенните бази данни в средата остават съвместими с цялостната карта на приложениетоping.

Полезни инструменти за валидиране на схеми на бази данни:

• DBUnit интегриран с Ant — подходящ за картаping тестване.
• SQL Server позволява на тестерите да проверяват схемата, като пишат прости заявки вместо код.

Например, ако екипът за разработка промени или премахне таблица, тестерът потвърждава, че всяка съхранена процедура и изглед, препращащи към тази таблица, са съвместими с промяната. Друг пример: когато се сравняват разлики в схемите между две бази данни, прости заявки към системния каталог вършат работата бързо.

Таблица на база данни, тестване на колони

1. Проверете дали полетата и колоните на backend базата данни съответстват ясно на техните еквиваленти от frontend.
2. Валидирайте дължината и конвенциите за именуване на полетата и колоните на базата данни спрямо изискванията.
3. Открийте всички неизползвани или ненанесени таблици и колони.
4. Проверете дали типът данни и дължината на полетата на колоните от back-end системата са съвместими с полетата на формуляра от front-end системата.
5. Потвърдете, че полетата на базата данни приемат потребителските входни данни, изисквани от спецификацията на бизнес изискванията.

Тестване на ключове и индекси

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

Тестване на съхранени процедури

1. Уверете се, че екипът за разработка е спазил необходимите конвенции за кодиране, обработка на изключения и обработка на грешки за всяка съхранена процедура във всеки модул.
2. Проверете дали всички условия и цикли се изпълняват от входните данни, предоставени по време на тестването.
3. Уверете се, че операцията TRIM се прилага винаги, когато се извличат данни от необходимите таблици.
4. Ръчно изпълнете всяка съхранена процедура и проверете дали резултатът отговаря на очакванията.
5. Потвърдете, че ръчното изпълнение актуализира полетата на основната таблица, както се изисква от тестваното приложение.
6. Проверете дали изпълнението на съхранена процедура имплицитно извиква необходимите тригери.
7. Открийте всички неизползвани съхранени процедури.
8. Валидирайте поведението за NULL входни данни на ниво база данни.
9. Уверете се, че всяка съхранена процедура и функция се изпълнява успешно, когато тестваната база данни е празна.
10. Валидирайте цялостната интеграция на модулите за съхранени процедури спрямо изискванията на приложението.

Полезни инструменти за тестване на съхранени процедури включват LINQ и СП тест полезност.

Тестване на задействане

1. Проверете дали са спазени необходимите конвенции за кодиране по време на разработването на тригера.
2. Потвърдете, че това задейства задействането на предвидените DML транзакции и само на тях.
3. Проверете дали спусъкът актуализира данните правилно след задействане.
4. Валидирайте необходимата функционалност за задействане на актуализиране, вмъкване и изтриване в тестваното приложение.

Валидации на сървър на база данни

1. Проверете конфигурацията на сървъра на базата данни спрямо бизнес изискванията.
2. Проверете дали потребителят е оторизиран само за действията, които приложението позволява.
3. Проверете дали сървърът на базата данни може да обработи максималното едновременни потребителски транзакции, дефинирани в изискванията.

Функционално тестване на база данни

Функционално тестване на база данни валидира функционалните изисквания на базата данни от гледна точка на крайния потребител. Целта му е да потвърди, че транзакциите и операциите, задействани от крайния потребител, се държат според очакванията на ниво база данни.

Основни условия за проверка по време на валидиране на базата данни:

• Дали всяко поле е задължително или приема NULL стойности.
• Дали всяко поле предоставя достатъчна дължина за очакваните данни.
• Дали семантично сходните полета използват едно и също име в различните таблици.
• Дали в базата данни съществуват изчислени полета и какви формули се прилагат към тях.

Тази валидация се извършва в двете посоки. Тестерът извършва операция на ниво база данни и я проверява на потребителския интерфейс, след което извършва операция на потребителския интерфейс и я проверява на ниво база данни.

Проверка на целостта и последователността на данните

1. Проверете дали данните са логически организирани.
2. Уверете се, че съхранените данни отговарят на бизнес изискванията.
3. Открийте всички ненужни данни в тестваното приложение.
4. Проверете дали данните, актуализирани от потребителския интерфейс, се попълват правилно в базата данни.
5. Потвърдете TRIM операциите върху данните преди вмъкване.
6. Проверете дали всяка транзакция отговаря на бизнес спецификацията и води до очаквания резултат.
7. Потвърждавайте успешни комити, когато транзакциите завършат.
8. Потвърдете правилното връщане назад, когато транзакцията е неуспешна.
9. Потвърдете правилното връщане назад в транзакции, които обхващат хетерогенни бази данни.
10. Проверете дали всяка транзакция следва процедурите за проектиране, определени в системните изисквания.

Вход и сигурност на потребителите

1. Проверете дали приложението блокира опитите за влизане с: (а) невалидно потребителско име + валидна парола, (б) валидно потребителско име + невалидна парола и (в) невалидно потребителско име + невалидна парола.
2. Уверете се, че всеки потребител може да извършва само операциите, определени от неговата роля.
3. Проверете дали чувствителните данни са защитени от неоторизиран достъп.
4. Потвърдете, че съществуват отделни потребителски роли с отделни набори от разрешения.
5. Проверете дали всеки потребител има нивото на достъп, посочено в бизнес изискванията.
6. Уверете се, че чувствителните данни – пароли, номера на кредитни карти, лични идентификатори – са криптирани в покой и никога не се съхраняват като обикновен текст. Всички акаунти трябва да използват сложни, трудни за отгатване пароли.

Нефункционално тестване

Нефункционално тестване в контекста на базата данни обхваща тестване на товара, стрес тестове, тестване на сигурността, тестване на използваемостта, и тестване за съвместимостТестването под натоварване и стрес тестването — и двете форми на тестване на производителността — служат на две специфични цели:

• Количествено определяне на риска: Количественото определяне на риска помага на заинтересованите страни да установят времето за реакция на системата при определени нива на натоварване. Това е основната цел на всяко гарантиране на качеството усилие. Тестването на натоварване не намалява риска директно; по-скоро то го разкрива и създава тласък за отстраняване.
• Минимални хардуерни изисквания: Тестването на производителността идентифицира минималната инфраструктура, необходима за задоволяване на заявените очаквания за производителност, което позволява на екипите да избегнат прекомерното използване на хардуер и завишаването на разходите за собственост.

Тестване на товара

Целта на всеки тест за натоварване трябва да бъде ясно разбрана и документирана. Следните конфигурации са задължителни за тестване на товара:

1. Включете най-често изпълняваните потребителски транзакции, тъй като тяхното изпълнение влияе върху всяка друга транзакция.
2. Включете поне една транзакция, която не е свързана с редактиране, за да разграничите производителността на четене от производителността на запис.
3. Включете транзакциите, които са в основата на основната бизнес цел – неуспехите тук имат най-голямо въздействие.
4. Включете поне една транзакция за редактиране, за да разграничите производителността на запис от производителността на четене.
5. Измерете времето за реакция при максимално прогнозирано натоварване на виртуалния потребител.
6. Измерете латентността при извличане на записи в голям мащаб.

Често срещаните инструменти за тестване на натоварване включват LoadRunner Professional, WinRunner и Apache JMeter.

Какво е стрес тестване на база данни?

Стрес тестване на базата данни прилага голямо натоварване към базата данни, докато тя не се повреди. Това идентифицира точката на повреда на системата. Стрес тестването изисква внимателно планиране, за да се избегне изчерпване на ресурсите на споделената инфраструктура. Стрес тестването се нарича още тестване за мъчения or изпитване на умораВижте по-широкия урок за стрес тестване за фон. Често срещани инструменти включват LoadRunner Professional намлява JMeter.

Най-добрите инструменти за тестване на бази данни (2026 г.)

Подходящият инструмент зависи от това кой слой от стека на базата данни тествате. Таблицата по-долу съчетава често срещани категории с най-известните опции.

категория	Инструмент	Най-добър за
Тестване на единица	DBUnit, tSQLt	Повтаряеми схеми и тестове със съхранени процедури, интегрирани с Ant или конвейери за изграждане.
Натоварване и стрес	LoadRunner Professional, Apache JMeter	Симулация на виртуални потребители с голям обем спрямо работни натоварвания от производствен клас.
Сравнение на данни	Сравняване на данни в Redgate SQL, Apache DBUtils	Проверка дали две бази данни съдържат идентични данни след миграция или ETL.
Генериране на макетни данни	Мокару, Datatect	Създаване на реалистични тестови набори от данни, които зачитат референтната цялост.
Управление на схеми	Liquibase, Flyway	Миграции с контролирани версии и тестване за връщане към предишни версии в различни среди.
SQL редактор / ad-hoc валидиране	DBeaver, Azure Студио за данни, SSMS	Интерактивно създаване на заявки по време на проучвателно тестване на база данни.

Сдвоете поне един инструмент от категорията натоварване с един от категорията единици, за да покриете както риска от производителност, така и риска от регресия.

Най-често срещаните проблеми по време на тестване на база данни

Издаване	Препоръчително решение
Необходими са значителни режийни разходи за определяне на състоянието на транзакциите в базата данни.	Планирайте времето и зависимостите предварително, така че да не възникне неяснота относно състоянието на транзакцията по време на изпълнението.
Нови тестови данни трябва да бъдат проектирани след почистване на старите тестови данни.	Поддържайте документирана стратегия за генериране на тестови данни и процедура за обновяване преди всеки цикъл.
Необходим е SQL генератор, който да трансформира SQL валидаторите, така че заявките да съответстват на необходимите тестови случаи.	Отнасяйте се към поддръжката на SQL като към първокласна част от цялостната тестова стратегия, а не като ad-hoc работа.
Горните предпоставки могат да направят настройката скъпа и отнемаща време.	Балансирайте дълбочината на теста спрямо графика чрез разпределяне на покритието на нива: дълбока автоматизация за области с висок риск, леки проверки другаде.

Митове и погрешни схващания за тестването на бази данни

Мит	Реалност
Тестването на бази данни изисква задълбочени познания и е твърде досадно, за да бъде оправдано.	Ефективното тестване на базата данни осигурява дългосрочна функционална стабилност. Усилията се отплащат многократно чрез намаляване на реакцията при инциденти.
Тестването на базата данни създава допълнително затруднение в работата.	Той разкрива скрити дефекти рано и подобрява цялостното качество на приложението, премахвайки пречките, вместо да ги създава.
Тестването на базата данни забавя процеса на разработка.	Инвестициите в тестване на бази данни ускоряват разработката надолу по веригата, като откриват дефекти в схемата и целостта, преди те да се каскадират.
Тестването на бази данни е изключително скъпо.	База данни (и SQL) тестването е дългосрочна инвестиция в стабилността на приложението и предпазна мярка срещу скъпоструващи производствени повреди.

Най-добри практики

• Валидирайте всички данни — метаданни и функционални данни — спрямо спецификацията на изискванията, включително нейната картаping правила.
• Revвижте всеки набор от данни от теста произведен от или с екипа за разработка, преди да се разчита на него.
• Валидирайте изходните данни, използвайки както ръчни, така и автоматизирани процедури.
• Прилагайте графично изобразяване на причинно-следствена връзка, еквивалентно разделяне и анализ на гранични стойности при генериране на условия за тестови данни.
• Валидирайте правилата за референтна цялост в необходимите таблици на базата данни.
• Използвайте умишлени стойности по подразбиране, когато проверявате съгласуваността на базата данни, и потвърдете, че събитията в лога се записват за всяко необходимо събитие за влизане.
• Уверете се, че планираните задачи се изпълняват навреме и произвеждат очакваните резултати.
• Архивирайте базата данни по определен график и проверявайте пътя за възстановяване поне веднъж на тримесечие.

Вижте също — Въпроси и отговори за интервю за тестване на бази данни.

Въпроси и Отговори