most popular test automation frameworks with pros
У кількох останніх підручниках із селену ми обговорили різні загальновживані та популярні команди в WebDriver , обробка веб-елементів, таких як веб-таблиці, кадри і обробка винятків в селенових сценаріях.
Ми обговорили кожну з цих команд із зразками фрагментів коду та прикладами, щоб зробити вас здатними ефективно використовувати ці команди, коли ви стикаєтесь із подібними ситуаціями. Серед команд, які ми обговорювали в попередньому підручнику, мало хто з них набуває надзвичайного значення.
Просуваючись в серії Selenium, ми зосередимо свою увагу на Створення фреймворку автоматизації у наступних кількох майбутніх підручниках. Ми також проливаємо світло на різні аспекти фреймворку автоматизації, типи фреймворків автоматизації, переваги використання фреймворку та основні компоненти, що складають фреймворк автоматизації.
Що ви дізнаєтесь:
- Що таке Framework?
- Структура автоматизації тестів
- Типи рамки автоматизації тестів
- # 1) Модульна база тестування
- # 2) Структура тестування архітектури бібліотеки
- # 3) Структура тестування на основі даних
- # 4) Структура тестування на основі ключових слів
- # 5) Структура гібридного тестування
- # 6) Структура розвитку, керована поведінкою
- Висновок
- Рекомендована література
Що таке Framework?
Фреймворк вважається поєднанням набору протоколів, правил, стандартів та вказівок, які можуть бути включені або дотримуватися як єдине ціле, щоб використати переваги будівельних лісів, передбачені Рамкою.
Давайте розглянемо реальний сценарій.
Ми дуже часто використовуємо ліфти або ліфти. У ліфті є кілька рекомендацій, яких слід дотримуватися та доглядати за ними, щоб забезпечити максимальну користь та тривале обслуговування від системи.
Як запустити файли .jar у Windows 10
Таким чином, користувачі могли помітити такі вказівки:
- Слідкуйте за максимальною місткістю ліфта і не сідайте на ліфт, якщо максимальна місткість досягла.
- Натисніть кнопку тривоги на випадок надзвичайної ситуації чи проблеми.
- Дозвольте пасажиру вийти з ліфта, якщо такий є, перед тим, як увійти в ліфт і стояти подалі від дверей.
- У разі пожежі в будівлі або випадкової ситуації уникайте використання ліфта.
- Не грайте і не стрибайте всередину ліфта.
- Не палити всередині ліфта.
- Зателефонуйте за допомогою / допомогою, якщо двері не відчиняються або якщо ліфт взагалі не працює. Не намагайтеся відчинити двері з силою.
Правил чи наборів настанов може бути набагато більше. Таким чином, якщо дотримуватися цих вказівок, система стає більш вигідною, доступною, масштабованою та менш проблемною для користувачів.
Тепер, коли ми говоримо про «Тестові рамки автоматизації», давайте зосередимося на них.
Структура автоматизації тестів
«Тестова система автоматизації» - це будівельні ліси, які прокладені для забезпечення середовища виконання сценаріїв тестування автоматизації. Фреймворк надає користувачеві різні переваги, які допомагають йому ефективно розробляти, виконувати та звітувати про сценарії тестування автоматизації. Це більше схоже на систему, яка створена спеціально для автоматизації наших тестів.
Дуже простою мовою можна сказати, що фреймворк - це конструктивна суміш різноманітних настанов, стандартів кодування, концепцій, процесів, практик, ієрархій проектів, модульності, механізму звітування, введення даних тестування тощо до тестування автоматизації стовпів. Таким чином, користувач може дотримуватися цих вказівок, одночасно автоматизуючи додаток, щоб скористатися перевагами різних продуктивних результатів.
Переваги можуть полягати в різних формах, таких як простота написання сценаріїв, масштабованість, модульність, зрозумілість, визначення процесу, повторне використання, вартість, обслуговування тощо. Таким чином, щоб отримати ці переваги, розробникам рекомендується використовувати один або декілька рамки автоматизації тестів.
Більше того, необхідність єдиної та стандартної програми автоматизації тестування виникає, коли у вас є купа розробників, які працюють над різними модулями одного додатка, і коли ми хочемо уникнути ситуацій, коли кожен із розробників реалізує свій підхід до автоматизації.
Примітка : Зверніть увагу, що тестовий фреймворк завжди є незалежним від програми, тобто його можна використовувати з будь-яким додатком незалежно від ускладнень (наприклад, стек технологій, архітектура тощо) тестованої програми. Структура повинна бути масштабованою та ремонтопридатною.
Перевага рамки автоматизації тестів
- Багаторазове використання коду
- Максимальне покриття
- Сценарій відновлення
- Недороге обслуговування
- Мінімальне ручне втручання
- Простота звітування
Типи рамки автоматизації тестів
Тепер, коли ми маємо базове уявлення про те, що таке Framework Automation, у цьому розділі ми б познайомили вас з різними типами Test Automation Frameworks, доступними на ринку. Ми також спробуємо пролити світло на їх плюси і мінуси та рекомендації щодо зручності використання.
На сьогоднішній день існує різноманітний діапазон Рамок автоматизації. Ці фреймворки можуть відрізнятися один від одного на основі підтримки різних ключових факторів автоматизації, таких як багаторазове використання, простота обслуговування тощо.
Давайте обговоримо декілька найбільш популярних тестових систем автоматизації:
- Модульна база тестування
- Структура тестування архітектури бібліотеки
- Структура тестування на основі даних
- Структура тестування на основі ключових слів
- Структура гібридного тестування
- Структура розвитку, керована поведінкою
(натисніть на зображення, щоб переглянути збільшене)
Давайте обговоримо кожен із них детально.
Але перед цим я хотів би також зазначити, що, незважаючи на наявність цього фреймворку, користувач завжди має змогу побудувати та розробити власний фреймворк, який найкраще підходить для його / її потреб проекту.
# 1) Модульна база тестування
Модульна база тестування заснована на одній з відомих концепцій ООП - Абстракція. Фреймворк розділяє всю “Тестова програма” на ряд логічних та ізольованих модулів. Для кожного модуля ми створюємо окремий та незалежний тестовий сценарій. Таким чином, коли ці тестові скрипти беруться разом, будується більший тестовий скрипт, що представляє кілька модулів.
Ці модулі розділені шаром абстракції таким чином, що зміни, внесені в розділи програми, не дають впливу на цей модуль.
Плюси:
- Структура забезпечує високий рівень модуляризації, що призводить до спрощення та економічного обслуговування.
- Фреймворк є майже масштабованим
- Якщо зміни впроваджені в одній частині програми, потрібно виправити лише тестовий скрипт, що представляє цю частину програми, щоб усі інші частини залишалися недоторканими.
Мінуси:
- Впроваджуючи тестові скрипти для кожного модуля окремо, ми вбудовуємо тестові дані (Дані, за допомогою яких ми повинні проводити тестування) в тестові скрипти. Таким чином, щоразу, коли ми маємо проводити тестування з різним набором тестових даних, це вимагає маніпуляцій, які слід робити в тестових сценаріях.
# 2) Структура тестування архітектури бібліотеки
Структура тестування архітектури бібліотеки фундаментально і фундаментально побудована на модульній основі тестування з деякими додатковими перевагами. Замість того, щоб розділяти тестоване додаток на тестові скрипти, ми розділяємо додаток на функції, а точніше загальні функції можуть використовуватись і в інших частинах програми. Таким чином, ми створюємо загальну бібліотеку, що складається із загальних функцій для програми, що тестується. Тому ці бібліотеки можна викликати з тестових скриптів, коли це потрібно.
Основною основою фреймворку є визначення загальних кроків та групування їх у функції в бібліотеці та виклик цих функцій у тестових скриптах, коли це потрібно.
Приклад : Кроки входу можна об'єднати у функцію та зберегти у бібліотеці. Таким чином, всі тестові сценарії, які потрібні для входу в програму, можуть викликати цю функцію, замість того, щоб писати код знову.
Плюси:
- Як і модульна структура, ця структура також запроваджує високий рівень модуляризації, що також призводить до більш простого та економічного обслуговування та масштабованості.
- Оскільки ми створюємо загальні функції, які можуть ефективно використовуватися різними тестовими скриптами в рамках Framework. Таким чином, фреймворк забезпечує значну ступінь повторного використання.
Мінуси:
- Подібно до модульної основи, тестові дані вносяться до тестових скриптів, тому будь-яка зміна тестових даних потребує змін і в тестовому сценарії.
- З введенням бібліотек рамки трохи ускладнюються.
# 3) Структура тестування на основі даних
Під час автоматизації або тестування будь-якої програми іноді може знадобитися кілька разів протестувати одну і ту ж функціональність із різним набором вхідних даних. Таким чином, у таких випадках ми не можемо дозволити тестові дані вбудувати в тестовий скрипт. Тому рекомендується зберігати тестові дані в якійсь зовнішній базі даних поза тестовими сценаріями.
Data Driven Testing Framework допомагає користувачеві розділити логіку тестового сценарію та тестові дані один від одного. Це дозволяє користувачеві зберігати тестові дані у зовнішній базі даних. Зовнішні бази даних можуть бути файлами властивостей, файлами xml, файлами Excel, текстовими файлами, файлами CSV, сховищами ODBC тощо. Дані зазвичай зберігаються в парах 'ключ-значення'. Таким чином, ключ можна використовувати для доступу та заповнення даних у тестових скриптах.
Примітка : Тестові дані, що зберігаються у зовнішньому файлі, можуть належати матриці очікуваного значення, а також матриці вхідних значень.
Приклад:
Давайте розберемося в наведеному механізмі на прикладі.
Давайте розглянемо функціональність «Gmail - Вхід».
Крок 1: Першим і найголовнішим кроком є створення зовнішнього файлу, що зберігає тестові дані (вхідні дані та очікувані дані). Розглянемо, наприклад, аркуш Excel.
Крок 2: Наступним кроком є заповнення тестових даних у тестовому сценарії автоматизації. Для цього для читання даних тесту можна використовувати декілька API.
public void readTD(String TestData, String testcase) throws Exception { TestData=readConfigData(configFileName,'TestData',driver); testcase=readConfigData(configFileName,'testcase',driver); FileInputStream td_filepath = new FileInputStream(TestData); Workbook td_work =Workbook.getWorkbook(td_filepath); Sheet td_sheet = td_work.getSheet(0); if(counter==0) { for (int i = 1,j = 1; i <= td_sheet.getRows()-1; i++){ if(td_sheet.getCell(0,i).getContents().equalsIgnoreCase(testcase)){ startrow = i; arrayList.add(td_sheet.getCell(j,i).getContents()); testdata_value.add(td_sheet.getCell(j+1,i).getContents());}} for (int j = 0, k = startrow +1; k <= td_sheet.getRows()-1; k++){ if (td_sheet.getCell(j,k).getContents()==''){ arrayList.add(td_sheet.getCell(j+1,k).getContents()); testdata_value.add(td_sheet.getCell(j+2,k).getContents());}} } counter++; }
Вищезазначений метод допомагає читати тестові дані, а наступний крок тесту допомагає користувачеві ввести тестові дані в графічному інтерфейсі.
element.sendKeys (obj_value.get (obj_index));
Плюси:
- Найважливішою особливістю цього фреймворку є те, що він значно зменшує загальну кількість сценаріїв, необхідних для охоплення всіх можливих комбінацій тестових сценаріїв. Таким чином, для перевірки повного набору сценаріїв потрібно менша кількість коду.
- Будь-яка зміна матриці тестових даних не буде перешкоджати коду тестового сценарію.
- Збільшує гнучкість та ремонтопридатність
- Можна виконати один сценарій тесту, змінюючи значення даних тесту.
Мінуси:
- Процес складний і вимагає додаткових зусиль для створення тестових джерел даних та механізмів зчитування.
- Потрібно володіння мовою програмування, яка використовується для розробки тестових сценаріїв.
# 4) Структура тестування на основі ключових слів
Структура тестування, керована ключовими словами, є розширенням Тестової платформи, керованої даними, в тому сенсі, що вона не тільки відокремлює тестові дані від сценаріїв, але також зберігає певний набір коду, що належить тестовому сценарію, у зовнішній файл даних.
Цей набір коду відомий як Ключові слова, і тому фреймворк має таку назву. Ключові слова є самоорієнтовними щодо того, які дії потрібно виконати з додатком.
Ключові слова та тестові дані зберігаються у структурі, подібній до таблиці, і, отже, вона також широко розглядається як таблична структура. Зверніть увагу, що ключові слова та тестові дані - це сутності, незалежні від використовуваного інструменту автоматизації.
ПрикладТестовий приклад тестової основи, керованої ключовими словами
У наведеному вище прикладі ключові слова, такі як вхід, клацання та перевірка посилання, визначені в коді.
Залежно від характеру програми можна отримати ключові слова. І всі ключові слова можна повторно використовувати кілька разів в одному тестовому випадку. Стовпець Locator містить значення локатора, яке використовується для ідентифікації веб-елементів на екрані або даних тесту, які потрібно надати.
Всі необхідні ключові слова розроблені та розміщені в базовому коді фреймворку.
Плюси:
- На додаток до переваг, які надає тестування, кероване даними, фреймворк, керований ключовими словами, не вимагає від користувача володіння знаннями сценаріїв, на відміну від тестування на основі даних.
- Одне ключове слово можна використовувати в декількох тестових сценаріях.
Мінуси:
- Користувач повинен добре знати механізм створення ключових слів, щоб мати змогу ефективно використовувати переваги, передбачені фреймворком.
- Фреймворк ускладнюється поступово по мірі зростання та введення ряду нових ключових слів.
# 5) Структура гібридного тестування
Як випливає з назви, Hybrid Testing Framework - це комбінація більш ніж однієї з вищезазначених платформ. Найкраще в такій установці полягає в тому, що вона використовує переваги всіх видів пов'язаних фреймворків.
Прикладгібридних фреймворків
Тестовий аркуш містив би як ключові слова, так і Дані.
У наведеному вище прикладі стовпець ключових слів містить усі необхідні ключові слова, що використовуються в конкретному тестовому випадку, а стовпець даних керує всіма даними, необхідними в тестовому сценарії. Якщо будь-який крок не потребує введення, тоді його можна залишити порожнім.
# 6) Структура розвитку, керована поведінкою
Структура, що керується поведінкою, дозволяє автоматизувати перевірку функціональності у легко читаному та зрозумілому форматі для бізнес-аналітиків, розробників, тестувальників тощо. Такі рамки не обов'язково вимагають ознайомлення користувача з мовою програмування. Для BDD доступні різні інструменти, такі як огірок, Jbehave тощо. Детальна інформація про структуру BDD обговорюється далі в навчальному посібнику з огірків. Ми також обговорили деталі щодо мови огірків, щоб писати тестові кейси в огірку.
Компоненти системи тестування автоматизації
Незважаючи на те, що наведене вище графічне представлення фреймворку є зрозумілим, ми все-таки виділимо кілька моментів.
- Сховище об’єктів : Абревіатура сховища об’єктів як АБО складається із набору типів локаторів, пов’язаних з веб-елементами.
- Дані тесту: Вхідні дані, з якими буде тестуватися сценарій, і це можуть бути очікувані значення, з якими порівнюватимуться фактичні результати.
- Файл конфігурації / Константи / Налаштування середовища : У файлі зберігається інформація щодо URL-адреси програми, інформації про браузер тощо. Зазвичай ця інформація залишається статичною у всій структурі.
- Дженерики / Логіка програм / Читачі : Це класи, які зберігають функції, які можна часто використовувати в усьому фреймворку.
- Створення інструментів та безперервна інтеграція : Це інструменти, які допомагають можливостям фреймворку генерувати звіти про випробування, сповіщення електронною поштою та інформацію про реєстрацію.
Висновок
Фреймворки, проілюстровані вище, є найпопулярнішими фреймворками, що використовуються тестуючим братством. Є також різні інші рамки. Для всіх подальших підручників ми спиралися б на Структура тестування на основі даних .
У цьому підручнику ми обговорили основи Framework Automation. Ми також обговорили типи фреймворків, доступних на ринку.
Наступний підручник No21 : У наступному уроці ми коротко познайомимо вас із зразком фреймворку, MS Excel, який зберігатиме дані тесту, маніпуляції з Excel і т.д.
До цього сміливо задавайте свої запитання щодо систем автоматизації.
Рекомендована література
- 7 факторів, що впливають на тестову оцінку проекту автоматизації селену - Підручник з селену № 32
- Вступ до Selenium WebDriver - Підручник з селену №8
- Ефективні сценарії сценаріїв та усунення несправностей селену - Підручник селену No27
- Налагодження сценаріїв селену за допомогою журналів (Підручник Log4j) - Підручник селену No26
- 30+ найкращих підручників із селену: вивчіть селен на реальних прикладах
- Поглиблені підручники Eclipse для початківців
- Як знайти елементи в браузерах Chrome та IE для побудови сценаріїв селену - Підручник з селену No7
- Підручник з огірка селену: інтеграція огірка Java Selenium WebDriver