database testing complete guide why
Комплетан водич за тестирање базе података са практичним саветима и примерима:
Рачунарске апликације су данас сложеније са технологијама попут Андроида, као и са пуно апликација за паметне телефоне. Што су предњи крајеви сложенији, задњи крајеви постају замршенији.
Дакле, утолико је важније научити о ДБ тестирању и бити у стању ефикасно потврдити базе података како би се осигурала сигурност и квалитет база података.
У овом упутству ћете научити све о тестирању података - зашто, како и шта тестирати?
База података је један од неизбежних делова софтверске апликације.
Није битно да ли је то веб, радна површина или мобилни уређај, клијент-сервер, пеер-то-пеер, предузеће или појединачно предузеће; база података је потребна свуда на позадини.
Слично томе, било да се ради о здравству, финансијама, лизингу, малопродаји, пошти или контроли свемирског брода; база података је увек на делу иза сцене.
Како се сложеност апликације повећава, јавља се потреба за јачом и сигурнијом базом података. На исти начин, за апликације са великом фреквенцијом трансакција ( На пример, Банкарство или апликација за финансије), повезана је потреба за потпуно опремљеним ДБ алатом.
У данашње време имамо велике и сложене велике податке са којима традиционалне базе података не могу да се носе.
Има их неколико Алати за базе података доступни су на тржишту На пример, МС-Аццесс, МС СКЛ Сервер, СКЛ Сервер, Орацле, Орацле Финанциал, МиСКЛ, ПостгреСКЛ, ДБ2, Тоад, Адмирер итд. Ови алати се разликују по цени, робусности, карактеристикама и сигурности. Сваки од ових има своје предности и недостатке.
Шта ћете научити:
- Зашто тестирати базу података?
- Шта тестирати (контролна листа за тестирање базе података)
- Како тестирати базу података (корак по корак)
Зашто тестирати базу података?
Испод ћемо видети зашто треба потврдити следеће аспекте ДБ:
# 1) Мапирање података
У софтверским системима подаци често путују напред и назад од корисничког интерфејса (корисничког интерфејса) до позадинске ДБ и обрнуто. Ево неколико аспеката на које треба обратити пажњу:
- Проверите да ли су поља у обрасцима УИ / фронтенд мапирана доследно са одговарајућим пољима у ДБ табели. Ти подаци о мапирању обично су дефинисани у документима са захтевима.
- Кад год се изврши одређена радња на предњем крају апликације, на задњем крају се позива одговарајућа ЦРУД (Цреате, Ретриеве, Упдате анд Делете) радња. Тестер ће морати да провери да ли се позива исправна радња и да ли је сама позвана акција успешна или не.
# 2) Провера ваљаности АЦИД својстава
Атомицност, доследност, изолација и трајност. Свака трансакција коју ДБ изврши мора се придржавати ова четири својства.
- Атомицити значи да трансакција или не успева или пролази. То значи да чак и ако један део трансакције закаже - то значи да је целокупна трансакција пропала. Обично се то назива правилом „све или ништа“.
- Доследност : Трансакција ће увек резултирати важећим стањем ДБ-а
- Изолација : Ако постоји више трансакција и оне се извршавају одједном, резултат / стање ДБ-а треба бити исто као да су извршене једна за другом.
- Трајност : Једном када се трансакција изврши и изврши, ниједан спољни фактор као што је губитак енергије или пад не би требало да је могу променити
Предложено читање = >> МиСКЛ Трансацтион Туториал
# 3) Интегритет података
За било који од ЦРУД Оператионс , ажуриране и најновије вредности / статус дељених података треба да се појаве на свим обрасцима и екранима. Вредност не би требало ажурирати на једном екрану, а старију вредност приказати на другом.
Када је апликација у извршењу, крајњи корисник углавном користи операције „ЦРУД“ које омогућава ДБ алатка .
Ц: Створи - Када корисник ‘Сачувај’ било коју нову трансакцију, извршава се операција ‘Направи’.
Р: Преузми - Када корисник претражује или прегледа било коју сачувану трансакцију, извршава се операција „Дохвати“.
У: Ажурирање - Када корисник 'Уреди' или 'Измени' постојећи запис, врши се операција 'Ажурирај' ДБ-а.
Д: Избриши - Када корисник ‘уклони’ било који запис из система, извршава се операција ‘Избриши’ ДБ-а.
Било која операција базе података коју изводи крајњи корисник увек је једна од горе наведене четири.
Дакле, осмислите своје ДБ тест случајеве на начин да укључују проверу података на свим местима за која се чини да ли су у потпуности исти.
# 4) Усклађеност пословног правила
Већа сложеност у базама података значи сложеније компоненте попут релационих ограничења, окидача, ускладиштених процедура итд. Тако да ће тестери морати да смисле одговарајуће СКЛ упите да би потврдили ове сложене објекте.
Шта тестирати (контролна листа за тестирање базе података)
# 1) Трансакције
При тестирању трансакција важно је осигурати да задовољавају АЦИД својства.
Ово су најчешће коришћене изјаве:
- ПОЧИНИТЕ ТРАНСАКЦИЈУ ТРАНСАКЦИЈУ #
- КРАЈ ТРАНСАКЦИЈЕ ТРАНСАКЦИЈА #
Изјава о враћању осигурава да база података остане у доследном стању.
- ТРАНСАКЦИЈА РОЛБАЦК-А
Након извршавања ових израза, користите Селецт да бисте били сигурни да су промене одражене.
- СЕЛЕЦТ * ИЗ ТАБЛЕНАМЕ
# 2) Шеме база података
Шема базе података није ништа друго до формална дефиниција како ће подаци бити организовани унутар ДБ-а. Да бисте га тестирали:
- Утврдите захтеве на основу којих база података ради. Захтеви за узорак:
- Примарни кључеви који се креирају пре него што се креира било које друго поље.
- Страни кључеви би требали бити потпуно индексирани ради лакшег проналажења и претраживања.
- Имена поља која почињу или се завршавају одређеним знаковима.
- Поља са ограничењем да се одређене вредности могу или не могу убацити.
- Користите једну од следећих метода у складу са релевантношћу:
- СКЛ упит ДЕСЦ
за потврду шеме.
- Регуларни изрази за потврђивање имена појединачних поља и њихових вредности
- Алати попут СцхемаЦравлер
# 3) Окидачи
Када се одређени догађај догоди на одређеној табели, може се аутоматски наложити да се изврши комад кода (окидач).
На пример, нови ученик се придружио школи. Ученик похађа 2 часа: математику и природне науке. Ученик се додаје у „студентски сто“. Триггер би могао додати ученика у одговарајуће табеле предмета када се дода у студентски сто.
Уобичајена метода за тестирање је да се прво самостално изврши СКЛ упит уграђен у Триггер и забележи резултат. Следите ово извршавањем Окидача у целини. Упоредите резултате.
Они су тестирани и у фази тестирања црне и беле кутије.
како прогласити повезану листу у јави
- Испитивање беле кутије : Стубс и Дриверс се користе за уметање или ажурирање или брисање података који би резултирали позивањем окидача. Основна идеја је само тестирати ДБ чак и пре него што се изврши интеграција са предњим крајем (УИ).
- Тестирање црне кутије :
до) Од корисничког интерфејса и базе података, интеграција је сада доступна; можемо уметнути / избрисати / ажурирати податке са предње стране на начин да се активира Покретач. Након тога, наредбе Селецт могу се користити за дохваћање ДБ података да би се видело да ли је Окидач успешан у извођењу намераване операције.
б) Други начин да се ово тестира је директно учитавање података који би позвали Окидач и утврђивање да ли ради како је предвиђено.
# 4) Чуване процедуре
Похрањене процедуре су више или мање сличне функцијама које дефинишу корисници. На њих се могу позивати изрази Процедура позива / Извршити процедуру, а излаз је обично у облику скупова резултата.
Они се чувају у РДБМС и доступни су апликацијама.
Они се такође тестирају током:
- Испитивање беле кутије: Стубс се користе за позивање ускладиштених процедура, а затим се резултати потврђују према очекиваним вредностима.
- Тестирање црне кутије: Извршите операцију са предњег краја (УИ) апликације и проверите извршење сачуване процедуре и њених резултата.
# 5) Ограничења поља
Подразумевана вредност, јединствена вредност и спољни кључ:
- Извршите фронт-енд операцију која вежба стање објекта базе података
- Потврдите резултате помоћу СКЛ упита.
Провера подразумеване вредности за одређено поље је прилично једноставна. То је део валидације пословних правила. Можете то учинити ручно или можете користити алате попут КТП-а. Ручно можете извршити радњу која ће додати вредност која није подразумевана вредност поља са предње стране и видети да ли ће то довести до грешке.
Следи пример ВБСцрипт кода:
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) Резултат горњег кода је Тачно ако постоји подразумевана вредност или Нетачно ако не постоји.
Провера јединствене вредности може се обавити тачно онако како смо то урадили за подразумеване вредности. Покушајте да унесете вредности из корисничког интерфејса које ће кршити ово правило и погледајте да ли се приказује грешка.
ВБ скрипта за аутоматизацију може бити:
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) Осигурајте мапирање података:
Мапирање података је један од кључних аспеката базе података и сваки испитивач софтвера треба га строго тестирати.
Уверите се да мапирање између различитих облика или екрана АУТ-а и његовог ДБ-а није само тачно већ и према пројектним документима (СРС / БРС) или коду. У основи, потребно је да потврдите мапирање између сваког предњег поља са одговарајућим пољем базе података позадине.
За све ЦРУД операције проверите да ли се одговарајуће табеле и записи ажурирају када корисник кликне на „Сачувај“, „Ажурирај“, „Претражи“ или „Избриши“ из ГУИ апликације.
Шта треба да верификујете:
- Мапирање табела, мапирање колона и мапирање типова података.
- Мапирање података претраживања.
- Исправна ЦРУД операција се позива за сваку радњу корисника у корисничком интерфејсу.
- ЦРУД операција је успешна.
# 2) Осигурајте АЦИД својства трансакција:
АЦИД својства ДБ трансакција односе се на „ ДО томицити “,„ Ц. постојаност ’,‘ Ја солација ’и‘ Д. урабилност ’. Правилно тестирање ова четири својства мора се обавити током активности тестирања базе података. Морате да потврдите да свака појединачна трансакција задовољава АЦИД својства базе података.
Узмимо једноставан пример испод СКЛ кода:
CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));Табела АЦИД теста имаће две колоне - А и Б. Постоји ограничење интегритета да збир вредности у А и Б увек буде 100.
Тест атомскости обезбедиће да је свака трансакција извршена у овој табели цела или ниједна, тј. да се ниједан запис не ажурира ако било који корак трансакције не успе.
Тест конзистентности осигураће да кад год се вредност у колони А или Б ажурира, сума увек остане 100. Неће дозволити уметање / брисање / ажурирање у А или Б ако је укупан збир нешто друго осим 100.
Тест изолације ће осигурати да се, ако се две трансакције дешавају истовремено и покушавају да се измене подаци табеле АЦИД теста, тада се те вуче извршавају изоловано.
Тест издржљивости осигураће да ће једном извршена трансакција преко ове табеле остати таква, чак и у случају губитка електричне енергије, пада или грешака.
Ово подручје захтева строже, детаљније и пажљивије тестирање ако ваша апликација користи дистрибуирану базу података.
# 3) Осигурајте интегритет података
Узмите у обзир да различити модули (тј. Екрани или обрасци) апликације користе исте податке на различите начине и изводе све ЦРУД операције над подацима.
У том случају, уверите се да се најновије стање података одражава свуда. Систем мора приказати ажуриране и најновије вредности или статус таквих дељених података на свим обрасцима и екранима. То се назива интегритет података.
Тест случајеви за потврђивање интегритета података базе података:
- Проверите да ли су сви окидачи на месту да бисте ажурирали записе референтне табеле.
- Проверите да ли постоје нетачни / неваљани подаци у главним колонама сваке табеле.
- Покушајте да уметнете погрешне податке у табеле и проверите да ли се деси било какав квар.
- Проверите шта се дешава ако покушате да убаците дете пре него што убаците његовог родитеља (покушајте да се играте са примарним и страним кључевима).
- Тестирајте да ли ће доћи до било какве грешке ако избришете запис на који се још увек позивају подаци у било којој другој табели.
- Проверите да ли су репликовани сервери и базе података синхронизовани.
# 4) Осигурајте тачност примењених правила пословања:
Данас базе података нису намењене само чувању записа. У ствари, базе података су еволуирале у изузетно моћне алате који пружају обимну подршку програмерима за примену пословне логике на нивоу ДБ-а.
Неки једноставни примери моћних карактеристика су „Референцијални интегритет“, релациона ограничења, окидачи и ускладиштене процедуре.
Дакле, користећи ове и многе друге функције које нуде ДБ-ови, програмери имплементирају пословну логику на нивоу ДБ-а. Тестер мора осигурати да је имплементирана пословна логика тачна и да ради тачно.
Горње тачке описују четири најважнија „Шта треба“ тестирања ДБ-а. Сада пређимо на део „Како да“.
Како тестирати базу података (корак по корак)
База података о општем тестирању процеса тестирања не разликује се много од било које друге апликације.
Следе основни кораци:
Корак 1) Припремите окружење
Корак 2) Покрените тест
Корак # 3) Проверите резултат теста
Корак # 4) Потврдити према очекиваним резултатима
Корак # 5) Извештајте о налазима одговарајућим заинтересованим странама
За развој тестова обично се користе СКЛ упити. Најчешће коришћена команда је „Изабери“.
Изаберите * одакле
Поред Селецт-а, СКЛ има 3 важне врсте наредби:
- ДДЛ: Језик за дефинисање података
- ДМЛ: Језик за манипулацију подацима
- ДЦЛ: Језик за контролу података
Погледајмо синтаксу најчешће коришћених изјава.
Језик дефиниције података Користи ЦРЕАТЕ, АЛТЕР, РЕНАМЕ, ДРОП и ТРУНЦАТЕ за руковање табелама (и индексима).
Језик за манипулацију подацима Укључује изјаве за додавање, ажурирање и брисање записа.
Језик за контролу података: Бави се давањем овлашћења корисницима за манипулацију и приступ подацима. Две изјаве које се користе су „Грант анд Ревоке“.
Синтакса одобрења:
Одобри избор / ажурирање
на
До ;Опозови синтаксу:
Опозови избор / ажурирање
на
од;Неки практични савети
# 1) Напишите упите сами:
Да би тачно тестирао базу података, испитивач треба да добро познаје СКЛ и ДМЛ (Дата Манипулатион Лангуаге) изразе. Испитивач би такође требао знати унутрашњу структуру ДБ-а АУТ.
Можете комбиновати ГУИ и проверу података у одговарајућим табелама ради боље покривености. Ако користите СКЛ сервер, онда СКЛ Куери Анализер можете користити за писање упита, њихово извршавање и преузимање резултата.
Ово је најбољи и робусни начин тестирања базе података када је апликација малог или средњег нивоа сложености.
Ако је апликација веома сложена, тестеру ће можда бити тешко или немогуће да напише све потребне СКЛ упите. За сложене упите потражите помоћ програмера. Увек препоручујем овај метод јер вам даје поверење у тестирање и такође побољшава ваше СКЛ вештине.
# 2) Посматрајте податке у свакој табели:
Можете да извршите проверу података користећи резултате ЦРУД операција. То се може учинити ручно помоћу корисничког интерфејса апликације када знате интеграцију базе података. Али ово може бити досадан и гломазан задатак када у различитим табелама базе података има огромних података.
За ручно тестирање података, испитивач базе података мора да поседује добро знање о структури табеле базе података.
# 3) Добијте упите од програмера:
Ово је најједноставнији начин за тестирање базе података. Извршите било коју ЦРУД операцију из ГУИ-а и потврдите њене утицаје извршавањем одговарајућих СКЛ упита добијених од програмера. Не захтева добро познавање СКЛ-а нити добро познавање структуре ДБ апликације.
Али ову методу треба користити опрезно. Шта ако је упит који је дао програмер семантички погрешан или не испуњава правилно захтев корисника? Процес једноставно неће успети да потврди податке.
# 4) Искористите алате за тестирање аутоматизације базе података:
За поступак тестирања података доступно је неколико алата. Требали бисте одабрати прави алат према вашим потребама и искористити га на најбољи начин.
=> Ево листе ТОП ДБ алата за тестирање које бисте требали проверити
Закључак
Уз све ове карактеристике, факторе и процесе за тестирање на бази података, све је већа потреба да тестери буду технички вешти у кључним концептима базе података. Упркос неким негативним уверењима да тестирање базе података ствара нова уска грла и представља много додатних трошкова - ово је подручје тестирања које привлачи значајну пажњу и потражњу.
Предложено читање = >> Шта је тестирање сигурности базе података
Надам се да је овај водич помогао да се усредсредите на то зашто је то тако што вам је пружио и основне детаље о томе шта иде у тестирање базе података.
Обавестите нас о својим повратним информацијама и поделите своја лична искуства ако радите на ДБ тестирању.
Препоручено читање
- Тестирање базе података помоћу ЈМетер-а
- 40+ најбољих алата за тестирање база података - популарна решења за тестирање података
- Једноставан приступ за КСМЛ тестирање база података
- Водич за тестирање складишта података ЕТЛ (комплетан водич)
- Водич за тестирање миграције података: Комплетан водич
- 10 најбољих алата за дизајн базе података за изградњу сложених модела података
- Водич за тестирање складишта података са примерима | ЕТЛ Водич за тестирање
- Како тестирати Орацле базу података
^
- СКЛ упит ДЕСЦ
