Най-популярните рамки за автоматизация на тестове с плюсове и минуси на всеки - Урок № 20 за селен

most popular test automation frameworks with pros

В последните няколко урока по Селен обсъдихме различни често и често използвани команди в WebDriver , обработка на уеб елементи като уеб таблици, рамки и обработка на изключения в скриптове на Селен.

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

Докато вървим напред в серията Селен, бихме концентрирали фокуса си върху Създаване на рамка за автоматизация в следващите няколко предстоящи урока. Също така бихме хвърлили светлина върху различни аспекти на рамката за автоматизация, видовете рамки за автоматизация, предимствата от използването на рамка и основните компоненти, които съставляват рамка за автоматизация.

Какво ще научите:

• Какво е Framework?
• Тестова рамка за автоматизация
• Видове рамка за автоматизация на тестове
• # 1) Модулна базирана рамка за тестване
• # 2) Рамка за тестване на архитектура на библиотеката
• # 3) Рамка за тестване на данни
• # 4) Рамка за тестване, управлявана от ключови думи
• # 5) Хибридна рамка за тестване
• # 6) Рамка за развитие, управлявана от поведението
• Заключение
• Препоръчително четене

Какво е Framework?

Счита се, че дадена рамка е комбинация от определени протоколи, правила, стандарти и насоки, които могат да бъдат включени или следвани като цяло, така че да се възползват от предимствата на скелето, предоставено от Рамката.

Нека разгледаме сценарий от реалния живот.

Много често използваме асансьори или асансьори. Има няколко насоки, посочени в асансьора, които трябва да се следват и да се избягват, за да се постигне максимална полза и продължително обслужване от системата.

По този начин потребителите може да са забелязали следните насоки:

• Проверявайте максималния капацитет на асансьора и не се качвайте на асансьор, ако максималният капацитет е достигнал.
• Натиснете бутона за аларма в случай на извънредна ситуация или проблем.
• Оставете пътника да слезе от асансьора, ако има такъв, преди да влезе в асансьора и застанете далеч от вратите.
• В случай на пожар в сградата или ако има някаква случайна ситуация, избягвайте използването на асансьора.
• Не играйте и не скачайте вътре в асансьора.
• Не пушете в асансьора.
• Обадете се за помощ / помощ, ако вратата не се отваря или ако асансьорът изобщо не работи. Не се опитвайте да отворите насила вратите.

Може да има много повече правила или набори от насоки. По този начин тези указания, ако се спазват, правят системата по-полезна, достъпна, мащабируема и по-малко обезпокоена за потребителите.

Сега, докато говорим за „Тестови рамки за автоматизация“, нека насочим вниманието си към тях.

Тестова рамка за автоматизация

„Тестова рамка за автоматизация“ е скеле, което е поставено, за да осигури среда за изпълнение на скриптовете за тестване на автоматизацията. Рамката предоставя на потребителя различни предимства, които му помагат да разработват, изпълняват и докладват ефективно скриптове за тестове за автоматизация. По-скоро прилича на система, създадена специално за автоматизиране на нашите тестове.

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

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

Освен това, необходимостта от единна и стандартна рамка за автоматизация на тестовете възниква, когато имате куп разработчици, работещи върху различните модули на едно и също приложение и когато искаме да избегнем ситуации, при които всеки от разработчиците прилага свой подход към автоматизацията.

Забележка : Обърнете внимание, че рамката за тестване винаги е независима от приложението, т.е. може да се използва с всяко приложение, независимо от усложненията (като технологичен стек, архитектура и т.н.) на тестваното приложение. Рамката трябва да бъде мащабируема и поддържаема.

Предимство на рамката за автоматизация на тестовете

1. Многократна употреба на кода
2. Максимално покритие
3. Сценарий за възстановяване
4. Евтина поддръжка
5. Минимална ръчна намеса
6. Лесно отчитане

Видове рамка за автоматизация на тестове

Сега, когато имаме основна представа за това какво е рамка за автоматизация, в този раздел ще ви предвестим различните видове рамки за автоматизация на тестовете, които се предлагат на пазара. Също така бихме се опитали да хвърлим светлина върху техните плюсове и минуси и препоръки за използваемост.

Налице е различен набор от рамки за автоматизация, които се предлагат в наши дни. Тези рамки могат да се различават една от друга въз основа на тяхната подкрепа за различни ключови фактори за автоматизация като повторна употреба, лекота на поддръжка и т.н.

какво е тестване на черна кутия и бяла кутия с пример

Нека обсъдим няколкото най-често използвани рамки за автоматизация на тестовете:

1. Модулна базирана рамка за тестване
2. Рамка за тестване на библиотечна архитектура
3. Рамка за тестване на данни
4. Рамка за тестване на ключови думи
5. Рамка за хибридно тестване
6. Рамка за развитие, основана на поведение

(щракнете върху изображението, за да видите увеличено)

Нека обсъдим всеки от тях подробно.

Но преди това бих искал също да спомена, че въпреки че разполага с тази рамка, потребителят винаги се възползва да изгради и проектира своя собствена рамка, която е най-подходяща за неговите / нейните нужди на проекта.

# 1) Модулна базирана рамка за тестване

Модулната базирана рамка за тестване се основава на една от популярните концепции за ООП - Абстракция. Рамката разделя цялото „Тествано приложение“ на множество логически и изолирани модули. За всеки модул създаваме отделен и независим тестов скрипт. По този начин, когато тези тестови скриптове вземат заедно, изгражда по-голям тестов скрипт, представляващ повече от един модул.

Тези модули са разделени от абстракционен слой по такъв начин, че промените, направени в секциите на приложението, да не се отразят на този модул.

Професионалисти:

1. Рамката въвежда високото ниво на модуларизация, което води до по-лесна и рентабилна поддръжка.
2. Рамката е почти мащабируема
3. Ако промените са внедрени в една част от приложението, трябва да бъде фиксиран само тестовият скрипт, представляващ тази част от приложението, за да останат всички останали части незасегнати.

Минуси:

1. Докато внедряваме тестови скриптове за всеки модул поотделно, ние вграждаме тестовите данни (Данни, с които трябва да извършваме тестване) в тестовите скриптове. По този начин, когато трябва да тестваме с различен набор от тестови данни, той изисква манипулациите да се извършват в тестовите скриптове.

# 2) Рамка за тестване на архитектура на библиотеката

Рамката за тестване на архитектурата на библиотеката е фундаментално и в основата си изградена на базата на модули за тестване с някои допълнителни предимства. Вместо да разделяме тестваното приложение на тестови скриптове, ние разделяме приложението на функции или по-скоро общи функции могат да се използват и от другите части на приложението. По този начин ние създаваме обща библиотека, съставяща общи функции за тестваното приложение. Следователно тези библиотеки могат да се извикват от тестовите скриптове, когато е необходимо.

Основната фундаментална основа на рамката е да се определят общите стъпки и да се групират във функции в библиотека и да се извикат тези функции в тестовите скриптове, когато е необходимо.

Пример : Стъпките за влизане могат да се комбинират във функция и да се съхраняват в библиотека. По този начин всички тестови скриптове, които се изискват за влизане в приложението, могат да извикат тази функция, вместо да пишат кода отново.

Професионалисти:

1. Подобно на модулната рамка, тази рамка също така въвежда високото ниво на модуларизация, което води до по-лесна и икономична поддръжка и мащабируемост.
2. Тъй като създаваме общи функции, които могат да бъдат ефективно използвани от различните тестови скриптове в рамките. По този начин рамката въвежда голяма степен на повторно използване.

Минуси:

1. Подобно на модулна рамка, тестовите данни се вписват в тестовите скриптове, поради което всяка промяна в тестовите данни ще изисква промени и в тестовия скрипт.
2. С въвеждането на библиотеките рамката става малко сложна.

# 3) Рамка за тестване на данни

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

Data Driven Testing Framework помага на потребителя да отдели логиката на тестовия скрипт и тестовите данни един от друг. Позволява на потребителя да съхранява тестовите данни във външна база данни. Външните бази данни могат да бъдат файлове с свойства, xml файлове, Excel файлове, текстови файлове, CSV файлове, хранилища ODBC и др. Данните обикновено се съхраняват в двойки „ключ-стойност“. По този начин ключът може да се използва за достъп и попълване на данните в тестовите скриптове.

Забележка : Тестовите данни, съхранявани във външен файл, могат да принадлежат към матрицата на очакваната стойност, както и към матрицата на входните стойности.

как да настроите мрежова защитна стена

Пример:

Нека разберем горния механизъм с помощта на пример.

Нека разгледаме функционалността „Gmail - Login“.

Етап 1: Първата и най-важната стъпка е да създадете външен файл, който съхранява тестовите данни (входни данни и очаквани данни). Нека разгледаме например лист на Excel.

Стъпка 2: Следващата стъпка е да се попълнят данните от теста в скрипта за тест за автоматизация. За тази цел могат да се използват няколко API за четене на тестовите данни.

Горният метод помага за четене на тестовите данни, а долната стъпка на теста помага на потребителя да въведе тестовите данни в GUI.

element.sendKeys (obj_value.get (obj_index));

Професионалисти:

1. Най-важната характеристика на тази рамка е, че тя значително намалява общия брой скриптове, необходими за покриване на всички възможни комбинации от тестови сценарии. По този начин се изисква по-малко количество код за тестване на пълен набор от сценарии.
2. Всяка промяна в матрицата на тестовите данни няма да попречи на кода на тестовия скрипт.
3. Повишава гъвкавостта и поддръжката
4. Може да се изпълни единичен тестов сценарий, като се променят стойностите на тестовите данни.

Минуси:

1. Процесът е сложен и изисква допълнителни усилия за изготвяне на тестовите източници на данни и механизмите за четене.
2. Изисква владеене на език за програмиране, който се използва за разработване на тестови скриптове.

# 4) Рамка за тестване, управлявана от ключови думи

Управляваната от ключова дума рамка за тестване е разширение на Framework за тестване, управлявана от данни, в смисъл, че тя не само отделя тестовите данни от скриптовете, но и запазва определения набор от код, принадлежащ на тестовия скрипт, във външен файл с данни.

Този набор от кодове са известни като Ключови думи и следователно рамката е наречена така. Ключовите думи са самоуправляващи се относно това какви действия трябва да бъдат извършени върху приложението.

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

ПримерТестови случаи на Тестова рамка за управление на ключови думи

В горния пример ключовите думи като влизане, щракване и проверка на връзката са дефинирани в кода.
В зависимост от естеството на приложението могат да се извлекат ключови думи. И всички ключови думи могат да бъдат повторно използвани многократно в един тестов случай. Колоната Locator съдържа стойността на локатора, която се използва за идентифициране на уеб елементите на екрана или тестовите данни, които трябва да бъдат предоставени.

Всички необходими ключови думи са проектирани и поставени в основния код на рамката.

Професионалисти:

1. В допълнение към предимствата, предоставени от тестването, управлявано от данни, рамката, управлявана от ключови думи, не изисква от потребителя да притежава познания за скриптове, за разлика от тестването на данни.
2. Една ключова дума може да се използва в множество тестови скриптове.

Минуси:

1. Потребителят трябва да е добре запознат с механизма за създаване на ключови думи, за да може ефективно да използва предимствата, предоставени от рамката.
2. Рамката се усложнява постепенно с нарастването и въвеждането на редица нови ключови думи.

# 5) Хибридна рамка за тестване

Както подсказва името, Hybrid Testing Framework е комбинация от повече от една гореспомената рамка. Най-доброто нещо при такава настройка е, че тя използва предимствата на всички видове свързани рамки.

Примерна хибридната рамка

Тестовият лист ще съдържа както ключовите думи, така и данните.

В горния пример колоната с ключови думи съдържа всички необходими ключови думи, използвани в конкретния тестов случай, а колоната с данни управлява всички данни, необходими в тестовия сценарий. Ако някоя стъпка не се нуждае от въвеждане, тогава тя може да остане празна.

# 6) Рамка за развитие, управлявана от поведението

Рамка за поведенческо развитие позволява автоматизация на функционалните проверки в лесно четим и разбираем формат за бизнес анализатори, разработчици, тестери и др. Такива рамки не изискват непременно потребителят да бъде запознат с езика за програмиране. Налични са различни инструменти за BDD като краставица, Jbehave и др. Подробности за BDD рамката са обсъдени по-късно в урока за краставици. Също така обсъдихме подробности за езика корнишони, за да напишем тестови случаи в Краставица.

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

Въпреки че горното изобразително представяне на рамка е обяснително, все пак бихме подчертали няколко точки.

1. Хранилище на обекти : Съкращението на хранилището на обекти като ИЛИ се състои от набора от типове локатори, свързани с уеб елементи.
2. Данни от теста: Входните данни, с които ще бъде тестван сценарият, и това могат да бъдат очакваните стойности, с които ще бъдат сравнени действителните резултати.
3. Конфигурационен файл / Константи / Настройки на околната среда : Файлът съхранява информацията относно URL адреса на приложението, специфична информация за браузъра и т.н. Обикновено информацията остава статична в цялата рамка.
4. Дженерици / Програмна логика / Читатели : Това са класовете, които съхраняват функциите, които могат да бъдат често използвани в цялата рамка.
5. Изграждане на инструменти и непрекъсната интеграция : Това са инструментите, които подпомагат възможностите на рамката за генериране на тестови отчети, известия по имейл и информация за регистриране.

Заключение

Илюстрираните по-горе рамки са най-популярните рамки, използвани от тестващото братство. На мястото има и различни други рамки. За всички по-нататъшни уроци ще се основаваме на Рамка за тестване на данни .

В този урок обсъдихме основите на рамката за автоматизация. Също така обсъдихме видовете рамки, налични на пазара.

Следващ урок # 21 : В следващия урок бихме го направили накратко ще ви запозная с примерната рамка, MS Excel, която ще съхранява данните от теста, Excel манипулации и т.н.

Дотогава не се колебайте да задавате вашите запитвания за рамки за автоматизация.

Препоръчително четене

• 7 фактора, влияещи върху тестовата оценка на проекта за автоматизация на селен - Урок № 32 за селен
• Въведение в Selenium WebDriver - Урок № 8 за селен
• Ефективни сценарии за скриптове и отстраняване на неизправности при селен - Урок №27 за селен
• Отстраняване на грешки в скриптове за селен с регистрационни файлове (Урок за Log4j) - Урок за селен # 26
• 30+ най-добри урока за селен: Научете селен с реални примери
• Уроци за задълбочено затъмнение за начинаещи
• Как да намерим елементи в браузърите Chrome и IE за изграждане на скриптове за селен - Урок № 7 за селен
• Урок за краставици селен: Интеграция на краставица Java Selenium WebDriver