Тестови рамки за автоматизация - неща, които трябва да знаете!

Съдържание:

Anonim

В този урок ще научите

  • Какво е рамка?
  • Какво представлява рамката за автоматизация TEST?
  • Видове рамка за автоматизация
  • 1) Линейни скриптове - Запис и възпроизвеждане
  • 2) Тестовата рамка за архитектура на библиотеката.
  • 3) Рамка за тестване на данни.
  • 4) Рамка за тестване, управлявана от ключови думи или таблица.
  • 5) Хибридната рамка за автоматизация на тестовете.

Какво е рамка?

Вместо да предоставим книжна дефиниция на рамка, нека разгледаме един пример.

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

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

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

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

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

Въз основа на гореизложеното, Рамката може да бъде определена като набор от насоки, които при спазване дават полезни резултати.

Какво представлява рамката за автоматизация TEST?

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

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

1) Линейни скриптове
2) Тестова библиотечна архитектура.
3) Рамка за тестване на данни.
4) Рамка за тестване, управлявана от ключови думи или таблица.
5) Хибридната рамка за автоматизация на тестовете.

Нека ги разгледаме в детайли -

1) Линейни скриптове - Запис и възпроизвеждане

Това е най-простият от всички фреймворки и познат също като „Запис и възпроизвеждане" . В този фреймворк тестерът записва ръчно всяка стъпка (навигация и потребителски входове), вмъква контролни точки (стъпки за проверка) в първия кръг. След това той възпроизвежда записания сценарий в следващите кръгове.

Пример: Помислете за влизане в приложение за резервация на полет и проверка дали приложението се е заредило при успешно влизане. Тук тестерът просто ще запише стъпките и ще добави стъпки за проверка.

SystemUtil.Run "flight4a.exe", "", "", "open"Диалогов прозорец ("Вход"). WinEdit ("Име на агент:"). Задайте "Guru99"Диалогов прозорец ("Вход"). WinEdit ("Парола:"). Задайте "Меркурий"Диалогов прозорец ("Вход"). WinButton ("ОК"). Щракнете„Проверете дали прозорецът за резервация на полет е зареден след успешно влизанеПрозорец ("Резервация на полет"). Проверете CheckPoint ("Резервация на полет")

Предимства

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

Недостатъци

  • Малко повторно използване на скриптове
  • Тестовите данни са кодирани твърдо в скрипта
  • Кошмар за поддръжка

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

Той е известен също като "Структуриран скриптинг" или "Функционално разлагане".

В тази рамка тестовите скриптове първоначално се записват по метода "Record & Playback". По-късно често срещаните задачи в скриптовете се идентифицират и групират във Функции. Тези функции се извикват от главния тестов скрипт, наречен Driver, по различни начини за създаване на тестови случаи.

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

Вход за функция ()SystemUtil.Run "flight4a.exe", "", "", "open"Диалогов прозорец ("Вход"). WinEdit ("Име на агент:"). Задайте "Guru99"Диалогов прозорец ("Вход"). WinEdit ("Парола:"). Задайте "Меркурий"Диалогов прозорец ("Вход"). WinButton ("ОК"). ЩракнетеКрайна функция

Сега ще извикате тази функция в основния скрипт, както следва

Обадете се Вход ()---------------------------Други повиквания на функции / тестови стъпки.---------------------------

Предимства

  • По-високо ниво на повторно използване на кода се постига в структурираните скриптове в сравнение със „Запис и възпроизвеждане“
  • Скриптовете за автоматизация са по-евтини за разработване поради по-голямо повторно използване на кода
  • По-лесна поддръжка на скриптове

Недостатъци

  • Необходима е техническа експертиза за писане на скриптове, използвайки Test Library Framework.
  • Необходимо е повече време за планиране и подготовка на тестови скриптове.
  • Тестовите данни са трудно кодирани в скриптовете

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

В тази рамка, докато логиката на тестовия случай се намира в тестовите скриптове, тестовите данни се отделят и съхраняват извън тестовите скриптове. Тестовите данни се четат от външните файлове (Excel файлове, текстови файлове, CSV файлове, ODBC източници, DAO обекти, ADO обекти) и се зареждат във променливите в тестовия скрипт. Променливите се използват както за входни стойности, така и за стойности за проверка. Самите тестови скриптове се подготвят или с помощта на Linear Scripting или Test Library Framework.

Пример: Разработването на скрипт за вход за резервация на полет, използвайки този метод, ще включва две стъпки.

Стъпка 1) Създайте файл за тест - файл с данни, който може да бъде Excel, CSV или друг източник на база данни.

AgentName

Парола

Джими

живак

Тина

ЖИВАК

Бил

Живак

Стъпка 2) Разработете тест скрипт и направете препратки към вашия източник на данни за тест.

SystemUtil.Run "flight4a.exe", "", "", "open"Диалогов прозорец ("Login"). WinEdit ("Agent Name:"). Set DataTable ("AgentName", dtGlobalSheet)Диалогов прозорец („Вход“). WinEdit („Парола:“). Задаване на таблица с данни („Парола“, dtGlobalSheet)Диалогов прозорец ("Вход"). WinButton ("ОК"). Щракнете„Проверете Прозорецът за резервация на полет е зареденПрозорец ("Резервация на полет"). Проверете CheckPoint ("Резервация на полет")** Забележка "dtGlobalSheet" е стандартният Excel лист, предоставен от QTP.

Предимства

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

Недостатъци

  • Необходимо е повече време, за да планирате и подготвите както тестови скриптове, така и тестови данни

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

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

Има 3 основни компонента на Framework Driven Framework, а именно. Ключова дума, карта на приложението, функция на компонента.

Какво е ключова дума?

Ключовата дума е действие, което може да се извърши върху компонент на GUI. Напр. За текстовото поле на компонент на GUI някои ключови думи (действие) ще бъдат InputText, VerifyValue, VerifyProperty и т.н.

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

Карта на приложението предоставя именувани референции за компоненти на GUI. Картите на приложения не са нищо друго освен „ Обектно хранилище “

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

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

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

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

Обект

(КАРТА на приложението)

Действие

(КЛЮЧОВИ ДУМИ)

Аргумент
WinEdit (име на агент)
 Комплект
 Гуру99
WinEdit (парола)
 Комплект
 живак
WinButton (OK)
 Щракнете
Прозорец (Резервация на полет)
 Проверете
 Съществува

Стъпка 2 : Писане на код под формата на компонентни функции.

След като създадете таблицата (ите) си с данни, просто пишете програма или набор от скриптове, които четат във всяка стъпка, изпълняват стъпката въз основа на ключовата дума, съдържаща полето Action, извършват проверка на грешките и регистрират всякаква подходяща информация. Тази програма или набор от скриптове ще изглежда подобно на псевдо кода по-долу:

Основна функция (){Call ConnectTable (Име на таблицата) {// Функция за повикване за свързване към масата.while (Call TableParser ()! = -1) // Функция за извикване за анализиране и извличане на стойности от таблицата.{Предайте стойности на подходящи функции COMPONENT. Подобно на Set (Object Name, Argument) ex.Set (Agent Name, Guru99).}}Обадете се CloseConnection () // Функция за затваряне на връзката, след като е извършена цялата операция.} // Край на главното

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

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

Обект (КАРТА ЗА ПРИЛОЖЕНИЕ) Действие (КЛЮЧОВА ДУМА) Аргумент
WebEdit (UserName) Комплект Този имейл адрес е защитен от спам ботове. Трябва да имате активиран JavaScript, за да го видите.
WebEdit (парола) Комплект ххххх
WebButton (OK) Щракнете
Прозорец (Yahoo Mail) Проверете Натоварвания

Ако наблюдавате в този случай Наборът ключови думи, Щракнете, Проверете остават същите, за които вече са разработени съответните функции на компонентите. Всичко, което трябва да направите, е да промените картографирането на приложения (хранилище на обекти) от по-ранната резервация за полет на Yahoo Mail, с промяна в стойностите на аргументите и същият скрипт ще работи!

Предимства

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

Недостатъци

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

ЗАБЕЛЕЖКА: Въпреки че Micro Focus UFT се рекламира като KeyWord Driven Framework, не можете да постигнете пълна тестовост на инструмента и идейността на приложението, използвайки HP UFT.

5) Хибридната рамка за автоматизация на тестовете.

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

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

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

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

Пример : Използването на действия в QTP може да създаде скриптове Modualr

Примерен скрипт за вход

SystemUtil.Run "flight4a.exe", "", "", "open"Диалогов прозорец ("Вход"). WinEdit ("Име на агент:"). Задайте "Guru99"Диалогов прозорец ("Вход"). WinEdit ("Парола:"). Задайте "Меркурий"Диалогов прозорец ("Вход"). WinButton ("ОК"). Щракнете„Край на сценария

Сега можете да извикате това действие в основния скрипт, както следва -

RunAction ("Вход [Аргумент]", oneIteration)

Тестване на бизнес процеси (BPT)

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