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

Какво е ETL?
ETL стойки за Извличане-Трансформиране-Зарежданеи описва как данните се преместват от изходна система в хранилище за данни. Данните се извличат от OLTP база данни, трансформират се, за да съответстват на схемата на хранилището за данни, и се зареждат в базата данни на хранилището. Много хранилища включват и данни от системи, които не са OLTP, като текстови файлове, стари приложения и електронни таблици.
Например, един магазин за търговия на дребно може да има отделни отдели, като например продажби, маркетинг и логистика. Всеки отдел обработва информацията за клиентите независимо и начинът, по който всеки от тях съхранява тези данни, е различен. Отделът за продажби може да съхранява записи по име на клиента, докато маркетинговият отдел използва идентификатор на клиента.
Ако бизнес екипите искат да прегледат пълната история на покупките на даден клиент в различни маркетингови кампании, несвързаните данни правят това много досадно. Решението е да се използва DataWarehouse да съхранява информация от различни източници в унифицирана структура, използвайки ETL. ETL може да трансформира различни набори от данни в унифицирана структура, така че BI инструментите по-късно да могат да извличат смислени анализи и отчети.
Следната диаграма показва потока на процеса на ETL тестване и основните концепции, които ще използвате в това ръководство:
1) Екстракт
- Извличане на релевантни данни от една или повече изходни системи.
2) Трансформирайте
- Трансформирайте данните във формат DW (Data Warehouse).
- Ключове за изграждане: ключът е един или повече атрибути на данни, които уникално идентифицират даден обект. Различни видове ключове са първичен ключ, алтернативен ключ, външен ключ, съставен ключ и сурогатен ключ. Хранилището за данни притежава тези ключове и никога не позволява на други лица да ги присвояват.
- Почистване на данни: след извличане на данните, те преминават към следващата фаза на почистване и съгласуване. Почистването поправя пропуски и идентифицира грешки. Съгласуването разрешава конфликти между несъвместими набори от данни, така че те да могат да се използват в корпоративно хранилище за данни. Системата също така създава метаданни, които помагат за диагностициране на проблеми в изходната система и подобряване на качеството на данните.
3) Зареждане
- Зареждане на данни в DW (Data Warehouse).
- Изграждане на агрегати: агрегатът обобщава и съхранява данни от таблица с факти за подобряване на производителността на заявките на крайните потребители.
Какво е ETL тестване?
ETL тестването се извършва, за да се гарантира, че данните, заредени от източник към местоназначение, след бизнес трансформация, са точни. То включва и проверка на данните на различните междинни етапи между източника и местоназначението. Тъй като ETL е съкращение от Extract-Transform-Load (Извличане-Трансформиране-Зареждане), ETL тестването обхваща всеки от тези три етапа и точките, където данните се пресичат между тях.
Защо ETL тестването е важно?
След като разберете какво е ETL тестване, следващият въпрос е защо организациите инвестират толкова много усилия в него. Бизнес решенията разчитат на данни, които са правилни, пълни и надеждни, така че една-единствена грешка при трансформация може да се отрази на финансовите отчети, анализите на клиентите и регулаторните оповестявания.
Следните точки обясняват практическата стойност на силното ETL тестване:
- Точност на данните: Това потвърждава, че стойностите, трансформирани от бизнес правилата, съответстват на документираните спецификации за картографиране, предотвратявайки тиха корупция.
- Надеждно отчитане: Таблата за управление и инструментите за бизнес разузнаване зависят от склада, така че проверените ETL канали защитават всеки отчет и ключов показател за ефективност (KPI) надолу по веригата.
- Спазване на нормативната уредба: Индустрии като банковото дело, здравеопазването и застраховането трябва да докажат, че произходът и целостта на данните са запазени от край до край.
- Намалена преработка: Откриването на дефекти в по-нискокачествени среди избягва скъпоструващи презареждания на производството, ръчни съгласувания и грешки, изправени пред клиентите.
- Гаранция за изпълнение: ETL тестването измерва прозорците на натоварване, пропускателната способност и пречките, така че хранилището да продължи да се мащабира с нарастването на обема на данните.
След като тези мотивации са ясни, следващият раздел разглежда структурирания процес, който ETL тестерите следват в реални проекти.
Процес на тестване на ETL
Подобно на други процеси на тестване, ETL също преминава през различни фази. Различните фази на процеса на ETL тестване са следните:
ETL тестването се извършва на пет етапа:
- Идентифициране на източници на данни и изисквания
- Събирането на данни
- Внедряване на бизнес логика и моделиране на размери
- Изграждане и попълване на данни
- Изграждане на отчети
Имайки предвид процеса на високо ниво, нека разгледаме специфичните видове тестове, които се вписват в този жизнен цикъл.
Видове ETL тестване
- Тестване за валидиране на производството
Процес на тестване: Наричан още „балансиране на таблици“ или „съгласуване на производството“, този тип ETL тестване се извършва върху данни, докато те се преместват в производствените системи. За да се подкрепят бизнес решенията, производствените данни трябва да са в правилния ред. Информатика Опцията за валидиране на данни предоставя възможности за автоматизация и управление на ETL тестване, така че производствените системи да не бъдат компрометирани от лоши данни. - Източник към Target Тестване (тестване за валидиране)
Процес на тестване: Този тип тестване валидира дали трансформираните стойности на данните съответстват на очакваните целеви стойности. - Приложение Upgrades
Процес на тестване: Този тип ETL тестване може да се генерира автоматично, спестявайки значително време за разработване на тестове. То проверява дали данните, извлечени от по-старо приложение или хранилище, съвпадат с данните в ново приложение или хранилище. - Тестване на метаданни
Процес на тестване: Тестването на метаданни включва проверки на типа данни, проверки на дължината на данните и проверки на индекси или ограничения. - Тестване за пълнота на данните
Процес на тестване: Тестването за пълнота на данните проверява дали всички очаквани данни са заредени от източника в целевия. Често срещаните тестове включват сравняване и валидиране на броя записи, агрегати и действителни данни между изходните и целевите колони, когато трансформацията е проста или липсва. - Тестване на точността на данните
Процес на тестване: Това тестване гарантира, че данните са точно заредени и трансформирани според очакванията. - Тестване на трансформация на данни
Процес на тестване: Трансформацията на тестовите данни често не може да се постигне с един източник SQL заявка и сравнение на изхода. Може да са необходими множество SQL заявки за всеки ред, за да се проверят правилата за трансформация. - Тестване на качеството на данните
Процес на тестване:Тестовете за качество на данните включват синтактични тестове и референтни тестове. Те предотвратяват грешки в бизнес процесите, причинени от неправилни дати или номера на поръчки.
Синтаксичните тестове отчитат „мръсни“ данни въз основа на невалидни символи, шаблони на символи и неправилен ред на главни или малки букви.
Референтните тестове проверяват данните спрямо модела на данните. Например: Идентификационен номер на клиента.
Тестването на качеството на данните включва също проверки на числа, проверки на дати, проверки на точност, проверки на данни и проверки за нулеви стойности.
- Инкрементално ETL тестване
Процес на тестване: Това тестване проверява целостта на старите и новите данни с добавянето на нови данни. Инкременталното тестване проверява дали вмъкванията и актуализациите се обработват според очакванията по време на инкременталния ETL процес. - Тестване на GUI/навигация
Процес на тестване: Това тестване проверява навигационните и графичните аспекти на отчетите от предния край.
Как да създадете ETL тестов случай
ETL тестването е концепция, която може да се приложи към различни инструменти и бази данни в индустрията за управление на информацията. Целта на ETL тестването е да се гарантира, че данните, заредени от източник към местоназначение след трансформация на бизнеса, са точни. Това включва и проверка на данните на различните междинни етапи между източника и местоназначението.
Докато извършва ETL тестване, ETL тестерът винаги използва два документа:
- ETL картографски листове: ETL листът за картографиране съдържа цялата информация за изходните и целевите таблици, включително всяка колона и нейното търсене в референтните таблици. ETL тестерите трябва да са умели със SQL заявки, тъй като ETL тестването може да включва писане на големи заявки с множество съединения за валидиране на данни на всеки етап. ETL листовете за картографиране предоставят значителна помощ при писане на заявки за проверка на данни.
- Схема на базата данни на източника и целта: Трябва да се държи под ръка, за да се проверят всички детайли в картографските листове.
ETL тестови сценарии и тестови случаи
- Проверка на документ за картографиране
Тестови случаи: Проверете дали съответната ETL информация е предоставена в документа за картографиране. Във всеки документ за картографиране трябва да се поддържа дневник на промените. - Утвърждаване
Тестови случаи:1) Валидирайте структурата на изходната и целевата таблица спрямо съответния документ за съпоставяне.
2) Типът на изходните данни и типът на целевите данни трябва да са еднакви.
3) Дължината на типовете данни както в източника, така и в целта трябва да е еднаква.
4) Проверете дали са посочени типовете и форматите на полетата за данни.
5) Дължината на изходния тип данни не трябва да бъде по-малка от дължината на целевия тип данни.
6) Проверете имената на колоните в таблицата спрямо документа за съпоставяне. - Валидиране на ограничения
Тестови случаи: Уверете се, че ограниченията са дефинирани за конкретната таблица, както се очаква. - Проблеми с последователността на данните
Тестови случаи:1) Типът данни и дължината на даден атрибут могат да варират в различните файлове или таблици, дори когато семантичната дефиниция е една и съща.
2) Злоупотреба с ограниченията на целостта. - Проблеми с пълнотата
Тестови случаи:1) Уверете се, че всички очаквани данни са заредени в целевата таблица.
2) Сравнете броя на записите между източника и целта.
3) Проверете за отхвърлени записи.
4) Проверете дали данните в колоните на целевите таблици не са съкратени.
5) Проверете анализа на граничните стойности.
6) Сравнете уникалните стойности на ключови полета между данните, заредени в хранилището, и изходните данни. - Проблеми с коректността
Тестови случаи:1) Данни, които са с правописни грешки или неточно записани.
2) Нулеви, неуникални или данни извън обхват. - Трансформация
Тестови случаи: Проверете дали всяко бизнес правило и логика на трансформация в документа за съпоставяне са правилно приложени към изходните данни, преди те да попаднат в целевия документ. - Качество на данните
Тестови случаи:1) Проверка на числа: валидиране на числови формати и стойности.
2) Проверка на датата: датите трябва да следват единен формат и да са последователни във всички записи.
3) Проверка на прецизността.
4) Проверка на данните.
5) Проверка за нула. - Нулева проверка
Тестови случаи: Проверете празните стойности, където е указано „Не е нула“ за конкретна колона. - Проверка на дубликат
Тестови случаи:1) Проверете уникалния ключ, първичния ключ и всяка друга колона, която трябва да е уникална според бизнес изискванията, за да потвърдите, че няма дублирани редове.
2) Проверете дали съществуват дублиращи се стойности в някоя колона, извлечена от множество изходни колони и комбинирана в една колона.
3) Съгласно изискванията на клиента, уверете се, че няма дубликати в комбинация от множество колони в целевия файл. - Валидиране на дата
Тестови случаи: Стойностите на датите се използват в много области на ETL разработката:1) Да се знае датата на създаване на реда.
2) Идентифицирайте активните записи от гледна точка на разработката на ETL.
3) Идентифицирайте активните записи от гледна точка на бизнес изискванията.
4) Понякога, въз основа на стойностите на датите, се генерират актуализации и вмъквания. - Пълна проверка на данните
Тестови случаи:1) Валидирайте пълния набор от данни в изходната и целевата таблица, като използвате минус заявка като най-добро решение.
2) Трябва да изпълните уравненията източник минус цел и цел минус източник.
3) Ако заявката minus върне някаква стойност, тези редове трябва да се считат за несъответстващи.
4) Свържете редовете между източника и целта, използвайки оператор intersect.
5) Броят, върнат от intersect, трябва да съвпада с индивидуалния брой на изходните и целевите таблици.
6) Ако минус заявка върне редове и броят на пресечните точки е по-малък от броя на източника или целта, съществуват дублирани редове. - Чистота на данните
Тестови случаи: Ненужните колони трябва да бъдат изтрити, преди да се заредят в етапната област.
Видове грешки в ETL
Дори при силни тестови случаи, ETL конвейерите могат да се провалят по различни начини. Изображението по-долу обобщава категориите грешки, за които трябва да следите, а таблицата по-долу описва всяка една от тях.
| Видове грешки | Descriptйон |
|---|---|
| Грешки в потребителския интерфейс/козметични грешки |
• Свързано с графичния потребителски интерфейс на приложението • Стил на шрифта, размер на шрифта, цветове, подравняване, правописни грешки, навигация и т.н. |
| Грешка, свързана с анализ на гранични стойности (BVA). | • Минимални и максимални стойности |
| Грешка, свързана с разделяне на класове на еквивалентност (ECP). | • Валиден и невалиден тип |
| Входно/изходни грешки |
• Не се приемат валидни стойности • Приемат се невалидни стойности |
| Грешки в изчисленията |
• Математически грешки • Крайният резултат е грешен |
| Грешки в условията на натоварване |
• Не позволява множество потребители • Не позволява очаквано от клиента натоварване |
| Грешки в условията на състезанието |
• Срив на системата и замръзване • Системата не може да изпълнява клиентски платформи |
| Грешки в контрола на версиите |
• Няма съвпадение на логото • Няма налична информация за версията • Обикновено се среща в Тестване на регресия |
| H/W грешки | • Устройството не отговаря на приложението |
| Помощ Източник на грешки | • Грешки в помощните документи |
Тестване на Data Warehouse
Тестване на Data Warehouse е метод за тестване, при който данните в хранилището за данни се проверяват за целостност, надеждност, точност и съгласуваност, за да отговарят на рамката за данни на компанията. Основната цел на тестването на хранилището за данни е да се гарантира, че интегрираните данни в хранилището са достатъчно надеждни, за да може компанията да взема решения. Докато ETL тестването се фокусира върху движението на данни, тестването на хранилището за данни обхваща по-широкия слой за съхранение и отчитане, който ETL в крайна сметка захранва.
Разлика между тестване на бази данни и ETL тестване
Въпреки че и двете дисциплини работят със структурирани данни, те отговарят на различни въпроси. Таблицата по-долу подчертава практическото различие:
| ETL тестване | Тестване на база данни |
|---|---|
| Проверява дали данните са преместени според очакванията. | Основната цел е да се провери дали данните отговарят на правилата и стандартите, определени в модела на данните. |
| Проверява дали броячите в източника и целта съвпадат и дали трансформираните данни са според очакванията. | Проверява дали няма осиротели записи и дали са поддържани връзките между външния и първичния ключ. |
| Проверява дали връзките между външните първични ключове са запазени по време на ETL. | Проверява дали няма излишни таблици и дали базата данни е оптимално нормализирана. |
| Проверява за дублиране в заредените данни. | Проверява дали липсват данни в колоните, където е необходимо. |
Тестване на производителността в ETL
Тестване на производителността в ETL е техника за тестване, която гарантира, че ETL системата може да се справи с натоварването от множество потребители и транзакции. Основната цел на ETL Тестване на производителността е да се оптимизира и подобри производителността на сесиите чрез идентифициране и елиминиране на пречки в производителността. Изходните и целевите бази данни, съпоставянията, сесиите и самата система могат да съдържат пречки.
Един от най-добрите инструменти, използвани за тестване и настройване на производителността, е Informatica.
Отговорности на ETL тестер
Ключовите отговорности на ETL тестера са разделени в три категории:
- Сценична маса / SFS или MFS
- Приложена логика на бизнес трансформация
- Target зареждане на таблица от файл или таблица на етапа след прилагане на трансформация
Някои от ежедневните отговорности на ETL тестер са:
- Тествайте софтуера ETL
- Тестови компоненти на ETL хранилището за данни
- Изпълнявайте тестове, базирани на данни, от бекенд системата
- Създаване, проектиране и изпълнение тестови случаи, тестови планове и тестови снопове
- Идентифицирайте проблеми и предложете решения за потенциални проблеми
- Одобрете изискванията и спецификациите на дизайна
- Валидиране на трансфери на данни и тестване на плоски файлове
- Пишете SQL заявки за различни сценарии, като например тестове за броене
Автоматизация на ETL тестване
Общата методология на ETL тестването е използването на SQL скриптове или визуално „огледално“ представяне на данните. Тези подходи са времеемки, податливи на грешки и рядко предоставят пълни резултати. покритие на тестаЗа ускоряване на изпълнението, подобряване на покритието, намаляване на разходите и подобряване дефект За откриване в производствени и развойни среди, автоматизацията е актуална нужда. Един такъв инструмент е Informatica.
Съвременните екипи също така съчетават традиционната автоматизация с помощници, подпомагани от изкуствен интелект, които предлагат тестове за трансформация, генерират синтетични изходни данни и сигнализират за отклонение на схемата, освобождавайки тестерите да се съсредоточат върху сложна бизнес логика, а не върху повтаряща се поддръжка на скриптове.
Най-добри практики за ETL тестване
- Уверете се, че данните са трансформирани правилно.
- Без загуба или съкращаване на данни, прогнозираните данни трябва да бъдат заредени в хранилището за данни.
- Уверете се, че ETL приложението правилно отхвърля невалидни данни, замества ги със стойности по подразбиране, където е приложимо, и ги докладва.
- Потвърдете, че данните се зареждат в хранилището в рамките на предписаните и очаквани срокове, за да валидирате мащабируемостта и производителността.
- Всички методи трябва да имат подходящи модулни тестове, независимо от видимостта.
- За да се измери тяхната ефективност, всички модулни тестове трябва да използват подходящи техники за покритие.
- Стремете се към едно твърдение на тестов случай.
- Създаване на единични тестове които са насочени към изключения.
Разгледайте - Въпроси и отговори за интервю за ETL тестване





