Meni

Sveobuhvatan vodič za testiranje Hadoop-a | Vodič za testiranje velikih podataka

  • Glavni
  • Ostalo
  • Sveobuhvatan vodič za testiranje Hadoop-a | Vodič za testiranje velikih podataka

comprehensive hadoop testing tutorial big data testing guide

Isprobajte Naš Instrument Za Uklanjanje Problema

Ovaj vodič objašnjava osnove, vrste ispitivanja, planove, potrebno okruženje, postupak testiranja, provjeru valjanosti i provjere za testiranje Hadoop-a i BigData:

U ovom uputstvu vidjet ćemo osnovni uvod u testiranje Hadoop-a i BigData, poput vremena i mjesta testiranja te što trebamo testirati kao dio testiranja Hadoop-a.

Također ćemo detaljno razgovarati o sljedećim temama:

  • Uloge i odgovornosti Hadoop testiranja
  • Pristup testiranju za testiranje Hadoop / BigData

=> Ovdje pogledajte kako biste ovdje vidjeli A-Z vodiča za obuku za BigData.

Uvod u BigData i Hadoop testiranje

Što ćete naučiti:

Pohranjivanje i obrada podataka u Hadoopu

Da bismo izvršili ove procese na sustavu Hadoop, imamo radnu snagu koja je kategorizirana u četiri odjeljka.

  • Administratori Hadoopa odgovorni su za postavljanje okoliša i imaju administratorska prava za pristup sustavima Hadoop.
  • Programeri Hadoop razviti programe koji se odnose na izvlačenje, spremanje i obradu podataka s različitih mjesta na centralizirana mjesta.
  • Hadoop testeri za provjeru valjanosti i provjeru podataka prije povlačenja s različitih lokacija i nakon povlačenja na centraliziranom mjestu, kao i provjeru valjanosti i provjeru vrši se tijekom učitavanja podataka u klijentsko okruženje.
  • Hadoop analitičari rade kad se izvrši učitavanje podataka i kada podaci dođu do skladišta na mjestu klijenta. Te podatke koriste za generiranje izvješća i nadzorne ploče. Analitičari provode analizu podataka za rast i poslovni razvoj.

Znamo da Hadoop nije jedinstveni sustav; sadrži više sustava i strojeva. Podaci se dijele i pohranjuju u više strojeva, a ako im želimo ponovno pristupiti, moramo kombinirati i povući podatke u izvješća i tako dalje.

Programer je odgovoran za pisanje programa na JAVA-i i Pythonu za izdvajanje podataka i njihovo spremanje.

Drugi posao programera je obrada podataka. Postoje dva sloja Hadoopa, jedan je za pohranu tj. Hadoop HDFS, a drugi za obradu tj. Hadoop MapReduce.

Pohranjivanje znači da se podaci koje imamo u izvoru samo pohrane / ubace u sustav. Obrada znači da ga moramo podijeliti na više strojeva i opet kombinirati i poslati klijentu.

Dakle, pohrana i obrada obavljaju se programskim skriptama, a programer je odgovoran za pisanje skripti.

Osim programiranja, druga metoda za pohranu i obradu podataka u Hadoopu je upotreba aplikacija baza podataka poput Hive, Impala, HBase, itd. Ovim alatima nije potrebno nikakvo programsko znanje.

BigData i Hadoop testiranje

Jednom kada programer izvrši pohranu i obradu, podaci idu u generiranje izvješća. Prije toga trebamo provjeriti točnost obrađenih podataka i provjeriti jesu li podaci točno učitani i ispravno obrađeni ili ne.

Dakle, program i / ili skripte koje je stvorio programer moraju biti provjereni od strane Hadoop ili BigData Tester. Tester mora znati osnovno programiranje kao što su Mapper, Hive, Pig Scripts, itd. Da bi provjerio skripte i izvršio naredbe.

Dakle, prije testiranja testeri moraju znati koji svi programi i skripte rade, kako napisati kod, a zatim razmisliti kako ih testirati. Testiranje se može obaviti ručno ili pomoću alata za automatizaciju.

Hadoop ima razne vrste testiranja poput jediničnog, regresijskog, sistemskog i izvedbenog testiranja itd. Dakle, to su uobičajene vrste testiranja koje koristimo u našem uobičajenom testiranju, kao i Hadoop i BigData testiranje.

Imamo iste vrste terminologija testiranja kao što su strategija testiranja, scenariji testiranja i test slučajevi, itd. U Hadoop i BigData Testing. Samo je okruženje različito i postoje različite vrste tehnika koje koristimo za testiranje sustava BigData i Hadoop jer ovdje moramo testirati podatke, a ne aplikaciju.

Kako testirati BigData i što sve zahtijeva testiranje u BigData?

Za BigData testiranje moramo imati neke planove i strategije.

Stoga moramo uzeti u obzir sljedeće točke:

  • Koja je strategija ili plan testiranja za BigData?
  • Kakvi se pristupi testiranju primjenjuju na BigData?
  • Koja je okolina potrebna?
  • Kako provjeriti i potvrditi BigData?
  • Koji su alati koji se koriste u BigData testiranju?

Pokušajmo dobiti odgovore na sva gore navedena pitanja.

Koja je strategija ili plan za testiranje BigData?

BigData testiranje znači provjeru i provjeru valjanosti podataka tijekom spremanja i obrade u skladište podataka.

Tijekom testiranja BigData, moramo testirati količinu i raznolikost podataka izvučenih iz različitih baza podataka i učitanih kao i obrađenih u Data Warehouseu ili Hadoop sustavu, ovo testiranje podliježe funkcionalnom testiranju.

Moramo testirati brzinu podataka preuzetih iz različitih baza podataka i učitanih u sustav Hadoop, koji je dio ispitivanja performansi.

Dakle, kao plan ili strategija, moramo se usredotočiti na funkcionalno, kao i na testiranje performansi BigData testiranja.

U BigData testiranju, ispitivač mora potvrditi obradu ogromne količine podataka pomoću robnog hardvera i relativnih komponenti. Stoga kvaliteta podataka također igra važnu ulogu u testiranju BigData. Bitno je provjeriti i potvrditi kvalitetu podataka.

Vrste testiranja za BigData testiranje

U prethodnom smo odjeljku vidjeli da funkcionalno testiranje i ispitivanje performansi igraju vitalnu ulogu u testiranju BigData, osim onog kao BigData testera, moramo obaviti još nekoliko vrsta testiranja poput testiranja baze podataka i arhitektonskog testiranja.

Ove su vrste ispitivanja jednako važne kao i ispitivanje funkcionalnosti i performansi.

# 1) Arhitektonsko ispitivanje

Ovo se ispitivanje vrši kako bi se osiguralo da je obrada podataka pravilna i udovoljava zahtjevima. Zapravo, sustav Hadoop obrađuje ogromne količine podataka i izuzetno je sveobuhvatan.

Ako je arhitektura neispravna, to može pogoršati performanse zbog kojih se obrada podataka može prekinuti i može doći do gubitka podataka.

# 2) Ispitivanje baze podataka

Ovdje validacija procesa dolazi u sliku i moramo provjeriti valjanost podataka iz različitih baza podataka, tj. Moramo osigurati da podaci dohvaćeni iz izvornih baza podataka ili lokalnih baza podataka moraju biti ispravni i ispravni.

Također, moramo provjeriti podudaraju li se podaci dostupni u izvornim bazama podataka s podacima unesenim u sustav Hadoop.

Ispitivanje baze podataka

Slično tome, moramo provjeriti jesu li podaci u sustavu Hadoop točni i ispravni nakon obrade ili recimo nakon transformacije te da li se učitavaju u klijentovo okruženje uz odgovarajuću provjeru valjanosti i provjere.

Kao dio testiranja baze podataka, moramo proći kroz Surovo operacije tj. Stvoriti tada podaci u Lokalnim bazama podataka Dohvati podatke i trebamo ih pretražiti, a trebali bi biti dostupni u Bazi podataka prije i nakon učitavanja u Skladište podataka i iz Skladišta podataka u Klijentovo okruženje.

Provjera bilo kojeg Ažurirano Podaci o svakoj fazi pohrane ili učitavanja i obrade podataka. Brisanje oštećenih podataka ili dupliciranih i nevaljanih podataka.

# 3) Ispitivanje performansi

Kao dio ispitivanja performansi, moramo provjeriti brzinu učitavanja i obrade podataka, tj. Poput IOPS-a (ulazni izlaz u sekundi).

Trebate provjeriti brzinu unosa podataka ili podataka kao ulaz iz različitih baza podataka u skladište podataka ili sustav Hadoop i iz sustava Hadoop ili skladište podataka u klijentovo okruženje.

Također morate provjeriti brzinu podataka koji dolaze iz različitih baza podataka i iz skladišta podataka kao izlaz. To nazivamo ulaznim izlazom u sekundi ili IOPS-om.

Osim toga, drugi aspekt je provjera performansi apsorpcije podataka i distribucije podataka te brzine potrošnje podataka iz skladišta podataka iz različitih baza podataka i klijentskog sustava iz sustava Hadoop.

Također kao ispitivač, moramo provjeriti izvedbu Distribucije podataka poput brzine distribucije podataka u razne datoteke dostupne u sustavu Hadoop ili u skladištu podataka. Slično tome, isti se postupak događa tijekom distribucije podataka klijentskim sustavima.

Sustav Hadoop ili skladište podataka sastoji se od više komponenti, pa ispitivač treba provjeriti izvedbu svih tih komponenata poput MapReduce poslova, umetanja i potrošnje podataka, vremena odziva upita i njihove performanse, kao i izvedbu pretraživanja operacijama. Sve je to uključeno u ispitivanje performansi.

# 4) Funkcionalno ispitivanje

Funkcionalno testiranje sadrži testiranje svih potkomponenata, programa i skripti, alata koji se koriste za izvođenje operacija pohrane ili učitavanja i obrade, itd.

Za ispitivača to su četiri važne vrste i faze kroz koje se podaci moraju filtrirati kako bi klijent dobio savršene podatke bez pogrešaka.

Alati za BigData Hadoop testiranje

Postoje različiti alati koji se koriste za testiranje BigData:

  • HDFS sustav distribucije datoteka Hadoop za pohranu BigData.
  • Smanjenje HDFS mape za obradu BigData.
  • Za NoSQL ili HQL Cassandra DB, ZooKeeper i HBase itd.
  • Poslužni alati zasnovani na oblaku poput EC2.

Testiranje okruženja i postavki

Za bilo koju vrstu testiranja, ispitivač treba odgovarajuće postavke i okruženje.

Slijedi popis zahtjeva:

  1. Vrsta podataka i aplikacija koja će se testirati.
  2. Pohranjivanje i obrada zahtijeva velik prostor za ogromnu količinu podataka.
  3. Pravilna distribucija datoteka na svim DataNodes-ima u cjelini klastera.
  4. Tijekom obrade podataka, upotreba hardvera trebala bi biti minimalna.
  5. Programi i skripte koji se mogu pokrenuti prema zahtjevu aplikacije.

Uloge i odgovornosti Hadoop testiranja

Kao ispitivač Hadoop-a, odgovorni smo za razumijevanje zahtjeva, pripremamo procjene ispitivanja, planiranje test-slučajeva, pribavimo neke podatke o testiranju za testiranje nekih test-slučajeva, sudjelujemo u stvaranju ispitnog ležišta, izvršavanju testnih planova, izvještavanju i ponovnom testiranju nedostataka.

Također, moramo biti odgovorni za svakodnevno izvještavanje o statusu i završetak ispitivanja.

Uloge i odgovornosti Hadoop testiranja

Prvo o čemu ćemo razgovarati je Strategija ispitivanja . Jednom kad predložimo rješenje za naš problem, trebamo krenuti u planiranje ili strategiju plana testiranja, možemo razgovarati o strategiji automatizacije koju tamo možemo koristiti, planu o rasporedu ispitivanja koji ovisi o datumima isporuke, također mogu razgovarati o planiranju resursa.

Strategija automatizacije je nešto što će nam pomoći u smanjenju ručnih napora potrebnih za testiranje proizvoda. Raspored ispitivanja važan je jer će osigurati pravovremenu isporuku proizvoda.

Planiranje resursa bit će presudno jer moramo planirati koliko radnih sati trebamo u našem testiranju i koliko je resursa Hadoop potrebno za izvršenje našeg planiranja ispitivanja.

Jednom kada strategiramo testiranje, moramo krenuti i stvoriti planove za razvoj testova koji uključuju izradu planova za testiranje, izradu skripti za test koji će nam pomoći da automatiziramo testiranje i identificirati neke podatke o testiranju koji će se koristiti u planovima za testiranje. i pomaže nam u izvršavanju tih testnih planova.

Nakon što završimo s testnim razvojem koji uključuje stvaranje testnih planova, testnih skripti i testnih podataka, nastavljamo i započinjemo s izvršavanjem tih testnih planova.

Kada izvršimo testne planove, mogu postojati određeni scenariji u kojima stvarni izlaz nije onakav kakav se očekivao, a te se stvari nazivaju nedostacima. Kad god postoji nedostatak, moramo testirati i te nedostatke te moramo stvoriti i održavati matrice za njih.

Sve ove stvari spadaju u sljedeću kategoriju koja je Upravljanje nedostacima .

Što je upravljanje nedostacima?

Upravljanje nedostacima sastoji se od praćenja grešaka, ispravljanja grešaka i provjere grešaka. Kad god se izvrši testni plan za bilo koji proizvod koji imamo i čim se utvrdi određena greška ili utvrdi nedostatak, tada se taj nedostatak mora prijaviti programeru ili dodijeliti programeru.

Tako da ga programer može pogledati i početi raditi na njemu. Kao ispitivač, moramo pratiti napredak Bug-a i pratiti je li Bug ispravljen. Ako je greška ispravljena kako je prijavljeno, trebamo je ponovno testirati i provjeriti je li riješena.

Nakon što se sve programske pogreške poprave, zatvore i provjere, trebamo nastaviti i isporučiti testirani proizvod OKAY. No, prije nego što isporučimo proizvod, moramo se pobrinuti da je UAT (User Acceptance Testing) uspješno dovršen.

Pazimo da su instalacijska ispitivanja i provjera zahtjeva izvršeni pravilno, tj. Proizvod koji se isporučuje klijentu ili krajnjem korisniku odgovara zahtjevu navedenom u dokumentu softverskog zahtjeva.

Koraci o kojima smo razgovarali temelje se na mašti, bilo da je riječ o bilo kojem od scenarija testiranja ili bilo kojem pristupu testiranja koji ćemo koristiti za te korake ili izgovoriti te fraze za testiranje našeg proizvoda i isporuku krajnjeg rezultata, što je OKAY Testirani proizvod.

Krenimo i detaljno raspravimo ovo i povežemo s Hadoop testiranjem.

Znamo da je Hadoop nešto što se koristi za skupnu obradu, a također znamo da je ETL jedno od polja u kojima se Hadoop puno koristi. ETL je kratica za ekstrakciju i transformaciju . O tim ćemo procesima detaljno razgovarati kada razgovaramo o planu ispitivanja i strategiji ispitivanja kao gledištu Hadoop testiranja.

Prema dolje spomenutom dijagramu, samo pretpostavljamo da imamo četiri različita izvora podataka. Operativni sustav, CRM ( Upravljanje odnosima s kupcima ) i ERP ( Planiranje resursa za poduzeća ) je RDBMS ili recimo Relacijski sustav za upravljanje bazama podataka koji imamo, a imamo i hrpu ravnih datoteka koje možda zapisuju, datoteke, zapise ili bilo što već u vezi s našim izvorima podataka.

Možda koristimo Sqoop ili Flume ili bilo koji određeni proizvod za dobivanje podataka, zapisa ili bilo čega drugog kao mojih izvora podataka. Te alate možemo koristiti za dobivanje podataka iz izvora podataka u moj direktorij za uspostavljanje, što je prva faza našeg procesa Izvlačenje.

Jednom kad podaci u njima budu postavljeni za direktorij koji se zapravo dogodi HDFS (Hadoop Distribution File System), posebno ćemo koristiti skriptni jezik kao što je PIG za Transformirati taj Podatak. Da Transformacija bit će prema podacima koje imamo.

Jednom kada se podaci transformiraju u skladu s bilo kojom tehnologijom skriptiranja koju imamo, to ćemo i učiniti Učitavam te podatke u skladište podataka. Iz skladišta podataka ti će se podaci koristiti za OLAP analizu, izvještavanje i rudarenje podataka ili za Analytics.

Krenimo dalje i razgovarajmo koje sve faze možemo koristiti za testiranje Hadoop-a.

Prva faza bit će faza ekstrakcije. Ovdje ćemo dobiti podatke iz naših Izvornih baza podataka ili iz Flat datoteka, a u tom slučaju, ono što možemo učiniti, možemo provjeriti jesu li svi podaci uspješno i ispravno kopirani iz izvora u Staging direktorij.

To može uključivati ​​provjeru broja zapisa, vrste zapisa i vrste polja itd.

Nakon što se ti podaci kopiraju u direktorij za uprizorenje, nastavit ćemo i pokrenuti drugu fazu koja je Transformacija. Ovdje ćemo imati neku poslovnu logiku koja će djelovati na kopirane podatke iz izvornih sustava i koja će zapravo stvoriti ili transformirati podatke u potrebnu poslovnu logiku.

Transformacija može uključivati ​​sortiranje podataka, filtriranje podataka, spajanje podataka iz dva različita izvora podataka i određene druge operacije.

Nakon što se podaci transformiraju, nastavit ćemo i pripremiti planove ispitivanja te ćemo provjeriti dobivamo li izlaz prema očekivanjima, a svi izlazi koje dobivamo ispunjavaju očekivani rezultat i vrste podataka, vrijednosti polja i dometi itd. nešto su što pada na svoje mjesto.

Nakon što je ispravno, možemo nastaviti s učitavanjem podataka u Skladište podataka.

U fazi učitavanja zapravo provjeravamo je li broj zapisa iz Stagea i broj zapisa u Skladištu podataka sinkroniziran, možda nisu slični, ali bi trebali biti sinkronizirani. Također vidimo je li vrsta podataka koji su transformirani sinkronizirana.

Objavi da ćemo ove podatke koristiti za OLAP analizu, izvještavanje i miniranje podataka, što je posljednji sloj našeg proizvoda, a u tom slučaju možemo imati naknadne ili možemo reći da su testni planovi dostupni za sve ove slojeve.

Kad god dobijemo neke podatke iz izvora na odredište, uvijek moramo osigurati da samo ovlaštene osobe imaju ovlašteni pristup podacima.

Ovjera

Ovjera

Ovlaštenje

Ovlaštenje

Što podrazumijevamo pod oba ova pojma?

Da bismo to razumjeli, pogledajmo stvari u perspektivu iz ETL dijagrama.

ETL

Prema gornjem dijagramu, podatke dobivamo iz izvornih RDBMS motora i iz ravnih datoteka u HDFS, a ta se faza naziva ekstrakcija.

Razgovarajmo o autentifikaciji na određeni način, postoje određene tvrtke koje imaju podatke koji su ograničeni zbog svoje prirode, ova vrsta podataka naziva se podacima koji otkrivaju identitet prema američkim standardima.

PII stoji za Osobni podaci koji mogu identificirati, sve informacije kao što su datum rođenja, SSN, broj mobitela, adresa e-pošte i adresa kuće, itd. sve spadaju u osobne podatke. Ovo je ograničeno i ne može se dijeliti sa svima.

Podatke treba dijeliti samo s osobama kojima su najpotrebniji i onima kojima su podaci potrebni za stvarnu obradu. Imajući ovu provjeru i postavljenu prvu liniju obrane naziva se Autentifikacija.

Na primjer, koristimo prijenosno računalo i tamo imamo instaliran sustav Windows, možda imamo kreiran neki korisnički račun u našem operacijskom sustavu Windows i tamo primjenjujemo lozinku.

Na taj se način samo osoba koja ima vjerodajnice za ovaj određeni korisnički račun može prijaviti u Sustav i na taj ćemo način zaštititi svoje podatke od krađe ili nepotrebnog pristupa. Drugi sloj je Autorizacija.

Primjer, u našem operacijskom sustavu Windows imamo dva različita korisnička računa, jedan je naš, a drugi bi mogao biti gost. Administrator (WE) ima pravo na sve vrste operacija, poput instalacije i deinstalacije softvera, izrade nove datoteke i brisanja postojećih datoteka itd.

S druge strane, gosti korisnici možda neće imati svu ovu vrstu pristupa. Gost ima provjeru autentičnosti za prijavu u sustav, ali nema ovlast brisati ili stvarati datoteke i instalaciju, kao i deinstalirati bilo koji softver u sustavu, odnosno iz sustava.

Međutim, gostujući korisnički račun zbog provjere autentičnosti ima pravo čitati stvorene datoteke i koristiti već instalirani softver.

Na ovaj se način provjeravaju autentičnost i autorizacija, u ovom slučaju, bilo koji podaci dostupni u HDFS-u ili bilo kojem datotečnom sustavu koji moramo provjeriti za autentifikaciju i autorizaciju podataka.

Pristup testiranju za Hadoop testiranje / BigData testiranje

Pristup testiranju

Pristup testiranju uobičajen je za sve vrste testiranja, ne samo zato što je to BigData ili Hadoop testiranje kada odemo na Uobičajeno ručno testiranje ili Automatsko testiranje ili sigurnosno testiranje, testiranje performansi, pa bilo koja vrsta testiranja slijedi isti pristup.

Zahtjevi

Kao dio pristupa ispitivanju, moramo započeti s Zahtjevi , Zahtjev je osnovna stvar, danas smo ga u Agile procesu nazivali Stories and Epics. Epsko je samo veći zahtjev, dok su Priče manji zahtjevi.

Zahtjev u osnovi sadrži koji su sve modeli podataka, ciljevi, izvori, kao i kakve transformacije trebamo primijeniti, kakve alate moramo koristiti? Sve ove vrste detalja bit će dostupne na Zahtjevima.

To su u osnovi zahtjevi klijenta ili zahtjevi kupca. Na temelju ovog zahtjeva započet ćemo postupak testiranja.

Procjena

Drugi dio pristupa je Procjena , Koliko vremena trebamo uzeti za to da se cjelokupna aktivnost izvrši kao dio testiranja. Izrađujemo planiranje ispitivanja, pripremamo scenarije ispitivanja, pripremamo ispitne slučajeve i izvršenje istih, kao i pronaći ćemo nedostatke, prijaviti ih i pripremiti izvješća o ispitivanju.

Sve će ove aktivnosti trebati neko vrijeme, pa koliko nam vremena treba za izvršavanje svih ovih aktivnosti i to se u osnovi naziva Procjena. Moramo dati grubu procjenu upravi.

Planiranje ispitivanja

Planiranje ispitivanja nije ništa drugo nego opis procesa, što testirati, što ne testirati, koji je opseg testiranja, koji su rasporedi, koliko je resursa potrebno, hardverski i softverski zahtjevi i koji su vremenski rokovi kao i ciklusi testiranja koristit će se, koje su razine ispitivanja potrebne itd.

Tijekom planiranja testa izvršit će određenu raspodjelu resursa za projekt i koji su različiti modeli koje imamo, koliko je resursa potrebno i kakvi su kompleti vještina potrebni itd. Sve ove stvari i aspekti bit će uključeni u test Faza planiranja.

Većinu vremena ljudi na razini vodstva ili na razini upravljanja obavljaju planiranje ispitivanja.

Testni scenariji i test slučajevi

Kad završimo s planiranjem ispitivanja, trebamo se pripremiti Testni scenariji i test slučajevi , posebno za testiranje velikih podataka, trebamo nekoliko dokumenata zajedno s dokumentom zahtjeva. Što sve trebamo uz ovaj dokument zahtjeva?

Trebamo Dokument zahtjeva koji sadrži potrebe klijenta, zajedno s tim trebamo i Ulazni dokument tj. Podatkovni modeli. Model podataka u smislu što su sheme baza podataka, koje su tablice i u kakvim su odnosima svi ovi podaci bit će dostupni u modelima podataka.

Također, imamo i Mapiranje dokumenata , Mapiranje dokumenata za Npr. u relacijskim bazama podataka imamo neke tablice, a nakon učitavanja podataka kroz ETL u skladištu podataka u HDFS-u, što sve moramo mapirati? tj. Mapiranje vrste podataka.

tehnička pitanja i odgovori na razgovor za pomoć

Na primjer, ako imamo tablicu kupca u HDFS-u, tada u HDFS-u imamo tablicu CUSTOMER_TARGET ili ista tablica može biti i u HIVE-u.

Mapiranje podataka

U ovoj tablici kupaca imamo određene stupce, au tablici CILJ ZA KUPCE imamo određene stupce kao što je prikazano na dijagramu. Podatke smo prebacili iz tablice kupaca u tablicu CILJ KUPACA, tj. Izvor na cilj.

Zatim moramo provjeriti točno mapiranje poput podataka prisutnih u izvornoj tablici, a to je stupac 1 i redak korisničke tablice i smatra ga C1R1, a isti bi podaci trebali biti mapirani u C1R1 tablice CILJNI CILJ. To se u osnovi naziva Mapiranje.

Kako ćemo znati, koja su sve preslikavanja koja moramo provjeriti? Dakle, ta će mapiranja biti prisutna u dokumentu za mapiranje. U dokumentu za mapiranje kupac će dati sve vrste mapiranja.

Također, zahtijevali smo a Projektni dokument , Projektni dokument potreban i za razvojni tim, kao i za QA tim, jer će u projektnom dokumentu kupac pružiti, kakvu vrstu Map Reduce poslova koje će implementirati i koja vrsta MapReduce poslova uzima ulaze i koju vrstu MapReduce Poslovi daju rezultate.

Slično tome, ako imamo HIVE ili PIG, što su sve UDF-ovi koje je kupac stvorio, kao i koje su sve ulazne podatke koje će uzeti i kakav će izlaz proizvesti itd.

Da bismo pripremili scenarije za testiranje i test slučajeve, trebamo imati sve ove dokumente na ruci:

  • Dokument zahtjeva
  • Model podataka
  • Mapiranje dokumenta
  • Projektni dokument

Oni se mogu razlikovati od jedne do druge organizacije i ne postoji obvezno pravilo da moramo imati sve ove dokumente. Ponekad imamo sve dokumente, a ponekad imamo samo dva ili tri dokumenta ili se ponekad moramo osloniti i na jedan dokument, to je do složenosti projekta, rasporeda tvrtki i svega.

Pregledi scenarija ispitivanja i test slučajeva

Moramo obaviti pregled testnih scenarija i test slučajeva, jer nekako ili u nekim slučajevima zaboravimo ili propustimo neke test slučajeve, jer svi ne mogu smisliti sve moguće stvari koje se mogu učiniti sa zahtjevima, u takvim uvjetima koje moramo poduzeti pomoć od alata treće strane ili od nekoga drugog.

Dakle, kad god pripremimo neke dokumente ili izvedemo nešto, trebamo nekoga da pregleda stvari iz istog tima, poput programera, testera. Oni će dati odgovarajuće prijedloge za uključivanje nečeg više ili također predložiti ažuriranje ili modificiranje testnih scenarija i test slučajeva.

Oni pružaju sve komentare i na temelju toga ažurirat ćemo naše scenarije testiranja i slučajeve ispitivanja te više verzija dokumenta koje trebamo objaviti u cijelom timu dok se dokument u potpunosti ne ažurira prema zahtjevu.

Izvršenje testa

Jednom kada je dokument spreman, dobit ćemo odjavu od gornjeg tima za započinjanje postupka izvršenja koji se u osnovi naziva Test Case Execution.

Ako želimo izvršiti svoje test slučajeve tijekom izvršenja, moramo provjeriti mora li programer poslati podatke, ako je to normalno funkcionalno testiranje ili neko drugo testiranje ili automatsko testiranje, trebamo izgradnju. Ali, ovdje s gledišta Hadoop ili BigData Testing, programer će pružiti MapReduce Jobs.

HDFS datoteke - bez obzira na datoteke koje se kopiraju u HDFS-u, potrebne su informacije o datotekama za provjeru privilegija, HIVE skripte koje su kreirali programeri za provjeru podataka u tablici HIVE, a također nam trebaju i HIVE UDF-ove koje su razvili programeri, PIG Skripte i PIG UDF-ovi.

To su sve stvari koje trebamo dobiti od programera. Prije odlaska na pogubljenje trebali bismo imati sve ove stvari.

Za MapReduce Jobs pružit će neke JAR datoteke, a kao dio HDFS-a već su učitali podatke u HDFS, a datoteke bi trebale biti spremne i HIVE skripte za provjeru podataka u tablicama HIVE. Kakvi god UDF-ovi bili implementirani, bit će dostupni u HIVE UDF-u. Zahtijevamo isto za PIG skripte i UDF-ove.

Izvještavanje i praćenje nedostataka

Jednom kada izvršimo test slučajeve, pronađemo neke nedostatke, neke očekivane, a neke stvarne nisu jednake očekivanim rezultatima, pa ih moramo navesti i dostaviti razvojnom timu na rješavanje, a to se u osnovi naziva Izvještavanje o nedostacima.

Pretpostavimo ako pronađemo neki nedostatak u zadatku MapReduce, tada ćemo ga prijaviti programeru, a oni će ponovno stvoriti zadatak MapReduce, izvršit će neke izmjene na razini koda, a zatim će pružiti najnoviji zadatak MapReduce koji moramo testirati .

To je trajni postupak, nakon što se posao testira i položi, trebamo ga ponovo testirati i prijaviti programeru, a zatim dobiti sljedeći na testiranje. Na ovaj se način postiže izvješćivanje i praćenje nedostataka.

Izvješća o ispitivanjima

Nakon što završimo sa svim postupkom ispitivanja i kad se nedostaci zatvore, moramo stvoriti naša izvješća o ispitivanju. Izvješća o ispitivanju sve su što smo do sada učinili kako bismo dovršili postupak testiranja. Sva planiranja, pisanje i izvršavanje testnih slučajeva, koji smo izlaz dobili itd. Sve je dokumentirano zajedno u obliku izvještaja o testiranju.

Ta izvješća moramo slati svakodnevno ili tjedno ili prema potrebama kupca. Danas organizacije koriste AGILE model, tako da se svako Izvješće o statusu mora ažurirati tijekom dnevnih obračuna.

Zaključak

U ovom uputstvu smo prošli kroz:

  • Strategija ili plan testiranja BigData.
  • Potrebno okruženje za BigData testiranje.
  • Provjera i provjera BigData.
  • Alati korišteni u testiranju BigData.

Također smo saznali o -

  • Kako strategija ispitivanja, razvoj testova, izvršavanja testova, upravljanje nedostacima i isporuka funkcioniraju u ulogama i odgovornostima kao dio Hadoop testiranja.
  • Pristup testiranju za testiranje Hadoop / BigData koji uključuje prikupljanje zahtjeva, procjenu, planiranje testa, stvaranje scenarija za testiranje i test slučajeva zajedno s pregledima.
  • Također smo saznali o izvršavanju testova, izvještavanju i praćenju kvarova te izvještavanju o testovima.

Nadamo se da vam je ovaj vodič za testiranje BigData bio od pomoći!

=> Ovdje provjerite SVE upute za BigData.

Preporučena literatura

^