Meniu

Tutorial cuprinzător de testare Hadoop | Ghid de testare Big Data

  • Principal
  • Alte
  • Tutorial cuprinzător de testare Hadoop | Ghid de testare Big Data

comprehensive hadoop testing tutorial big data testing guide

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Acest tutorial explică elementele de bază, tipurile de testare, planurile, mediul necesar, procesul de testare, validarea și verificările pentru testarea Hadoop și BigData:

În acest tutorial, vom vedea introducerea de bază a testelor Hadoop și BigData, cum ar fi când și unde testarea va intra în imagine și ce trebuie să testăm ca parte a testării Hadoop.

De asemenea, vom discuta în detaliu următoarele subiecte:

  • Rolurile și responsabilitățile testării Hadoop
  • Abordare de testare pentru testarea Hadoop / BigData

=> Verificați aici pentru a vedea A-Z a tutorialelor de instruire BigData aici.

Introducere în testarea BigData și Hadoop

Ce veți învăța:

Stocarea și prelucrarea datelor în Hadoop

Pentru a efectua aceste procese pe sistemul Hadoop, avem forța de muncă care este clasificată în patru secțiuni.

  • Administratori Hadoop sunt responsabili pentru configurarea mediului și au drepturile de administrare pentru a accesa sistemele Hadoop.
  • Dezvoltatori Hadoop dezvoltați programele privind extragerea, stocarea și prelucrarea datelor din diferite locații în locații centralizate.
  • Testatori Hadoop pentru validarea și verificarea datelor înainte de extragerea din diferite locații și după extragerea la locația centralizată, precum și validarea și verificarea se face în timpul încărcării datelor în mediul client.
  • Analiști Hadoop funcționează când încărcarea datelor este efectuată și când datele ajung în depozit la locația clientului. Aceștia folosesc aceste date pentru generarea de rapoarte și tablouri de bord. Analiștii efectuează analiza datelor pentru creștere și dezvoltarea afacerii.

Știm că Hadoop nu este un sistem unic; conține mai multe sisteme și mașini. Datele sunt împărțite și stocate în mai multe mașini și, dacă dorim să le accesăm din nou, trebuie să combinăm și să extragem datele în rapoarte și așa mai departe.

Dezvoltatorul este responsabil pentru scrierea programelor în JAVA și Python pentru a extrage datele și a le stoca.

Cealaltă sarcină a unui dezvoltator este să proceseze datele. Există două straturi de Hadoop, unul este pentru stocarea adică Hadoop HDFS și altul pentru procesare adică Hadoop MapReduce.

Stocarea înseamnă orice date pe care le avem în sursă sunt stocate / inserate în sistem. Procesarea înseamnă că trebuie să o împărțim în mai multe mașini și să o combinăm din nou și să o trimitem clientului.

Astfel, stocarea și procesarea se realizează prin programarea scripturilor, iar dezvoltatorul este responsabil pentru scrierea scripturilor.

În afară de programare, cealaltă metodă de stocare și procesare a datelor în Hadoop este utilizarea aplicațiilor de baze de date precum Hive, Impala, HBase etc. Aceste instrumente nu au nevoie de cunoștințe de programare.

Testarea BigData și Hadoop

Odată ce stocarea și procesarea sunt realizate de către dezvoltator, datele sunt destinate generării de rapoarte. Înainte de aceasta, trebuie să verificăm exactitatea datelor procesate și să verificăm dacă datele sunt corect încărcate și procesate corect sau nu.

Deci, programul și / sau scripturile create de un dezvoltator trebuie verificate de Hadoop sau BigData Tester. Testatorul trebuie să cunoască programarea de bază, cum ar fi Mapper, Hive, Pig Scripts, etc. pentru a verifica scripturile și pentru a executa comenzile.

Deci, înainte de testare, testerii trebuie să știe ce funcționează toate programele și scripturile, cum să scrie codul și apoi să se gândească la cum să le testeze. Testarea se poate face fie manual, fie folosind instrumente de automatizare.

Hadoop are diferite tipuri de testare, cum ar fi testarea unitară, testarea de regresie, testarea sistemului și testarea performanței, etc. Deci acestea sunt tipurile de testare obișnuite pe care le folosim în testarea noastră normală, precum și testarea Hadoop și BigData.

Avem același tip de terminologii de testare, cum ar fi strategia de testare, scenariile de testare și cazurile de testare, etc. în testarea Hadoop și BigData. Numai mediul este diferit și există diferite tipuri de tehnici pe care le folosim pentru a testa sistemul BigData și Hadoop, deoarece aici trebuie să testăm datele și nu aplicația.

Cum se testează BigData și ce necesită testarea tuturor lucrurilor în BigData?

Pentru testarea BigData, trebuie să avem câteva planuri și strategii.

Astfel, trebuie să luăm în considerare următoarele puncte:

  • Care este strategia sau planul de testare pentru BigData?
  • Ce fel de abordări de testare sunt aplicate BigData?
  • Care este mediul necesar?
  • Cum se validează și se verifică BigData?
  • Care sunt instrumentele utilizate în testarea BigData?

Să încercăm să obținem răspunsurile la toate întrebările de mai sus.

Care este strategia sau planul pentru testarea BigData?

Testarea BigData înseamnă verificarea și validarea datelor în timp ce le stocați și le prelucrați în Data Warehouse.

În timp ce testăm BigData, trebuie să testăm volumul și varietatea datelor extrase din diferite baze de date și încărcate, precum și procesate pe Data Warehouse sau Hadoop System, aceste teste intră sub testare funcțională.

Trebuie să testăm viteza datelor descărcate din diferite baze de date și încărcate în sistemul Hadoop, care face parte din testarea performanței.

Deci, ca plan sau strategie, trebuie să ne concentrăm atât pe funcționalitatea, cât și pe testarea performanței testelor BigData.

În testarea BigData, testerul trebuie să verifice prelucrarea unei cantități uriașe de date utilizând hardware de marfă și componente relative. Prin urmare, calitatea datelor joacă, de asemenea, un rol important în testarea BigData. Este esențial să verificați și să validați calitatea datelor.

Tipuri de testare pentru testarea BigData

În secțiunea anterioară, am văzut că testarea funcțională și testarea performanței joacă un rol vital în testarea BigData, în afară de asta ca tester BigData, trebuie să mai facem câteva tipuri de testare, cum ar fi testarea bazelor de date, precum și testarea arhitecturală.

Aceste tipuri de testare sunt, de asemenea, la fel de importante ca testele funcționale și de performanță.

# 1) Testare arhitecturală

Această testare se face pentru a se asigura că prelucrarea datelor este adecvată și îndeplinește cerințele. De fapt, sistemul Hadoop procesează volume imense de date și este extrem de cuprinzător de resurse.

Dacă arhitectura este necorespunzătoare, atunci aceasta poate degrada performanța din cauza căreia prelucrarea datelor se poate întrerupe și poate apărea pierderea datelor.

# 2) Testarea bazei de date

Aici, validarea procesului intră în imagine și trebuie să validăm datele din diferite baze de date, adică trebuie să ne asigurăm că datele preluate din bazele de date sursă sau bazele de date locale trebuie să fie corecte și corecte.

De asemenea, trebuie să verificăm dacă datele disponibile în bazele de date sursă sunt potrivite cu datele introduse în Hadoop System.

Testarea bazei de date

În mod similar, trebuie să validăm dacă datele din sistemul Hadoop sunt corecte și corecte după procesare sau spunem după transformare și pentru a fi încărcate în mediul clientului cu validare și verificare corespunzătoare.

Ca parte a testării bazelor de date, trebuie să parcurgem CRUD operațiuni adică Crea datele din bazele de date locale atunci Recupera datele și trebuie să le căutăm și ar trebui să fie disponibile în baza de date înainte și după încărcare în Data Warehouse și de la Data Warehouse la mediul clientului.

Verificarea oricărui Actualizat Date despre fiecare etapă de stocare sau încărcare și prelucrare a datelor. Ștergerea oricăror date corupte sau a oricăror date duplicate și nule.

# 3) Testarea performanței

Ca parte a testării performanței, trebuie să verificăm viteza de încărcare și procesare a datelor, adică IOPS (intrare pe secundă).

Trebuie să verificați viteza de introducere a datelor sau a datelor ca intrare de la diverse baze de date la Data Warehouse sau Hadoop System și de la Hadoop System sau Data Warehouse la Client’s Environment.

Trebuie, de asemenea, să verificați viteza datelor provenite din diferite baze de date și din Data Warehouse ca ieșire. Aceasta este ceea ce numim Input Output Per Second sau IOPS.

În afară de asta, un alt aspect este verificarea performanței absorbției și distribuției datelor și cât de repede sunt consumate datele de către Data Warehouse din diferite baze de date și de sistemul clientului din sistemul Hadoop.

De asemenea, în calitate de Tester, trebuie să verificăm performanța distribuției de date, precum, cât de repede sunt distribuite datele în diferite fișiere disponibile în sistemul Hadoop sau în Data Warehouse. În mod similar, același proces se întâmplă la distribuirea datelor către sistemele client.

Sistemul Hadoop sau Data Warehouse constă din mai multe componente, astfel încât un Tester trebuie să verifice performanța tuturor acelor componente, cum ar fi MapReduce Jobs, inserarea și consumul de date, timpul de răspuns al interogărilor și performanța acestora, precum și performanța căutării operațiuni. Toate acestea sunt incluse în Testarea performanței.

# 4) Testarea funcțională

Testarea funcțională conține testarea tuturor componentelor secundare, a programelor și scripturilor, a instrumentelor utilizate pentru efectuarea operațiunilor de stocare, încărcare și procesare etc.

Pentru un Tester, acestea sunt cele patru tipuri și etape importante prin care datele trebuie filtrate, astfel încât clientul să obțină datele perfecte și fără erori.

Instrumente pentru testarea BigData Hadoop

Există diverse instrumente care sunt utilizate pentru testarea BigData:

  • Sistem de fișiere de distribuție Hadoop HDFS pentru stocarea BigData.
  • Reducere hartă HDFS pentru procesarea BigData.
  • Pentru NoSQL sau HQL Cassandra DB, ZooKeeper și HBase etc.
  • Instrumente de server bazate pe cloud, cum ar fi EC2.

Medii și setări de testare

Pentru orice tip de testare, Tester-ul are nevoie de setări și mediu adecvat.

Mai jos este lista cerințelor:

  1. Tipul de date și aplicația care urmează să fie testate.
  2. Stocarea și procesarea necesită un spațiu mare pentru o cantitate imensă de date.
  3. Distribuirea corectă a fișierelor pe toate nodurile de date în general în cluster.
  4. În timpul procesării datelor, utilizarea hardware-ului ar trebui să fie minimă.
  5. Rulează programele și scripturile conform cerințelor aplicației.

Rolurile și responsabilitățile testării Hadoop

În calitate de Tester Hadoop, suntem responsabili pentru înțelegerea cerințelor, pregătirea estimărilor de testare, planificarea probelor, obținerea unor date de testare pentru testarea unor teste, implicarea în crearea patului de testare, executarea planurilor de testare, raportarea și testarea defectelor.

De asemenea, trebuie să fim responsabili pentru raportarea zilnică a stării și finalizarea testelor.

Rolurile și responsabilitățile testării Hadoop

Primul lucru pe care îl vom discuta este Strategia de testare . Odată ce avem o soluție propusă pentru problema noastră, trebuie să mergem mai departe și să planificăm sau să planificăm strategia planului nostru de testare, putem discuta strategia de automatizare pe care o putem folosi acolo, planul despre programul de testare care depinde de datele noastre de livrare, de asemenea, noi poate discuta despre planificarea resurselor.

Strategia de automatizare este ceva care ne va ajuta să reducem eforturile manuale necesare testării produsului. Programul de testare este important deoarece va asigura livrarea la timp a produsului.

Planificarea resurselor va fi crucială, deoarece trebuie să planificăm cât de multe ore de muncă avem nevoie pentru testare și cât de multe resurse Hadoop sunt necesare pentru a executa planificarea noastră de testare.

Odată ce ne-am strategizat testarea, trebuie să mergem mai departe și să creăm planuri de dezvoltare a testelor care includ crearea de planuri de testare, crearea de scripturi de testare care ne vor ajuta să ne automatizăm testarea și, de asemenea, să identificăm unele date de testare care urmează să fie utilizate în planurile de testare. și ne ajută să executăm acele planuri de testare.

Odată ce am terminat cu dezvoltarea testului care include crearea planurilor de testare, scripturi de testare și date de testare, mergem mai departe și începem să executăm acele planuri de testare.

Când executăm planurile de testare, ar putea exista anumite scenarii în care rezultatul real nu este așa cum era de așteptat, iar aceste lucruri sunt numite defecte. Ori de câte ori există un defect, trebuie să testăm și aceste defecte și trebuie să creăm și să menținem matricile pentru acestea.

Toate aceste lucruri se încadrează în următoarea categorie, care este Gestionarea defectelor .

Ce este gestionarea defectelor?

Gestionarea defectelor constă în urmărirea erorilor, remedierea erorilor și verificarea erorilor. Ori de câte ori un Plan de testare este executat împotriva oricărui produs pe care îl avem și de îndată ce este identificat un anumit bug sau este identificat un defect, acel defect trebuie raportat dezvoltatorului sau atribuit dezvoltatorului.

Deci dezvoltatorul poate analiza și începe să lucreze la el. În calitate de Tester, trebuie să urmărim progresul bugului și să urmărim dacă bug-ul a fost remediat. Dacă eroarea a fost remediată așa cum a fost raportat, atunci trebuie să mergem mai departe și să o testăm din nou și să verificăm dacă este rezolvată.

Odată ce toate erorile sunt remediate, închise și verificate, trebuie să mergem mai departe și să livrăm un produs testat OKAY. Dar, înainte de a livra produsul, trebuie să ne asigurăm că UAT (User Acceptance Testing) este finalizat cu succes.

Ne asigurăm că testarea instalării și verificarea cerințelor sunt efectuate corect, adică produsul livrat clientului sau utilizatorului final este conform cerinței menționate în Documentul de cerințe software.

Pașii pe care i-am discutat se bazează pe imaginație, fie pe oricare dintre scenariile de testare sau pe oricare dintre abordările de testare pe care urmează să le folosim pentru acești pași sau spuneți acele fraze pentru a testa produsul nostru și pentru a furniza rezultatul final, care este un Produs testat OKAY.

Să mergem mai departe și să discutăm acest lucru în detaliu și să-l corelăm cu testarea Hadoop.

Știm că Hadoop este ceva care este utilizat pentru procesarea în lot și știm, de asemenea, că ETL este unul dintre domeniile în care Hadoop este folosit foarte mult. ETL înseamnă Extraction Transformare și încărcare . Vom discuta în detaliu aceste procese atunci când vom discuta despre Planul de testare și Strategia de testare ca punct de vedere al testării Hadoop.

Conform diagramei menționate mai jos, presupunem doar că avem patru surse de date diferite. Sistem operațional, CRM ( Managementul relatiilor cu clientii ) și ERP ( planificarea resurselor intreprinderii ) este RDBMS sau spuneți sistemul de gestionare a bazelor de date relaționale pe care îl avem și avem, de asemenea, o grămadă de fișiere plate, care poate jurnalele, fișierele, înregistrările sau orice altceva în ceea ce privește sursele noastre de date.

Este posibil să folosim Sqoop sau Flume sau orice alt produs special pentru a obține datele, înregistrările sau orice altceva ca surse de date. Putem folosi aceste instrumente pentru a obține datele din Surse de date în directorul meu de etapizare, care este prima fază a procesului nostru numită Extracţie.

Odată ce directorul de date din etapă care se întâmplă să fie HDFS (Hadoop Distribution File System), vom folosi în special limbajul de scriptare, cum ar fi PIG pentru a Transforma acele Date. Acea Transformare va fi conform datelor pe care le avem.

Odată ce datele sunt transformate corespunzător folosind orice tehnologie de scriptare pe care o avem, vom fi Se încarcă acele date în Data Warehouse. Din Data Warehouse, aceste date vor fi utilizate pentru analiza OLAP, raportare și extragerea datelor sau pentru Analytics.

Să mergem mai departe și să discutăm ce faze putem folosi pentru testarea Hadoop.

Prima fază va fi faza de extracție. Aici, vom obține datele din bazele noastre de date sursă sau din fișierele plate și, în acest caz, ceea ce putem face este să putem verifica dacă toate datele au fost copiate cu succes și corect din sursă în directorul de etapizare.

Poate include, verificarea numărului de înregistrări, tipul înregistrărilor și tipul câmpurilor etc.

Odată ce aceste date sunt copiate în Directorul de etapizare, vom continua și vom declanșa a doua fază, care este Transformarea. Aici, vom avea unele logici de afaceri care vor acționa asupra datelor copiate din sistemele sursă și vor crea sau transforma datele în logica de afaceri necesară.

Transformarea poate include Sortarea datelor, Filtrarea datelor, Alăturarea datelor din două surse de date diferite și anumite alte operații.

Odată ce datele sunt transformate, vom continua și vom avea planurile de testare pregătite și vom verifica dacă obținem rezultatul așa cum era de așteptat și toate rezultatele obținute îndeplinesc rezultatul așteptat și tipurile de date, valorile câmpului și intervalele etc. sunt ceva care se încadrează la locul său.

Odată ce este corect, putem continua și încărca datele în Data Warehouse.

În faza de încărcare, verificăm de fapt dacă numărul de înregistrări din etapă și numărul de înregistrări din Data Warehouse sunt sincronizate, s-ar putea să nu fie similare, dar se presupune că sunt sincronizate. De asemenea, vedem dacă tipul de date care a fost transformat este sincronizat.

Afișați că vom folosi aceste date pentru analiza, raportarea și extragerea datelor OLAP, care este ultimul strat al produsului nostru și, în acest caz, putem avea ulterior sau putem spune că planurile de testare sunt disponibile pentru toate aceste straturi.

Ori de câte ori primim niște date de la sursă la destinație, atunci trebuie să ne asigurăm întotdeauna că numai persoanele autentificate au acces autorizat la date.

Autentificare

Autentificare

Autorizare

Autorizare

Ce înțelegem prin ambii termeni?

Pentru a înțelege acest lucru, să luăm lucrurile în perspectivă din Diagrama ETL.

ETL

Conform diagramei de mai sus, obținem datele de la motoarele RDBMS sursă și de la fișierele plate în HDFS, iar acea fază se numește Extracție.

Să discutăm autentificarea într-o manieră specială, există anumite companii care au date care sunt restricționate prin natura lor, acest tip de date se numește date PII conform standardelor Statelor Unite.

PII înseamnă Informații personale de identificare, orice informații precum Data nașterii, SSN, numărul de telefon mobil, adresa de e-mail și adresa casei etc. se încadrează toate în PII. Acest lucru este restricționat și nu poate fi distribuit tuturor.

Datele trebuie distribuite numai persoanelor care au avut cel mai mult nevoie de ele și celor care au nevoie de date pentru prelucrarea efectivă. Având această verificare și prima linie de apărare la locul său se numește autentificare.

De exemplu, folosim un laptop și avem Windows instalat acolo, este posibil să avem un cont de utilizator creat în sistemul nostru de operare Windows și acolo aplicăm o parolă.

În acest fel, numai persoana care are acreditările pentru acest cont de utilizator se poate conecta la sistem și astfel vom proteja datele noastre de furt sau acces inutil. Celălalt strat este Autorizare.

Exemplu, avem două conturi de utilizator diferite în sistemul nostru de operare Windows, un cont de utilizator este al nostru și altul ar putea fi contul de utilizator invitat. Administratorul (WE) are dreptul să facă tot felul de operațiuni, cum ar fi instalarea și dezinstalarea software-ului, crearea unui fișier nou și ștergerea fișierelor existente etc.

Pe de altă parte, este posibil ca utilizatorii oaspeți să nu aibă tot acest tip de acces. Invitatul are autentificare pentru a se conecta la sistem, dar nu are autoritatea de a șterge sau de a crea fișierele și instalarea, precum și dezinstalarea oricărui software din sistem și, respectiv, din sistem.

Cu toate acestea, contul de utilizator invitat din cauza autentificării are dreptul să citească fișierele create și să utilizeze software-ul care este deja instalat.

Acesta este modul în care sunt testate autentificarea și autorizarea, în acest caz, orice date disponibile în HDFS sau în oricare dintre sistemele de fișiere pe care trebuie să le verificăm pentru autentificare și autorizare a datelor.

Abordare de testare pentru testare Hadoop / testare BigData

Abordarea de testare

Abordarea de testare este obișnuită pentru toate tipurile de teste, nu numai pentru că este BigData sau Hadoop Testing atunci când mergem la Testarea manuală normală sau Testarea automatizării sau Testarea securității, Testarea performanței, de aceea orice tip de testare urmează aceeași abordare.

Cerințe

Ca parte a abordării de testare, trebuie să începem cu Cerințe , Cerința este un lucru de bază, în prezent, în procesul Agile, am numit-o Povești și Epopee. Epic nu este altceva decât o cerință mai mare, în timp ce povestirile sunt cerințe mai mici.

Cerința conține, în principiu, care sunt toate modelele de date, țintele, sursele, precum și ce tip de transformări trebuie să aplicăm, ce fel de instrumente trebuie să folosim? Toate aceste tipuri de detalii vor fi disponibile în Cerințe.

Aceasta este în esență Cerința Clientului sau Cerințele Clientului. Pe baza acestei cerințe, vom începe procesul de testare.

Estimare

O altă parte a abordării este Estimare , Cât timp avem nevoie pentru ca întreaga activitate să fie realizată ca parte a testării. Planificăm testarea, pregătim scenariile de testare, pregătim cazurile de testare și executăm aceleași, precum și vom găsi defecte și le vom raporta și vom pregăti și rapoarte de testare.

Toate aceste activități vor dura ceva timp, deci cât de mult timp avem nevoie pentru a finaliza toate aceste activități și aceasta se numește practic o estimare. Trebuie să oferim o estimare aproximativă conducerii.

Planificarea testelor

Planificarea testelor nu este altceva decât descrierea despre procese, ce să testați, ce să nu testați, care este domeniul de aplicare al testării, care sunt programele, câte resurse sunt necesare, cerințele hardware și software și care sunt calendarele, precum și ciclurile de testare vor fi utilizate, care sunt nivelurile de testare necesare, etc.

În timpul planificării testului, aceștia vor face anumite alocări de resurse pentru proiect și care sunt diferitele modele pe care le avem, câte resurse sunt necesare și ce fel de seturi de competențe sunt necesare etc. toate aceste lucruri și aspecte vor fi incluse în test Faza de planificare.

De cele mai multe ori, nivelul de conducere sau nivelul de management vor face planificarea testului.

Testarea scenariilor și cazurile de testare

Odată ce am terminat planificarea testului, trebuie să ne pregătim Scenarii de testare și cazurile de testare , în special pentru testarea Big Data, avem nevoie de câteva documente împreună cu documentul de cerință. Împreună cu acest document de cerință, de ce avem nevoie?

Avem nevoie de Document de cerință care conține nevoile Clientului, împreună cu acesta avem nevoie de Intrare document adică Modele de date. Model de date în sensul care este schemele de baze de date, care sunt tabelele și care sunt relațiile, toate aceste date vor fi disponibile în modelele de date.

De asemenea, avem Cartarea documentelor , Cartografierea documentelor pentru De exemplu. în bazele de date relaționale avem câteva tabele și după încărcarea datelor prin ETL în Data Warehouse în HDFS, ce sunt toate mapările pe care trebuie să le facem? adică tipul de date de cartografiere.

tcp ip întrebări și răspunsuri la interviu pdf

De exemplu, dacă avem un tabel al clientului în HDFS, atunci în HDFS avem un tabel CUSTOMER_TARGET sau același tabel poate fi și în HIVE.

Cartografierea datelor

În acest Tabel pentru clienți, avem anumite coloane, iar în Tabelul ȚINTĂ CLIENT, avem anumite coloane așa cum se arată în diagramă. Am aruncat datele din Tabelul clienților în Tabelul ȚINTĂ CLIENT, adică Sursă în țintă.

Apoi, trebuie să verificăm maparea exactă, cum ar fi datele prezente în tabelul sursă, care este coloana 1 și rândul 1 al tabelului clientului și îl consideră C1R1 și aceleași date ar trebui să fie mapate în C1R1 din tabelul TARGET CUSTOMER. Aceasta se numește practic Cartografiere.

Cum vom ști, care sunt toate mapările pe care trebuie să le verificăm? Deci, aceste mapări vor fi prezente în documentul de cartografiere. În documentul de cartografiere, Clientul va oferi tot felul de mapări.

De asemenea, am solicitat o Document de proiectare , Document de proiectare necesar atât pentru echipa de dezvoltare, cât și pentru echipa QA, deoarece în documentul de proiectare va furniza clientul, ce fel de joburi de reducere a hărții urmează să implementeze și ce tip de joburi de la MapReduce ia intrări și ce tip de MapReduce Locurile de muncă oferă rezultate.

În mod similar, dacă avem HIVE sau PIG, care sunt toate UDF-urile pe care le-a creat Clientul, precum și care sunt toate intrările pe care le vor lua și ce tip de ieșire vor produce etc.

Pentru a pregăti scenarii de testare și cazuri de testare, trebuie să avem toate aceste documente de mână:

  • Document de cerință
  • Model de date
  • Document de cartografiere
  • Document de proiectare

Acestea pot varia de la o organizație la alta și nu există o regulă obligatorie conform căreia trebuie să avem toate aceste documente. Uneori avem toate documentele și alteori avem doar două sau trei documente sau uneori trebuie să ne bazăm și pe un singur document, care depinde de complexitatea proiectului, programele companiei și orice altceva.

Recenzii privind scenariile de testare și cazurile de testare

Trebuie să efectuăm o revizuire a scenariilor de testare și a cazurilor de testare, deoarece cumva sau în unele cazuri uităm sau ne lipsesc unele cazuri de testare, deoarece toată lumea nu se poate gândi la toate lucrurile posibile care pot fi făcute cu cerințele, în astfel de condiții trebuie să luăm ajutor de la instrumentele terță parte sau de la altcineva.

Deci, ori de câte ori pregătim niște documente sau efectuăm ceva, atunci avem nevoie de cineva care să revizuiască lucrurile de la aceeași echipă, cum ar fi dezvoltatorii, testerii. Vor oferi sugestii adecvate pentru a include ceva mai mult sau, de asemenea, vor sugera actualizarea sau modificarea scenariilor de testare și a cazurilor de testare.

Acestea oferă toate comentariile și, pe baza acestora, vom actualiza scenariile și cazurile de testare și mai multe versiuni ale documentului pe care trebuie să le lansăm în întreaga echipă până când documentul este complet actualizat conform cerințelor.

Executarea testului

Odată ce documentul este gata, vom primi semnarea de la echipa superioară pentru a începe procesul de execuție care se numește practic Execuția cazului de testare.

Dacă vrem să executăm cazurile noastre de test în timpul execuției, trebuie să verificăm dacă dezvoltatorul trebuie să trimită informațiile, dacă este normal Testarea funcțională sau alte teste sau teste de automatizare, avem nevoie de o versiune de construcție. Dar, aici, din punct de vedere al testării Hadoop sau BigData, dezvoltatorul va furniza MapReduce Jobs.

Fișiere HDFS - orice fișiere care sunt copiate în HDFS, aceste informații despre fișiere sunt necesare pentru a verifica privilegiile, scripturile HIVE care au fost create de dezvoltatori pentru a verifica datele din tabelul HIVE și, de asemenea, avem nevoie de UDF-urile HIVE care au fost dezvoltate de dezvoltatori, PIG Scripturi și UDF PIG.

Acestea sunt toate lucrurile pe care trebuie să le obținem de la dezvoltatori. Înainte de a merge la execuție ar trebui să avem toate aceste lucruri.

Pentru MapReduce Jobs, acestea vor furniza unele fișiere JAR și ca parte a HDFS au încărcat deja datele în HDFS, iar fișierele ar trebui să fie gata și Scripturi HIVE pentru a valida datele din tabelele HIVE. Indiferent de UDF pe care l-au implementat va fi disponibil în UDF’s HIVE. Avem nevoie de același lucru și pentru scripturile PIG și UDF.

Raportarea și urmărirea defectelor

Odată ce ne executăm cazurile de testare, găsim unele defecte, unele așteptate și altele reale nu sunt egale cu rezultatele așteptate, așa că trebuie să le listăm și să le furnizăm echipei de dezvoltare pentru rezolvare, iar acest lucru se numește practic Raportarea defectelor.

Să presupunem că dacă găsim un defect în jobul MapReduce, atunci îl vom raporta dezvoltatorului și vor recrea din nou jobul MapReduce și vor face unele modificări ale nivelului de cod și vor furniza din nou cel mai recent job MapReduce, pe care trebuie să îl testăm .

Acesta este un proces continuu, odată ce lucrarea este testată și trecută, trebuie din nou să o testăm din nou și să o raportăm dezvoltatorului și apoi să o luăm pe următoarea pentru testare. Astfel se realizează activitatea de raportare și urmărire a defectelor.

Rapoarte de testare

Odată ce am terminat tot procesul de testare și defectele au fost închise, atunci trebuie să ne creăm rapoartele de testare. Rapoartele de testare sunt tot ceea ce am făcut pentru a finaliza procesul de testare până acum. Toate planificarea, scrierea și executarea cazurilor de testare, ce rezultat am obținut, etc. totul este documentat împreună sub formă de rapoarte de testare.

Trebuie să trimitem aceste rapoarte zilnic sau săptămânal sau conform nevoilor clientului. În prezent, organizațiile folosesc modelul AGILE, astfel încât fiecare raport de stare trebuie actualizat în timpul Daily Scrums.

Concluzie

În acest tutorial, am parcurs:

  • Strategia sau planul de testare a BigData.
  • Mediu necesar pentru testarea BigData.
  • Validare și verificări BigData.
  • Instrumente utilizate în testarea BigData.

De asemenea, am aflat despre -

  • Cum funcționează strategia de testare, dezvoltarea testelor, execuțiile testelor, gestionarea defectelor și livrarea în roluri și responsabilități ca parte a testării Hadoop.
  • Abordare de testare pentru testarea Hadoop / BigData, care include colectarea cerințelor, estimarea, planificarea testelor, crearea scenariilor de testare și cazurile de testare împreună cu recenziile.
  • De asemenea, am aflat despre execuția testelor, raportarea și urmărirea defectelor și raportarea testelor.

Sperăm că acest tutorial de testare BigData ți-a fost de ajutor!

=> Verificați TOATE Tutorialele BigData aici.

Lectură recomandată

^