Рамка за автоматизирано тестване: Archiтекстура и видове

Какво е рамка в автоматизираното тестване?

A Рамка за автоматизация на тестове е набор от насоки като стандарти за кодиране, обработка на тестови данни, обработка на хранилище на обекти и т.н., които, когато се следват по време на скриптове за автоматизация, дават полезни резултати като увеличено повторно използване на кода, по-висока преносимост, намалени разходи за поддръжка на скриптове и т.н. Това са само насоки, а не правила; те не са задължителни и все пак можете да пишете скриптове, без да следвате указанията. Но ще пропуснете предимствата на наличието на Framework.

Защо имате нужда от Framework?

Нека разгледаме един пример, за да разберем защо имате нужда от Framework.

Сигурен съм, че сте присъствали на семинар/лекция/конференция, където участниците са били помолени да спазват следните указания –

• Участниците трябва да заемат местата си 5 минути преди началото на лекцията.
• Носете тефтер и химикал за водене на бележки.
• Прочетете коремните мускулиtracт, така че да имате представа за какво ще бъде презентацията.
• Мобилните телефони трябва да бъдат настроени на безшумен режим.
• Използвайте изходните порти в противоположния край на говорителя, ако искате да напуснете по средата на лекцията.
• Въпросите ще се задават в края на сесията.

Мислите ли, че можете да проведете семинар БЕЗ спазване на тези насоки?

Отговорът е голям YES! Разбира се, можете да проведете семинар/лекция/конференция/демонстрация без горните указания.. всъщност някои от нас няма да ги следват, въпреки че са изложени!

Но ако се спазват указанията, това ще доведе до благоприятен резултат, като например намалено нежелано въздействие върху аудиторията.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 „Функционално разлагане“.

В тази рамка за автоматизирано тестване тестовите скриптове първоначално се записват от „Запис и възпроизвеждане”Метод. 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 Component Textbox някои ключови думи (Action) биха били InputText, VerifyValue, VerifyProperty и т.н.

Какво представлява картата на приложението?

Картата на приложението предоставя наименувани препратки за GUI компоненти. Картите на приложенията не са нищо друго освен „Хранилище на обекти"

Какво е компонентна функция?

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

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

Стъпка : Създаване на таблица с данни (различна от таблица с тестови данни, създадена в Data Driven Framework). Тази таблица с данни съдържа действие, което трябва да се извърши върху GUI обекти и съответните аргументи, ако има такива. Всеки ред представлява една тестова стъпка.

Стъпка : Писане 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 е, че ключовите думи могат да се използват повторно. За да разберете това, помислете, че искате да потвърдите операцията за влизане в уебсайт, например YAHOO MAIL. Таблицата ще изглежда така -

Ако в този случай наблюдавате, че ключовите думи „Set“, „Click“ и „Verify“ остават същите, за които съответните функции на компонентите вече са разработени. Всичко, което трябва да направите, е да промените картата на приложението.ping (Хранилище на обекти) от по-ранна резервация на полет до Yahoo Mail , с промяна в стойностите на аргументите и същият скрипт ще работи!

Предимства

• Осигурява висока възможност за повторно използване на кода
• Независим тестов инструмент
• Независимо от тестваното приложение, същият скрипт работи за AUT (с някои ограничения)
• Тестовете могат да бъдат проектирани със или без AUT

Недостатъци

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

ЗАБЕЛЕЖКА: Въпреки че OpenText UFT Едно (преди това Micro Focus UFT) се рекламира като рамка, управлявана от ключови думи, не можете да постигнете пълна независимост на инструментите за тестване и приложенията, използвайки я.

5) Рамката за автоматизиране на хибридни тестове

Както подсказва името, тази рамка е комбинацията от една или повече рамки за автоматизация, обсъдени по-горе, като се вземат предвид силните им страни и се опитват да смекчат слабите им страни. Рамката за автоматизация на хибридния тест QA е това, в което повечето рамки за автоматизация на тестове се развиват с течение на времето и множество проекти. Maximum индустрията използва рамка на ключови думи в комбинация от метод на разлагане на функцията.

PS: Други рамки за автоматизация, които си струва да се споменат, са

Тествайте модулната рамка

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

ПримерИзползване на действия в 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текстура

Следват предимствата на архитектурата на рамката за автоматизация на тестове:

• Рамката за автоматизиране на тестове помага за намаляване на риска и разходите
• Подобрява ефективността на тестовете
• Помага за намаляване на разходите за поддръжка
• Позволява повторно използване на код
• Позволява постигане на максимално покритие на теста
• Той увеличава максимално функционалността на приложението
• Помага за намаляване на дублирането на тестови случаи
• Помага за подобряване на ефективността и производителността на теста с автоматизация на теста

Въпроси и Отговори