Шта је регресијско тестирање? Дефиниција, алати, метода и пример

what is regression testing

Шта је регресијско тестирање?

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

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

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

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

Регресија значи поновно тестирање непромењених делова апликације.

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

• Туториали обрађени у овој серији
• Преглед регресионог теста
• Када извршити овај тест?
• Да ли се регресијско тестирање може извршити ручно?
• Алати за аутоматско тестирање регресије
• Зашто тест регресије?
• Врсте регресивног испитивања
  • # 1) Регресија јединице
  • # 2) Делимична регресија
  • # 3) Потпуна регресија
• Колика је регресија потребна?
• Шта радимо у регресионој провери?
• Технике испитивања регресије
  • # 1) Поново тестирајте све
  • # 2) Избор регресионог теста
  • # 3) Одређивање приоритета тест случајева
  • # 4) Хибрид
• Како одабрати пакет за регресиони тест?
• Како извршити регресијско тестирање?
• Регресија у окретном
  • # 1) Регресија нивоа спринта
  • # 2) Регресија од краја до краја
• Предности
• Мане
• Регресија ГУИ апликације
• Разлика између регресије и поновног тестирања
• Предложак плана регресионог теста (ТОЦ)
  • # 1) Историја докумената
  • # 2) Референце
  • # 3) План испитивања регресије
  • # 4) Одобрење / прихватање
• Закључак
• Препоручено читање

Туториали обрађени у овој серији

Туториал # 1: Шта је регресијско тестирање (Овај водич)
Туториал # 2: Алати за регресион тест
Туториал # 3: Поново тестирајте против регресивног тестирања
Туториал # 4: Аутоматизовано регресијско тестирање у агилном

Преглед регресионог теста

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

На пример, Размотрите производ Кс, чија је једна од функција покретање потврде, прихватања и слања е-порука када се кликну на дугме Потврди, Прихвати и Отпреми.

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

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

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

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

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

Регресијски тест треба да буде део циклуса ослобађања и мора се узети у обзир у процени теста.

Када извршити овај тест?

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

Провера регресије је варијација поновног тестирања (што је једноставно понављање теста). При поновном тестирању разлог може бити било шта. Рецимо, тестирали сте одређену особину и био је крај дана - нисте могли да завршите тестирање и морали сте да зауставите поступак без одлуке да ли је тест прошао / пао.

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

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

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

Да ли се регресијско тестирање може извршити ручно?

Управо сам предавао један од ових дана у разреду и поставило ми се питање - „Може ли се регресија извршити ручно?“

Одговорио сам на питање и кренули смо даље у разреду. Чинило се да је све у реду, али некако ме је ово питање прилично дуго мучило.

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

• Да ли нам је потребан алат за извршење теста?
• Како се врши регресијско тестирање?
• Чак и након читавог круга тестирања - новопридошлима је тешко да разазнају шта је тачно регресијски тест?

И наравно, оригинално питање:

• Да ли се ово тестирање може извршити ручно?

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

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

Алати за аутоматско тестирање регресије

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

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

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

Већина алата за регресиони тест су типа снимања и репродукције. Забележићете испитне случајеве кретањем кроз АУТ (апликација која се тестира) и верификовати да ли долазе очекивани резултати или не.

Алати

• Селен
• Каталог Студио
• АдвентНет КЕнгине
• Испитивач регресије
• вТест
• воде
• активна
• Рационални функционални испитивач
• СилкТест
• ТимеСхифтКс

Већина су то алати за функционисање и регресију.

Препоручено читање => Овде потражите листу најбољих алата за регресију

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

бесплатни софтвер за часовник на мрежи

У већини случајева морамо често да ажурирамо аутоматизоване тестове регресије због честих промена у систему.

ПОГЛЕДАЈТЕ ВИДЕО

За детаљније објашњење дефиниције са примером, молимо проверите следећеВидео регресионог теста:

Зашто тест регресије?

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

У ново доданој и постојећој функционалности може бити много зависности.

Мера квалитета је да се провери да ли је нови код у складу са старим кодом, тако да на неизмењени код не утиче. Већину времена испитни тим има задатак да провери промене система у последњем тренутку.

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

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

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

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

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

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

Дакле, ово тестирање игра велику улогу и такође је веома потребно и важно.

Врсте регресивног испитивања

Доље су дати различити типови регресије:

• Регресија јединице
• Делимична регресија
• Комплетна регресија

# 1) Регресија јединице

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

# 2) Делимична регресија

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

# 3) Потпуна регресија

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

Колика је регресија потребна?

Ово зависи од обима нових додатих функција.

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

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

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

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

Шта радимо у регресионој провери?

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

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

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

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

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

Технике испитивања регресије

Доље су дате разне технике.

• Поново тестирајте све
• Избор регресионог теста
• Приоритизација тест случаја
• Хибрид

# 1) Поново тестирајте све

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

# 2) Избор регресионог теста

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

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

# 3) Одређивање приоритета тест случајева

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

# 4) Хибрид

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

Како одабрати пакет за регресиони тест?

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

Испод је листа тест случајева који се могу користити током извођења овог теста:

• Функције које се често користе.
• Тест случајеви који покривају модул где су промене извршене.
• Сложени тест случајеви.
• Случајеви интеграционих тестова који укључују све главне компоненте.
• Тестирајте кључне функције или карактеристике производа.
• Треба укључити тестове приоритета 1 и приоритета 2.
• У истима су пронађени случајеви тестирања који често не успевају или су недавно откривени недостаци тестирања.

Како извршити регресијско тестирање?

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

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

Доље су дати различити кораци који су укључени у извођење овог тестирања

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

На пример:

Објаснићу ово на примеру. Молимо проучите доњу ситуацију:

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

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

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

Основни кораци за извођење регресивних тестова

Сваки пут када се софтвер подвргне промени и појави се нова верзија / издање, следе кораци које можете предузети за спровођење ове врсте тестирања:

• Схватите какве су промене унете у софтвер
• Анализирајте и утврдите на које модуле / делове софтвера може утицати - развојни и БА тимови могу бити кључни у пружању ових информација
• Погледајте своје тестове и утврдите да ли ћете морати да извршите потпуну, делимичну или јединствену регресију. Препознајте оне који ће одговарати вашој ситуацији
• Закажите време и тестирајте!

Регресија у окретном

Окретан је адаптивни приступ који следи итеративни и инкрементални метод. Производ је развијен у кратким итерацијама названим спринт који траје 2 - 4 недеље. У агилности постоји читав низ итерација, па стога ово тестирање игра значајну улогу јер се у итерацијама врши нова функционалност или промена кода.

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

У Агиле-у, Провера регресије обухваћена је у две категорије:

• Регресија нивоа спринта
• Регресија од краја до краја

# 1) Регресија нивоа спринта

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

# 2) Регресија од краја до краја

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

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

Предности

Доље су дате разне предности регресионог теста

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

Мане

Иако постоји неколико предности, постоје и неки недостаци. Су:

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

Регресија ГУИ апликације

Тешко је извршити тест регресије ГУИ (графички кориснички интерфејс) када структура ГУИ је измењен. Тест случајеви написани на старом ГУИ-у или застаревају или их је потребно изменити.

Поновна употреба регресионих тест случајева значи да су ГУИ тест случајеви модификовани у складу са новим ГУИ. Али овај задатак постаје гломазан ако имате велики скуп ГУИ тест случајева.

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

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

Предложак плана регресионог теста (ТОЦ)

1. Историја докумената

2. Референце

3. План испитивања регресије

3.1. Увод

3.2. Сврха

3.3. Тест Стратеги

3.4. Карактеристика за тестирање

3.5. Потребни ресурси

3.5.1. Захтев за хардвером

3.5.2. Захтеви за софтвер

3.6. Распоред испитивања

3.7. Промена захтев

3.8. Критеријуми за улазак / излазак

3.8.1. Критеријуми за улазак у ово тестирање

3.8.2. Излазни критеријуми за ово тестирање

3.9. Претпоставка / Ограничења

3.10. Тест случајева

3.11. Ризик / претпоставке

3.12. Алати

4. Одобрење / прихватање

Хајде да детаљно погледамо сваку од њих.

# 1) Историја докумената

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

# 2) Референце

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

# 3) План испитивања регресије

3.1. Увод

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

3.2. Сврха

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

3.3. Тест Стратеги

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

3.4. Карактеристике које треба тестирати

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

3.5. Потребни ресурси

3.5.1. Захтев за хардвером:

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

3.5.2. Захтев за софтвер:

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

3.6. Распоред испитивања

Распоред испитивања дефинише процењено време извођења активности испитивања.

На пример Колико ресурса ће извршити активност тестирања и то такође за колико времена?

3.7. Промена захтев

Поменути су детаљи о ЦР за које би се извршила регресија.

3.8. Критеријуми за улазак / излазак

3.8.1. Критеријуми за улазак у ово тестирање:

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

На пример:

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

3.8.2. Критеријуми изласка за ово тестирање:

Овде су дефинисани излазни критеријуми за регресију.

На пример:

• Треба извршити регресијско тестирање.
• Све нове критичне грешке пронађене током овог тестирања треба да буду затворене.
• Извештај о испитивању треба да буде спреман.

3.9. Тест случајева

Овде су дефинисани случајеви регресионих тестова.

3.10. Ризик / претпоставке

Идентификују се сви ризици и претпоставке и за њих се припрема план за непредвиђене случајеве.

3.11. Алати

Идентификовани су алати који ће се користити у пројекту. Као такав:

• Алат за аутоматизацију
• Алат за пријављивање грешака

# 4) Одобрење / прихватање

Овде су наведена имена и имена људи:

Закључак

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

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

Тиме завршавамо ову тему и надамо се да ће од сада бити много јасније у вези с том темом.

Обавестите нас о питањима и коментарима у вези са регресијом. Како сте се бавили својим задацима тестирања регресије?

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

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

• Најбољи алати за тестирање софтвера 2021. (Алати за аутоматизацију КА теста)
• 10 најпопуларнијих алата за тестирање регресије 2021
• Шта је испитивање поузданости: дефиниција, метода и алати
• 11 најбољих алата за аутоматизацију за тестирање Андроид апликација (Андроид Апп Тестинг Тоолс)
• Аутоматизовано регресијско тестирање: изазови, процес и кораци
• Преузимање е-књиге за тестирање буквара
• Разлика између поновног тестирања и регресивног тестирања са примером
• Топ 10+ најбољих САП алата за тестирање (САП алати за аутоматизацију)