Мени

Водич за тестирање складишта података са примерима | ЕТЛ Водич за тестирање

  • Главни
  • Остало
  • Водич за тестирање складишта података са примерима | ЕТЛ Водич за тестирање

data warehouse testing tutorial with examples etl testing guide

Испробајте Наш Инструмент За Елиминисање Проблема

Овај водич детаљно покрива циљеве и значај тестирања складишта података, одговорности за тестирање ЕТЛ-а, грешке у примени ДВ-а и ЕТЛ-а:

У ово Серија обука за дубинско складиште података , погледали смо Шта је ЕТ Л Процес у складишту података у детаљи у нашем претходном водичу.

Овај водич ће вам дати разумевање како се тестирање складишта података може извршити у организацији. Такође ћете се упознати са циљевима ДВ тестирања, како и какво тестирање се може извршити на позадини, ко је све укључен у овај процес, ДВ грешке и ЕТЛ примена у детаље.

=> Овде погледајте СВЕ водиче о складиштењу података.

ЕТЛ тестирање складишта података

Циљна група

  • Програмери и тестери складишта података / ЕТЛ.
  • Стручњаци за базе података са основним знањем о концептима база података.
  • Администратори базе података / стручњаци за велике податке који желе да разумеју концепте Складишта података / ЕТЛ.
  • Дипломирани студенти / свежи студенти који траже посао у складишту података.

Шта ћете научити:

Тестирање складишта података (ЕТЛ)

Који је значај тестирања складишта података и система пословне интелигенције?

Тестирање игра пресудну улогу у успеху било ког од горе наведена два система, осигуравајући тачност података који граде веру крајњих корисника.

Генерално, квар пронађен у каснијим фазама животног циклуса развоја софтвера кошта више да би се отклонио тај недостатак. Ова ситуација у ДВ може се погоршати јер су погрешни подаци пронађени у каснијим фазама до тада могли бити коришћени у важним пословним одлукама.

Стога је поправак ДВ-а скупљи у погледу процеса, људи и технолошких промена. ДВ тестирање можете започети већ у фази прикупљања захтева.

Матрица сљедивости захтјева је припремљена и прегледана, а ово углавном мапира карактеристике ДВ-а са њиховим пословним захтјевима. Матрица следљивости делује као улаз у план испитивања ДВ који припремају тестери. План испитивања описује испитивања која треба извршити за потврђивање ДВ система.

Такође описује врсте тестова који ће се изводити на систему. Када је план теста спреман, сви детаљни тестови биће припремљени за различите сценарије ДВ-а. Тада ће се извршити сви тест случајеви и евидентирати недостаци.

У оперативном свету постоји стандард који одржава различита окружења за развој, тестирање и производњу. У ДВ свету, програмери и тестери ће се постарати да окружења за развој и тестирање буду доступна са репликама производних података пре почетка рада.

Ово се копира за листу табела са ограниченим или потпуним подацима у зависности од потреба пројекта, јер су производни подаци заиста велики. Програмери развијају свој код у окружењу програмера и достављају га тестерима.

Тестери ће тестирати код испоручен у окружењима за тестирање како би се уверили да ли сви системи раде. Тада ће код бити активан у производном окружењу. ДВ код се такође одржава у различитим верзијама на основу недостатака отклоњених у сваком издању. Одржавање више окружења и верзија кода помаже у изградњи система доброг квалитета.

која је разлика између осигурања квалитета и контроле квалитета?

Циљеви тестирања складишта података (ЕТЛ)

Погледајмо циљеве тестирања складишта података.

# 1) Комплетност података: Уверите се да су сви подаци из различитих извора учитани у складиште података. Тест тим проверава да ли су сви ДВ записи учитани у односу на изворну базу података и равне датотеке пратећи доленаведене примере стратегија.

  • Укупан број записа отпремљених из изворног система треба да се подудара са укупним бројем записа учитаних у ДВ. Ако постоји разлика, онда можете размислити о одбијеним записима.
  • Упоредите податке учитане у свако поље ДВ са пољима података изворног система. Ово ће открити грешке у подацима ако их има.

# 2) Трансформација података: Током отпремања изворних података у складиште података, мало поља се може директно учитати са изворним подацима, али мало поља ће бити учитано подацима који се трансформишу према пословној логици. Ово је сложени део тестирања ДВ (ЕТЛ).

Испод су примери стратегија за тестирање:

  • Можете да тестирате стварањем и упоређивањем података у табелама. Учитајте изворне трансформисане податке и ДВ податке у прорачунске табеле и извршите поређење. Не би требало да дође до неслагања.
  • Испитивачи би требали писати упите према логици трансформације да би упоредили ДВ податке са изворним подацима. Извршење упита гарантоваће да потврда података за било које поље не недостаје.

# 3) Квалитет података: Систем складишта података (ЕТЛ) мора осигурати квалитет података који се у њега учитавају одбацивањем (или) исправком података.

ДВ може одбити неколико изворних системских података заснованих на логици пословних захтева. На пример, одбити запис ако одређено поље има не-нумеричке податке. Сви одбијени записи учитавају се у табелу одбијања ради референце.

Одбијени подаци се пријављују клијентима јер нема шансе да се упознају са тим пропуштеним подацима, јер се неће учитати у ДВ систем. ДВ може тачно податке учитавањем нуле на место нултих вредности итд.

# 4) Скалабилност и перформансе: Складиште података мора да обезбеди скалабилност система са све већим оптерећењима. Уз ово, не би требало да дође до погоршања перформанси током извршавања упита, са очекиваним резултатима у одређеним временским оквирима. Тако испитивање перформанси открива било какве проблеме и решава их пре производње.

Испод су примери стратегија за тестирање перформанси и скалабилности:

  • Обавите тестирање перформанси учитавањем производних количина података и уверите се да временски оквири нису пропуштени.
  • Потврдите перформансе сваког упита скупним подацима. Тестирајте перформансе помоћу једноставних и вишеструких спајања.
  • Учитајте двоструко (или) троструко на количине података за које се очекује да приближно израчунају капацитет система.
  • Тестирајте покретањем задатака за све наведене извештаје истовремено.

# 5) Тестирање интеграције: Складиште података требало би да изврши тестирање интеграције са осталим апликацијама узводно и низводно. Ако је могуће, боље је копирати производне податке у тест окружење за интеграционо тестирање.

Сви системски тимови требало би да буду укључени у ову фазу како би премостили празнине, истовремено разумевајући и тестирајући све системе заједно.

# 6) Јединствено тестирање: Ово изводе појединачни програмери на основу својих резултата. Програмери ће припремити сценарије јединствених тестова на основу њиховог разумевања захтева, покренути јединствене тестове и документовати резултате. Ово помаже програмерима да исправе грешке ако их пронађу, пре него што испоруче код тиму за тестирање.

# 7) Испитивање регресије: Потврђује да ДВ систем не ради исправно након отклањања било каквих недостатака. То се изводи много пута са сваком новом променом кода.

# 8) Тестирање прихватљивости корисника: Ово тестирање обављају пословни корисници да би проверили функционалност система. УАТ окружење се разликује од КА окружења. Одјава са УАТ-а подразумева да смо спремни да преместимо код у производњу.

како писати тест случајеве у екцелу

Из перспективе Складишта података и система пословне интелигенције, пословни корисници могу потврдити различите извештаје путем корисничког интерфејса (УИ). Могу да потврде спецификације извештаја према захтевима, могу да потврде тачност података у извештајима, могу да потврде колико брзо систем враћа резултате итд.

ДВ дијаграм тока испитивања:

Дијаграм тока тестирања складишта података

Одговорности за тестирање складишта података

У наставку су наведени различити тимови укључени у испоруку успешног ДВ система:

  • Пословни аналитичари: Прикупите све пословне захтеве за систем и документујте оне који одговарају свима.
  • Инфраструктурни тим: Подесите различита окружења како је потребно и за програмере и за тестере.
  • Програмери: Развити ЕТЛ код у складу са захтевима и извршити јединствене тестове.
  • КА (осигурање квалитета) / тестери: Развити план теста, тест случајеве итд. Идентификује недостатке у систему извршавањем тест случајева. Извршите различите нивое тестирања.
  • ДБА: ДБА преузимају задатак претварања логичких сценарија ЕТЛ базе података у физичке сценарије ЕТЛ базе података и такође укључују тестирање перформанси.
  • Пословни корисници: Укључите се у тестирање прихватљивости корисника, покрените упите и извештаје на ДВ табелама.

Грешке у складишту података

Када из више извора извлачите, трансформишете и учитавате податке (ЕТЛ), постоји шанса да ћете добити лоше податке који могу прекинути дуготрајне послове.

Следе кључни узроци кварова у ДВ систему:

# 1) Кршење пословних правила (логичке грешке): Логично погрешни подаци крше правила пословања. Таквим подацима се може руковати углавном током фаза трансформације или учитавања.

# 2) Кршење правила података (грешке у подацима): Грешке у подацима се јављају у систему базе података ДВ попут неусклађености типова података, грешака у ограничењу података итд.

Примена ЕТЛ-а

Ово је фаза у којој сви ваши напори иду уживо. Треба припремити сву документацију за подршку производњи.

Документација ће другима рећи о редоследу извршених послова, сценаријима опоравка од кварова, материјалима за обуку тимовима за подршку ДВ-а за надгледање система након примене и административном тиму за подршку за извршавање извештаја.

Закључак

О циљевима тестирања складишта података, одговорностима за тестирање ЕТЛ-а, грешкама у примени ДВ-а и ЕТЛ-у детаљно смо сазнали у овом упутству.

Надамо се да сте добили идеју о томе како се детаљно тестирање може обавити у систему складишта података (ЕТЛ).

=> Посетите овде да бисте од нуле научили складиштење података.

Препоручено читање

^