Menu

Komplexní výukový program pro testování Hadoop | Průvodce testováním velkých dat

  • Hlavní
  • Jiný
  • Komplexní výukový program pro testování Hadoop | Průvodce testováním velkých dat

comprehensive hadoop testing tutorial big data testing guide

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Tento kurz vysvětluje základy, typy testování, plány, požadované prostředí, testovací proces, ověření a ověření pro testování Hadoop a BigData:

V tomto tutoriálu uvidíme základní úvod do testování Hadoop a BigData, například kdy a kde testování přijde do obrazu a co je třeba otestovat jako součást testování Hadoop.

Budeme také podrobně diskutovat o následujících tématech:

  • Role a odpovědnost testování Hadoop
  • Přístup k testování pro testování Hadoop / BigData

=> Podívejte se sem a podívejte se na A-Z BigData výukových kurzů zde.

Úvod do testování BigData a Hadoop

Co se naučíte:

Ukládání a zpracování dat v Hadoopu

K provedení těchto procesů v systému Hadoop máme pracovní sílu, která je rozdělena do čtyř sekcí.

  • Správci Hadoop jsou odpovědní za nastavení prostředí a mají administrátorská práva pro přístup k systémům Hadoop.
  • Vývojáři Hadoop vyvíjet programy týkající se stahování, ukládání a zpracování dat z různých míst do centralizovaných míst.
  • Testery Hadoop pro ověření a ověření dat před načtením z různých míst a po načtení na centralizovaném místě, stejně jako ověření a ověření se provádí při načítání dat do klientského prostředí.
  • Analytici Hadoop pracovat, když je načtení dat hotové a když se data dostanou do skladu v místě klienta. Tato data používají pro generování sestav a řídicích panelů. Analytici provádějí analýzu dat pro růst a rozvoj podnikání.

Víme, že Hadoop není jediný systém; obsahuje více systémů a strojů. Data jsou rozdělena a uložena do více strojů a pokud k nim chceme znovu přistupovat, musíme data zkombinovat a vytáhnout do sestav atd.

Vývojář je zodpovědný za psaní programů v JAVA a Pythonu za účelem extrakce dat a jejich uložení.

Druhou úlohou vývojáře je zpracování dat. Existují dvě vrstvy Hadoop, jedna je pro ukládání, tj. Hadoop HDFS a druhá pro zpracování, tj. Hadoop MapReduce.

Ukládání znamená, že jakákoli data, která máme ve zdroji, se právě ukládají / vkládají do systému. Zpracování znamená, že je musíme rozdělit na více strojů a znovu je zkombinovat a odeslat klientovi.

Ukládání a zpracování se tedy provádí programováním skriptů a vývojář je odpovědný za psaní skriptů.

Kromě programování je další metodou pro ukládání a zpracování dat v Hadoopu použití databázových aplikací jako Hive, Impala, HBase atd. Tyto nástroje nepotřebují žádné znalosti programování.

BigData a testování Hadoop

Jakmile vývojář ukládá a zpracovává data, jde o generování sestav. Před tím musíme ověřit přesnost zpracovávaných dat a zkontrolovat, zda jsou data přesně načtena a správně zpracována nebo ne.

Program nebo skripty vytvořené vývojářem tedy musí být ověřeny testerem Hadoop nebo BigData. Tester musí znát základní programování, jako je Mapper, Hive, Pig Script, atd., Aby ověřil skripty a provedl příkazy.

Před testováním tedy testeři potřebují vědět, co fungují všechny programy a skripty, jak napsat kód a poté přemýšlet o tom, jak je otestovat. Testování lze provádět buď ručně, nebo pomocí automatizačních nástrojů.

Hadoop má různé druhy testování, jako je Unit Uniting, Regression Testing, System Testing, and Performance Testing atd. Jedná se tedy o běžné typy testování, které používáme při běžném testování a také o testování Hadoop a BigData.

V testech Hadoop a BigData máme stejný druh testovacích terminologií, jako je testovací strategie, testovací scénáře a testovací případy atd. Pouze prostředí je jiné a existují různé druhy technik, které používáme k testování systému BigData a Hadoop, protože zde musíme testovat data a ne aplikaci.

Jak otestovat BigData a co všechno vyžaduje testování v BigData?

Pro testování BigData potřebujeme nějaké plány a strategie.

Musíme tedy vzít v úvahu následující body:

  • Jaká je strategie nebo plán testování pro BigData?
  • Jaký druh testovacích přístupů se používá pro BigData?
  • Jaké je požadované prostředí?
  • Jak ověřit a ověřit BigData?
  • Jaké jsou nástroje používané při testování BigData?

Pokusme se získat odpovědi na všechny výše uvedené otázky.

Jaká je strategie nebo plán pro testování BigData?

Testování BigData znamená ověřování a ověřování dat při jejich ukládání a zpracování do datového skladu.

Při testování BigData musíme otestovat objem a rozmanitost dat extrahovaných z různých databází a načtených a zpracovaných na Data Warehouse nebo Hadoop System, toto testování spadá pod funkční testování.

Musíme otestovat rychlost dat stažených z různých databází a nahraných do systému Hadoop, který je součástí testování výkonu.

Jako plán nebo strategie se tedy musíme soustředit na funkční i výkonnostní testování BigData Testing.

Při testování BigData musí tester ověřit zpracování velkého množství dat pomocí Commodity Hardware a relativních komponent. Proto při testování BigData hraje důležitou roli také kvalita dat. Je nezbytné ověřit a ověřit kvalitu údajů.

Typy testování pro testování BigData

V předchozí části jsme viděli, že funkční testování a testování výkonu hrají zásadní roli v testování BigData, kromě toho, že jako BigData Tester, musíme udělat několik dalších typů testování, jako je Testování databáze, stejně jako Testování architektury.

Tyto typy testování jsou také stejně důležité jako testování funkcí a výkonu.

# 1) Architektonické testování

Toto testování se provádí, aby se zajistilo, že zpracování dat je správné a splňuje požadavky. Ve skutečnosti systém Hadoop zpracovává obrovské objemy dat a je vysoce komplexní.

Pokud je architektura nesprávná, může snížit výkon, kvůli kterému se může zpracování dat přerušit a může dojít ke ztrátě dat.

# 2) Testování databáze

Zde přichází na scénu validace procesu a musíme ověřit data z různých databází, tj. Musíme zajistit, aby data získaná ze zdrojových databází nebo místních databází byla správná a správná.

Musíme také zkontrolovat, zda jsou data dostupná ve zdrojových databázích porovnána s daty zadanými v systému Hadoop.

Testování databáze

Podobně musíme ověřit, zda jsou data v systému Hadoop správná a správná po zpracování nebo řekněme po transformaci a aby byla načtena do prostředí klienta se správným ověřením a ověřením.

Jako součást testování databáze musíme projít KRUTÝ operace tj. Vytvořit poté data v místních databázích Načíst data a musíme je prohledat a měla by být k dispozici v databázi před a po načtení do Data Warehouse a z Data Warehouse do prostředí klienta.

Ověření jakékoli Aktualizováno Údaje o každé fázi ukládání nebo načítání a zpracování dat. Vymazání všech poškozených dat nebo duplicitních a nulových dat.

# 3) Testování výkonu

V rámci testování výkonu musíme zkontrolovat rychlost načítání a zpracování dat, tj. Jako IOPS (Input Output Per Second).

Je třeba zkontrolovat rychlost zadávání dat nebo dat jako vstupu z různých databází do systému Data Warehouse nebo Hadoop a ze systému Hadoop nebo Data Warehouse do prostředí klienta.

Musí také zkontrolovat rychlost dat přicházejících z různých databází a z datového skladu jako výstup. Tomu říkáme Input Input Per Second nebo IOPS.

Kromě toho je dalším aspektem kontrola výkonu absorpce a distribuce dat a jak rychle jsou data spotřebována datovým skladem z různých databází a klientským systémem ze systému Hadoop.

Také jako tester musíme zkontrolovat výkon datové distribuce, například jak rychle jsou data distribuována do různých souborů dostupných v systému Hadoop nebo v datovém skladu. Podobně se stejný proces děje při distribuci dat do klientských systémů.

Systém Hadoop nebo datový sklad se skládá z více komponent, takže tester musí zkontrolovat výkon všech těchto komponent, jako jsou úlohy MapReduce, vkládání a spotřeba dat, doba odezvy dotazů a jejich výkon, stejně jako výkon vyhledávání operace. To vše je zahrnuto v Testování výkonu.

# 4) Funkční testování

Funkční testování obsahuje testování všech dílčích komponent, programů a skriptů, nástrojů používaných k provádění operací ukládání nebo načítání a zpracování atd.

Pro testera jsou to čtyři důležité typy a fáze, kterými je třeba filtrovat data, aby klient získal perfektní a bezchybná data.

Nástroje pro testování BigData Hadoop

K testování BigData se používají různé nástroje:

  • HDFS Hadoop distribuční souborový systém pro ukládání BigData.
  • Redukce mapy HDFS pro zpracování dat BigData.
  • Pro NoSQL nebo HQL Cassandra DB, ZooKeeper a HBase atd.
  • Cloudové serverové nástroje jako EC2.

Testování prostředí a nastavení

Pro jakýkoli typ testování potřebuje Tester správné nastavení a prostředí.

Níže je uveden seznam požadavků:

  1. Typ dat a aplikací, které budou testovány.
  2. Ukládání a zpracování vyžaduje velký prostor pro obrovské množství dat.
  3. Správná distribuce souborů na všech DataNodes celkově v clusteru.
  4. Při zpracování dat by mělo být využití hardwaru minimální.
  5. Spustitelné programy a skripty podle požadavků aplikace.

Role a odpovědnost testování Hadoop

Jako tester Hadoop zodpovídáme za pochopení požadavků, přípravu odhadů testování, plánování testovacích skříní, získání některých testovacích dat pro testování některých testovacích skříní, zapojení do vytváření testovacího lože, provádění testovacích plánů, hlášení a opakované testování závad.

Rovněž musíme být zodpovědní za denní hlášení stavu a dokončení testu.

Role a odpovědnost testování Hadoop

První věc, o které budeme diskutovat, je Testovací strategie . Jakmile máme navržené řešení našeho problému, musíme pokračovat a naplánovat nebo strategizovat náš testovací plán, můžeme diskutovat o strategii automatizace, kterou tam můžeme použít, o plánu testovacího plánu, který závisí na našich dodacích termínech, také může diskutovat o plánování zdrojů.

Strategie automatizace je něco, co nám pomůže snížit manuální úsilí vyžadované při testování produktu. Časový plán zkoušek je důležitý, protože zajistí včasné dodání produktu.

Plánování zdrojů bude zásadní, protože musíme naplánovat, kolik člověkohodin potřebujeme při testování a kolik zdrojů Hadoop je zapotřebí k provedení našeho plánování testů.

Jakmile strategizujeme naše testování, musíme pokračovat a vytvořit plány rozvoje testů, které zahrnují vytváření testovacích plánů, vytváření testovacích skriptů, které nám pomohou automatizovat naše testování a také identifikovat některá testovací data, která budou použita v testovacích plánech a pomáhá nám provádět tyto testovací plány.

Jakmile skončíme s vývojem testů, který zahrnuje vytváření testovacích plánů, testovacích skriptů a testovacích dat, pokračujeme a začneme tyto testovací plány provádět.

Když provedeme testovací plány, mohou existovat určité scénáře, kdy skutečný výstup není podle očekávání, a tyto věci se nazývají defekty. Kdykoli se vyskytne vada, musíme také otestovat tyto vady a musíme pro ně vytvořit a udržovat matice.

Všechny tyto věci spadají do další kategorie, která je Správa defektů .

Co je správa defektů?

Správa defektů zahrnuje sledování chyb, opravy chyb a ověření chyb. Kdykoli se provede testovací plán proti kterémukoli z produktů, které máme, a jakmile je zjištěna konkrétní chyba nebo je zjištěna závada, je třeba tuto závadu nahlásit vývojáři nebo jej přiřadit.

Takže vývojář to může prozkoumat a začít na tom pracovat. Jako tester musíme sledovat postup chyby a sledovat, zda byla chyba opravena. Pokud byla chyba opravena, jak byla nahlášena, musíme pokračovat a znovu ji otestovat a ověřit, zda je vyřešena.

Jakmile jsou všechny chyby opraveny, uzavřeny a ověřeny, musíme pokračovat a dodat produkt OKAY Tested. Než však dodáme produkt, musíme se ujistit, že UAT (User Acceptance Testing) je úspěšně dokončeno.

Zajistíme, aby testování instalace a ověření požadavku proběhlo správně, tj. Produkt dodávaný klientovi nebo koncovému uživateli odpovídá požadavku uvedenému v dokumentu s požadavky na software.

Kroky, o kterých jsme diskutovali, jsou založeny na představivosti, ať už jde o testovací scénáře nebo testovací přístupy, které pro tyto kroky použijeme, nebo řekneme fráze pro testování našeho produktu a poskytnutí konečného výsledku, což je Dobře Testovaný produkt.

Pojďme to probrat podrobně a porovnat to s testováním Hadoop.

Víme, že Hadoop je něco, co se používá pro dávkové zpracování, a také víme, že ETL je jednou z oblastí, kde se Hadoop hodně používá. ETL znamená Extrakční transformace a načítání . Tyto procesy podrobně probereme, když budeme diskutovat o plánu testování a strategii testování z hlediska testování Hadoop.

Podle níže uvedeného diagramu předpokládáme, že máme čtyři různé zdroje dat. Operační systém, CRM ( Management vztahu se zákazníky ) a ERP ( Plánování podnikových zdrojů ) je RDBMS nebo řekněme Relational DataBase Management System, který máme, a máme také spoustu hromadných souborů, které mohou protokoly, soubory, záznamy nebo cokoli jiného týkající se našich zdrojů dat.

Mohli bychom používat Sqoop nebo Flume nebo jakýkoli konkrétní produkt k získání dat, záznamů nebo cokoli jiného jako mých zdrojů dat. Tyto nástroje můžeme použít k získání dat ze zdrojů dat do mého pracovní adresáře, což je první fáze našeho procesu Extrakce.

Jakmile jsou data v něm pracovní adresář, který je ve skutečnosti HDFS (Hadoop Distribution File System), použijeme zejména skriptovací jazyk, jako je PIG, Přeměnit ta Data. Že Proměna bude podle údajů, které máme.

Jakmile budou Data odpovídajícím způsobem transformována pomocí jakékoli skriptovací technologie, kterou máme, budeme načítání že data do datového skladu. Z datového skladu budou tato data použita pro analýzu OLAP, vytváření sestav a dolování dat nebo pro Analytics.

Pojďme si promluvit o tom, které všechny fáze můžeme pro testování Hadoop použít.

První fází bude fáze extrakce. Zde budeme získávat data z našich zdrojových databází nebo z plochých souborů a v takovém případě můžeme udělat, abychom mohli ověřit, že všechna data byla úspěšně a správně zkopírována ze zdroje do pracovní adresáře.

Může zahrnovat ověření počtu záznamů, typu záznamů a typu polí atd.

Jakmile jsou tato data zkopírována do pracovního adresáře, pokračujeme a spustíme druhou fázi, kterou je Transformace. Zde budeme mít nějakou obchodní logiku, která bude působit na zkopírovaná data ze zdrojových systémů a ve skutečnosti vytvoří nebo transformuje data do požadované obchodní logiky.

Transformace může zahrnovat třídění dat, filtrování dat, připojení dat ze dvou různých zdrojů dat a určité další operace.

Jakmile se Data transformují, pokračujeme a máme připravené testovací plány a zkontrolujeme, zda získáváme výstup podle očekávání, a veškerý výstup, který získáváme, splňuje očekávaný výsledek a datové typy, hodnoty pole a rozsahy atd. spadají na místo.

Jakmile je správná, můžeme pokračovat a načíst data do Data Warehouse.

Ve fázi načítání vlastně kontrolujeme, zda je počet záznamů ze Stage a počet záznamů v Data Warehouse synchronizován, nemusí být podobné, ale předpokládá se, že jsou synchronizovány. Vidíme také, zda je typ dat, který byl transformován, synchronizován.

Zveřejněte, že tato data použijeme pro analýzu, vykazování a dolování dat OLAP, což je poslední vrstva našeho produktu, a v takovém případě můžeme mít k dispozici následné nebo můžeme říci, že pro všechny tyto vrstvy jsou k dispozici plány testů.

Kdykoli získáme některá data ze zdroje do cíle, musíme se vždy ujistit, že k datům mají autorizovaný přístup pouze ověřené osoby.

Ověření

Ověření

Oprávnění

Oprávnění

Co máme na mysli pod oběma těmito pojmy?

Abychom tomu porozuměli, pojďme si představit věci v perspektivě z ETL diagramu.

ETL

Podle výše uvedeného diagramu dostáváme naše data ze zdrojových RDBMS motorů a z plochých souborů do HDFS a tato fáze se nazývá extrakce.

Pojďme diskutovat o autentizaci konkrétním způsobem, existují určité podniky, které mají Data, která jsou omezena svou povahou, tento typ Data se podle standardů Spojených států nazývá Data PII.

PII znamená Osobní identifikovatelné údaje, veškeré informace, jako je datum narození, SSN, číslo mobilního telefonu, e-mailová adresa a adresa domu atd., spadají pod PII. To je omezeno a nelze jej sdílet se všemi.

Údaje by měly být sdíleny pouze s osobami, které je nejvíce potřebují, a těmi, kteří je potřebují ke skutečnému zpracování. Mít tuto kontrolu a první linii obrany na místě se nazývá Ověření.

Například, používáme notebook a máme tam nainstalovaný Windows, můžeme mít vytvořený nějaký uživatelský účet v našem operačním systému Windows a tam jsme aplikovali heslo.

Tímto způsobem se do systému může přihlásit pouze osoba, která má pověření pro tento konkrétní uživatelský účet, a tak budeme chránit naše data před krádeží nebo zbytečným přístupem. Druhou vrstvou je Autorizace.

Příklad, v našem operačním systému Windows máme dva různé uživatelské účty, jeden uživatelský účet je náš a druhý může být uživatelský účet hosta. Správce (WE) má právo provádět všechny druhy operací, jako je instalace a odinstalování softwaru, vytváření nových souborů a mazání stávajících souborů atd.

Zatímco na druhou stranu, uživatelé typu host nemusí mít všechny tyto přístupy. Host má autentizaci pro přihlášení do systému, ale nemá oprávnění mazat nebo vytvářet soubory a instalaci, ani odinstalovat jakýkoli software v systému, respektive ze systému.

Uživatelský účet hosta však z důvodu ověření má právo číst vytvořené soubory a používat software, který je již nainstalován.

Takto se testuje ověřování a autorizace, v tomto případě bez ohledu na data dostupná v HDFS nebo v jakémkoli ze souborových systémů, které potřebujeme ke kontrole autentizace a autorizace dat.

Přístup k testování pro testování Hadoop / testování BigData

Přístup k testování

Přístup k testování je společný pro všechny druhy testování, nejen proto, že jde o BigData nebo Hadoop Testing, když přejdeme k Normálnímu ručnímu testování nebo Testování automatizace nebo Testování zabezpečení, Testování výkonu také, takže jakýkoli druh Testování sleduje stejný přístup.

Požadavky

Jako součást testovacího přístupu musíme začít s Požadavky „Požadavek je základní věc, dnes jsme jej v agilním procesu nazývali Stories and Epics. Epic není nic jiného než větší požadavek, zatímco Stories jsou menší požadavky.

Požadavek v zásadě obsahuje, jaké jsou všechny datové modely, cíle, zdroje a jaké transformace musíme použít, jaké nástroje musíme použít? Všechny tyto druhy podrobností budou k dispozici v Požadavcích.

Jedná se v zásadě o požadavek klienta nebo požadavky zákazníka. Na základě tohoto požadavku zahájíme proces testování.

Odhad

Další součástí přístupu je Odhad „Kolik času potřebujeme, aby celá činnost proběhla v rámci testování. Děláme plánování testů, připravujeme testovací scénáře, připravujeme testovací případy a provádíme je, stejně tak najdeme závady a nahlásíme je a připravíme také testovací protokoly.

Všechny tyto aktivity budou nějakou dobu trvat, takže kolik času potřebujeme k dokončení všech těchto aktivit a tomu se v zásadě říká Odhad. Musíme vedení dát hrubý odhad.

Plánování testů

Plánování testů není nic jiného než popis procesů, co testovat, co netestovat, jaký je rozsah testování, jaké jsou plány, kolik zdrojů je vyžadováno, požadavky na hardware a software a jaké jsou časové osy a testovací cykly budou použity, jaké jsou úrovně testování, které jsme požadovali atd.

Během plánování testu provedou určité přidělení zdrojů projektu a jaké jsou různé modely, které máme, kolik zdrojů je požadováno a jaké sady dovedností jsou požadovány atd. Všechny tyto věci a aspekty budou zahrnuty do testu Fáze plánování.

Plánování testů většinou provedou lidé na hlavní nebo manažerské úrovni.

Testovací scénáře a testovací případy

Jakmile skončíme s plánováním testů, musíme se připravit Testovací scénáře a testovací případy , zejména pro testování velkých dat, spolu s dokumentem požadavku vyžadujeme několik dokumentů. Co vše spolu s tímto dokumentem požadavku potřebujeme?

Potřebujeme Doklad o požadavku který obsahuje potřeby klienta, spolu s tím potřebujeme Vstupní dokument tj. Datové modely. Datový model v tom smyslu, co jsou schémata DataBase, jaké jsou tabulky a jaké jsou vztahy, všechna tato data budou k dispozici v datových modelech.

Také máme Mapování dokumentů , Mapování dokumentů pro Např. v relačních databázích máme nějaké tabulky a po načtení dat prostřednictvím ETL v Data Warehouse v HDFS, co všechno je třeba mapovat? tj. mapování datového typu.

jak zobrazit soubor .dat

Například, pokud máme tabulku zákazníků v HDFS, pak v HDFS máme tabulku CUSTOMER_TARGET nebo stejná tabulka může být také v HIVE.

Mapování dat

V této tabulce zákazníků máme určité sloupce a v tabulce CÍLE ZÁKAZNÍKA máme určité sloupce, jak je znázorněno v diagramu. Vypsali jsme data z tabulky zákazníků do tabulky CÍLŮ ZÁKAZNÍKŮ, tj. Zdroje do cíle.

Pak musíme zkontrolovat přesné mapování, jako jsou Data přítomná ve zdrojové tabulce, což je sloupec 1 a řádek 1 zákaznické tabulky, a považuje ji za C1R1 a stejná data by měla být mapována v C1R1 tabulky CÍLE ZÁKAZNÍKA. Tomu se v zásadě říká Mapování.

Jak budeme vědět, jaké jsou všechna mapování, která potřebujeme k ověření? Takže tato mapování budou přítomna v mapovacím dokumentu. V mapovacím dokumentu zákazník uvede všechny druhy mapování.

Také jsme požadovali a Návrhový dokument „Návrhový dokument vyžadovaný jak pro vývojový tým, tak pro tým QA, protože v návrhovém dokumentu zákazník uvede, jaký druh Map Reduce Jobs bude implementovat a jaký typ MapReduce Jobs vstupuje a jaký typ MapReduce Jobs dává výstupy.

Podobně, pokud máme HIVE nebo PIG, jaké jsou všechny UDF, které zákazník vytvořil, a jaké jsou všechny vstupy, které vezmou a jaký výstup budou produkovat atd.

Abychom mohli připravit testovací scénáře a testovací případy, musíme mít všechny tyto dokumenty ručně:

  • Doklad o požadavku
  • Datový model
  • Mapovací dokument
  • Návrhový dokument

Ty se mohou v jednotlivých organizacích lišit a neexistuje žádné povinné pravidlo, že všechny tyto dokumenty musíme mít. Někdy máme všechny dokumenty a někdy máme jen dva nebo tři dokumenty, nebo se někdy musíme spoléhat na jeden dokument, to je až na složitost projektu, časové plány společnosti a všechno.

Recenze testovacích scénářů a testovacích případů

Musíme provést kontrolu testovacích scénářů a testovacích případů, protože nějak nebo v některých případech zapomeneme nebo nám některé testovací případy chybí, protože každý nemůže myslet na všechny možné věci, které lze s požadavky udělat, za takových podmínek musíme vzít pomoc od nástrojů třetích stran nebo od někoho jiného.

Kdykoli tedy připravujeme nějaké dokumenty nebo něco provádíme, potřebujeme někoho, aby zkontroloval obsah od stejného týmu, jako jsou vývojáři, testeři. Poskytnou správné návrhy, aby zahrnovaly něco více, nebo také navrhnou aktualizaci nebo úpravu testovacích scénářů a testovacích případů.

Poskytují všechny komentáře a na základě toho budeme aktualizovat naše testovací scénáře a testovací případy a několik verzí dokumentu, které potřebujeme vydat napříč týmem, dokud nebude dokument plně aktualizován podle požadavku.

Provedení testu

Jakmile je dokument připraven, dostaneme odhlášení z horního týmu, abychom zahájili proces provádění, který se v zásadě nazývá Test Case Execution.

Pokud chceme provést naše testovací případy během provádění, musíme zkontrolovat, zda vývojář musí informace odeslat, pokud se jedná o normální funkční testování nebo jiné testování nebo testování automatizace, které vyžadujeme sestavení. Ale tady z hlediska testování Hadoop nebo BigData poskytne vývojář MapReduce Jobs.

Soubory HDFS - bez ohledu na soubory, které jsou zkopírovány do HDFS, jsou tyto informace potřebné ke kontrole oprávnění, skripty HIVE, které byly vytvořeny vývojáři k ověření dat v tabulce HIVE, a také potřebujeme HIVE UDF, které byly vyvinuty vývojáři, PIG Skripty a PIG UDF.

To jsou vše, co potřebujeme od vývojářů. Než půjdeme na popravu, měli bychom mít všechny tyto věci.

Pro MapReduce Jobs poskytnou některé soubory JAR a jako součást HDFS již načetli data do HDFS a soubory by měly být připraveny a HIVE skripty k ověření dat v HIVE tabulkách. Bez ohledu na UDF, které implementovali, bude k dispozici v HIVE UDF. Totéž požadujeme i pro PIG skripty a UDF.

Hlášení a sledování vad

Jakmile provedeme naše testovací případy, zjistíme, že některé vady, některé očekávané a některé skutečné, se nerovnají očekávaným výsledkům, takže musíme vypsat totéž a poskytnout je vývojovému týmu k řešení, což se v zásadě nazývá Defektní hlášení.

Předpokládejme, že pokud v MapReduce Job najdeme nějaký Defekt, nahlásíme to vývojáři a oni znovu vytvoří MapReduce Job a udělají nějaké úpravy na úrovni kódu a pak zase poskytnou nejnovější MapReduce Job, kterou musíme otestovat .

Toto je trvalý proces, jakmile je úloha otestována a předána, musíme ji znovu otestovat a nahlásit vývojáři a poté získat další pro testování. Takto se provádí aktivita hlášení a sledování vad.

Protokoly o zkouškách

Jakmile jsme dokončili celý proces testování a vady byly uzavřeny, musíme vytvořit naše protokoly o testování. Zkušební zprávy jsou vše, co jsme dosud pro dokončení procesu testování udělali. Veškeré plánování, psaní a provádění testovacích případů, jaký výstup jsme dostali atd., Vše je společně dokumentováno ve formě testovacích protokolů.

Tyto zprávy musíme zasílat denně nebo týdně nebo podle potřeb zákazníka. V současné době organizace používají model AGILE, takže je třeba během Denních scrumů aktualizovat všechny zprávy o stavu.

Závěr

V tomto kurzu jsme prošli:

  • Strategie nebo plán testování BigData.
  • Požadované prostředí pro testování BigData.
  • Ověření a ověření BigData.
  • Nástroje používané při testování BigData.

Dozvěděli jsme se také o -

  • Jak strategie testování, vývoj testů, provádění testů, správa defektů a dodávka fungují v rolích a odpovědnosti jako součást testování Hadoop.
  • Přístup k testování pro testování Hadoop / BigData, který zahrnuje shromažďování požadavků, odhad, plánování testů, vytváření testovacích scénářů a testovacích případů spolu s recenzemi.
  • Také jsme se dozvěděli o provádění testu, hlášení a sledování vad a hlášení o testu.

Doufáme, že vám tento návod k testování BigData pomohl!

=> Zkontrolujte VŠECHNY výukové programy BigData zde.

Doporučené čtení

^