Мени

Шта је испитивање аутоматизације (ултимативни водич за покретање аутоматизације теста)

what is automation testing

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

Комплетан водич за започињање тестирања аутоматизације на вашем пројекту:

Шта је испитивање аутоматизације?

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

водич за испитивање аутоматизације

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

  • Како у свој систем увести аутоматизацију?
  • Како одабрати најбољи и прави алат за аутоматизацију?
  • Како ефикасно развити скрипте?
  • Како извршити и одржавати тест скрипте?
  • И на крају, које су најбоље праксе које морате следити за успешно тестирање аутоматизације?

Данас смо планирали да обогатимо ваше знање низом лекција о „ Први кораци са тестирањем аутоматизације ”. Ова серија туторијала за аутоматизацију одговориће на сва горе наведена питања корак по корак једноставним примерима.

Погледајмо серију Водича о покретању аутоматизације на вашем пројекту !!

Процес аутоматизације од краја до краја:

Туториал # 1 : Најбољи водич за покретање аутоматизације на вашем пројекту
Туториал # 2: Врсте аутоматизованих тестова и неке заблуде
Туториал # 3: 10 корака за увођење аутоматизације у ваш пројекат
Туториал # 4: Водич од А до Ж о избору најбољег алата за аутоматизацију
Водич бр. 5: Оквири за развој скрипти и аутоматизацију
Лекција # 6: Извршење и извештавање о аутоматизацији
Туториал # 7: Најбоље праксе и стратегије аутоматизације тестова

најбољи софтвер за развој игара за почетнике

Савети за аутоматизацију:

Туториал # 8: 10 савета које бисте требали прочитати пре него што аутоматизујете свој рад на тестирању
Туториал # 9: Како се разликује планирање теста за ручне и аутоматизационе пројекте
Водич бр. 10: Када се одлучити за аутоматизацију?
Туториал # 11: Изазови испитивања аутоматизације
Водич бр. 12: Водич за примену доказа о концепту (ПОЦ) у аутоматизацији
Водич бр. 13: Како одабрати тачне тест случајеве за аутоматизацију
Водич # 14: Како превести случајеве ручног тестирања у скрипте за аутоматизацију

Каријера аутоматизације:

Водич бр. 15: Савети како постати бољи испитивач аутоматизације
Туториал # 16: Тест аутоматизација - да ли је то специјализована каријера? Да ли могу и нормални тестери да раде аутоматизацију?

Популарни алати за аутоматизацију:

Водич # 17: Водичи за селен 31+ Најбољи бесплатни водичи за селен
Туториал # 18: КТП водичи
Водич бр. 19: Алат за тестирање веб услуга СоапУИ
Водич бр. 20: ХП ЛоадРуннер за тестирање перформанси

Оквири за аутоматизацију:

Туториал # 21: Зашто нам је потребан оквир за аутоматизацију
Водич бр. 22: Најпопуларнији оквири за аутоматизацију

Аутоматска аутоматизација:

Водич бр. 23: Како применити ефикасну аутоматизацију у окретном свету

Остали алати за аутоматизацију:

Лекција # 24: Најбољи алати за тестирање аутоматизације
Лекција # 25: Сикули ГУИ алат за аутоматизацију
Туториал # 26: ПоверСхелл: Аутоматизација корисничког интерфејса радне површине са ПоверСхелл-ом
Лекција # 27: Цаталон Аутоматион Рецордер (Селениум ИДЕ Алтернативе)
Лекција # 28: Геб Алат: Аутоматизација прегледача помоћу Геб Алата
Лекција # 29: АутоИт: Како се рукује искачућим прозорима система Виндовс помоћу програма АутоИт
Туториал # 30: Краставац: аутоматизација помоћу алата за краставац и селена
Туториал # 31: Алат за испитивање угломера за тестирање од краја до краја апликација АнгуларЈС

Тестирање мобилне аутоматизације:

Туториал # 32: Аппиум Студио практични приручник
Водич # 33: Водич за апије за почетнике
Туториал # 34: Водич за Селендроид: Андроид Мобиле Аутоматион Фрамеворк
Туториал # 35: Водич за Ранорек: Моћан алат за тестирање на радној површини, вебу и мобилном уређају

Примери аутоматизације специфичне за домен:

Туториал # 36: Аутоматизација ЈАВА / Ј2ЕЕ апликација

Припрема за интервју за послове аутоматизације:

Водич # 37: Питања за интервју за испитивање аутоматизације
Водич бр. 38: Питања за интервју са селеном

Истражимо први водич из серије „Врхунски водич за испитивање аутоматизације“ !!

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

Шта је испитивање аутоматизације?

Ако софтвер тада може било шта, зашто софтвер не може да тестира софтвер?

Да ли вам ова изјава звучи логично?

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

Замислите себе првог дана свог посла као СКА. Представља вам се апликација коју треба тестирати. То је ЕРП апликација која садржи стотине образаца и хиљаде извештаја. Истраживачко тестирање започињете отварањем обрасца који садржи око 50 различитих поља.

Покушавате да унесете случајне податке у овај образац, што је трајало око 20 минута. Затим притиснете субмит. Волла !! Приказује се порука о грешци која изгледа као необрађени изузетак. Постајете веома срећни. Поносно бележите кораке и пријављујете грешку у свом систему за управљање грешкама. Велики напор, осећате се заиста самопоуздано и енергично. Наставите са тестирањем док се дан не заврши и пронађите још неке грешке. „Невероватан први дан“, помислили сте.

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

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

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

Сад се осећаш бесно. Осећате се уморно . Почињете да прескачете кораке. Попуните само око 50% укупних поља. Ваша тачност није иста, енергија није иста и дефинитивно, кораци нису исти.

И једног дана, клијент пријави исту грешку у истом облику. Осећате се јадно. Сад се осећате несигурно. Мислите да нисте довољно компетентни. Менаџери доводе у питање ваше способности.

Имам вести за вас; ово је прича о 90% ручних тестера тамо. Ти се не разликујеш.

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

Надам се да сте схватили моју поенту !!

аутоматизација тестирање пријатеља

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

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

Аутоматизација - исплатива метода за регресијско испитивање

Трошкови аутоматизације су у почетку заиста већи. Укључује трошкове алата, затим трошкове ресурса за аутоматизацију и његову / њену обуку.

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

Сценарији који захтевају аутоматизацију

Горе наведени сценарио није једини случај када ће вам требати тестирање аутоматизације. Постоји неколико ситуација које се не могу ручно тестирати.

На пример ,

  1. Поређење две слике пиксел по пиксел.
  2. Упоређивање две табеле која садржи хиљаде редова и колона.
  3. Тестирање апликације под оптерећењем од 100.000 корисника.
  4. Референтне перформансе.
  5. Тестирање апликације на различитим прегледачима и паралелно на различитим оперативним системима.

Ове ситуације захтевају и треба да се тестирају помоћу алата.

Па, када аутоматизовати?

Ово је доба агилна методологија у СДЛЦ-у, где ће развој и тестирање ићи готово паралелно и врло је тешко одлучити када аутоматизовати.

Размотрите следеће ситуације пре него што уђете у аутоматизацију

  • Производ може бити у примитивним фазама, када производ чак нема ни кориснички интерфејс, у тим фазама морамо имати јасну мисао о томе шта желимо аутоматизовати. Треба запамтити следеће тачке.
    • Тестови не би требало да буду застарели.
    • Како се производ развија, лако би било одабрати скрипте и додати их.
    • Веома је важно да се не заносите и осигурате да се скрипте лако отклањају.
  • Не покушавајте аутоматизацију корисничког интерфејса у почетним фазама, јер је кориснички интерфејс подложан честим променама, што ће довести до неуспеха скрипти. Колико год је могуће одлучите се за аутоматизацију на нивоу АПИ-ја / не-УИ нивоа док се производ не стабилизује. АПИ аутоматизацију је лако поправити и отклонити грешке.

Како одредити најбоље случајеве аутоматизације:

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

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

Ефикасна аутоматизација испитивања

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

Такође, покривао сам одговоре на питања попут Када аутоматизовати, Шта аутоматизовати, Шта не аутоматизовати и Како стратегизирати аутоматизацију.

Прави тестови за аутоматизацију

Најбољи начин за решавање овог проблема је брзо постизање „Стратегије аутоматизације“ која одговара нашем производу.

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

Груписање тест случајева

Заронимо сада дубоко и схватимо шта свака група може да нам помогне да постигнемо:

# 1) Направите тест пакет свих основних функција Позитивни тестови . Овај пакет треба аутоматизовати и када се овај пакет покрене против било које верзије, резултати се одмах приказују. Свака скрипта која не успије у овом пакету доводи до недостатака С1 или С2 и та специфична верзија може бити дисквалификована. Дакле, овде смо уштедели пуно времена.

Као додатни корак, можемо додати овај аутоматизовани пакет за тестирање као део БВТ (тестови за верификацију градње) и проверити скрипте за аутоматизацију КА у процес израде производа. Дакле, када је израда спремна, тестери могу да провере резултате испитивања аутоматизације и одлуче да ли је зграда погодна за инсталацију и даљи поступак испитивања.

Овим се јасно постижу циљеви аутоматизације који су:

  • Смањите напор тестирања.
  • Пронађите грешке у ранијим фазама.

#два) Даље, имамо групу Енд то Енд тестови .

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

Ако је било који део интеграције покварен, треба навести пакет за аутоматизацију. Овај пакет не мора да покрива сваку мању особину / функционалност решења, али треба да покрије рад производа у целини. Кад год имамо алфа или бета или било која друга средња издања, такве скрипте добро дођу и дају одређени ниво самопоуздања купцу.

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

Као што је дато испод:

  • Улаз за кориснике.
  • Прегледајте и изаберите ставке.
  • Могућност плаћања - ово обухвата предње тестове.
  • Управљање позадинским поруџбинама (укључује комуникацију са више интегрисаних партнера, проверу залиха, слање е-поште кориснику итд.) - ово ће помоћи тестирању интеграције појединачних комада, а такође и суштине производа.

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

# 3) Трећи сет је Тестови на основу карактеристика / функционалности .

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

# 4) Следећи на листи би био Тестови засновани на корисничком интерфејсу. Можемо имати још један пакет који ће тестирати функционалности засноване искључиво на корисничком интерфејсу као што су пагинација, ограничење броја знакова текстуалног оквира, дугме календара, падајући менији, графикони, слике и многе такве карактеристике само оријентисане на кориснички интерфејс. Неуспех ових скрипти обично није врло критичан, осим ако кориснички интерфејс потпуно не ради или се одређене странице не појављују како се очекује!

# 5) Можемо имати још један низ тестова који су једноставни, али врло напорни за ручно извођење. Заморни, али једноставни тестови су идеални кандидати за аутоматизацију, на пример, уношење података о 1000 купаца у базу података има једноставну функционалност, али изузетно је заморно да се врши ручно, такви тестови би требали бити аутоматизовани. Ако не, углавном их се игнорише и не тестира.

Шта НЕ аутоматизовати?

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

# 1) Негативни тестови / Фаиловер тестови

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

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

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

# 2) Ад хоц тестови

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

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

За кога планирамо аутоматизација можда ћемо желети да одредимо приоритет и не направимо исцрпну аутоматизацију свих ад хоц тестова само за ту функцију и на крају ћемо имати мало времена за аутоматизацију осталих кључних карактеристика.

# 3) Тестови са масивном пред-поставком

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

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

3рдпарти софтвер може бити било шта, а подешавање може бити сложене природе, а ако су такве скрипте аутоматизоване, оне ће заувек зависити од функције / подешавања тог независног софтвера.

Предуслов укључује:

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

Горе наведено је само пример, уопште, припазите на тестове који имају напорне претпоставке за једноставан тест који следи.

Једноставан пример аутоматизације теста

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

На пример , ако тестирате калкулатор, а тест је да морате додати два броја и видети резултат. Скрипта ће извести исте кораке користећи миш и тастатуру.

које је најбоље средство за чишћење рачунара бесплатно?

Пример је приказан у наставку.

Кораци ручног тест случаја:

  1. Покрени калкулатор
  2. Притисните 2
  3. Притисните +
  4. Притисните 3
  5. Притисните =
  6. На екрану би требало да се прикаже 5.
  7. Затвори калкулатор.

Скрипта за аутоматизацију:

//the example is written in MS Coded UI using c# language. (TestMethod) public void TestCalculator() { //launch the application var app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations Mouse.Click(button2); Mouse.Click(buttonAdd); Mouse.Click(button3); Mouse.Click(buttonEqual); //evaluate the results Assert.AreEqual('5', txtResult.DisplayText,”Calculator is not showing 5); //close the application app.Close(); }

Горња скрипта је само дупликат ваших ручних корака. Скрипт је једноставан за креирање и једноставан за разумевање.

Шта су тврдње?

За други последњи ред скрипте потребно је још неко објашњење.

Ассерт.АреЕкуал („5“, тктРесулт.ДисплаиТект, „Калкулатор не приказује 5);

У сваком тест случају имамо на крају неки очекивани или предвиђени резултат. У горњој скрипти очекујемо да на екрану буде приказано „5“. Стварни исход је резултат који се приказује на екрану. У сваком тест случају упоређујемо очекивани исход са стварним исходом.

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

Неки алати то називају „ Тврдња ”, Неки то називају„ контролни пункт “А неки то називају„ валидацијом “. Али у основи, ово је само поређење. Ако ово поређење не успе, за На пример. екран приказује 15 уместо 5, онда ова тврдња / контролна тачка / валидација не успе и ваш тест случај је означен као неуспешан.

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

У горњој скрипти извршили смо тврдњу у другом последњем реду. 5 је очекивани исход, тктРесулт . ДисплаиТект је стварни исход и ако нису једнаки, приказаће нам се порука „Калкулатор не приказује 5“.

Закључак

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

Постоје неке уобичајене „погрешне“ перцепције о аутоматизацији.

Су:

  • Можемо аутоматизовати сваки тест случај.
  • Аутоматизација тестова ће изузетно смањити време тестирања.
  • Ниједна грешка се не уводи ако скрипте за аутоматизацију раде глатко.

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

Груписање и аутоматизација правих кандидата уштедеће пуно времена и пружити све предности аутоматизације.

Овај одличан водич се може сажети у само 7 тачака.

Испитивање аутоматизације:

  • Да ли се тестирање врши програмски.
  • Користи алат за контролу извршавања тестова.
  • Поређује очекиване исходе са стварним исходима (тврдње).
  • Може аутоматизовати неке понављајуће али неопходне задатке ( На пример. Ваши случајеви регресионих тестова).
  • Може аутоматизовати неке задатке које је тешко ручно извршити (На пример.Сценарији испитивања оптерећења).
  • Скрипте се могу изводити брзо и више пута.
  • Да ли је дугорочно исплативо.

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

Будући у овој серији:

У нашим предстојећим водичима разговараћемо о неколико аспеката који се односе на аутоматизацију.

Ови укључују:

  1. Врсте аутоматизованих тестова и неке заблуде.
  2. Како увести аутоматизацију у своју организацију и избећи уобичајене замке приликом аутоматизације тестова.
  3. Процес избора алата и упоређивање различитих алата за аутоматизацију.
  4. Оквири за развој скрипти и аутоматизацију са примерима.
  5. Извршење и извештавање о аутоматизацији испитивања.
  6. Најбоље праксе и стратегије аутоматизације тестова.

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

СЛЕДЕЋА Лекција # 2

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

^