Мени

Аутоматизовано регресијско тестирање: изазови, процес и кораци

automated regression testing

Испробајте Наш Инструмент За Елиминисање Проблема

Овај водич објашњава изазове аутоматског тестирања регресије. Такође ћемо научити о процесу и корацима за аутоматизацију тестирања регресије:

Научићемо како да аутоматизујемо регресионе тест случајеве почевши од њиховог идентификовања, одабира алата за аутоматизацију, анализе трошкова, времена и напора, писања скрипти и на крају достављања тиму за ручни тест како би могли да изврше тест случајеве са било ког места у било које време.

Ако се питате зашто само пакет за регресијски тест, то је зато што је пакет за регресијски тест главни кандидат за аутоматизацију, јер је то низ тест случајева који се понављају и одузимају време. Стога би њихова аутоматизација заиста уштедела пуно ресурса, а такође би била и дуготрајна.

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

=> Кликните овде за комплетну серију тестирања регресије.

Аутоматизовано регресијско испитивање

Шта ћете научити:

Аутоматизовано регресијско испитивање

Недавно, када сам желео да започнем свој нови пројекат аутоматског тестирања са четири ресурса, размишљао сам о примени било које од агилних методологија. Али нисам могао да наставим јер ми је у мислима покренут низ питања.

Питања су била:

  • Да ли је могуће користити агилне методологије у аутоматизованом тестирању?
  • Могу ли да користим традиционалне алате?
  • Да ли треба да користим алате отвореног кода?
  • Са којим изазовима морам да се суочим ако примењујем аутоматизацију у окретном окружењу?

У овом чланку анализирајмо неке изазове са којима се суочавамо током примене аутоматизације са агилним методологијама. Аутоматско регресијско тестирање у окретном окружењу представља ризик да постанете хаотични, неструктурирани и неконтролисани.

Агиле Пројецтс представљају сопствене изазове тиму за аутоматизацију. Агиле методологија наглашава тимску сарадњу и честу испоруку производа. Чимбеници попут нејасног обима пројекта, вишеструких понављања, минималне документације, раних и честих потреба за аутоматизацијом и активног укључивања заинтересованих страна, итд. Захтевају много изазова од тима за аутоматизацију.

Аутоматизовано тестирање: изазови у агилном окружењу

Постоји неколико агилних изазова за тим аутоматизације. Међутим, а неколико од њих је укратко дато у наставку.

Изазов 1:Фаза захтева

Програмер Тест Аутоматион бележи захтеве у облику „корисничких прича“, што су кратки описи корисничких функција.

Сваки захтев мора имати приоритет на следећи начин:

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

Једном када се успоставе приоритети, планирају се „поновне верзије“ издања. Обично је потребно да се изврши свака поновна издања Агиле између 1 и 3 месеца. Купци / корисници софтвера имају слободу да направе превише промена у захтевима. Понекад су ове промене толико нестабилне, да се итерације одбијају. Ове промене су већи изазови у примени процеса тестирања Агиле Аутоматион.

неке софтверске грешке упућују на физички проблем повезивања

Изазов 2:Избор правих алата

Традиционални, последњи тест алати са карактеристикама снимања и репродукције приморају тимове да сачекају док софтвер не буде готов. Штавише, традиционални алати за аутоматизацију тестова не раде за Агиле контекст јер решавају традиционалне проблеме који се разликују од изазова са којима се суочавају тимови Агиле Аутоматион.

Аутоматизација у раним фазама агилног пројекта обично је врло тешка, али како систем расте и еволуира, неки аспекти се смирују и постаје прикладно применити аутоматизацију. Тако избор алата за тестирање постаје пресудан за убирање ефикасности и квалитетних предности агилности.

Изазов 3:Фаза развоја скрипте

Испитивачи аутоматизације, програмери, пословни аналитичари и заинтересоване стране заједно доприносе почетним састанцима на којима су за следећи спринт одабране „Приче о корисницима“. Једном када се за спринт одаберу „Усер-Сториес“, оне се користе као основа за сет тестова.

Како функционалност расте са сваком итерацијом, мора се извршити тестирање регресије како би се осигурало да увођење нове функционалности у сваки циклус понављања не утиче на постојећу функционалност. Тхе скала Испитивања регресије расте са сваким спринтом и осигурава да ово остане изводљив задатак, а тест тим користи аутоматизацију теста за регресиони пакет.

Изазов 4:Управљање ресурсима

Агиле приступ захтева мешавину вештина тестирања, односно ресурси за тестирање биће потребни за дефинисање нејасних сценарија и тест случајева, понашање Ручно тестирање заједно са програмерима, пишите аутоматизоване регресионе тестове и извршавајте аутоматизоване регресионе пакете.

Како пројекат буде напредовао, биће потребне и специјалистичке вештине за покривање даљих области испитивања која би могла да укључују интеграцију и тестирање перформанси.

Требало би да постоји одговарајућа комбинација специјалиста за домене који планирају и прикупљају захтеве. Изазован део управљања ресурсима је открити тест ресурсе са више вештина и доделити их.

Изазов 5:Комуникација

Добра комуникација мора постојати међу Испитивање аутоматизације тим, програмери, пословни аналитичари и заинтересоване стране. Мора постојати веома сарадничка интеракција између клијента и тимова за доставу. Веће учешће клијента подразумева више предлога или промена од стране клијента. И подразумева већу пропусност за комуникацију.

Кључни изазов је да процес треба да буде у стању да обухвати и ефикасно примени све промене и да се одржи интегритет података. У традиционалном тестирању програмери и тестери су попут нафте и воде, али у агилном окружењу изазовни задатак је да обоје морају заједно радити на постизању циља.

Изазов 6:Дневни Сцрум састанак

Дневни Сцрум састанак је једна од кључних активности у Агиле Процесу. Тимови се састају на 15 минута станд уп сесија. Каква је ефикасност ових састанака? Колико ови састанци помажу програмерима да увежбавају аутоматизацију? итд., о којима се разговара на овом састанку.

Изазов 7:Фаза пуштања

Циљ пројекта Агиле је пружити основни радни производ што је брже могуће, а затим проћи кроз процес сталног побољшања. То значи да не постоји појединачна фаза пуштања производа. Изазовни део лежи у интеграционом тестирању и испитивању прихватљивости производа.

Кораци за аутоматизовање регресивног тестирања

Процес који треба следити за аутоматизацију регресије може се прецизно поделити у следеће кораке:

7 корака до аутоматизованог тестирања регресије

Ових 7 корака је детаљно објашњено у наставку једноставним терминима ради вашег лакшег разумевања.

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

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

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

  • Да бисте започели аутоматизацију случајева регресионих тестова, прва ствар коју требате учинити је да идентификујете и правилно дефинишу случајеве регресионих тестова са свим корацима, подацима и предусловима.
  • Да бисте били сигурни да имате ефикасан пакет за регресион тест, не заборавите да укључите:
    • Тест случајеви са понављајућим недостацима.
    • Тест случајеви који покривају сценарије од краја до краја.
    • Тест случајеви који су крајњи корисници видљивији.
    • Тест случајеви на граничним вредностима.
    • Добра комбинација позитивних и негативних тест случајева.
    • Сложени тест случајеви.

#два) Идентификујте алати за аутоматизацију који су најбољи за ваше захтеве и понашање апликације. Једном када су случајеви регресионих тестова идентификовани и спремни за аутоматизацију, идентификујте алате који најбоље одговарају вашим тест случајевима.

Најбољи начин да идентификујете алате је да направите матрицу са алатима и вашим захтевима, а затим водите евиденцију који алат задовољава које захтеве.

Предложено читање => Листа најбољих алата за тестирање аутоматизације

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

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

Као што је објашњено горе, идентификоваћемо тест случајеве.

  • Претпоставимо да је наш тест случај „Проверите да ли се корисник може успешно пријавити користећи важеће корисничко име и лозинку“.

Даље ћемо идентификовати алате за аутоматизацију.

  • Тест случај заснован на прегледачу може се аутоматизовати са „ Селен ',' Ранорек ”,„ ТестЦомплете ”. Одлучимо се за алат Селениум који најбоље одговара захтевима.

Идемо сада да идентификујемо програмски језик.

  • Желимо да користимо „ Јава ”Као програмски језик као језик који се веома подржава.

2. Анализа

Анализа1

# 1) Урадити Трошак анализа. Веома је важно радити у оквиру буџетских ограничења. Тако ћете након фазе идентификације имати представу колико тест случајева треба аутоматизовати и који су могући алати који се могу користити.

Сви налази из фазе идентификације помоћи ће вам да направите приближни буџет и тако можете добити било које одобрење итд., Ако је потребно.

#два) Урадити ресурса и напора анализу да бисте видели да ли имате ресурсе за рад на овоме. Заједно са анализом трошкова, веома је важно направити анализу ресурса и напора ради боље расподјеле ресурса и ефикасног кориштења њиховог времена на пројекту.

Док процењујете ресурсе и напоре, водите рачуна о ризицима као што је, ако се неко разболи или ако је неким тестовима потребно више ресурса за извршење итд.

# 3) Урадити време Анализа. Потребна је временска анализа како бисте били сигурни да пројекат аутоматизације можете завршити у оквиру буџета и рокова. Током рада на временској анализи било би корисно припремити временску табелу за праћење напретка током развоја.

За бољу временску анализу пројекта:

  • Утврдите задатке и подзадатке у својим пројектима.
  • Дајте приоритет задацима и подзадацима.
  • Нацртајте Ганттов графикон или мрежни дијаграм за бољу сликовитост временске линије.

Пример :Настављајући са нашим примером у разматрању из фазе идентификације, објашњење ове фазе дато је у наставку:

Анализа трошкова:

Претпоставимо да је приближни трошак за овај пројекат износ од Кс УСД.

Ресурс и напор:

За ово, један тест случај мора бити аутоматизован од краја до краја и потребан нам је један ресурс са пуним радним временом приближно 24 сата, а такође нам је потребан још један ресурс за преглед рада. Дакле, потребна су нам два ресурса, а процена напора је око 40 сати.

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

За ово, нацртајмо мали Ганттов графикон да бисмо видели временску линију.

дијаграм ганта - Аутоматско тестирање регресије

3. Обука / запошљавање

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

У овом случају, идентификујте ове ресурсе и планирајте њихову обуку како би могли да почну да раде на аутоматизацији случајева регресионих тестова.

#два) Ако нам треба више ресурса, онда порадите на запошљавање план. Када обавите анализу ресурса за напоре и ако не можете да задовољите потребе са већ расположивим ресурсима, онда планирајте да ангажујете неке нове ресурсе са одговарајућим вештинама које су потребне за пројекат у оквиру буџета.

Пример:

Рецимо да већ имамо ресурс који је упознат са Јава концептима и жели да научи Селениум. Тада ћемо организовати тренинг за селен за ту особу.

Ако немамо ресурсе за аутоматизацију. Тада ћемо унајмити особу која има искуства у аутоматизацији таквих тест случајева помоћу селена и јаве.

4. Оквир и смернице

# 1) Када су алат и ресурси спремни, порадите на осмишљавању а оквир или одлучивање о томе који ће се користити из постојећих оквира. Можете користити вишеструко већ изграђене оквире или свој оквир од почетка.

Док одабирете или градите оквир, обавезно укључите компоненте о, тестовима, евиденцијама, извештајима, уносом, везом базе података итд.

#два) Одлучите се за другу помоћни алати које желите да користите. Како је развој скрипте за аутоматизацију развојни задатак који укључује писање кода, било би много боље схватити друге развојне алате који би били потребни за подршку писању ваших скрипти.

На пример , Неки алати који могу бити од помоћи укључују гит, ГитХуб, Јенкинс итд.

# 3) Скицирајте Смернице за писање скрипти за аутоматизацију. Потребно је дати смернице тако да се сви ресурси који раде на пројекту синхронизују и користе исте конвенције именовања, исте процедуре за пријаву / одјаву кода и исти програмски језик.

како написати макефиле ц ++

Пример:

Оквир: Одлучимо о БДД (развој заснован на понашању) оквир за тестирање аутоматизације.

Помоћни алати: Алати који су нам потребни за потпуну подршку аутоматизацији биће ГитХуб, Јенкинс, Лог4Ј, Цуцумбер и ЈУнит.

5. Скрипте за аутоматизацију

Почните писати скрипте за аутоматизацију. Једном када имамо све, тј. Алат, програмски језик, потребне вештине и тестове који морају бити аутоматизовани, можемо започети писање скрипти за аутоматизацију.

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

  • Смернице се поштују.
  • Користимо алате.
  • Тест случајеви су модуларизовани.
  • Могли бисмо бити у могућности да поново користимо компоненте ако су потребне у више тест случајева.

Такође морамо бити сигурни да се код правилно одржава у алату за контролу верзија и да сви чланови тима могу лако да сарађују.

Пример:

Напишимо стварне скрипте како бисмо покренули овај тест. Узорак из скрипти може се приказати као доле.

Прво, сценарио краставца за овај тестни случај изгледао би доле:

Карактеристика: Проверите функционалност пријаве
Као корисник желим да се пријавим у апликацију
Преглед сценарија: Пријава у апликацију
С обзиром на то да сам отворио пријаву
Када унесем корисничко име “”
И уносим лозинку “”
И кликнем на дугме Логин
Затим идем на почетну страницу

Примери:
|. | корисничко име | лозинка |
|. | тестусер1 | пассворд1 |
|. | тестусер2 | пассворд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) Преглед тест случајева: Уз преглед кода, веома је важан и тест тест случаја. Морамо бити сигурни да скрипте за аутоматизацију при извршавању изводе исти скуп радњи и верификација као што очекујемо од случајева ручног тестирања.

Стога, преглед случајева аутоматизације са пословним аналитичарима или стручњацима за испитивање помаже у повећању поверења у тестирање аутоматизације тих случајева.

Пример:

За наш пример у разматрању, рецимо да смо за преглед кода добили коментаре попут „тражи елемент по ИД-у, а не по имену“. Овде ћемо ово узети у обзир и у складу са тим изменити нашу скрипту.

Такође, могао би се извршити тест тест да бисте додали кораке за тестирање ако сте на матичној страници након успешне пријаве. Затим бисмо ово додали и нашим скриптама.

7. Испоручи

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

Овај план је потребан, јер желимо да се уверимо да аутоматизација тест случајева не ограничава његово извршавање на одређени скуп људи или вештина. Свима у тиму или пројекту треба омогућити да изврше тест случајеве.

Један од могућих планова испоруке је пружање Јенкинсовог посла који се може покренути за извршавање аутоматизованих тест случајева.

Пример:

У нашем случају, претпоставимо да смо тест случај испоручили користећи посао Јенкинс-а. Овај Јенкинсов посао узима код од ГитХуб-а, прави га и покреће тестове на другој машини.

Када је посао успешан, приказује вам генерисани извештај о тестирању. Свако ко има приступ Јенкинс-у може да ради овај посао. Такође, овај посао се може заказати за извођење у одређено време.

Закључак

Ако се са овим изазовима можемо суочити на добро оптимизован начин, тада је аутоматско тестирање регресије у агилном окружењу одлична прилика за КА да преузме вођство агилних процеса. Боље је премостити јаз између корисника и програмера, разумети шта је потребно, како се то може постићи и како се може осигурати пре примене.

Пракса аутоматизације требала би имати главни интерес и за један и за други резултат, као и да настави да осигурава да цео систем који се развија испуњава пословне циљеве и да одговара својој сврси.

Аутоматизација регресионог тест случаја је увек корисна као најбољи кандидат за почетак испитивање аутоматизације . Можете следити горе поменуте кораке за аутоматизацију било ког скупа тестова, а не само регресије.

Испитивање аутоматизације је такође корисно и исплативо, а улагање времена у тестирање аутоматизације је само у писању скрипти и њиховом одржавању. Стога испитивање аутоматизације треба правилно планирати и заказати за успешан пројекат.

О аутору: Ј.Б.Рајкумар има више од 15 година искуства и у академском и у софтверском тестирању. Радио је као корпоративни тренер, вођа теста, КА менаџер и КЦ менаџер.

Обавестите нас о својим коментарима / сугестијама на овај чланак.

=> Посетите овде за комплетну серију тестирања регресије.

Препоручено читање

^