Menu

Uitgebreide zelfstudie over Hadoop-tests | Gids voor het testen van big data

  • Hoofd
  • Andere
  • Uitgebreide zelfstudie over Hadoop-tests | Gids voor het testen van big data

comprehensive hadoop testing tutorial big data testing guide

Probeer Ons Instrument Voor Het Oplossen Van Problemen

In deze tutorial worden de basisprincipes, testtypen, plannen, vereiste omgeving, testproces, validatie en verificatie voor Hadoop- en BigData-testen uitgelegd:

In deze tutorial zullen we de basisintroductie van Hadoop en BigData Testing zien, zoals wanneer en waar het testen in beeld komt en wat we moeten testen als onderdeel van Hadoop Testing.

We zullen ook de volgende onderwerpen in detail bespreken:

  • Rollen en verantwoordelijkheden van Hadoop-tests
  • Testaanpak voor Hadoop / BigData-testen

​ Kijk hier om AZ van BigData-trainingshandleidingen hier te zien.

Inleiding tot BigData en Hadoop-tests

Wat je leert:

Gegevens opslaan en verwerken in Hadoop

Om deze processen op het Hadoop-systeem uit te voeren, hebben we de mankracht die is onderverdeeld in vier secties.

  • Hadoop-beheerders zijn verantwoordelijk voor het opzetten van de omgeving en hebben de beheerdersrechten voor toegang tot de Hadoop-systemen.
  • Hadoop-ontwikkelaars ontwikkelen van de programma's met betrekking tot het ophalen, opslaan en verwerken van de gegevens van verschillende locaties naar gecentraliseerde locaties.
  • Hadoop-testers voor het valideren en verifiëren van de gegevens voordat ze van verschillende locaties worden opgehaald en na het ophalen op de gecentraliseerde locatie, evenals validatie en verificatie tijdens het laden van de gegevens naar de clientomgeving.
  • Hadoop-analisten werken wanneer het laden van gegevens is voltooid en wanneer de gegevens het magazijn op de locatie van de klant bereiken. Ze gebruiken deze gegevens voor het genereren van rapporten en dashboards. De analisten voeren de data-analyse uit voor groei en bedrijfsontwikkeling.

We weten dat Hadoop geen enkel systeem is; het bevat meerdere systemen en machines. De gegevens worden opgesplitst en opgeslagen in meerdere machines en als we er weer toegang toe willen hebben, moeten we de gegevens combineren en in rapporten opnemen, enzovoort.

De ontwikkelaar is verantwoordelijk voor het schrijven van programma's in JAVA en Python om de gegevens te extraheren en op te slaan.

De andere taak van een ontwikkelaar is om de gegevens te verwerken. Er zijn twee lagen van Hadoop, een is voor het opslaan van bijvoorbeeld Hadoop HDFS en een ander voor verwerking, dat wil zeggen Hadoop MapReduce.

Opslaan betekent dat alle gegevens die we in de bron hebben, worden opgeslagen / ingevoegd in het systeem. Verwerking betekent dat we het moeten splitsen in meerdere machines en opnieuw moeten combineren en naar de klant moeten sturen.

Het opslaan en verwerken gebeurt dus door scripts te programmeren en de ontwikkelaar is verantwoordelijk voor het schrijven van de scripts.

Afgezien van programmeren, is de andere methode om de gegevens in Hadoop op te slaan en te verwerken het gebruik van databasetoepassingen zoals Hive, Impala, HBase, enz. Voor deze tools is geen programmeerkennis nodig.

BigData en Hadoop-testen

Zodra het opslaan en verwerken door de ontwikkelaar is gedaan, gaan de gegevens voor het genereren van rapporten. Voordien moeten we de verwerkte gegevens verifiëren op juistheid en controleren of de gegevens correct zijn geladen en correct worden verwerkt of niet.

Het programma en / of de scripts die door een ontwikkelaar zijn gemaakt, moeten dus worden geverifieerd door de Hadoop- of BigData-tester. De tester moet basisprogrammering kennen, zoals Mapper, Hive, Pig Scripts, enz. Om de scripts te verifiëren en de opdrachten uit te voeren.

Voordat ze gaan testen, moeten de testers dus weten wat alle programma's en scripts werken, hoe ze de code moeten schrijven en vervolgens nadenken over hoe ze deze kunnen testen. Testen kan handmatig worden gedaan of met behulp van automatiseringstools.

Hadoop heeft verschillende soorten tests, zoals unit-tests, regressietests, systeemtests en prestatietests, enz. Dit zijn dus de algemene testtypen die we gebruiken bij onze normale tests, evenals Hadoop- en BigData-tests.

We hebben dezelfde soort testterminologieën zoals teststrategie, testscenario's en testcases, enz. In Hadoop en BigData Testing. Alleen de omgeving is anders en er zijn verschillende soorten technieken die we gebruiken om het BigData- en Hadoop-systeem te testen, omdat we hier de gegevens moeten testen en niet de applicatie.

Hoe de BigData testen en wat er allemaal moet worden getest in BigData?

Voor het testen van BigData hebben we een aantal plannen en strategieën nodig.

We moeten dus rekening houden met de volgende punten:

  • Wat is de strategie of het testplan voor de BigData?
  • Welke testbenaderingen worden toegepast op BigData?
  • Wat is de omgeving vereist?
  • Hoe de BigData valideren en verifiëren?
  • Welke tools worden gebruikt bij BigData Testing?

Laten we proberen om de antwoorden op alle bovenstaande vragen te krijgen.

Wat is de strategie of het plan om BigData te testen?

BigData-testen betekent verificatie en validatie van gegevens tijdens het opslaan en verwerken in het datawarehouse.

Tijdens het testen van BigData moeten we het volume en de verscheidenheid aan gegevens testen die uit verschillende databases zijn geëxtraheerd en die zijn geladen en verwerkt op Data Warehouse of Hadoop System. Deze tests vallen onder functionele tests.

We moeten de snelheid testen van de gegevens die zijn gedownload uit verschillende databases en geüpload naar het Hadoop-systeem, dat een onderdeel is van prestatietests.

Dus als plan of strategie moeten we ons concentreren op zowel functionele als prestatietests van BigData-tests.

Bij BigData Testing moet de tester de verwerking van een enorme hoeveelheid gegevens verifiëren met behulp van Commodity Hardware en bijbehorende componenten. Daarom speelt de kwaliteit van data ook een belangrijke rol bij het testen van BigData. Het is essentieel om de kwaliteit van gegevens te verifiëren en valideren.

Typen testen voor BigData-tests

In het vorige gedeelte hebben we gezien dat Functional Testing en Performance Testing een cruciale rol spelen bij BigData Testing, behalve dat we als BigData Tester nog een paar soorten testen moeten doen, zoals Database Testing en Architectural Testing.

Deze testtypen zijn ook net zo belangrijk als functionele en prestatietests.

# 1) Bouwkundige testen

Dit testen wordt gedaan om er zeker van te zijn dat de gegevensverwerking correct is en voldoet aan de eisen. In feite verwerkt het Hadoop-systeem enorme hoeveelheden gegevens en bevat het zeer veel middelen.

Als de architectuur onjuist is, kan dit de prestaties verminderen, waardoor de verwerking van gegevens kan worden onderbroken en gegevens verloren kunnen gaan.

# 2) Database testen

Hier komt de procesvalidatie in beeld en moeten we de gegevens uit verschillende databases valideren, d.w.z. we moeten ervoor zorgen dat de gegevens die uit de brondatabases of lokale databases worden opgehaald, correct en correct moeten zijn.

We moeten ook controleren of de gegevens die beschikbaar zijn in de brondatabases overeenkomen met de gegevens die zijn ingevoerd in het Hadoop-systeem.

DataBase testen

Evenzo moeten we valideren of de gegevens in het Hadoop-systeem correct en correct zijn na verwerking of zeg maar na transformatie, en met de juiste validatie en verificatie in de omgeving van de klant worden geladen.

Als onderdeel van databasetests moeten we het WREED operaties d.w.z. Creëer de gegevens in lokale databases dan Ophalen de gegevens en we moeten deze doorzoeken en het moet beschikbaar zijn in de database voor en na het laden in het datawarehouse en van het datawarehouse naar de omgeving van de klant.

Verificatie van elk Bijgewerkt Gegevens over elke fase van het opslaan of laden en verwerken van de gegevens. Verwijderen van beschadigde gegevens of dubbele en nulgegevens.

# 3) Prestatietests

Als onderdeel van prestatietests moeten we de laad- en verwerkingssnelheid van gegevens controleren, bijvoorbeeld zoals de IOPS (Input Output Per Second).

Noodzaak om de snelheid te controleren van het invoeren van de gegevens of gegevens als invoer van verschillende databases naar het datawarehouse of Hadoop-systeem en van het Hadoop-systeem of datawarehouse naar de omgeving van de klant.

Moet ook de snelheid controleren van de gegevens afkomstig uit verschillende databases en uit het datawarehouse als output. Dit noemen we Input Output Per Second of IOPS.

Afgezien daarvan is een ander aspect het controleren van de prestaties van de gegevensabsorptie en gegevensdistributie, en hoe snel de gegevens worden verbruikt door het datawarehouse uit verschillende databases en door het systeem van de klant uit het Hadoop-systeem.

Ook als tester moeten we de prestaties van de datadistributie controleren, zoals hoe snel de gegevens worden gedistribueerd naar verschillende bestanden die beschikbaar zijn in het Hadoop-systeem of in het datawarehouse. Op dezelfde manier vindt hetzelfde proces plaats tijdens het distribueren van gegevens naar clientsystemen.

Het Hadoop-systeem of het datawarehouse bestaat uit meerdere componenten, dus een tester moet de prestaties van al die componenten controleren, zoals de MapReduce-taken, gegevensinvoer en -consumptie, de responstijd van zoekopdrachten en hun prestaties, evenals de prestaties van de zoekopdracht operaties. Deze zijn allemaal opgenomen in Performance Testing.

# 4) Functioneel testen

Functioneel testen omvat het testen van alle subcomponenten, programma's en scripts, tools die worden gebruikt voor het uitvoeren van de bewerkingen van opslaan of laden en verwerken, enz.

Voor een tester zijn dit de vier belangrijke typen en fasen waarin de gegevens moeten worden gefilterd, zodat de klant de perfecte en foutloze gegevens krijgt.

Tools voor BigData Hadoop-tests

Er zijn verschillende tools die worden gebruikt om BigData te testen:

  • HDFS Hadoop Distribution File System voor het opslaan van BigData.
  • HDFS Map Reduce voor het verwerken van BigData.
  • Voor NoSQL of HQL Cassandra DB, ZooKeeper en HBase, etc.
  • Cloudgebaseerde servertools zoals EC2.

Omgevingen en instellingen testen

Voor elk type test heeft de tester de juiste instellingen en de omgeving nodig.

Hieronder vindt u de lijst met vereisten:

  1. Type gegevens en applicatie dat wordt getest.
  2. Voor het opslaan en verwerken is veel ruimte nodig voor een enorme hoeveelheid gegevens.
  3. Correcte distributie van bestanden op alle DataNodes in het hele cluster.
  4. Bij het verwerken van de gegevens moet het hardwaregebruik minimaal zijn.
  5. Uitvoerbare programma's en scripts volgens de vereisten van de applicatie.

Rollen en verantwoordelijkheden van Hadoop-tests

Als Hadoop-tester zijn we verantwoordelijk voor het begrijpen van de vereisten, het opstellen van de testschattingen, het plannen van de testcases, het verkrijgen van testgegevens om enkele testcases te testen, betrokken zijn bij het maken van testbedden, het uitvoeren van de testplannen, het rapporteren en opnieuw testen van defecten.

We moeten ook verantwoordelijk zijn voor de dagelijkse statusrapportage en het voltooien van tests.

Rollen en verantwoordelijkheden van Hadoop-tests

Het eerste dat we gaan bespreken is de Teststrategie ​Zodra we een voorgestelde oplossing voor ons probleem hebben, moeten we doorgaan en ons testplan plannen of strategisch bedenken, we kunnen de automatiseringsstrategie bespreken die we daarin kunnen gebruiken, het plan over het testschema dat afhangt van onze leverdata, ook wij kan de resourceplanning bespreken.

De automatiseringsstrategie is iets dat ons zal helpen bij het verminderen van de handmatige inspanningen die nodig zijn om het product te testen. Het testschema is belangrijk omdat het de tijdige levering van het product garandeert.

Resourceplanning zal cruciaal zijn omdat we moeten plannen hoeveel manuren we nodig hebben voor onze tests en hoeveel Hadoop-resources nodig zijn om onze testplanning uit te voeren.

Zodra we onze tests strategiseren, moeten we doorgaan en de testontwikkelingsplannen maken, waaronder het maken van testplannen en het maken van testscripts die ons zullen helpen onze tests te automatiseren en ook enkele testgegevens te identificeren die in de testplannen zullen worden gebruikt. en helpt ons om die testplannen uit te voeren.

Zodra we klaar zijn met de testontwikkeling die het maken van testplannen, testscripts en testgegevens omvat, gaan we door en beginnen we met het uitvoeren van die testplannen.

Wanneer we de testplannen uitvoeren, kunnen er bepaalde scenario's zijn waarin de werkelijke output niet is zoals verwacht, en die dingen worden defecten genoemd. Elke keer dat er een defect is, moeten we die defecten ook testen en daarvoor moeten we de matrices maken en onderhouden.

Al deze dingen vallen onder de volgende categorie, namelijk Beheer van defecten ​

Wat is defectbeheer?

Defectbeheer bestaat uit het volgen van fouten, het verhelpen van fouten en het verifiëren van fouten. Telkens wanneer een testplan wordt uitgevoerd tegen een van de producten die we hebben en zodra een bepaalde bug wordt geïdentificeerd of een defect wordt geïdentificeerd, moet dat defect worden gerapporteerd aan de ontwikkelaar of toegewezen aan de ontwikkelaar.

Zodat de ontwikkelaar ernaar kan kijken en eraan kan werken. Als tester moeten we de voortgang van de bug volgen en bijhouden of de bug is verholpen. Als de bug is opgelost zoals gerapporteerd, dan moeten we doorgaan en hem opnieuw testen en controleren of hij is opgelost.

Zodra alle bugs zijn opgelost, gesloten en geverifieerd, moeten we doorgaan en een OKAY getest product leveren. Maar voordat we het product leveren, moeten we ervoor zorgen dat de UAT (User Acceptance Testing) met succes is voltooid.

We zorgen ervoor dat de installatietests en de verificatie van de vereisten correct worden uitgevoerd, d.w.z. dat het product dat aan de klant of een eindgebruiker wordt geleverd, voldoet aan de vereiste die wordt vermeld in het document met softwarevereisten.

De stappen die we hebben besproken, zijn gebaseerd op de verbeelding, dit zijn een van de testscenario's of een van de testbenaderingen die we voor die stappen gaan gebruiken of die zinnen zeggen om ons product te testen en het eindresultaat te leveren, wat een OKAY Getest product.

Laten we dit in detail bespreken en het in verband brengen met de Hadoop-tests.

We weten dat Hadoop iets is dat wordt gebruikt voor batchverwerking en we weten ook dat ETL een van de velden is waar Hadoop veel wordt gebruikt. ETL staat voor Extraction Transformation and Loading ​We zullen deze processen in detail bespreken wanneer we het testplan en de teststrategie bespreken als een Hadoop-teststandpunt.

Volgens het onderstaande diagram gaan we ervan uit dat we vier verschillende gegevensbronnen hebben. Operationeel systeem, CRM ( Beheer van klantrelaties ) en ERP ( Enterprise Resource Planning ) is het RDBMS of zeg maar het relationele databasemanagementsysteem dat we hebben en we hebben ook een aantal platte bestanden die misschien logs, bestanden, records of wat dan ook met betrekking tot onze gegevensbronnen.

We kunnen Sqoop of Flume of een ander product gebruiken om de gegevens, records of wat dan ook als mijn gegevensbronnen te krijgen. We kunnen deze tools gebruiken om de gegevens van de gegevensbronnen in mijn staging-directory te krijgen, de eerste fase van ons proces genaamd Extractie.

Zodra de gegevens daarin de Staging Directory zijn die eigenlijk HDFS (Hadoop Distribution File System) is, zullen we met name de scripttaal zoals PIG gebruiken om Transformeren die gegevens. Dat Transformatie zal zijn in overeenstemming met de gegevens die we hebben.

Zodra de gegevens dienovereenkomstig zijn getransformeerd met behulp van de scripttechnologie die we hebben, zullen we dat zijn Bezig met laden die gegevens in het datawarehouse. Vanuit het datawarehouse worden die gegevens gebruikt voor OLAP-analyse, rapportage en datamining of voor analyse.

Laten we doorgaan en bespreken welke alle fasen we kunnen gebruiken voor Hadoop-tests.

De eerste fase is de extractiefase. Hier gaan we de gegevens halen uit onze brondatabases of uit platte bestanden, en in dat geval kunnen we controleren of alle gegevens met succes en correct van de bron naar de staging-directory zijn gekopieerd.

Het kan gaan om het verifiëren van het aantal records, het type records en het type velden, enz.

Zodra deze gegevens naar de Staging Directory zijn gekopieerd, gaan we door en starten we de tweede fase, namelijk Transformatie. Hier zullen we enige bedrijfslogica hebben die zal werken op de gekopieerde gegevens van de bronsystemen en de gegevens daadwerkelijk zullen creëren of transformeren in de vereiste bedrijfslogica.

Transformatie kan het sorteren van de gegevens, het filteren van de gegevens, het samenvoegen van de gegevens uit twee verschillende gegevensbronnen en bepaalde andere bewerkingen omvatten.

Zodra de gegevens zijn getransformeerd, zullen we doorgaan en testplannen gereed hebben en zullen we controleren of we de uitvoer krijgen zoals verwacht, en alle uitvoer die we krijgen, voldoet aan het verwachte resultaat en de gegevenstypen, veldwaarden en de bereiken, enz. zijn iets dat op zijn plaats valt.

Zodra het correct is, kunnen we doorgaan en de gegevens in Data Warehouse laden.

In de laadfase controleren we eigenlijk of het aantal records uit de Stage en het aantal records in Data Warehouse gesynchroniseerd zijn, ze zijn misschien niet vergelijkbaar, maar ze zouden synchroon moeten zijn. We zien ook of het type gegevens dat is getransformeerd, gesynchroniseerd is.

Post dat we deze gegevens zullen gebruiken voor OLAP-analyse, rapportage en datamining, wat de laatste laag van ons product is en in dat geval kunnen we de volgende of we kunnen zeggen dat de testplannen beschikbaar zijn voor al deze lagen.

Telkens wanneer we bepaalde gegevens van de bron naar de bestemming krijgen, moeten we er altijd voor zorgen dat alleen geauthenticeerde personen geautoriseerde toegang tot de gegevens hebben.

Authenticatie

Authenticatie

Autorisatie

Autorisatie

Wat bedoelen we met beide termen?

Laten we, om dit te begrijpen, de dingen in perspectief bekijken vanuit het ETL-diagram.

ETL

Volgens het bovenstaande diagram halen we onze gegevens van Source RDBMS Engines en van platte bestanden naar HDFS, en die fase wordt Extractie genoemd.

Laten we authenticatie op een bepaalde manier bespreken. Er zijn bepaalde bedrijven die gegevens hebben die door hun aard beperkt zijn, dit type gegevens wordt PII-gegevens genoemd volgens de Amerikaanse normen.

PII betekent Persoonlijk identificeerbare informatie, alle informatie zoals de geboortedatum, SSN, mobiel nummer, e-mailadres en adres van het huis, enz. vallen allemaal onder PII. Dit is beperkt en kan niet met iedereen worden gedeeld.

De gegevens mogen alleen worden gedeeld met de personen die deze het meest nodig hebben en degenen die de gegevens nodig hebben voor daadwerkelijke verwerking. Het hebben van deze controle en de eerste verdedigingslinie wordt authenticatie genoemd.

Bijvoorbeeld, we gebruiken een laptop en we hebben Windows daar geïnstalleerd, we hebben mogelijk een gebruikersaccount aangemaakt op ons Windows-besturingssysteem en daar pasten we een wachtwoord toe.

Op deze manier kan alleen de persoon die de inloggegevens voor dit specifieke gebruikersaccount heeft, inloggen op het systeem en zo gaan we onze gegevens beschermen tegen diefstal of onnodige toegang. De andere laag is Autorisatie.

Voorbeeld, we hebben twee verschillende gebruikersaccounts op ons Windows-besturingssysteem, één gebruikersaccount is van ons en een ander kan het gastgebruikersaccount zijn. De beheerder (WE) heeft het recht om allerlei bewerkingen uit te voeren, zoals het installeren en verwijderen van de software, het maken van een nieuw bestand en het verwijderen van bestaande bestanden, enz.

Aan de andere kant hebben de gastgebruikers mogelijk niet al dit soort toegang. De gast heeft authenticatie om in te loggen op het systeem, maar heeft niet de bevoegdheid om de bestanden te verwijderen of aan te maken en om de software in het systeem respectievelijk van het systeem te verwijderen of te verwijderen.

Het gastgebruikersaccount heeft echter, omdat het is geverifieerd, het recht om de bestanden die zijn gemaakt te lezen en de software te gebruiken die al is geïnstalleerd.

Dit is hoe de authenticatie en autorisatie worden getest, in dit geval, alle gegevens die beschikbaar zijn in HDFS of een van de bestandssystemen die we moeten controleren op de authenticatie en autorisatie van gegevens.

Testaanpak voor Hadoop-tests / BigData-tests

Testbenadering

Testaanpak is gebruikelijk voor alle soorten tests, niet alleen omdat het BigData- of Hadoop-tests zijn wanneer we naar de normale handmatige tests of automatiseringstests of beveiligingstests gaan, ook prestatietests, dus elke vorm van testen volgt dezelfde aanpak.

Voorwaarden

Als onderdeel van de testaanpak moeten we beginnen met de Voorwaarden Vereiste is een basiszaak, tegenwoordig noemden we het in het Agile-proces als Verhalen en Epics. Epic is niets anders dan een grotere vereiste, terwijl de verhalen kleinere vereisten zijn.

Vereiste bevat in feite wat alle datamodellen, doelen, bronnen zijn en wat voor soort transformaties we moeten toepassen, wat voor soort tools we moeten gebruiken? Al dit soort details zullen beschikbaar zijn op de vereisten.

Dit is in feite de klantvereiste of klantvereisten. Op basis van deze vereiste zullen we ons testproces starten.

Schatting

Een ander onderdeel van een aanpak is Schatting Hoeveel tijd we nodig hebben om de hele activiteit uit te voeren als onderdeel van het testen. We doen testplanning, het voorbereiden van de testscenario's, het voorbereiden van testcases en de uitvoering daarvan, en we zullen defecten vinden en deze rapporteren en ook testrapporten opstellen.

Al deze activiteiten zullen enige tijd kosten, dus hoeveel tijd hebben we nodig voor het voltooien van al deze activiteiten en dit wordt in feite een schatting genoemd. We moeten het management een ruwe schatting geven.

Testplanning

Testplanning is niets anders dan de beschrijving van processen, wat te testen, wat niet te testen, wat is de scope van het testen, wat zijn de schema's, hoeveel middelen zijn er nodig, hardware- en softwarevereisten en wat zijn de tijdlijnen en testcycli zullen worden gebruikt, wat zijn de testniveaus die we nodig hebben, enz.

Tijdens de testplanning zullen ze bepaalde middelen toewijzen aan het project en wat zijn de verschillende modellen die we hebben, hoeveel middelen er nodig zijn en wat voor soort vaardigheden zijn vereist, enz. Al deze dingen en aspecten zullen in de test worden opgenomen. Planningsfase.

Meestal zullen de mensen op leadniveau of managementniveau de testplanning uitvoeren.

Testscenario's en testcases

Als we klaar zijn met de testplanning, moeten we ons voorbereiden Testscenario's en testcases , vooral voor Big Data Testing, hebben we naast het vereiste document ook enkele documenten nodig. Wat hebben we naast dit vereiste document allemaal nodig?

We hebben de Vereiste document dat de behoeften van de klant bevat, daarnaast hebben we de Invoerdocument d.w.z. Gegevensmodellen. Datamodel in de zin wat de databaseschema's zijn, wat de tabellen zijn en wat de relaties zijn, al deze data zullen beschikbaar zijn in de datamodellen.

We hebben ook de Documenten in kaart brengen , Mapping Documents for Bijv. in relationele databanken hebben we enkele tabellen en wat moeten we allemaal doen na het laden van de gegevens via ETL in datawarehouse in HDFS? d.w.z. Mapping Data Type.

wat is mijn router login en wachtwoord

Bijvoorbeeld, als we een klantentabel hebben in HDFS, dan hebben we in HDFS een CUSTOMER_TARGET-tabel of kan dezelfde tabel ook in HIVE staan.

Gegevens in kaart brengen

In deze Klantentabel hebben we bepaalde kolommen en in de CUSTOMER TARGET-tabel hebben we bepaalde kolommen zoals weergegeven in het diagram. We hebben de gegevens van de klantentabel naar de klantendoel-tabel gedumpt, d.w.z. bron naar doel.

Vervolgens moeten we de exacte toewijzing controleren, zoals de gegevens die aanwezig zijn in de brontabel, die kolom 1 en rij 1 van de klantentabel zijn en deze als C1R1 beschouwen en dezelfde gegevens moeten worden toegewezen in C1R1 van de tabel CUSTOMER TARGET. Dit wordt in feite Mapping genoemd.

Hoe zullen we weten wat alle toewijzingen zijn die we moeten verifiëren? Dus deze Mappings zullen aanwezig zijn in het Mapping Document. In het Mapping Document geeft de Klant allerlei Mappings.

We hebben ook een Ontwerpdocument , Ontwerpdocument vereist voor zowel het ontwikkelteam als het QA-team, omdat de klant in het ontwerpdocument zal aangeven wat voor soort Map Reduce-taken ze gaan implementeren en welk type MapReduce-taken invoer nodig heeft en welk type MapReduce Jobs geeft output.

Evenzo, als we HIVE of PIG hebben, wat zijn alle UDF's die de klant heeft gemaakt en wat zijn alle input die ze zullen gebruiken en wat voor soort output ze zullen produceren, enz.

Om testscenario's en testcases voor te bereiden, hebben we al deze documenten handmatig nodig:

  • Vereiste document
  • Gegevensmodel
  • Toewijzingsdocument
  • Ontwerpdocument

Deze kunnen van organisatie tot organisatie verschillen, en er is geen verplichte regel dat we al deze documenten moeten hebben. Soms hebben we alle documenten en soms hebben we slechts twee of drie documenten of soms moeten we ook op één document vertrouwen, namelijk de complexiteit van het project, bedrijfsschema's en alles.

Recensies over testscenario's en testcases

We moeten testscenario's en testcases beoordelen omdat we op de een of andere manier of in sommige gevallen enkele testcases vergeten of missen omdat iedereen niet alle mogelijke dingen kan bedenken die kunnen worden gedaan met de vereisten, in dergelijke omstandigheden moeten we hulp van tools van derden of van iemand anders.

Dus telkens als we documenten voorbereiden of iets uitvoeren, hebben we iemand nodig die de dingen van hetzelfde team beoordeelt, zoals ontwikkelaars, testers. Ze zullen de juiste suggesties doen om iets meer op te nemen of ook voorstellen om de testscenario's en testcases bij te werken of te wijzigen.

Ze bieden alle opmerkingen en op basis hiervan zullen we onze testscenario's en testcases bijwerken en meerdere versies van het document die we binnen het team moeten vrijgeven totdat het document volledig is bijgewerkt volgens de vereisten.

Testuitvoering

Zodra het document klaar is, krijgen we de handtekening van het bovenste team om het uitvoeringsproces te starten dat in feite Test Case Execution wordt genoemd.

Als we onze testcases tijdens de uitvoering willen uitvoeren, moeten we controleren of de ontwikkelaar de informatie moet verzenden, als het normaal functioneel testen is of een andere test of automatiseringstest, hebben we een build nodig. Maar hier vanuit het oogpunt van Hadoop of BigData Testing, zal de ontwikkelaar MapReduce Jobs leveren.

HDFS-bestanden - welke bestanden ook die in HDFS worden gekopieerd, die bestandsinformatie is vereist om de rechten te controleren, HIVE-scripts die zijn gemaakt door de ontwikkelaars om de gegevens in de HIVE-tabel te verifiëren en we hebben ook de HIVE UDF's nodig die zijn ontwikkeld door de ontwikkelaars, PIG Scripts en PIG UDF's.

Dit zijn alle dingen die we van ontwikkelaars moeten krijgen. Voordat we voor de executie gaan, zouden we al deze dingen moeten hebben.

Voor MapReduce-taken zullen ze enkele JAR-bestanden leveren en als onderdeel van de HDFS hebben ze de gegevens al in HDFS geladen en moeten de bestanden gereed zijn en HIVE-scripts om de gegevens in HIVE-tabellen te valideren. Wat de UDF's die ze ook hebben geïmplementeerd, zullen beschikbaar zijn in de HIVE UDF's. We hebben hetzelfde nodig voor PIG-scripts en UDF's.

Defectrapportage en tracking

Zodra we onze testcases hebben uitgevoerd, vinden we enkele defecten, waarvan sommige worden verwacht en sommige feitelijk niet gelijk zijn aan de verwachte resultaten, dus we moeten dezelfde opsommen en ze ter oplossing aan het ontwikkelingsteam verstrekken, en dit wordt in feite defectrapportage genoemd.

Stel dat als we een defect in de MapReduce-taak vinden, we dit aan de ontwikkelaar zullen rapporteren en zij de MapReduce-taak opnieuw zullen maken en ze zullen wat aanpassingen op codeniveau uitvoeren en dan weer zullen ze de nieuwste MapReduce-taak leveren, die we moeten testen .

Dit is een doorlopend proces, zodra de taak is getest en geslaagd, moeten we deze opnieuw testen en rapporteren aan de ontwikkelaar en vervolgens de volgende laten testen. Dit is hoe de activiteit Rapportage en tracering van defecten wordt bereikt.

Test rapporten

Zodra we het hele testproces hebben voltooid en de defecten zijn verholpen, moeten we onze testrapporten maken. Testrapporten is alles wat we tot nu toe hebben gedaan om het testproces te voltooien. Alle planning, testcases schrijven en uitvoeren, welke output we hebben, etc. alles wordt samen gedocumenteerd in de vorm van testrapporten.

We moeten deze rapporten dagelijks of wekelijks verzenden of volgens de behoeften van de klant. Tegenwoordig gebruiken organisaties het AGILE-model, dus elk statusrapport moet tijdens de dagelijkse scrums worden bijgewerkt.

Gevolgtrekking

In deze tutorial hebben we het volgende doorlopen:

  • De strategie of het plan voor het testen van de BigData.
  • Vereiste omgeving voor BigData-testen.
  • BigData-validatie en -verificaties.
  • Tools die worden gebruikt bij het testen van de BigData.

We leerden ook over -

  • Hoe de teststrategie, testontwikkeling, testuitvoering, defectbeheer en levering werken in de rollen en verantwoordelijkheden als onderdeel van Hadoop-tests.
  • Testaanpak voor Hadoop / BigData-testen, waaronder het verzamelen van vereisten, schatting, testplanning, het maken van testscenario's en testcases samen met de beoordelingen.
  • We maakten ook kennis met Test Execution, Defect Reporting & Tracking en Test Reporting.

We hopen dat deze BigData Testing-zelfstudie nuttig voor je was!

​ Bekijk hier ALLE BigData-tutorials.

Aanbevolen literatuur

^