Меню

Як розробляти тестові сценарії за допомогою 5 найпопулярніших платформ автоматизації тестів (приклади)

how develop test scripts using top 5 most popular test automation frameworks

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

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

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

Структура автоматизації тестів (дуже простою мовою) - це 'набір правил'. Правила допомагають нам писати сценарії таким чином, що призводить до 'нижчого обслуговування'.

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

тестові скрипти з використанням систем автоматизації

Для автоматизації тестів ми пишемо сценарії. Сценарії в основному складаються з трьох «A»:

  1. УСТАНОВКА
  2. ДІЯ
  3. СТВЕРДЖЕННЯ

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

№1.УСТАНОВКАабо Ідентифікація об’єкта

Ми ідентифікуємо об'єкти (кнопки, випадаючі меню тощо) або за їх ідентифікаторами, іменами, або за назвою вікон тощо.

У випадку веб-програми ми ідентифікуємо за ідентифікатором користувача, або за XPath, або за CSS, або за назвою класу тощо. Якщо нічого не працює, ми ідентифікуємо об'єкти за допомогою координат миші (але це не надійний метод ідентифікації об'єкта)

Візьмемо цей приклад Selenium WebDriver (з C #), в якому ми ідентифікуємо об’єкти за допомогою ідентифікатора. (Веб-додаток)

IWebElement txtServer = _webDriver.FindElement(By.Id('tfsServerURL'));

Ще один приклад із кодованого інтерфейсу MS (настільний додаток)

WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties(WinButton.PropertyNames.Name) = 'Add';

Після ідентифікації ми розміщуємо або зберігаємо ці об'єкти в UIMaps або Object Repository для повторного використання їх у наших сценаріях. Ось чому цей крок називається УПРАВЛІННЯМ.

# два.ДІЯна ідентифікованому об’єкті

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

Приклад 1 : (Selenium WebDriver з C #)

тестовий веб-сайт на вразливість введення SQL
txtServer.Clear(); txtServer.SendKeys(“Some sample text”);

Приклад 2 : (Інтерфейс користувача, кодований MS за допомогою C #)

Mouse.Click(buttonAdd);

№3.СТВЕРДЖЕННЯ

Твердження в основному полягає у перевірці об’єкта з певним очікуваним результатом. Наприклад, якщо натиснути 2 + 3 на калькуляторі, на екрані повинно з'явитися 5. У цьому випадку очікуваний результат - 5. Це поняття вже пояснено в нашому першому навчальному посібнику.

Тут ми наводимо приклад твердження:

Assert.AreEqual('5', txtResult.DisplayText);

Майже кожен сценарій, написаний в автоматичній системі тестування, містить ці три речі: аранжування, дія та твердження.

Тепер погляньте на повний сценарій, який містить усі ці кроки. Скрипт відкриє калькулятор, натисніть 1 + 6, а потім перевірте, чи відображається на екрані 7 чи ні.

тестовий скрипт для середовища автоматизації

Приклад А:

(TestMethod) (TestMethod) public void TestCalculator() { var app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //Object identification part (ARRANGEMENT) //----*Calculator Window----*// WinWindow calWindow = new WinWindow(app); calWindow.SearchProperties(WinWindow.PropertyNames.Name) = 'Calculator'; calWindow.SearchProperties(WinWindow.PropertyNames.ClassName) = 'CalcFrame'; //----*Button1 ----*// WinButton btn1 = new WinButton(calWindow); btn1.SearchProperties(WinButton.PropertyNames.Name) = '1'; //----*Button Add ----*// WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties(WinButton.PropertyNames.Name) = 'Add'; //----*Button 6 ----*// WinButton btn6 = new WinButton(calWindow); btn6.SearchProperties(WinButton.PropertyNames.Name) = '6'; //----*Button Equals ----*// WinButton btnEquals = new WinButton(calWindow); btnEquals.SearchProperties(WinButton.PropertyNames.Name) = 'Equals'; //----*Text Box Results----*// WinText txtResult = new WinText(calWindow); txtResult.SearchProperties(WinText.PropertyNames.Name) = 'Result'; //(ACTIONS Part) // Click '1' button Mouse.Click(btn1); // Click 'Add' button Mouse.Click(btnAdd); // Click '6' button Mouse.Click(btn6); // Click 'Equals' button Mouse.Click(btnEquals); //evaluate the results (ASSERTIONS) Assert.AreEqual('7', txtResult.DisplayText, “Screen is not displaying 7); //close the application app.Close(); }

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

Що не так із цим сценарієм?

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

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

Наприклад, візьмемо приклад кнопки ADD у сценарії.

WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties(WinButton.PropertyNames.Name) = 'Add';

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

btnAdd.SearchProperties(WinButton.PropertyNames.Name) = 'Plus';

Тож ми маємо вдосконалити цей тест. Ми повинні дотримуватися відомого принципу СУХОГО в кодуванні. DRY розшифровується як «Не повторюйся». Ми повинні писати частину ідентифікації об'єкта таким чином, щоб об’єкт повинен бути ідентифікований лише в одному місці і повинен називатися скрізь.

Погляньте на вдосконалений сценарій.

Приклад В:

//defining the objects outside the script and only once. ApplicationUnderTest app = null; public WinWindow calWindow { get { WinWindow _calWindow = new WinWindow(app); _calWindow.SearchProperties(WinWindow.PropertyNames.Name) = 'Calculator'; _calWindow.SearchProperties(WinWindow.PropertyNames.ClassName) = 'CalcFrame'; return _calWindow; } } public WinText txtResult { get { WinText _txtResult = new WinText(calWindow); _txtResult.SearchProperties(WinText.PropertyNames.Name) = 'Result'; return _txtResult; } } //making functions for similar kind of tasks public void ClickButton(string BtnName) { WinButton button = new WinButton(calWindow); button.SearchProperties(WinButton.PropertyNames.Name) = BtnName ; Mouse.Click(button); } public void AddTwoNumbers(string number1, string number2) { ClickButton(number1); ClickButton('Add'); ClickButton(number2); ClickButton('Equals'); } //Test case becomes simple and easy to maintain. (TestMethod) public void TestCalculatorModular() { app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations AddTwoNumbers('6', '1'); //evaluate the results Assert.AreEqual('7', txtResult.DisplayText, “screen is not displaying 7”); //close the application app.Close(); }

У наведеному вище прикладі ми розділили calWindow і txtResult об'єктів та перемістіть їх у верхню частину, щоб їх можна було використовувати в різних методах тестування. Ми визначили їх лише один раз, і ми можемо використовувати їх у скільки завгодно тестів.

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

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

Дивитися також=> Навіщо нам потрібна система автоматизації тестів?

Існує п'ять популярних фреймворків з автоматизації тестів :

  1. Лінійний
  2. Модульність
  3. На основі даних
  4. Управління ключовими словами
  5. Гібридний

Зараз ми пояснимо кожен фреймворк за допомогою його характеристик.

№1. Лінійна структура:

Характеристика

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

Прочитавши вищезазначені 5 характеристик Linear Framework, ми можемо легко зв’язати наш Приклад A з ними. Цей приклад в основному використовує лінійний фреймворк. Усе, що стосується сценарію, визначається всередині сценарію. вікно дзвінка і TxtResult визначаються всередині сценарію. Сценарій не дбає про абстракцію та дублювання коду. Це також кошмар обслуговування, як я вже пояснював раніше.

То чому ми повинні використовувати цей фреймворк?

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

=> Подивіться тут приклад Прикладу лінійних та ключових слів із прикладом QTP.

№2. Рамка модульності:

Характеристика

  • Об'єкти визначаються один раз і багаторазово використовуються у всіх методах тестування.
  • Невеликі і точні методи створюються для окремих функціональних можливостей
  • Тестовий випадок - це збір цих малих методів та об’єктів багаторазового використання
  • Це дозволяє нам писати підтримуваний код.

Читаючи вищезазначені характеристики, ми можемо пов’язати наш Приклад В з цими характеристиками. У цьому прикладі ми створили абстракцію, перемістивши calWindow вгору та визначте його всередині властивості, яку можна використовувати скрізь. Ми створили дві невеликі та незалежні функції, які називаються ClickButton () і AddTwoNumbers () . Ми поєднуємо ці дві невеликі функції, щоб створити наш остаточний сценарій, який перевіряє функцію “Додати” калькулятора.

Це призводить до спрощення обслуговування. Якщо в інтерфейсі калькулятора відбувається якась зміна, ми маємо змінювати лише функції. Наші сценарії залишаться цілими. Цей фреймворк широко використовується в автоматизації. Відомий фреймворк Page Object (який використовується з Selenium) також є своєрідною структурою модульності. Ми розподіляємо весь веб-додаток на окремі сторінки. Кнопки, розкривні меню та прапорці кожної сторінки визначаються всередині класу цієї сторінки. Якщо на веб-сайті відбуваються будь-які зміни, ми маємо змінюватися лише в цьому класі сторінок, а інші сторінки залишаються цілими. Це призводить до кращого обслуговування та легшої читабельності сценаріїв.

Єдиним недоліком цієї основи є те, що вона вимагає хороших об’єктно-орієнтованих концепцій та потужних навичок розвитку. Якщо у вас є такі, настійно рекомендуємо цей фреймворк.

№3. Управління даними:

Характеристики:

  • Тестові дані (вхідні та вихідні значення) відокремлюються від сценарію та зберігаються у зовнішніх файлах. Це може бути файл CSV, електронна таблиця Excel або база даних.
  • Коли сценарій виконується, ці значення вибираються із зовнішніх файлів, зберігаються у змінних і замінюють жорстко закодовані значення, якщо вони є.
  • Дійсно корисно в місцях, де один і той же тестовий приклад повинен запускатися з різними входами.

Приклад С:

Ми хочемо запустити тест додавання з трьома різними входами.

Дані є
7 + 2 = 9
5 + 2 = 7
3 + 2 = 5

Ми зберегли ці дані (як вхідні, так і вихідні) у зовнішньому файлі CSV.

Приклад фреймворку, керованого даними

(DataSource('Microsoft.VisualStudio.TestTools.DataSource.CSV', '|DataDirectory|\data.csv', 'data#csv', DataAccessMethod. Sequential ), DeploymentItem('TestCalc\data.csv'), TestMethod) public void TestCalculatorDataDrivsen() { app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations AddTwoNumbers(FromCSV.ADD1, FromCSV.ADD2); //evaluate the results Assert.AreEqual(FromCSV.Sum, txtResult.DisplayText); //close the application app.Close(); }

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

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

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

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

=> Дивіться тут приклад керованого даними та гібридного фреймворку з прикладом QTP.

No4. Управління ключовими словами:

Характеристики:

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

Приклад D:

Ми визначили дані (наприклад, 1 + 3 = 4), а також дії (наприклад, клацання, очищення тощо) у файлі Excel у табличній формі.

Приклад фреймворку, керованого ключовими словами

Сценарій стане приблизно таким (наведений нижче код написаний лише для розуміння)

(TestMethod) public void TestCalculator() { app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); Table tb = ReadFromExcel(); Foreach(WinRow row in tb) { WinCell Window = row.Cells(“Window”); WinCell Control = row.Cells(“Control”); WinCell Action = row.Cells(“Action”); WinCell Arguments = row.Cells(“Arguments”); UITestControl c = GetControl(Control.Text,Window.Text); If(Action.Text == “Click”) Mouse.Click (c); If (Action.Text == “Clear”) c.Clear(); if(Action.Text == “Verify Result”) Assert.AreEqual(c.Text, Arguments.Text) //….and so on } }

Наведений вище сценарій - це лише синтаксичний аналізатор файлу Excel. Він аналізує файл Excel за рядком і шукає ключові слова для виконання відповідних дій. Якщо він знаходить ключове слово “Клацніть”, він клацне на визначений об’єкт. Якщо він знайде “Перевірити результат”, він виконає твердження.

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

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

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

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

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

У деяких складних сценаріях, коли об’єкти неможливо легко ідентифікувати, і нам потрібно використовувати координати миші та інші прийоми, ця структура не надто корисна.

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

№5. Структура автоматизованої гібридної перевірки:

Характеристики:

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

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

Висновок

Я сподіваюся, що рамки автоматизації тестів для вас зараз не є страшним терміном. Я намагався пояснити найпопулярніші фреймворки якомога простіше.

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

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

В нашому наступний підручник у цій серії ми дізнаємось «Виконання та звітування про автоматизацію тестів».

як додати репозиторій svn в eclipse -

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

НАЗАД Підручник No4 | НАСТУПНИЙ підручник No6

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

^