Regresinis testavimas yra juodosios dėžės testavimo metodai. Jis naudojamas autentifikuoti programinės įrangos kodo pakeitimą, kuris neturi įtakos esamam gaminio funkcionalumui. Regresijos testavimas užtikrina, kad produktas gerai veiktų su naujomis funkcijomis, klaidų pataisymais ar bet kokiu esamos funkcijos pakeitimu.

Regresinis testas yra tam tikras tipas programinės įrangos testavimas . Bandomieji atvejai vykdomi iš naujo, siekiant patikrinti, ar ankstesnis programos funkcionalumas veikia gerai, o nauji pakeitimai nesukėlė jokių klaidų.

Regresijos testavimas gali būti atliekamas naujoje versijoje, kai reikšmingai pasikeičia pradinės funkcijos. Tai užtikrina, kad kodas veiktų net ir įvykus pakeitimams. Regresija reiškia, kad pakartotinai patikrinkite tas programos dalis, kurios yra nepakitusios.

Regresijos testai taip pat žinomi kaip patikrinimo metodas. Bandymo atvejai dažnai yra automatizuoti. Bandomuosius atvejus reikia atlikti daug kartų, o vėl ir vėl rankiniu būdu paleisti tą patį bandomąjį atvejį, tai taip pat užima daug laiko ir nuobodu.

Regresijos testavimo pavyzdys

Čia mes paimsime atvejį, kad galėtume efektyviai apibrėžti regresijos testavimą:

Apsvarstykite produktą Y, kurio viena iš funkcijų yra suaktyvinti patvirtinimą, priėmimą ir išsiųsti el. laiškus. Taip pat reikia patikrinti, ar kodo pakeitimas jų nepaveikė. Regresinis testavimas nepriklauso nuo jokios programavimo kalbos, pavyzdžiui Java , C++ , C# ir tt Šis metodas naudojamas norint patikrinti, ar gaminyje nėra modifikacijų ar bet kokių atnaujinimų. Tai užtikrina, kad bet koks produkto pakeitimas neturės įtakos esamam gaminio moduliui. Patikrinkite, ar ištaisytos klaidos ir naujai pridėtos funkcijos nesukėlė problemų ankstesnėje veikiančioje programinės įrangos versijoje.

Kada galime atlikti regresijos testą?

Mes atliekame regresijos testavimą, kai keičiamas gamybos kodas.

Regresijos testavimą galime atlikti pagal šį scenarijų:

1. Kai prie programos pridedamos naujos funkcijos.

Pavyzdys:

Svetainėje yra prisijungimo funkcija, leidžianti vartotojams prisijungti tik naudojant el. Dabar teikiama nauja funkcija prisijungti naudojant „Facebook“.

2. Kai yra pakeitimo reikalavimas.

Pavyzdys:

Prisiminkite slaptažodį, pašalintą iš prisijungimo puslapio, kuris buvo taikomas anksčiau.

3. Kai defektas pašalinamas

Pavyzdys:

Tarkime, kad prisijungimo mygtukas neveikia prisijungimo puslapyje, o bandytojas praneša apie klaidą, nurodydamas, kad prisijungimo mygtukas neveikia. Kai kūrėjai ištaisys klaidą, testuotojas ją išbando, kad įsitikintų, jog prisijungimo mygtukas veikia taip, kaip tikėtasi. Tuo pačiu metu testeris išbando kitas funkcijas, susijusias su prisijungimo mygtuku.

4. Kai išspręsta našumo problema

Pavyzdys:

Pagrindinis puslapis įkeliamas per 5 sekundes, o įkėlimo laikas sutrumpėja iki 2 sekundžių.

5. Kai vyksta aplinkos pasikeitimas

Pavyzdys:

Kai atnaujiname duomenų bazę iš MySql į Oracle.

Kaip atlikti regresijos testą?

Regresijos testavimo poreikis atsiranda, kai programinės įrangos priežiūra apima patobulinimus, klaidų taisymus, optimizavimą ir esamų funkcijų ištrynimą. Šie pakeitimai gali turėti įtakos sistemos funkcionalumui. Šiuo atveju būtina atlikti regresijos testą.

Regresijos testą galima atlikti naudojant šiuos metodus:

1. Iš naujo išbandyti viską:

Pakartotinis testavimas yra vienas iš regresinio testavimo būdų. Taikant šį metodą, visi bandomojo atvejo ieškiniai turėtų būti vykdomi iš naujo. Čia galime apibrėžti pakartotinį testą kaip tada, kai bandymas nepavyksta, ir nustatome, kad gedimo priežastis yra programinės įrangos gedimas. Apie gedimą pranešta, galime tikėtis naujos programinės įrangos versijos, kurioje defektas ištaisytas. Tokiu atveju turėsime dar kartą atlikti testą, kad patvirtintume, jog gedimas pašalintas. Tai žinoma kaip pakartotinis testavimas. Kai kurie tai vadins patvirtinimo bandymu.

Pakartotinis testas yra labai brangus, nes reikalauja daug laiko ir išteklių.

perjungti java programavimą

2. Regresijos testo pasirinkimas:

• Taikant šią techniką, bus atliktas pasirinktas bandomasis kostiumas, o ne visas bandomasis kostiumas.
• Pasirinktas bandomasis atvejis tinka padalytas į du atvejus
  1. Daugkartinio naudojimo bandymo dėklai.
  2. Pasenę Bandymo atvejai.
• Pakartotinai naudojami bandymo atvejai gali būti naudojami kitame regresijos cikle.
• Pasenusių bandymų atvejų negalima naudoti kitame regresijos cikle.

3. Bandomųjų atvejų prioritetų nustatymas:

Pirmenybę teikite bandomajam atvejui, atsižvelgdami į poveikį verslui, svarbias ir dažnai naudojamas funkcijas. Testavimo atvejų pasirinkimas sumažins regresijos testų rinkinį.

Kokie yra regresijos testavimo įrankiai?

Regresinis testavimas yra gyvybiškai svarbi kokybės užtikrinimo proceso dalis; Vykdydami regresiją galime susidurti su šiais iššūkiais:

Daug laiko
Regresiniam testavimui atlikti reikia daug laiko. Regresinis testavimas vėl apima esamus testus, todėl testuotojai nesijaudina pakartotinai atlikti testą.Sudėtingas
Regresinis testavimas taip pat yra sudėtingas, kai reikia atnaujinti bet kurį produktą; testų sąrašai taip pat didėja.Bendravimo verslo taisyklė
Regresinis testavimas užtikrina, kad esamos produkto funkcijos vis dar veikia. Bendravimas apie regresijos testavimą su netechniniu lyderiu gali būti sudėtinga užduotis. Vadovas nori, kad produktas judėtų į priekį ir investuotų daug laiko į regresijos testavimą, kad būtų užtikrintas sunkus esamų funkcijų veikimas.Nustatykite poveikio sritį Bandomieji atvejai padidina išleidimą Mažiau išteklių Nėra tikslumo Pasikartojanti užduotis Monotoniškas darbas

Regresijos testavimo procesas

Regresijos testavimo procesas gali būti atliekamas visoje stato ir išleidžia .

Regresinis testavimas visose konstrukcijose

Ištaisius klaidą, iš naujo patikriname klaidą, o jei yra koks nors priklausomas modulis, atliekame regresijos testavimą.

Pavyzdžiui , Kaip atliekame regresijos testavimą, jei turime skirtingus statymus kaip 1, 2 ir 3 statymas , kuri turi skirtingus scenarijus.

Sukurti 1

• Pirmiausia klientas pateiks verslo poreikius.
• Tada kūrėjų komanda pradeda kurti funkcijas.
• Po to testavimo komanda pradės rašyti bandomuosius atvejus; Pavyzdžiui, jie parašo 900 bandomųjų atvejų, skirtų produkto 1 leidimui.
• Ir tada jie pradės įgyvendinti bandomuosius atvejus.
• Kai produktas išleidžiamas, klientas atlieka vieną priėmimo bandymo etapą.
• Ir galiausiai produktas perkeliamas į gamybos serverį.

Sukurti 2

• Dabar klientas prašo pridėti 3–4 papildomas (naujas) funkcijas, taip pat pateikia reikalavimus naujoms funkcijoms.
• Kūrimo komanda pradeda kurti naujas funkcijas.
• Po to testavimo komanda pradės rašyti naujų funkcijų bandomąjį atvejį ir parašys apie 150 naujų bandymų atvejų. Todėl bendras parašyto bandomojo atvejo skaičius yra 1050 abiem leidimams.
• Dabar testavimo komanda pradeda testuoti naujas funkcijas naudodama 150 naujų bandomųjų atvejų.
• Kai tai bus padaryta, jie pradės testuoti senąsias funkcijas naudodami 900 bandymų atvejų, kad patikrintų, ar naujos funkcijos pridėjimas sugadino senas funkcijas, ar ne.
• Čia senų funkcijų testavimas žinomas kaip Regresinis testavimas .
• Išbandžius visas funkcijas (naujas ir senas), gaminys perduodamas klientui, o tada klientas atliks priėmimo testavimą.
• Atlikus priėmimo testavimą, produktas perkeliamas į gamybos serverį.

Sukurti 3

• Po antro leidimo klientas nori pašalinti vieną iš funkcijų, pvz., Pardavimas.
• Tada jis ištrins visus pardavimo moduliui priklausančius testavimo atvejus (apie 120 bandomųjų atvejų).
• Tada išbandykite kitą funkciją, kad patikrintumėte, ar visos kitos funkcijos veikia gerai, pašalinus pardavimo modulio testavimo atvejus, ir šis procesas atliekamas atliekant regresijos testavimą.

Pastaba:

• Stabilių funkcijų testavimas, siekiant užtikrinti, kad dėl pakeitimų ji neveikia. Čia pakeitimai reiškia, kad modifikavimas, papildymas, klaidų taisymas arba ištrynimas .
• Pakartotinai atliekant tuos pačius testavimo atvejus skirtingose ​​versijose ar leidimuose, užtikrinama, kad pakeitimai (keitimas, papildymas, klaidų taisymas ar ištrynimas) nesukeltų stabilių funkcijų klaidų.

Regresijos testavimas visame leidime

Regresijos testavimo procesas prasideda kiekvieną kartą, kai tam pačiam projektui išleidžiamas naujas leidimas, nes nauja funkcija gali paveikti senus ankstesnių leidimų elementus.

Norėdami suprasti regresijos testavimo procesą, atliksime šiuos veiksmus:

1 žingsnis

Nėra regresijos testavimo 1 leidimas nes 1 leidimas nevyksta, nes pats leidimas yra naujas.

2 žingsnis

Regresinio testavimo koncepcija prasideda nuo 2 leidimas kai klientas duoda šiek tiek nauji reikalavimai .

3 veiksmas

Pirmiausia gavus naujus reikalavimus (pakeitus funkcijas), jie (kūrėjai ir bandymų inžinieriai) supras poreikius prieš eidami į poveikio analizė .

4 veiksmas

Supratę naujus reikalavimus, atliksime vieną etapą poveikio analizė kad išvengtumėte didelės rizikos, tačiau čia kyla klausimas, kas atliks poveikio analizę?

5 veiksmas

Poveikio analizę atlieka klientas remiantis jų verslo žinių , programuotojas remiantis jų kodavimo žinios , ir, svarbiausia, tai atlieka bandymų inžinierius nes jie turi produkto išmanymas .

Pastaba: jei tai daro vienas asmuo, jis gali neaprėpti visų poveikio zonų, todėl įtraukiame visus asmenis, kad galėtume aprėpti didžiausią poveikio sritį, o poveikio analizė turėtų būti atlikta ankstyvose išleidimo stadijose.

6 veiksmas

Kai baigsime su poveikio zona , tada kūrėjas parengs poveikio sritis (dokumentas) , ir klientas taip pat parengs poveikio zonos dokumentas kad galėtume pasiekti didžiausią poveikio analizės aprėptį .

7 veiksmas

Baigę poveikio analizę, kūrėjas, klientas ir bandymų inžinierius išsiųs Ataskaitos Nr. poveikio zonos dokumentų Bandymo laidas . O kol kas bandymų inžinierius ir kūrėjas dirba su nauju bandomuoju atveju.

8 veiksmas

Kai bandomasis asmuo gaus Ataskaitų Nr., jis/ji tai padarys konsoliduoti ataskaitose ir saugomos bandymo atvejų reikalavimų saugykla 1 leidimui.

Pastaba: Bandomųjų atvejų saugykla: čia išsaugosime visus leidimų bandomuosius atvejus.

9 veiksmas

Po to bandymo vadovas pasinaudos RTM pagalba ir pasirinks reikiamą regresijos testo atvejis nuo bandymų atvejų saugykla , ir tie failai bus patalpinti į Regresijos testų rinkinys .

Pastaba:

• Bandymo laidas išsaugos regresijos testo atvejį regresijos testų rinkinyje, kad nebūtų daugiau painiavos.
Regresijos testų rinkinys: Čia išsaugosime visus smūgio zonos bandymo dokumentus.Regresijos testo atvejai: Tai yra senų leidimų tekstinio dokumento bandomieji atvejai, kuriuos reikia vykdyti iš naujo, kaip matome toliau pateiktame paveikslėlyje:

10 veiksmas

Po to, kai bandymo inžinierius baigs dirbti su naujais bandymo atvejais, bandymo laidas atliks priskirti regresijos testo atvejį pas bandytoją.

11 veiksmas

Kai visi regresijos testo atvejai ir naujos funkcijos yra stabilus ir praeina , tada patikrinkite poveikio plotas naudojant bandomąjį atvejį kol jis bus patvarus senoms funkcijoms ir naujoms funkcijoms, tada jis bus perduotas klientui.

Regresijos testavimo tipai

Skirtingi regresijos testų tipai yra tokie:

1. Vieneto regresijos testavimas [URT]
2. Regioninis regresijos testas[RRT]
3. Visiškas arba visiškas regresijos testas [FRT]

1) Vieneto regresijos testavimas [URT]

Šiuo metu bandysime tik pakeistą bloką, o ne smūgio sritį, nes tai gali turėti įtakos to paties modulio komponentams.

sujungimas java eilutė

1 pavyzdys

Toliau pateiktoje programoje ir pirmoje versijoje kūrėjas kuria Paieška mygtukas, kuris priima 1-15 simbolių . Tada bandymų inžinierius išbando paieškos mygtuką naudodamas bandomojo atvejo projektavimo technika .

Dabar klientas šiek tiek pakeičia reikalavimą ir taip pat prašo, kad Paieškos mygtukas gali priimti 1-35 simboliai . Bandymo inžinierius išbandys tik mygtuką „Ieškoti“, kad patikrintų, ar jis užima 1–35 simbolius, ir netikrina jokių kitų pirmosios versijos funkcijų.

2 pavyzdys

Štai, mes turime Pastatas B001 , ir nustatomas defektas, o ataskaita pristatoma kūrėjui. Kūrėjas ištaisys klaidą ir atsiųs kartu su kai kuriomis naujomis funkcijomis, kurios sukurtos antroje Pastatas B002 . Po to bandymų inžinierius testuos tik po to, kai bus pašalintas defektas.

• Bandymo inžinierius atpažins, kad spustelėjo Pateikti mygtukas pereina į tuščią puslapį.
• Ir tai yra defektas, ir jis siunčiamas kūrėjui, kad jį sutvarkytų.
• Kai naujoji versija bus pataisyta kartu su klaidų pataisymais, testavimo inžinierius išbandys tik mygtuką Pateikti.
• Ir čia mes neketiname tikrinti kitų pirmosios versijos funkcijų ir bandyti išbandyti naujas funkcijas, išsiųstas į antrąją versiją.
• Esame tikri, kad taisydami Pateikti mygtukas neturės įtakos kitoms funkcijoms, todėl išbandome tik ištaisytą klaidą.

Todėl galime teigti, kad testuojant tik pakeista funkcija vadinama Vieneto regresijos testavimas .

2) Regioninis regresijos testas [RRT]

Šiuo metu mes išbandysime modifikaciją kartu su poveikio zona ar regionais, vadinamais Regioninis regresijos testas . Čia mes išbandome poveikio sritį, nes jei yra patikimų modulių, tai turės įtakos ir kitiems moduliams.

Pavyzdžiui:

Žemiau esančiame paveikslėlyje matome, kad turime keturis skirtingus modulius, tokius kaip A moduliai, B moduliai, C moduliai ir D moduliai , kuriuos kūrėjai pateikia bandymams pirmojo kūrimo metu. Dabar bandymų inžinierius nustatys klaidas D modulis . Pranešimas apie klaidą siunčiamas kūrėjams, o kūrimo komanda ištaiso tuos defektus ir išsiunčia antrąją versiją.

Antroje konstrukcijoje ankstesni defektai yra ištaisyti. Dabar bandymų inžinierius supranta, kad klaidų taisymas D modulyje paveikė kai kurias funkcijas A ir C moduliai . Taigi bandymų inžinierius pirmiausia išbando D modulį, kuriame klaida buvo ištaisyta, o tada patikrina smūgio vietas A ir C moduliai . Todėl šis bandymas yra žinomas kaip Regioninės regresijos testas.

Vykdydami regioninį regresijos testą galime susidurti su tokia problema:

Problema:

Pirmoje versijoje klientas siunčia tam tikrus reikalavimo pakeitimus ir taip pat nori pridėti naujų gaminio funkcijų. Poreikiai siunčiami abiem komandoms, ty kūrimui ir testavimui.

Gavusi reikalavimus, kūrėjų komanda pradeda modifikaciją ir pagal poreikius kuria naujas funkcijas.

Dabar bandomasis asmuo siunčia el. laišką klientams ir klausia, kad visos yra poveikio sritys, kurios bus paveiktos atlikus reikiamus pakeitimus. Todėl klientas susidarys idėją, kurias visas funkcijas reikia išbandyti dar kartą. Be to, jis (ji) išsiųs el. laišką kūrimo komandai, kad sužinotų, kurios visos programos sritys turės įtakos dėl pakeitimų ir naujų funkcijų papildymų.

Be to, klientas siunčia el. laišką testavimo komandai, kad gautų poveikio sričių sąrašą. Taigi bandomasis asmuo surinks poveikio sąrašą iš kliento, kūrimo komandos ir testavimo komandos.

Tai Poveikio sąrašas yra siunčiamas visiems bandymų inžinieriams, kurie peržiūri sąrašą ir patikrina, ar jų funkcijos yra pakeistos, o jei taip, tada jie tai daro regioninės regresijos testavimas . Poveikio zonas ir pakeistas sritis išbando atitinkami inžinieriai. Kiekvienas bandymų inžinierius išbando tik savo savybes, kurios galėjo turėti įtakos dėl modifikacijos.

Šio anksčiau pateikto metodo problema yra ta, kad bandomasis asmuo gali nesuvokti visos poveikio zonų idėjos, nes kūrėjų komanda ir klientas gali neturėti tiek daug laiko grąžinti savo laiškus.

Sprendimas

Norėdami išspręsti aukščiau pateiktą problemą, atliksime toliau nurodytus veiksmus.

Kai bus sukurta nauja versija su naujausiomis funkcijomis ir klaidų pataisymais, testavimo komanda surengs susitikimą, kuriame aptars, ar jų funkcijos turi įtakos dėl pirmiau nurodyto pakeitimo. Todėl jie atliks vieną ratą Poveikio analizė ir generuoti Poveikio sąrašas . Šiame konkrečiame sąraše bandymų inžinierius bando įtraukti didžiausias tikėtinas smūgio vietas, o tai taip pat sumažina defektų atsiradimo tikimybę.

Kai bus sukurta nauja versija, testavimo komanda atliks toliau nurodytą procedūrą:

• Jie atliks dūmų testą, kad patikrintų pagrindines programos funkcijas.
• Tada jie išbandys naujas funkcijas.
• Po to jie patikrins pakeistas funkcijas.
• Kai tik bus patikrintos pakeistos funkcijos, bandymų inžinierius iš naujo patikrins klaidas.
• Tada jie patikrins poveikio sritį, atlikdami regioninį regresijos testą.

Vieneto ir regioninės regresijos testavimo trūkumas

Toliau pateikiami kai kurie vieneto ir regioninės regresijos testavimo trūkumai:

• Galime praleisti kai kurią poveikio sritį.
• Gali būti, kad galime nustatyti neteisingą poveikio sritį.

Pastaba: galime sakyti, kad pagrindinis darbas, kurį atliekame su regioniniu regresijos testavimu, leis mums gauti daugiau defektų. Bet jei mes taip pat atsiduosime darbui su visišku regresuojančiu testavimu, sulauksime mažiau defektų. Todėl čia galime nustatyti, kad bandymų patobulinimas nepadės mums gauti daugiau defektų.

3) Visiškas regresijos testas [FRT]

Per antrą ir trečią gaminio išleidimą klientas prašo pridėti 3-4 naujas funkcijas, taip pat reikia ištaisyti kai kuriuos ankstesnės versijos defektus. Tada testavimo komanda atliks poveikio analizę ir nustatys, kad dėl pirmiau nurodyto pakeitimo išbandysime visą produktą.

Todėl galime teigti, kad išbandydami pakeistos savybės ir visos likusios (senos) funkcijos vadinamas Pilnas regresijos testas .

Kada atliekame pilnos regresijos testavimą?

Mes atliksime FRT, kai turėsime šias sąlygas:

• Kai modifikavimas vyksta produkto šaltinio faile. Pavyzdžiui , JVM yra JAVA programos šakninis failas, o jei JVM įvyks koks nors pakeitimas, bus išbandyta visa JAVA programa.
• Kai turime atlikti n skaičių pakeitimų.

Pastaba:

Regioninis regresijos testavimas yra idealus regresijos testavimo metodas, tačiau problema ta, kad atlikdami regioninės regresijos testavimą galime nepastebėti daug defektų.

Ir čia mes išspręsime šią problemą naudodami šį metodą:

• Kai bus pateikta paraiška bandymui atlikti, bandymų inžinierius išbandys pirmąjį 10–14 ciklų ir atliks RRT .
• Tada 15 ciklą atliekame FRT. Ir vėl, kitą 10-15 ciklą, mes tai darome Regioninės regresijos testas , o 31 ciklą atliekame pilnas regresijos testas , ir tęsime taip.
• Tačiau paskutinius dešimt leidimo ciklų atliksime tik pilnas regresijos testas .

Todėl, jei laikysimės aukščiau pateikto požiūrio, galime gauti daugiau defektų.

Pakartotinio regresijos testavimo rankiniu būdu trūkumas:

• Sumažės našumas.
• Tai sunkus darbas.
• Testo vykdymas nėra nuoseklus.
• Taip pat pailgėja testo vykdymo laikas.

Taigi, sieksime automatizuoti šias problemas; kai turėsime regresijos testo ciklo n skaičių, pasirinksime automatizavimo regresijos testavimo procesas .

Automatizuotas regresijos testavimo procesas

Paprastai mes pasirenkame automatizavimą, kai yra keli leidimai arba keli regresijos ciklai arba kartojasi užduotis.

Automatizavimo regresijos testavimo procesą galima atlikti šiais veiksmais:

1 pastaba:

Programos testavimo procesas naudojant kai kuriuos įrankius vadinamas automatizavimo testavimu.

Tarkime, jei paimtume vieną pavyzdį a Prisijungimo modulis , tada kaip galime atlikti regresijos testą.

Čia prisijungimas gali būti atliekamas dviem būdais, kurie yra tokie:

Rankiniu būdu: Šiuo atveju regresiją atliksime tik vieną ir du kartus.

Automatika: Šiuo atveju automatizavimą atliksime kelis kartus, nes turėsime parašyti bandomuosius scenarijus ir atlikti vykdymą.

2 pastaba: realiuoju laiku, jei susidūrėme su tokiomis problemomis kaip:

1 žingsnis

Kai prasideda naujas leidimas, mes nesiimame automatizavimo, nes nėra regresijos testavimo ir regresijos testo atvejo koncepcijos, kaip supratome aukščiau pateiktame procese.

2 žingsnis

Kai prasideda naujas leidimas ir patobulinimas, turime dvi komandas, t. y. rankinio darbo komandą ir automatizavimo komandą.

3 veiksmas

Vadovų komanda išnagrinės reikalavimus, taip pat nustatys poveikio zoną ir perduos reikalavimų testų rinkinys automatikos komandai.

4 veiksmas

Dabar rankinio darbo komanda pradeda dirbti su naujomis funkcijomis, o automatizavimo komanda pradės kurti bandomąjį scenarijų ir taip pat pradės automatizuoti bandomąjį atvejį , o tai reiškia, kad regresijos bandymo atvejai bus konvertuojami į bandomąjį scenarijų.

5 veiksmas

Prieš pradėdami automatizuoti bandomąjį atvejį, jie (automatizacijos komanda) taip pat išanalizuos, kurie visi atvejai gali būti automatizuoti ar ne.

6 veiksmas

Remdamiesi analize, jie pradės automatizavimą, ty kiekvieną regresijos testo atvejį konvertuos į bandymo scenarijų.

7 veiksmas

Šio proceso metu jie pasinaudos pagalba Regresijos atvejai nes jie neturi tiek žinių apie produktą, kiek įrankis ir taikymas .

8 veiksmas

Kai bandomasis scenarijus bus paruoštas, jie pradės šių scenarijų vykdymą naujoje programoje [senoji funkcija]. Kadangi bandomasis scenarijus parašytas naudojant regresijos funkciją arba senąją funkciją.

9 veiksmas

Kai vykdymas bus baigtas, gauname kitokią būseną, pvz Išlaikyta/nepavyko .

10 veiksmas

Jei būsena nepavyko, o tai reiškia, kad ją reikia iš naujo patvirtinti rankiniu būdu, o jei klaida yra, ji praneš atitinkamam kūrėjui. Kai kūrėjas ištaiso šią klaidą, neautomatinio testavimo inžinierius turi iš naujo išbandyti klaidą kartu su poveikio sritimi, o automatikos testavimo inžinierius taip pat turi iš naujo vykdyti scenarijų.

11 veiksmas

Šis procesas tęsiasi tol, kol bus panaudotos visos naujos funkcijos ir regresijos funkcija.

Regresinio testavimo automatizavimo testavimo pranašumai:

Tikslumasvisada egzistuoja, nes užduotį atlieka įrankiai ir įrankiai niekada nenuobodžiauja ir nepavargsta.
• Bandomąjį scenarijų galima pakartotinai naudoti keliuose leidimuose.
Paketinis vykdymasgalima naudojant automatiką t.y.; visi parašyti testo scenarijai gali būti vykdomi lygiagrečiai arba vienu metu.
• Net jei regresijos bandymo atvejų skaičius padidina leidimą kiekvienam leidimui, ir mes neturime didinti automatizavimo išteklių, nes kai kurie regresijos atvejai jau yra automatizuoti iš ankstesnio leidimo.
• Tai yra laiką taupantis procesas nes vykdymas visada yra greitesnis nei rankinis metodas.

Kaip pasirinkti regresijos testavimo testus?

Tai buvo nustatyta atlikus pramonės patikrinimą. Keletas defektų, apie kuriuos pranešė klientas, atsirado dėl paskutinės minutės klaidų pataisymų. Tai sukuria šalutinius poveikius ir todėl pasirenka testo atvejį regresijos testavimui yra menas, o ne lengva užduotis.

Regresijos testą galima atlikti taip:

• Bandomasis atvejis, kuriame dažnai pasitaiko defektų
• Funkcijos, kurios geriau matomos vartotojams.
• Bandomieji atvejai patvirtina pagrindines produkto savybes.
• Visi integravimo bandymo atvejai
• Visi sudėtingi bandymų atvejai
• Ribinių verčių testavimo atvejai
• Sėkmingų bandomųjų atvejų pavyzdys
• Bandomųjų atvejų nesėkmės

Regresijos testavimo įrankiai

Jei programinė įranga dažnai keičiama, regresinio testavimo išlaidos taip pat didėja. Tokiais atvejais rankinis testavimo atvejų vykdymas padidina testo vykdymo laiką ir išlaidas. Tokiu atveju automatizavimo testavimas yra geriausias pasirinkimas. Automatizavimo trukmė priklauso nuo bandymų atvejų, kuriuos galima pakartotinai naudoti nuosekliems regresijos ciklams, skaičiaus.

Toliau pateikiami pagrindiniai regresijos testavimo įrankiai:

Selenas

Selenas yra atvirojo kodo įrankis. Šis įrankis naudojamas automatiniam žiniatinklio programos testavimui. Atliekant naršyklės regresijos testą, naudojamas selenas. Selenas naudojamas UI lygio regresijos testui žiniatinklio programoms.

Ranorex studija

Viskas viename darbalaukio, žiniatinklio ir mobiliųjų programų regresijos testo automatizavimas su integruota Selenium žiniatinklio tvarkykle. „Ranorex Studio“ apima visus IDE plius įrankius bekodiniam automatizavimui.

Greito testavimo profesionalas (QTP)

mockito bet kada

QTP yra automatizuotas testavimo įrankis, naudojamas regresijos ir funkciniams testams. Tai duomenimis pagrįstas raktiniais žodžiais pagrįstas įrankis. Automatizavimui naudojo VBScript kalbą. Jei atidarysime QTP įrankį, pamatysime tris mygtukus, kurie yra Įrašyti, paleisti ir sustabdyti . Šie mygtukai padeda įrašyti kiekvieną paspaudimą ir veiksmą, atliekamą kompiuterinėje sistemoje. Jis įrašo veiksmus ir atkuria juos.

Racionalus funkcinis testeris (RTF)

Racionalus funkcinis testeris yra „Java“ įrankis, naudojamas programinės įrangos testavimo atvejams automatizuoti. RTF naudojamas automatizuoti regresijos testavimo atvejus, taip pat integruojamas su racionaliu funkciniu testeriu.

Daugiau informacijos apie regresijos ir automatizavimo testavimo įrankius rasite toliau pateiktoje nuorodoje:

https://www.javatpoint.com/automation-testing-tool

Regresinis testavimas ir konfigūracijos valdymas

Konfigūracijos valdymas regresijos testavimo metu tampa būtinas judriose aplinkose, kur kodas yra nuolat keičiamas. Norėdami užtikrinti teisingą regresijos testą, turime atlikti šiuos veiksmus:

• Regresijos testavimo fazės metu kodo pakeitimai neleidžiami.
• Regresijos bandymo atvejis turi būti nepaveiktas kūrėjo pakeitimų.
• Regresijos testavimui naudojama duomenų bazė turi būti izoliuota; duomenų bazėje keisti neleidžiama.

Pakartotinio ir regresinio testavimo skirtumai

Pakartotinis testavimas Testavimas reiškia dar kartą išbandyti funkcionalumą arba klaidą, kad įsitikintumėte, jog kodas ištaisytas. Jei nenustatyta, defektų nereikia iš naujo atidaryti. Jei ištaisyta, defektas uždarytas.

Pakartotinis testavimas – tai testavimo tipas, kurio metu tikrinami bandymo atvejai, kurių galutinis vykdymas buvo nesėkmingas, po defektų pašalinimo sėkmingai praeina.

Regresinis testavimas reiškia programinės įrangos testavimą, kai keičiamas kodas, siekiant užtikrinti, kad naujas kodas nepaveiktų kitų Programinės įrangos dalių.

Regresinis testavimas yra testavimo tipas, atliekamas siekiant patikrinti, ar kodas nepakeitė esamų programos funkcijų.

Skirtumai tarp pakartotinio ir regresinio testavimo yra tokie:

Regresinio testavimo privalumai

Regresijos testo pranašumai yra šie:

• Regresinis testavimas padidina produkto kokybę.
• Tai užtikrina, kad bet koks klaidų taisymas ar pakeitimai neturės įtakos esamoms produkto funkcijoms.
• Automatikos įrankiai gali būti naudojami regresijos testavimui.
• Tai užtikrina, kad išspręstos problemos nepasikartotų.

Regresinio testo trūkumai

Regresinis testavimas turi keletą privalumų, tačiau yra ir trūkumų.

• Regresinis testavimas turėtų būti atliekamas atliekant nedidelius kodo pakeitimus, nes net ir nedidelis kodo pakeitimas gali sukelti esamų funkcijų problemų.
• Jei testavimui projekte nenaudojama automatika, tai atlikti testą vėl ir vėl bus daug laiko ir varginanti užduotis.

Išvada

Regresinis testavimas yra vienas iš esminių aspektų, nes jis padeda pateikti kokybišką produktą, taupantį organizacijos laiką ir pinigus. Tai padeda pateikti kokybišką produktą užtikrinant, kad bet koks kodo pakeitimas nepaveiks esamų funkcijų.

Norint automatizuoti regresijos testo atvejus, yra keletas automatizavimo įrankių. Įrankis turi turėti galimybę atnaujinti bandymų komplektas nes regresijos testo kostiumą reikia dažnai atnaujinti.