Меню

Пълно ръководство за тестване на база данни (Защо, какво и как да тестваме данни)

database testing complete guide why

Опитайте Нашия Инструмент За Премахване На Проблемите

Пълно ръководство за тестване на база данни с практически съвети и примери:

В наши дни компютърните приложения са по-сложни с технологии като Android, а също и с много приложения за смартфони. Колкото по-сложни са предните краища, толкова по-сложни стават задните краища.

Затова е още по-важно да научите повече за тестването на DB и да можете да проверявате ефективно базите данни, за да осигурите сигурност и качество на базите данни.

В този урок ще научите всичко за тестването на данни - защо, как и какво да тествате?

Ръководство за тестване на база данни

Базата данни е една от неизбежните части на софтуерно приложение.

Няма значение дали е уеб, настолен или мобилен, клиент-сървър, peer-to-peer, предприятие или индивидуален бизнес; базата данни се изисква навсякъде в бекенда.

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

С увеличаването на сложността на приложението възниква необходимостта от по-силна и сигурна база данни. По същия начин, за приложения с висока честота на транзакции ( Например, Приложението за банкиране или финанси) се съчетава необходимостта от пълнофункционален DB Tool.

В днешно време имаме големи и сложни данни, които традиционните бази данни не могат да обработят.

Има няколко Инструменти за бази данни се предлагат на пазара Например, MS-Access, MS SQL Server, SQL Server, Oracle, Oracle Financial, MySQL, PostgreSQL, DB2, Toad, Admirer и др. Тези инструменти се различават по цена, стабилност, характеристики и сигурност. Всеки от тях има свои собствени предимства и недостатъци.

Какво ще научите:

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

По-долу ще видим защо следва да бъдат валидирани следните аспекти на DB:

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

# 1) Картографиране на данни

В софтуерните системи данните често се придвижват напред-назад от потребителския интерфейс (потребителски интерфейс) до вътрешната DB и обратно. Ето някои аспекти, които трябва да се следят:

  • Проверете дали полетата във формулярите за потребителски интерфейс / интерфейс са картографирани в съответствие със съответните полета в таблицата на DB. Обикновено тази информация за картографиране се дефинира в документите за изисквания.
  • Винаги, когато се извърши определено действие в предния край на приложение, съответното действие CRUD (Създаване, извличане, актуализиране и изтриване) се извиква в задния край. Тестерът ще трябва да провери дали правилното действие е извикано и дали самото извикано действие е успешно или не.

# 2) Проверка на свойствата на ACID

Атомност, последователност, изолация и трайност. Всяка транзакция, която DB извършва, трябва да се придържа към тези четири свойства.

DB ACID свойства

  • Атомност означава, че транзакцията се проваля или преминава. Това означава, че дори ако една част от транзакцията се провали - това означава, че цялата транзакция е неуспешна. Обикновено това се нарича правило „всичко или нищо“.
  • Последователност : Транзакцията винаги ще доведе до валидно състояние на DB
  • Изолация : Ако има множество транзакции и те се изпълняват наведнъж, резултатът / състоянието на DB трябва да бъде същото, както ако те се изпълняват една след друга.
  • Трайност : След като транзакцията бъде извършена и извършена, никакви външни фактори като загуба на енергия или срив не трябва да могат да я променят

Предложено четене = >> Урок за транзакции на MySQL

# 3) Целостта на данните

За всеки от CRUD операции , актуализираните и най-новите стойности / състояние на споделените данни трябва да се показват на всички формуляри и екрани. Стойността не трябва да се актуализира на един екран и да показва по-стара стойност на друг.

Когато приложението е в изпълнение, крайният потребител използва главно операциите „CRUD“, улеснени от DB Tool .

C: Създаване - Когато потребителят ‘Запази’ всяка нова транзакция, се извършва операция ‘Създаване’.
R: Извличане - Когато потребителят ‘Търсене’ или ‘Преглед’ всяка запазена транзакция, се извършва операция ‘Извличане’.
U: Актуализация - Когато потребителят ‘Edit’ или ‘Modify’ съществуващ запис, се извършва операцията ‘Update’ на DB.
D: Изтриване - Когато потребител ‘премахне’ който и да е запис от системата, се извършва операция ‘Изтриване’ на DB.

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

Така че разработете вашите DB тестови случаи по начин, който да включва проверка на данните на всички места, които изглежда, за да видите дали те са постоянно еднакви.

Тестване на целостта на данните

# 4) Съответствие на бизнес правилата

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

Какво да тествате (Контролен списък за тестване на база данни)

# 1) Транзакции

При тестване на транзакции е важно да се уверите, че те отговарят на ACID свойствата.

Това са често използваните твърдения:

  • НАЧАЛО СДЕЛКА СДЕЛКА #
  • ЗАВЪРШЕТЕ СДЕЛКА

Отчетът за връщане гарантира, че базата данни остава в постоянно състояние.

  • ОБРАТНА СДЕЛКА №

След като тези инструкции бъдат изпълнени, използвайте Select, за да сте сигурни, че промените са отразени.

  • ИЗБЕРЕТЕ * ОТ ТАБЛЕНА

# 2) Схеми на база данни

Схемата на базата данни не е нищо повече от формална дефиниция за това как ще бъдат организирани данните в база данни. За да го тествате:

  • Идентифицирайте изискванията, въз основа на които работи базата данни. Примерни изисквания:
    • Първични ключове, които трябва да бъдат създадени преди да бъдат създадени други полета.
    • Външните ключове трябва да бъдат напълно индексирани за лесно извличане и търсене.
    • Имена на полета, започващи или завършващи с определени знаци.
    • Полета с ограничение, че определени стойности могат или не могат да бъдат вмъкнати.
  • Използвайте един от следните методи според уместността:
    • SQL заявка DESC за валидиране на схемата.
    • Регулярни изрази за валидиране на имената на отделните полета и техните стойности
    • Инструменти като SchemaCrawler

      • # 3) Задействания

      Когато определено събитие се случи на определена маса, част от кода (спусък) може да бъде инструктирана автоматично да бъде изпълнена.

      Например, нов ученик се присъедини към училище. Студентът посещава 2 класа: математика и природни науки. Ученикът се добавя към „студентската маса“. Тригер може да добави студента към съответните таблици на предмета, след като той бъде добавен към таблицата на студента.

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

      Те се тестват както във фазите на тестване на Black-box, така и в White-box.

      YouTube към mp3 конвертор без вирус
      • Тестване на бяла кутия : Stubs и Drivers се използват за вмъкване, актуализиране или изтриване на данни, които биха довели до задействане на задействането. Основната идея е просто да тествате DB самостоятелно, дори преди да бъде направена интеграцията с предния край (UI).
      • Тестване на черна кутия :

      да се) Тъй като потребителският интерфейс и DB, вече е налична интеграция; можем да вмъкнем / изтрием / актуализираме данни от предния край по начин, по който тригерът се извиква. След това операторите Select могат да бъдат използвани за извличане на данните на DB, за да се види дали задействането е било успешно при изпълнение на предвидената операция.

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

      # 4) Съхранени процедури

      Съхранените процедури са повече или по-малко подобни на дефинираните от потребителя функции. Те могат да бъдат извикани чрез оператори за извикване на процедура / Изпълнение на процедурата и изходът обикновено е под формата на набори от резултати.

      Те се съхраняват в RDBMS и са достъпни за приложения.

      Те също се тестват по време на:

      • Тестване на бяла кутия: Stubs се използват за извикване на съхранените процедури и след това резултатите се валидират спрямо очакваните стойности.
      • Тестване на черна кутия: Извършете операция от предния край (UI) на приложението и проверете за изпълнението на съхранената процедура и нейните резултати.

      # 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 Script може да бъде:

      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 и неговата DB е не само точно, но и в съответствие с проектните документи (SRS / BRS) или код. По принцип трябва да валидирате картографирането между всяко предно поле със съответното поле за база данни на бекенда.

      За всички CRUD операции проверете дали съответните таблици и записи се актуализират, когато потребителят щракне върху „Запазване“, „Актуализиране“, „Търсене“ или „Изтриване“ от GUI на приложението.

      Какво трябва да потвърдите:

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

      # 2) Осигурете ACID свойства на транзакциите:

      ACID свойствата на транзакциите на DB се отнасят до „ ДА СЕ Tomicity ’,‘ ° С постоянство “,„ Аз успокоение “и„ д урабилност “. По време на тестовата дейност на базата данни трябва да се направи правилно тестване на тези четири свойства. Трябва да проверите дали всяка отделна транзакция удовлетворява ACID свойствата на базата данни.

      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) Гарантирайте точността на въведените бизнес правила:

      Днес базите данни не са предназначени само за съхраняване на записите. Всъщност базите данни са еволюирали в изключително мощни инструменти, които осигуряват достатъчно подкрепа на разработчиците за внедряване на бизнес логиката на ниво DB.

      Някои прости примери за мощни функции са „Referencial Integrity“, релационни ограничения, тригери и съхранени процедури.

      Така че, използвайки тези и много други функции, предлагани от DB, разработчиците прилагат бизнес логиката на ниво DB. Изпитателят трябва да се увери, че внедрената бизнес логика е правилна и работи точно.

      Горните точки описват четирите най-важни „Какво да“ от тестването на DB. Сега да преминем към частта „Как да“.

      Как да тествате базата данни (процес стъпка по стъпка)

      Общата база данни за тестване на тестовия процес не се различава много от всяко друго приложение.

      Следват основните стъпки:

      Етап 1) Подгответе околната среда
      Стъпка 2) Пуснете тест
      Стъпка # 3) Проверете резултата от теста
      Стъпка # 4) Валидирайте според очакваните резултати
      Стъпка # 5) Докладвайте констатациите на съответните заинтересовани страни

      Процес на тестване на база данни

      Обикновено за разработване на тестовете се използват SQL заявки. Най-често използваната команда е „Избор“.

      Изберете * от къде

      Освен Select, SQL има 3 важни типа команди:

      1. DDL: Език за дефиниране на данни
      2. DML: Език за манипулиране на данни
      3. DCL: Език за контрол на данните

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

      Език за дефиниране на данни Използва CREATE, ALTER, RENAME, DROP и TRUNCATE за обработка на таблици (и индекси).

      Език за манипулиране с данни Включва изявления за добавяне, актуализиране и изтриване на записи.

      Език за контрол на данните: Занимава се с предоставяне на разрешение на потребители за манипулация и достъп до данните. Grant и Revoke са двете използвани твърдения.

      Предоставяне на синтаксис:
      Предоставяне на избор / актуализация
      На


      Да се ​​;

      Отмяна на синтаксиса:
      Отмяна на избор / актуализация
      На


      от;

      Някои практически съвети

      # 1) Напишете запитвания сами:

      За да тества точно базата данни, тестерът трябва да има много добри познания за SQL и DML (Data Manipulation Language) изрази. Тестерът също трябва да знае вътрешната структура на DB на AUT.

      Можете да комбинирате GUI и проверка на данните в съответните таблици за по-добро покритие. Ако използвате SQL сървъра, можете да използвате SQL Query Analyzer за писане на заявки, тяхното изпълнение и извличане на резултати.

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

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

      # 2) Наблюдавайте данните във всяка таблица:

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

      За ръчно тестване на данни тестерът на базата данни трябва да притежава добри познания за структурата на таблицата на базата данни.

      # 3) Получавайте заявки от разработчиците:

      Това е най-простият начин за тестване на базата данни. Извършете всяка CRUD операция от GUI и проверете нейното въздействие, като изпълните съответните SQL заявки, получени от разработчика. Нито се изисква добро познаване на SQL, нито добро познаване на структурата на DB на приложението.

      Но този метод трябва да се използва предпазливо. Какво ще стане, ако заявката, дадена от разработчика, е семантично грешна или не отговаря на изискванията на потребителя правилно? Процесът просто няма да успее да провери данните.

      # 4) Използвайте инструментите за тестване на автоматизация на база данни:

      Налични са няколко инструмента за процеса на тестване на данни. Трябва да изберете правилния инструмент според вашите нужди и да го използвате по най-добрия начин.

      => Ето списъка с ТОП инструментите за тестване на DB, които трябва да проверите

      Заключение

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

      Предложено четене = >> Какво е тестване на сигурността на базата данни

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

      Моля, уведомете ни за вашите отзиви и споделете личния си опит, ако работите по тестване на DB.

      Препоръчително четене

      ^