Какво е регресионно тестване?

Какво е регресионно тестване?

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

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

Защо регресионно тестване?

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

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

Кога можем да извършим регресионно тестване?

Ето сценариите, когато можете да приложите процеса на регресионно тестване.

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

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

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

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

При интегриране с нова външна система: Процесът на регресионно тестване от край до край е необходим винаги, когато продуктът се интегрира с нова външна система.

Как да направите регресионно тестване в софтуерното тестване

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

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

Могат да се извършат различни техники за регресионно тестване за ефективно осигуряване на качеството на софтуера:

Повторно тестване на всички

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

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

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

Приоритизиране на тестови случаи

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

Избор на тестови случаи за регресионно тестване

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

Ефективен набор от регресионни тестове може да бъде изграден чрез избиране на следните типове тестови случаи –

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

Инструменти за регресионно тестване

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

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

1) testRigor

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

Характеристики:

• Безплатна завинаги публична версия
• Тестовите случаи са на английски език
• Неограничени потребители и неограничени тестове
• Най-лесният начин да научите автоматизация
• Рекордер за уеб стъпки
• Интеграции с CI/CD и управление на тестови случаи
• Тестване на имейл и SMS
• Web + Mobile + API стъпки в един тест

Посетете testRigor >>

Selenium: Selenium е най-използваният инструмент с отворен код, използван за автоматизиране на уеб приложения. Selenium може да се използва за базирано на браузър регресионно тестване. Поддържа езици за програмиране като Java, Руби, PythonИ др

Quick Test Professional (QTP): HP Quick Test Professional е автоматизиран софтуер, предназначен да автоматизира функционални и регресионни тестови случаи. Той използва VB Script език за автоматизация. Това е инструмент, управляван от данни и базиран на ключови думи.

Rational Functional Tester (RFT): IBMРационалният функционален тестер на е a Java инструмент, използван за автоматизиране на тестовите случаи на софтуерни приложения. Това се използва предимно за автоматизиране на регресионни тестови случаи и също така се интегрира с Rational Test Manager.

Видове регресионно тестване

Ето различните видове регресионни тестове:

1) Единично регресионно тестване (URT)

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

Пример

Като например в Build 1 е открит проблем и докладван на разработчика.

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

2) Регионално регресионно тестване (RRT)

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

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

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

Следователно, тестерът проверява модификациите на модул B във второто издание. След това тества и областите на въздействие в A и C, за да определи как са били засегнати.

Забележка: По време на регресионното тестване е възможно да възникне този проблем по-долу.

Проблем:

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

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

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

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

Ето как ще изглежда процесът по-долу:

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

3) Пълно регресионно тестване (FRT):

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

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

Например, 4-тата версия е последната версия преди стартирането. Така че в тази компилация екипът за тестване извършва пълен тест или повторен тест на продукта, вместо само зоната на удар или функция. Това се прави след модификациите и тестовете в компилации 1, 2 и 3.

За да извършите пълно регресионно тестване, трябва да имате предвид следните обстоятелства:

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

4) Корективно регресионно тестване:

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

5) Повторно тестване на всички регресионни тестове:

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

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

6) Селективно регресионно тестване:

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

7) Прогресивно регресионно тестване:

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

Помага да се гарантира, че нито един компонент от по-старите версии не е засегнат в най-новата версия.

8) Частично регресионно тестване:

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

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

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

Както бе споменато по-рано, автоматизирането на регресионните тестове е необходимо, когато има множество версии. Необходим е и за множество цикли на регресия и множество повтарящи се дейности. Тъй като извършването на множество тестови цикли в версиите отнема много време.

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

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

Стъпка 2) Екипът за ръчно тестване започва да тества новите модули, докато екипът за автоматизирани тестове пише скрипта и автоматизира тестовия случай.

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

Стъпка 4) Те преобразуват тези регресионни тестове в скриптове в зависимост от това кои случаи могат да бъдат автоматизирани.

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

Стъпка 6) Когато тестовите скриптове са завършени, екипът за автоматизация ще ги изпълни в новото приложение.

Стъпка 7) След изпълнението резултатът информира дали тестът е преминал или неуспешен.

Стъпка 8) Ако тестът е неуспешен, той се проверява отново чрез метода на ръчно тестване и ако проблемът съществува, той се докладва на съответния разработчик.

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

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

Ето предимствата на автоматизираното регресионно тестване:

• за многократна употреба: Неговите тестови скриптове могат да се използват повторно в множество версии.
• Точност: Инструментите за автоматизация изпълняват задачата излишно, намалявайки вероятността от грешка.
• Спестява време: Той е по-бърз от процеса на ръчно функционално тестване и е ефективен във времето.
• Пакетно изпълнение: Възможно е изпълнението на всички скриптове едновременно и паралелно при автоматизирано тестване.
• Не е необходимо увеличаване на ресурсите: Регресионният тест е длъжен да се увеличава с всяка нова версия. Не е необходимо обаче да добавяте нови ресурси за автоматизация.

Как да изберем тестови случаи за регресионно тестване?

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

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

Най-добри практики за регресионно тестване

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

Автоматизирайте навсякъде, където е възможно

Автоматичното регресионно тестване намалява усилието за тестване и позволява бързо изпълнение на голям брой тестови случаи.

Непрекъснато интегриране

Включването на регресионно тестване в CI/CD тръбопроводите гарантира, че тестовете се изпълняват автоматично, когато се извършват промени в кодовата база.

Избор на тестов случай

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

Редовно изпълнение

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

Управление на тестови данни

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

Управление на околната среда

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

Дефекти в записа и проследяването

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

Реус Възможност

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

Регресионно тестване и управление на конфигурацията

Управлението на конфигурацията по време на регресионното тестване става наложително в гъвкави среди, където кодът се модифицира непрекъснато. За да осигурите ефективни регресионни тестове, спазвайте следното:

• Кодът, който се тества регресионно, трябва да бъде под инструмент за управление на конфигурацията.
• Не трябва да се допускат промени в кода по време на фазата на регресионния тест. Кодът на регресионния тест трябва да бъде защитен от промените на разработчиците.
• Базата данни, използвана за регресионно тестване, трябва да бъде изолирана. Не трябва да се допускат промени в базата данни

Разлика между повторно тестване и регресионно тестване

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

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

По-долу са основните разлики между тези два теста:

Повторно	Регресионно тестване
Създаден е специално за корекции на дефекти.	Регресионното тестване се прави главно, за да се провери дали промените в кода са повлияли на други функционалности.
Повторното тестване не проверява другите версии и само проверява дали повредените функции са възстановени.	Фокусира се върху предишни версии и тества дали предишните функции все още работят според очакванията.
Всеки тест е специфичен	Регресията е общ тест.
Това тестване е за неуспешни тестови случаи.	Това е за случаи с преминали тестове.
Той проверява конкретни дефекти, така че не може да бъде автоматизиран.	Може да се автоматизира. Също така силно препоръчително е да бъдете автоматизирани, както обсъдихме по-рано.
Повторното тестване не винаги е част от цикъл на тестване, тъй като се изисква само когато се открият грешки.	Регресията винаги е част от тестването, тъй като всеки път, когато се промени код, този тест трябва да се проведе, за да се разбере дали функционалността на продукта е стабилна.
Това е тестване с висок приоритет, тъй като се фокусира върху известни проблеми.	Това е тестване с нисък приоритет, тъй като е цялостно тестване на възможни дефекти.
Това тестване не отнема време, тъй като работи върху конкретен дефект.	Тъй като включва голяма част от софтуера, следователно отнема много време.
Той определя дефекти със същите данни и среда с различен вход и нова версия.	Това тестване може да придобие случаи от ръководства за потребителя, доклади за дефекти и функционални спецификации.
Повторно тестване не може да се проведе без първото тестване.	Прави се, когато са задължителни промени и модификации в съществуващ проект.

Освен това вижте пълния списък с разлики тук.

Предимства и недостатъци на регресионното тестване

Предимства

• Регресионното тестване подобрява качеството на продуктите.
• С това тестване вие ​​гарантирате, че модификациите и корекциите на грешки не са променили съществуващите функции и функции.
• Тъй като леглата за регресия работят върху съществуващи функции, можем да гарантираме, че по-старите дефекти също са покрити.
• Улеснява ефективното разработване на продукти.
• Можете да постигнете висока удовлетвореност на потребителите с това тестване на място.
• Като цяло поддържа стабилността на софтуера.

Недостатъци

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

Предизвикателства при регресионното тестване

Следват основните проблеми при тестване за извършване на регресионно тестване:

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

Практическо приложение на пример за регресионно тестване с видео

Кликнете тук ако видеото не е достъпно

Пример за регресионно тестване – Amazon

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

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

Представи си това Amazon решава да разшири своите продуктови предложения, като въведе нова категория, наречена „Устройства за интелигентен дом“, заедно със съществуващите категории като „Електроника“ и „Облекло“.

Възможни случаи на регресия биха били:

Функционалност на началната страница: Уверете се, че началната страница показва новата категория „Устройства за интелигентен дом“ заедно със съществуващите без проблеми с дисплея.

Навигация по категории: Уверете се, че потребителите могат безпроблемно да навигират до страницата с категория „Устройства за интелигентен дом“ и да се върнат на началната страница без проблеми.

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

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

Обработка на плащане: Тествайте шлюзове за плащане, специфични за покупките, и гарантирайте сигурни транзакции без грешки.

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

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

Заключение

• Значение на регресионното тестване – Регресионното тестване е вид софтуерно тестване, което гарантира, че приложението продължава да функционира според очакванията след подобрения, промени в кода или корекции на грешки.
• Една ефективна регресивна стратегия може да спести време и пари на организацията.
• Според казусите, регресията спаси до 60% от по-късните корекции на грешки.