Меню

Комплексний підручник з тестування Hadoop | Посібник з тестування великих даних

  • Головна
  • Інший
  • Комплексний підручник з тестування Hadoop | Посібник з тестування великих даних

comprehensive hadoop testing tutorial big data testing guide

Спробуйте Наш Інструмент Для Усунення Проблем

Цей підручник пояснює основи, типи тестування, плани, необхідне середовище, процес тестування, перевірку та перевірку для тестування Hadoop та BigData:

У цьому підручнику ми побачимо базове введення в тестування Hadoop та BigData, як, коли та де тестування з’явиться, і що нам потрібно перевірити як частину тестування Hadoop.

Ми також детально обговоримо наступні теми:

  • Ролі та обов'язки тестування Hadoop
  • Підхід до тестування для тестування Hadoop / BigData

=> Перегляньте тут, щоб побачити A-Z навчальних посібників BigData тут.

Вступ до тестування BigData та Hadoop

Що ви дізнаєтесь:

Зберігання та обробка даних у Hadoop

Для виконання цих процесів у системі Hadoop ми маємо робочу силу, яка розділена на чотири секції.

  • Адміністратори Hadoop відповідають за налаштування навколишнього середовища та мають адміністративні права на доступ до систем Hadoop.
  • Розробники Hadoop розробити програми щодо витягування, зберігання та обробки даних з різних місць до централізованих місць.
  • Тестувальники Hadoop для перевірки та перевірки даних перед витяганням з різних місць і після витягування з централізованого місця, а також перевірка та перевірка здійснюється під час завантаження даних у клієнтське середовище.
  • Аналітики Hadoop функціонують, коли виконується завантаження даних і коли дані надходять на склад у місцезнаходження клієнта. Вони використовують ці дані для створення звітів та інформаційної панелі. Аналітики проводять аналіз даних для зростання та розвитку бізнесу.

Ми знаємо, що Hadoop - це не єдина система; він містить безліч систем і машин. Дані поділяються та зберігаються на декількох машинах, і якщо ми хочемо отримати до них доступ знову, нам потрібно об’єднати та втягнути дані у звіти тощо.

Розробник відповідає за написання програм на JAVA та Python для вилучення даних та їх зберігання.

Інша робота розробника - це обробка даних. Існує два шари Hadoop, один призначений для зберігання, тобто Hadoop HDFS, а інший - для обробки, тобто Hadoop MapReduce.

Зберігання означає, що всі дані, які ми маємо у джерелі, просто зберігаються / вставляються в систему. Обробка означає, що нам потрібно розділити її на кілька машин і знову об’єднати та надіслати клієнту.

Таким чином, зберігання та обробка здійснюються за допомогою сценаріїв програмування, а розробник відповідає за написання сценаріїв.

Окрім програмування, іншим методом зберігання та обробки даних у Hadoop є використання програм баз даних, таких як Hive, Impala, HBase тощо. Ці інструменти не потребують знань з програмування.

Тестування BigData та Hadoop

Після зберігання та обробки розробником дані надходять на формування звіту. До цього нам потрібно перевірити оброблювані дані на точність і перевірити, чи дані точно завантажені та оброблені правильно чи ні.

Отже, програму та / або сценарії, створені розробником, потрібно перевірити Hadoop або BigData Tester. Тестувальник повинен знати базове програмування, таке як Mapper, Hive, Pig Scripts тощо, щоб перевірити сценарії та виконати команди.

Отже, перед тестуванням тестувальники повинні знати, які всі програми та сценарії працюють, як написати код, а потім подумати, як їх протестувати. Тестування може проводитися як вручну, так і за допомогою засобів автоматизації.

Hadoop має різні види тестування, такі як модульне тестування, тестування регресії, тестування системи та тестування продуктивності тощо. Отже, це загальні типи тестування, які ми використовуємо в нашому звичайному тестуванні, а також тестування Hadoop та BigData.

У нас є однакові терміни тестування, такі як стратегія тестування, сценарії тестування, тестові кейси тощо у тестуванні Hadoop та BigData. Тільки середовище відрізняється, і існують різні види методів, які ми використовуємо для тестування системи BigData та Hadoop, оскільки тут нам потрібно тестувати дані, а не додаток.

Як протестувати BigData і що все вимагає тестування в BigData?

Для тестування BigData нам потрібно мати деякі плани та стратегії.

Таким чином, нам потрібно врахувати наступні моменти:

  • Яка стратегія чи план тестування для BigData?
  • Який підхід до тестування застосовується до BigData?
  • Яке середовище потрібно?
  • Як перевірити та перевірити BigData?
  • Які інструменти використовуються при тестуванні BigData?

Спробуємо отримати відповіді на всі вищезазначені запитання.

Яка стратегія чи план тестування BigData?

Тестування BigData означає перевірку та перевірку даних при зберіганні та обробці їх у сховищі даних.

Під час тестування BigData нам потрібно перевірити обсяг та різноманітність даних, вилучених з різних баз даних та завантажених, а також оброблених у сховищі даних або системі Hadoop, це тестування підлягає функціональному тестуванню.

Нам потрібно протестувати швидкість даних, завантажених з різних баз даних і завантажених до системи 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, вставка та споживання даних, час відгуку запитів та їх продуктивність, а також продуктивність пошуку операцій. Все це включено до тестування продуктивності.

# 4) Функціональне тестування

Функціональне тестування містить тестування всіх підкомпонентів, програм та скриптів, інструментів, що використовуються для виконання операцій зберігання або завантаження та обробки тощо.

Для тестера це чотири важливі типи та етапи, через які дані потрібно відфільтрувати, щоб клієнт отримав ідеальні дані без помилок.

Інструменти для тестування BigData Hadoop

Існують різні інструменти, які використовуються для тестування BigData:

  • Файлова система розподілу HDFS Hadoop для зберігання BigData.
  • Зниження карти HDFS для обробки BigData.
  • Для NoSQL або HQL Cassandra DB, ZooKeeper та HBase тощо.
  • Хмарні серверні інструменти, такі як EC2.

Тестування середовищ та налаштувань

Для будь-якого типу тестування тестувальник потребує належних налаштувань та середовища.

Нижче наведено перелік вимог:

  1. Тип даних та програми, які будуть перевірені.
  2. Зберігання та обробка вимагає великого простору для величезного обсягу даних.
  3. Правильний розподіл файлів на всіх вузлах даних загалом у кластері.
  4. Під час обробки даних використання апаратного забезпечення має бути мінімальним.
  5. Запущені програми та сценарії відповідно до вимог Програми.

Ролі та обов'язки тестування Hadoop

Як тестувальник Hadoop, ми несемо відповідальність за розуміння вимог, підготовку кошторисів випробувань, планування тестових кейсів, отримання деяких даних тестування для тестування деяких тестових кейсів, участь у створенні випробувального стенду, виконанні планів випробувань, звітуванні та повторному тестуванні дефектів.

Крім того, ми повинні відповідати за щоденне звітування про стан та проходження тестів.

Ролі та обов

Перше, що ми збираємося обговорити, це Тестова стратегія . Після того, як ми запропонуємо рішення нашої проблеми, нам потрібно продовжити і спланувати або розробити стратегію нашого плану випробувань, ми можемо обговорити стратегію автоматизації, яку ми можемо використовувати там, план про графік випробувань, який залежить від наших термінів постачання, також ми може обговорювати планування ресурсів.

Стратегія автоматизації допоможе нам зменшити ручні зусилля, необхідні для тестування продукту. Графік випробувань важливий, оскільки він забезпечить своєчасну доставку товару.

Планування ресурсів буде мати вирішальне значення, оскільки нам потрібно спланувати, скільки людських годин нам потрібно на нашому тестуванні та скільки ресурсів Hadoop потрібно для виконання нашого планування тестів.

Після того, як ми розробимо стратегію тестування, нам потрібно продовжувати створювати плани розробки тестів, які включають створення планів тестування, створення тестових сценаріїв, які допоможуть нам автоматизувати тестування, а також визначити деякі дані тестування, які будуть використовуватися в планах тестування. і допомагає нам виконувати ці тестові плани.

Коли ми закінчимо розробку тестів, що включає створення тестових планів, тестових сценаріїв та тестових даних, ми продовжуємо і починаємо виконувати ці тестові плани.

Коли ми виконуємо тестові плани, можуть бути певні сценарії, коли фактичний результат не відповідає очікуваному, і ці речі називаються дефектами. Всякий раз, коли є дефект, нам також потрібно перевірити ці дефекти, і нам потрібно створити і підтримувати матриці для них.

Всі ці речі підпадають під наступну категорію, яка є Управління дефектами .

Що таке управління дефектами?

Управління дефектами складається з відстеження помилок, виправлення помилок та перевірки помилок. Щоразу, коли план тестування виконується щодо будь-якого з наявних у нас продуктів, і як тільки виявляється конкретна помилка або виявляється дефект, про цей дефект потрібно повідомляти розробнику або призначати розробнику.

Тож розробник може розглянути це і почати над ним працювати. Як тестувальник, нам потрібно відстежувати хід помилки та відстежувати, чи помилку виправлено. Якщо помилка була виправлена, як повідомляється, тоді нам потрібно повторно протестувати її та перевірити, чи вона вирішена.

Як тільки всі помилки будуть виправлені, закриті та перевірені, нам потрібно продовжувати і пропонувати випробуваний продукт OKAY. Але перед тим, як ми доставимо товар, ми повинні переконатися, що UAT (Тест прийняття користувача) успішно завершено.

Ми переконуємось, що тестування встановлення та перевірка вимог зроблені належним чином, тобто продукт, який доставляється клієнту або кінцевому користувачеві, відповідає вимозі, зазначеній у Документі вимоги до програмного забезпечення.

Крок, який ми обговорили, ґрунтується на уяві, будь-який із сценаріїв тестування або будь-який з підходів до тестування, які ми будемо використовувати для цих кроків, або вимовляємо ці фрази для тестування нашого продукту та отримання кінцевого результату, що є OKAY Випробуваний продукт.

Давайте обговоримо це детально та порівняємо з тестуванням Hadoop.

Ми знаємо, що Hadoop - це те, що використовується для пакетної обробки, і ми також знаємо, що ETL - одне з полів, де Hadoop багато використовується. ETL означає екстракційне перетворення та завантаження . Ми детально обговоримо ці процеси, коли обговоримо план випробувань та стратегію випробувань як точку зору тестування Hadoop.

Відповідно до діаграми, згаданої нижче, ми просто припускаємо, що у нас є чотири різних джерела даних. Операційна система, CRM ( Управління відносинами з клієнтами ) та ERP ( Планування ресурсів підприємства ) - це СУБД, або, скажімо, Реляційна система управління базами даних, яка у нас є, і у нас також є кілька плоских файлів, які можуть бути журналами, файлами, записами або чим-небудь стосовно наших джерел даних.

Ми можемо використовувати Sqoop або Flume або будь-який конкретний продукт для отримання Даних, записів або чого-небудь іншого як своїх джерел даних. Ми можемо використовувати ці інструменти для отримання даних із джерел даних до мого проміжного каталогу, який називається першим етапом нашого процесу Видобуток.

Після того, як дані, що містяться в директорії проміжних етапів, які насправді виявляються HDFS (файлова система розподілу Hadoop), ми будемо особливо використовувати мову сценаріїв, таку як PIG, щоб Трансформувати ці дані. Це Трансформація буде відповідно до даних, які ми маємо.

Як тільки Дані будуть трансформовані відповідним чином, використовуючи будь-яку технологію сценаріїв, яка у нас є, ми будемо Завантаження ці дані до сховища даних. З Сховища даних ці дані будуть використовуватися для аналізу OLAP, звітування та видобутку даних або для аналітики.

Давайте обговоримо, які етапи ми можемо використовувати для тестування Hadoop.

Першою фазою буде фаза видобутку. Тут ми збираємось отримати дані з наших вихідних баз даних або з Flat-файлів, і в такому випадку ми можемо перевірити, що всі Дані були скопійовані успішно та правильно з джерела в Дирекцію проміжного етапу.

Він може включати перевірку кількості записів, типу записів і типу полів тощо.

Після того, як ці дані скопіюються до директорії проміжних етапів, ми продовжимо і ініціюємо другу фазу, яка є перетворенням. Тут ми матимемо певну бізнес-логіку, яка діятиме на скопійовані дані з вихідних систем і фактично створюватиме або перетворюватиме дані у необхідну бізнес-логіку.

Трансформація може включати сортування даних, фільтрування даних, об’єднання даних із двох різних джерел даних та деякі інші операції.

Після того, як Дані перетворені, ми продовжимо і матимемо готові плани випробувань, і ми перевіримо, чи отримуємо вихідні дані, як очікувалось, і всі вихідні дані, які ми отримуємо, відповідають очікуваному результату та типам даних, значенням полів та діапазони тощо - це те, що падає на місце.

Як тільки це буде правильно, ми можемо продовжувати завантажувати дані до сховища даних.

На етапі завантаження ми фактично перевіряємо, чи синхронізована кількість записів із етапу та кількість записів у сховищі даних, вони можуть бути не схожими, але вони повинні бути синхронізованими. Ми також бачимо, чи тип даних, які були перетворені, синхронізований.

Повідомляємо, що ми будемо використовувати ці дані для аналізу, звітності та видобутку даних OLAP, що є останнім шаром нашого продукту, і в цьому випадку ми можемо мати наступні або можна сказати, що тестові плани доступні для всіх цих шарів.

Кожного разу, коли ми отримуємо якісь Дані з Джерела в пункт призначення, тоді нам завжди потрібно переконатися, що лише Уповноважені особи мають Уповноважений доступ до Даних.

Аутентифікація

Аутентифікація

Авторизація

Авторизація

Що ми маємо на увазі під цими двома цими термінами?

Щоб зрозуміти це, давайте розглянемо ситуацію в перспективі з діаграми ETL.

ETL

Відповідно до наведеної діаграми, ми отримуємо наші дані з вихідних двигунів СУБД та з плоским файлів у HDFS, і ця фаза називається вилученням.

Давайте обговоримо аутентифікацію конкретним чином, є певні компанії, котрі мають Дані, які обмежені за своєю суттю; цей тип Даних згідно зі стандартами Сполучених Штатів називається даними ідентифікації даних.

ІПІ виступає за Персональна ідентифікаційна інформація, будь-яка інформація, така як дата народження, номер SSN, номер мобільного телефону, адреса електронної пошти та адреса будинку тощо, підпадає під ідентифікаційну інформацію. Це обмежено і не може ділитися з усіма.

Дані повинні передаватися лише особам, які найбільше їх потребували, та тим, хто потребує даних для фактичної обробки. Наявність цієї перевірки та встановлення першої лінії захисту називається автентифікацією.

Наприклад, ми використовуємо ноутбук, і у нас там встановлена ​​Windows, можливо, у нас є якийсь обліковий запис користувача, створений в нашій операційній системі Windows, і там ми застосовуємо пароль.

Таким чином лише особа, яка має Повноваження для цього конкретного облікового запису користувача, може ввійти в Систему, і саме таким чином ми збираємось захистити наші Дані від крадіжки або непотрібного доступу. Інший рівень - «Авторизація».

Приклад, у нас є дві різні облікові записи користувачів в нашій операційній системі Windows. Один обліковий запис наш, а інший може бути гостьовим. Адміністратор (WE) має право виконувати всі види операцій, таких як встановлення та видалення програмного забезпечення, створення нового файлу та видалення існуючих файлів тощо.

З іншого боку, гостьові користувачі можуть не мати такого доступу. Гість має автентифікацію для входу в систему, але не має повноважень видаляти або створювати файли та інсталяцію, а також видаляти будь-яке програмне забезпечення в системі та із системи відповідно.

Однак гостьовий обліковий запис користувача через автентифікацію має право читати створені файли та використовувати вже встановлене програмне забезпечення.

Ось як перевіряються автентифікація та авторизація, в даному випадку, будь-які Дані, доступні в HDFS, або будь-яка з файлових систем, які нам потрібні для перевірки автентифікації та авторизації даних.

Підхід до тестування для тестування Hadoop / тестування BigData

Підхід до тестування

Підхід до тестування є загальним для всіх видів тестування не тільки тому, що це тестування BigData або Hadoop, коли ми переходимо до звичайного ручного тестування або тестування автоматизації чи тестування безпеки, тестування продуктивності, тому будь-яке тестування дотримується того самого підходу.

Вимоги

Як частина підходу до тестування, нам слід почати з Вимоги , Вимоги - це основна річ, сьогодні в процесі Agile ми називали це Історіями та Епосами. Епічність - це не що інше, як більша вимога, тоді як Історії - це менші вимоги.

Вимога в основному містить, які є всі моделі даних, цілі, джерела, а також які трансформації нам потрібно застосовувати, які інструменти ми повинні використовувати? Усі ці деталі будуть доступні в розділі 'Вимоги'.

В основному це вимоги клієнта або вимоги клієнта. Виходячи з цієї вимоги, ми розпочнемо процес тестування.

Оцінка

Ще однією частиною Підходу є Оцінка , Скільки часу нам потрібно витратити, щоб виконати всю діяльність як частину тестування. Ми робимо планування випробувань, готуємо сценарії випробувань, готуємо кейси для тестування та виконуємо їх, а також знаходимо дефекти та повідомляємо про них, а також готуємо звіти про випробування.

Всі ці заходи займуть певний час, тому скільки часу нам потрібно для завершення всіх цих дій, і це в основному називається оцінкою. Нам потрібно дати грубу оцінку керівництву.

Планування тестів

Планування тестів це не що інше, як опис процесів, що тестувати, що не тестувати, який обсяг тестування, які графіки, скільки потрібно ресурсів, вимоги до апаратного та програмного забезпечення та які терміни, а також цикли тестування буде використовуватися, які рівні тестування ми вимагали тощо.

Під час планування тестування вони виконуватимуть певний розподіл ресурсів для проекту та які різні моделі ми маємо, скільки ресурсів потрібно і які набори навичок потрібні тощо. Усі ці речі та аспекти будуть включені в тест Етап планування.

Здебільшого люди, які займаються керівництвом або керівництвом, виконуватимуть планування тестів.

Тестові сценарії та тестові випадки

Після того, як ми закінчимо планування тестів, нам потрібно підготуватися Тестові сценарії та тестові випадки , особливо для тестування великих даних, нам потрібні кілька документів разом із документом вимог. Разом із цим документом вимоги, що все нам потрібно?

Нам потрібен Документ вимоги що містить потреби Клієнта, поряд із цим нам потрібна Вхідний документ тобто Моделі даних. Модель даних у тому сенсі, що таке схеми баз даних, які таблиці та які взаємозв'язки будуть доступні в даних моделях.

Крім того, ми маємо Картування документів , Складання документів для Наприклад у реляційних базах даних у нас є кілька таблиць, і після завантаження даних через ETL у сховищі даних у HDFS, що все картографування нам потрібно зробити? тобто відображення типу даних.

який найкращий засіб для видалення шпигунських програм -

Наприклад, якщо у нас є таблиця замовника в HDFS, то в HDFS у нас є таблиця CUSTOMER_TARGET або та сама таблиця може бути і в HIVE.

Зіставлення даних

У цій таблиці клієнтів у нас є певні стовпці, а в таблиці ЦІЛЬ НА КЛІЄНТИ - певні стовпці, як показано на схемі. Ми передали дані з таблиці клієнтів у таблицю ЦІЛЬ НА КЛІЄНТИ, тобто джерело до цільової.

Потім нам потрібно перевірити точне відображення, як дані, наявні у вихідній таблиці, яка є стовпцем 1 та рядком 1 таблиці клієнтів, і розглядає її як C1R1, а ті самі дані повинні бути відображені в C1R1 таблиці ЦІЛЬ НА КЛІЄНТИ. Це в основному називається картографуванням.

Як ми дізнаємось, які всі відображення нам потрібно перевірити? Отже, ці зіставлення будуть присутні в Документі зіставлення. У Документі зіставлення Клієнт надає всі види зіставлення.

Крім того, ми вимагали Проектний документ , Проектний документ, необхідний як для команди розробників, так і для команди контролю якості, оскільки в проектному документі Клієнт надасть, який вид завдань Map Reduce він збирається впровадити та який тип MapReduce Jobs бере вхідні дані та який тип MapReduce Робота дає результати.

Подібним чином, якщо у нас є HIVE або PIG, що це все, що створив Замовник, а також який вхідний матеріал вони прийматимуть і який вид продукції вони вироблятимуть тощо.

Для підготовки сценаріїв тестування та тестових справ нам потрібно мати усі ці документи від руки:

  • Документ вимоги
  • Модель даних
  • Картографування документа
  • Проектний документ

Вони можуть відрізнятися в залежності від організації, і немає жодного обов’язкового правила про те, що ми повинні мати усі ці документи. Іноді у нас є всі документи, а іноді у нас є лише два-три документи, або іноді нам також потрібно покладатися на один документ, тобто до складності проекту, графіків компаній та всього іншого.

Огляди сценаріїв випробувань та тестових випадків

Нам потрібно провести огляд сценаріїв тестування та тестових випадків, тому що якимось чином, або в деяких випадках ми забуваємо або пропускаємо деякі тестові випадки, тому що всі не можуть подумати про всі можливі речі, які можна зробити з вимогами, в таких умовах нам потрібно приймати допомогу від сторонніх інструментів або від когось іншого.

Отже, коли ми готуємо якісь документи або виконуємо щось, тоді нам потрібен хтось, щоб переглянути матеріали тієї самої команди, як розробники, тестувальники. Вони дадуть належні пропозиції включити щось більше або також запропонують оновити або змінити тестові сценарії та тестові випадки.

Вони надають всі коментарі, і на основі цього ми будемо оновлювати наші тестові сценарії та тестові випадки, а також кілька версій документа, які нам потрібно опублікувати в команді, доки документ не буде повністю оновлений відповідно до вимог.

Виконання тесту

Після того, як документ буде готовий, ми отримаємо підпис від верхньої команди, щоб розпочати процес виконання, який в основному називається тестовим виконанням.

Якщо ми хочемо виконати наші тестові випадки під час виконання, нам потрібно перевірити, чи розробник повинен надіслати інформацію, якщо це нормальне функціональне тестування чи якесь інше тестування або тестування автоматизації, нам потрібна збірка. Але тут, з точки зору тестування Hadoop або BigData, розробник надасть MapReduce Jobs.

Файли HDFS - будь-які файли, які копіюються в HDFS, інформація про ці файли потрібна для перевірки привілеїв, сценарії HIVE, створені розробниками для перевірки даних у таблиці HIVE, а також нам потрібні UDF HIVE, розроблені розробниками, PIG Сценарії та СВІ СДС.

Це все, що нам потрібно отримати від розробників. Перш ніж йти на страту, ми повинні мати усі ці речі.

Для MapReduce Jobs вони нададуть деякі файли JAR, і як частина HDFS вони вже завантажили дані в HDFS, і файли повинні бути готовими, а сценарії HIVE для перевірки даних у таблицях HIVE. Незалежно від того, які СДС вони впровадили, вони будуть доступні в СДІ HIVE. Ми вимагаємо те саме для сценаріїв PIG та UDF.

Звітування про дефекти та відстеження

Одного разу, коли ми виконуємо наші тестові випадки, ми виявляємо деякі дефекти, деякі очікувані, а деякі фактичні не дорівнюють очікуваним результатам, тому нам потрібно внести їх у список і надати їх команді розробників для вирішення, і це в основному називається звітування про дефекти.

Припустимо, якщо ми виявимо дефект у завданні MapReduce, тоді ми повідомимо про це розробника, і вони знову відтворять завдання MapReduce, і вони внесуть деякі модифікації рівня коду, а потім знову нададуть останнє завдання MapReduce, яке нам потрібно протестувати .

Це постійний процес, після того як завдання буде перевірено та пройдено, нам знову потрібно буде протестувати його та повідомити про це розробнику, а потім отримати наступне для тестування. Ось як здійснюється діяльність зі звітування та відстеження дефектів.

Звіти про випробування

Після того, як ми закінчили весь процес тестування та дефекти були усунені, нам потрібно створити наші Звіти про тестування. Звіти про тести - це все, що ми зробили для завершення процесу тестування до цього часу. Все планування, написання та виконання тестових випадків, який результат ми отримали тощо, все документується разом у формі Тестових звітів.

Нам потрібно надсилати ці звіти щодня або щотижня або відповідно до потреб Клієнта. На сьогоднішній день організації використовують модель AGILE, тому кожен звіт про статус потрібно оновлювати під час щоденних сутичок.

Висновок

У цьому посібнику ми пройшли:

  • Стратегія або план тестування BigData.
  • Необхідне середовище для тестування BigData.
  • Перевірка та перевірка BigData.
  • Інструменти, що використовуються при тестуванні BigData.

Ми також дізналися про -

  • Як стратегія тестування, розробка тестів, виконання тестів, управління дефектами та доставка працюють у ролях та відповідальності як частина тестування Hadoop.
  • Підхід до тестування для тестування Hadoop / BigData, який включає збір вимог, оцінку, планування тестів, створення тестових сценаріїв та тестових справ разом із оглядами.
  • Ми також дізналися про виконання тестів, звітування про дефекти та відстеження та звітування про тести.

Ми сподіваємось, що цей посібник з тестування BigData був для вас корисним!

=> Перевірте ВСІ підручники з BigData тут.

Рекомендована література

^