Meny

Omfattande Hadoop-testhandledning | Big Data Testing Guide

  • Huvud
  • Övrig
  • Omfattande Hadoop-testhandledning | Big Data Testing Guide

comprehensive hadoop testing tutorial big data testing guide

Prova Vårt Instrument För Att Eliminera Problem

Denna handledning förklarar grunderna, testtyper, planer, nödvändig miljö, testprocess, validering och verifiering för Hadoop- och BigData-testning:

I den här handledningen kommer vi att se den grundläggande introduktionen till Hadoop och BigData Testing, som när och var testningen kommer in i bilden och vad vi behöver testa som en del av Hadoop Testing.

Vi kommer också att diskutera följande ämnen i detalj:

  • Roller och ansvar för Hadoop-testning
  • Testmetod för Hadoop / BigData-testning

=> Kolla här för att se A-Z av BigData-utbildningsövningar här.

Introduktion till BigData- och Hadoop-testning

Vad du kommer att lära dig:

Lagring och bearbetning av data i Hadoop

För att utföra dessa processer på Hadoop-systemet har vi arbetskraften som är kategoriserad i fyra sektioner.

  • Hadoop-administratörer ansvarar för att ställa in miljön och har administrationsrättigheter för åtkomst till Hadoop-systemen.
  • Hadoop-utvecklare utveckla programmen för att dra, lagra och bearbeta data från olika platser till centraliserade platser.
  • Hadoop-testare för att validera och verifiera data innan du drar från olika platser och efter att ha dragit på den centraliserade platsen samt att validering och verifiering görs medan data laddas till klientmiljön.
  • Hadoop-analytiker fungerar när dataladdningen är klar och när data når lagret på klientplatsen. De använder dessa data för generering av rapporter och instrumentpaneler. Analytikerna utför dataanalysen för tillväxt och affärsutveckling.

Vi vet att Hadoop inte är ett enda system; den innehåller flera system och maskiner. Data delas upp och lagras i flera datorer och om vi vill komma åt den igen måste vi kombinera och dra in data i rapporter och så vidare.

Utvecklaren ansvarar för att skriva program i JAVA och Python för att extrahera data och lagra dem.

Det andra jobbet för en utvecklare är att bearbeta data. Det finns två lager av Hadoop, ett är för lagring d.v.s. Hadoop HDFS och ett annat för bearbetning dvs Hadoop MapReduce.

Lagring betyder att alla data vi har i källan bara lagras / infogas i systemet. Bearbetning innebär att vi måste dela upp det i flera maskiner och kombinera igen och skicka det till klienten.

Således lagras och bearbetas genom programmering av skript, och utvecklaren är ansvarig för att skriva skripten.

Förutom programmering använder den andra metoden för att lagra och bearbeta data i Hadoop databasapplikationer som Hive, Impala, HBase, etc. Dessa verktyg behöver ingen programmeringskunskap.

BigData och Hadoop-testning

När lagring och bearbetning har gjorts av utvecklaren går data för rapportgenerering. Innan det måste vi verifiera de bearbetade uppgifterna för noggrannhet och kontrollera om uppgifterna är korrekt laddade och behandlade korrekt eller inte.

Så programmet och / eller skript som skapats av en utvecklare måste verifieras av Hadoop eller BigData Tester. Testaren behöver känna till grundläggande programmering som Mapper, Hive, Pig Scripts, etc. för att verifiera skript och för att utföra kommandona.

Så innan testning måste testarna veta vad alla program och skript fungerar, hur man skriver koden och sedan funderar på hur man testar dem. Testning kan göras antingen manuellt eller med hjälp av automatiseringsverktyg.

Hadoop har olika typer av tester som Unit Testing, Regression Testing, System Testing, and Performance Testing, etc. Så det här är de vanliga testtyperna som vi använder i vår normala testning samt Hadoop- och BigData-testning.

Vi har samma typ av testterminologier som teststrategi, testscenarier och testfall etc. i Hadoop och BigData Testing. Endast miljön är annorlunda och det finns olika typer av tekniker som vi använder för att testa BigData och Hadoop-systemet eftersom vi här måste testa data och inte applikationen.

Hur testar du BigData och vad som krävs testas i BigData?

För BigData-testning måste vi ha några planer och strategier.

Därför måste vi överväga följande punkter:

  • Vad är strategin eller planen för testning för BigData?
  • Vilken typ av testmetoder tillämpas på BigData?
  • Vad krävs miljön?
  • Hur validerar och verifierar du BigData?
  • Vilka är de verktyg som används i BigData Testing?

Låt oss försöka få svar på alla ovanstående frågor.

Vad är strategin eller planen för att testa BigData?

BigData-testning innebär verifiering och validering av data medan de lagras och bearbetas i datalageret.

När vi testar BigData måste vi testa volymen och variationen av data som extraheras från olika databaser och laddas såväl som bearbetas på Data Warehouse eller Hadoop System, denna testning kommer att testas funktionellt.

Vi måste testa hastigheten på de data som laddas ner från olika databaser och laddas upp till Hadoop-systemet, som är en del av Performance Testing.

Så som en plan eller strategi måste vi koncentrera oss på såväl funktionell som prestandatestning av BigData-testning.

I BigData Testing måste testaren verifiera behandlingen av en enorm mängd data med hjälp av Commodity Hardware och relativa komponenter. Därför spelar datakvaliteten också en viktig roll i testningen av BigData. Det är viktigt att verifiera och validera datakvaliteten.

Testtyper för BigData-testning

I föregående avsnitt såg vi att funktionstestning och prestandatestning spelar en viktig roll i BigData-testning, förutom det som en BigData-testare, vi måste göra några fler typer av tester som Databastestning samt Arkitektonisk testning.

Dessa testtyper är också lika viktiga som funktionstestning och prestandatestning.

# 1) Arkitektonisk testning

Denna testning görs för att säkerställa att behandlingen av data är korrekt och uppfyller kraven. Egentligen bearbetar Hadoop-systemet enorma datamängder och är mycket resursomfattande.

Om arkitekturen är felaktig kan den försämra prestandan på grund av vilken databehandling kan avbryta och dataförlust kan inträffa.

# 2) Databastestning

Här kommer processvalideringen in i bilden och vi måste validera data från olika databaser, dvs. vi måste se till att data som hämtas från källdatabaserna eller lokala databaser måste vara korrekta och korrekta.

Vi måste också kontrollera att de data som finns tillgängliga i källdatabaserna matchas med de data som anges i Hadoop System.

DataBase-testning

På samma sätt måste vi validera om data i Hadoop System är korrekta och korrekta efter bearbetning eller säga efter transformation och att laddas till klientens miljö med korrekt validering och verifiering.

Som en del av databastestning måste vi gå igenom GRYM verksamhet dvs. Skapa data i lokala databaser då Hämta data och vi måste söka efter dem och de ska vara tillgängliga i databasen före och efter laddning i datalager och från datalager till kundens miljö.

Verifiering av eventuella Uppdaterad Data om varje steg i lagring eller laddning och bearbetning av data. Radering av skadad data eller dubbletter och nolldata.

# 3) Prestandatestning

Som en del av Performance Testing måste vi kontrollera laddnings- och bearbetningshastigheten för data, dvs som IOPS (Input Output Per Second).

Behöver kontrollera hastigheten för att mata in data eller data som en inmatning från olika databaser till datalager eller Hadoop-system och från Hadoop-system eller datalager till kundens miljö.

Måste också kontrollera hastigheten på data som kommer från olika databaser och från datalageret som en utdata. Det här är vad vi kallar Input Output Per Second eller IOPS.

Bortsett från det är en annan aspekt att kontrollera prestanda för dataabsorption och datadistribution och hur snabbt datan konsumeras av datalagret från olika databaser och av kundens system från Hadoop-systemet.

Som testare måste vi också kontrollera datadistributionens prestanda, hur snabbt informationen distribueras till olika filer som finns i Hadoop-systemet eller i datalageret. På samma sätt sker samma process när data distribueras till klientsystem.

Hadoop-systemet eller datalagret består av flera komponenter, så en testare måste kontrollera prestanda för alla dessa komponenter som MapReduce Jobs, datainsättning och konsumtion, svarstiden för frågor och deras prestanda samt sökningens prestanda operationer. Alla dessa ingår i Prestandatestning.

# 4) Funktionstestning

Funktionstestning innehåller test av alla underkomponenter, program och skript, verktyg som används för att utföra lagring eller laddning och bearbetning etc.

För en testare är detta de fyra viktiga typerna och stadierna genom vilka data måste filtreras så att klienten får perfekta och felfria data.

Verktyg för BigData Hadoop-testning

Det finns olika verktyg som används för att testa BigData:

  • HDFS Hadoop Distribution File System för lagring av BigData.
  • HDFS Map Reduce för bearbetning av BigData.
  • För NoSQL eller HQL Cassandra DB, ZooKeeper och HBase, etc.
  • Molnbaserade serververktyg som EC2.

Testa miljöer och inställningar

För alla typer av tester behöver testaren korrekta inställningar och miljö.

Nedan följer en lista med krav:

  1. Typ av data och applikation som kommer att testas.
  2. Lagring och bearbetning kräver ett stort utrymme för en enorm mängd data.
  3. Korrekt distribution av filer på alla DataNodes i hela klustret.
  4. Vid bearbetning av data bör maskinvaran vara minimal.
  5. Körbara program och skript enligt kraven i applikationen.

Roller och ansvar för Hadoop-testning

Som en Hadoop-testare är vi ansvariga för att förstå kraven, förbereda testuppskattningarna, planera testcases, få några testdata för att testa några testcases, vara involverade i skapandet av testbäddar, genomföra testplanerna, rapportering och omprövning av defekter.

Vi måste också vara ansvariga för daglig statusrapportering och testavslutning.

Roller och ansvar för Hadoop-testning

Det första vi ska diskutera är Teststrategi . När vi väl har en föreslagen lösning på vårt problem måste vi gå vidare och planera eller strategisera vår testplan, vi kan diskutera automatiseringsstrategin som vi kan använda där inne, planen om testschemat som beror på våra leveransdatum, också vi kan diskutera resursplanering.

Automationsstrategin är något som kommer att hjälpa oss att minska de manuella ansträngningar som krävs för att testa produkten. Testschemat är viktigt eftersom det säkerställer att produkten levereras i rätt tid.

Resursplanering kommer att vara avgörande eftersom vi behöver planera hur mycket arbetstimmar vi behöver i vår testning och hur mycket Hadoop-resurser som krävs för att genomföra vår testplanering.

När vi väl har strategiserat våra tester måste vi gå vidare och skapa testutvecklingsplaner som inkluderar att skapa testplaner, skapa testskript som hjälper oss att automatisera våra tester och även identifiera några testdata som kommer att användas i testplanerna. och hjälper oss att genomföra dessa testplaner.

När vi är färdiga med testutvecklingen som inkluderar att skapa testplaner, testskript och testdata, fortsätter vi och kör dessa testplaner.

När vi utför testplanerna kan det finnas vissa scenarier där den faktiska produktionen inte är som förväntat, och dessa saker kallas defekter. Närhelst det finns en defekt måste vi också testa dessa defekter och vi måste skapa och underhålla matriserna för dem.

Alla dessa saker faller under nästa kategori som är Defekthantering .

Vad är felhantering?

Defekthantering består av bugspårning, bugfixning och bugverifiering. När en testplan utförs mot någon av de produkter som vi har och så snart en viss bugg identifieras eller en defekt identifieras måste den felet rapporteras till utvecklaren eller tilldelas utvecklaren.

Så utvecklaren kan titta på det och börja arbeta med det. Som testare måste vi spåra felet och spåra om felet har rättats. Om felet har åtgärdats som rapporterat måste vi fortsätta och testa om det och verifiera om det är löst.

När alla fel har fixats, stängts och verifierats måste vi fortsätta och leverera en OKAY-testad produkt. Men innan vi levererar produkten måste vi se till att UAT (User Acceptance Testing) är klar.

Vi ser till att installationstestning och kravverifiering görs ordentligt, dvs produkten som levereras till klienten eller en slutanvändare är enligt kravet som nämns i programvarukravsdokumentet.

Stegen som vi har diskuterat är baserade på fantasin, vara någon av testscenarierna eller någon av de testmetoder som vi ska använda för dessa steg eller säg dessa fraser för att testa vår produkt och leverera slutresultatet, vilket är ett OKAY Testad produkt.

Låt oss gå vidare och diskutera detta i detalj och korrelera det med Hadoop-testningen.

Vi vet att Hadoop är något som används för batchbehandling och vi vet också att ETL är ett av de fält där Hadoop används mycket. ETL står för Extraction Transformation and Loading . Vi kommer att diskutera dessa processer i detalj när vi diskuterar testplanen och teststrategin som en Hadoop-testperspektiv.

Enligt diagrammet som nämns nedan antar vi bara att vi har fyra olika datakällor. Operativsystem, CRM ( Hantering av kundrelationer ) och ERP ( Enterprise Resource Planning ) är RDBMS eller säg Relational DataBase Management System som vi har och vi har också några gäng Flat Files som kanske loggar, filer, poster eller vad som helst till våra datakällor.

Vi kan använda Sqoop eller Flume eller vilken produkt som helst för att få data, register eller vad som helst som mina datakällor. Vi kan använda dessa verktyg för att få data från datakällorna till min iscensättningskatalog som är den första fasen av vår process som kallas Extraktion.

När Data däri Staging Directory som faktiskt råkar vara HDFS (Hadoop Distribution File System) kommer vi särskilt att använda skriptspråket som PIG för att Omvandla dessa data. Det där Omvandling kommer att vara enligt de uppgifter som vi har.

När data har transformerats i enlighet därmed med hjälp av vilken skriptteknologi vi har, kommer vi att vara det Läser in data i datalagret. Från datalageret kommer dessa data att användas för OLAP-analys, rapportering och datautvinning eller för Analytics.

Låt oss gå vidare och diskutera vilka alla faser vi kan använda för Hadoop-testning.

Den första fasen kommer att vara extraktionsfasen. Här ska vi hämta data från våra källdatabaser eller från platta filer, och i så fall kan vi verifiera att all data har kopierats framgångsrikt och korrekt från källa till Staging Directory.

Det kan inkludera, verifiera antalet poster, typen av poster och typen av fält etc.

När dessa data har kopierats till Staging Directory fortsätter vi och utlöser den andra fasen som är Transformation. Här kommer vi att ha en viss affärslogik som kommer att verka på de kopierade uppgifterna från källsystemen och faktiskt skapar eller förvandlar data till den önskade affärslogiken.

Transformation kan inkludera sortering av data, filtrering av data, sammanfogning av data från två olika datakällor och vissa andra åtgärder.

När data har transformerats fortsätter vi och har testplaner redo och vi kommer att kontrollera om vi får utdata som förväntat, och all utdata som vi får uppfyller förväntat resultat och datatyper, fältvärden och intervall etc. är något som faller på plats.

När det är korrekt kan vi fortsätta och ladda in data i Data Warehouse.

I laddningsfasen kontrollerar vi faktiskt om antalet poster från scenen och antalet poster i Data Warehouse är synkroniserade, de kanske inte är lika, men de ska vara synkroniserade. Vi ser också om den typ av data som har transformerats är synkroniserad.

Lägg upp att vi kommer att använda dessa data för OLAP-analys, rapportering och datautvinning som är det sista lagret i vår produkt och i så fall kan vi ha efterföljande eller så kan vi säga att testplanerna är tillgängliga för alla dessa lager.

Närhelst vi får in några data från källan till destinationen, måste vi alltid se till att endast autentiserade personer har auktoriserad åtkomst till data.

Autentisering

Autentisering

Tillstånd

Tillstånd

Vad menar vi med båda dessa termer?

För att förstå detta, låt oss få sakerna i perspektiv från ETL-diagrammet.

ETL

Enligt ovanstående diagram hämtar vi våra data från RDBMS-källor från källor och från platta filer till HDFS, och den fasen kallas extraktion.

Låt oss diskutera autentisering på ett visst sätt, det finns vissa företag som har data som är begränsade av sin natur, denna typ av data kallas som PII-data enligt de amerikanska standarderna.

PII står för Personligt identifierbar information, all information som födelsedatum, SSN, mobilnummer, e-postadress och adress till huset etc. faller under PII. Detta är begränsat och kan inte delas med alla.

Uppgifterna bör endast delas med de personer som behövde det mest och de som behöver Uppgifterna för faktisk behandling. Att ha den här kontrollen och den första försvarslinjen på plats heter Authentication.

Till exempel, vi använder en bärbar dator och vi har Windows installerat där, vi kan ha skapat ett användarkonto på vårt Windowsoperativsystem och där använde vi ett lösenord.

På det här sättet kan endast den person som har referenser för det här användarkontot logga in på systemet och det är så vi ska skydda våra data från stöld eller onödig åtkomst. Det andra lagret är auktorisering.

Exempel, Vi har två olika användarkonton i vårt Windows-operativsystem, ett användarkonto är vårt och ett annat kan vara gästanvändarkontot. Administratören (WE) har rätt att utföra alla typer av åtgärder, till exempel installation och avinstallation av programvaran, Skapande av ny fil och radering av befintliga filer, etc.

Medan å andra sidan kanske gästanvändarna inte har all den här typen av åtkomst. Gästen har autentisering för att logga in på systemet men har inte behörighet att radera eller skapa filer och installation samt avinstallation av programvaran i systemet respektive från systemet.

Gästanvändarkontot har dock rätt att läsa de filer som skapas och använda den redan installerade programvaran.

Så här testas autentisering och auktorisering, i det här fallet, vilken data som helst som finns i HDFS eller något av de filsystem som vi behöver kontrollera för autentisering och auktorisering av data.

Testmetod för Hadoop-testning / BigData-testning

Testmetod

Testmetod är vanligt för alla typer av testning, inte bara för att det är BigData- eller Hadoop-testning när vi går till Normal manuell testning eller automatiseringstestning eller säkerhetstestning, även prestandatestning, så all typ av testning följer samma metod.

Krav

Som en del av testmetoden måste vi börja med Krav , Krav är en grundläggande sak, numera i Agile-processen kallade vi det som Stories and Epics. Epic är inget annat än ett större krav medan Stories är mindre krav.

Kravet innehåller i grunden alla datamodeller, mål, källor samt vilken typ av transformationer vi behöver tillämpa, vilken typ av verktyg vi måste använda? Alla dessa typer av detaljer kommer att finnas tillgängliga på kraven.

Detta är i princip kundkravet eller kundkraven. Baserat på detta krav kommer vi att starta vår testprocess.

Uppskattning

En annan del av en strategi är Uppskattning , Hur mycket tid vi behöver ta för att hela aktiviteten ska göras som en del av testningen. Vi gör testplanering, förbereder testscenarier, förbereder testfall och utförande av detsamma, så kommer vi att hitta defekter och rapportera dem och förbereda testrapporter också.

Alla dessa aktiviteter kommer att ta lite tid, så hur mycket tid vi behöver för att slutföra alla dessa aktiviteter och detta kallas i princip en uppskattning. Vi måste ge en grov uppskattning till ledningen.

Testplanering

Testplanering är inget annat än beskrivningen om processer, vad man ska testa, vad man inte ska testa, vad är testets omfattning, vad är scheman, hur många resurser som krävs, hårdvaru- och mjukvarukrav och vad är tidslinjerna samt testcykler kommer att användas, vilka testnivåer krävs vi etc.

Under testplaneringen kommer de att göra en viss resursallokering till projektet och vad är de olika modellerna vi har, hur många resurser som krävs och vilken typ av skicklighetsuppsättningar som krävs etc. alla dessa saker och aspekter kommer att ingå i testet Planeringsfas.

För det mesta kommer ledningsnivån eller ledningsnivån att göra testplaneringen.

Testscenarier och testfall

När vi är klara med testplaneringen måste vi förbereda oss Testscenarier och testfall , särskilt för Big Data Testing, kräver vi några dokument tillsammans med kravdokumentet. Tillsammans med detta kravdokument vad behöver vi allt?

Vi behöver Kravsdokument som innehåller kundens behov, tillsammans med detta behöver vi Ingångsdokument dvs. Datamodeller. Datamodell i den meningen vad är DataBase Schemas, vad är tabellerna och vilka förhållanden kommer alla dessa data att finnas tillgängliga i datamodellerna.

Vi har också Kartläggning av dokument , Mappningsdokument för T.ex. i Relational DataBases har vi några tabeller och efter laddning av Data via ETL i Data Warehouse i HDFS, vad är all kartläggning vi behöver göra? dvs. kartläggning av datatyp.

bästa programmet för att konvertera videofiler

Till exempel, om vi har en kundtabell i HDFS, har vi i HDFS en CUSTOMER_TARGET-tabell eller samma tabell kan också finnas i HIVE.

Datakartläggning

I denna kundtabell har vi vissa kolumner och i KUNDMÅL-tabellen har vi vissa kolumner som visas i diagrammet. Vi dumpade data från kundtabellen till KUNDMÅLTabellen, dvs. källa till mål.

Då måste vi kontrollera den exakta kartläggningen som den data som finns i källtabellen som är kundtabellens kolumn 1 och rad 1 och anser att den är C1R1 och samma data ska kartläggas i C1R1 i KUNDMÅLTabellen. Detta kallas i princip som Mapping.

Hur vet vi, vilka är alla kartläggningar vi behöver för att verifiera? Så dessa kartningar kommer att finnas i kartdokumentet. I kartläggningsdokumentet kommer kunden att ge alla typer av kartningar.

Vi har också krävt en Designdokument , Designdokument krävs både för utvecklingsteamet och QA-teamet, för i designdokumentet kommer kunden att tillhandahålla, vilken typ av kartreducerande jobb de ska implementera och vilken typ av MapReduce-jobb som används och vilken typ av MapReduce Jobb ger resultat.

På samma sätt, om vi har HIVE eller PIG, vad är alla UDF: er som kunden har skapat samt vad är all input de kommer att ta och vilken typ av output de kommer att producera, etc.

För att förbereda testscenarier och testfall måste vi ha alla dessa dokument för hand:

  • Kravsdokument
  • Datamodell
  • Kartläggningsdokument
  • Designdokument

Dessa kan variera från en organisation till en annan organisation, och det finns ingen obligatorisk regel att vi måste ha alla dessa dokument. Ibland har vi alla dokument och ibland har vi bara två eller tre dokument eller ibland behöver vi förlita oss på ett dokument också, det är upp till projektets komplexitet, företagsscheman och allt.

Recensioner om testscenarier och testfall

Vi måste göra en granskning av testscenarier och testfall för att vi på något sätt eller i vissa fall glömmer bort eller att vi saknar några testfall eftersom alla inte kan tänka på alla möjliga saker som kan göras med kraven, under sådana förhållanden måste vi ta hjälp från tredjepartsverktyg eller från någon annan.

Så när vi förbereder några dokument eller utför något behöver vi någon att granska sakerna från samma team, som utvecklare, testare. De kommer att ge korrekta förslag för att inkludera något mer eller också föreslå uppdatering eller modifiering av testscenarier och testfall.

De ger alla kommentarer och baserat på detta kommer vi att uppdatera våra testscenarier och testfall och flera versioner av dokumentet som vi behöver släppa i hela teamet tills dokumentet är fullständigt uppdaterad enligt kravet.

Testutförande

När dokumentet är klart får vi signaturen från det övre teamet för att starta exekveringsprocessen som i princip kallas Test Case Execution.

Om vi ​​vill utföra våra testfall under körning måste vi kontrollera att utvecklaren måste skicka informationen, om det är normalt funktionstestning eller någon annan testning eller automatiseringstestning kräver vi en Build. Men här från Hadoop- eller BigData-testperspektivet kommer utvecklaren att tillhandahålla MapReduce-jobb.

HDFS-filer - oavsett vilka filer som kopieras i HDFS, krävs det information om dessa filer för att kontrollera behörigheterna, HIVE-skript som skapades av utvecklarna för att verifiera data i HIVE-tabellen och vi behöver också HIVE UDF: er som utvecklats av utvecklarna, PIG Skript och PIG UDF: er.

Det här är alla saker vi behöver få från utvecklare. Innan vi går till avrättningen borde vi ha alla dessa saker.

För MapReduce-jobb kommer de att tillhandahålla vissa JAR-filer och som en del av HDFS har de redan laddat data i HDFS och filerna ska vara färdiga och HIVE-skript för att validera data i HIVE-tabeller. Oavsett vilka UDF de har implementerat kommer de att finnas tillgängliga i HIVE UDF: erna. Vi kräver samma sak även för PIG-skript och UDF.

Felrapportering och spårning

När vi väl har genomfört våra testfall hittar vi några defekter, vissa förväntade och vissa faktiska är inte lika med de förväntade resultaten, så vi måste lista ut samma och ge dem till utvecklingsteamet för lösning, och detta kallas i princip Defektrapportering.

Antag att om vi hittar något fel i MapReduce-jobbet, kommer vi att rapportera det till utvecklaren och de kommer att återskapa MapReduce-jobbet och de gör några modifieringar av kodnivå och sedan igen kommer de att tillhandahålla det senaste MapReduce-jobbet, som vi behöver testa .

Detta är en pågående process, när jobbet har testats och godkänts, måste vi igen testa det igen och rapportera det till utvecklaren och sedan få nästa för testning. Så här utförs felrapporterings- och spårningsaktiviteten.

Testrapporter

När vi är klara med hela testprocessen och bristerna har stängts måste vi skapa våra testrapporter. Testrapporter är vad vi har gjort för att slutföra testprocessen hittills. All planering, skrivning av testfall och utförande, vilken produktion vi fick osv. Allt dokumenteras tillsammans i form av testrapporter.

Vi måste skicka dessa rapporter dagligen eller veckovis eller enligt kundens behov. Numera använder organisationer AGILE-modellen, så varje statusrapport måste uppdateras under Daily Scrums.

Slutsats

I den här guiden gick vi igenom:

  • Strategin eller planen för att testa BigData.
  • Nödvändig miljö för BigData-testning.
  • BigData-validering och verifieringar.
  • Verktyg som används för att testa BigData.

Vi lärde oss också om -

  • Hur teststrategi, testutveckling, testkörningar, defekthantering och leverans fungerar i rollerna och ansvarsområdena som en del av Hadoop-testning.
  • Testmetod för Hadoop / BigData-test som inkluderar kravinsamling, uppskattning, testplanering, skapande av testscenarier och testfall tillsammans med recensionerna.
  • Vi lärde oss också om testutförande, felrapportering och spårning och testrapportering.

Vi hoppas att denna BigData-testhandledning hjälpte dig!

=> Kontrollera ALLA BigData-självstudier här.

Rekommenderad läsning

^