Meny

Omfattende Hadoop-testveiledning | Big Data Testing Guide

  • Hoved
  • Annen
  • Omfattende Hadoop-testveiledning | Big Data Testing Guide

comprehensive hadoop testing tutorial big data testing guide

Prøv Instrumentet Vårt For Å Eliminere Problemer

Denne opplæringen forklarer det grunnleggende, testtyper, planer, påkrevd miljø, testprosess, validering og verifisering for Hadoop- og BigData-testing:

I denne opplæringen vil vi se den grunnleggende introduksjonen til Hadoop og BigData Testing, som når og hvor testingen kommer inn i bildet, og hva vi trenger å teste som en del av Hadoop Testing.

Vi vil også diskutere følgende emner i detalj:

  • Roller og ansvar for Hadoop-testing
  • Testing Approach for Hadoop / BigData Testing

=> Sjekk her for å se AZ av BigData opplæringsveiledninger her.

Introduksjon til BigData og Hadoop Testing

Hva du vil lære:

Lagring og behandling av data i Hadoop

For å utføre disse prosessene på Hadoop-systemet har vi arbeidskraften som er kategorisert i fire seksjoner.

  • Hadoop-administratorer er ansvarlig for å sette opp miljøet og har administrasjonsrettighetene til å få tilgang til Hadoop Systems.
  • Hadoop-utviklere utvikle programmene for å trekke, lagre og behandle data fra forskjellige steder til sentraliserte steder.
  • Hadoop-testere for validering og verifisering av dataene før du trekker fra forskjellige steder og etter å ha trukket på det sentraliserte stedet, samt validering og verifisering gjøres mens du laster dataene til klientmiljøet.
  • Hadoop-analytikere fungere når datainnlasting er ferdig og når dataene når lageret på klientstedet. De bruker disse dataene for generering av rapporter og dashbord. Analytikerne utfører dataanalysen for vekst og forretningsutvikling.

Vi vet at Hadoop ikke er et eneste system; den inneholder flere systemer og maskiner. Dataene deles og lagres i flere maskiner, og hvis vi vil ha tilgang til dem igjen, må vi kombinere og trekke dataene i rapporter og så videre.

Utvikleren er ansvarlig for å skrive programmer i JAVA og Python for å trekke ut dataene og lagre dem.

Den andre jobben til en utvikler er å behandle dataene. Det er to lag med Hadoop, det ene er for lagring, dvs. Hadoop HDFS, og et annet for behandling, dvs. Hadoop MapReduce.

Lagring betyr at data vi har i kilden bare blir lagret / satt inn i systemet. Behandling betyr at vi må dele den i flere maskiner og igjen kombinere og sende den til klienten.

Dermed gjøres lagring og prosessering ved å programmere manus, og utvikleren er ansvarlig for å skrive manusene.

Bortsett fra programmering, bruker den andre metoden for å lagre og behandle dataene i Hadoop databaseapplikasjoner som Hive, Impala, HBase osv. Disse verktøyene trenger ingen programmeringskunnskap.

BigData og Hadoop-testing

Når lagring og behandling er gjort av utvikleren, går dataene for generering av rapporter. Før det må vi verifisere de behandlede dataene for nøyaktighet og kontrollere om dataene er nøyaktig lastet inn og behandlet riktig eller ikke.

Så programmet og / eller skriptene som er opprettet av en utvikler, må verifiseres av Hadoop eller BigData Tester. Testeren trenger å vite grunnleggende programmering som Mapper, Hive, Pig Scripts, etc. for å verifisere skriptene og for å utføre kommandoene.

Så før testene, må testerne vite hva alle programmer og skript fungerer, hvordan man skriver koden og deretter tenker på hvordan de skal testes. Testing kan gjøres enten manuelt eller ved hjelp av automatiseringsverktøy.

Hadoop har forskjellige typer tester som Unit Testing, Regression Testing, System Testing, and Performance Testing, etc. Dette er de vanligste testtypene vi bruker i vår normale testing, samt Hadoop og BigData-testing.

Vi har samme type testterminologier som teststrategi, testscenarier og testtilfeller etc. i Hadoop og BigData Testing. Bare miljøet er annerledes, og det er forskjellige typer teknikker vi bruker for å teste BigData og Hadoop-systemet, fordi vi her må teste dataene og ikke applikasjonen.

Hvordan teste BigData og hva alle ting krever testing i BigData?

For BigData-testing må vi ha noen planer og strategier.

Derfor må vi vurdere følgende punkter:

  • Hva er strategien eller planen for testing for BigData?
  • Hva slags testtilnærminger brukes på BigData?
  • Hva kreves miljøet?
  • Hvordan validere og verifisere BigData?
  • Hva er verktøyene som brukes i BigData Testing?

La oss prøve å få svarene på alle spørsmålene ovenfor.

Hva er strategien eller planen for å teste BigData?

BigData-testing betyr verifisering og validering av data mens de lagres og behandles i datavarehuset.

Mens vi tester BigData, må vi teste volumet og variasjonen av data hentet fra forskjellige databaser og lastet så vel som behandlet på Data Warehouse eller Hadoop System. Denne testen kommer under funksjonell testing.

Vi må teste hastigheten på dataene som er lastet ned fra forskjellige databaser og lastet opp til Hadoop-systemet, som er en del av Performance Testing.

Så som en plan eller strategi, må vi konsentrere oss om funksjonell så vel som ytelsestesting av BigData-testing.

I BigData Testing må testeren verifisere behandlingen av en enorm mengde data ved hjelp av Commodity Hardware og relative komponenter. Derfor spiller kvaliteten på data en viktig rolle i testingen av BigData. Det er viktig å verifisere og validere datakvaliteten.

Testingstyper for BigData-testing

I forrige avsnitt så vi at funksjonstesting og ytelsestesting spiller en viktig rolle i BigData Testing, bortsett fra det som en BigData Tester, må vi gjøre noen flere typer testing som databasetesting så vel som arkitektonisk testing.

Disse testtypene er også like viktige som funksjonelle og ytelsestesting.

# 1) Arkitektonisk testing

Denne testingen er gjort for å sikre at behandlingen av data er riktig og oppfyller kravene. Egentlig behandler Hadoop-systemet store datamengder og er svært ressurskomponent.

Hvis arkitekturen er feil, kan det forringe ytelsen som kan føre til at behandlingen av data kan avbryte og tap av data kan oppstå.

# 2) Databasetesting

Her kommer prosessvalidering inn i bildet, og vi må validere dataene fra forskjellige databaser, dvs. vi må sørge for at dataene hentet fra kildedatabasene eller lokale databaser må være korrekte og riktige.

Vi må også sjekke at dataene som er tilgjengelige i kildedatabasene samsvarer med dataene som er angitt i Hadoop System.

DataBase Testing

På samme måte må vi validere om dataene i Hadoop System er korrekte og riktige etter bearbeiding eller si etter transformasjon og å lastes til klientens miljø med riktig validering og verifisering.

Som en del av databasetesting, må vi gå gjennom GRUSOM operasjoner dvs. Skape dataene i lokale databaser da Hente dataene, og vi må søke i dem, og de skal være tilgjengelige i databasen før og etter innlasting i datavarehus og fra datavarehus til klientens miljø.

Bekreftelse av eventuelle Oppdatert Data på hvert trinn i lagring eller lasting og behandling av dataene. Sletting av ødelagte data eller dupliserte og null data.

# 3) Ytelsestesting

Som en del av Performance Testing, må vi sjekke innlastings- og behandlingshastigheten til data, dvs. som IOPS (Input Output Per Second).

Må sjekke hastigheten på å legge inn dataene eller dataene som en inngang fra forskjellige databaser til Data Warehouse eller Hadoop System og fra Hadoop System eller Data Warehouse til Client's Environment.

Må også kontrollere hastigheten på dataene som kommer fra forskjellige databaser og fra datalageret som en utdata. Dette er det vi kaller som Input Output Per Second eller IOPS.

Bortsett fra det, er et annet aspekt å kontrollere ytelsen til dataabsorpsjonen og datadistribusjonen, og hvor raskt dataene konsumeres av datalageret fra forskjellige databaser og av klientens system fra Hadoop-systemet.

Også som en tester, må vi sjekke ytelsen til datadistribusjonen, hvor raskt dataene distribueres til forskjellige filer som er tilgjengelige i Hadoop-systemet eller i datalageret. På samme måte skjer den samme prosessen mens data distribueres til klientsystemer.

Hadoop-systemet eller datalageret består av flere komponenter, så en tester må sjekke ytelsen til alle disse komponentene, som MapReduce Jobs, datainnsetting og forbruk, responstid på spørsmål og ytelse samt søket. operasjoner. Alle disse er inkludert i ytelsestesting.

# 4) Funksjonstesting

Funksjonstesting inneholder testing av alle underkomponenter, programmer og skript, verktøy som brukes til å utføre operasjonene for lagring eller lasting og prosessering, etc.

For en tester er dette de fire viktige typene og trinnene dataene må filtreres gjennom slik at klienten får de perfekte og feilfrie dataene.

Verktøy for BigData Hadoop-testing

Det er forskjellige verktøy som brukes til å teste BigData:

  • HDFS Hadoop Distribution File System for lagring av BigData.
  • HDFS Map Reduce for behandling av BigData.
  • For NoSQL eller HQL Cassandra DB, ZooKeeper og HBase, etc.
  • Skibaserte serververktøy som EC2.

Testing av miljøer og innstillinger

For enhver type testing trenger testeren riktige innstillinger og miljøet.

Nedenfor er listen over krav:

  1. Type data og applikasjon som skal testes.
  2. Lagring og behandling krever stor plass for en enorm mengde data.
  3. Riktig distribusjon av filer på alle DataNodes samlet i klyngen.
  4. Mens du behandler dataene, bør maskinvarebruk være minst mulig.
  5. Kjørbare programmer og skript i henhold til kravet i applikasjonen.

Roller og ansvar for Hadoop-testing

Som Hadoop-tester er vi ansvarlige for å forstå kravene, utarbeide testestimeringer, planlegging av testkassene, få testdata for å teste noen testkaser, være involvert i oppretting av testseng, gjennomføre testplaner, rapportering og omprøving av mangler.

Vi må også være ansvarlige for daglig statusrapportering og fullføring av test.

Roller og ansvar for Hadoop-testing

Det første vi skal diskutere er Teststrategi . Når vi har en foreslått løsning på problemet vårt, må vi gå videre og planlegge eller strategisere testplanen vår, vi kan diskutere automatiseringsstrategien vi kan bruke der inne, planen om testplanen som avhenger av leveringsdato, også vi kan diskutere ressursplanlegging.

Automatiseringsstrategien vil hjelpe oss med å redusere den manuelle innsatsen som kreves for å teste produktet. Testplanen er viktig, da den vil sikre levering av produktet i tide.

Ressursplanlegging vil være avgjørende ettersom vi trenger å planlegge hvor mye arbeidstid vi trenger i testingen vår og hvor mye Hadoop-ressurser som kreves for å utføre testplanleggingen.

Når vi har strategisert testingen vår, må vi fortsette og lage testutviklingsplanene som inkluderer Opprette testplaner, Opprette testskripter som vil hjelpe oss med å automatisere testene våre og også identifisere noen testdata som skal brukes i testplanene. og hjelper oss å gjennomføre disse testplanene.

Når vi er ferdige med testutviklingen som inkluderer å lage testplaner, testskripter og testdata, begynner vi å utføre testplanene.

Når vi gjennomfører testplanene, kan det være visse scenarier der den faktiske produksjonen ikke er som forventet, og disse tingene kalles mangler. Når det er en feil, må vi også teste disse feilene, og vi må lage og vedlikeholde matriser for dem.

Alle disse tingene faller inn under neste kategori som er Feilbehandling .

Hva er feilbehandling?

Defekthåndtering består av feilsporing, feilretting og feilbekreftelse. Hver gang en testplan blir utført mot noen av produktene vi har, og så snart en bestemt feil blir identifisert eller en mangel er identifisert, må den mangelen rapporteres til utvikleren eller tildeles utvikleren.

Så utvikleren kan se på det og begynne å jobbe med det. Som en tester må vi spore fremdriften til feilen og spore hvis feilen er løst. Hvis feilen er løst som rapportert, må vi gå videre og teste den på nytt og kontrollere om den er løst.

Når alle feilene er løst, lukket og bekreftet, må vi fortsette og levere et OKAY-testet produkt. Men før vi leverer produktet, må vi sørge for at UAT (User Acceptance Testing) er fullført.

Vi sørger for at installasjonstesting og kravverifisering blir utført riktig, dvs. produktet som leveres til klienten eller en sluttbruker er i samsvar med kravet som er nevnt i programvarekravdokumentet.

Trinnene vi har diskutert er basert på fantasien, være noen av testscenariene eller noen av testmetodene vi skal bruke for disse trinnene eller si disse setningene for å teste produktet vårt og levere sluttresultatet, som er en OKAY Testet produkt.

La oss gå videre og diskutere dette i detalj og korrelere det med Hadoop Testing.

Vi vet at Hadoop er noe som brukes til batchbehandling, og vi vet også at ETL er et av feltene der Hadoop brukes mye. ETL står for Extraction Transformation and Loading . Vi vil diskutere disse prosessene i detalj når vi diskuterer testplanen og teststrategien som et Hadoop-testperspektiv.

I henhold til diagrammet nevnt nedenfor, antar vi bare at vi har fire forskjellige datakilder. Operasjonssystem, CRM ( Kundeansvarlig ) og ERP ( planlegging av bedriftens ressurser ) er RDBMS eller si Relational DataBase Management System som vi har, og vi har også noen haug med flate filer som kanskje logger, filer, poster eller hva som helst med hensyn til våre datakilder.

Vi bruker kanskje Sqoop eller Flume eller hvilket som helst bestemt produkt for å få dataene, postene eller hva som helst som mine datakilder. Vi kan bruke disse verktøyene til å hente dataene fra datakildene inn i iscenesettelseskatalogen min, som er den første fasen av prosessen vår Utdrag.

Når dataene i Staging Directory som faktisk er HDFS (Hadoop Distribution File System), vil vi spesielt bruke skriptspråket som PIG til Forvandle disse dataene. At Transformasjon vil være i samsvar med dataene vi har.

Når dataene er transformert tilsvarende ved hjelp av hvilken skriptteknologi vi har, vil vi være det Laster inn disse dataene inn i datalageret. Fra datavarehuset vil disse dataene brukes til OLAP-analyse, rapportering og datautvinning eller for Analytics.

La oss gå videre og diskutere hvilke alle faser vi kan bruke til Hadoop-testing.

Den første fasen vil være utvinningsfasen. Her skal vi hente dataene fra våre kildedatabaser eller fra flate filer, og i så fall kan vi bekrefte at alle dataene er kopiert vellykket og riktig fra kilde til Staging Directory.

Det kan inkludere, verifisere antall poster, typen poster og typen felt osv.

Når disse dataene er kopiert til Staging Directory, vil vi fortsette og utløse den andre fasen som er Transformation. Her vil vi ha litt forretningslogikk som vil virke på de kopierte dataene fra kildesystemene og faktisk vil opprette eller transformere dataene til den nødvendige forretningslogikken.

Transformasjon kan omfatte Sortering av data, Filtrering av data, Sammenkobling av data fra to forskjellige datakilder og visse andre operasjoner.

Når dataene er transformert, vil vi fortsette og ha testplaner klare, og vi vil sjekke om vi får utdataene som forventet, og all utdata som vi får oppfyller forventet resultat og datatyper, feltverdier og områdene osv. er noe som faller på plass.

Når det er riktig, kan vi fortsette og laste dataene inn i Data Warehouse.

I lastefasen sjekker vi faktisk om antall poster fra scenen og antall poster i Data Warehouse er synkronisert, de er kanskje ikke like, men de skal være synkroniserte. Vi ser også om typen data som er transformert er synkronisert.

Legg inn at vi vil bruke disse dataene til OLAP-analyse, rapportering og datautvinning som er det siste laget av produktet vårt, og i så fall kan vi ha påfølgende, eller vi kan si at testplanene er tilgjengelige for alle disse lagene.

Når vi får inn noen data fra kilden til destinasjonen, må vi alltid sørge for at bare autentiserte personer har autorisert tilgang til dataene.

Godkjenning

Godkjenning

Autorisasjon

Autorisasjon

Hva mener vi med begge disse begrepene?

For å forstå dette, la oss få tingene i perspektiv fra ETL-diagrammet.

ETL

I henhold til diagrammet ovenfor får vi dataene våre fra Source RDBMS Engines og fra Flat Files til HDFS, og den fasen kalles Extraction.

La oss diskutere autentisering på en bestemt måte, det er visse virksomheter som har data som er begrenset av sin art, denne typen data kalles PII-data i henhold til USAs standarder.

PII står for Personlig identifiserbar informasjon, All informasjon som fødselsdato, SSN, mobilnummer, e-postadresse og adresse til huset osv. faller under PII. Dette er begrenset og kan ikke deles med alle.

Dataene skal kun deles med personene som trengte det mest og de som trenger dataene for faktisk behandling. Å ha denne kontrollen og den første forsvarslinjen på plass kalles Authentication.

For eksempel, vi bruker en bærbar datamaskin og vi har Windows installert der, vi kan ha opprettet en brukerkonto på Windows-operativsystemet vårt, og der bruker vi et passord.

På denne måten er det bare personen som har legitimasjonen for denne brukerkontoen som kan logge på systemet, og det er slik vi skal beskytte dataene våre mot tyveri eller unødvendig tilgang. Det andre laget er autorisasjon.

Eksempel, vi har to forskjellige brukerkontoer på Windows-operativsystemet vårt, en brukerkonto er vår og en annen kan være gjestebrukerkontoen. Administratoren (WE) har rett til å utføre alle slags operasjoner, for eksempel installasjon og avinstallering av programvaren, Opprettelse av ny fil og Sletting av eksisterende filer, etc.

Mens det derimot er gjestebrukerne kanskje ikke all denne typen tilgang. Gjesten har autentisering for å logge på systemet, men har ikke fullmakt til å slette eller opprette filene og installasjonen, samt avinstallering av programvaren i henholdsvis systemet.

Gjestebrukerkontoen har imidlertid rett til å lese filene som er opprettet og bruke programvaren som allerede er installert.

Dette er hvordan autentisering og autorisasjon blir testet, i dette tilfellet, uansett hvilken data som er tilgjengelig i HDFS eller hvilket som helst av filsystemene vi trenger for å kontrollere for godkjenning og autorisering av data.

Testing Approach For Hadoop Testing / BigData Testing

Testing Approach

Testing Approach er vanlig for alle typer testing, ikke bare fordi det er BigData eller Hadoop Testing når vi går til Normal Manual Testing eller Automation Testing eller Security Testing, Performance Testing også, slik at enhver form for Testing følger samme tilnærming.

Krav

Som en del av testtilnærmingen, må vi starte med Krav , Krav er en grunnleggende ting, i dag i Agile-prosessen kalte vi det som Stories and Epics. Epic er ikke noe annet enn et større krav, mens historiene er mindre krav.

Krav inneholder i utgangspunktet alle datamodellene, målene, kildene, samt hva slags transformasjoner vi trenger å bruke, hva slags verktøy vi må bruke? All denne typen detaljer vil være tilgjengelig på Kravene.

Dette er i utgangspunktet klientkrav eller kundekrav. Basert på dette kravet starter vi testprosessen.

Anslag

En annen del av en tilnærming er Anslag , Hvor lang tid vi trenger å ta for at hele aktiviteten skal utføres som en del av testing. Vi gjør testplanlegging, forbereder testscenarier, utarbeider testtilfeller og utfører det samme, i tillegg til at vi vil finne feil og rapportere dem og utarbeide testrapporter også.

Alle disse aktivitetene vil ta litt tid, så hvor mye tid vi trenger for å fullføre alle disse aktivitetene, og dette kalles i utgangspunktet en estimering. Vi må gi noen grove estimater til ledelsen.

Testplanlegging

Testplanlegging er ingenting annet enn beskrivelsen om prosesser, hva man skal teste, hva man ikke skal teste, hva er omfanget av testingen, hva er tidsplanene, hvor mange ressurser som kreves, Maskinvare- og programvarekrav og hva er tidslinjene samt testsykluser vil bli brukt, hva er testnivåene vi krevde osv.

I løpet av testplanleggingen vil de gjøre en viss ressurstildeling til prosjektet og hva er de forskjellige modellene vi har, hvor mange ressurser som kreves og hva slags ferdighetssett som kreves osv. Alle disse tingene og aspektene vil bli inkludert i testen Planleggingsfase.

Mesteparten av tiden vil ledere eller ledelsesnivå folk gjøre testplanleggingen.

Testscenarier og testsaker

Når vi er ferdige med testplanleggingen, må vi forberede oss Testscenarier og testsaker , spesielt for Big Data Testing, krever vi noen få dokumenter sammen med kravdokumentet. Sammen med dette kravdokumentet, hva trenger vi?

Vi trenger Kravdokument som inneholder kundens behov, sammen med dette trenger vi Inndata dokument dvs. Datamodeller. Datamodell i den forstand hva er DataBase Schemas, hva er tabellene og hva er forholdet alle disse dataene vil være tilgjengelige i datamodellene.

Vi har også Kartlegging av dokumenter , Kartleggingsdokumenter for F.eks. i Relational DataBases har vi noen tabeller, og etter å ha lastet inn dataene gjennom ETL i Data Warehouse i HDFS, hva er all kartlegging vi trenger å gjøre? dvs. kartlegging av datatype.

hvordan spiller du swf-filer

For eksempel, hvis vi har en kundetabell i HDFS, har vi i HDFS en CUSTOMER_TARGET-tabell eller den samme tabellen kan også være i HIVE.

Datakartlegging

I denne kundetabellen har vi visse kolonner, og i KUNDEMÅLTabellen har vi visse kolonner som vist i diagrammet. Vi dumpet dataene fra kundetabellen til KUNDEMÅLTabellen, dvs. kilde til mål.

Deretter må vi sjekke den nøyaktige kartleggingen som dataene som er til stede i kildetabellen, som er kundetabellens kolonne 1 og rad 1, og anser det som C1R1, og de samme dataene bør kartlegges i C1R1 i KUNDETILPASSETABELL. Dette kalles i utgangspunktet som Mapping.

Hvordan vil vi vite, hva er alle kartleggingene vi trenger for å bekrefte? Så disse kartleggingene vil være til stede i kartleggingsdokumentet. I kartleggingsdokumentet vil kunden gi alle typer kartlegginger.

Vi har også krevd en Design dokument , Designdokument som kreves for både utviklingsteamet og QA-teamet, fordi i designdokumentet vil kunden gi, hva slags kartreduserende jobber de skal implementere og hvilken type MapReduce-jobber som tar innspill og hvilken type MapReduce Jobber gir utganger.

På samme måte, hvis vi har HIVE eller PIG, hva er alle UDF-er kunden har laget, samt hva er all input de vil ta og hva slags produksjon de vil produsere, etc.

For å forberede testscenarier og testtilfeller må vi ha alle disse dokumentene for hånd:

  • Kravdokument
  • Datamodell
  • Kartleggingsdokument
  • Design dokument

Disse kan variere fra en organisasjon til en annen organisasjon, og det er ingen obligatorisk regel om at vi må ha alle disse dokumentene. Noen ganger har vi alle dokumenter, og noen ganger har vi bare to eller tre dokumenter, eller noen ganger må vi også stole på ett dokument, det er opp til prosjektets kompleksitet, firmaplaner og alt.

Omtaler om testscenarier og testsaker

Vi må foreta en gjennomgang av testscenarier og testtilfeller fordi vi på en eller annen måte eller i noen tilfeller glemmer eller savner noen testtilfeller fordi alle ikke kan tenke på alle mulige ting som kan gjøres med kravene, under slike forhold må vi ta hjelp fra tredjepartsverktøyene eller fra noen andre.

Så når vi forbereder noen dokumenter eller utfører noe, trenger vi noen til å se gjennom ting fra samme team, som utviklere, testere. De vil gi riktige forslag for å inkludere noe mer eller også foreslå oppdatering eller endring av testscenarier og testsaker.

De gir alle kommentarene, og basert på dette vil vi oppdatere testscenarier og testtilfeller og flere versjoner av dokumentet som vi trenger å frigjøre på tvers av teamet til dokumentet er fullstendig oppdatert i henhold til kravet.

Testutførelse

Når dokumentet er klart, vil vi få avloggingen fra øvre team for å starte utførelsesprosessen som i utgangspunktet kalles Test Case Execution.

Hvis vi ønsker å utføre testtilfellene våre under utførelsen, må vi sjekke at utvikleren må sende informasjonen. Hvis det er vanlig funksjonstesting eller annen testing eller automatiseringstest, trenger vi en Build. Men her fra Hadoop eller BigData Testing synspunkt vil utvikleren tilby MapReduce Jobs.

HDFS Files - uansett hvilke filer som kopieres i HDFS, er det nødvendig med informasjon om disse filene for å kontrollere privilegiene, HIVE-skript som ble opprettet av utviklerne for å verifisere dataene i HIVE-tabellen, og vi trenger også HIVE UDF-er som ble utviklet av utviklerne, PIG Skript og PIG UDF-er.

Dette er alle tingene vi trenger å få fra utviklere. Før vi går for henrettelsen, bør vi ha alle disse tingene.

For MapReduce Jobs vil de levere noen JAR-filer, og som en del av HDFS har de allerede lastet inn dataene i HDFS, og filene skal være klare og HIVE-skript for å validere dataene i HIVE-tabeller. Uansett UDF-er de har implementert, vil de være tilgjengelige i HIVE UDF-er. Vi krever det samme for PIG-skript og UDF-er også.

Feilrapportering og sporing

Når vi har utført testtilfellene, finner vi noen mangler, noen forventede og noen faktiske er ikke lik forventede resultater, så vi må liste opp det samme og gi dem til utviklingsteamet for løsning, og dette kalles i utgangspunktet Defektrapportering.

Anta at hvis vi finner noen defekter i MapReduce-jobben, vil vi rapportere det til utvikleren, og de vil igjen gjenskape MapReduce-jobben, og de gjør noen modifikasjoner på kodenivå, og igjen vil de gi den nyeste MapReduce-jobben, som vi trenger å teste .

Dette er en pågående prosess, når jobben er testet og bestått, må vi igjen teste den på nytt og rapportere den til utvikleren og deretter få den neste til testing. Slik oppnås feilrapportering og sporing.

Testrapporter

Når vi er ferdige med hele testprosessen og manglene er lukket, må vi lage testrapportene våre. Testrapporter er hva vi har gjort for å fullføre testprosessen så langt. All planlegging, prøveskriving og henrettelser, hvilken produksjon vi fikk osv. Alt er dokumentert sammen i form av testrapporter.

Vi må sende disse rapportene daglig eller ukentlig, eller i henhold til kundens behov. I dag bruker organisasjoner AGILE-modellen, så hver statusrapport må oppdateres under Daily Scrums.

Konklusjon

I denne opplæringen gikk vi gjennom:

  • Strategien eller planen for å teste BigData.
  • Nødvendig miljø for BigData-testing.
  • Validering og bekreftelse av BigData.
  • Verktøy som brukes til å teste BigData.

Vi lærte også om -

  • Hvordan teststrategi, testutvikling, testutførelser, feilhåndtering og levering fungerer i rollene og ansvaret som en del av Hadoop-testing.
  • Testing Approach for Hadoop / BigData Testing som inkluderer kravsamling, estimering, testplanlegging, oppretting av testscenarier og testtilfeller sammen med vurderingene.
  • Vi ble også kjent med testutførelse, feilrapportering og sporing og testrapportering.

Vi håper denne BigData Testing Tutorial var nyttig for deg!

=> Sjekk ALLE BigData-opplæringsprogrammer her.

Anbefalt lesing

^