Меню

Тести перевірки даних для проектів ETL та міграції даних

  • Головна
  • Інший
  • Тести перевірки даних для проектів ETL та міграції даних

data validation tests

Спробуйте Наш Інструмент Для Усунення Проблем

Цей посібник описує проекти ETL та міграцію даних та охоплює перевірки та тести перевірки даних для проектів ETL / міграції даних для покращення якості даних:

Ця стаття призначена для тестувальників програмного забезпечення, які працюють над проектами ETL або Data Migration і зацікавлені зосередити свої тести лише на аспектах якості даних. Такі типи проектів мають величезний обсяг даних, які зберігаються у вихідному сховищі, а потім оперуються деякою логікою, наявною в програмному забезпеченні, і переміщуються до цільового сховища.

Тести перевірки даних гарантують, що дані, що містяться в кінцевих цільових системах, є достовірними, точними, відповідно до бізнес-вимог, і придатними для використання в системі реального виробництва.

Перевірка даних для ETL та проектів міграції даних

Кількість аспектів якості даних, які можна перевірити, величезна, і цей перелік нижче дає вступ до цієї теми.

як відкрити swf файл -

Що ви дізнаєтесь:

Що таке перевірка даних?

Перевірка даних

Простіше кажучи, перевірка даних - це акт підтвердження того факту, що дані, які переміщуються як частина ETL або завдання міграції даних, є послідовними, точними та повними в цільових робочих системах, що відповідають бізнес-вимогам.

Приклад: Адреса студента у таблиці Студент у вихідній системі складала 2000 символів. Перевірка даних перевіряє, чи точно таке саме значення знаходиться в цільовій системі. Він перевіряє, чи дані були усічені, чи певні спеціальні символи видалено.

У цій статті ми обговоримо багато з цих перевірок перевірки даних. Як тестувальники ETL або проектів міграції даних, це додає величезної цінності, якщо ми виявимо проблеми якості даних, які можуть поширюватися на цільові системи та порушувати цілі бізнес-процеси.

Навіщо перевіряти дані для проектів ETL?

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

Тут перевірка даних необхідна, щоб підтвердити, що дані, які завантажуються в цільову систему, є повноцінними, точними та відсутністю втрати даних або розбіжностей.

цільова і джерельна система

Приклад: Додаток для електронної комерції має завдання ETL, які обирають усі ідентифікатори замовлень по кожному ідентифікатору замовника з таблиці замовлень, що підсумовує загальну суму витрачених клієнтом і завантажує її в нову таблицю замовника, позначаючи кожного замовника як високу / середню / низьку вартість. на якомусь складному алгоритмі.

Простий тест перевірки даних полягає в тому, щоб перевірити, чи правильно розраховано Оцінку замовника.

Інший тест - перевірити правильність обчислення TotalDollarSpend без дефектів округлення значень або перевищення максимальних значень.

Навіщо перевіряти дані для проектів міграції даних?

У проектах міграції даних величезні обсяги даних, які зберігаються у сховищі джерела, переносяться у різні цільові сховища з багатьох причин, таких як оновлення інфраструктури, застарілі технології, оптимізація тощо. Наприклад, компанії можуть перенести свій величезний склад даних із застарілих систем на новіші та надійніші рішення на AWS або Azure.

Основним мотивом таких проектів є переміщення даних із вихідної системи в цільову систему таким чином, щоб цільові дані були дуже корисними без будь-яких перешкод чи негативного впливу на бізнес.

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

Приклад: Припустимо, для програми електронної комерції таблиця Замовлення, яка мала 200 мільйонів рядків, була перенесена до цільової системи на Azure. Простий тест перевірки даних полягає в тому, щоб перевірити, чи всі 200 мільйонів рядків даних доступні в цільовій системі.

Іншим тестом може бути підтвердження відповідності форматів дат між вихідною та цільовою системою.

Існують різні аспекти, які тестувальники можуть перевірити в таких проектах, як функціональні тести, тести продуктивності, тести безпеки, інфратести, тести E2E, регресійні тести тощо.

Рекомендована література => Тестування міграції даних , Підручник з тестування сховища даних ETL

У цій статті ми розглянемо лише аспект даних тестів для проектів ETL та міграції.

Лист зіставлення даних

Для початку створіть аркуш зіставлення даних для вашого проекту даних. Зіставлення даних - це процес узгодження сутностей між вихідною та цільовою таблицями. Почніть із документування всіх таблиць та їх сутностей у вихідній системі в електронній таблиці. Тепер задокументуйте відповідні значення для кожного з цих рядків, які, як очікується, збігаються в цільових таблицях. Запишіть правила трансформації в окремій колонці, якщо такі є.

Аркуші відображення даних містять багато інформації, зібраної з моделей даних, наданих Data Architects. Спочатку тестувальники могли створити спрощену версію та могли додавати більше інформації в процесі роботи. Див. Приклад таблиці зіставлення даних нижче - батьківська таблиця

Завантажте шаблон із Спрощена таблиця зіставлення даних

Тести перевірки даних

# 1) Рівномірність даних

Проводяться тести на однорідність даних, щоб переконатися, що фактичне значення сутності точно відповідає в різних місцях. Тут ми маємо два типи тестів:

(i) Перевірки в рамках однієї схеми:

  • Сутність даних може існувати у двох таблицях в одній схемі (або вихідна система, або цільова система)
  • Приклад: Як ви можете бачити на зображенні нижче, ProductID присутній у таблиці OrderDetails and Products. Виконайте точну перевірку відповідності ProductId, присутньої в таблиці OrderDetails vs Products.

Спрощений аркуш картографії1

(ii) Перевірка схем:

  • Сутність даних може бути перенесена як є у цільову схему, тобто вона присутня у вихідній системі, а також цільовій системі
  • Приклад: Як ви можете бачити на зображенні вище, ProductID присутній у таблиці Products у вихідній системі та таблиці Products у цільовій системі. Виконайте точну перевірку відповідності ProductId у таблиці Products у вихідній системі ProductId у таблиці Products у цільовій системі.

Примітка: Найкраще виділити (кольоровий код) відповідні сутності даних на аркуші картографування даних для швидкого довідки.

# 2) Присутність сутності

У цьому типі тесту нам потрібно перевірити, чи всі сутності (таблиці та поля) співпадають між джерелом та ціллю. Є дві можливості: сутність може бути присутнім або відсутнім відповідно до проекту Моделі даних.

(i) Перевірте, чи всі таблиці (і стовпці), які мають відповідну присутність як у джерелі, так і в цілі, збігаються. Витягуємо список усіх таблиць (і стовпців) і робимо порівняння тексту. Цей тест на розумність працює лише в тому випадку, якщо однакові назви об'єктів використовуються в усіх.

Іноді використовуються різні назви таблиць, і, отже, пряме порівняння може не спрацювати. Можливо, нам доведеться зіставити цю інформацію на аркуші зіставлення даних та перевірити її на наявність помилок.

Інша можливість - відсутність даних. Бувають випадки, коли модель даних вимагає, щоб таблиця у вихідній системі (або стовпці) не мала відповідної присутності в цільовій системі (або навпаки). Проведіть тести, щоб підтвердити це.

порівняти два файли рядок за рядком
  • Приклад: Як ви можете бачити на зображенні нижче, таблиця CustDemographic присутня в цільовій системі, а не у вихідній системі.
  • Поле CustomerType у таблиці Customers містить дані лише у вихідній системі, а не в цільовій системі.

дротик (точність даних)

# 3) Точність даних

Як випливає з назви, ми перевіряємо, чи дані логічно точні. Існує дві категорії для цього типу тестування. Завдяки цьому тестер може виявити проблеми з якістю даних навіть у вихідній системі.

Цілісність даних

(зображення джерело )

Примітка: Запустіть цей тест у цільовій системі та перевірте у вихідній системі на наявність дефектів.

(i) Нечисловий тип: За цією класифікацією ми перевіряємо точність нечислового вмісту. Приклади є Електронні листи, Пін-коди, Телефон у дійсному форматі.

(ii) Аналіз домену: У цьому типі тесту ми відбираємо домени даних і перевіряємо наявність помилок. Для цього існує три групи:

  • На основі значення: Тут ми створюємо список значень, які можуть мати місце для поля (стовпець у таблиці). Потім перевірте, чи значення стовпців є підмножиною нашого списку.
    • Приклад: Переконайтеся, що стовпець 'Гендер' містить або M, або F.
  • На основі діапазону: Тут ми встановлюємо мінімальний та максимальний діапазон для дійсних значень даних для стовпця на основі логічних або ділових міркувань. Потім ми перевіряємо, якщо значення стовпців потрапляють у цей діапазон.
    • Приклад: Від 0 до 120 для віку.
  • Довідковий файл : Тут система використовує зовнішній файл дійсності.
    • Приклад: Чи дійсні коди країн, чи правильно вони вибирають значення з довідкового файлу, чи однакові коди країн між QA та виробничим середовищем? Якщо в довідковому файлі оновлено код країни, чи правильно він оновлюється в БД?

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

Під час перевірки метаданих ми перевіряємо, що визначення даних таблиці та стовпця для цілі правильно розроблені, і після їх розробки вони виконуються відповідно до специфікацій проектування моделі даних.

Тут є дві групи:

(i) Дизайн метаданих: Перша перевірка полягає у підтвердженні того, що модель даних правильно розроблена відповідно до бізнес-вимог до цільових таблиць. Архітектори даних можуть мігрувати сутності схеми або можуть вносити зміни під час проектування цільової системи.

Наступною перевіркою має бути перевірка того, що правильні сценарії були створені за допомогою моделей даних.

Для кожної категорії нижче ми спочатку перевіряємо, чи відповідають метадані, визначені для цільової системи, бізнес-вимогам, а по-друге, чи точно створені таблиці та визначення полів.

Нижче наведено кілька перевірок метаданих:

  • Перевірка типу даних: Приклад: Чи правильно працюватиме загальний обсяг продажів із десятковим (8, 16 або 20 байтами) чи подвійним типом?
  • Перевірка довжини даних : Приклад: Чи буде довжина даних для поля Адреса достатньою для 500 символів? Це може бути випадок, коли міграція даних здійснюється у міру того, як до компанії додається нова географія. Адреси нової географії можуть мати надзвичайно довгий формат, і дотримання оригінальної довжини може спричинити помилку у випадку використання.
  • Перевірка індексу: Приклад: Чи проводиться індексація стовпця OrderId у цільовій системі? Що, якби відбулося злиття компаній, що вимагало міграції даних, і таблиця Замовлення зросла в цільовій системі в 100 разів?
  • Перевірка метаданих у різних середовищах: За допомогою цієї перевірки переконайтеся, що метадані відповідають тесту контролю якості та виробничому середовищу. Тести можуть проходити в середовищі контролю якості, але невдало в інших середовищах.

(Ii) Delta change: Ці тести виявляють дефекти, що виникають, коли проект триває, а в середині є зміни в метаданих вихідної системи, які не були впроваджені в цільові системи.

Приклад: Нове поле CSI (Індекс задоволеності клієнтів) було додано до таблиці клієнтів у джерелі, але не вдалося внести його до цільової системи.

# 5) Цілісність даних

Тут ми в основному перевіряємо обмеження цілісності, такі як Зовнішній ключ, Посилання на первинний ключ, Унікальний, За замовчуванням тощо.

батьківська таблиця

(зображення джерело )

Що стосується зовнішніх ключів, нам потрібно перевірити, чи є в дочірній таблиці записи-сироти, де використаний зовнішній ключ відсутній у батьківській таблиці.

Перевірка повноти даних

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

Примітка: Запустіть цей тест у цільовій системі та перевірте у вихідній системі, якщо є дефекти.

# 6) Повнота даних

Це тести на розумність, які виявляють відсутність записів або підрахунків рядків між вихідною та цільовою таблицями і можуть бути запущені часто після автоматизації.

Існує два типи тестів:

(i) Кількість записів: Тут ми порівнюємо загальну кількість записів для збігу таблиць між вихідною та цільовою системою. Це швидка перевірка стану здоров'я, щоб перевірити після запуску завдання ETL або міграції. У нас є дефект, якщо підрахунок не збігається.

Іноді під час виконання роботи є відхилені записи. Деякі з них можуть бути дійсними. Але як тестувальник, ми підкреслюємо це.

(ii) Профілювання даних стовпців: Цей тип перевірки розумності цінний, коли кількість записів величезна. Тут ми створюємо логічні набори даних, які зменшують кількість записів, а потім проводимо порівняння між джерелом і ціллю.

  • Де це можливо, відфільтруйте всі унікальні значення у стовпці, наприклад, ProductID може траплятися кілька разів у таблиці OrderDetails. Виберіть унікальний список ProductID із цільової та вихідної таблиць та підтвердьте. Це значно зменшує кількість записів і пришвидшує перевірку розумності.
  • Як і вищевказані тести, ми також можемо вибрати всі основні стовпці та перевірити, чи збігаються KPI (мінімальна, максимальна, середня, максимальна чи мінімальна довжина тощо) між цільовою та вихідною таблицями. Приклад: Візьміть середнє, мінімальне та максимальне значення зі стовпця Ціна в OrderDetails і порівняйте ці значення між цільовою та вихідною таблицями на предмет невідповідностей.
  • Ще одну перевірку можна зробити для значень Null. Виберіть важливі стовпці та відфільтруйте список рядків, де стовпець містить нульові значення. Порівняйте ці рядки між цільовою та вихідною системами на предмет невідповідності.

Графіки

# 7) Перетворення даних

Ці тести складають основні тести проекту. Перегляньте документ з вимогами, щоб зрозуміти вимоги до трансформації. Підготуйте тестові дані у вихідних системах, щоб відобразити різні сценарії трансформації. Вони мають безліч тестів і повинні бути детально висвітлені в темах тестування ETL.

Нижче наводиться короткий перелік тестів, охоплених цим:

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

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

(ii) Крайові випадки: Переконайтеся, що логіка перетворення добре тримається на межах.

  • Приклад: Що відбувається, коли TotalSales із вартістю 1 трлн. Виконується через роботу ETL? Чи спрацьовують наскрізні справи? Визначте поля, які потенційно можуть мати великі значення, та проведіть тести з цими великими значеннями. Вони повинні включати числові та нечислові значення.
  • Для полів дат, включаючи весь діапазон очікуваних дат - високосний рік, 28/29 днів лютого. 30, 31 день для інших місяців.

# 8) Унікальність даних або тиражування

У цьому типі тесту визначте стовпці, які повинні мати унікальні значення відповідно до моделі даних. Крім того, візьміть до уваги ділову логіку, щоб відсіяти такі дані. Запустіть тести, щоб перевірити, чи вони є унікальними в системі. Потім запустіть тести, щоб визначити фактичні дублікати.

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

# 9) Обов’язково

У цьому типі тесту визначте всі поля, позначені як Обов’язкові, і перевірте, чи обов’язкові поля мають значення. Якщо у БД є значення за замовчуванням, пов'язані з полем, перевірте, чи воно заповнене правильно, коли даних немає.

  • Приклад: Якщо BillDate не введено, то CurrentDate є BillDate.

# 10) Своєчасність

Завжди документуйте тести, які підтверджують, що ви працюєте з даними із узгоджених термінів.

він підтримує питання та відповіді на співбесіду

  • Приклад: ProductDiscount було оновлено 15 днів тому, а домен бізнесу ProductDiscount змінюється кожні сім днів. Це означає, що ваші тести не проводяться з правильними значеннями знижки.
  • Звіт прогностичної аналітики для індексу задоволеності клієнтів повинен був працювати з останніми 1-тижневими даними, що було тижнем стимулювання продажів у Walmart. Але робота ETL була розроблена для роботи з частотою 15 днів. Це основний дефект, який тестери можуть виявити.

# 11) Нульові дані

У цьому типі тесту ми зосереджуємось на достовірності нульових даних та перевірці, що важливий стовпець не може бути нульовим.

  • Приклад: Відфільтруйте всі нульові дані та перевірте, якщо дозволено нульове значення.
  • Якщо є важливі стовпці для ділових рішень, переконайтеся, що відсутні нулі.

# 12) Перевірка дальності

Суб’єкт даних, де діапазони мають діловий сенс, слід перевірити.

  • Приклад: Кількість замовлень на рахунок-фактура не може перевищувати 5K у категорії програмного забезпечення.
  • Вік не повинен бути більше 120 років.

# 13) Правила ведення бізнесу

Задокументуйте будь-які бізнес-вимоги до полів та проведіть тести на те саме.

  • Приклад: Ресурси віком до 20 років не приймаються. Перевірки перевірки даних необхідні, якщо це правило застосовується до даних.
  • Дата припинення повинна бути нульовою, якщо статус Співробітник активний істинний / померлий.
  • Дані FROM повинні бути менше, ніж TO Date.
  • Зробіть суму покупок на рівні товару до суми на рівні замовлення

# 14) Сукупні функції

Сукупні функції вбудовані у функціонал бази даних. Документуйте всі сукупності у вихідній системі та переконайтеся, що використання сукупності дає однакові значення в цільовій системі (сума, макс., Хв., Кількість).

Досить часто інструменти вихідної системи відрізняються від цільової. Перевірте, чи обидва інструменти виконують сукупні функції однаково.

# 15) Зрізання та округлення даних

У цих типах тестів ми визначаємо поля з логікою усічення та округлення, що стосуються бізнесу. Потім ми документуємо та отримуємо підписку на логіку скорочення та округлення з власниками Продукту та перевіряємо їх за допомогою репрезентативних даних виробництва.

# 16) Тести кодування

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

  • Приклад: Двобайтові символи для FirstName китайською мовою були прийняті в кодованій системі джерела. Перевірте поведінку цього поля при переміщенні до цільової системи.
  • Поле Пароль було закодовано та перенесено. Переконайтеся, що вони працюють нормально після міграції.

# 17) Тести на регресію

Це основна концепція тестування, коли тестувальники запускають усі свої критичні набори тестових випадків, створені за допомогою вищезазначеного контрольного списку, після зміни в джерелі або цільовій системі.

Висновок

Отже, ми переконались, що перевірка даних є цікавою областю для досліджень, що потребують великих обсягів проектів, і формує найважливіші тести. Таблиця відображення даних є критичним артефактом, який тестери повинні підтримувати, щоб досягти успіху в цих тестах. Вони можуть підтримувати кілька версій із кольоровими підсвітками, щоб сформувати вхідні дані для будь-якого з наведених вище тестів.

Слід подбати про підтримку дельта-змін у різних версіях.

Ми просимо читачів поділитися іншими тестами, з якими вони стикалися під час своєї роботи, щоб принести користь спільноті тестувальників.

Рекомендована література

^