Menú

Tutorial complet de proves Hadoop | Guia de proves de Big Data

  • Principal
  • Altres
  • Tutorial complet de proves Hadoop | Guia de proves de Big Data

comprehensive hadoop testing tutorial big data testing guide

Proveu El Nostre Instrument Per Eliminar Problemes

Aquest tutorial explica els conceptes bàsics, els tipus de proves, els plans, l’entorn necessari, el procés de proves, la validació i les verificacions de les proves Hadoop i BigData:

En aquest tutorial, veurem la introducció bàsica a la prova Hadoop i BigData, com quan i on apareixeran les proves i què hem de provar com a part de la prova Hadoop.

També parlarem detalladament dels temes següents:

  • Funcions i responsabilitats de les proves Hadoop
  • Enfocament de proves per a proves Hadoop / BigData

=> Consulteu aquí per veure A-Z de tutorials de formació BigData aquí.

Introducció a les proves BigData i Hadoop

Què aprendreu:

Emmagatzematge i processament de dades a Hadoop

Per realitzar aquests processos al sistema Hadoop, disposem de la mà d'obra que es classifica en quatre seccions.

  • Administradors d’Hadoop són responsables de configurar l’entorn i tenen els drets d’administració per accedir als sistemes Hadoop.
  • Desenvolupadors Hadoop desenvolupar els programes d’extracció, emmagatzematge i processament de dades des de diferents ubicacions fins a ubicacions centralitzades.
  • Provadors Hadoop per validar i verificar les dades abans d’extreure de diferents ubicacions i després d’extreure’ls a la ubicació centralitzada, així com validar i verificar es realitza mentre es carreguen les dades a l’entorn del client.
  • Analistes Hadoop funcionar quan es realitzi la càrrega de dades i quan les dades arribin al magatzem a la ubicació del client. Utilitzen aquestes dades per generar informes i taulers. Els analistes realitzen l'anàlisi de dades per al creixement i el desenvolupament empresarial.

Sabem que Hadoop no és un sistema únic; conté múltiples sistemes i màquines. Les dades es divideixen i s’emmagatzemen en diverses màquines i, si volem accedir-hi de nou, hem de combinar i extreure les dades en informes, etc.

El desenvolupador és responsable d’escriure programes en JAVA i Python per extreure les dades i emmagatzemar-les.

L’altra tasca d’un desenvolupador és processar les dades. Hi ha dues capes de Hadoop, una és per emmagatzemar, és a dir, Hadoop HDFS i una altra per processar, és a dir, Hadoop MapReduce.

Emmagatzemar significa que totes les dades que tenim a la font s’emmagatzemen / insereixen al sistema. El processament significa que hem de dividir-lo en diverses màquines i tornar-ho a combinar i enviar al client.

Per tant, l'emmagatzematge i el processament es realitzen mitjançant programació de scripts, i el desenvolupador és el responsable d'escriure els scripts.

A part de la programació, l’altre mètode per emmagatzemar i processar les dades a Hadoop és utilitzar aplicacions de bases de dades com Hive, Impala, HBase, etc. Aquestes eines no necessiten cap coneixement de programació.

Proves de BigData i Hadoop

Un cop el desenvolupador realitza l’emmagatzematge i el processament, les dades es destinen a la generació d’informes. Abans d’això, hem de verificar la precisió de les dades processades i comprovar si les dades es carreguen i processen correctament o no.

Per tant, el programa i / o els scripts creats per un desenvolupador han de ser verificats per Hadoop o BigData Tester. El comprovador ha de conèixer la programació bàsica com Mapper, Hive, Pig Scripts, etc. per verificar els scripts i executar les ordres.

Per tant, abans de provar-los, els provadors han de saber què funcionen tots els programes i scripts, com escriure el codi i després pensar com provar-los. Les proves es poden fer manualment o mitjançant eines d'automatització.

Hadoop té diversos tipus de proves, com ara proves unitàries, proves de regressió, proves de sistemes i proves de rendiment, etc. Per tant, aquests són els tipus de proves més habituals que fem servir tant en proves normals com en proves Hadoop i BigData.

Tenim el mateix tipus de terminologies de proves com l’estratègia de prova, escenaris de prova i casos de prova, etc. a Hadoop i BigData Testing. Només l’entorn és diferent i hi ha diferents tipus de tècniques que fem servir per provar el sistema BigData i Hadoop perquè aquí hem de provar les dades i no l’aplicació.

Com provar BigData i què requereixen provar totes les coses a BigData?

Per a les proves de BigData, hem de tenir alguns plans i estratègies.

Per tant, hem de tenir en compte els següents punts:

  • Quina és l'estratègia o pla de proves per a BigData?
  • Quin tipus d'enfocaments de prova s'apliquen a BigData?
  • Quin és el medi ambient necessari?
  • Com es pot validar i verificar la BigData?
  • Quines són les eines que s’utilitzen a les proves BigData?

Intentem obtenir les respostes a totes les preguntes anteriors.

Quina és l'estratègia o el pla per provar BigData?

La prova BigData significa la verificació i la validació de dades mentre s’emmagatzemen i processen al magatzem de dades.

Mentre provem BigData, hem de provar el volum i la varietat de dades extretes de diferents bases de dades i carregades i processades a Data Warehouse o al sistema Hadoop, aquesta prova passa per proves funcionals.

Hem de provar la velocitat de les dades descarregades de diverses bases de dades i carregades al sistema Hadoop, que forma part de les proves de rendiment.

Per tant, com a pla o estratègia, ens hem de concentrar tant en les proves funcionals com de rendiment de les proves BigData.

A BigData Testing, el comprovador ha de verificar el processament d’una gran quantitat de dades utilitzant Commodity Hardware i components relatius. Per tant, la qualitat de les dades també té un paper important en la prova de BigData. És essencial verificar i validar la qualitat de les dades.

Tipus de proves per a proves de BigData

A la secció anterior, vam veure que les proves funcionals i les proves de rendiment juguen un paper fonamental en les proves BigData, a part del provador BigData, hem de fer alguns tipus de proves més, com ara les proves de bases de dades i les proves arquitectòniques.

Aquests tipus de proves també són tan importants com les proves funcionals i de rendiment.

# 1) Assaigs arquitectònics

Aquesta prova es fa per assegurar-se que el processament de dades és adequat i compleix els requisits. En realitat, el sistema Hadoop processa enormes volums de dades i és molt complet amb recursos.

Si l'arquitectura és incorrecta, pot degradar el rendiment a causa del qual el processament de dades pot interrompre's i es pot produir la pèrdua de dades.

# 2) Prova de bases de dades

Aquí, la validació del procés apareix a la imatge i hem de validar les dades de diverses bases de dades, és a dir, hem de garantir que les dades obtingudes de les bases de dades d'origen o de les bases de dades locals han de ser correctes i adequades.

A més, hem de comprovar que les dades disponibles a les bases de dades d'origen coincideixen amb les dades introduïdes al sistema Hadoop.

Proves de base de dades

De la mateixa manera, hem de validar si les dades del sistema Hadoop són correctes i adequades després del processament o diuen després de la transformació i es carreguen a l’entorn del client amb una validació i verificació adequades.

Com a part de la prova de bases de dades, hem de passar per la CRUEL operacions és a dir Crear les dades de les bases de dades locals Recupera les dades i hem de cercar-les i haurien d’estar disponibles a la base de dades abans i després de carregar-les a Data Warehouse i de Data Warehouse a l’entorn del client.

Verificació de qualsevol Actualitzat Dades sobre totes les etapes d’emmagatzematge, càrrega i processament de les dades. Supressió de les dades danyades o de les dades duplicades i nul·les.

# 3) Proves de rendiment

Com a part de les proves de rendiment, hem de comprovar la velocitat de càrrega i processament de les dades, és a dir, com el IOPS (Input Output Per Second).

Cal comprovar la velocitat d’introducció de dades o dades com a entrada des de diverses bases de dades a Data Warehouse o Hadoop System i des del sistema Hadoop o Data Warehouse a l’entorn del client.

També s'ha de comprovar la velocitat de les dades que provenen de diverses bases de dades i del magatzem de dades com a sortida. Això és el que anomenem sortida d'entrada per segon o IOPS.

A part d’això, un altre aspecte és comprovar el rendiment de l’absorció de dades i la distribució de dades i la rapidesa amb què les dades són consumides pel magatzem de dades de diverses bases de dades i pel sistema del client des del sistema Hadoop.

També com a provador, hem de comprovar el rendiment de la distribució de dades, com la rapidesa amb què es distribueixen les dades a diversos fitxers disponibles al sistema Hadoop o al magatzem de dades. De la mateixa manera, passa el mateix procés mentre es distribueixen dades als sistemes client.

El sistema Hadoop o el magatzem de dades consta de múltiples components, de manera que un provador ha de comprovar el rendiment de tots aquells components com MapReduce Jobs, inserció i consum de dades, el temps de resposta de les consultes i el seu rendiment, així com el rendiment de la cerca. operacions. Tot això s'inclou a les proves de rendiment.

# 4) Proves funcionals

Les proves funcionals contenen proves de tots els components secundaris, programes i scripts, eines que s’utilitzen per realitzar les operacions d’emmagatzematge, càrrega i processament, etc.

Per a un provador, aquests són els quatre tipus i etapes importants a través dels quals cal filtrar les dades perquè el client obtingui les dades perfectes i sense errors.

Eines per a la prova BigData Hadoop

Hi ha diverses eines que s’utilitzen per provar BigData:

  • Sistema de fitxers de distribució Hadoop HDFS per emmagatzemar BigData.
  • Reducció de mapes HDFS per al processament de BigData.
  • Per a NoSQL o HQL Cassandra DB, ZooKeeper i HBase, etc.
  • Eines de servidor basades en núvol com EC2.

Paràmetres i entorns de prova

Per a qualsevol tipus de prova, el Tester necessita una configuració i un entorn adequats.

A continuació es mostra la llista de requisits:

  1. Tipus de dades i aplicació que es provarà.
  2. L’emmagatzematge i el processament requereixen un gran espai per a una gran quantitat de dades.
  3. Distribució adequada dels fitxers a tots els nodes de dades en general al clúster.
  4. Mentre es processen les dades, la utilització del maquinari ha de ser mínima.
  5. Programes i scripts executables segons el requisit de l'aplicació.

Funcions i responsabilitats de les proves Hadoop

Com a provador Hadoop, ens encarreguem de comprendre els requisits, preparar les estimacions de proves, planificar les proves, obtenir algunes dades de prova per provar algunes proves, estar involucrat en la creació del banc de proves, executar els plans de prova, informar i tornar a provar els defectes.

A més, hem de ser responsables dels informes d’estat diaris i de la realització de les proves.

Funcions i responsabilitats de les proves Hadoop

El primer que parlarem és el Prova d’Estratègia . Un cop tinguem la solució proposada al nostre problema, hem de seguir endavant i planificar o planificar el nostre pla de proves, és possible que discutim l’estratègia d’automatització que hi podem utilitzar, el pla sobre el calendari de proves que depèn de les nostres dates d’entrega, també pot discutir la planificació de recursos.

L’estratègia d’automatització és una cosa que ens ajudarà a reduir els esforços manuals necessaris per provar el producte. El calendari de proves és important, ja que assegurarà el lliurament oportú del producte.

La planificació de recursos serà crucial ja que hem de planificar quantes hores laborals necessitem en les nostres proves i quants recursos Hadoop es requereixen per executar la nostra planificació de proves.

Quan hàgim de fer estratègies de proves, hem de seguir endavant i crear els plans de desenvolupament de proves que incloguin la creació de plans de prova, la creació d’escriptures de prova que ens ajudin a automatitzar les proves i també a identificar algunes dades de prova que s’utilitzaran als plans de prova. i ens ajuda a executar aquests plans de prova.

Un cop hàgim acabat el desenvolupament de proves que inclou la creació de plans de prova, scripts de prova i dades de prova, seguim endavant i comencem a executar aquests plans de prova.

Quan executem els plans de prova, pot haver-hi certs escenaris en què la producció real no sigui l’esperada i aquestes coses s’anomenin defectes. Sempre que hi ha un defecte, també hem de provar-los i hem de crear i mantenir les matrius per a aquests.

Totes aquestes coses entren en la següent categoria que és Gestió de defectes .

Què és la gestió de defectes?

La gestió de defectes consisteix en el seguiment d’errors, la correcció d’errors i la verificació d’errors. Sempre que s’executa un pla de prova contra algun dels productes que tenim i tan aviat com s’identifica un error concret o s’identifica un defecte, aquest defecte s’ha de comunicar al desenvolupador o assignar-lo al desenvolupador.

De manera que el desenvolupador pot examinar-ho i començar a treballar-hi. Com a provador, hem de fer un seguiment del progrés de l’error i fer un seguiment si l’error s’ha solucionat. Si l'error s'ha solucionat tal com s'ha informat, haurem de continuar i tornar a provar-lo i verificar si s'ha resolt.

Un cop s'hagin solucionat, tancat i verificat tots els errors, haurem de continuar i lliurar un producte provat OKAY. Però abans d’entregar el producte, hem d’assegurar-nos que la prova d’acceptació d’usuaris (UAT) s’ha completat amb èxit.

Ens assegurem que les proves d’instal·lació i la verificació dels requisits es facin correctament, és a dir, que el producte que es lliura al client o a l’usuari final compleix els requisits que s’esmenten al document de requisits de programari.

Els passos que hem comentat es basen en la imaginació, sigui en qualsevol dels escenaris de prova o en qualsevol dels mètodes de prova que farem servir per a aquests passos o digueu aquestes frases per provar el nostre producte i oferir el resultat final, que és un OKAY Producte provat.

Anem endavant i discutim-ho detalladament i correlacionem-ho amb la prova Hadoop.

Sabem que Hadoop és una cosa que s’utilitza per al processament per lots i també sabem que ETL és un dels camps on s’utilitza molt Hadoop. ETL significa extracció i transformació de càrrega . Parlarem detalladament d’aquests processos quan discutim el pla de prova i l’estratègia de prova com a punt de vista de les proves Hadoop.

Segons el diagrama esmentat a continuació, només assumim que tenim quatre fonts de dades diferents. Sistema Operatiu, CRM ( Gestió de relacions amb clients ) i ERP ( Planificació de Recursos Empresarials ) és el RDBMS o diguem el sistema de gestió de bases de dades relacionals que tenim i també tenim un munt de fitxers plans que potser registren, fitxers, registres o el que sigui quant a les nostres fonts de dades.

És possible que utilitzem Sqoop o Flume o qualsevol producte en particular per obtenir les dades, els registres o el que sigui com a fonts de dades. Podem utilitzar aquestes eines per obtenir les dades de les fonts de dades al meu directori de prova, que es diu la primera fase del nostre procés Extracció.

Una vegada que les dades que hi ha a Staging Directory, que realment passa a ser HDFS (sistema de fitxers de distribució Hadoop), utilitzarem especialment el llenguatge de seqüències com PIG Transformar que les dades. Això Transformació serà segons les dades que tinguem.

Una vegada que les dades es transformin en conseqüència mitjançant qualsevol tecnologia de script que tinguem, ho serem S'està carregant aquestes dades al magatzem de dades. Des del magatzem de dades, aquestes dades s’utilitzaran per a l’anàlisi OLAP, l’elaboració d’informes i l’explotació de dades o per a Analytics.

Anem endavant i discutim quines fases podem utilitzar per a les proves Hadoop.

La primera fase serà la fase d’extracció. Aquí obtindrem les dades de les nostres bases de dades d’origen o de fitxers plans i, en aquest cas, el que podem fer és comprovar que totes les dades s’han copiat correctament i correctament de la font al directori d’intercanvi.

Pot incloure, verificant el nombre de registres, el tipus de registres i el tipus de camps, etc.

Un cop copiades aquestes dades al directori de posada en escena, continuarem endavant i activarem la segona fase, que és Transformació. Aquí tindrem una lògica empresarial que actuarà sobre les dades copiades dels sistemes font i que realment crearà o transformarà les dades en la lògica empresarial necessària.

La transformació pot incloure ordenar les dades, filtrar les dades, unir les dades de dues fonts de dades diferents i algunes altres operacions.

Un cop transformades les dades, seguirem endavant i tindrem preparats els plans de prova i comprovarem si obtenim la sortida tal com s’esperava i si tots els resultats que obtenim compleixen el resultat esperat i els tipus de dades, valors de camp i els rangs, etc. són una cosa que està caient al seu lloc.

Un cop sigui correcta, podem continuar i carregar les dades a Data Warehouse.

A la fase de càrrega, estem comprovant si el nombre de registres de la fase i el nombre de registres a Data Warehouse estan sincronitzats, és possible que no siguin similars, però se suposa que estan sincronitzats. També veiem si el tipus de dades que s’han transformat està sincronitzat.

Publiqueu que utilitzarem aquestes dades per a l’anàlisi OLAP, l’informe i l’explotació de dades, que és l’última capa del nostre producte i, en aquest cas, podem disposar de plans de prova disponibles o per a totes aquestes capes.

Sempre que obtenim algunes dades de la font a la destinació, sempre ens hem d’assegurar que només les persones autenticades tinguin accés autoritzat a les dades.

Autenticació

Autenticació

Autorització

Autorització

Què volem dir amb aquests dos termes?

Per entendre-ho, posem les coses en perspectiva des del diagrama ETL.

ETL

Segons el diagrama anterior, obtenim les nostres dades dels motors RDBMS d'origen i de fitxers plans a HDFS, i aquesta fase s'anomena Extracció.

Analitzem l'autenticació d'una manera particular, hi ha algunes empreses que tenen dades restringides per la seva naturalesa; aquest tipus de dades s'anomena Dades PII segons els estàndards dels Estats Units.

PII significa Informació personal identificable, qualsevol informació com ara la data de naixement, SSN, número de mòbil, adreça de correu electrònic i adreça de casa, etc., pertany a PII. Això està restringit i no es pot compartir amb tothom.

Les dades s’han de compartir únicament amb les persones que més ho necessitin i aquelles que necessiten les dades per al tractament real. Tenir aquesta comprovació i la primera línia de defensa al seu lloc s’anomena autenticació.

Per exemple, fem servir un ordinador portàtil i hi tenim instal·lat Windows, és possible que tinguem algun compte d’usuari creat al nostre sistema operatiu Windows i allà estiguem aplicant una contrasenya.

D’aquesta manera, només la persona que té les credencials d’aquest compte d’usuari en concret pot iniciar sessió al sistema i així és com protegirem les nostres dades contra robatoris o accessos innecessaris. L’altra capa és Autorització.

Exemple, tenim dos comptes d'usuari diferents al nostre sistema operatiu Windows, un compte d'usuari és nostre i un altre pot ser el compte d'usuari convidat. L’administrador (WE) té dret a fer tot tipus d’operacions, com ara la instal·lació i desinstal·lació del programari, la creació de fitxers nous i la supressió de fitxers existents, etc.

D'altra banda, és possible que els usuaris convidats no tinguin tot aquest tipus d'accés. El convidat té autenticació per iniciar la sessió al sistema, però no té l’autoritat per suprimir o crear els fitxers i la instal·lació, així com la desinstal·lació de cap programa del sistema i del sistema, respectivament.

Tanmateix, el compte d’usuari convidat a causa de l’autenticació té dret a llegir els fitxers creats i a utilitzar el programari que ja està instal·lat.

És així com es comprova l'autenticació i l'autorització, en aquest cas, qualsevol que sigui la informació disponible en HDFS o qualsevol dels sistemes de fitxers que necessitem comprovar per a l'autenticació i l'autorització de dades.

Enfocament de proves per a proves Hadoop / proves BigData

Enfocament de proves

L’enfocament de les proves és comú per a tot tipus de proves, no només perquè es tracta de proves BigData o Hadoop quan anem a les proves manuals normals o a les proves d’automatització o a les proves de seguretat, també les proves de rendiment, de manera que qualsevol tipus de prova segueix el mateix enfocament.

Requisits

Com a part de l 'enfocament de proves, hem de començar per Requisits , El requisit és una cosa bàsica, actualment, en el procés Agile, l’anomenàvem com a històries i èpiques. Epic no és res més que un requisit més gran, mentre que les històries són requisits menors.

El requisit bàsicament conté quins són tots els models de dades, objectius, fonts, i quin tipus de transformacions hem d’aplicar, quin tipus d’eines hem d’utilitzar? Tot aquest tipus de detalls estaran disponibles als Requisits.

Aquest és bàsicament el requisit del client o els requisits del client. Basant-nos en aquest requisit, iniciarem el nostre procés de proves.

Estimació

Una altra part d’un enfocament és Estimació , Quant de temps necessitem perquè es faci tota l'activitat com a part de les proves. Fem planificació de proves, preparem els escenaris de prova, preparem casos de prova i executem els mateixos, trobarem defectes i els informarem i prepararem també informes de proves.

Totes aquestes activitats trigaran una mica, per tant, quant de temps necessitem per completar totes aquestes activitats i això bàsicament s’anomena estimació. Hem de fer una aproximació aproximada a la direcció.

Planificació de proves

Planificació de proves no és res més que la descripció dels processos, què cal provar, què no provar, quin és l'abast de la prova, quins són els horaris, quants recursos es requereixen, els requisits de maquinari i programari i quins són els terminis i els cicles de proves s’utilitzaran, quins són els nivells de prova que necessitem, etc.

Durant la planificació de la prova, faran determinades assignacions de recursos al projecte i quins són els diferents models que tenim, quants recursos es requereixen i quin tipus de conjunts d’habilitats es necessiten, etc. totes aquestes coses i aspectes s’inclouran a la prova. Fase de Planificació.

La majoria de les vegades, les persones de nivell de plom o de gestió faran la planificació de proves.

Escenaris i casos de prova

Un cop hàgim acabat la planificació de la prova, ens hem de preparar Escenaris de prova i casos de prova , especialment per a les proves de dades grans, necessitem uns quants documents juntament amb el document de requisits. Juntament amb aquest document de requisits, què necessitem?

Necessitem el Document de requisit que conté les necessitats del client, juntament amb això necessitem el Entrada del document és a dir, Models de dades. Model de dades en el sentit de què són els esquemes de base de dades, quines són les taules i quines són les relacions que totes aquestes dades estaran disponibles als models de dades.

A més, tenim el Assignació de documents , Documents de mapatge per a Per exemple. a Relational DataBases tenim algunes taules i, després de carregar les dades a través d’ETL a Data Warehouse a HDFS, quins mapes hem de fer? és a dir, el tipus de dades de mapatge.

com obrir un nou projecte en eclipsi

Per exemple, si tenim una taula de clients a HDFS, a HDFS tenim una taula CUSTOMER_TARGET o la mateixa taula també pot estar a HIVE.

Assignació de dades

En aquesta taula de clients, tenim algunes columnes i, a la taula OBJECTIU DE CLIENTS, tenim algunes columnes tal com es mostra al diagrama. Vam deixar les dades de la taula de clients a la taula OBJECTIU DEL CLIENT, és a dir, de font a objectiu.

A continuació, hem de comprovar l’assignació exacta, com ara les dades presents a la taula font, que són la columna 1 i la fila 1 de la taula de clients i la considerem C1R1 i les mateixes dades s’han de mapar a C1R1 de la taula TARGET CLIENT. Això s’anomena bàsicament mapatge.

Com sabrem, quines són totes les assignacions que hem de verificar? Per tant, aquestes assignacions estaran presents al document de mapatge. Al document de mapatge, el client proporcionarà tot tipus de mapes.

A més, hem requerit un Document de disseny , Document de disseny necessari tant per a l’equip de desenvolupament com per a l’equip de control de qualitat, ja que al document de disseny el client proporcionarà, quin tipus de feines de reducció de mapes implementaran i quin tipus de feines de MapReduce necessita entrades i quin tipus de MapReduce Jobs dóna resultats.

De la mateixa manera, si tenim HIVE o PIG, quines són totes les UDF que ha creat el client, quines són totes les aportacions que prendran i quin tipus de producció produiran, etc.

Per preparar escenaris de prova i casos de prova, hem de tenir tots aquests documents a mà:

  • Document de requisit
  • Model de dades
  • Document de mapatge
  • Document de disseny

Aquests poden variar d'una organització a una altra, i no hi ha cap norma obligatòria que ens permeti disposar de tots aquests documents. De vegades tenim tots els documents i de vegades només en tenim dos o tres, o de vegades també hem de confiar en un document, que depèn de la complexitat del projecte, els horaris de la companyia i tot.

Ressenyes sobre escenaris de prova i casos de prova

Hem de fer una revisió dels escenaris i casos de prova perquè d'alguna manera o en alguns casos oblidem o trobem a faltar alguns casos de prova perquè tothom no pot pensar en totes les coses possibles que es poden fer amb els requisits, en aquestes condicions hem de prendre ajuda de les eines de tercers o d’algú altre.

Per tant, sempre que preparem alguns documents o realitzem alguna cosa, necessitem que algú revisi les coses del mateix equip, com ara desenvolupadors, verificadors. Donaran suggeriments adequats per incloure alguna cosa més o també suggeriran actualitzar o modificar els escenaris i casos de prova.

Proporcionen tots els comentaris i, en funció d’això, actualitzarem els nostres escenaris de prova i casos de prova i diverses versions del document que hem de publicar a tot l’equip fins que el document s’actualitzi completament segons el requisit.

Execució de la prova

Un cop el document estigui llest, rebrem l’inici de sessió de l’equip superior per iniciar el procés d’execució que bàsicament s’anomena Test Case Execution.

Si volem executar els nostres casos de prova durant l'execució, hem de comprovar que el desenvolupador ha d'enviar la informació, si es tracta de proves funcionals normals o d'altres proves o proves d'automatització, necessitem una compilació. Però, des del punt de vista de les proves Hadoop o BigData, el desenvolupador proporcionarà MapReduce Jobs.

Fitxers HDFS: qualsevol fitxer que es copiï en aquesta informació de fitxers HDFS és necessari per comprovar els privilegis, els scripts HIVE que van ser creats pels desenvolupadors per verificar les dades de la taula HIVE i també necessitem els UDF HIVE que van ser desenvolupats pels desenvolupadors, PIG Scripts i UDF PIG.

Tot això és el que necessitem per obtenir dels desenvolupadors. Abans d’anar a l’execució hauríem de tenir totes aquestes coses.

Per a MapReduce Jobs, proporcionaran alguns fitxers JAR i, com a part de l'HDFS, ja han carregat les dades a HDFS i els fitxers haurien d'estar preparats i els scripts HIVE per validar les dades a les taules HIVE. Sigui quina sigui la UDF que hagin implementat, estarà disponible a la UDF de HIVE. També necessitem el mateix per als scripts PIG i els UDF.

Informes i seguiment de defectes

Un cop executem els nostres casos de prova, trobem alguns defectes, alguns esperats i alguns reals no són iguals als resultats esperats, per la qual cosa hem d’enumerar-los i proporcionar-los a l’equip de desenvolupament per a la seva resolució, i això bàsicament s’anomena Informes de defectes.

Suposem que si trobem algun defecte al treball MapReduce, l’informarem al desenvolupador i tornaran a crear el treball MapReduce i faran algunes modificacions del nivell de codi i, de nou, proporcionaran l’últim treball MapReduce, que hem de provar. .

Aquest és un procés continu, un cop provat i aprovat el treball, hem de tornar a provar-lo i informar-lo al desenvolupador i obtenir el següent per fer-ne la prova. Així es realitza l'activitat d'informes i seguiment de defectes.

Informes de proves

Un cop hàgim acabat tot el procés de proves i els defectes s'hagin tancat, caldrà crear els nostres informes de prova. Els informes de proves són tot el que hem fet per completar el procés de proves fins ara. Tota la planificació, redacció i execució de casos de prova, quina producció obtenim, etc. tot està documentat junt en forma d’informes de prova.

Hem d’enviar aquests informes diàriament, setmanalment o segons les necessitats del client. Actualment, les organitzacions utilitzen el model AGILE, de manera que cal actualitzar tots els informes d’estat durant els Scrums diaris.

Conclusió

En aquest tutorial, hem recorregut:

  • L'estratègia o pla de prova de BigData.
  • Entorn obligatori per a les proves de BigData.
  • Validació i verificacions de BigData.
  • Eines utilitzades per provar BigData.

També vam conèixer -

  • Com funcionen l'estratègia de prova, el desenvolupament de proves, les execucions de proves, la gestió de defectes i el lliurament en els rols i les responsabilitats com a part de les proves Hadoop.
  • Enfocament de proves per a proves Hadoop / BigData, que inclou la recopilació de requisits, l'estimació, la planificació de proves, la creació d'escenaris de prova i casos de prova juntament amb les revisions.
  • També vam conèixer l’execució de les proves, l’informe i seguiment de defectes i els informes de proves.

Esperem que aquest tutorial de proves de BigData us sigui útil.

=> Consulteu TOTS els tutorials de BigData aquí.

Lectura recomanada

^