Урок за тестване на база данни (данни).
Какво е тестване на база данни?
Тестване на бази данни е вид софтуерно тестване, което проверява схемата, таблиците, тригерите и т.н. на тестваната база данни. Той също така проверява целостта и последователността на данните. Може да включва създаване на сложни заявки за натоварване/стрес тест на базата данни и проверка на нейната реакция.
Защо тестването на бази данни е важно?
Тестването на бази данни е важно in тестване на софтуер тъй като гарантира, че стойностите на данните и информацията, получени и съхранени в базата данни, са валидни или не. Тестването на базата данни помага да се спести загуба на данни, спестява данни за прекратени транзакции и предотвратява неоторизиран достъп до информацията. Базата данни е важна за всяко софтуерно приложение, следователно тестерите трябва да имат добри познания по SQL за тестване на бази данни.
GUI обикновено се набляга най-много от членовете на екипа за тестване и разработка, тъй като графичният потребителски интерфейс се оказва най-видимата част от приложението. Но това, което също е важно, е да се валидира информацията, която е сърцето на приложението, известна още като БАЗА ДАННИ.
Нека разгледаме банково приложение, в което потребител извършва транзакции. Сега от следната гледна точка на тестване на база данни или тестване на база данни, нещата са важни:
- Приложението съхранява информацията за транзакцията в базата данни на приложението и я показва правилно на потребителя.
- Никаква информация не се губи в процеса.
- Приложението не запазва информация за частично изпълнени или прекратени операции.
- Неупълномощено лице няма право на достъп до информацията на потребителя.
За да гарантираме всички тези цели по-горе, трябва да използваме валидиране на данни или тестване на данни.
Разлики между тестване на потребителски интерфейс и тестване на данни
Тестване на потребителския интерфейс | Тестване на база данни или данни |
---|---|
Този тип тестване е известен също като тестване на графичен потребителски интерфейс или тестване на предния край. | Този тип тестване е известен също като Backend тестване или тестване на данни. |
Този тип тестване основно се занимава с всички тествани елементи, които са отворени за потребителя за гледане и взаимодействие, като формуляри, презентации, графики, менюта и отчети и др. (създадени чрез VB, VB.net, VC++, Delphi – инструменти за преден край) | Този тип тестване се занимава главно с всички тествани елементи, които обикновено са скрити от потребителя за гледане. Те включват вътрешни процеси и съхранение като Assembly, като СУБД Oracle, SQL Server, MYSQL и др. |
Този тип тестване включва валидиране на
|
Този тип тестване включва валидиране на:
|
Тестерът трябва да е задълбочено запознат с бизнес изискванията, както и с използването на инструментите за разработка и използването на рамки и инструменти за автоматизация. | За да може да извършва бекенд тестване, тестерът трябва да има сериозен опит в сървъра на базата данни и концепциите на езика за структурирани заявки. |
Видове тестване на бази данни
Трите вида тестване на бази данни са
В този урок за тестване на бази данни ще разгледаме всеки тип и неговите подтипове един по един.
Тестване на структурна база данни
Тестване на структурна база данни е техника за тестване на база данни, която валидира всички елементи в хранилището на данни, които се използват главно за съхранение на данни и които не могат да бъдат директно манипулирани от крайните потребители. Валидирането на сървърите на бази данни също е важно съображение при тестването на структурни бази данни. Успешното завършване на това тестване изисква майсторство в SQL заявките.
Какво е тестване на схема?
Тестване на схема при тестване на база данни валидира различни формати на схеми, свързани с базата данни, и проверява дали форматите за картографиране на таблици/изгледи/колони са съвместими с форматите за картографиране на потребителския интерфейс. Основната цел на тестването на схемата е да се гарантира, че картографирането на схемата между предния и задния край е подобно. По този начин се нарича още тестване на картографиране.
Нека обсъдим най-важните контролни точки за тестване на схема.
- Валидиране на различните формати на схеми, свързани с базите данни. Много пъти форматът за картографиране на таблицата може да не е съвместим с формата за картографиране, присъстващ в нивото на потребителския интерфейс на приложението.
- Има нужда от проверка в случай на некартирани таблици/изгледи/колони.
- Също така е необходимо да се провери дали хетерогенните бази данни в една среда са в съответствие с цялостното картографиране на приложението.
Нека също да разгледаме някои от интересните инструменти за тестване на база данни за валидиране на схеми на база данни.
- DBUnit, който е интегриран с Ant, е много подходящ за тестване на картографиране.
- SQL Server позволява на тестерите да могат да проверяват и да правят запитвания към схемата на базата данни чрез писане на прости заявки, а не чрез код.
Например, ако разработчиците искат да променят структурата на таблица или да я изтрият, тестерът би искал да гарантира, че всички съхранени процедури и изгледи, които използват тази таблица, са съвместими с конкретната промяна. Друг пример може да бъде, че ако тестерите искат да проверят за промени в схемата между 2 бази данни, те могат да направят това с помощта на прости заявки.
Таблица на база данни, тестване на колони
Нека разгледаме различни проверки за база данни и тестване на колони.
- Дали картографирането на полетата и колоните на базата данни в бекенда е съвместимо с тези картографирания в предния край?
- Валидиране на дължината и конвенцията за именуване на полетата и колоните на базата данни, както е посочено от изискванията.
- Валидиране на наличието на всички неизползвани/некартирани таблици/колони на база данни.
- Валидиране на съвместимостта на
- тип данни
- дължини на полето
на колоните на задния край на базата данни с тези на присъстващите в предния край на приложението.
- Дали полетата на базата данни позволяват на потребителя да предостави желани потребителски данни, както се изисква от документите за спецификация на бизнес изискванията.
Тестване на ключове и индекси
Важни проверки за ключове и индекси –
- Проверете дали изискваното
- Първичен ключ
- Чужд ключ
са създадени ограничения върху необходимите таблици.
- Проверете дали референциите за външни ключове са валидни.
- Проверете дали типът данни на първичния ключ и съответните външни ключове са еднакви в двете таблици.
- Проверете дали необходимите конвенции за именуване са спазени за всички ключове и индекси.
- Проверете размера и дължината на задължителните полета и индекси.
- Независимо дали е необходимо
- Clusterизд индекси
- Non Clusterизд индекси
са създадени на необходимите таблици, както е посочено от бизнес изискванията.
Тестване на съхранени процедури
Важни тестове за проверка на запомнените процедури са:
- Дали екипът за разработка е възприел необходимите, A) стандартни конвенции за кодиране и B) обработка на изключения и грешки. За всички съхранени процедури за всички модули за тестваното приложение.
- Дали екипът за разработка е покрил всички условия/цикли, като е приложил необходимите входни данни към тестваното приложение?
- Дали екипът за разработка правилно е приложил операцията TRIM, когато се извличат данни от необходимите таблици в базата данни?
- Дали ръчното изпълнение на съхранената процедура предоставя на крайния потребител необходимия резултат?
- Дали ръчното изпълнение на съхранената процедура гарантира, че полетата на таблицата се актуализират според изискванията на тестваното приложение?
- Дали изпълнението на съхранените процедури позволява имплицитното извикване на необходимите тригери?
- Валидиране на наличието на всички неизползвани съхранени процедури.
- Валидиране за условие Allow Null, което може да се направи на ниво база данни.
- Валидиране на факта, че всички съхранени процедури и функции са били успешно изпълнени, когато базата данни, която се тества, е празна.
- Валидиране на цялостната интеграция на модулите за запомнени процедури според изискванията на тестваното приложение.
Някои от полезните инструменти за тестване на бази данни за тестване на съхранени процедури са LINQ, SP Test tool и т.н.
Тестване на задействане
- Дали необходимите конвенции за кодиране са били спазени по време на фазата на кодиране на тригерите?
- Проверете дали тригерите, изпълнени за съответните DML транзакции, са изпълнили необходимите условия.
- Дали тригерът актуализира данните правилно, след като са били изпълнени?
- Валидирането на необходимата актуализация/вмъкване/изтриване задейства функционалност в сферата на тестваното приложение.
Валидации на сървър на база данни
- Проверете конфигурациите на сървъра на базата данни, както е посочено от бизнес изискванията.
- Проверете упълномощаването на необходимия потребител да извършва само тези нива на действия, които се изискват от приложението.
- Проверете дали сървърът на базата данни е в състояние да се погрижи за нуждите на максималния разрешен брой потребителски транзакции, както е посочено от спецификациите на бизнес изискванията.
Функционално тестване на база данни
Функционално тестване на база данни е вид тестване на база данни, което се използва за валидиране на функционалните изисквания на база данни от гледна точка на крайния потребител. Основната цел на функционалното тестване на база данни е да се провери дали транзакциите и операциите, извършвани от крайните потребители, които са свързани с базата данни, работят според очакванията или не.
Следват основните условия, които трябва да се спазват за валидиране на база данни.
- Дали полето е задължително, докато позволява NULL стойности в това поле?
- Дали дължината на всяко поле е достатъчна?
- Дали всички подобни полета имат еднакви имена в таблиците?
- Дали има изчислени полета в базата данни?
Този конкретен процес е валидирането на картографирането на полето от гледна точка на крайния потребител. В този конкретен сценарий тестерът ще извърши операция на ниво база данни и след това ще премине към съответния елемент на потребителския интерфейс, за да наблюдава и потвърди дали правилните проверки на полето са извършени или не.
Обратното условие, при което първата операция се извършва от тестера в потребителския интерфейс, а след това същата се валидира от задната част, също трябва да бъде направено.
Проверка на целостта и последователността на данните
Следващите проверки са важни
- Дали данните са логически добре организирани?
- Дали данните, съхранявани в таблиците, са правилни и отговарят на бизнес изискванията?
- Дали в приложението, което се тества, има ненужни данни?
- Дали данните са били съхранени съгласно изискванията по отношение на данните, които са били актуализирани от потребителския интерфейс?
- Дали операциите TRIM са извършени върху данните преди вмъкването на данни в тестваната база данни?
- Дали транзакциите са извършени съгласно спецификациите на бизнес изискванията и дали резултатите са правилни или не?
- Дали данните са били правилно ангажирани, ако транзакцията е била успешно изпълнена?
- Дали данните са били върнати успешно, ако транзакцията не е била изпълнена успешно от крайния потребител?
- Дали данните са върнати назад, ако транзакцията не е била изпълнена успешно и във въпросната транзакция са участвали множество разнородни бази данни?
- Дали всички транзакции са изпълнени чрез използване на необходимите процедури за проектиране, както е посочено от системните бизнес изисквания?
Вход и сигурност на потребителите
Валидирането на данните за влизане и защитата на потребителя трябва да вземе предвид следните неща.
- Дали приложението пречи на потребителя да продължи по-нататък в приложението в случай на a
- невалидно потребителско име, но валидна парола
- валидно потребителско име, но невалидна парола.
- невалидно потребителско име и невалидна парола.
- Дали на потребителя е разрешено да извършва само онези специфични операции, които са определени от бизнес изискванията?
- Дали данните са защитени от неоторизиран достъп?
- Дали има различни потребителски роли, създадени с различни разрешения?
- Дали всички потребители имат необходими нива на достъп до определената база данни, както се изисква от бизнес спецификациите?
- Проверете дали чувствителните данни като пароли, номера на кредитни карти са криптирани и не се съхраняват като обикновен текст в базата данни. Добра практика е да се гарантира, че всички акаунти имат пароли, които са сложни и не се отгатват лесно.
Нефункционално тестване
Нефункционално тестване в контекста на тестването на бази данни може да се категоризира в различни категории според изискванията на бизнеса. Те могат да бъдат тестване на натоварване, стрес тестване, Тестване на сигурността, Тестване за ползваемост, и Тест за съвместимост, и така нататък. Тестовете за натоварване, както и стрес тестовете, които могат да бъдат групирани в гамата от тестване на производителността, служат на две специфични цели, когато става въпрос за ролята на нефункционалното тестване.
Количествено определяне на риска– Количественото определяне на риска помага на заинтересованите страни да установят различните изисквания за време за реакция на системата при изискваните нива на натоварване. Това е първоначалното намерение на всеки гарантиране на качеството задача. Трябва да отбележим, че тестването на натоварването не намалява директно риска, но чрез процесите на идентифициране на риска и количествено определяне на риска, представя коригиращи възможности и импулс за коригиране, което ще смекчи риска.
Минимално изискване за системно оборудване– Минималната системна конфигурация, която ще позволи на системата да отговори на официално заявените очаквания за ефективност на заинтересованите страни. Така че външният хардуер, софтуер и свързаните с тях разходи за притежание могат да бъдат сведени до минимум. Това конкретно изискване може да се категоризира като цялостно изискване за оптимизация на бизнеса.
Тестване на товара
Целта на всеки тест за натоварване трябва да бъде ясно разбрана и документирана. Следните типове конфигурации са задължителни за тестване на товара.
- Най-често използваните потребителски транзакции имат потенциала да повлияят на ефективността на всички останали транзакции, ако не са ефективни.
- Поне една потребителска транзакция без редактиране трябва да бъде включена в окончателния тестов пакет, така че изпълнението на такива транзакции да може да се разграничи от други по-сложни транзакции.
- Трябва да се включат по-важните транзакции, които улесняват основните цели на системата, тъй като неуспехът при натоварване на тези транзакции има по дефиниция най-голямо въздействие.
- Трябва да бъде включена поне една редактируема транзакция, така че пърформанс такива сделки могат да бъдат разграничени от други сделки.
- Оптимално време за реакция при огромен брой виртуални потребители за всички бъдещи изисквания.
- Ефективни времена за извличане на различни записи.
Важни инструменти за тестване на натоварването са LoadRunner Professional, win runner и 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
Reality: Ефективното и ефикасно тестване на бази данни в софтуерното тестване осигурява дългосрочна функционална стабилност на цялостното приложение, поради което е необходимо да се вложи упорита работа зад него.
Database testing adds extra work bottleneck
Reality: Напротив, тестването на бази данни добавя повече стойност към цялостната работа, като открива скрити проблеми и по този начин проактивно помага за подобряване на цялостното приложение.
Database testing slows down the overall development process
Reality: Значителното количество тестване на база данни помага за цялостното подобряване на качеството на приложението за база данни.
Database testing could be excessively costly
Reality: Всеки разход за тестване на база данни е дългосрочна инвестиция, която води до дългосрочна стабилност и устойчивост на приложението. По този начин разходите за тестване на база данни или SQL Тестването е необходимо.
Най-добри практики
- Всички данни, включително метаданните, както и функционалните данни, трябва да бъдат валидирани в съответствие с картографирането им от документите за спецификация на изискванията.
- Проверка на данни от теста който е създаден от / след консултация с екипа за разработка, трябва да бъде валидиран.
- Валидиране на изходните данни чрез използване както на ръчни, така и на автоматизирани процедури.
- Разгръщане на различни техники, като техника за графично изобразяване на причинно-следствени последици, техника за разделяне на еквивалентност и техника за анализ на гранични стойности за генериране на изискваните условия за тестови данни.
- Правилата за валидиране на референтната цялост за необходимите таблици на базата данни също трябва да бъдат валидирани.
- Изборът на стойности на таблицата по подразбиране за валидиране на последователността на базата данни е много важна концепция Дали регистрационните събития са били успешно добавени в базата данни за всички необходими събития за влизане
- Насрочените задачи изпълняват ли се навреме?
- Направете своевременно архивиране на базата данни.
Също така проверете- Въпроси и отговори за интервю за тестване на бази данни