Тестови за проверу ваљаности података за ЕТЛ и пројекте миграције података

data validation tests

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

Овај чланак је намењен тестерима софтвера који раде на ЕТЛ или пројектима Миграције података и заинтересовани су да своје тестове фокусирају само на аспекте квалитета података. Ове врсте пројеката имају огроман обим података који се чувају у изворном складишту, а затим оперишу неком логиком присутном у софтверу и премештају се у циљно складиште.

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

Број аспеката квалитета података који се могу тестирати је огроман и овај списак у наставку даје увод у ову тему.

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

• Шта је валидација података?
• Зашто потврђивати податке за ЕТЛ пројекте?
• Зашто валидирати податке за пројекте миграције података?
  • Лист за мапирање података
  • Тестови за проверу података
    • # 1) Уједначеност података
    • # 2) Присуство ентитета
    • # 3) Тачност података
    • # 4) Провера метаподатака
    • # 5) Интегритет података
    • # 6) Комплетност података
    • # 7) Трансформација података
    • # 8) Јединственост података или копирање
    • # 9) Обавезно
    • # 10) Правовременост
    • # 11) Нулл подаци
    • # 12) Провера домета
    • # 13) Правила пословања
    • # 14) Збирне функције
    • # 15) Скраћивање података и заокруживање
    • # 16) Тестови кодирања
    • # 17) Тестови регресије
• Закључак
  • Препоручено читање

Шта је валидација података?

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

Пример: Адреса студента у табели Студент била је 2000 знакова у изворном систему. Провера података проверава да ли се потпуно иста вредност налази у циљном систему. Проверава да ли су подаци скраћени или су уклоњени одређени посебни знакови.

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

Зашто потврђивати податке за ЕТЛ пројекте?

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

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

Пример: Апликација за е-трговину има ЕТЛ послове који бирају све ОрдерсИдс према сваком ЦустомерИД-у из табеле Ордерс који сажима ТоталДолларс-ове потрошње од стране Купца и учитава их у нову табелу ЦустомерВалуе означавајући сваког Цустомер-а као клијенте високе / средње / мале вредности. на неком сложеном алгоритму.

Једноставни тест за проверу података је да се утврди да ли је Оцена клијената тачно израчуната.

Други тест је да се верификује да ли је ТоталДолларСпенд исправно израчунат без недостатака у заокруживању вредности или максималних преливања вредности.

Зашто валидирати податке за пројекте миграције података?

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

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

И овде је потребна потврда података како би се потврдило да су подаци на извору исти у циљу након кретања.

Пример: Претпоставимо да је за апликацију е-трговине табела Поруџбине која је имала 200 милиона редова мигрирана у циљни систем на Азуреу. Једноставан тест за проверу ваљаности података је да се потврди да је свих 200 милиона редова података доступно у циљном систему.

Други тест би могао бити потврђивање да се формати датума подударају између изворног и циљног система.

Постоје различити аспекти које тестери могу тестирати у таквим пројектима као што су функционални тестови, тестови перформанси, сигурносни тестови, инфра тестови, Е2Е тестови, регресијски тестови итд.

Препоручено читање => Тестирање миграције података , Водич за тестирање складишта података ЕТЛ

У овом чланку ћемо размотрити само аспект података тестова за ЕТЛ и миграционе пројекте.

Лист за мапирање података

За почетак направите лист за мапирање података за свој пројекат података. Мапирање података је поступак упаривања ентитета између изворне и циљне табеле. Почните са документовањем свих табела и њихових ентитета у изворном систему у табелу. Сада документујте одговарајуће вредности за сваки од ових редова за које се очекује да се подударају у циљним табелама. Забележите правила трансформације у посебну колону ако постоје.

Листови за мапирање података садрже пуно информација прикупљених из модела података које су обезбедили Дата Арцхитецтс. У почетку су тестери могли да креирају поједностављену верзију и могу да додају више информација током наставка. Погледајте пример табеле за мапирање података испод -

Преузмите образац са Поједностављени лист за мапирање података

Тестови за проверу података

# 1) Уједначеност података

Тестови униформности података се спроводе да би се потврдило да се стварна вредност ентитета тачно подудара на различитим местима. Овде су могуће две врсте тестова:

(и) Провере у оквиру исте шеме:

• Ентитет података може постојати у две табеле у истој шеми (било изворни систем или циљни систем)
• Пример: Као што можете видети на доњој слици, ПродуцтИД је присутан у табели ОрдерДетаилс и Продуцтс. Направите тачну верификацију подударања за ПродуцтИд који се налази у табели ОрдерДетаилс вс Продуцтс.

(ии) Провера међу шемама:

• Ентитет података може се мигрирати какав јесте у циљну шему, тј. Присутан је у изворном систему као и циљном систему
• Пример: Као што можете видети на горњој слици, ПродуцтИД је присутан у табели Продуцтс у изворном систему и Продуцтс табели у циљном систему. Урадите тачну верификацију подударања за ПродуцтИд у табели Продуцтс у изворном систему са ПродуцтИд у табели Продуцтс у циљном систему.

Белешка: Најбоље је истакнути (код у боји) одговарајуће целине података у листу Мапирање података за брзу референцу.

# 2) Присуство ентитета

У овој врсти теста морамо да потврдимо да се сви ентитети (табеле и поља) подударају између извора и циља. Постоје две могућности, ентитет може бити присутан или одсутан према дизајну модела података.

(и) Потврдите да се све табеле (и колоне), које имају одговарајуће присуство и у извору и у циљу, подударају. Повлачимо листу свих табела (и колона) и упоређујемо текст. Овај тест исправности делује само ако се користе иста имена ентитета.

Понекад се користе различита имена табела и стога директно упоређивање можда неће успети. Можда ћемо морати да мапирамо ове информације у листу Мапирање података и потврдимо их због грешака.

Друга могућност је одсуство података. Постоје случајеви када модел података захтева да табела у изворном систему (или колони) нема одговарајуће присуство у циљном систему (или обрнуто). Имајте тестове да то потврдите.

• Пример: Као што можете видети на доњој слици, ЦустДемограпхиц Табле је присутан у циљном систему, а не у изворном систему.
• Поље ЦустомерТипе у табели Купци садржи податке само у изворном систему, а не у циљном систему.

# 3) Тачност података

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

задати мрежни пролаз за Виндовс 10 није доступан

(слика извор )

Белешка: Покрените овај тест у циљном систему и проверите да ли постоје недостаци у изворном систему.

(и) Ненумерички тип: Према овој класификацији верификујемо тачност ненумеричког садржаја. Примери су Е-пошта, Пин кодови, Телефон у важећем формату.

(ии) Анализа домена: У овој врсти теста бирамо домене података и потврђујемо грешке. Постоје три групе за ово:

• На основу вредности: Овде креирамо листу вредности које се могу појавити за поље (ступац у табели). Затим потврдите да ли су вредности колона подскуп наше листе.
  • Пример: Проверите да ли колона Род садржи М или Ф.
• На основу домета: Овде постављамо минимални и максимални опсег за важеће вредности података за колону, на основу логичког или пословног образложења. Затим потврђујемо да ли вредности колона спадају у овај опсег.
  • Пример: 0 до 120 за старост.
• Референтна датотека : Овде систем користи спољну датотеку ваљаности.
  • Пример: Да ли су шифре држава валидне, да ли одабиру праву вредност из референтне датотеке, да ли су кодови земаља исти између КА и производног окружења? Ако је референтној датотеци ажуриран код државе, да ли се исправно ажурира у ДБ-у?

# 4) Провера метаподатака

У валидацији метаподатака потврђујемо да су дефиниције типа података Табела и Колона за циљ исправно дизајниране, а када се једном дизајнирају, извршавају се према спецификацијама дизајна модела података.

Овде постоје две групе:

(и) Дизајн метаподатака: Прва провера је потврда да ли је модел података правилно дизајниран у складу са пословним захтевима за циљне табеле. Архитекте података могу мигрирати ентитете шеме или могу извршити модификације када дизајнирају циљни систем.

Следећа провера требало би да буде потврда да су праве скрипте креиране помоћу модела података.

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

Неколико провера метаподатака је дато у наставку:

• Провера типа података: Пример: Да ли ће укупна продаја исправно радити са децималним (8, 16 или 20 бајтова) или двоструким типом?
• Провера дужине података : Пример: Да ли ће дужина података за поље Адреса бити довољна за 500 знакова? То би могао бити случај када се миграција података врши када се компанији додаје нова географија. Адресе нове географије могу имати изузетно дугачак формат, а придржавање оригиналне дужине може погрешити у употреби.
• Провера индекса: Пример: Да ли се врши индексирање за колону ОрдерИд у циљном систему? Шта ако се деси спајање компанија које захтевају миграцију података и табела Наруџбе у циљном систему постане 100 пута већа?
• Провера метаподатака у различитим окружењима: У оквиру ове провере проверите да ли се метаподаци подударају између КА теста и производног окружења. Тестови могу проћи у КА окружењу, али у другим окружењима неће успети.

(ии) Делта промена: Ови тестови откривају недостатке који настају када је пројекат у току и усред промена постоје метаподаци изворног система и нису примењени у циљним системима.

Пример: Ново поље ЦСИ (Индекс задовољства купаца) додато је у табелу купаца у извору, али није успело да се унесе у циљни систем.

# 5) Интегритет података

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

(слика извор )

За стране кључеве морамо да проверимо да ли постоје матични записи у подређеној табели, где се страни кључ не налази у надређеној табели.

Пример: Табела купаца има ЦустомерИД који је Примарни кључ. Табела поруџбина има ЦустомерИД као страни кључ. Табела поруџбина можда има ИД купца који није у табели Купци. Морамо да имамо тестове да бисмо открили таква кршења ограничења интегритета. Табела мапирања података пружит ће вам јасност у томе које табеле имају ова ограничења.

Белешка: Покрените овај тест у циљном систему и поново проверите у изворном систему ако постоје недостаци.

# 6) Комплетност података

Ово су тестови исправности који откривају недостајући број записа или редова између изворне и циљне табеле и могу се често покретати након што се аутоматизују.

Постоје две врсте тестова:

(и) Број записа: Овде упоређујемо укупан број записа за подударање табела између изворног и циљног система. Ово је брза провера исправности да би се верификовало покретање ЕТЛ-а или задатка миграције. Имамо недостатак ако се бројање не подудара.

Повремено постоје одбијени записи током извођења посла. Неке од ових могу бити валидне. Али као тестер, наводимо конкретне случајеве за ово.

(ии) Профилисање података у колони: Ова врста здравственог стања вредна је када је број записа огроман. Овде креирамо логичке скупове података који смањују број записа, а затим вршимо поређење између извора и циља.

• Где је то могуће, филтрирајте све јединствене вредности у колони, на пример, ПродуцтИД се можда појављује више пута у табели ОрдерДетаилс. Изаберите јединствену листу ПродуцтИД из циљне и изворне табеле и потврдите. Ово значајно смањује број бројања записа и убрзава тестове исправности.
• Као и горњи тестови, такође можемо одабрати све главне колоне и проверити да ли се КПИ (минимална, максимална, просечна, максимална или минимална дужина итд.) Подударају између циљне и изворне табеле. Пример: Узмите просечне, минималне и максималне вредности из колоне Цена у ОрдерДетаилс и упоредите ове вредности између циљних и изворних табела ради неподударања.
• Још једна провера може се извршити за вредности Нулл. Изаберите важне колоне и филтрирајте листу редова у којима колона садржи нулл вредности. Упоредите ове редове између циљног и изворног система ради неусклађености.

# 7) Трансформација података

Ови тестови чине суштинске тестове пројекта. Прегледајте документ са захтевима да бисте разумели захтеве за трансформацију. Припремите тест податке у изворним системима да одражавају различите сценарије трансформације. Они имају мноштво тестова и требали би бити детаљно покривени у ЕТЛ темама тестирања.

Испод је сажета листа тестова обухваћених овим:

(и) Трансформација:

• Пример: ЕТЛ код може имати логику за одбацивање неважећих података. Проверите ове у односу на захтеве.
• ЕТЛ код такође може садржавати логику за аутоматско генерисање одређених кључева попут сурогат кључева. Морамо да имамо тестове да бисмо проверили исправност (техничких и логичких) ових.
• Потврдите исправност спајања или поделе вредности поља након завршетка ЕТЛ-а или миграције.
• Имајте тестове за верификацију референтних провера интегритета. На пример, врста квара може бити ПродуцтИд која се користи у табели Наруџбе није присутна у надређеној табели Продуцтс. Направите тест да бисте потврдили како се евиденција о сироче понаша током ЕТЛ посла.
• Понекад се подаци који недостају убацују помоћу ЕТЛ кода. Проверите исправност ових.
• ЕТЛ или Мигратион скрипте понекад имају логику за исправљање података. Проверите да ли корекција података ради.
• Проверите да ли се корисници пријављују неваљаним / одбијеним / погрешним подацима.
• Направите прорачунску табелу сценарија улазних података и очекиваних резултата и оверите их код пословног купца.

(ии) Рубни случајеви: Проверите да ли се логика трансформације добро држи на границама.

• Пример: Шта се дешава када се ТоталСалес у вредности од 1 трилиона изврши кроз ЕТЛ посао? Да ли случајеви од краја до краја функционишу? Идентификујте поља која потенцијално могу имати велике вредности и покрените тестове са тим великим вредностима. Требају садржати нумеричке и не-нумеричке вредности.
• За поља са датумима, укључујући читав опсег очекиваних датума - преступне године, 28/29 дана за фебруар. 30, 31 дан за остале месеце.

# 8) Јединственост података или копирање

У овој врсти теста идентификујте колоне које би требале имати јединствене вредности према моделу података. Такође, узмите у обзир пословну логику да искористите такве податке. Покрените тестове да бисте проверили да ли су јединствени у систему. Следеће покретање тестова за идентификовање стварних дупликата.

• Пример: Филтрирајте дупликате података и проверите да ли су аутентични. На пример, Запис о зависном запосленом садржи два пута исте податке о браћи и сестрама.
• Кориснички телефонски број треба да буде јединствен у систему (пословни захтев).
• Пословни захтев каже да комбинација ПродуцтИД и ПродуцтНаме у табели Продуцтс треба да буде јединствена, јер ПродуцтНаме може бити дупликат.

# 9) Обавезно

У овој врсти теста идентификујте сва поља означена као Обавезна и потврдите да ли обавезна поља имају вредности. Ако постоје подразумеване вредности повезане са пољем у ДБ-у, проверите да ли је правилно попуњено кад података нема.

• Пример: Ако БиллДате није унесен, тада је ЦуррентДате БиллДате.

# 10) Правовременост

Увек документујте тестове који потврђују да радите са подацима из договорених рокова.

• Пример: ПродуцтДисцоунт је ажуриран пре 15 дана, а ПродуцтДисцоунт се мења на сваких седам дана. То значи да се ваши тестови не раде са правим вредностима попуста.
• Извештај предиктивне аналитике за индекс задовољства купаца требало је да ради са последњим једнонедељним подацима, који су били недеље промоције продаје у Валмарту. Али посао ЕТЛ-а је дизајниран да ради у фреквенцији од 15 дана. Ово је главни недостатак који тестери могу открити.

# 11) Нулл подаци

У овој врсти теста фокусирамо се на валидност нулл података и верификацију да важна колона не може бити нулл.

• Пример: Филтрирајте све нулл податке и потврдите ако је нулл дозвољена.
• Ако постоје важне колоне за пословне одлуке, уверите се да нису присутне нуле.

# 12) Провера домета

Треба тестирати ентитет података у коме опсези имају пословни смисао.

• Пример: Количина поруџбине по фактури не може бити већа од 5К у категорији софтвера.
• Старост не би требало да буде већа од 120 година.

# 13) Правила пословања

Документујте све пословне захтеве за поља и покрените тестове за исте.

бесплатни софтвер радног времена за мала предузећа

• Пример: Ресурси млађи од 20 година не испуњавају услове. Провере ваљаности података потребне су ако се ово правило примењује на податке.
• Датум отказа треба да буде ништаван ако је статус запосленог активног тачно / преминуо.
• ФРОМ подаци требају бити мањи од ТО Дате.
• Износе суме за куповину на нивоу предмета сумирајте са износима на нивоу поруџбине

# 14) Збирне функције

Агрегатне функције уграђене су у функционалност базе података. Документујте све агрегате у изворном систему и проверите да ли агрегатна употреба даје исте вредности у циљном систему (сум, мак, мин, цоунт).

Често се алати на изворном систему разликују од циљног система. Проверите да ли оба алата извршавају агрегатне функције на исти начин.

# 15) Скраћивање података и заокруживање

У овим врстама тестова идентификујемо поља са логиком скраћивања и заокруживања која се односе на посао. Затим документујемо и добивамо потпис на логику скраћивања и заокруживања са власницима производа и тестирамо их са репрезентативним подацима производње.

# 16) Тестови кодирања

Провјерите постоје ли кодиране вриједности у изворном систему и провјерите да ли су подаци правилно попуњени након ЕТЛ-а или задатка миграције података у циљни систем.

• Пример: Двобајтни знакови за ФирстНаме на кинеском прихваћени су у изворном систему који је кодиран. Проверите понашање овог поља када је премештено у циљни систем.
• Поље Лозинка је кодирано и мигрирано. Осигурајте да раде добро након миграције.

# 17) Тестови регресије

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

Закључак

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

Треба водити рачуна о одржавању делта промена у различитим верзијама.

Тражимо од читалаца да поделе и друга подручја теста на која су наишли током свог рада у корист заједнице тестера.

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

• Шта је ЕТЛ (екстракт, трансформација, учитавање) поступак у складишту података?
• 15 најбољих ЕТЛ алата у 2021. години (комплетна ажурирана листа)
• Како извршити ЕТЛ тестирање помоћу алата Информатица ПоверЦентер
• 10 најбољих алата за мапирање података корисних у ЕТЛ процесу (2021 ЛИСТ)
• Топ 10 ЕТЛ алата за тестирање 2021. године
• Водич за тестирање миграције података: Комплетан водич
• 13 најбољих алата за миграцију података за потпуну интегритет података (ЛИСТА 2021)
• Водич за тестирање складишта података ЕТЛ (комплетан водич)