Меню

Автоматизирано тестване на регресия: Предизвикателства, процес и стъпки

automated regression testing

Опитайте Нашия Инструмент За Премахване На Проблемите

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

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

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

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

=> Щракнете тук за пълната серия за тестване на регресия.

Автоматизирано тестване на регресия

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

Автоматизирано тестване на регресия

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

Въпросите бяха като:

  • Възможно ли е да се използват Agile методологии при автоматизирано тестване?
  • Мога ли да използвам традиционни инструменти?
  • Трябва ли да се наложи да използвам инструменти с отворен код?
  • Какви са предизвикателствата, пред които трябва да се изправя, ако прилагам автоматизация в гъвкавата среда?

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

Agile Projects представят свои собствени предизвикателства пред екипа за автоматизация. Методологията Agile набляга на екипното сътрудничество и честата доставка на продукт. Фактори като неясен обхват на проекта, множество итерации, минимална документация, ранни и чести нужди на автоматизацията и активно участие на заинтересованите страни и т.н., изискват много предизвикателства от екипа за автоматизация.

Автоматизирано тестване: Предизвикателства в гъвкавата среда

Има няколко Agile предизвикателства пред екипа за автоматизация. A малко от тях са дадени накратко по-долу.

Предизвикателство 1:Фаза на изискване

Разработчикът на Test Automation улавя изискванията под формата на „потребителски истории“, които са кратки описания на съответната за клиента функционалност.

Всяко изискване трябва да бъде приоритизирано, както следва:

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

След като се установят приоритетите, се планират „итерации“ за освобождаване. Обикновено всяка итерация на Agile освобождаване отнема от 1 до 3 месеца. Клиентите / хората от софтуера си позволяват да направят твърде много промени в изискванията. Понякога тези промени са толкова нестабилни, че итерациите се отблъскват. Тези промени са по-големи предизвикателства при прилагането на процеса на тестване на Agile Automation.

частен сървър на world of warcraft pvp

Предизвикателство 2:Избиране на правилните инструменти

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

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

Предизвикателство 3:Фаза на разработка на скриптове

Тестерите за автоматизация, разработчиците, бизнес анализаторите и заинтересованите страни от проекта допринасят изцяло за начални срещи, на които „Потребителски истории“ са избрани за следващия спринт. След като за потребителски спринт са избрани „Потребителски истории“, те се използват като основа за набор от тестове.

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

Предизвикателство 4:Управление на ресурси

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

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

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

Предизвикателство 5:Комуникация

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

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

Предизвикателство 6:Ежедневна среща за скрам

Ежедневната среща на Scrum е една от ключовите дейности в Agile процеса. Екипите се срещат в продължение на 15 минути сеанси за изправяне. Каква е ефективността на тези срещи? До каква степен тези срещи помагат на разработчиците да практикуват автоматизацията? и т.н., се обсъждат на тази среща.

Предизвикателство 7:Фаза на освобождаване

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

Стъпки за автоматизиране на регресионното тестване

Процесът, който трябва да се следва за автоматизиране на регресията, може да бъде прецизно разделен на следните стъпки:

7 стъпки за автоматизиране на регресионното тестване

Тези 7 стъпки са обяснени подробно по-долу с прости термини за вашето лесно разбиране.

1. Идентификация

Идентификация

# 1) Идентифицирайте тестови случаи което трябва да бъде част от пакета за регресионен тест.

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

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

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

Предложено четене => Списък на най-добрите инструменти за тестване на автоматизация

# 3) Идентифицирайте Програмен език които искате да използвате. С толкова много инструменти, налични на пазара, много езици се поддържат от тези инструменти. Поради това е важно да идентифицирате езика за програмиране, на който искате да напишете вашите тестови случаи за автоматизация.

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

Както е обяснено по-горе, ние ще идентифицираме тестовите случаи.

  • Да приемем, че нашият тестов случай е „Проверете дали потребителят може да влезе успешно, като използва валидно потребителско име и парола“.

След това ще идентифицираме инструментите за автоматизация.

  • Тестовият случай, базиран на браузър, може да бъде автоматизиран с „ Селен ',' Ранорекс ”,„ TestComplete ”. Нека да вземем решение за инструмента Selenium, тъй като той най-добре отговаря на изискванията.

Сега, нека идентифицираме език за програмиране.

  • Искаме да използваме „ Java ”Като език за програмиране като негов силно поддържан език.

2. Анализ

Анализ

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

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

# две) Направете ресурс и усилия анализ, за ​​да видите дали имате ресурси да работите по това. Заедно с анализа на разходите е много важно да се направи анализ на ресурсите и усилията за по-добро разпределение на ресурсите и ефективно използване на времето им по проекта.

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

# 3) Направете Време Анализ. Необходим е анализ на времето, за да сте сигурни, че можете да завършите проекта за автоматизация в рамките на бюджета и сроковете. Докато работите върху анализ на времето, ще бъде полезно да изготвите график за времеви график, който да следи напредъка по време на разработката.

За по-добър анализ на времевата линия на проекта:

  • Определете задачите и подзадачите във вашите проекти.
  • Приоритизирайте задачите и подзадачите.
  • Начертайте диаграма на Гант или мрежова диаграма за по-добро изобразяване на времевата линия.

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

Анализ на разходите:

Да приемем, че приблизителните разходи за този проект са $ X сума.

Ресурс и усилия:

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

Анализ на времето:

За това нека нарисуваме малка диаграма на Гант, за да видим времевата линия.

диаграма на Гант - Автоматизирано тестване на регресия

3. Обучение / наемане

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

В този случай идентифицирайте тези ресурси и планирайте обучението им, за да могат да започнат да работят по автоматизацията на регресионните тестови случаи.

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

Пример:

Да приемем, че вече имаме ресурс, който е запознат с концепциите на Java и иска да научи Селен. След това ще организираме обучение за селен за този човек.

Ако нямаме налични ресурси за автоматизация. След това ще наемем човек, който има известен опит в автоматизирането на такива тестови случаи, използвайки селен и java.

4. Рамка и насоки

# 1) След като инструментът и ресурсите са готови, работете върху изготвянето на рамка или да решите кой да използвате от съществуващите рамки. Могат да се използват множество вече изградени рамки или можете да изградите вашата рамка от нулата.

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

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

Например , Някои инструменти, които могат да ви помогнат, включват git, GitHub, Jenkins и др.

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

използвайки eclipse за c ++

Пример:

Рамка: Нека решим за BDD (поведенческо развитие) рамка за тестване на автоматизация.

Поддържащи инструменти: Инструментите, от които се нуждаем, за да подкрепим напълно автоматизацията, ще бъдат GitHub, Jenkins, Log4J, Cucumber и JUnit.

5. Скриптове за автоматизация

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

Докато пишем скриптове, трябва да се уверим, че:

  • Следват се указанията.
  • Използваме инструментите.
  • Тестовите случаи са модулирани.
  • Би трябвало да можем да използваме повторно компонентите, ако са необходими в множество тестови случаи.

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

Пример:

Нека напишем действителни скриптове, за да стартира този тестов случай. Пример от скриптове може да бъде показан както по-долу.

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

Характеристика: Проверете функционалността за вход
Като потребител искам да вляза в приложението
Сценарий Схема: Влезте в приложението
Като се има предвид, че отварям приложение
Когато въведа потребителско име „“
И въвеждам парола “”
И щраквам върху бутона Login
След това отивам на начална страница

Примери:
| потребителско име | парола |
| testuser1 | парола1 |
| testuser2 | парола2 |

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

public class Login { LoginImpl loginImpl = new LoginImpl(); @Given('^I open application$') public void i_open_application() { loginImpl.openURL('URL'); } @When('^I Enter username '((^')*)'$') public void i_Enter_username(String arg1) { loginImpl.enterUserName(arg1); } @When('^I Enter password '((^')*)'$') public void i_Enter_password(String arg1) { loginImpl.enterPassword(arg1); } @When('^I click on Login button$') public void i_click_on_Login_button() { loginImpl.clickLoginButton(); } @Then('^I go to Home page$') public void i_go_to_Home_page() { loginImpl.verifyHomePage(); } }

В крайна сметка действителното изпълнение на класа за функционалност за вход ще изглежда по-долу:

public class LoginImpl { WebDriver driver; public LoginImpl(){ System.setProperty('webdriver.chrome.driver', 'webdriver/chromedriver.exe'); driver = new ChromeDriver(); } public void openURL(String string) { driver.get(string); } public void enterUserName(String arg1) { driver.findElement(By.id('UserName')).sendKeys(arg1); } public void enterPassword(String arg1) { driver.findElement(By.id('Password')).sendKeys(arg1); } public void clickLoginButton() { driver.findElement(By.id('LoginButton')).click(); } public void verifyHomePage() { String currUrl = driver.getCurrentUrl(); if(currUrl.equals('homePageURL')) { System.out.println('Home page verified'); } } }

6. Преглед

Преглед

(изображение източник )

# 1) Преглед на кода: След като разработчикът на автоматизация приключи с писането на скриптове за автоматизация, е много важно да преминете през различните нива на преглед на кода.

Код рецензии помощ в

  1. Идентифициране на грешни проверки.
  2. Намиране на точки за оптимизиране на кода.
  3. Намиране на по-добри начини за внедряване на функционалността за ефективно използване на ресурсите.

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

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

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

Пример:

За разгледания от нас пример, да речем, за преглед на кода получихме коментари като „елемент за търсене по id, а не по име“. Тук ще вземем това предвид и ще променим съответно нашия скрипт.

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

7. Доставете

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

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

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

Пример:

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

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

Заключение

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

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

Автоматизирането на теста за регресия винаги е полезно, тъй като е най-добрият кандидат за стартиране тестване за автоматизация . Можете да следвате стъпките, споменати по-горе, за да автоматизирате всеки тестов пакет, а не само регресията.

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

За автора: J.B. Rajkumar има повече от 15 години опит както в академичните среди, така и в тестването на софтуер. Работил е като корпоративен треньор, ръководител на тестове, QA мениджър и QC мениджър.

Кажете ни вашите коментари / предложения относно тази статия.

=> Посетете тук за пълната серия за тестване на регресия.

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

^