Menu

Testy walidacyjne danych dla projektów ETL i migracji danych

  • Główny
  • Inny
  • Testy walidacyjne danych dla projektów ETL i migracji danych

data validation tests

Wypróbuj Nasz Instrument Do Eliminowania Problemów

W tym samouczku opisano ETL i projekty migracji danych oraz omówiono sprawdzanie poprawności danych lub testy dla projektów ETL / migracji danych w celu poprawy jakości danych:

Ten artykuł jest przeznaczony dla testerów oprogramowania, którzy pracują nad projektami ETL lub migracji danych i są zainteresowani skupieniem się w testach tylko na aspektach jakości danych. Tego typu projekty zawierają ogromną ilość danych, które są przechowywane w pamięci źródłowej, a następnie są obsługiwane przez jakąś logikę obecną w oprogramowaniu i są przenoszone do pamięci docelowej.

Testy walidacji danych zapewniają, że dane obecne w ostatecznych systemach docelowych są ważne, dokładne, zgodnie z wymaganiami biznesowymi i dobre do wykorzystania w systemie produkcyjnym na żywo.

Walidacja danych dla projektów ETL i migracji danych

Liczba aspektów jakości danych, które można przetestować, jest ogromna, a poniższa lista stanowi wprowadzenie do tego tematu.

Czego się nauczysz:

Co to jest walidacja danych?

Walidacji danych

Mówiąc najprościej, walidacja danych polega na sprawdzeniu faktu, że dane przenoszone w ramach zadań ETL lub migracji danych są spójne, dokładne i kompletne w docelowych produkcyjnych systemach na żywo, aby spełniać wymagania biznesowe.

Przykład: Adres ucznia w tabeli Student to 2000 znaków w systemie źródłowym. Walidacja danych sprawdza, czy dokładnie ta sama wartość znajduje się w systemie docelowym. Sprawdza, czy dane zostały obcięte lub czy niektóre znaki specjalne zostały usunięte.

W tym artykule omówimy wiele z tych kontroli poprawności danych. Jako testerzy projektów ETL lub migracji danych, odkryjemy problemy z jakością danych, które mogą zostać przeniesione do systemów docelowych i zakłócić całe procesy biznesowe.

Po co weryfikować dane w projektach ETL?

W projektach ETL dane są pobierane ze źródła, przetwarzane przez zastosowanie pewnej logiki w oprogramowaniu, przekształcane, a następnie ładowane do pamięci docelowej. W wielu przypadkach transformacja ma na celu zmianę danych źródłowych na format bardziej użyteczny dla wymagań biznesowych.

W tym przypadku wymagana jest walidacja danych, aby potwierdzić, że dane ładowane do systemu docelowego są kompletne, dokładne i nie ma utraty danych ani rozbieżności.

system docelowy i źródłowy

Przykład: Aplikacja e-commerce ma zadania ETL, które pobierają wszystkie OrderIds dla każdego CustomerID z tabeli Orders, która podsumowuje łączne wydatki poniesione przez klienta, i ładuje je do nowej tabeli CustomerValue, oznaczając każdy CustomerRating jako oparty na klientach o wysokiej / średniej / niskiej wartości na jakimś złożonym algorytmie.

Prosty test sprawdzania poprawności danych polega na sprawdzeniu, czy CustomerRating jest poprawnie obliczony.

Innym testem jest sprawdzenie, czy TotalDollarSpend jest poprawnie obliczony, bez błędów w zaokrąglaniu wartości lub przekroczeniach wartości maksymalnych.

Po co weryfikować dane w projektach migracji danych?

W projektach migracji danych ogromne ilości danych przechowywanych w pamięci źródłowej są migrowane do innej pamięci docelowej z wielu powodów, takich jak aktualizacja infrastruktury, przestarzała technologia, optymalizacja itp. Na przykład, firmy mogą migrować swoje ogromne hurtownie danych ze starszych systemów do nowszych i bardziej niezawodnych rozwiązań na platformie AWS lub Azure.

Głównym motywem takich projektów jest przeniesienie danych z systemu źródłowego do systemu docelowego, tak aby dane w systemie docelowym były wysoce użyteczne bez zakłóceń lub negatywnych skutków dla firmy.

Tutaj znowu wymagana jest walidacja danych, aby potwierdzić, że dane w źródle są takie same w celu po przemieszczeniu.

Przykład: Załóżmy, że w przypadku aplikacji handlu elektronicznego tabela Zamówienia, która zawierała 200 milionów wierszy, została przeniesiona do systemu docelowego na platformie Azure. Prosty test sprawdzania poprawności danych polega na sprawdzeniu, czy wszystkie 200 milionów wierszy danych jest dostępnych w systemie docelowym.

Innym testem może być potwierdzenie, że formaty dat są zgodne w systemie źródłowym i docelowym.

jak odtwarzać pliki .swf

Istnieją różne aspekty, które testerzy mogą testować w takich projektach, jak testy funkcjonalne, testy wydajnościowe, testy bezpieczeństwa, testy infra, testy E2E, testy regresji itp.

Zalecana lektura => Testowanie migracji danych , ETL Testing Data Warehouse Testing Tutorial

W tym artykule przyjrzymy się tylko aspektowi danych w testach dla projektów ETL i migracji.

Arkusz mapowania danych

Na początek utwórz arkusz mapowania danych dla projektu danych. Mapowanie danych to proces dopasowywania jednostek między tabelą źródłową i docelową. Zacznij od udokumentowania wszystkich tabel i ich jednostek w systemie źródłowym w arkuszu kalkulacyjnym. Teraz udokumentuj odpowiednie wartości dla każdego z tych wierszy, które mają być zgodne w tabelach docelowych. Zapisz zasady transformacji w osobnej kolumnie, jeśli takie istnieją.

Arkusze mapowania danych zawierają wiele informacji pobranych z modeli danych dostarczonych przez Data Architects. Początkowo testerzy mogli stworzyć uproszczoną wersję i dodawać więcej informacji w miarę postępów. Zobacz przykład arkusza mapowania danych poniżej- tabela nadrzędna

Pobierz szablon z Uproszczony arkusz mapowania danych

Testy walidacyjne danych

1) Jednolitość danych

Testy jednorodności danych są przeprowadzane w celu sprawdzenia, czy rzeczywista wartość jednostki ma dokładne dopasowanie w różnych miejscach. Mamy tutaj możliwe dwa rodzaje testów:

(i) Kontrole w ramach tego samego schematu:

  • Jednostka danych może istnieć w dwóch tabelach w ramach tego samego schematu (system źródłowy lub system docelowy)
  • Przykład: Jak widać na poniższym obrazku, ProductID jest obecny w tabeli OrderDetails and Products. Przeprowadź weryfikację dokładnego dopasowania dla ProductId obecnego w tabeli OrderDetails vs Products.

Uproszczony arkusz mapowania danych 1

(ii) Weryfikacje w ramach schematów:

  • Jednostka danych może zostać zmigrowana tak jak jest do schematu docelowego, tj. Jest obecna zarówno w systemie źródłowym, jak i docelowym
  • Przykład: Jak widać na powyższym obrazku, ProductID jest obecny w tabeli Produkty w systemie źródłowym i tabeli Produkty w systemie docelowym. Wykonaj weryfikację dokładnego dopasowania dla ProductId w tabeli Products w systemie źródłowym do ProductId w tabeli Products w systemie docelowym.

Uwaga: Najlepiej jest podświetlić (kodem kolorowym) pasujące jednostki danych w arkuszu mapowania danych w celu szybkiego odniesienia.

# 2) Obecność jednostki

W tego typu teście musimy sprawdzić, czy wszystkie jednostki (tabele i pola) są dopasowane między źródłem i celem. Istnieją dwie możliwości, jednostka może być obecna lub nieobecna, zgodnie z projektem modelu danych.

(ja) Sprawdź, czy wszystkie tabele (i kolumny), które mają odpowiednią obecność zarówno w źródle, jak i celu, są zgodne. Pobieramy listę wszystkich tabel (i kolumn) i porównujemy tekst. Ten test poczytalności działa tylko wtedy, gdy używane są te same nazwy jednostek.

Czasami używane są różne nazwy tabel, dlatego bezpośrednie porównanie może nie działać. Być może będziemy musieli zmapować te informacje w arkuszu mapowania danych i zweryfikować je pod kątem błędów.

Inną możliwością jest brak danych. Istnieją przypadki, w których model danych wymaga, aby tabela w systemie źródłowym (lub kolumnie) nie miała odpowiedniej obecności w systemie docelowym (lub odwrotnie). Miej testy, aby to potwierdzić.

  • Przykład: Jak widać na poniższym obrazku, CustDemographic Table występuje w systemie docelowym, a nie w systemie źródłowym.
  • Pole CustomerType w tabeli Klienci zawiera dane tylko w systemie źródłowym, a nie w systemie docelowym.

dart (dokładność danych)

# 3) Dokładność danych

Jak sama nazwa wskazuje, sprawdzamy, czy dane są logicznie poprawne. Istnieją dwie kategorie tego typu testów. Dzięki temu tester może wychwycić problemy z jakością danych nawet w systemie źródłowym.

Integralność danych

(wizerunek źródło )

Uwaga: Uruchom ten test w systemie docelowym i sprawdź wstecz w systemie źródłowym wszelkie defekty.

narzędzia do monitorowania systemu dla systemu Windows 10

(i) Typ nienumeryczny: W ramach tej klasyfikacji weryfikujemy dokładność treści nienumerycznych. Przykłady to e-maile, kody PIN, telefon w prawidłowym formacie.

(ii) Analiza domeny: W tego typu testach wybieramy domeny danych i sprawdzamy je pod kątem błędów. Istnieją trzy grupy do tego:

  • Na podstawie wartości: Tutaj tworzymy listę wartości, które mogą wystąpić dla pola (kolumny w tabeli). Następnie sprawdź, czy wartości kolumn są podzbiorem naszej listy.
    • Przykład: Sprawdź, czy kolumna Płeć zawiera M lub F.
  • Na podstawie zakresu: Tutaj ustawiamy minimalny i maksymalny zakres prawidłowych wartości danych dla kolumny, na podstawie logicznego lub biznesowego rozumowania. Następnie sprawdzamy, czy wartości kolumn mieszczą się w tym zakresie.
    • Przykład: 0 do 120 dla wieku.
  • Plik referencyjny : Tutaj system używa zewnętrznego pliku weryfikacji.
    • Przykład: Czy kody krajów są prawidłowe, czy wybierają właściwą wartość z pliku referencyjnego, czy kody krajów są takie same w przypadku kontroli jakości i środowiska produkcyjnego? Jeśli plik referencyjny miał zaktualizowany kod kraju, czy jest on słusznie aktualizowany w DB?

# 4) Walidacja metadanych

W walidacji metadanych sprawdzamy, czy definicje typu danych tabeli i kolumny dla celu są poprawnie zaprojektowane, a po zaprojektowaniu są wykonywane zgodnie ze specyfikacjami projektu modelu danych.

Istnieją tutaj dwie grupy:

(i) Projekt metadanych: Pierwsza kontrola polega na zweryfikowaniu, czy model danych jest poprawnie zaprojektowany zgodnie z wymaganiami biznesowymi dla tabel docelowych. Architekci danych mogą migrować jednostki schematu lub wprowadzać modyfikacje podczas projektowania systemu docelowego.

Następnym sprawdzeniem powinno być sprawdzenie, czy właściwe skrypty zostały utworzone przy użyciu modeli danych.

Dla każdej z poniższych kategorii najpierw weryfikujemy, czy metadane zdefiniowane dla systemu docelowego spełniają wymagania biznesowe, a po drugie, czy tabele i definicje pól zostały utworzone poprawnie.

Poniżej przedstawiono kilka sprawdzeń metadanych:

  • Kontrola typu danych: Przykład: Czy Total Sales będzie działać poprawnie z typem Decimal (8, 16 lub 20 bajtów) lub Double?
  • Kontrola długości danych : Przykład: Czy długość danych w polu Adres będzie wystarczająca przy 500 znakach? Może to być przypadek, w którym migracja danych odbywa się w miarę dodawania nowego obszaru geograficznego do firmy. Adresy w nowej geografii mogą mieć wyjątkowo długi format i trzymanie się pierwotnej długości może spowodować błąd w przypadku użycia.
  • Sprawdzenie indeksu: Przykład: Czy w systemie docelowym przeprowadzono indeksowanie kolumny OrderId? A co by było, gdyby doszło do fuzji firm, wymagającej migracji danych i 100-krotnego powiększenia tabeli Zamówienia w docelowym systemie?
  • Sprawdzanie metadanych w różnych środowiskach: W ramach tej kontroli sprawdź, czy metadane są zgodne między testem kontroli jakości a środowiskiem produkcyjnym. Testy mogą przejść pomyślnie w środowisku zapewniania jakości, ale zakończyć się niepowodzeniem w innych środowiskach.

(ii) Zmiana delta: Testy te ujawniają usterki, które pojawiają się, gdy projekt jest w toku oraz w trakcie zmian w metadanych systemu źródłowego, które nie zostały wdrożone w systemach docelowych.

Przykład: Do tabeli Klientów w źródle dodano nowe pole CSI (Indeks satysfakcji klienta), ale nie udało się go wprowadzić do systemu docelowego.

# 5) Integralność danych

W tym przypadku sprawdzamy głównie ograniczenia integralności, takie jak klucz obcy, odwołanie do klucza podstawowego, unikatowe, domyślne itp.

tabela nadrzędna

(wizerunek źródło )

W przypadku kluczy obcych musimy sprawdzić, czy w tabeli podrzędnej znajdują się osierocone rekordy, w których nie ma użytego klucza obcego w tabeli nadrzędnej.

Sprawdzenie kompletności danych

Przykład: Tabela Klienci zawiera CustomerID, który jest kluczem podstawowym. Tabela zamówień ma CustomerID jako klucz obcy. Tabela zamówień może mieć identyfikator klienta, którego nie ma w tabeli Klienci. Musimy przeprowadzić testy, aby wykryć takie naruszenia ograniczeń integralności. Tabela mapowania danych daje jasność co do tego, które tabele mają te ograniczenia.

Uwaga: Uruchom ten test w systemie docelowym i sprawdź wstecz w systemie źródłowym, jeśli występują defekty.

# 6) Kompletność danych

Są to testy poprawności, które ujawniają brakujące rekordy lub liczby wierszy między tabelą źródłową a docelową i mogą być często uruchamiane po zautomatyzowaniu.

Istnieją dwa rodzaje testów:

(i) Liczba rekordów: Tutaj porównujemy całkowitą liczbę rekordów pasujących tabel między systemem źródłowym i docelowym. Jest to szybkie sprawdzenie poprawności w celu zweryfikowania po uruchomieniu zadania ETL lub zadania migracji. Mamy wadę, jeśli liczby się nie zgadzają.

Czasami podczas wykonywania zadania występują odrzucone rekordy. Niektóre z nich mogą być ważne. Ale jako tester stawiamy na to argument.

(ii) Profilowanie danych kolumnowych: Ten rodzaj testu poczytalności jest cenny, gdy liczba rekordów jest ogromna. Tutaj tworzymy logiczne zestawy danych, które zmniejszają liczbę rekordów, a następnie porównujemy źródło i cel.

  • Tam, gdzie to możliwe, filtruj wszystkie unikalne wartości w kolumnie, na przykład, ProductID może występować wiele razy w tabeli OrderDetails. Wybierz unikalną listę dla ProductID z tabeli docelowej i źródłowej i sprawdź poprawność. To znacznie zmniejsza liczbę zliczeń rekordów i przyspiesza testy poczytalności.
  • Podobnie jak w powyższych testach, możemy również wybrać wszystkie główne kolumny i sprawdzić, czy KPI (minimalna, maksymalna, średnia, maksymalna lub minimalna długość itp.) Pasują do tabeli docelowej i źródłowej. Przykład: Weź średnie, minimalne i maksymalne wartości z kolumny Cena w OrderDetails i porównaj te wartości między tabelami docelowymi i źródłowymi pod kątem niezgodności.
  • Kolejną kontrolę można przeprowadzić dla wartości Null. Wybierz ważne kolumny i odfiltruj listę wierszy, w których kolumna zawiera wartości Null. Porównaj te wiersze między systemem docelowym i źródłowym pod kątem niezgodności.

Osie czasu

# 7) Transformacja danych

Testy te stanowią podstawowe testy projektu. Przejrzyj dokument wymagań, aby zrozumieć wymagania dotyczące transformacji. Przygotuj dane testowe w systemach źródłowych, aby odzwierciedlić różne scenariusze transformacji. Mają wiele testów i powinny być szczegółowo omówione w tematach testowania ETL.

Poniżej znajduje się zwięzła lista testów objętych tym:

(i) Transformacja:

  • Przykład: Kod ETL może mieć logikę do odrzucania nieprawidłowych danych. Sprawdź je pod kątem wymagań.
  • Kod ETL może również zawierać logikę do automatycznego generowania niektórych kluczy, takich jak klucze zastępcze. Musimy mieć testy, aby zweryfikować ich poprawność (techniczną i logiczną).
  • Sprawdź poprawność łączenia lub podziału wartości pól po wykonaniu zadania ETL lub migracji.
  • Przeprowadzaj testy, aby zweryfikować kontrole integralności referencyjnej. Na przykład, typ wady może być ProductId używany w tabeli Zamówienia nie występuje w tabeli nadrzędnej Produkty. Przeprowadź test, aby sprawdzić, jak osierocone rekordy zachowują się podczas zadania ETL.
  • Czasami brakujące dane są wstawiane za pomocą kodu ETL. Sprawdź poprawność tych.
  • Skrypty ETL lub migracyjne czasami mają logikę do poprawiania danych. Sprawdź, czy poprawianie danych działa.
  • Sprawdź, czy nieprawidłowe / odrzucone / błędne dane są zgłaszane użytkownikom.
  • Utwórz arkusz kalkulacyjny zawierający scenariusze danych wejściowych i oczekiwanych wyników i zweryfikuj je z klientem biznesowym.

(ii) Przypadki skrajne: Sprawdź, czy logika transformacji dobrze trzyma się granic.

  • Przykład: Co się stanie, gdy TotalSales o wartości 1 biliona zostanie przeprowadzony przez zadanie ETL? Czy sprawy od końca do końca działają? Zidentyfikuj zmienne, które mogą potencjalnie mieć duże wartości, i uruchom testy z tymi dużymi wartościami. Powinny zawierać wartości liczbowe i nienumeryczne.
  • Dla pól dat, w tym całego zakresu oczekiwanych dat - lata przestępne, 28/29 dni dla lutego. 30, 31 dni w przypadku pozostałych miesięcy.

# 8) Unikalność lub powielanie danych

W tym typie testu zidentyfikuj kolumny, które powinny mieć unikalne wartości zgodnie z modelem danych. Weź również pod uwagę logikę biznesową, aby wyeliminować takie dane. Uruchom testy, aby sprawdzić, czy są unikalne w systemie. Następnie uruchom testy, aby zidentyfikować rzeczywiste duplikaty.

  • Przykład: Odfiltruj zduplikowane dane i sprawdź, czy są autentyczne. Na przykład, Rekord zależny od pracownika zawiera dwukrotnie te same dane dotyczące rodzeństwa.
  • Numer telefonu użytkownika powinien być unikalny w systemie (wymaganie biznesowe).
  • Wymóg biznesowy mówi, że kombinacja ProductID i ProductName w tabeli Products powinna być unikalna, ponieważ ProductName może być zduplikowana.

# 9) Obowiązkowe

W tym typie testu zidentyfikuj wszystkie pola oznaczone jako obowiązkowe i sprawdź, czy pola obowiązkowe mają wartości. Jeśli istnieją wartości domyślne skojarzone z polem w bazie danych, sprawdź, czy jest wypełnione poprawnie, gdy nie ma danych.

  • Przykład: Jeśli BillDate nie zostanie wprowadzona, to CurrentDate jest BillDate.

# 10) Terminowość

Zawsze dokumentuj testy sprawdzające, czy pracujesz z danymi z uzgodnionych terminów.

jak zadeklarować kolejkę w java

  • Przykład: ProductDiscount został zaktualizowany 15 dni wstecz, a status domeny ProductDiscount zmienia się co siedem dni. Oznacza to, że testy nie są wykonywane z odpowiednimi wartościami rabatu.
  • Raport analizy predykcyjnej dla indeksu satysfakcji klienta miał działać na danych z ostatniego tygodnia, który był tygodniem promocji sprzedaży w Walmart. Ale zadanie ETL zostało zaprojektowane tak, aby działało z częstotliwością 15 dni. Jest to główna wada, którą testerzy mogą odkryć.

# 11) Puste dane

W tego typu teście skupiamy się na poprawności danych zerowych i weryfikacji, czy ważna kolumna nie może być zerowa.

  • Przykład: Odfiltruj wszystkie puste dane i sprawdź, czy wartość null jest dozwolona.
  • Jeśli istnieją ważne kolumny dla decyzji biznesowych, upewnij się, że nie ma wartości null.

# 12) Sprawdzanie zasięgu

Jednostka danych, dla której zakresy mają sens biznesowy, powinna zostać przetestowana.

  • Przykład: Ilość zamówienia na fakturę nie może przekraczać 5 tys. W kategorii oprogramowania.
  • Wiek nie powinien przekraczać 120 lat.

13) Zasady biznesowe

Udokumentuj wszelkie wymagania biznesowe dla pól i przeprowadź testy dla nich.

  • Przykład: Zasoby w wieku poniżej 20 lat nie kwalifikują się. Kontrole poprawności danych są wymagane, jeśli ta reguła jest stosowana do danych.
  • Data zakończenia powinna być pusta, jeśli status pracownika aktywnego to Prawda / Zmarły.
  • Dane FROM powinny być mniejsze niż Data TO.
  • Sumuj kwoty zakupów na poziomie pozycji z kwotami na poziomie zamówienia

# 14) Funkcje agregujące

Funkcje agregujące są wbudowane w funkcjonalność bazy danych. Udokumentuj wszystkie agregaty w systemie źródłowym i sprawdź, czy użycie agregatów daje takie same wartości w systemie docelowym (suma, maksimum, minimum, liczba).

Dość często narzędzia w systemie źródłowym różnią się od systemu docelowego. Sprawdź, czy oba narzędzia wykonują funkcje agregujące w ten sam sposób.

# 15) Obcinanie i zaokrąglanie danych

W tego typu testach identyfikujemy pola z logiką obcinania i zaokrąglania dotyczącą biznesu. Następnie dokumentujemy i zatwierdzamy logikę obcinania i zaokrąglania z właścicielami produktów i testujemy je z danymi reprezentatywnymi dla produkcji.

# 16) Testy kodowania

Sprawdź, czy w systemie źródłowym są zakodowane wartości i sprawdź, czy dane są prawidłowo wypełnione, po wysłaniu ETL lub zadania migracji danych do systemu docelowego.

  • Przykład: Znaki dwubajtowe dla FirstName w języku chińskim zostały zaakceptowane w systemie źródłowym, który został zakodowany. Sprawdź zachowanie tego pola po przeniesieniu do systemu docelowego.
  • Pole Hasło zostało zakodowane i poddane migracji. Upewnij się, że po migracji działają dobrze.

# 17) Testy regresji

Jest to podstawowa koncepcja testowania, w której testerzy uruchamiają wszystkie krytyczne zestawy przypadków testowych wygenerowane przy użyciu powyższej listy kontrolnej, po wprowadzeniu zmiany w systemie źródłowym lub docelowym.

Wniosek

Widzieliśmy więc, że walidacja danych jest interesującym obszarem do zbadania w przypadku projektów wymagających dużej ilości danych i stanowi najważniejsze testy. Arkusz mapowania danych jest krytycznym artefaktem, który testerzy muszą zachować, aby osiągnąć sukces w tych testach. Mogą utrzymywać wiele wersji z kolorowymi podświetleniami, aby utworzyć dane wejściowe dla dowolnego z powyższych testów.

Należy zachować ostrożność, aby zachować zmiany delta między wersjami.

Prosimy czytelników, aby podzielili się innymi obszarami testu, z którymi zetknęli się podczas pracy, aby przynieść korzyści społeczności testerów.

rekomendowane lektury

^