Меню

Тестове за проверка на данните за проекти за ETL и миграция на данни

  • Основен
  • Други
  • Тестове за проверка на данните за проекти за ETL и миграция на данни

data validation tests

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

Този урок описва проекти за миграция на ETL и данни и обхваща проверки или тестове за проверка на данни за проекти за миграция на ETL / данни за подобрено качество на данните:

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

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

Проверка на данни за ETL и проекти за миграция на данни

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

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

Какво е проверка на данните?

Потвърждаване на данни

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

Пример: Адресът на студент в таблицата за ученици е 2000 знака в системата източник. Проверката на данните проверява дали точно същата стойност се намира в целевата система. Той проверява дали данните са били съкратени или някои специални знаци са премахнати.

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

Защо да потвърждаваме данните за ETL проекти?

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

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

целева и изходна система

Пример: Приложението за електронна търговия има ETL работни места, като избира всички OrdersIds спрямо всеки CustomerID от таблицата Orders, която обобщава TotalDollarsSpend от клиента и го зарежда в нова таблица CustomerValue, като всеки клиент се класира като клиент с висока / средна / ниска стойност на някакъв сложен алгоритъм.

Прост тест за проверка на данни е да се види, че CustomerRating е правилно изчислен.

Друг тест е да се провери дали TotalDollarSpend правилно се изчислява без дефекти при закръгляване на стойностите или препълване на максимална стойност.

Защо да проверявам данните за проекти за миграция на данни?

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

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

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

Пример: Да предположим, че за приложението за електронна търговия таблицата Orders, която имаше 200 милиона реда, беше мигрирана към системата Target на Azure. Прост тест за проверка на данни е да се провери всички 200 милиона реда данни са налични в целевата система.

Друг тест може да бъде да се потвърди, че форматите на датите съвпадат между източника и целевата система.

Има различни аспекти, които тестерите могат да тестват в такива проекти като функционални тестове, тестове за производителност, тестове за сигурност, инфра тестове, тестове E2E, регресионни тестове и т.н.

Препоръчително четене => Тестване на миграцията на данни , Урок за тестване на хранилище на данни за ETL

В тази статия ще разгледаме само аспекта на данните от тестовете за ETL и миграционни проекти.

Лист за картографиране на данни

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

Листовете за картографиране на данни съдържат много информация, взета от модели на данни, предоставени от Data Architects. Първоначално тестерите могат да създадат опростена версия и могат да добавят повече информация, докато продължават. Вижте примера на Лист за картографиране на данни по-долу - родителска таблица

Изтеглете шаблон от Опростен лист за картографиране на данни

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

# 1) Еднородност на данните

Тестовете за еднородност на данните се провеждат, за да се провери дали действителната стойност на обекта има точното съвпадение на различни места. Тук имаме два вида тестове:

(i) Проверки в рамките на същата схема:

  • Обектът на данни може да съществува в две таблици в рамките на една и съща схема (или система източник, или целева система)
  • Пример: Както можете да видите на изображението по-долу, ProductID присъства в таблицата OrderDetails и Products. Направете точна проверка на съвпадението за ProductId, представен в таблицата OrderDetails vs Products.

Опростен лист за картографиране на данни

(ii) Проверки по схеми:

  • Обектът на данни може да бъде мигриран такъв, какъвто е, в целевата схема, т.е. той присъства в системата източник, както и в целевата система
  • Пример: Както можете да видите на горното изображение, ProductID присъства в таблицата Products в системата източник и таблицата Products в целевата система. Направете точна проверка на съвпадението за ProductId в таблицата Products в системата източник на ProductId в таблицата Products в целевата система.

Забележка: Най-добре е да маркирате (цветен код) съвпадащи обекти на данни в листа за картографиране на данни за бърза справка.

# 2) Присъствие на субект

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

(i) Проверете дали всички таблици (и колони), които имат съответно присъствие както в източника, така и в целта, съвпадат. Извличаме списък с всички таблици (и колони) и правим сравнение на текст. Този тест за вменяемост работи само ако се използват едни и същи имена на обекти.

Понякога се използват различни имена на таблици и следователно директното сравнение може да не работи. Може да се наложи да картографираме тази информация в листа за картографиране на данни и да я проверим за грешки.

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

  • Пример: Както можете да видите на изображението по-долу, CustDemographic Table присъства в целевата система, а не в системата източник.
  • Полето CustomerType в таблицата Клиенти съдържа данни само в системата източник, а не в целевата система.

стрела (точност на данните)

# 3) Точност на данните

Както подсказва името, проверяваме дали данните са логически точни. Има две категории за този тип тест. С това тестерът може да засече проблемите с качеството на данните дори в системата източник.

Целостта на данните

(изображение източник )

Забележка: Изпълнете този тест в целевата система и проверете обратно в системата източник за дефекти.

(i) Нецифрен тип: При тази класификация ние проверяваме точността на нечисловото съдържание. Примери са Имейли, ПИН кодове, Телефон във валиден формат.

(ii) Анализ на домейн: При този тип тест избираме домейни от данни и проверяваме за грешки. Има три групи за това:

  • Въз основа на стойност: Тук създаваме списък със стойности, които могат да възникнат за дадено поле (колона в таблицата). След това проверете дали стойностите на колоните са подмножество от нашия списък.
    • Пример: Проверете дали колоната „Пол“ съдържа или M, или F.
  • Въз основа на обхвата: Тук задаваме минимален и максимален диапазон за валидни стойности на данни за колона, базирани на логически или бизнес разсъждения. След това проверяваме дали стойностите на колоните попадат в този диапазон.
    • Пример: 0 до 120 за Възраст.
  • Референтен файл : Тук системата използва външен файл за валидност.
    • Пример: Валидни ли са кодовете на държавите, избират ли точната стойност от референтния файл, еднакви ли са кодовете на държавите между QA и производствената среда? Ако референтният файл е актуализирал код на държава, правилно ли е актуализиран в DB?

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

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

Тук има две групировки:

недефинирана препратка към основния c ++

(i) Дизайн на метаданни: Първата проверка е да се провери дали моделът на данни е правилно проектиран според бизнес изискванията за целевите таблици. Архитектите на данни могат да мигрират обекти на схемата или да правят модификации, когато проектират целевата система.

Следващата проверка трябва да бъде да се провери дали правилните скриптове са създадени с помощта на моделите на данни.

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

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

  • Проверка на типа данни: Пример: Общите продажби ще работят ли правилно с десетичен (8, 16 или 20 байта) или двоен тип?
  • Проверка на дължината на данните : Пример: Ще бъде ли достатъчна дължината на данните за полето Адрес с 500 символа? Възможно е да се извърши миграция на данни, тъй като към компанията се добавя нова география. Адресите на новата география може да имат изключително дълъг формат и придържането към оригиналната дължина може да доведе до грешка в случай на употреба.
  • Проверка на индекса: Пример: Прави ли се индексиране за колоната OrderId в целевата система? Какво ще стане, ако се случи сливане на компании, което изисква миграция на данни и таблицата Orders се увеличи 100 пъти по размер в целевата система?
  • Проверка на метаданни в различни среди: При тази проверка проверете дали метаданните съвпадат между QA теста и производствената среда. Тестовете могат да преминат в QA среда, но да се провалят в други среди.

(ii) Делта промяна: Тези тестове разкриват дефекти, които възникват, когато проектът е в ход и по средата има промени в метаданните на системата източник и не са внедрени в целевите системи.

Пример: Ново поле CSI (Индекс на удовлетвореност на клиента) беше добавено към таблицата на клиентите в източника, но не успя да бъде направено в целевата система.

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

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

родителска таблица

(изображение източник )

За външните ключове трябва да проверим дали в дъщерната таблица има записи сираци, където използваният външен ключ не присъства в родителската таблица.

Проверка на пълнотата на данните

Пример: Клиентската таблица има CustomerID, който е първичен ключ. Таблицата за поръчки има CustomerID като външен ключ. Таблицата за поръчки може да има идентификатор на клиента, който не е в таблицата на клиентите. Трябва да имаме тестове, за да разкрием такива нарушения на ограниченията на целостта. Таблицата за картографиране на данни ще ви даде яснота кои таблици имат тези ограничения.

Забележка: Изпълнете този тест в целевата система и проверете обратно в системата източник, ако има дефекти.

# 6) Пълнота на данните

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

Има два вида тестове:

(i) Брой записи: Тук сравняваме общия брой записи за съвпадение на таблици между източника и целевата система. Това е бърза проверка на здравословното състояние, за да се провери след пускането на ETL или миграцията. Имаме дефект, ако броят не съвпада.

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

(ii) Профилиране на данни в колона: Този тип тест за здравословно състояние е ценен, когато броят на записите е огромен. Тук създаваме логически набори от данни, които намаляват броя на записите и след това правим сравнение между източника и целта.

  • Където е възможно, филтрирайте всички уникални стойности в колона, например, ProductID може да се появява няколко пъти в таблицата OrderDetails. Изберете уникален списък за ProductID както от целевите, така и от изходните таблици и потвърдете. Това значително намалява броя на записите и ускорява тестовете за здравословно състояние.
  • Подобно на горните тестове, ние също можем да изберем всички основни колони и да проверим дали KPI (минимална, максимална, средна, максимална или минимална дължина и т.н.) съвпадат между целевата и изходната таблица. Пример: Вземете средни, минимални и максимални стойности от колоната Цена в OrderDetails и сравнете тези стойности между целевите и изходните таблици за несъответствия.
  • Може да се направи друга проверка за Null стойности. Изберете важни колони и филтрирайте списък с редове, където колоната съдържа Null стойности. Сравнете тези редове между целевата и изходната системи за несъответствие.

Срокове

# 7) Преобразуване на данни

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

По-долу е даден кратък списък от тестове, обхванати от това:

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

  • Пример: Кодът ETL може да има логика за отхвърляне на невалидни данни. Проверете това спрямо изискванията.
  • Кодът ETL може също да съдържа логика за автоматично генериране на определени ключове като заместващи ключове. Трябва да имаме тестове, за да проверим правилността (техническа и логическа) на тях.
  • Проверете правилността на присъединяването или разделянето на стойностите на полетата след извършване на ETL или миграция.
  • Направете тестове за проверка на референтни проверки на целостта. Например, тип дефект може да бъде ProductId, използван в таблицата Поръчки не присъства в родителската таблица Продукти. Направете тест, за да проверите как се държат записите сираци по време на работа с ETL.
  • Понякога липсващите данни се вмъкват с помощта на ETL кода. Проверете верността на тези.
  • ETL или Migration скриптовете понякога имат логика за коригиране на данните. Проверете дали работи корекция на данни.
  • Проверете дали на потребителите се съобщават невалидни / отхвърлени / грешни данни.
  • Създайте електронна таблица със сценарии на входни данни и очаквани резултати и ги утвърдете с бизнес клиента.

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

  • Пример: Какво се случва, когато TotalSales на стойност 1 трилион се изпълнят чрез ETL работа? Случаите от край до край ли работят? Идентифицирайте полета, които потенциално могат да имат големи стойности, и изпълнете тестове с тези големи стойности. Те трябва да включват числови и нечислови стойности.
  • За полета с дати, включително целия диапазон от очаквани дати - високосна година, 28/29 дни за февруари. 30, 31 дни за други месеци.

# 8) Уникалност или дублиране на данни

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

  • Пример: Филтрирайте за дублирани данни и проверете дали са автентични. Например, Зависимият от служителя запис съдържа едни и същи данни за братя и сестри два пъти.
  • Потребителският телефонен номер трябва да е уникален в системата (бизнес изискване).
  • Бизнес изискването казва, че комбинация от ProductID и ProductName в таблицата Products трябва да бъде уникална, тъй като ProductName може да бъде дублирана.

# 9) Задължително

При този тип тест идентифицирайте всички полета, отбелязани като Задължителни и проверете дали задължителните полета имат стойности. Ако има стойности по подразбиране, свързани с поле в DB, ​​проверете дали то е попълнено правилно, когато данните не са там.

  • Пример: Ако BillDate не е въведен, тогава CurrentDate е BillDate.

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

Винаги документирайте тестове, които потвърждават, че работите с данни от договорените срокове.

  • Пример: ProductDiscount бе актуализиран преди 15 дни и състоянието на бизнес домейн се променя на всеки седем дни. Това означава, че тестовете ви не се извършват с правилните отстъпки.
  • Отчет за прогнозен анализ за индекса на удовлетвореност на клиентите трябваше да работи с последните 1-седмични данни, които бяха седмица за насърчаване на продажбите на Walmart. Но ETL работата беше проектирана да работи с честота от 15 дни. Това е основен дефект, който тестерите могат да открият.

# 11) Null данни

В този тип тест ние се фокусираме върху валидността на нулеви данни и проверка, че важната колона не може да бъде нула.

  • Пример: Филтрирайте всички нулеви данни и проверете дали е разрешено null.
  • Ако има важни колони за бизнес решения, уверете се, че нулите не присъстват.

# 12) Проверка на обхвата

Субектът на данни, където диапазоните имат бизнес смисъл, трябва да бъде тестван.

  • Пример: Количеството на поръчката на фактура не може да бъде повече от 5K в категорията софтуер.
  • Възрастта не трябва да бъде повече от 120.

# 13) Бизнес правила

Документирайте всички бизнес изисквания за полета и изпълнете тестове за същото.

  • Пример: Ресурси на възраст под 20 години не са допустими. Проверките за проверка на данните се изискват, ако това правило се прилага към данните.
  • Датата на прекратяване трябва да бъде нула, ако статусът на служител активен е Истина / Починал.
  • FROM данните трябва да са по-малко от TO Date.
  • Правете суми за покупка на ниво артикул до суми на ниво поръчка

# 14) Обобщени функции

Обобщените функции са вградени във функционалността на базата данни. Документирайте всички агрегати в системата източник и проверете дали използването на агрегат дава същите стойности в целевата система (сума, макс., Мин., Брой).

Доста често инструментите в системата източник се различават от целевата система. Проверете дали и двата инструмента изпълняват агрегирани функции по един и същи начин.

# 15) Съкращаване на данни и закръгляване

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

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

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

  • Пример: Двубайтовите символи за FirstName на китайски бяха приети в кодираната система източник. Проверете поведението на това поле при преместване в целевата система.
  • Полето Парола беше кодирано и мигрирано. Уверете се, че работят добре след миграцията.

# 17) Тестове за регресия

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

Заключение

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

Трябва да се внимава да се поддържат делта промените във всички версии.

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

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

^