Фреймворк автоматизації тестування: ArchiТекстура та типи

Що таке Framework в автоматизованому тестуванні?

A Платформа автоматизації тестування це набір інструкцій, як-от стандарти кодування, обробка тестових даних, обробка репозиторію об’єктів тощо…, дотримання яких під час створення сценаріїв автоматизації дає корисні результати, як-от збільшення повторного використання коду, краща переносимість, зниження вартості обслуговування сценаріїв тощо. Це лише рекомендації, а не правила; вони не є обов’язковими, і ви все одно можете створювати сценарії, не дотримуючись інструкцій. Але ви втратите переваги наявності Framework.

Навіщо потрібен фреймворк?

Розглянемо приклад, щоб зрозуміти, навіщо потрібен Framework.

Я впевнений, що ви відвідували семінар/лекцію/конференцію, де учасників просили дотримуватися наступних вказівок –

• Учасники повинні зайняти свої місця за 5 хвилин до початку лекції.
• Візьміть із собою зошит і ручку для нотаток.
• Читайте м'язи пресуtracт, щоб ви мали уявлення про те, про що буде презентація.
• Мобільні телефони повинні бути налаштовані на беззвучний режим.
• Скористайтеся воротами на протилежному кінці доповідача, якщо вам потрібно вийти посеред лекції.
• Питання будуть відповідати наприкінці сесії.

Як ви вважаєте, чи зможете ви провести семінар БЕЗ дотримуючись цих рекомендацій?

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

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

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

Платформа автоматизації тестування ArchiТекстура: Ключові компоненти

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

• Тестовий скриптовий шар: Містить тестові випадки. Скрипти залишаються короткими, оскільки вони викликають функції повторного використання, а не повторюють кроки навігації.
• Бібліотека функцій: Зберігає спільні дії, такі як вхід, пошук та вихід, тому зміна робочого процесу вноситься один раз.
• Репозиторій об'єктів: Зіставляє зрозумілі назви з локаторами елементів графічного інтерфейсу. Під час зміни інтерфейсу редагується лише цей шар.
• Тестовий шар даних: Зберігає вхідні та очікувані значення в Excel, CSV або джерелах бази даних, а не всередині коду.
• Конфігураційний шар: Містить середовище URLс, параметри браузера, час очікування та облікові дані.
• Звітний рівень: Створює звіти про виконання, знімки екрана з помилками та журнали діагностики.
• Виконавчий рівень: Запускає пакети з сервера збірки, пов'язуючи автоматизацію з безперервна інтеграція.

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

Типи платформ автоматизації тестування

Нижче наведено різні типи платформ автоматизованого тестування:

1. Лінійне написання сценаріїв
2. Бібліотека тестів Archiтектурний фреймворк.
3. Керований даними Тестування Рамки.
4. Фреймворк для тестування на основі ключових слів або таблиць.
5. Фреймворк гібридної автоматизації тестування.

Розглянемо їх докладніше –

1) Лінійний сценарій – запис і відтворення

Це найпростіша з усіх платформ автоматизації тестування, також відома як «Запис і відтворення». В цьому Тестування автоматизації Framework, тестер вручну записує кожен крок (навігація та введення користувача), вставляє контрольні точки (кроки перевірки) у першому раунді. Потім він відтворює записаний сценарій у наступних раундах.

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

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
Dialog("Login").WinEdit("Password:").Set "Mercury"
Dialog("Login").WinButton("OK").Click
'Check Flight Reservation Window has loaded after successful log-on
Window("Flight Reservation").Check CheckPoint("Flight Reservation")

Переваги

• Найшвидший спосіб створити сценарій
• Експертиза автоматизації не потрібна
• Найпростіший спосіб дізнатися про функції інструменту тестування

Недоліки

• Невелике повторне використання сценаріїв
• Тестові дані жорстко закодовані в сценарій
• Кошмар технічного обслуговування

2) Бібліотека тестів Archiтектурний фреймворк

Він також відомий як «Структурований сценарій» or «Функціональна декомпозиція».

У цьому Automation Testing Framework тестові сценарії спочатку записуються "Запис і відтворення”Метод. Laterзагальні завдання всередині сценаріїв ідентифікуються та групуються у Функції. Ці функції викликаються головним тестовим сценарієм Водій різними способами для створення тестів.

приклад: Використовуючи той самий приклад, що й вище, функція для входу в Бронювання авіаквитків виглядатиме так.

Function Login()
  SystemUtil.Run "flight4a.exe","","","open"
  Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
  Dialog("Login").WinEdit("Password:").Set "Mercury"
  Dialog("Login").WinButton("OK").Click
End Function

Тепер ви викличете цю функцію в основному сценарії наступним чином

Call Login()
---------------------------
'Other Function calls / Test Steps.
---------------------------

Переваги

• Вищий рівень повторного використання коду досягається в структурованих сценаріях порівняно з «записом і відтворенням»
• Розробка сценаріїв автоматизації є дешевшою через більшу кількість повторного використання коду
• Простіше обслуговування сценаріїв

Недоліки

• Для написання сценаріїв за допомогою Test Library Framework необхідна технічна експертиза
• Потрібно більше часу для планування та підготовки тестових сценаріїв.
• Тестові дані жорстко закодовані в сценаріях

3) Система тестування на основі даних

У цій Рамці, поки Тестовий випадок Логіка знаходиться в тестових скриптах, тестові дані відокремлені та зберігаються поза тестовими скриптами. Тестові дані зчитуються із зовнішніх файлів (файли Excel, текстові файли, CSV-файли, джерела ODBC, об'єкти DAO, об'єкти ADO) та завантажуються у змінні всередині тестового скрипта. Змінні використовуються як для вхідних значень, так і для значень перевірки. Самі тестові скрипти готуються або за допомогою лінійного скриптингу, або Test Library Framework. Метод пояснюється далі в тестування на основі даних навчальний посібник.

приклад: Розвитокping Скрипт входу для бронювання авіаквитків, що використовує цей метод, складатиметься з двох кроків.

Крок 1) Створіть тестовий файл даних, який може бути Excel, CSV або будь-яким іншим джерелом бази даних.

Крок 2) Розробіть тестовий сценарій і зробіть посилання на своє джерело тестових даних.

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set DataTable("AgentName", dtGlobalSheet)
Dialog("Login").WinEdit("Password:").Set DataTable("Password", dtGlobalSheet)
Dialog("Login").WinButton("OK").Click
'Check Flight Reservation Window has loaded
Window("Flight Reservation").Check CheckPoint("Flight Reservation")
'Note "dtGlobalSheet" is the default excel sheet provided by QTP.

Переваги

• Зміни тестових сценаріїв не впливають на тестові дані
• Тестові випадки можна виконувати з кількома наборами даних
• Різноманітність тестових сценаріїв можна виконати, просто змінивши тестові дані у файлі зовнішніх даних

Недоліки

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

4) Система тестування на основі ключових слів або таблиць

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

Існує 3 основні компоненти системи, керованої ключовими словами, а саме. Ключове слово, Карта програми, Функція компонента.

Ключове слово — це дія, яку можна виконати над компонентом GUI. Пр. Для текстового поля компонента GUI деякі ключові слова (дія) будуть InputText, VerifyValue, VerifyProperty тощо.

Що таке карта додатків?

Карта програми надає іменовані посилання для компонентів GUI. Карти програм – це не що інше, як «Репозиторій об'єктів"

Що таке функція компонента?

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

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

крок 1: Створення таблиці даних (на відміну від таблиці тестових даних, створеної в Data Driven Framework). Ця таблиця даних містить дії, які потрібно виконати над об’єктами GUI, і відповідні аргументи, якщо такі є. Кожен рядок представляє один тестовий крок.

крок 2: Письмо Code у вигляді компонентних функцій.

Створивши таблицю(и) даних, ви просто пишете програму або набір сценаріїв, які зчитують кожен крок, виконують крок на основі ключового слова, яке містить поле «Дія», виконує перевірку помилок і записує будь-яку відповідну інформацію. Ця програма або набір сценаріїв виглядатиме подібно до наведеного нижче псевдокоду:

Function main()
{
  Call ConnectTable(Name of the Table) { //Calling Function for connecting to the table.
  while (Call TableParser() != -1) //Calling function for Parsing and extracting values from the table.
  {
    Pass values to appropriate COMPONENT functions. Like Set(Object Name, Argument) ex. Set(Agent Name, Guru99).
  }
}
  Call CloseConnection() //Function for Closing connection after all the operation has been performed.
} //End of main

Це все для Keyword Driven Framework.

Перевага Keyword Driven Framework полягає в тому, що ключові слова можна використовувати повторно. Щоб зрозуміти це, подумайте, що ви хочете перевірити операцію входу на веб-сайт, наприклад YAHOO MAIL. Таблиця буде виглядати так –

Якщо ви помітите, що в цьому випадку ключові слова Set, Click, Verify залишаються незмінними, для яких відповідні функції компонента вже розроблені, вам потрібно лише змінити карту застосунків.ping (Сховище об'єктів) з попереднього бронювання авіаквитків до Yahoo Mail , зі зміною значень аргументів і той самий скрипт буде працювати!

Переваги

• Забезпечує високу можливість повторного використання коду
• Тестовий інструмент Незалежний
• Незалежно від програми, що тестується, той самий сценарій працює для AUT (з деякими обмеженнями)
• Тести можуть бути розроблені з AUT або без нього

Недоліки

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

ПРИМІТКА : Навіть якщо OpenText UFT Один (раніше Micro Focus UFT) рекламує себе як фреймворк, керований ключовими словами, ви не можете досягти повної незалежності інструментів тестування та додатків, використовуючи його.

5) Система автоматизації гібридного тестування

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

PS: Інші фреймворки автоматизації, про які варто згадати

Модульність тестування Framework

У цій структурі звичайні завдання в сценарії тестування згруповані разом як модулі.

ПрикладВикористання дій у QTP використання може створювати модульні скрипти

Зразок сценарію для входу

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
Dialog("Login").WinEdit("Password:").Set "Mercury"
Dialog("Login").WinButton("OK").Click
'End of Script

Тепер ви можете викликати цю дію в основному сценарії наступним чином –

RunAction ("Login[Argument]", oneIteration)

Тестування бізнес-процесів (BPT)

Ці інфраструктури автоматизації розбивають великі бізнес-процеси на компоненти, які можна багаторазово використовувати в одному або різних тестових сценаріях. Наприклад, бізнес-процес бронювання авіаквитка розділений на такі компоненти, як «Вхід», «Пошук рейсів», «Бронювання», «Оплата та вихід», які можна повторно використовувати в тому самому бізнес-процесі або в інших процесах. Крім того, BPT сприяє тіснішій координації між МСП та інженерами з автоматизації.

Як вибрати правильний фреймворк для автоматизації тестування

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

Перш ніж брати на себе зобов'язання, обміркуйте ці питання:

1. Як довго проживе люкс? Роки підтримки виправдовують високі початкові інвестиції в дизайн, орієнтований на ключові слова, або гібридний дизайн. Короткий проект цього не робить.
2. Хто пише тести? Якщо тестувальники, які працюють вручну, створюють кейси, таблиця ключових слів дозволяє їм працювати без вивчення мови сценаріїв.
3. Наскільки нестабільний інтерфейс? Часта зміна екрану робить окремий репозиторій об'єктів необхідним, інакше кожен скрипт потребує редагування.
4. Яка потрібна варіація даних? Багато комбінацій вхідних даних безпосередньо вказують на дизайн, керований даними.
5. Який інструмент вже використовується? Каркас повинен відповідати обраному інструмент автоматизації та мова, яку знає команда, наприклад Selenium з Java or Cucumber.

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

Переваги Test Automation Framework Archiтектура

Нижче наведено переваги архітектури автоматизації тестування.

• Система автоматизації тестування допомагає зменшити ризики та витрати
• Це підвищує ефективність тестів
• Це допомагає зменшити витрати на обслуговування
• Дозволяє повторно використовувати код
• Це дозволяє досягти максимального охоплення тестом
• Це максимізує функціональність програми
• Допомагає зменшити дублювання тестів
• Це допомагає підвищити ефективність і продуктивність тестування завдяки автоматизації тестування

Поширені запитання