Menu

Omfattende Hadoop-testvejledning | Guide til test af big data

  • Vigtigste
  • Andet
  • Omfattende Hadoop-testvejledning | Guide til test af big data

comprehensive hadoop testing tutorial big data testing guide

Prøv Vores Instrument Til At Fjerne Problemer

Denne tutorial forklarer de grundlæggende, testtyper, planer, påkrævet miljø, testproces, validering og verifikation af Hadoop- og BigData-test:

I denne vejledning vil vi se den grundlæggende introduktion til Hadoop- og BigData-test, som hvornår og hvor testningen kommer ind i billedet, og hvad vi har brug for at teste som en del af Hadoop-testning.

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

  • Roller og ansvar ved Hadoop-testning
  • Testmetode til Hadoop / BigData-test

=> Tjek her for at se AZ af BigData-træningsvejledninger her.

Introduktion til BigData- og Hadoop-test

Hvad du vil lære:

Lagring og behandling af data i Hadoop

For at udføre disse processer på Hadoop-systemet har vi den arbejdskraft, der er kategoriseret i fire sektioner.

  • Hadoop-administratorer er ansvarlige for at oprette miljøet og har administratorrettighederne til at få adgang til Hadoop-systemerne.
  • Hadoop-udviklere udvikle programmerne vedrørende træk, lagring og behandling af data fra forskellige placeringer til centraliserede placeringer.
  • Hadoop-testere til validering og verificering af data inden træk fra forskellige placeringer og efter træk på den centraliserede placering samt validering og verifikation udføres under indlæsning af data til klientmiljøet.
  • Hadoop-analytikere fungerer når dataindlæsning er færdig, og når dataene når lageret på klientplaceringen. De bruger disse data til generering af rapporter og dashboards. Analytikerne udfører dataanalysen til vækst og forretningsudvikling.

Vi ved, at Hadoop ikke er et enkelt system; den indeholder flere systemer og maskiner. Dataene opdeles og lagres i flere maskiner, og hvis vi ønsker at få adgang til dem igen, er vi nødt til at kombinere og trække dataene ind i rapporter osv.

Udvikleren er ansvarlig for at skrive programmer i JAVA og Python for at udtrække dataene og gemme dem.

Det andet job hos en udvikler er at behandle dataene. Der er to lag Hadoop, det ene er til lagring, dvs. Hadoop HDFS, og et andet til behandling, dvs. Hadoop MapReduce.

Lagring betyder, at de data, vi har i kilden, bare bliver gemt / indsat i systemet. Behandling betyder, at vi har brug for at opdele det i flere maskiner og igen kombinere og sende det til klienten.

Lagring og behandling sker således ved programmering af scripts, og udvikleren er ansvarlig for at skrive scripts.

Bortset fra programmering bruger den anden metode til at gemme og behandle dataene i Hadoop databaseapplikationer som Hive, Impala, HBase osv. Disse værktøjer har ikke brug for nogen programmeringsviden.

BigData og Hadoop-test

Når lagring og behandling er udført af udvikleren, går dataene til generering af rapporter. Før det er vi nødt til at kontrollere de behandlede data for nøjagtighed og kontrollere, om dataene er nøjagtigt indlæst og behandlet korrekt eller ikke.

Så programmet og / eller scripts oprettet af en udvikler skal verificeres af Hadoop eller BigData Tester. Testeren har brug for at kende grundlæggende programmering som Mapper, Hive, Pig Scripts osv. For at kontrollere scripts og udføre kommandoer.

Så før testningen skal testerne vide, hvad alle programmer og scripts fungerer, hvordan man skriver koden og derefter tænker på, hvordan man tester dem. Test kan udføres enten manuelt eller ved hjælp af automatiseringsværktøjer.

Hadoop har forskellige slags test som enhedstest, regressionstest, systemtest og ydelsestest osv. Så det er de almindelige testtyper, som vi bruger i vores normale test såvel som Hadoop- og BigData-test.

Vi har den samme type testterminologier som teststrategi, testscenarier og testcases osv. I Hadoop og BigData Testing. Kun miljøet er anderledes, og der er forskellige slags teknikker, som vi bruger til at teste BigData og Hadoop-systemet, for her skal vi teste dataene og ikke applikationen.

Hvordan testes BigData, og hvad alle ting kræver test i BigData?

Til BigData-test er vi nødt til at have nogle planer og strategier.

Derfor skal vi overveje følgende punkter:

  • Hvad er strategien eller planen for testning af BigData?
  • Hvilken type testmetoder anvendes til BigData?
  • Hvad kræves miljøet?
  • Hvordan valideres og verificeres BigData?
  • Hvad er de værktøjer, der bruges i BigData Testing?

Lad os prøve at få svarene på alle ovenstående spørgsmål.

Hvad er strategien eller planen til test af BigData?

BigData-test betyder verifikation og validering af data under lagring og behandling i Data Warehouse.

Mens vi tester BigData, er vi nødt til at teste volumen og variation af data, der ekstraheres fra forskellige databaser og indlæses såvel som behandles på Data Warehouse eller Hadoop System, denne test kommer under funktionel test.

Vi er nødt til at teste hastigheden på de data, der downloades fra forskellige databaser og uploades til Hadoop-systemet, som er en del af Performance Testing.

Så som en plan eller strategi er vi nødt til at koncentrere os om funktionel såvel som Performance Testing af BigData Testing.

I BigData Testing skal testeren verificere behandlingen af ​​en enorm mængde data ved hjælp af Commodity Hardware og relative komponenter. Derfor spiller datakvaliteten også en vigtig rolle i afprøvningen af ​​BigData. Det er vigtigt at kontrollere og validere datakvaliteten.

Testtyper til BigData-test

I det foregående afsnit så vi, at funktionstest og præstationsafprøvning spiller en vigtig rolle i BigData-test, bortset fra det som en BigData-tester, er vi nødt til at foretage et par flere testtyper som databasetest såvel som arkitektonisk testning.

Disse testtyper er også lige så vigtige som funktionstest og test.

# 1) Arkitektonisk testning

Denne test udføres for at sikre, at behandlingen af ​​data er korrekt og opfylder kravene. Faktisk behandler Hadoop-systemet enorme datamængder og er meget ressourceomfattende.

Hvis arkitekturen er forkert, kan den forringe ydelsen, som behandlingen af ​​data kan afbryde, og tab af data kan forekomme.

# 2) Test af databaser

Her kommer procesvalidering ind i billedet, og vi skal validere dataene fra forskellige databaser, dvs. vi skal sikre, at de data, der hentes fra kildedatabaser eller lokale databaser, skal være korrekte og korrekte.

Vi skal også kontrollere, at de tilgængelige data i kildedatabaserne matcher de data, der er indtastet i Hadoop System.

DataBase-test

På samme måde er vi nødt til at validere, hvis dataene i Hadoop System er korrekte og korrekte efter behandling eller siger efter transformation og skal indlæses til klientens miljø med korrekt validering og verifikation.

Som en del af databasetestning er vi nødt til at gennemgå GRUSOM operationer dvs. skab dataene i lokale databaser derefter Hent dataene, og vi skal søge i dem, og de skal være tilgængelige i databasen før og efter indlæsning i datavarehus og fra datavarehus til klientens miljø.

Bekræftelse af evt Opdateret Data om hvert trin i lagring eller indlæsning og behandling af data. Sletning af beskadigede data eller duplikat og nul data.

# 3) Test af ydeevne

Som en del af Performance Testing er vi nødt til at kontrollere indlæsnings- og behandlingshastigheden på data, dvs. som IOPS (Input Output Per Second).

Brug for at kontrollere hastigheden for at indtaste data eller data som input fra forskellige databaser til Data Warehouse eller Hadoop System og fra Hadoop System eller Data Warehouse til Client's Environment.

Skal også kontrollere hastigheden på dataene, der kommer fra forskellige databaser og fra datalageret som output. Dette er hvad vi kalder som Input Output Per Second eller IOPS.

Bortset fra det er et andet aspekt at kontrollere ydeevnen for dataabsorption og datadistribution, og hvor hurtigt dataene forbruges af datalageret fra forskellige databaser og af klientens system fra Hadoop-systemet.

Også som en tester er vi nødt til at kontrollere ydelsen af ​​datadistributionen ligesom, hvor hurtigt dataene distribueres til forskellige filer, der er tilgængelige i Hadoop-systemet eller i datalageret. Tilsvarende sker den samme proces under distribution af data til klientsystemer.

Hadoop-systemet eller datavarehuset består af flere komponenter, så en tester skal kontrollere ydeevnen for alle disse komponenter som MapReduce Jobs, dataindsættelse og -forbrug, responstid for forespørgsler og deres ydeevne såvel som søgningens ydeevne operationer. Alle disse er inkluderet i Performance Testing.

# 4) Funktionstest

Funktionel testning indeholder test af alle underkomponenter, programmer og scripts, værktøjer, der bruges til at udføre operationerne ved lagring eller indlæsning og behandling osv.

For en tester er dette de fire vigtige typer og faser, hvorigennem dataene skal filtreres, så klienten får de perfekte og fejlfrie data.

Værktøjer til test af BigData Hadoop

Der er forskellige værktøjer, der bruges til at teste BigData:

  • HDFS Hadoop Distribution File System til lagring af BigData.
  • HDFS-kortreduktion til behandling af BigData.
  • Til NoSQL eller HQL Cassandra DB, ZooKeeper og HBase osv.
  • Cloudbaserede serverværktøjer som EC2.

Test af miljøer og indstillinger

Til enhver form for test har testeren brug for korrekte indstillinger og miljøet.

Nedenfor er listen over krav:

  1. Type data og applikation, der skal testes.
  2. Opbevaring og behandling kræver en stor plads til en enorm mængde data.
  3. Korrekt distribution af filer på alle DataNodes samlet i klyngen.
  4. Under behandling af dataene skal hardwareudnyttelsen være minimal.
  5. Kørbare programmer og scripts i henhold til kravene i applikationen.

Roller og ansvar ved Hadoop-testning

Som Hadoop-tester er vi ansvarlige for at forstå kravene, forberede testestimeringer, planlægning af testcases, få nogle testdata til at teste nogle testcases, være involveret i oprettelse af testbed, udførelse af testplaner, rapportering og gentest af defekter.

Vi skal også være ansvarlige for daglig statusrapportering og testafslutning.

Roller og ansvar ved Hadoop-testning

Den første ting, vi skal diskutere, er Teststrategi . Når vi har en foreslået løsning på vores problem, skal vi gå videre og planlægge eller strategisere vores testplan, vi kan diskutere den automatiseringsstrategi, som vi kan bruge derinde, planen om testplanen, der afhænger af vores leveringsdatoer, også vi kan diskutere ressourceplanlægning.

Automatiseringsstrategien er noget, der vil hjælpe os med at reducere den manuelle indsats, der kræves for at teste produktet. Testplanen er vigtig, da den vil sikre levering af produktet i rette tid.

Ressourceplanlægning vil være afgørende, da vi har brug for at planlægge, hvor meget man-timer vi har brug for i vores test, og hvor meget Hadoop-ressourcer der kræves for at udføre vores testplanlægning.

Når vi har strategiseret vores test, er vi nødt til at fortsætte med at oprette testudviklingsplaner, der inkluderer Oprettelse af testplaner, Oprettelse af testskripter, der hjælper os med at automatisere vores test og også identificerer nogle testdata, der skal bruges i testplanerne. og hjælper os med at gennemføre disse testplaner.

Når vi er færdige med testudviklingen, der inkluderer oprettelse af testplaner, testskripter og testdata, går vi videre og begynder at udføre disse testplaner.

Når vi udfører testplanerne, kan der være visse scenarier, hvor den faktiske produktion ikke er som forventet, og disse ting kaldes defekter. Når der er en fejl, er vi også nødt til at teste disse mangler, og vi er nødt til at oprette og vedligeholde matricerne til dem.

Alle disse ting falder ind under den næste kategori, som er Fejlhåndtering .

Hvad er defekthåndtering?

Fejlhåndtering består af fejlsporing, fejlrettelse og fejlbekræftelse. Hver gang en testplan udføres mod et af de produkter, vi har, og så snart en bestemt fejl identificeres, eller en defekt identificeres, skal denne mangel rapporteres til udvikleren eller tildeles udvikleren.

Så udvikleren kan se på det og begynde at arbejde på det. Som tester er vi nødt til at spore Bugens fremskridt og spore, hvis Bug er blevet rettet. Hvis fejlen er rettet som rapporteret, er vi nødt til at gå videre og teste det igen og kontrollere, om det er løst.

Når alle fejlene er rettet, lukket og verificeret, skal vi gå videre og levere et OKAY-testet produkt. Men inden vi leverer produktet, skal vi sikre os, at UAT (User Acceptance Testing) er gennemført med succes.

Vi sørger for, at installationstest og kravverifikation udføres korrekt, dvs. det produkt, der leveres til klienten eller en slutbruger, er i henhold til kravet, der er nævnt i softwarekravsdokumentet.

De trin, vi har diskuteret, er baseret på fantasien, være et hvilket som helst af testscenarierne eller en hvilken som helst af de testmetoder, som vi vil bruge til disse trin, eller sig disse sætninger for at teste vores produkt og levere slutresultatet, hvilket er en OKAY Testet produkt.

Lad os gå videre og diskutere dette detaljeret og korrelere det med Hadoop-testen.

Vi ved, at Hadoop er noget, der bruges til batchbehandling, og vi ved også, at ETL er et af de felter, hvor Hadoop bruges meget. ETL står for Extraction Transformation and Loading . Vi vil diskutere disse processer detaljeret, når vi diskuterer testplanen og teststrategien som et Hadoop-testperspektiv.

I henhold til nedenstående diagram antager vi bare, at vi har fire forskellige datakilder. Operativsystem, CRM ( Management af kundeforhold ) og ERP ( Enterprise Resource Planning ) er RDBMS, eller sig Relational DataBase Management System, som vi har, og vi har også nogle flade flade filer, som måske logfiler, filer, poster eller hvad angår vores datakilder.

Vi bruger muligvis Sqoop eller Flume eller et hvilket som helst bestemt produkt til at få data, optegnelser eller hvad som mine datakilder. Vi bruger muligvis disse værktøjer til at hente dataene fra datakilderne til min iscenesættelsesmappe, som er den første fase af vores proces kaldet Udvinding.

Når dataene deri Staging Directory, som faktisk tilfældigvis er HDFS (Hadoop Distribution File System), bruger vi især scriptingsproget som PIG til Transformer disse data. At Transformation vil være i overensstemmelse med de data, vi har.

Når dataene er transformeret i overensstemmelse hermed ved hjælp af den scriptingteknologi, vi har, vil vi være Indlæser disse data i datalageret. Fra datavarehuset vil disse data blive brugt til OLAP-analyse, rapportering og dataudvinding eller til Analytics.

Lad os gå videre og diskutere, hvilke alle faser vi kan bruge til Hadoop-test.

Den første fase vil være ekstraktionsfasen. Her skal vi hente dataene fra vores kildedatabaser eller fra flade filer, og i så fald kan vi kontrollere, at alle data er kopieret med succes og korrekt fra kilde til Staging Directory.

Det kan omfatte, verificering af antallet af poster, typen af ​​poster og typen af ​​felter osv.

Når disse data er kopieret til Staging Directory, fortsætter vi og udløser den anden fase, som er Transformation. Her vil vi have en vis forretningslogik, der virker på de kopierede data fra kildesystemerne og faktisk opretter eller omdanner dataene til den krævede forretningslogik.

Transformation kan omfatte sortering af data, filtrering af data, sammenføjning af data fra to forskellige datakilder og visse andre operationer.

Når dataene er transformeret, vil vi fortsætte og have testplaner klar, og vi vil kontrollere, om vi får output som forventet, og alt det output, vi får, lever op til det forventede resultat og datatyper, feltværdier og områderne osv. er noget, der falder på plads.

Når det er korrekt, kan vi fortsætte og indlæse dataene i Data Warehouse.

I indlæsningsfasen kontrollerer vi faktisk, om antallet af poster fra scenen og antallet af poster i Data Warehouse er synkroniseret, de er muligvis ikke ens, men de skal synkroniseres. Vi ser også, om den type data, der er blevet transformeret, er synkroniseret.

Indsend, at vi vil bruge disse data til OLAP-analyse, rapportering og datamining, som er det sidste lag af vores produkt, og i så fald kan vi have efterfølgende, eller vi kan sige, at testplanerne er tilgængelige for alle disse lag.

Når vi får nogle data fra kilden til destinationen, skal vi altid sørge for, at kun godkendte personer har autoriseret adgang til dataene.

Godkendelse

Godkendelse

Bemyndigelse

Bemyndigelse

Hvad mener vi med begge disse udtryk?

For at forstå dette, lad os få tingene i perspektiv fra ETL-diagrammet.

ETL

I henhold til ovenstående diagram får vi vores data fra RDBMS-kilder og fra flade filer til HDFS, og den fase kaldes ekstraktion.

Lad os diskutere godkendelse på en bestemt måde, der er visse virksomheder, der har data, der er begrænset af deres art, denne type data kaldes PII-data i henhold til de amerikanske standarder.

PII står for Personligt identificerbare oplysninger, alle oplysninger såsom fødselsdato, SSN, mobilnummer, e-mail-adresse og husadresse osv. falder alle ind under PII. Dette er begrænset og kan ikke deles med alle.

Dataene skal kun deles med de personer, der har mest brug for det, og dem, der har brug for dataene til faktisk behandling. At have denne kontrol og den første forsvarslinje på plads kaldes Authentication.

For eksempel, vi bruger en bærbar computer, og vi har Windows installeret der, vi har muligvis oprettet en brugerkonto på vores Windows-operativsystem, og der anvendte vi en adgangskode.

På denne måde kan kun den person, der har legitimationsoplysningerne til denne brugerkonto, logge ind på systemet, og det er sådan, vi skal beskytte vores data mod tyveri eller unødvendig adgang. Det andet lag er autorisation.

Eksempel, vi har to forskellige brugerkonti på vores Windows-operativsystem, en brugerkonto er vores, og en anden kan være gæstebrugerkontoen. Administratoren (WE) har ret til at udføre alle former for operationer, f.eks. Installation og afinstallation af softwaren, Oprettelse af ny fil og sletning af eksisterende filer osv.

På den anden side har gæstebrugerne muligvis ikke al denne form for adgang. Gæsten har godkendelse til at logge ind på systemet, men har ikke beføjelse til at slette eller oprette filerne og installationen samt afinstallation af softwaren i henholdsvis systemet og fra systemet.

Gæstebrugerkontoen har dog ret til at læse de filer, der oprettes, og bruge den allerede installerede software på grund af at den er godkendt.

Sådan testes godkendelse og godkendelse, i dette tilfælde, uanset hvilke data der er tilgængelige i HDFS eller et hvilket som helst af de filsystemer, som vi har brug for for at kontrollere for godkendelse og godkendelse af data.

Testmetode til Hadoop-test / BigData-test

Testmetode

Testmetode er almindelig for alle former for test, ikke kun fordi det er BigData- eller Hadoop-test, når vi går til Normal manuel test eller automatiseringstest eller sikkerhedstest, også Ydelsestest, således at enhver form for test følger den samme tilgang.

Krav

Som en del af testmetoden skal vi starte med Krav , Krav er en grundlæggende ting, i dag i Agile-processen kaldte vi det som Stories and Epics. Epic er intet andet end et større krav, mens historierne er mindre krav.

Krav indeholder grundlæggende, hvad er alle datamodeller, mål, kilder samt hvilken form for transformation vi skal anvende, hvilken slags værktøjer vi skal bruge? Alle disse slags detaljer vil være tilgængelige på kravene.

Dette er dybest set klientkravet eller kundekravene. Baseret på dette krav starter vi vores testproces.

Skøn

En anden del af en tilgang er Skøn , Hvor lang tid vi har brug for, for at hele aktiviteten skal udføres som en del af testningen. Vi laver testplanlægning, forbereder testscenarier, forbereder testtilfælde og udfører det samme, ligesom vi finder fejl og rapporterer dem og udarbejder også testrapporter.

Alle disse aktiviteter vil tage noget tid, så hvor meget tid vi har brug for til at gennemføre alle disse aktiviteter, og dette kaldes grundlæggende en estimering. Vi er nødt til at give ledelsen et groft skøn.

Testplanlægning

Testplanlægning er intet andet end beskrivelsen om processer, hvad man skal teste, hvad man ikke skal teste, hvad er omfanget af testen, hvad er tidsplanerne, hvor mange ressourcer der kræves, hardware- og softwarekrav, og hvad er tidslinjerne samt testcyklusser vil blive brugt, hvad er de testniveauer, vi har krævet osv.

Under testplanlægningen vil de foretage visse ressourceallokeringer til projektet, og hvad er de forskellige modeller, vi har, hvor mange ressourcer der kræves, og hvilken type færdighedssæt der kræves osv. Alle disse ting og aspekter vil blive inkluderet i testen Planlægningsfase.

Det meste af tiden vil lead-niveauet eller ledelsesniveauet udføre testplanlægningen.

Testscenarier og testsager

Når vi er færdige med testplanlægningen, skal vi forberede os Testscenarier og testsager , især til Big Data Testing, kræver vi et par dokumenter sammen med kravdokumentet. Sammen med dette kravsdokument, hvad har vi alt brug for?

Vi har brug for Kravsdokument der indeholder kundens behov, sammen med dette har vi brug for Indtastningsdokument dvs. Datamodeller. Datamodel i den forstand, hvad der er DataBase-skemaer, hvad er tabellerne, og hvad er forholdet, alle disse data vil være tilgængelige i datamodellerne.

Vi har også Kortlægning af dokumenter , Kortlægning af dokumenter til For eksempel. i Relational DataBases har vi nogle tabeller, og efter indlæsning af data gennem ETL i Data Warehouse i HDFS, hvad er alt kortlægning, vi skal gøre? dvs. kortlægning af datatype.

bedste enhedstestningsramme til java

For eksempel, hvis vi har en kundetabel i HDFS, så har vi i HDFS en CUSTOMER_TARGET-tabel, eller den samme tabel kan også være i HIVE.

Datakortlægning

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

Derefter skal vi kontrollere den nøjagtige kortlægning ligesom de data, der er til stede i kildetabellen, som er kundetabellens kolonne 1 og række 1, og betragter det som C1R1, og de samme data skal kortlægges i C1R1 i KUNDETALTabel. Dette kaldes grundlæggende som Mapping.

Hvordan ved vi, hvad er alle de kortlægninger, vi har brug for for at verificere? Så disse kortlægninger vil være til stede i kortlægningsdokumentet. I kortlægningsdokumentet vil kunden give alle slags kortlægninger.

Vi har også krævet en Design dokument , Designdokument, der kræves til både udviklingsteamet såvel som QA-teamet, fordi kunden i designdokumentet vil give, hvilken slags kortreducerende job de vil implementere, og hvilken type MapReduce-job, der tager input, og hvilken type MapReduce Job giver output.

Tilsvarende, hvis vi har HIVE eller PIG, hvad er alle UDF'er, som kunden har oprettet, samt hvad er alt det input, de vil tage, og hvilken slags output de producerer osv.

For at forberede testscenarier og testsager skal vi have alle disse dokumenter i hånden:

  • Kravsdokument
  • Datamodel
  • Kortlægning af dokument
  • Design dokument

Disse kan variere fra en organisation til en anden organisation, og der er ingen obligatorisk regel om, at vi skal have alle disse dokumenter. Nogle gange har vi alle dokumenter, og nogle gange har vi kun to eller tre dokumenter, eller nogle gange er vi også nødt til at stole på et dokument, det er op til projektets kompleksitet, virksomhedsplaner og alt.

Anmeldelser af testscenarier og testsager

Vi er nødt til at foretage en gennemgang af testscenarier og testsager, fordi vi på en eller anden måde eller i nogle tilfælde glemmer, eller vi savner nogle testsager, fordi alle ikke kan tænke på alle de mulige ting, der kan gøres med kravene, under sådanne forhold er vi nødt til at tage hjælp fra tredjepartsværktøjerne eller fra en anden.

Så når vi forbereder nogle dokumenter eller udfører noget, så har vi brug for nogen til at gennemgå tingene fra det samme hold, som udviklere, testere. De vil give de rette forslag til at inkludere noget mere eller også foreslå opdatering eller ændring af testscenarier og testtilfælde.

De leverer alle kommentarer og baseret på dette opdaterer vi vores testscenarier og testtilfælde og flere versioner af dokumentet, som vi har brug for at frigive på tværs af teamet, indtil dokumentet er fuldt opdateret i henhold til kravet.

Testudførelse

Når dokumentet er klar, får vi afmeldingen fra det øverste hold for at starte eksekveringsprocessen, der grundlæggende kaldes Test Case Execution.

Hvis vi ønsker at udføre vores testtilfælde under udførelse, skal vi kontrollere, at udvikleren skal sende oplysningerne, hvis det er normalt funktionstestning eller anden test eller automatiseringstestning, kræver vi en build. Men her set fra Hadoop- eller BigData-testperspektivet vil udvikleren levere MapReduce Jobs.

HDFS-filer - uanset hvilke filer der kopieres i HDFS, kræves disse filoplysninger for at kontrollere privilegierne, HIVE-scripts, der blev oprettet af udviklerne for at verificere dataene i HIVE-tabel, og vi har også brug for HIVE UDF'er, som blev udviklet af udviklerne, PIG Scripts og PIG UDF'er.

Dette er alle de ting, vi skal få fra udviklere. Før vi går til henrettelsen, skal vi have alle disse ting.

For MapReduce-job vil de levere nogle JAR-filer, og som en del af HDFS har de allerede indlæst dataene i HDFS, og filerne skal være klar og HIVE-scripts til validering af dataene i HIVE-tabeller. Uanset hvilke UDF'er de har implementeret, vil de være tilgængelige i HIVE UDF'er. Vi kræver det samme for PIG-scripts og UDF'er.

Fejlrapportering og sporing

Når vi først har udført vores testtilfælde, finder vi nogle mangler, nogle forventes og nogle faktiske er ikke lig med de forventede resultater, så vi skal liste det samme og give dem til udviklingsteamet til løsning, og dette kaldes grundlæggende Defektrapportering.

Antag, at hvis vi finder en defekt i MapReduce-jobbet, rapporterer vi det til udvikleren, og de vil igen genskabe MapReduce-jobbet, og de foretager nogle ændringer på kodeniveau, og så vil de igen give det nyeste MapReduce-job, som vi har brug for for at teste .

Dette er en løbende proces, når jobbet er testet og bestået, skal vi igen teste det igen og rapportere det til udvikleren og derefter få den næste til test. Dette er, hvordan fejlrapporterings- og sporingsaktiviteten udføres.

Testrapporter

Når vi er færdige med hele testprocessen, og manglerne er lukket, er vi nødt til at oprette vores testrapporter. Testrapporter er hvad vi har gjort for at gennemføre testprocessen hidtil. Al planlægning, skrivning af testsager og udførelser, hvilken output vi fik osv. Alt er dokumenteret sammen i form af testrapporter.

Vi er nødt til at sende disse rapporter dagligt eller ugentligt eller efter kundens behov. I dag bruger organisationer AGILE-modellen, så hver statusrapport skal opdateres under Daily Scrums.

Konklusion

I denne vejledning gik vi igennem:

  • Strategien eller planen for at teste BigData.
  • Påkrævet miljø til BigData-test.
  • BigData-validering og verifikationer.
  • Værktøjer, der bruges til at teste BigData.

Vi lærte også om -

  • Hvordan teststrategi, testudvikling, testudførelser, defektstyring og levering fungerer i roller og ansvar som en del af Hadoop-testning.
  • Testtilgang til Hadoop / BigData-test, som inkluderer kravindsamling, estimering, testplanlægning, oprettelse af testscenarier og testtilfælde sammen med anmeldelserne.
  • Vi lærte også om testudførelse, fejlrapportering og sporing og testrapportering.

Vi håber, at denne BigData-testvejledning var nyttig for dig!

=> Tjek ALLE BigData-selvstudier her.

Anbefalet læsning

^