Мени

Како применити ефикасну аутоматизацију тестова у окретном свету

how implement efficient test automation agile world

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

Аутоматизација у Агиле-у је врло критична.

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

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

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

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

Такође, прочитајте Део 1 и део 2 прво да би имали боље разумевање теме.

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

Шта аутоматизовати у агилном?

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

Осим горњег слоја и даље имамо сервисни слој и јединични слој који су важнији.

бесплатни ИоуТубе за мп4 конвертер за мац

Па који тестови, осим тестова дима и регресије, могу бити добри кандидати за аутоматизацију?

# 1) Израде и примене

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

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

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

Такође прочитајте=> Процес управљања објављивањем и применом

Неколико предности аутоматизованог постављања градње су:

  • Нема шансе да направите грешке у примени (могу се избећи људске грешке попут копирања нетачне датотеке или копирања датотеке на нетачно место)
  • Грешка / функције су доступне за тестирање чим се исправе
  • Испитивачи добијају више времена за тестирање
  • Функција је спремна за пресељење у производњу за мање времена
  • Брзе повратне информације

# 2) Јединствени тестови / тестови компонената

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

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

шта је окидање порта у односу на прослеђивање порта

# 3) АПИ / тестирање веб услуга

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

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

Ово посебно испитивање део је средњег слоја пирамиде. Већина функционалног испитивања може се угурати у овај слој. Отклањање кварова који настају у овом слоју постаје лако отклонити и они се не одлажу док УИ не постане доступан.

# 4) Тестирање иза ГУИ-а

Аутоматизација тестирања иза ГУИ-а је релативно лакша од аутоматизације стварног ГУИ-а. Још једна предност је што, без обзира на промене корисничког интерфејса, функционалност остаје нетакнута. Чак и ако се неки од елемената корисничког интерфејса промени, функционалност функције се не мења. Ова техника се углавном фокусира на пословну логику и правила.

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

# 5) Нефункционално тестирање

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

# 6) Поређење података

Многа наша тестирања захтевају да упоредимо датотеке са подацима, укључујући текстуалне датотеке, ЦСВ или Екцел датотеке

  • Ове датотеке се могу упоређивати са основним линијама за проверу ваљаности података
  • Поређења могу бити истих података, али различитог формата. То се у основи догађа када имамо две исте датотеке генерисане из два различита извора

Ова поређења се могу понављати, па стога и аутоматизовати.

# 7) Претраживање

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

# 8) Понављајући задаци

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

Где почети?

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

Можете започети са:

  • Идентификовање понављајућих задатака,
  • Идентификовање подручја бола у апликацији
  • Утврђивање изазова у тестирању

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

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

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

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

Једном када се обим аутоматизације и алата доврши, следећи је дизајн оквира.

Запамтите, у Агиле-у је оквир развијен. НЕМОЈТЕ прво циљати дизајнирање целокупног оквира, а затим имплементацију. Дизајнирајте и примените за МВП (минимално одрживи производ), а затим побољшајте постојећи оквир тако да укључује више функција. Такође морате применити добру праксу кодирања и развоја ако желите да ваш пакет аутоматизације буде робустан.

Неке најбоље праксе

  • Не циљајте на аутоматизацију 100% одједном. Почните са малим. Запамтите да је то процес који се развија
  • Пратите исте агилне праксе које следите за било који развој софтвера. Аутоматизација такође захтева правилно планирање и пројектовање. Не бисте желели да повећавате техничка дуговања када аутоматизујете
  • Направите заостатак за аутоматизацијом теста. Овај заостатак може се кретати од примене нове функције до побољшања постојеће функције. Дајте бодове причама својим идентификованим предметима и доделите их у складу с тим. Однесите ове заостале ставке на свој Спринт и пратите их помоћу Канбан табле
  • Напишите критеријуме прихватања за ваше приче о аутоматизацији. Ови критеријуми прихватања могу да укључују:
    • Интеграција тест пакета са ЦИ
    • Преношење одеће на централизовано место
    • Пошаљите резултате путем е-маила
    • Обезбеђивање слања датотека евиденције грешака када тест не успе
    • Било који други критеријум….
  • Не трошите време на процену новог алата. Можете створити приоритетну контролну листу онога што све желите од новог алата и одредити временску линију за његову процену. Ако не видите своје резултате у предвиђеном времену, пређите на следећи
  • Донесите разумну одлуку о томе шта аутоматизовати. Није сваки део аутоматизације ефикасан и доноси позитиван повраћај улагања. Не аутоматизујте само ради аутоматизације
  • Искористите одговарајуће развојно окружење. Не држите код код свог локалног. Имајте спремиште за чување кода и навику провјере кода на крају дана
  • На сличан начин, покушајте да извршите своје аутоматизоване тестове са централизоване локације. Нека особа буде независна. Требало би да било ко из тима може покренути скрипте са своје машине, а резултати се добијају путем е-поште

Који су агилни принципи који се могу применити на аутоматизацију?

Неколико врло једноставних савета:

  • Нека ствари буду једноставне. Урадите оно што је потребно. Видео сам много случајева када испоручујемо примену пресвучену шећером што аутоматизацију чини непотребно компликованом. Избегавајмо ствари које нису потребне
  • Радити једноставне ствари не значи радити најлакше ствари. То значи предузимање бебиних корака за постизање ваших циљева аутоматизације. Можете узети једноставну функцију за аутоматизацију, али може се догодити да се примена аутоматизације испостави као сложена
  • Примените приступ целокупног тима . Верујем да су сви испитивачи у агилном тиму. Не ограничавајмо посао аутоматизације ни само тестерима ни само програмерима. Свака од дисциплина мора ући једна у другу да би постигла аутоматизацију пројекта. Овај приступ би такође био ефикасан за решавање било ког техничког питања које долази са применом
  • Оквир је развијен у Агиле-у . Не покушавајте да пружите превише функција које могу непотребно да чине део аутоматизације сложеним
  • Нађите времена да то урадите како треба. Одвојите мало времена да га правилно дизајнирате како бисте избегли техничке дугове
  • Добијајте честе повратне информације
  • Примените одговарајуће стандарде кодирања и вежбајте. Дизајн треба да буде једноставан, применити ООПС концепте и покушати да тестови буду независни једни од других. Узмите у обзир факторе попут „одржавања“ тест одеће

Да ли видим неке изазове док аутоматизујем у Агиле-у?

Аутоматизација у агилном свету долази са сопствени изазови :

  • Морамо заиста добро да планирамо. Одлучивање о одговарајућем скупу тестова, алату, оквиру и приступу, свима треба одговарајућу стратегију. Међутим, требали бисмо запамтити да НЕ планирамо превише. Имајте на уму МВП (минимално одрживи производ)
  • Компромитујући квалитет кода, јер желимо да га испоручимо брзо: Морамо имати на уму да се технички дугови добро задржавају и у аутоматизацији
  • Тимови у већини случајева не прате „Приступ целог тима“ и препуштају целокупну одговорност кодирања и одржавања аутоматизованог пакета за тестере, што додаје одговорност тестера
  • Аутоматизација функционалних тестова је тежа од аутоматизације корисничког интерфејса

Међу свим овим изазовима, најкритичнији изазов је надоградња вештина тестера.

Рад и одржавање аутоматизације за тим је готово попут активности програмирања (развоја) коју програмери (програмери) раде. Важна је не само примена, већ и интегрисање аутоматизованог одела у ЦИ и захтева да тестери науче и усвоје нове вештине и науче нове алате и технологије.

код за сортирање облачића ц ++

Неки алати отвореног кода који се уклапају у Агиле

  • Селениум ВебДривер - За корисничко сучеље
  • Селен Грид - За паралелно извршење
  • Краставац - за БДД
  • ЈМетер - За испитивање перформанси
  • САПУН - За веб услуге
  • ВиреМоцк - Тестирање веб услуга када веб услуга није доступна.
  • Епохе - за мобилне уређаје

Закључујем са чувеним Агиле тест квадрантима:

Агиле тест куадрантс

Квадрант 1 је тест јединице и компонената који се могу аутоматизовати ТДД приступом.

Квадрант 2 говори о испитивању функционалности, где можемо применити БДД приступ.

Квадрант 3 је једини квадрант који има опсег ручног испитивања.

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

Закључак

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

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

О аутору: Овај чланак је члан СТХ тима Схилпа. Она ради на пољу тестирања софтвера последњих 10 и више година у доменима попут Интернет оглашавања, инвестиционог банкарства и Телекома.

Молимо поделите своје коментаре и размишљања у наставку.

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

^