Menu

Esercitazione completa sul test Hadoop | Big Data Testing Guide

  • Principale
  • Altro
  • Esercitazione completa sul test Hadoop | Big Data Testing Guide

comprehensive hadoop testing tutorial big data testing guide

Prova Il Nostro Strumento Per Eliminare I Problemi

Questo tutorial spiega le basi, i tipi di test, i piani, l'ambiente richiesto, il processo di test, la convalida e le verifiche per Hadoop e BigData Testing:

In questo tutorial, vedremo l'introduzione di base a Hadoop e BigData Testing, come quando e dove il test entrerà in scena e cosa dobbiamo testare come parte di Hadoop Testing.

Discuteremo anche i seguenti argomenti in dettaglio:

  • Ruoli e responsabilità dei test Hadoop
  • Approccio di test per test Hadoop / BigData

=> Controlla qui per vedere qui i tutorial di formazione su BigData dalla A alla Z.

Introduzione a BigData e Hadoop Testing

Cosa imparerai:

Archiviazione ed elaborazione dei dati in Hadoop

Per eseguire questi processi sul sistema Hadoop, disponiamo della manodopera suddivisa in quattro sezioni.

  • Amministratori di Hadoop sono responsabili della configurazione dell'ambiente e hanno i diritti di amministrazione per accedere ai sistemi Hadoop.
  • Sviluppatori Hadoop sviluppare i programmi riguardanti l'estrazione, l'archiviazione e l'elaborazione dei dati da diverse posizioni a posizioni centralizzate.
  • Hadoop Tester per la convalida e la verifica dei dati prima di estrarre da posizioni diverse e dopo aver estratto dalla posizione centralizzata, nonché la convalida e la verifica viene eseguita durante il caricamento dei dati nell'ambiente client.
  • Analisti Hadoop funzionano quando il caricamento dei dati è terminato e quando i dati raggiungono il magazzino presso la posizione del cliente. Usano questi dati per la generazione di report e dashboard. Gli analisti eseguono l'analisi dei dati per la crescita e lo sviluppo del business.

Sappiamo che Hadoop non è un unico sistema; contiene più sistemi e macchine. I dati vengono suddivisi e archiviati in più macchine e se vogliamo accedervi di nuovo dobbiamo combinare e inserire i dati nei rapporti e così via.

Lo sviluppatore è responsabile della scrittura di programmi in JAVA e Python per estrarre i dati e archiviarli.

L'altro compito di uno sviluppatore è elaborare i dati. Ci sono due livelli di Hadoop, uno per l'archiviazione, ad esempio Hadoop HDFS e un altro per l'elaborazione, ad esempio Hadoop MapReduce.

Archiviazione significa che tutti i dati che abbiamo nella sorgente vengono semplicemente memorizzati / inseriti nel sistema. Elaborazione significa che dobbiamo dividerlo in più macchine e di nuovo combinarlo e inviarlo al client.

Pertanto, la memorizzazione e l'elaborazione vengono eseguite programmando gli script e lo sviluppatore è responsabile della scrittura degli script.

Oltre alla programmazione, l'altro metodo per archiviare ed elaborare i dati in Hadoop consiste nell'utilizzare applicazioni database come Hive, Impala, HBase, ecc. Questi strumenti non richiedono alcuna conoscenza di programmazione.

BigData e test Hadoop

Una volta che l'archiviazione e l'elaborazione sono state eseguite dallo sviluppatore, i dati vengono utilizzati per la generazione di report. Prima di ciò, dobbiamo verificare l'accuratezza dei dati elaborati e controllare se i dati vengono caricati ed elaborati accuratamente o meno.

Quindi il programma e / o gli script creati da uno sviluppatore devono essere verificati da Hadoop o BigData Tester. Il tester deve conoscere la programmazione di base come Mapper, Hive, Pig Scripts, ecc. Per verificare gli script e per eseguire i comandi.

Quindi, prima di testare, i tester devono sapere cosa funzionano tutti i programmi e gli script, come scrivere il codice e poi pensare a come testarli. Il test può essere eseguito manualmente o utilizzando strumenti di automazione.

Hadoop ha vari tipi di test come test unitari, test di regressione, test di sistema e test delle prestazioni, ecc. Quindi questi sono i tipi di test comuni che utilizziamo nei nostri test normali, nonché test Hadoop e BigData.

Abbiamo lo stesso tipo di terminologie di test come strategia di test, scenari di test e casi di test, ecc. In Hadoop e BigData Testing. Solo l'ambiente è diverso e ci sono diversi tipi di tecniche che usiamo per testare il sistema BigData e Hadoop perché qui dobbiamo testare i dati e non l'applicazione.

Come testare BigData e cosa richiedono tutti i test in BigData?

Per i test BigData, abbiamo bisogno di alcuni piani e strategie.

Quindi dobbiamo considerare i seguenti punti:

  • Qual è la strategia o il piano di test per BigData?
  • Che tipo di approcci di test vengono applicati a BigData?
  • Qual è l'ambiente richiesto?
  • Come convalidare e verificare i BigData?
  • Quali sono gli strumenti utilizzati in BigData Testing?

Proviamo a ottenere le risposte a tutte le domande precedenti.

Qual è la strategia o il piano per testare BigData?

Test BigData significa verifica e convalida dei dati durante la memorizzazione e l'elaborazione nel Data Warehouse.

Durante il test di BigData, dobbiamo testare il volume e la varietà di dati estratti da diversi database e caricati ed elaborati su Data Warehouse o Hadoop System, questo test è sottoposto a test funzionali.

Dobbiamo testare la velocità dei dati scaricati da vari database e caricati sul sistema Hadoop, che fa parte del test delle prestazioni.

Quindi, come piano o strategia, dobbiamo concentrarci sui test funzionali e sulle prestazioni dei test BigData.

In BigData Testing, il tester deve verificare l'elaborazione di un'enorme quantità di dati utilizzando Commodity Hardware e relativi componenti. Quindi, anche la qualità dei dati gioca un ruolo importante nel test di BigData. È essenziale verificare e convalidare la qualità dei dati.

Tipi di test per test BigData

Nella sezione precedente, abbiamo visto che il test funzionale e il test delle prestazioni svolgono un ruolo fondamentale nel test BigData, a parte questo come BigData Tester, dobbiamo eseguire alcuni altri tipi di test come il test del database e il test architettonico.

Questi tipi di test sono importanti anche quanto i test funzionali e delle prestazioni.

# 1) Test architettonici

Questo test viene eseguito per garantire che l'elaborazione dei dati sia corretta e soddisfi i requisiti. In realtà, il sistema Hadoop elabora enormi volumi di dati ed è altamente completo di risorse.

Se l'architettura non è corretta, le prestazioni potrebbero peggiorare a causa della quale l'elaborazione dei dati potrebbe interrompersi e potrebbe verificarsi una perdita di dati.

# 2) Test del database

Qui, la convalida del processo entra in gioco e dobbiamo convalidare i dati da vari database, ovvero dobbiamo assicurarci che i dati recuperati dai database di origine o dai database locali siano corretti e appropriati.

Inoltre, dobbiamo controllare che i dati disponibili nei database di origine corrispondano ai dati inseriti nel sistema Hadoop.

DataBase Testing

Allo stesso modo, dobbiamo convalidare se i dati nel sistema Hadoop sono corretti e corretti dopo l'elaborazione o dire dopo la trasformazione e devono essere caricati nell'ambiente del cliente con la corretta convalida e verifica.

Come parte del test del database, dobbiamo passare attraverso il CRUDELE operazioni i.e. Creare i dati nei database locali quindi Recuperare i dati e dobbiamo cercarli e dovrebbero essere disponibili nel database prima e dopo il caricamento in Data Warehouse e dal Data Warehouse nell'ambiente del cliente.

Verifica di qualsiasi Aggiornato Dati in ogni fase della memorizzazione o del caricamento e dell'elaborazione dei dati. Cancellazione di qualsiasi dato danneggiato o di qualsiasi dato duplicato e nullo.

# 3) Test delle prestazioni

Come parte del test delle prestazioni, dobbiamo controllare la velocità di caricamento e di elaborazione dei dati, ad esempio come IOPS (Input Output Per Second).

È necessario controllare la velocità di immissione dei dati o dei dati come input da vari database al data warehouse o al sistema Hadoop e dal sistema Hadoop o al data warehouse all'ambiente del cliente.

Deve inoltre verificare la velocità dei dati provenienti dai vari Database e dal Data Warehouse come Output. Questo è ciò che chiamiamo Input Output Per Second o IOPS.

A parte questo, un altro aspetto è controllare le prestazioni dell'assorbimento e della distribuzione dei dati e la velocità con cui i dati vengono consumati dal Data Warehouse da vari database e dal sistema del cliente dal sistema Hadoop.

Inoltre, come tester, dobbiamo controllare le prestazioni della distribuzione dei dati, ad esempio la velocità con cui i dati vengono distribuiti ai vari file disponibili nel sistema Hadoop o nel data warehouse. Allo stesso modo, lo stesso processo si verifica durante la distribuzione dei dati ai sistemi client.

Il sistema Hadoop o il Data Warehouse è costituito da più componenti, quindi un Tester deve controllare le prestazioni di tutti quei componenti come i lavori MapReduce, l'inserimento e il consumo dei dati, il tempo di risposta delle query e le loro prestazioni, nonché le prestazioni della ricerca operazioni. Tutti questi sono inclusi nel test delle prestazioni.

# 4) Test funzionale

Il test funzionale contiene il test di tutti i sottocomponenti, programmi e script, strumenti utilizzati per eseguire le operazioni di archiviazione o caricamento ed elaborazione, ecc.

Per un tester, questi sono i quattro tipi e fasi importanti attraverso i quali i dati devono essere filtrati in modo che il cliente ottenga i dati perfetti e privi di errori.

Strumenti per test Hadoop BigData

Esistono vari strumenti utilizzati per testare BigData:

  • File system di distribuzione Hadoop HDFS per l'archiviazione di BigData.
  • Riduzione mappa HDFS per l'elaborazione di BigData.
  • Per NoSQL o HQL Cassandra DB, ZooKeeper e HBase, ecc.
  • Strumenti server basati su cloud come EC2.

Test di ambienti e impostazioni

Per qualsiasi tipo di test, il Tester necessita di impostazioni e ambiente adeguati.

Di seguito è riportato l'elenco dei requisiti:

  1. Tipo di dati e applicazione che verranno testati.
  2. La memorizzazione e l'elaborazione richiedono un ampio spazio per un'enorme quantità di dati.
  3. Corretta distribuzione dei file su tutti i DataNode nel complesso del cluster.
  4. Durante l'elaborazione dei dati, l'utilizzo dell'hardware dovrebbe essere minimo.
  5. Programmi e script eseguibili secondo i requisiti dell'applicazione.

Ruoli e responsabilità dei test Hadoop

In qualità di tester Hadoop, siamo responsabili della comprensione dei requisiti, della preparazione delle stime dei test, della pianificazione dei casi di test, di ottenere alcuni dati di test per testare alcuni casi di test, di essere coinvolti nella creazione del banco di prova, nell'esecuzione dei piani di prova, nel reporting e nel nuovo test dei difetti.

Inoltre, dobbiamo essere responsabili dei rapporti giornalieri sullo stato e del completamento dei test.

Ruoli e responsabilità dei test Hadoop

La prima cosa di cui discuteremo è il file Strategia di test . Una volta che abbiamo una soluzione proposta al nostro problema, dobbiamo andare avanti e pianificare o strategizzare il nostro piano di test, potremmo discutere la strategia di automazione che possiamo usare lì, il piano sul programma di test che dipende dalle nostre date di consegna, anche noi può discutere la pianificazione delle risorse.

La strategia di automazione è qualcosa che ci aiuterà a ridurre gli sforzi manuali richiesti per testare il prodotto. Il programma dei test è importante in quanto garantirà la consegna tempestiva del prodotto.

La pianificazione delle risorse sarà fondamentale in quanto dobbiamo pianificare quante ore di lavoro abbiamo bisogno per i nostri test e quante risorse Hadoop sono necessarie per eseguire la nostra pianificazione dei test.

Una volta che abbiamo strategizzato i nostri test, dobbiamo andare avanti e creare i piani di sviluppo del test che includono la creazione di piani di test, la creazione di script di test che ci aiuteranno ad automatizzare i nostri test e anche identificare alcuni dati di test che verranno utilizzati nei piani di test e ci aiuta a eseguire tali piani di test.

Una volta che abbiamo finito con lo sviluppo del test che include la creazione di piani di test, script di test e dati di test, andiamo avanti e iniziamo a eseguire quei piani di test.

Quando eseguiamo i piani di test, potrebbero esserci alcuni scenari in cui l'output effettivo non è quello previsto e queste cose sono chiamate difetti. Ogni volta che c'è un difetto, dobbiamo testare anche quei difetti e dobbiamo creare e mantenere le matrici per quelli.

Tutte queste cose rientrano nella categoria successiva che è Gestione dei difetti .

Cos'è la gestione dei difetti?

La gestione dei difetti consiste nel monitoraggio dei bug, nella correzione dei bug e nella verifica dei bug. Ogni volta che viene eseguito un piano di test su uno qualsiasi dei prodotti in nostro possesso e non appena viene identificato un bug particolare o viene identificato un difetto, quel difetto deve essere segnalato allo sviluppatore o assegnato allo sviluppatore.

Quindi lo sviluppatore può esaminarlo e iniziare a lavorarci. In qualità di tester, dobbiamo monitorare l'avanzamento del bug e monitorare se il bug è stato risolto. Se il bug è stato risolto come segnalato, dobbiamo andare avanti e ripetere il test e verificare se è stato risolto.

Una volta che tutti i bug sono stati corretti, chiusi e verificati, dobbiamo andare avanti e fornire un prodotto testato OK. Ma prima di consegnare il prodotto dobbiamo assicurarci che l'UAT (User Acceptance Testing) sia completato con successo.

Ci assicuriamo che i test di installazione e la verifica dei requisiti siano eseguiti correttamente, ovvero il prodotto che viene consegnato al cliente o a un utente finale sia conforme ai requisiti menzionati nel Documento sui requisiti software.

I passaggi che abbiamo discusso sono basati sull'immaginazione, essere uno qualsiasi degli scenari di test o uno qualsiasi degli approcci di test che utilizzeremo per quei passaggi o dire quelle frasi per testare il nostro prodotto e fornire il risultato finale, che è un OK Prodotto testato.

Andiamo avanti e discutiamo di questo in dettaglio e correliamolo con il test Hadoop.

Sappiamo che Hadoop è qualcosa che viene utilizzato per l'elaborazione in batch e sappiamo anche che ETL è uno dei campi in cui Hadoop viene utilizzato molto. ETL è l'acronimo di Extraction Transformation and Loading . Discuteremo questi processi in dettaglio quando discuteremo il piano di test e la strategia di test come punto di vista del test Hadoop.

Secondo il diagramma riportato di seguito, presumiamo di avere quattro diverse origini dati. Sistema operativo, CRM ( Gestione delle relazioni con i clienti ) e ERP ( Pianificazione delle risorse aziendali ) è l'RDBMS o diciamo il Relational DataBase Management System che abbiamo e abbiamo anche un po 'di file flat che forse log, file, record o qualsiasi altra cosa riguardante le nostre origini dati.

Potremmo utilizzare Sqoop o Flume o qualsiasi altro prodotto particolare per ottenere i dati, i record o qualsiasi altra cosa come le mie origini dati. Possiamo utilizzare questi strumenti per ottenere i dati dalle origini dati nella mia directory di staging, che è la prima fase del nostro processo chiamata Estrazione.

Una volta che i dati nella directory di staging che in realtà sono HDFS (Hadoop Distribution File System), utilizzeremo in particolare il linguaggio di scripting come PIG per Trasformare quei dati. Quello Trasformazione sarà secondo i dati che abbiamo.

Una volta che i dati vengono trasformati di conseguenza utilizzando qualsiasi tecnologia di scripting che abbiamo, lo saremo Caricamento in corso quei dati nel Data Warehouse. Dal Data Warehouse, tali dati verranno utilizzati per OLAP Analysis, Reporting e Data Mining o per Analytics.

Andiamo avanti e discutiamo su quali fasi possiamo utilizzare per i test Hadoop.

La prima fase sarà la fase di estrazione. Qui, otterremo i dati dai nostri Source DataBase o dai file Flat, e in tal caso, ciò che possiamo fare è verificare che tutti i dati siano stati copiati correttamente e correttamente dall'origine alla directory di staging.

Può includere la verifica del numero di record, il tipo di record e il tipo di campi, ecc.

Una volta che questi dati sono stati copiati nella directory di gestione temporanea, andremo avanti e attiveremo la seconda fase che è la trasformazione. Qui, avremo una logica di business che agirà sui dati copiati dai sistemi di origine e creerà o trasformerà effettivamente i dati nella logica di business richiesta.

La trasformazione può includere l'ordinamento dei dati, il filtraggio dei dati, l'unione dei dati da due diverse origini dati e alcune altre operazioni.

Una volta che i dati sono stati trasformati, andremo avanti e avremo pronti piani di test e controlleremo se stiamo ottenendo l'output come previsto e tutti gli output che stiamo ottenendo soddisfano il risultato atteso e i tipi di dati, i valori dei campi e gli intervalli, ecc. sono qualcosa che sta andando a posto.

Una volta che è corretto, possiamo andare avanti e caricare i dati in Data Warehouse.

Nella fase di caricamento, stiamo effettivamente verificando se il numero di record dallo stage e il numero di record in Data Warehouse sono sincronizzati, potrebbero non essere simili, ma dovrebbero essere sincronizzati. Vediamo anche se il tipo di dati che è stato trasformato è sincronizzato.

Pubblica che useremo questi dati per OLAP Analysis, Reporting e Data Mining che è l'ultimo strato del nostro prodotto e in tal caso, possiamo avere successivi o possiamo dire che i piani di test disponibili per tutti questi strati.

Ogni volta che otteniamo alcuni dati dall'origine nella destinazione, dobbiamo sempre assicurarci che solo le persone autenticate abbiano accesso autorizzato ai dati.

Autenticazione

Autenticazione

Autorizzazione

Autorizzazione

Cosa intendiamo con entrambi questi termini?

Per capirlo, vediamo le cose in prospettiva dal diagramma ETL.

ETL

Secondo il diagramma sopra, stiamo ottenendo i nostri dati dai motori RDBMS di origine e dai file flat in HDFS, e quella fase è chiamata Estrazione.

Parliamo di autenticazione in un modo particolare, ci sono alcune aziende che hanno dati limitati per sua natura, questo tipo di dati è chiamato dati PII secondo gli standard degli Stati Uniti.

PII sta per Informazioni personali identificabili, qualsiasi informazione come data di nascita, SSN, numero di cellulare, indirizzo e-mail e indirizzo di casa, ecc. rientrano tutte nelle PII. Questo è limitato e non può essere condiviso con tutti.

I Dati devono essere condivisi solo con le persone che ne hanno più bisogno e con coloro che hanno bisogno dei Dati per l'effettiva elaborazione. Avere questo controllo e la prima linea di difesa in atto si chiama autenticazione.

Per esempio, stiamo usando un laptop e abbiamo Windows installato lì, potremmo avere un account utente creato sul nostro sistema operativo Windows e lì stavamo applicando una password.

In questo modo solo la persona che ha le credenziali per questo particolare account utente può accedere al sistema ed è così che salvaguarderemo i nostri dati da furti o accessi non necessari. L'altro livello è l'autorizzazione.

Esempio, abbiamo due diversi account utente sul nostro sistema operativo Windows, un account utente è nostro e un altro potrebbe essere l'account utente ospite. L'amministratore (WE) ha il diritto di eseguire tutti i tipi di operazioni, come l'installazione e la disinstallazione del software, la creazione di un nuovo file e l'eliminazione di file esistenti, ecc.

Mentre d'altra parte, gli utenti guest potrebbero non avere tutto questo tipo di accesso. L'ospite ha l'autenticazione per accedere al sistema ma non ha l'autorità per eliminare o creare i file e l'installazione, nonché la disinstallazione di qualsiasi software nel sistema e dal sistema rispettivamente.

Tuttavia, l'account utente guest a causa dell'autenticazione ha il diritto di leggere i file creati e utilizzare il software già installato.

Questo è il modo in cui vengono testati l'autenticazione e l'autorizzazione, in questo caso, qualsiasi dato disponibile in HDFS o qualsiasi file system di cui abbiamo bisogno per verificare l'autenticazione e l'autorizzazione dei dati.

Approccio di test per test Hadoop / test BigData

Approccio al test

L'approccio di test è comune a tutti i tipi di test non solo perché è BigData o Hadoop Testing quando andiamo al normale test manuale o al test di automazione o al test di sicurezza, anche al test delle prestazioni, quindi qualsiasi tipo di test segue lo stesso approccio.

Requisiti

Come parte dell'approccio di test, dobbiamo iniziare con il Requisiti , Il requisito è una cosa fondamentale, al giorno d'oggi nel processo Agile, lo chiamavamo Stories ed Epics. L'epica non è altro che un requisito più grande mentre le storie sono requisiti più piccoli.

Il requisito fondamentalmente contiene quali sono tutti i modelli di dati, i target, le sorgenti e il tipo di trasformazioni che dobbiamo applicare, che tipo di strumenti dobbiamo usare? Tutti questi tipi di dettagli saranno disponibili nei Requisiti.

Questo è fondamentalmente il requisito del cliente o i requisiti del cliente. Sulla base di questo requisito, inizieremo il nostro processo di test.

Stima

Un'altra parte di un approccio è Stima , Quanto tempo è necessario impiegare per svolgere l'intera attività come parte del test. Facciamo la pianificazione dei test, prepariamo gli scenari di test, la preparazione dei casi di test e l'esecuzione degli stessi così come troveremo i difetti e li segnaleremo e prepareremo anche i rapporti di prova.

Tutte queste attività richiederanno del tempo, quindi quanto tempo abbiamo bisogno per completare tutte queste attività e questo è fondamentalmente chiamato una stima. Dobbiamo fornire una stima approssimativa alla direzione.

Pianificazione dei test

Pianificazione dei test non è altro che la descrizione dei processi, cosa testare, cosa non testare, qual è l'ambito del test, quali sono i programmi, quante risorse sono richieste, requisiti hardware e software e quali sono le tempistiche nonché i cicli di test verranno utilizzati, quali sono i livelli di test richiesti, ecc.

Durante la pianificazione del test, faranno una certa allocazione delle risorse al progetto e quali sono i diversi modelli che abbiamo, quante risorse sono richieste e che tipo di set di abilità sono richiesti, ecc. Tutte queste cose e aspetti saranno inclusi nel test Fase di pianificazione.

La maggior parte delle volte le persone a livello di lead o di gestione faranno la pianificazione del test.

Scenari di test e casi di test

Una volta che abbiamo finito con la pianificazione del test, dobbiamo prepararci Scenari di test e casi di test , soprattutto per il test dei Big Data, sono necessari alcuni documenti insieme al documento dei requisiti. Insieme a questo documento sui requisiti, di cosa abbiamo bisogno?

Abbiamo bisogno di Documento di requisito che contiene le esigenze del Cliente, insieme a questo abbiamo bisogno del file Documento di input cioè Modelli di dati. Data Model nel senso cosa sono gli Schemi DataBase, quali sono le tabelle e quali sono le relazioni tutti questi Dati saranno disponibili nei Data Model.

Inoltre, abbiamo il file Documenti di mappatura , Mappatura documenti per Per esempio. in Relational DataBase abbiamo alcune tabelle e dopo aver caricato i dati tramite ETL in Data Warehouse in HDFS, cosa sono tutte le mappature che dobbiamo fare? cioè Mapping Data Type.

quale azienda è attualmente leader nei servizi di web hosting basati su cloud?

Per esempio, se abbiamo una tabella del cliente in HDFS, in HDFS abbiamo una tabella CUSTOMER_TARGET o la stessa tabella potrebbe essere anche in HIVE.

Mappatura dei dati

In questa tabella clienti, abbiamo determinate colonne e nella tabella TARGET CLIENTE, abbiamo alcune colonne come mostrato nel diagramma. Abbiamo scaricato i dati dalla tabella del cliente alla tabella TARGET DEL CLIENTE, ovvero dall'origine al target.

Quindi dobbiamo controllare la mappatura esatta come i dati presenti nella tabella di origine che è la colonna 1 e la riga 1 della tabella clienti e la considera come C1R1 e gli stessi dati dovrebbero essere mappati in C1R1 della tabella CUSTOMER TARGET. Questo è fondamentalmente chiamato Mapping.

Come faremo a sapere, quali sono tutte le mappature che dobbiamo verificare? Quindi queste mappature saranno presenti nel documento di mappatura. Nel Documento di Mappatura, il Cliente fornirà tutti i tipi di Mappature.

Inoltre, abbiamo richiesto un file Documento di progettazione , Documento di progettazione richiesto sia per il team di sviluppo che per il team di controllo qualità, perché nel documento di progettazione il cliente fornirà, che tipo di lavori Map Reduce intende implementare e che tipo di lavori MapReduce prende input e che tipo di MapReduce I lavori danno risultati.

Allo stesso modo, se abbiamo HIVE o PIG, quali sono tutte le UDF che il cliente ha creato e quali sono tutti gli input che prenderanno e che tipo di output produrranno, ecc.

Per preparare scenari di test e casi di test, è necessario disporre di tutti questi documenti a mano:

  • Documento di requisito
  • Modello di dati
  • Documento di mappatura
  • Documento di progettazione

Questi possono variare da un'organizzazione all'altra e non esiste una regola obbligatoria per cui dobbiamo avere tutti questi documenti. A volte abbiamo tutti i documenti ea volte abbiamo solo due o tre documenti o talvolta dobbiamo fare affidamento anche su un documento, che dipende dalla complessità del progetto, dai programmi aziendali e da tutto.

Recensioni su scenari di test e casi di test

Dobbiamo eseguire una revisione su scenari di test e casi di test perché in qualche modo o in alcuni casi dimentichiamo o perdiamo alcuni casi di test perché tutti non possono pensare a tutte le cose possibili che possono essere fatte con i requisiti, in tali condizioni dobbiamo prendere aiuto da strumenti di terze parti o da qualcun altro.

Quindi, ogni volta che prepariamo dei documenti o eseguiamo qualcosa, abbiamo bisogno di qualcuno che riveda le cose dello stesso team, come sviluppatori, tester. Daranno suggerimenti adeguati per includere qualcosa di più o suggeriranno anche di aggiornare o modificare gli scenari di test e i casi di test.

Forniscono tutti i commenti e in base a questo aggiorneremo i nostri scenari di test e casi di test e le versioni multiple del documento che dobbiamo rilasciare in tutto il team fino a quando il documento non sarà completamente aggiornato secondo il requisito.

Esecuzione del test

Una volta che il documento è pronto, riceveremo l'approvazione dal team superiore per avviare il processo di esecuzione che è fondamentalmente chiamato Test Case Execution.

Se vogliamo eseguire i nostri casi di test durante l'esecuzione, dobbiamo controllare che lo sviluppatore debba inviare le informazioni, se è normale test funzionale o qualche altro test o test di automazione abbiamo bisogno di un build. Ma, qui dal punto di vista di Hadoop o BigData Testing, lo sviluppatore fornirà lavori MapReduce.

File HDFS: qualsiasi file copiato in HDFS, tali informazioni sui file sono necessarie per controllare i privilegi, gli script HIVE che sono stati creati dagli sviluppatori per verificare i dati nella tabella HIVE e inoltre abbiamo bisogno delle UDF HIVE che sono state sviluppate dagli sviluppatori, PIG Script e UDF PIG.

Queste sono tutte le cose che dobbiamo ottenere dagli sviluppatori. Prima di andare all'esecuzione dovremmo avere tutte queste cose.

Per i lavori MapReduce, forniranno alcuni file JAR e come parte dell'HDFS hanno già caricato i dati in HDFS e i file dovrebbero essere pronti e gli script HIVE per convalidare i dati nelle tabelle HIVE. Qualunque sia l'UDF che hanno implementato sarà disponibile nell'UDF HIVE. Abbiamo bisogno della stessa cosa per gli script PIG e anche per le UDF.

Segnalazione e monitoraggio dei difetti

Una volta eseguiti i nostri casi di test, troviamo alcuni difetti, alcuni attesi e alcuni effettivi non sono uguali ai risultati attesi, quindi dobbiamo elencarli e fornirli al team di sviluppo per la risoluzione, e questo è fondamentalmente chiamato Report dei difetti.

Supponiamo che se troviamo qualche difetto nel lavoro MapReduce, lo segnaleremo allo sviluppatore e loro ricreano nuovamente il lavoro MapReduce e fanno alcune modifiche a livello di codice e poi di nuovo forniranno l'ultimo lavoro MapReduce, che dobbiamo testare .

Questo è un processo continuo, una volta che il lavoro è stato testato e superato, dobbiamo nuovamente testarlo e segnalarlo allo sviluppatore e quindi ottenere quello successivo per il test. In questo modo viene eseguita l'attività di segnalazione e monitoraggio dei difetti.

Rapporti di prova

Una volta che abbiamo finito con tutto il processo di test e che i difetti sono stati chiusi, dobbiamo creare i nostri rapporti di prova. Test Reports è tutto ciò che abbiamo fatto finora per completare il processo di test. Tutta la pianificazione, la scrittura e l'esecuzione dei casi di test, l'output che abbiamo ottenuto, ecc. Tutto viene documentato insieme sotto forma di rapporti di prova.

Dobbiamo inviare questi rapporti su base giornaliera o settimanale o secondo le esigenze del cliente. Al giorno d'oggi le organizzazioni utilizzano il modello AGILE, quindi ogni Status Report deve essere aggiornato durante il Daily Scrums.

Conclusione

In questo tutorial, abbiamo esaminato:

  • La strategia o il piano per testare BigData.
  • Ambiente richiesto per BigData Testing.
  • Validazione e verifiche BigData.
  • Strumenti utilizzati per testare BigData.

Abbiamo anche appreso di:

  • Come funzionano la strategia di test, lo sviluppo dei test, le esecuzioni dei test, la gestione dei difetti e la consegna nei ruoli e nelle responsabilità come parte del test Hadoop.
  • Approccio di test per test Hadoop / BigData che include raccolta dei requisiti, stima, pianificazione dei test, creazione di scenari di test e casi di test insieme alle revisioni.
  • Siamo anche venuti a conoscenza dell'esecuzione dei test, del reporting e del monitoraggio dei difetti e dei rapporti sui test.

Ci auguriamo che questo tutorial sul test di BigData ti sia stato utile!

=> Controlla TUTTI i tutorial di BigData qui.

Lettura consigliata

^