how develop test scripts using top 5 most popular test automation frameworks
Когато започнете да научавате за автоматизация на тестове, трябва да срещнете термина „рамка за автоматизация на тестовете“. Може би някои от вас се чувстват неудобно с този термин и започват да усещат, че това е нещо, което е трудно за разбиране и още по-трудно за изпълнение.
Този урок е написан с цел да ви помогне да разберете възможно най-просто рамките за автоматизация на тестовете. Прочетете всички уроци в това ' Тук ще намерите поредица от уроци за тестване на автоматизация .
Рамка за автоматизация на тестове (на много прост език) е „набор от правила.“ Правилата ни помагат да пишем скриптове по такъв начин, че да доведе до „по-ниска поддръжка“.
За да разберем напълно концепцията на рамката, първо трябва да научим как пишем прости скриптове и след това как да приложим рамка върху тях.
В автоматизацията на тестовете пишем скриптове. Скриптовете в основата си са около три „А“:
- АРГАНИЗАЦИЯ
- ДЕЙСТВИЕ
- ТВЪРДЕНИЕ
По-долу са дадени подробностите за всеки A, с примери:
# 1.АРГАНИЗАЦИЯили Идентификация на обект
Ние идентифицираме обекти (бутони, падащи менюта и т.н.) или по техните идентификатори, имена или по техните заглавия на прозорци и т.н.
В случай на уеб приложение, ние се идентифицираме по потребителски идентификатор, или по XPath, или по CSS, или по име на клас и т.н.
Вземете този пример за Selenium WebDriver (с C #), в който идентифицираме обекти, използвайки идентификатора. (Уеб приложение)
IWebElement txtServer = _webDriver.FindElement(By.Id('tfsServerURL'));
Друг пример от MS Coded UI (настолно приложение)
WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties[WinButton.PropertyNames.Name] = 'Add';
След идентифицирането ние подреждаме или съхраняваме тези обекти в UIMaps или Object Repository, за да ги използваме повторно в нашите скриптове. Ето защо тази стъпка се нарича АРГАНИЗАЦИЯ.
# две.ДЕЙСТВИЕвърху Идентифицирания обект
Когато обектите бъдат идентифицирани, ние извършваме някакви действия върху него или с мишка, или с клавиатура.Например, или щракваме, или щракваме двукратно, или задържим курсора на мишката върху него, или понякога плъзгаме. Понякога пишем на текстови полета. Така че всякакъв вид действия, които извършваме върху тези обекти, са обхванати в тази втора стъпка.
Пример 1 : (Селен WebDriver с C #)
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 или не.
инструменти за тестване на производителността за Java приложения
Пример А:
[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(); }
Какво ще научите:
- Какво не е наред с този скрипт?
- Има пет популярни рамки в автоматизацията на тестовете:
- # 1. Линейна рамка:
- # 2. Рамка за модулност:
- # 3. Рамка за управление на данни:
- # 4. Управлявана от ключови думи рамка:
- # 5. Рамка за автоматизация на хибридни тестове:
- Заключение
- Препоръчително четене
Какво не е наред с този скрипт?
Сценарият е лесен за разбиране и се надявам да разберете концепцията за три „А“ в горния пример. Но всичко не е наред с този сценарий.
Този скрипт не позволява лесна поддръжка. Вземете отново примера с калкулатора, ако трябва да напишем тестови случаи на всяка функция на калкулатора, ще има много тестови случаи. Ако има 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. Линейна рамка:
Характеристики
- Всичко свързано със скрипт се дефинира вътре в скриптовете.
- Не се интересува от абстракция и дублиране на код
- Записът и възпроизвеждането обикновено генерират линеен код
- Лесно е да започнете
- Кошмар за поддръжка.
Четейки горните 5 характеристики на Linear Framework, можем лесно да свържем нашия пример A с тях. Този пример основно използва Linear framework, Винаги нещо, свързано със скрипт, е дефинирано вътре в скрипта. The прозорец за обаждане и TxtResult са определени в скрипта. Скриптът не се интересува от абстракция и дублиране на код. Това също е кошмар за поддръжка, както обясних по-рано.
И така, защо да използваме тази рамка?
Тази рамка може да се използва в малки проекти, където няма много екрани на потребителския интерфейс. Също така, когато използваме инструмент за автоматизация за първи път, той обикновено генерира код в линейна форма. Така че можем да научим какъв код се генерира от инструмента за автоматизация за конкретни действия. Освен тези причини, тази рамка трябва да се избягва във вашите сценарии.
как да намеря мрежов ключ за сигурност
=> Вижте тук примера на Linear и Framework с ключови думи с пример.
# 2. Рамка за модулност:
Характеристики
- Обектите се дефинират еднократно и могат да се използват повторно във всички тестови методи.
- За отделните функционалности са създадени малки и точни методи
- Тестовият случай е събирането на тези малки методи и обекти за многократна употреба
- Това ни позволява да напишем поддържаем код.
Четейки горните характеристики, можем да свържем нашия пример Б с тези характеристики. В този пример ние създадохме абстракция чрез преместване на calWindow до върха и го дефинирайте в свойство, което може да се използва навсякъде. Създадохме две малки и независими функции, наречени ClickButton () и AddTwoNumbers () . Ние комбинираме тези две малки функции, за да създадем нашия окончателен скрипт, който тества функционалността „Добавяне“ на калкулатора.
Това води до по-лесна поддръжка. Ако се случи някаква промяна в потребителския интерфейс на калкулатора, трябва да променим само функциите. Нашите скриптове ще останат непокътнати. Тази рамка се използва силно в автоматизацията. Известната рамка за обекти на страници (която се използва със Селен) също е вид рамка за модулност. Разпространяваме цялото уеб приложение на отделни страници. Бутоните, падащите менюта и квадратчетата за отметка на всяка страница са дефинирани в класа на тази страница. Ако се случи някаква промяна на уебсайта, ние трябва да се променим само в този клас страници, а други страници остават непокътнати. Това води до по-добра поддръжка и по-лесна четливост на скриптове.
Единственият недостатък на тази рамка е, че тя изисква добри обектно-ориентирани концепции и силни умения за развитие. Ако имате такива, тази рамка е силно препоръчителна.
# 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.
# 4. Управлявана от ключови думи рамка:
Характеристики:
- И данните, и действията са дефинирани извън скрипта.
- Това изисква разработването на ключови думи за различни видове действия.
- Функционалността, която трябва да тестваме, е написана стъпка по стъпка в табличен вид, използвайки ключовите думи, които разработваме, и данните от теста. Ние съхраняваме тази таблица във външни файлове точно като рамка, управлявана от данни.
- Скриптът ще анализира тази таблица и ще извърши съответните действия.
- Позволява на ръчен тестер, който не знае за кодирането, да бъде част от автоматизацията до известна степен.
Пример 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 в друг инструмент.
Недостатъкът на тази рамка е, че трябва да измислите ключови думи за различни видове действия. В мащабните проекти ще има толкова много ключови думи, че трябва да запомните и организирате вашите скриптове и ключови думи. Това само по себе си се превръща в тромава задача в даден момент.
В някои сложни сценарии, когато обектите не могат лесно да бъдат идентифицирани и трябва да използваме координати на мишката и други техники, тази рамка не е много полезна.
частен сървър на world of warcraft pvp
Управляваната от ключови думи все още е предпочитана рамка за много тестери за автоматизация. Роботна рамка от Google е популярна рамка, управлявана от ключови думи, която се поддържа от активна общност.
# 5. Рамка за автоматизация на хибридни тестове:
Характеристики:
- Комбинацията от две или повече от горните техники, като се вземат предвид техните силни страни и се свеждат до минимум техните слабости.
- Рамката може да използва модулния подход заедно с управлявана от данни или управлявана от ключова дума рамка.
- Рамката може да използва скриптове, за да изпълнява някои задачи, които може да са твърде трудни за изпълнение в чисто основан на ключови думи подход.
С прости думи, Хибридна рамка, използвайте комбинацията от гореспоменатите техники. Можем да използваме управлявана от данни рамка, която също е модулна по своя характер. За някои тестови случаи можем да използваме подход, основан на ключови думи, а за останалите - модулен. Така че, когато смесим две или повече техники, споменати в тази статия, всъщност използваме хибриден подход.
Заключение
Надявам се, че рамката за автоматизация на тестовете вече не е страшен термин за вас. Опитах се да обясня възможно най-популярните рамки възможно най-просто.
Рамките са тук, за да улеснят живота ви. Те ви помагат да пишете поддържани и надеждни скриптове. Без да се използват рамки, полето за автоматизация на тестовете е кошмар. За всяка малка промяна в приложението трябва да промените кода си на стотици места.
Така че разбирането на тези рамки е задължително за всеки тестер, който иска вкус на тестовата автоматизация.
В нашата следващ урок в тази поредица ще научим „Изпълнение и отчитане на тестовата автоматизация“.
Ако съм пропуснал нещо в тази статия или трябва да зададете някакъв въпрос, моля не се колебайте да попитате в раздела за коментари.
PREV Урок # 4 | СЛЕДВАЩ Урок # 6
Препоръчително четене
- QTP Frameworks - Тестови рамки за автоматизация - Примери, управлявани от ключови думи и линейна рамка - QTP урок # 17
- SeeTest Automation Commands: Подробно обяснение с примери
- 10 най-популярни RPA инструменти за автоматизация на роботизирани процеси през 2021 г.
- Как се различава планирането на тестове за ръчни проекти и проекти за автоматизация?
- Най-популярните рамки за автоматизация на тестове с плюсове и минуси на всеки - Урок № 20 за селен
- Рамка за автоматизация на тестове без скриптове: инструменти и примери
- Автоматизация на тестовете - Специализирана кариера ли е? Могат ли нормалните тестери да правят и автоматизация?
- 25 най-добри рамки за тестване на Java и инструменти за тестване за автоматизация (част 3)