Menu

Kompleksowy samouczek dotyczący testowania Hadoop | Przewodnik po testach Big Data

  • Główny
  • Inny
  • Kompleksowy samouczek dotyczący testowania Hadoop | Przewodnik po testach Big Data

comprehensive hadoop testing tutorial big data testing guide

Wypróbuj Nasz Instrument Do Eliminowania Problemów

W tym samouczku wyjaśniono podstawy, typy testów, plany, wymagane środowisko, proces testowania, walidację i weryfikacje testów Hadoop i BigData:

W tym samouczku zobaczymy podstawowe wprowadzenie do testowania Hadoop i BigData, na przykład kiedy i gdzie testy pojawią się na obrazku i co musimy przetestować w ramach testowania Hadoop.

Szczegółowo omówimy również następujące tematy:

  • Role i obowiązki związane z testowaniem Hadoop
  • Podejście do testowania dla Hadoop / BigData

=> Zajrzyj tutaj, aby zobaczyć od A do Z samouczków szkoleniowych BigData tutaj.

Wprowadzenie do testowania BigData i Hadoop

Czego się nauczysz:

Przechowywanie i przetwarzanie danych w Hadoop

Aby wykonać te procesy w systemie Hadoop, mamy siłę roboczą podzieloną na cztery sekcje.

  • Administratorzy Hadoop są odpowiedzialni za konfigurację środowiska i mają uprawnienia administracyjne do uzyskiwania dostępu do systemów Hadoop.
  • Programiści Hadoop opracowywać programy dotyczące pobierania, przechowywania i przetwarzania danych z różnych lokalizacji do centralnych lokalizacji.
  • Testerzy Hadoop do walidacji i weryfikacji danych przed pobraniem z różnych lokalizacji i po ściągnięciu w scentralizowanej lokalizacji, a także walidacja i weryfikacja odbywa się podczas ładowania danych do środowiska klienta.
  • Analitycy Hadoop działają po zakończeniu ładowania danych i gdy dane dotrą do magazynu w lokalizacji klienta. Używają tych danych do generowania raportów i pulpitów nawigacyjnych. Analitycy wykonują analizę danych pod kątem wzrostu i rozwoju biznesu.

Wiemy, że Hadoop nie jest pojedynczym systemem; zawiera wiele systemów i maszyn. Dane są dzielone i przechowywane na wielu maszynach, a jeśli chcemy ponownie uzyskać do nich dostęp, musimy połączyć i wciągnąć dane do raportów i tak dalej.

Deweloper jest odpowiedzialny za pisanie programów w językach JAVA i Python w celu wyodrębnienia danych i ich przechowywania.

Innym zadaniem programisty jest przetwarzanie danych. Istnieją dwie warstwy Hadoop, jedna służy do przechowywania, np. Hadoop HDFS, a druga do przetwarzania, np. Hadoop MapReduce.

Przechowywanie oznacza, że ​​wszelkie dane, które mamy w źródle, są po prostu przechowywane / wstawiane do systemu. Przetwarzanie oznacza, że ​​musimy podzielić go na wiele maszyn i ponownie połączyć i wysłać do klienta.

Zatem przechowywanie i przetwarzanie odbywa się za pomocą skryptów programistycznych, a programista jest odpowiedzialny za pisanie tych skryptów.

Oprócz programowania, inną metodą przechowywania i przetwarzania danych w Hadoop jest użycie aplikacji bazodanowych, takich jak Hive, Impala, HBase itp. Te narzędzia nie wymagają żadnej wiedzy programistycznej.

Testowanie BigData i Hadoop

Po zapisaniu i przetworzeniu przez programistę dane trafiają do generowania raportów. Wcześniej musimy zweryfikować przetwarzane dane pod kątem dokładności i sprawdzić, czy dane są poprawnie załadowane i poprawnie przetworzone, czy nie.

Dlatego program i / lub skrypty stworzone przez programistę muszą zostać zweryfikowane przez Hadoop lub BigData Tester. Tester musi znać podstawowe programowanie, takie jak Mapper, Hive, Pig Scripts itp., Aby zweryfikować skrypty i wykonać polecenia.

Tak więc przed rozpoczęciem testowania testerzy muszą wiedzieć, jak działają wszystkie programy i skrypty, jak napisać kod, a następnie zastanowić się, jak je przetestować. Testowanie można przeprowadzić ręcznie lub za pomocą narzędzi do automatyzacji.

Hadoop oferuje różne rodzaje testów, takie jak testowanie jednostkowe, testowanie regresji, testowanie systemu i testowanie wydajności itp. Są to więc typowe typy testów, których używamy w naszych normalnych testach, a także testach Hadoop i BigData.

Mamy ten sam rodzaj terminologii testowej, jak strategia testowa, scenariusze testowe i przypadki testowe itp. W Hadoop i BigData Testing. Jedynie środowisko jest inne i istnieją różne rodzaje technik, których używamy do testowania BigData i systemu Hadoop, ponieważ tutaj musimy przetestować dane, a nie aplikację.

Jak przetestować BigData i co wszystko wymaga testowania w BigData?

Aby móc testować BigData, musimy mieć pewne plany i strategie.

Dlatego musimy wziąć pod uwagę następujące punkty:

  • Jaka jest strategia lub plan testowania BigData?
  • Jakie metody testowania są stosowane w BigData?
  • Jakie jest wymagane środowisko?
  • Jak zweryfikować i zweryfikować BigData?
  • Jakie narzędzia są używane w testowaniu BigData?

Spróbujmy uzyskać odpowiedzi na wszystkie powyższe pytania.

Jaka jest strategia lub plan testowania BigData?

Testowanie BigData oznacza weryfikację i walidację danych podczas ich przechowywania i przetwarzania w hurtowni danych.

Podczas testowania BigData musimy przetestować ilość i różnorodność danych wyodrębnionych z różnych baz danych, a także załadowanych i przetworzonych w hurtowni danych lub systemie Hadoop. Testy te podlegają testom funkcjonalnym.

Musimy przetestować prędkość danych pobieranych z różnych baz danych i przesyłanych do systemu Hadoop, który jest częścią testów wydajności.

Tak więc, jako plan lub strategia, musimy skoncentrować się na testowaniu funkcjonalnym i wydajnościowym testowania BigData.

W testowaniu BigData tester musi zweryfikować przetwarzanie ogromnej ilości danych przy użyciu sprzętu i odpowiednich komponentów. Stąd jakość danych odgrywa również ważną rolę w testowaniu BigData. Istotne jest, aby zweryfikować i potwierdzić jakość danych.

Typy testowania do testowania BigData

W poprzedniej sekcji widzieliśmy, że testowanie funkcjonalne i testowanie wydajności odgrywają istotną rolę w testowaniu BigData, oprócz tego jako tester BigData musimy wykonać kilka innych rodzajów testów, takich jak testowanie baz danych, a także testowanie architektury.

Te typy testów są również tak samo ważne jak testy funkcjonalne i wydajnościowe.

1) Testowanie architektoniczne

Testowanie to ma na celu zapewnienie, że przetwarzanie danych jest prawidłowe i spełnia wymagania. W rzeczywistości system Hadoop przetwarza ogromne ilości danych i jest bardzo wszechstronny pod względem zasobów.

Niewłaściwa architektura może pogorszyć wydajność, przez co przetwarzanie danych może zostać przerwane i może nastąpić utrata danych.

# 2) Testowanie bazy danych

Tutaj pojawia się walidacja procesu i musimy walidować dane z różnych baz danych, tj. Musimy upewnić się, że dane pobrane ze źródłowych lub lokalnych baz danych muszą być poprawne i prawidłowe.

Musimy również sprawdzić, czy dane dostępne w źródłowych bazach danych są zgodne z danymi wprowadzonymi w systemie Hadoop.

Testowanie bazy danych

Podobnie musimy sprawdzić, czy dane w systemie Hadoop są poprawne i poprawne po przetworzeniu lub powiedzmy po transformacji i załadowane do środowiska klienta z odpowiednią walidacją i weryfikacją.

W ramach testowania bazy danych musimy przejść przez OKRUTNY operacje tj. Stwórz dane w lokalnych bazach danych Odzyskać dane i musimy je przeszukać i powinny być dostępne w Bazie Danych przed i po załadowaniu do Hurtowni Danych oraz z Hurtowni Danych do Środowiska Klienta.

Weryfikacja dowolnego Zaktualizowano Dane na każdym etapie Przechowywania lub Ładowania i Przetwarzania danych. Usunięcie wszelkich uszkodzonych danych lub wszelkich zduplikowanych i zerowych danych.

# 3) Testowanie wydajności

W ramach testów wydajnościowych musimy sprawdzić szybkość ładowania i przetwarzania danych, np. IOPS (Input Output Per Second).

Należy sprawdzić szybkość wprowadzania danych lub danych jako dane wejściowe z różnych baz danych do hurtowni danych lub systemu Hadoop oraz z systemu Hadoop lub hurtowni danych do środowiska klienta.

Należy również sprawdzić prędkość danych pochodzących z różnych baz danych oraz z hurtowni danych jako dane wyjściowe. To właśnie nazywamy Input Output Per Second lub IOPS.

Oprócz tego, kolejnym aspektem jest sprawdzenie wydajności Absorpcji i Dystrybucji Danych oraz tego, jak szybko dane są pobierane przez Hurtownię Danych z różnych baz danych oraz przez System Klienta z systemu Hadoop.

Również jako Tester musimy sprawdzić wydajność Dystrybucji danych, np. Jak szybko dane są dystrybuowane do różnych plików dostępnych w systemie Hadoop lub w hurtowni danych. Podobnie ten sam proces zachodzi podczas dystrybucji danych do systemów klienckich.

System Hadoop lub hurtownia danych składa się z wielu komponentów, więc tester musi sprawdzić wydajność wszystkich tych komponentów, takich jak zadania MapReduce, wprowadzanie i zużycie danych, czas odpowiedzi zapytań i ich wydajność, a także wydajność wyszukiwania operacje. Wszystko to jest uwzględnione w testach wydajności.

# 4) Testowanie funkcjonalne

Testowanie funkcjonalne obejmuje testowanie wszystkich podkomponentów, programów i skryptów, narzędzi używanych do wykonywania operacji przechowywania lub ładowania i przetwarzania itp.

Dla testera są to cztery ważne typy i etapy, przez które dane muszą być filtrowane, aby klient otrzymał doskonałe i wolne od błędów dane.

Narzędzia do testowania BigData Hadoop

Istnieje wiele narzędzi służących do testowania BigData:

  • Dystrybucyjny system plików HDFS Hadoop do przechowywania danych BigData.
  • Redukcja mapy HDFS do przetwarzania BigData.
  • Dla NoSQL lub HQL Cassandra DB, ZooKeeper i HBase itp.
  • Narzędzia serwerowe w chmurze, takie jak EC2.

Testowanie środowisk i ustawień

Do każdego rodzaju testów Tester potrzebuje odpowiednich ustawień i środowiska.

Poniżej podano listę wymagań:

  1. Typ danych i aplikacji, która będzie testowana.
  2. Przechowywanie i przetwarzanie wymaga dużej przestrzeni dla ogromnej ilości danych.
  3. Właściwa dystrybucja plików we wszystkich węzłach DataNodes w całym klastrze.
  4. Podczas przetwarzania danych wykorzystanie sprzętu powinno być minimalne.
  5. Uruchomione programy i skrypty zgodnie z wymaganiami Aplikacji.

Role i obowiązki związane z testowaniem Hadoop

Jako tester Hadoop jesteśmy odpowiedzialni za zrozumienie wymagań, przygotowanie oszacowań testowych, planowanie przypadków testowych, uzyskanie danych testowych w celu przetestowania niektórych przypadków testowych, udział w tworzeniu stanowiska testowego, wykonywaniu planów testów, raportowaniu i ponownym testowaniu defektów.

Musimy również być odpowiedzialni za codzienne raportowanie stanu i ukończenie testów.

Role i obowiązki związane z testowaniem Hadoop

Pierwszą rzeczą, którą omówimy, jest plik Strategia testów . Kiedy już mamy proponowane rozwiązanie naszego problemu, musimy iść naprzód i zaplanować lub opracować strategię naszego planu testów, możemy omówić strategię automatyzacji, którą możemy tam zastosować, plan dotyczący harmonogramu testów, który zależy od naszych dat dostawy, również my może omówić planowanie zasobów.

Strategia automatyzacji to coś, co pomoże nam zmniejszyć wysiłek ręczny wymagany podczas testowania produktu. Harmonogram testów jest ważny, ponieważ zapewni terminową dostawę produktu.

Planowanie zasobów będzie miało kluczowe znaczenie, ponieważ musimy zaplanować, ile roboczogodzin potrzebujemy w naszych testach i ile zasobów Hadoop są potrzebne do wykonania naszego planowania testów.

Kiedy opracujemy strategię naszych testów, musimy iść dalej i stworzyć plany rozwoju testów, które obejmują tworzenie planów testów, tworzenie skryptów testowych, które pomogą nam zautomatyzować nasze testy, a także zidentyfikować niektóre dane testowe, które będą używane w planach testów i pomaga nam wykonać te plany testów.

Gdy skończymy opracowywanie testów, które obejmuje tworzenie planów testów, skryptów testowych i danych testowych, przystępujemy do wykonywania tych planów testów.

Kiedy wykonujemy Plany Testów, mogą wystąpić pewne scenariusze, w których rzeczywiste wyniki nie są zgodne z oczekiwaniami, a te rzeczy nazywane są defektami. Zawsze, gdy występuje defekt, musimy przetestować również te defekty i musimy stworzyć i utrzymywać dla nich macierze.

Wszystkie te rzeczy należą do następnej kategorii, czyli Zarządzanie defektami .

Co to jest zarządzanie defektami?

Zarządzanie defektami obejmuje śledzenie błędów, naprawianie błędów i weryfikację błędów. Za każdym razem, gdy plan testów jest wykonywany w odniesieniu do któregokolwiek z naszych produktów i gdy tylko zostanie zidentyfikowany konkretny błąd lub usterka, wówczas defekt ten należy zgłosić deweloperowi lub przypisać mu.

Deweloper może się temu przyjrzeć i zacząć nad nim pracować. Jako tester musimy śledzić postęp błędu i śledzić, czy błąd został naprawiony. Jeśli błąd został naprawiony zgodnie z zgłoszeniem, musimy przejść dalej i ponownie go przetestować i sprawdzić, czy został rozwiązany.

Gdy wszystkie błędy zostaną naprawione, zamknięte i zweryfikowane, musimy iść dalej i dostarczyć OK, przetestowany produkt. Ale zanim dostarczymy produkt, musimy upewnić się, że UAT (test akceptacji użytkownika) został pomyślnie zakończony.

Dbamy o to, aby testy instalacji i weryfikacja wymagań zostały wykonane prawidłowo, tj. Produkt, który jest dostarczany do klienta lub użytkownika końcowego jest zgodny z wymaganiem, o którym mowa w dokumencie wymagań programowych.

Kroki, które omówiliśmy, są oparte na wyobraźni, są dowolnym scenariuszem testowania lub którymkolwiek z podejść testowych, które zamierzamy zastosować w tych krokach, lub powiedz te zwroty, aby przetestować nasz produkt i dostarczyć wynik końcowy, który jest OK Produkt przetestowany.

Przejdźmy dalej i omówmy to szczegółowo i skorelujmy to z testami Hadoop.

Wiemy, że Hadoop jest czymś, co jest używane do przetwarzania wsadowego, a także wiemy, że ETL jest jednym z pól, w których Hadoop jest często używany. ETL to skrót od Extraction Transformation and Loading . Omówimy szczegółowo te procesy, omawiając plan testów i strategię testów z punktu widzenia testowania Hadoop.

Zgodnie z poniższym diagramem po prostu zakładamy, że mamy cztery różne źródła danych. System operacyjny, CRM ( Menedżer ds. relacji z klientami ) i ERP ( Planowanie zasobów przedsiębiorstwa ) to RDBMS lub powiedzmy Relational DataBase Management System, który posiadamy, a także mamy kilka płaskich plików, które mogą być dziennikami, plikami, rekordami lub cokolwiek innego co do naszych źródeł danych.

Być może używamy Sqoop lub Flume lub jakiegokolwiek konkretnego produktu, aby uzyskać dane, rekordy lub cokolwiek innego jako moje źródła danych. Możemy użyć tych narzędzi, aby pobrać dane ze źródeł danych do mojego katalogu pomostowego, który jest pierwszą fazą naszego procesu o nazwie Ekstrakcja.

Po umieszczeniu danych w katalogu pomostowym, który w rzeczywistości jest HDFS (Hadoop Distribution File System), będziemy w szczególności używać języka skryptowego, takiego jak PIG, do Przekształcać te dane. Że Transformacja będzie zgodnie z posiadanymi przez nas danymi.

Gdy dane zostaną odpowiednio przekształcone przy użyciu dowolnej technologii skryptowej, którą posiadamy, tak się stanie Ładowanie te dane do hurtowni danych. Z hurtowni danych dane te będą wykorzystywane do analiz OLAP, raportowania i eksploracji danych lub do analiz.

Przejdźmy dalej i omówmy, których wszystkich faz możemy użyć do testowania Hadoop.

Pierwsza faza będzie fazą ekstrakcji. Tutaj otrzymamy dane z naszych źródłowych baz danych lub z plików płaskich, aw takim przypadku możemy zweryfikować, czy wszystkie dane zostały pomyślnie i poprawnie skopiowane ze źródła do katalogu pomostowego.

Może obejmować weryfikację liczby Rekordów, rodzaju Rekordów i rodzaju Pól itp.

Po skopiowaniu tych danych do katalogu przejściowego rozpoczniemy drugą fazę, którą jest Transformacja. Tutaj będziemy mieć pewną logikę biznesową, która będzie działać na skopiowanych danych z systemów źródłowych i faktycznie utworzy lub przekształci dane w wymaganą logikę biznesową.

Transformacja może obejmować sortowanie danych, filtrowanie danych, łączenie danych z dwóch różnych źródeł danych i pewne inne operacje.

Po przekształceniu danych przejdziemy dalej i przygotujemy plany testów i sprawdzimy, czy otrzymujemy dane wyjściowe zgodnie z oczekiwaniami, a wszystkie otrzymywane dane wyjściowe spełniają oczekiwany wynik oraz typy danych, wartości pól i zakresy itp. są czymś, co się układa.

Gdy jest poprawna, możemy przystąpić do załadowania danych do hurtowni danych.

W fazie ładowania faktycznie sprawdzamy, czy liczba rekordów ze stołu montażowego i liczba rekordów w hurtowni danych są zsynchronizowane, mogą nie być podobne, ale powinny być zsynchronizowane. Widzimy również, czy typ danych, które zostały przekształcone, jest zsynchronizowany.

Napisz, że wykorzystamy te dane do analizy OLAP, raportowania i eksploracji danych, co jest ostatnią warstwą naszego produktu, aw takim przypadku możemy mieć kolejne lub możemy powiedzieć, że plany testów są dostępne dla wszystkich tych warstw.

Za każdym razem, gdy otrzymujemy jakieś dane ze źródła do miejsca docelowego, zawsze musimy upewnić się, że tylko osoby uwierzytelnione mają upoważniony dostęp do danych.

Poświadczenie

Poświadczenie

Upoważnienie

Upoważnienie

Co rozumiemy przez oba te terminy?

Aby to zrozumieć, przyjrzyjmy się temu z perspektywy diagramu ETL.

ETL

Zgodnie z powyższym diagramem, pobieramy nasze dane ze źródłowych silników RDBMS i plików płaskich do HDFS, a ta faza nazywa się Ekstrakcja.

Omówmy uwierzytelnianie w szczególny sposób, są pewne firmy, które mają dane, które są ograniczone ze względu na swój charakter, ten typ danych jest nazywany danymi umożliwiającymi identyfikację zgodnie ze standardami amerykańskimi.

PII oznacza Dane osobowe umożliwiające identyfikację, wszelkie informacje, takie jak data urodzenia, numer PESEL, numer telefonu komórkowego, adres e-mail i adres domu itp., są objęte informacjami umożliwiającymi identyfikację. Jest to ograniczone i nie można go udostępniać wszystkim.

Dane należy udostępniać tylko tym osobom, które najbardziej ich potrzebują oraz tym, którym dane są potrzebne do faktycznego przetwarzania. Posiadanie tego sprawdzenia i pierwszej linii obrony nazywa się uwierzytelnianiem.

Na przykład, używamy laptopa i mamy tam zainstalowany system Windows, możemy mieć utworzone konto użytkownika w naszym systemie operacyjnym Windows i tam stosowaliśmy hasło.

W ten sposób tylko osoba posiadająca Poświadczenia do tego konkretnego konta użytkownika może zalogować się do Systemu i w ten sposób będziemy chronić nasze Dane przed kradzieżą lub niepotrzebnym dostępem. Druga warstwa to Autoryzacja.

Przykład, mamy dwa różne konta użytkowników w naszym systemie operacyjnym Windows, jedno konto użytkownika jest nasze, a drugie może być kontem gościa. Administrator (WE) ma prawo do wykonywania wszelkiego rodzaju operacji, takich jak instalacja i deinstalacja oprogramowania, tworzenie nowego pliku i usuwanie istniejących plików itp.

Z drugiej strony użytkownicy-goście mogą nie mieć całego tego rodzaju dostępu. Gość ma uwierzytelnienie umożliwiające zalogowanie się do systemu, ale nie ma uprawnień do usuwania lub tworzenia plików oraz instalacji, a także odinstalowywania oprogramowania w systemie i systemie.

Jednak konto użytkownika-gościa ze względu na uwierzytelnienie ma prawo do odczytu utworzonych plików i korzystania z już zainstalowanego oprogramowania.

W ten sposób testowane są uwierzytelnianie i autoryzacja, w tym przypadku, niezależnie od danych dostępnych w HDFS lub którymkolwiek z systemów plików, które musimy sprawdzić pod kątem uwierzytelnienia i autoryzacji danych.

Podejście testowe do testowania Hadoop / testowania BigData

Podejście testowe

Podejście testowe jest powszechne we wszystkich rodzajach testów, nie tylko dlatego, że jest to testowanie BigData lub Hadoop, kiedy przechodzimy do normalnego testowania ręcznego lub testowania automatycznego lub testowania bezpieczeństwa, a także do testów wydajnościowych, dlatego każdy rodzaj testowania ma to samo podejście.

Wymagania

W ramach podejścia testowego musimy zacząć od Wymagania , Wymaganie jest podstawową rzeczą, obecnie w procesie Agile nazywamy to Stories and Epics. Epic to nic innego jak większe wymaganie, podczas gdy Stories to mniejsze wymagania.

Wymagania w zasadzie zawierają, jakie są wszystkie modele danych, cele, źródła oraz jakiego rodzaju transformacje musimy zastosować, jakich narzędzi musimy użyć? Wszystkie te szczegóły będą dostępne w wymaganiach.

Zasadniczo jest to wymaganie klienta lub wymagania klienta. W oparciu o to wymaganie rozpoczniemy proces testowania.

Oszacowanie

Inną częścią podejścia jest Oszacowanie , Ile czasu potrzebujemy na wykonanie całej czynności w ramach testowania. Planujemy Testy, przygotowujemy Scenariusze Testów, przygotowujemy Przypadki Testowe i Wykonujemy je, jak również znajdujemy defekty i zgłaszamy je oraz przygotowujemy Raporty Testowe.

Wszystkie te czynności zajmie trochę czasu, więc ile czasu potrzebujemy na wykonanie wszystkich tych działań i jest to w zasadzie nazywane szacunkiem. Musimy dać kierownictwu pewne przybliżone oszacowanie.

Planowanie testów

Planowanie testów to nic innego jak opis procesów, co testować, czego nie testować, jaki jest zakres testów, jakie są harmonogramy, ile zasobów jest wymaganych, wymagania sprzętowe i programowe oraz jakie są ramy czasowe i cykle testowe zostaną użyte, jakie są wymagane poziomy testowania itp.

Podczas planowania testów dokonają alokacji zasobów do projektu i jakie mamy różne modele, ile zasobów jest wymaganych i jakie zestawy umiejętności są wymagane, itp. Wszystkie te rzeczy i aspekty zostaną uwzględnione w teście Faza planowania.

W większości przypadków osoby z poziomu wiodącego lub kierownictwa zajmują się planowaniem testów.

Scenariusze testowe i przypadki testowe

Kiedy skończymy z planowaniem testów, musimy się przygotować Scenariusze testowe i przypadki testowe , szczególnie w przypadku Big Data Testing, wymagamy kilku dokumentów wraz z dokumentem wymagań. Czego potrzebujemy razem z tym wymaganiem?

Potrzebujemy Dokument wymagań który zawiera potrzeby Klienta, wraz z tym potrzebujemy Dokument wejściowy to znaczy Modele danych. Model danych w sensie, czym są schematy bazy danych, jakie są tabele i jakie są relacje, wszystkie te dane będą dostępne w modelach danych.

Mamy również Mapowanie dokumentów , Mapowanie dokumentów dla Na przykład. w relacyjnych bazach danych mamy kilka tabel i po załadowaniu danych przez ETL do hurtowni danych w HDFS, jakie mapowanie musimy zrobić? tj. Mapowanie typu danych.

pytania dotyczące poziomu 1 podczas rozmowy kwalifikacyjnej działu pomocy technicznej

Na przykład, jeśli mamy tabelę klienta w HDFS, to w HDFS mamy tabelę CUSTOMER_TARGET lub ta sama tabela może również znajdować się w HIVE.

Mapowanie danych

W tej tabeli klientów mamy określone kolumny, aw tabeli CUSTOMER CARGET mamy określone kolumny, jak pokazano na diagramie. Zrzuciliśmy dane z tabeli klientów do tabeli CUSTOMER TARGET, tj. Source to Target.

Następnie musimy sprawdzić dokładne mapowanie, takie jak dane obecne w tabeli źródłowej, która jest kolumną 1 tabeli klientów i wierszem 1 i traktuje je jako C1R1, a te same dane powinny zostać zmapowane w C1R1 tabeli CUSTOMER TARGET. Zasadniczo nazywa się to mapowaniem.

Skąd będziemy wiedzieć, jakie są wszystkie mapowania, które musimy zweryfikować? Zatem te odwzorowania będą obecne w dokumencie mapowania. W dokumencie mapowania Klient poda wszelkiego rodzaju odwzorowania.

Wymagaliśmy również pliku Dokument projektowy , Dokument projektowy wymagany zarówno dla zespołu deweloperskiego, jak i zespołu ds. Zapewnienia jakości, ponieważ w dokumencie projektowym klient poda, jakiego rodzaju prace polegające na zmniejszaniu mapy zamierza wdrożyć i jakiego rodzaju prace MapReduce przyjmują dane wejściowe i jaki typ MapReduce Jobs daje wyniki.

Podobnie, jeśli mamy HIVE lub PIG, jakie są wszystkie UDF utworzone przez klienta, a także jakie są wszystkie wkłady, które weźmie i jaki rodzaj produkcji wyprodukuje itp.

Aby przygotować scenariusze testowe i przypadki testowe, musimy mieć wszystkie te dokumenty ręcznie:

  • Dokument wymagań
  • Model danych
  • Dokument mapowania
  • Dokument projektowy

Mogą się one różnić w zależności od organizacji i nie ma obowiązkowej zasady, że musimy mieć wszystkie te dokumenty. Czasami mamy wszystkie dokumenty, a czasami mamy tylko dwa lub trzy dokumenty, a czasami musimy również polegać na jednym dokumencie, to jest złożoność projektu, harmonogramy firmy i wszystko.

Recenzje scenariuszy testowych i przypadków testowych

Musimy przeprowadzić przegląd scenariuszy testowych i przypadków testowych, ponieważ w jakiś sposób lub w niektórych przypadkach zapominamy lub pomijamy niektóre przypadki testowe, ponieważ nie każdy może wymyślić wszystkie możliwe rzeczy, które można zrobić z wymaganiami, w takich warunkach, które musimy podjąć pomoc ze strony narzędzi innych firm lub kogoś innego.

Tak więc za każdym razem, gdy przygotowujemy jakieś dokumenty lub coś wykonujemy, potrzebujemy kogoś, kto przejrzy rzeczy z tego samego zespołu, np. Programiści, Testerzy. Podadzą odpowiednie sugestie, aby uwzględnić coś więcej lub zasugerują aktualizację lub modyfikację scenariuszy testowych i przypadków testowych.

Podają wszystkie komentarze i na tej podstawie zaktualizujemy nasze scenariusze testowe i przypadki testowe oraz wiele wersji dokumentu, które musimy opublikować w całym zespole, aż dokument zostanie w pełni zaktualizowany zgodnie z wymaganiami.

Wykonanie testu

Gdy dokument będzie gotowy, otrzymamy zgodę od wyższego zespołu, aby rozpocząć proces wykonywania, który zasadniczo nazywa się wykonywaniem przypadków testowych.

Jeśli chcemy wykonać nasze przypadki testowe podczas wykonywania, musimy sprawdzić, czy programista musi wysłać informacje, jeśli jest to normalne testowanie funkcjonalne lub inne testy lub testy automatyczne, wymagamy kompilacji. Ale tutaj, z punktu widzenia Hadoop lub BigData Testing, programista zapewni zadania MapReduce.

Pliki HDFS - wszystkie pliki, które są kopiowane w HDFS te informacje są wymagane do sprawdzenia uprawnień, Skrypty HIVE, które zostały utworzone przez programistów w celu weryfikacji danych w tabeli HIVE, a także potrzebujemy UDF HIVE, które zostały opracowane przez programistów, PIG Skrypty i UDF PIG.

To wszystko, czego potrzebujemy od programistów. Przed przystąpieniem do egzekucji powinniśmy mieć to wszystko.

W przypadku zadań MapReduce dostarczą pewne pliki JAR i jako część HDFS już załadowali dane w HDFS i pliki powinny być gotowe, a skrypty HIVE do sprawdzania poprawności danych w tabelach HIVE. Wszystkie wdrożone przez nich UDF będą dostępne w UDF. Wymagamy tego samego również w przypadku skryptów PIG i UDF.

Raportowanie i śledzenie defektów

Po wykonaniu naszych przypadków testowych znajdujemy pewne defekty, niektóre oczekiwane, a niektóre rzeczywiste nie są równe oczekiwanym wynikom, więc musimy je wyliczyć i przekazać zespołowi programistycznemu w celu rozwiązania, a to zasadniczo nazywa się raportowaniem defektów.

Załóżmy, że jeśli znajdziemy jakiś defekt w zadaniu MapReduce, zgłosimy to deweloperowi, a on ponownie utworzy zadanie MapReduce i wprowadzi pewne modyfikacje na poziomie kodu, a następnie ponownie dostarczy najnowsze zadanie MapReduce, które musimy przetestować .

Jest to proces ciągły, po przetestowaniu i przejściu zadania, musimy ponownie je przetestować i zgłosić deweloperowi, a następnie pobrać następne do testów. W ten sposób realizowane jest działanie raportowania i śledzenia defektów.

Raporty z testów

Po zakończeniu całego procesu testowania i zamknięciu usterek musimy utworzyć nasze raporty z testów. Raporty z testów to wszystko, co zrobiliśmy, aby zakończyć proces testowania. Całe planowanie, pisanie i wykonywanie przypadków testowych, jakie otrzymaliśmy wyniki itp. Wszystko jest dokumentowane razem w postaci raportów z testów.

Musimy wysyłać te raporty codziennie lub co tydzień lub zgodnie z potrzebami klienta. W dzisiejszych czasach organizacje używają modelu AGILE, więc każdy raport o stanie musi być aktualizowany podczas codziennych Scrumów.

Wniosek

W tym samouczku omówiliśmy:

  • Strategia lub plan testowania BigData.
  • Wymagane środowisko do testowania BigData.
  • Walidacja i weryfikacja BigData.
  • Narzędzia używane do testowania BigData.

Dowiedzieliśmy się również o -

  • Jak strategia testów, opracowywanie testów, wykonywanie testów, zarządzanie defektami i dostarczanie działają w ramach ról i obowiązków jako część testowania Hadoop.
  • Podejście testowe do testowania Hadoop / BigData, które obejmuje gromadzenie wymagań, szacowanie, planowanie testów, tworzenie scenariuszy testowych i przypadków testowych wraz z recenzjami.
  • Dowiedzieliśmy się również o wykonywaniu testów, raportowaniu i śledzeniu defektów oraz raportowaniu testów.

Mamy nadzieję, że ten samouczek dotyczący testowania BigData był dla Ciebie pomocny!

=> Sprawdź WSZYSTKIE samouczki BigData tutaj.

rekomendowane lektury

^