comprehensive hadoop testing tutorial big data testing guide
Този урок обяснява основите, видовете тестове, плановете, необходимата среда, процеса на тестване, валидирането и проверките за тестване на Hadoop и BigData:
В този урок ще видим основното въведение в тестването на Hadoop и BigData, като например кога и къде тестването ще се появи в картината и какво трябва да тестваме като част от тестването на Hadoop.
Също така ще обсъдим подробно следните теми:
- Роли и отговорности при тестването на Hadoop
- Подход за тестване за тестване на Hadoop / BigData
=> Проверете тук, за да видите A-Z на уроци за обучение на BigData тук.
Какво ще научите:
- Съхранение и обработка на данни в Hadoop
- Тестване на BigData и Hadoop
- Каква е стратегията или планът за тестване на BigData?
- Видове тестове за тестване на BigData
- Инструменти за тестване на BigData Hadoop
- Тестване на среди и настройки
- Роли и отговорности при тестването на Hadoop
- Подход за тестване за тестване на Hadoop / тестване на BigData
- Заключение
- Препоръчително четене
Съхранение и обработка на данни в Hadoop
За да изпълним тези процеси в системата Hadoop, разполагаме с работна сила, която е категоризирана в четири секции.
- Администратори на Hadoop са отговорни за създаването на околната среда и имат административни права за достъп до системите Hadoop.
- Разработчици на Hadoop разработване на програми за изтегляне, съхранение и обработка на данните от различни места до централизирани места.
- Тестери на Hadoop за валидиране и проверка на данните преди изтегляне от различни места и след изтегляне на централизираното място, както и валидиране и проверка се извършва, докато данните се зареждат в клиентската среда.
- Анализатори на Hadoop действат, когато се извършва зареждане на данни и когато данните достигнат до склада на местоположението на клиента. Те използват тези данни за генериране на отчети и табло. Анализаторите извършват анализ на данните за растеж и развитие на бизнеса.
Знаем, че Hadoop не е една система; съдържа множество системи и машини. Данните се разделят и съхраняват в множество машини и ако искаме да получим достъп до тях отново, трябва да комбинираме и извлечем данните в отчети и т.н.
Разработчикът е отговорен за писането на програми в JAVA и Python за извличане на данните и тяхното съхранение.
Другата работа на разработчика е да обработва данните. Има два слоя Hadoop, единият е за съхранение, т.е. Hadoop HDFS и друг за обработка, т.е. Hadoop MapReduce.
Съхранението означава, че всички данни, които имаме в източника, просто се съхраняват / вмъкват в системата. Обработката означава, че трябва да я разделим на множество машини и отново да я комбинираме и изпратим на клиента.
По този начин съхранението и обработката се извършват чрез програмиране на скриптове и разработчикът е отговорен за писането на скриптове.
Освен програмирането, другият метод за съхраняване и обработка на данните в Hadoop използва приложения за бази данни като Hive, Impala, HBase и др. Тези инструменти не се нуждаят от познания по програмиране.
Тестване на BigData и Hadoop
След като съхраняването и обработката са извършени от разработчика, данните отиват за генериране на отчети. Преди това трябва да проверим обработените данни за точност и да проверим дали данните са заредени и обработени правилно или не.
Така че програмата и / или скриптовете, създадени от разработчик, трябва да бъдат проверени от тестера Hadoop или BigData. Тестерът трябва да знае основно програмиране като Mapper, Hive, Pig Scripts и др., За да провери скриптовете и да изпълни командите.
Така че, преди тестване, тестерите трябва да знаят какви работят всички програми и скриптове, как да напишат кода и след това да помислят как да ги тестват. Тестването може да се извърши или ръчно, или с помощта на инструменти за автоматизация.
Hadoop има различни видове тестове като тестване на единица, тестване на регресия, тестване на системата и тестване на производителността и т.н. Така че това са често срещаните видове тестове, които използваме при обичайното ни тестване, както и тестовете Hadoop и BigData.
Имаме един и същи вид терминологии за тестване като тестова стратегия, тестови сценарии и тестови случаи и т.н. в Hadoop и BigData Testing. Единствено средата е различна и има различни видове техники, които използваме, за да тестваме системата BigData и Hadoop, защото тук трябва да тестваме данните, а не приложението.
Как да тестваме BigData и какви всички неща изискват тестване в BigData?
За тестването на BigData трябва да имаме някои планове и стратегии.
По този начин трябва да разгледаме следните точки:
- Каква е стратегията или планът за тестване на BigData?
- Какви подходи за тестване се прилагат към BigData?
- Каква е необходимата среда?
- Как да проверя и потвърждавам BigData?
- Какви са инструментите, използвани при тестването на BigData?
Нека се опитаме да получим отговорите на всички горепосочени въпроси.
Каква е стратегията или планът за тестване на BigData?
Тестването на BigData означава проверка и валидиране на данни, докато се съхранява и обработва в хранилището за данни.
Докато тестваме BigData, трябва да тестваме обема и разнообразието от данни, извлечени от различни бази данни и заредени, както и обработени в Data Warehouse или Hadoop System, това тестване е под функционално тестване.
Трябва да тестваме скоростта на данните, изтеглени от различни бази данни и качени в системата Hadoop, която е част от тестването на производителността.
Така че, като план или стратегия, трябва да се концентрираме върху функционално, както и тестване на производителността на тестване на BigData.
При тестването на BigData тестващият трябва да провери обработката на огромно количество данни, използвайки стоков хардуер и относителни компоненти. Следователно качеството на данните също играе важна роля при тестването на BigData. Важно е да проверите и потвърдите качеството на данните.
Видове тестове за тестване на BigData
В предишния раздел видяхме, че функционалното тестване и тестването на производителността играят жизненоважна роля в тестването на BigData, освен това като тестер на BigData, трябва да направим още няколко вида тестове като тестване на база данни, както и архитектурно тестване.
Тези видове тестване са също толкова важни, колкото тестването на функционалността и производителността.
# 1) Архитектурно тестване
Това тестване се прави, за да се гарантира, че обработката на данни е правилна и отговаря на изискванията. Всъщност системата Hadoop обработва огромни обеми данни и е с изчерпателен ресурс.
Ако архитектурата е неправилна, това може да влоши производителността, поради което обработката на данни може да прекъсне и да настъпи загуба на данни.
# 2) Тестване на база данни
Тук валидирането на процеса влиза в картината и ние трябва да проверим данните от различни бази данни, т.е. трябва да гарантираме, че данните, извлечени от базите данни източници или локалните бази данни, трябва да бъдат правилни и правилни.
Също така трябва да проверим дали данните, налични в базите данни на източника, са съвпадащи с данните, въведени в системата Hadoop.
По същия начин трябва да проверим дали данните в системата Hadoop са правилни и правилни след обработка или да кажем след трансформация и да бъдат заредени в клиентската среда с подходяща проверка и проверка.
Като част от тестване на база данни, трябва да преминем през ЖЕСТКО операции, т.е. Създайте тогава данните в Локални бази данни Извличане данните и ние трябва да ги търсим и те трябва да са достъпни в базата данни преди и след зареждането в хранилището за данни и от хранилището на данни в клиентската среда.
Проверка на всеки Актуализирано Данни за всеки етап от съхранението или зареждането и обработката на данните. Изтриване на всякакви повредени данни или всякакви дублирани и нулеви данни.
# 3) Тестване на производителността
Като част от тестването на производителността трябва да проверим скоростта на зареждане и обработка на данни, т.е. като IOPS (Input Output Per Second).
Трябва да проверите скоростта на въвеждане на данните или данните като вход от различни бази данни в хранилището на данни или системата Hadoop и от системата Hadoop или хранилището данни в клиентската среда.
Трябва също да проверите скоростта на данните, идващи от различни бази данни и от хранилището на данни като изход. Това е, което наричаме входен изход за секунда или IOPS.
Отделно от това, друг аспект е да се провери ефективността на поглъщането и разпространението на данни и колко бързо се консумират данните от хранилището на данни от различни бази данни и от системата на клиента от системата Hadoop.
Също като тестер трябва да проверим ефективността на разпределението на данните, например колко бързо се разпределят данните в различни файлове, налични в системата Hadoop или в хранилището на данни. По същия начин, същият процес се случва при разпределяне на данни в клиентски системи.
Системата Hadoop или Хранилището за данни се състои от множество компоненти, така че тестерът трябва да провери ефективността на всички тези компоненти като MapReduce Jobs, вмъкване и консумация на данни, времето за реакция на заявките и тяхната производителност, както и ефективността на търсенето операции. Всички те са включени в тестването на ефективността.
# 4) Функционално тестване
Функционалното тестване съдържа тестване на всички подкомпоненти, програми и скриптове, инструменти, използвани за извършване на операциите за съхранение или зареждане и обработка и др.
За тестера това са четирите важни типа и етапа, през които данните трябва да бъдат филтрирани, така че клиентът да получи перфектните данни без грешки.
Инструменти за тестване на BigData Hadoop
Има различни инструменти, които се използват за тестване на BigData:
- Файлова система за разпространение на HDFS Hadoop за съхранение на BigData.
- Намаляване на HDFS карта за обработка на BigData.
- За NoSQL или HQL Cassandra DB, ZooKeeper и HBase и др.
- Облачно-базирани сървърни инструменти като EC2.
Тестване на среди и настройки
За всякакъв вид тестване тестерът се нуждае от подходящи настройки и среда.
По-долу е даден списъкът с изисквания:
- Тип данни и приложение, което ще бъде тествано.
- Съхранението и обработката изискват голямо пространство за огромно количество данни.
- Правилно разпределение на файлове във всички DataNodes като цяло на клъстера.
- Докато обработвате данните, използването на хардуер трябва да бъде минимално.
- Изпълними програми и скриптове съгласно изискванията на приложението.
Роли и отговорности при тестването на Hadoop
Като тестер на Hadoop, ние сме отговорни за разбирането на изискванията, изготвяме тестовите оценки, планирането на тестовите кутии, получаваме някои данни от тестовете, за да тестваме някои тестови кутии, участваме в създаването на тестово легло, изпълнение на плановете за тестване, докладване и повторно тестване на дефекти
Освен това трябва да отговаряме за ежедневното докладване на състоянието и попълването на теста.
Първото нещо, което ще обсъдим, е Тестова стратегия . След като имаме предложено решение на нашия проблем, трябва да продължим и да планираме или стратегия на нашия план за тестване, можем да обсъдим стратегията за автоматизация, която можем да използваме там, планът за графика на тестване, който зависи от нашите дати на доставка, също така ние може да обсъди планирането на ресурси.
Стратегията за автоматизация е нещо, което ще ни помогне да намалим ръчните усилия, необходими за тестване на продукта. Графикът на тестовете е важен, тъй като ще осигури навременната доставка на продукта.
Планирането на ресурсите ще бъде от решаващо значение, тъй като трябва да планираме колко човекочаса са ни необходими в нашето тестване и колко ресурси на Hadoop са необходими за изпълнението на нашето тестово планиране.
След като разработим стратегия за тестване, трябва да продължим напред и да създадем планове за разработка на тестове, които включват създаване на планове за тестове, създаване на тестови скриптове, които ще ни помогнат да автоматизираме тестването си, а също така ще идентифицираме някои данни за тестване, които ще бъдат използвани в плановете за тестване и ни помага да изпълним тези тестови планове.
След като приключим с разработката на теста, която включва създаване на тестови планове, тестови скриптове и тестови данни, ние продължаваме и започваме да изпълняваме тези тестови планове.
Когато изпълняваме тестовите планове, може да има определени сценарии, при които действителният изход не е според очакванията и тези неща се наричат дефекти. Винаги, когато има дефект, трябва да тестваме и тези дефекти и трябва да създадем и поддържаме матриците за тях.
Всички тези неща попадат в следващата категория, която е Управление на дефекти .
Какво е управление на дефекти?
Управлението на дефекти се състои от проследяване на грешки, отстраняване на грешки и проверка на грешки. Винаги, когато се изпълнява план за тестване срещу който и да е от продуктите, които имаме, и веднага щом бъде идентифицирана конкретна грешка или бъде идентифициран дефект, тогава този дефект трябва да бъде докладван на разработчика или възложен на разработчика.
Така че разработчикът може да го разгледа и да започне да работи по него. Като тестер трябва да проследим напредъка на грешката и да проследим дали грешката е била отстранена. Ако грешката е била отстранена, както е съобщено, трябва да продължим и да я тестваме отново и да проверим дали е разрешена.
След като всички грешки бъдат отстранени, затворени и проверени, трябва да продължим и да доставим тестван продукт на OKAY. Но преди да доставим продукта, трябва да се уверим, че UAT (User Acceptance Testing) е завършен успешно.
Ние се уверяваме, че тестването на инсталацията и проверката на изискванията са направени правилно, т.е. продуктът, който се доставя на клиента или на краен потребител, е в съответствие с изискването, посочено в документа за софтуерни изисквания.
Стъпките, които обсъдихме, се основават на въображението, да бъде някой от сценариите за тестване или някой от подходите за тестване, които ще използваме за тези стъпки, или да кажем тези фрази, за да тестваме нашия продукт и да предоставим крайния резултат, което е OKAY Тестван продукт.
Нека да обсъдим това в детайли и да го съпоставим с тестването на Hadoop.
Знаем, че Hadoop е нещо, което се използва за групова обработка, а също така знаем, че ETL е едно от полетата, в които Hadoop се използва много. ETL означава екстракционна трансформация и зареждане . Ще обсъдим подробно тези процеси, когато обсъдим плана за изпитване и тестовата стратегия като гледна точка на тестване на Hadoop.
Според диаграмата, спомената по-долу, ние просто приемаме, че имаме четири различни източника на данни. Операционна система, CRM ( Управление на взаимоотношенията с клиенти ) и ERP ( Планиране на корпоративни ресурси ) е RDBMS или да кажем Релационната система за управление на база данни, която имаме, а също така имаме и куп плоски файлове, които може да регистрират, файлове, записи или каквото и да е по отношение на нашите източници на данни.
Може да използваме Sqoop или Flume или какъвто и да е конкретен продукт, за да получим данните, записите или каквото и да е като моите източници на данни. Можем да използваме тези инструменти, за да получим данните от Източниците на данни в моята директория за подреждане, която е първата фаза от нашия процес, наречена Екстракция.
След като данните в директорията за подреждане, които всъщност са HDFS (файлова система за разпространение на Hadoop), ще използваме особено скриптовия език като PIG, за да Трансформирайте тези данни. Че Трансформация ще бъде според данните, с които разполагаме.
След като данните се трансформират по съответния начин, използвайки каквато и да е технология за скриптове, която имаме, ще бъдем Зареждане тези данни в хранилището за данни. От хранилището на данни тези данни ще се използват за OLAP анализ, отчитане и извличане на данни или за Анализ.
Нека да продължим и да обсъдим кои всички фази можем да използваме за тестване на Hadoop.
Първата фаза ще бъде фазата на екстракция. Тук ще получим данните от нашите бази данни с данни или от плоски файлове и в този случай това, което можем да направим, е да проверим дали всички данни са копирани успешно и правилно от източника в директорията за подреждане.
Той може да включва проверка на броя на записите, вида на записите и вида на полетата и т.н.
След като тези данни бъдат копирани в директорията на Staging, ние ще продължим и ще задействаме втората фаза, която е трансформация. Тук ще имаме някаква бизнес логика, която ще действа върху копираните данни от изходните системи и всъщност ще създаде или трансформира данните в необходимата бизнес логика.
Трансформацията може да включва сортиране на данните, филтриране на данните, присъединяване на данните от два различни източника на данни и някои други операции.
След като данните се трансформират, ние ще продължим и ще имаме готови планове за тестване и ще проверим дали получаваме изхода, както се очаква, и всички изводи, които получаваме, отговарят на очаквания резултат и типовете данни, стойностите на полетата и диапазоните и т.н. са нещо, което пада на място.
След като е вярно, можем да продължим и да заредим данните в хранилището на данни.
Във фазата на зареждане всъщност проверяваме дали броят на записите от сцената и броят на записите в хранилището за данни са синхронизирани, може да не са подобни, но се предполага, че са синхронизирани. Също така виждаме дали типът данни, които са трансформирани, е синхронизиран.
Публикувайте, че ще използваме тези данни за OLAP анализ, докладване и извличане на данни, който е последният слой на нашия продукт и в този случай можем да имаме последващи или можем да кажем, че тестовите планове са достъпни за всички тези слоеве.
Винаги, когато получаваме някои данни от Източника в местоназначението, винаги трябва да се уверим, че само Упълномощени лица имат оторизиран достъп до Данните.
Удостоверяване
Разрешение
Какво имаме предвид под двата термина?
За да разберем това, нека разгледаме нещата в перспектива от диаграмата ETL.
Съгласно горната диаграма получаваме нашите данни от изходни RDBMS двигатели и от плоски файлове в HDFS и тази фаза се нарича Извличане.
Нека да обсъдим удостоверяването по определен начин, има някои фирми, които имат Данни, които са ограничени по своето естество, този тип Данни се наричат PII данни според стандартите на САЩ.
ИД означава Лична идентификационна информация, всякаква информация като дата на раждане, SSN, мобилен номер, имейл адрес и адрес на къща и др., всички попадат в личните данни. Това е ограничено и не може да се споделя с всички.
Данните трябва да се споделят само с лицата, които са имали най-голяма нужда от тях и тези, които се нуждаят от данните за реална обработка. Наличието на тази проверка и първата защитна линия се нарича удостоверяване.
Например, използваме лаптоп и имаме инсталиран Windows там, може да имаме създаден потребителски акаунт в нашата операционна система Windows и там прилагахме парола.
По този начин само човекът, който има пълномощията за този конкретен потребителски акаунт, може да влезе в системата и по този начин ще защитим нашите данни от кражба или ненужен достъп. Другият слой е Authorization.
Пример, имаме два различни потребителски акаунта в нашата операционна система Windows. Един потребителски акаунт е наш, а друг може да е акаунтът на гост потребител. Администраторът (WE) има право да извършва всякакви операции, като инсталиране и деинсталиране на софтуера, създаване на нов файл и изтриване на съществуващи файлове и др.
Докато от друга страна, гост-потребителите може да нямат целия този вид достъп. Гостът има удостоверяване, за да влезе в системата, но няма правомощия да изтрива или създава файловете и инсталацията, както и деинсталирането на който и да е от софтуера в системата и съответно от системата.
Потребителският акаунт на гост, тъй като е удостоверен, има право да чете създадените файлове и да използва софтуера, който вече е инсталиран.
Ето как се тестват удостоверяването и упълномощаването, в този случай, каквито и данни да са налични в HDFS или някоя от файловите системи, които трябва да проверим за удостоверяване и упълномощаване на данни.
Подход за тестване за тестване на Hadoop / тестване на BigData
Подходът за тестване е общ за всички видове тестове, не само защото това е тестване на BigData или Hadoop, когато отидем на Нормално ръчно тестване или Тестване на автоматизация или Тестване на сигурността, Тестване на производителността, така че всеки вид тестване следва същия подход.
Изисквания
Като част от подхода за тестване, трябва да започнем с Изисквания , Изискването е основно нещо, в днешно време в Agile процеса го наричахме Stories and Epics. Epic не е нищо друго освен по-голямо изискване, докато Stories са по-малки изисквания.
Изискването основно съдържа кои са всички модели на данни, цели, източници, както и какъв вид трансформации трябва да приложим, какви инструменти трябва да използваме? Всички тези подробности ще бъдат налични в Изискванията.
Това основно са изискванията на клиента или изискванията на клиента. Въз основа на това изискване ние ще започнем нашия процес на тестване.
Оценка
Друга част от Подхода е Оценка , Колко време трябва да отделим, за да бъде извършена цялата дейност като част от Тестване. Ние правим планиране на тестове, изготвяме тестови сценарии, подготвяме тестови случаи и изпълняваме същите, както и ще открием дефекти и ще ги докладваме и ще подготвим и доклади за тестване.
Всички тези дейности ще отнемат известно време, така че колко време ни е необходимо за изпълнението на всички тези дейности и това се нарича основно оценка. Трябва да дадем груба оценка на ръководството.
Планиране на тестове
Планиране на тестове не е нищо друго освен описание на процесите, какво да тествате, какво да не тествате, какъв е обхватът на тестването, какви са графиците, колко ресурси са необходими, хардуерни и софтуерни изисквания и какви са сроковете, както и цикли на тестване ще бъдат използвани, какви са нивата на тестване, които изисквахме и т.н.
По време на планирането на теста те ще направят определено разпределение на ресурсите към проекта и какви са различните модели, които имаме, колко ресурси са необходими и какви умения са необходими и т.н. всички тези неща и аспекти ще бъдат включени в теста Фаза на планиране.
По-голямата част от времето хората на ниво олово или ниво на управление ще правят тестовото планиране.
Тестови сценарии и тестови случаи
След като приключим с планирането на теста, трябва да се подготвим Тестови сценарии и тестови случаи , особено за тестване на големи данни, ние изискваме няколко документа заедно с документа за изискванията. Заедно с този документ за изискване какво всичко ни е необходимо?
Имаме нужда от Документ за изискване който съдържа нуждите на клиента, заедно с това се нуждаем и от Входящ документ i.e. Модели за данни. Модел на данни в смисъл какво представляват схемите за бази данни, какви са таблиците и какви са връзките, всички тези данни ще бъдат достъпни в моделите за данни.
Също така имаме Картографиране на документи , Картиране на документи за E.g. в релационните бази данни имаме няколко таблици и след зареждането на данните чрез ETL в хранилището на данни в HDFS, какви са всички карти, които трябва да направим? т.е. картографиране на типа данни.
връщане на масив от низове в java
Например, ако имаме таблица на клиента в HDFS, тогава в HDFS имаме таблица CUSTOMER_TARGET или същата таблица може да бъде и в HIVE.
В тази Таблица за клиенти имаме определени колони, а в Таблицата ЦЕЛ НА КЛИЕНТИ имаме определени колони, както е показано на диаграмата. Изхвърлихме данните от таблицата на клиентите към таблицата CILTER TARGET, т.е. източник към целта.
След това трябва да проверим точното картографиране като данните, присъстващи в таблицата на източника, която е колона 1 и ред 1 на таблицата на клиентите и я разглежда като C1R1 и същите данни трябва да бъдат картографирани в C1R1 на таблицата CILTER TARGET. Това основно се нарича Mapping.
Как ще разберем какви са всички картографирания, които трябва да проверим? Така че тези картографирания ще присъстват в документа за картографиране. В Документа за картографиране, Клиентът ще даде всички видове картографирания.
Също така, ние изисквахме a Документ за проектиране , Документ за проектиране, необходим както за екипа за разработка, така и за екипа за осигуряване на качеството, тъй като в документа за проектиране клиентът ще предостави какъв вид Map Reduce Jobs ще въведе и какъв тип MapReduce Jobs взема входове и какъв тип MapReduce Jobs дава резултати.
По същия начин, ако имаме HIVE или PIG, какви са всички UDF, създадени от клиента, както и какви са всички входни данни, които ще вземат и какъв вид продукция ще произвеждат и т.н.
За да подготвим тестови сценарии и тестови случаи, трябва да разполагаме с всички тези документи на ръка:
- Документ за изискване
- Модел на данни
- Картографиране на документ
- Документ за проектиране
Те могат да варират в различните организации и няма задължително правило, че трябва да разполагаме с всички тези документи. Понякога имаме всички документи, а понякога имаме само два или три документа или понякога трябва да разчитаме и на един документ, което зависи от сложността на проекта, фирмените графици и всичко.
Отзиви за тестови сценарии и тестови случаи
Трябва да извършим преглед на тестови сценарии и тестови случаи, защото по някакъв начин или в някои случаи забравяме или пропускаме някои тестови случаи, защото всеки не може да измисли всички възможни неща, които могат да се направят с изискванията, при такива условия трябва да предприемем помощ от инструменти на трети страни или от някой друг.
Така че, когато подготвяме някакви документи или изпълняваме нещо, имаме нужда от някой, който да прегледа нещата от същия екип, като разработчици, тестери. Те ще дадат подходящи предложения за включване на нещо повече или също така ще предложат актуализиране или модифициране на тестовите сценарии и тестовите случаи.
Те предоставят всички коментари и въз основа на това ще актуализираме нашите тестови сценарии и тестови случаи и множество версии на документа, които трябва да публикуваме в екипа, докато документът бъде напълно актуализиран според изискването.
Изпълнение на теста
След като документът е готов, ще получим изписването от горния екип, за да стартираме процеса на изпълнение, който по същество се нарича Тестово изпълнение.
Ако искаме да изпълним нашите тестови случаи по време на изпълнение, трябва да проверим дали разработчикът трябва да изпрати информацията, ако това е нормално функционално тестване или някакво друго тестване или тестване за автоматизация, ние се нуждаем от компилация. Но тук от гледна точка на тестване на Hadoop или BigData, разработчикът ще предостави MapReduce Jobs.
HDFS файлове - каквито и файлове да се копират в HDFS, информацията за тези файлове се изисква за проверка на привилегиите, HIVE скриптове, създадени от разработчиците за проверка на данните в таблицата HIVE, а също така ни трябват и HIVE UDF, разработени от разработчиците, PIG Скриптове и PIG UDF.
Това са всички неща, които трябва да получим от разработчиците. Преди да отидем за екзекуцията, трябва да имаме всички тези неща.
За MapReduce Jobs те ще предоставят някои JAR файлове и като част от HDFS вече са заредили данните в HDFS и файловете трябва да са готови и HIVE скриптове за валидиране на данните в HIVE таблици. Каквото и да са внедрили СДС, те ще бъдат достъпни в СДС на HIVE. Изискваме същото за PIG скриптове и UDF.
Отчитане и проследяване на дефекти
След като изпълним нашите тестови случаи, откриваме някои дефекти, някои очаквани, а някои действителни не са равни на очакваните резултати, така че трябва да ги изброим и да ги предоставим на екипа за разработка за разрешаване, а това в основата се нарича Отчитане на дефекти.
Да предположим, че ако намерим някакъв дефект в заданието MapReduce, тогава ще докладваме за него на разработчика и те ще пресъздадат отново заданието MapReduce и ще направят някои модификации на ниво код и след това отново ще предоставят най-новата задача MapReduce, която трябва да тестваме .
Това е непрекъснат процес, след като заданието бъде тествано и преминато, отново трябва да го тестваме отново и да докладваме на разработчика и след това да вземем следващото за тестване. Ето как се осъществява отчитането и проследяването на дефекти.
Доклади от тестовете
След като приключим с целия процес на тестване и дефектите бъдат затворени, трябва да създадем нашите протоколи за тестване. Докладите от тестовете са всичко, което сме направили, за да завършим процеса на тестване досега. Всички планиране, писане и изпълнение на тестови случаи, какъв изход имаме и т.н. всичко се документира заедно под формата на тестови отчети.
Трябва да изпращаме тези отчети ежедневно или ежеседмично или според нуждите на клиента. В днешно време организациите използват модела AGILE, така че всеки доклад за състоянието трябва да бъде актуализиран по време на ежедневните скрамове.
Заключение
В този урок разгледахме:
- Стратегията или планът за тестване на BigData.
- Необходима среда за тестване на BigData.
- Проверка и проверки на BigData.
- Инструменти, използвани при тестване на BigData.
Научихме и за -
- Как тестовата стратегия, разработването на тестове, изпълнението на тестове, управлението на дефекти и доставката работят в ролите и отговорностите като част от тестването на Hadoop.
- Подход за тестване за тестване на Hadoop / BigData, който включва събиране на изисквания, оценка, планиране на тестове, създаване на тестови сценарии и тестови случаи заедно с рецензиите.
- Също така разбрахме за изпълнение на тестове, докладване и проследяване на дефекти и докладване на тестове.
Надяваме се този урок за тестване на BigData да ви е бил полезен!
=> Проверете ВСИЧКИ уроци за BigData тук.
Препоръчително четене
- Урок за тестване на обем: Примери и инструменти за тестване на обем
- Как да извършите тестване на данни в SoapUI Pro - Урок SoapUI # 14
- Урок за тестване на хранилище на данни с примери | Ръководство за тестване на ETL
- Изтегляне на eBook за тестване на Primer
- Урок за тестване на хранилище на данни за ETL (Пълно ръководство)
- Какво е Hadoop? Урок за Apache Hadoop за начинаещи
- Урок за деструктивно изпитване и безразрушително тестване
- Функционално тестване срещу нефункционално тестване