TechCodeview

Regresijas testēšana ir melnās kastes testēšanas metodes. To izmanto, lai autentificētu programmatūras koda izmaiņas, kas neietekmē produkta esošo funkcionalitāti. Regresijas testēšana nodrošina, ka produkts darbojas labi ar jaunu funkcionalitāti, kļūdu labojumiem vai jebkādām izmaiņām esošajā funkcijā.

Regresijas pārbaude ir sava veida programmatūras testēšana . Testa gadījumi tiek atkārtoti izpildīti, lai pārbaudītu, vai lietojumprogrammas iepriekšējā funkcionalitāte darbojas labi, un jaunās izmaiņas nav radījušas nekādas kļūdas.

Regresijas testēšanu var veikt jaunam būvējumam, ja ir būtiskas izmaiņas sākotnējā funkcionalitātē. Tas nodrošina, ka kods joprojām darbojas pat tad, kad notiek izmaiņas. Regresija nozīmē atkārtoti pārbaudīt tās lietojumprogrammas daļas, kuras ir nemainīgas.

Regresijas testi ir pazīstami arī kā verifikācijas metode. Pārbaudes gadījumi bieži tiek automatizēti. Pārbaudes gadījumi ir jāizpilda daudzas reizes, un viena un tā paša pārbaudes gadījuma manuāla palaišana atkal un atkal ir laikietilpīga un nogurdinoša.

Regresijas testēšanas piemērs

Šeit mēs aplūkosim gadījumu, lai efektīvi definētu regresijas testēšanu:

f filmas

Apsveriet produktu Y, kura viena no funkcijām ir aktivizēt apstiprinājumu, pieņemšanu un nosūtīt e-pasta ziņojumus. Tas ir arī jāpārbauda, ​​lai pārliecinātos, ka koda izmaiņas viņus neietekmē. Regresējošā pārbaude nav atkarīga no tādas programmēšanas valodas kā Java , C++ , C# uc Šo metodi izmanto, lai pārbaudītu izstrādājumā veiktās modifikācijas vai atjauninājumus. Tas nodrošina, ka jebkuras izmaiņas produktā neietekmē esošo produkta moduli. Pārbaudiet, vai izlabotās kļūdas un tikko pievienotie līdzekļi neradīja problēmas iepriekšējā Programmatūras darba versijā.

Kad mēs varam veikt regresijas testu?

Mēs veicam regresijas testēšanu ikreiz, kad tiek mainīts ražošanas kods.

Mēs varam veikt regresijas testēšanu šādā scenārijā:

1. Kad lietojumprogrammai tiek pievienota jauna funkcionalitāte.

Piemērs:

Vietnei ir pieteikšanās funkcionalitāte, kas ļauj lietotājiem pieteikties tikai ar e-pastu. Tagad tiek nodrošināta jauna funkcija, lai pieteiktos, izmantojot Facebook.

2. Ja ir izmaiņu prasība.

Piemērs:

Atcerieties paroli, kas noņemta no pieteikšanās lapas, kas bija piemērojama iepriekš.

3. Kad defekts ir novērsts

Piemērs:

Pieņemsim, ka pieteikšanās poga nedarbojas pieteikšanās lapā un testētājs ziņo par kļūdu, norādot, ka pieteikšanās poga ir bojāta. Kad izstrādātāji ir novērsuši kļūdu, testētājs to pārbauda, ​​lai pārliecinātos, ka pieteikšanās poga darbojas atbilstoši gaidītajam rezultātam. Vienlaikus testeris pārbauda citu funkcionalitāti, kas ir saistīta ar pieteikšanās pogu.

4. Ja ir veiktspējas problēmu novēršana

Piemērs:

Mājas lapas ielāde aizņem 5 sekundes, samazinot ielādes laiku līdz 2 sekundēm.

5. Kad notiek vides izmaiņas

Piemērs:

Kad mēs atjauninām datubāzi no MySql uz Oracle.

Kā veikt regresijas testu?

Regresijas testēšanas nepieciešamība rodas, ja programmatūras uzturēšana ietver uzlabojumus, kļūdu labojumus, optimizāciju un esošo līdzekļu dzēšanu. Šīs izmaiņas var ietekmēt sistēmas funkcionalitāti. Šajā gadījumā ir nepieciešama regresijas pārbaude.

Regresijas testēšanu var veikt, izmantojot šādas metodes:

1. Atkārtoti pārbaudīt visu:

Atkārtota pārbaude ir viena no pieejām regresijas testēšanai. Izmantojot šo pieeju, visas pārbaudes lietas būtu jāizpilda atkārtoti. Šeit mēs varam definēt atkārtotu pārbaudi kā tad, kad pārbaude neizdodas, un mēs nosakām, ka neveiksmes cēlonis ir programmatūras kļūme. Par kļūmi ziņots, varam sagaidīt jaunu programmatūras versiju, kurā novērsts defekts. Šādā gadījumā mums būs jāveic pārbaude vēlreiz, lai apstiprinātu, ka kļūda ir novērsta. To sauc par atkārtotu testēšanu. Daži to dēvē par apstiprinājuma testēšanu.

Atkārtota pārbaude ir ļoti dārga, jo prasa milzīgu laiku un resursus.

2. Regresijas testa izvēle:

• Izmantojot šo paņēmienu, tiks izpildīts izvēlēts testa futrāļa uzvalks, nevis viss testa lietas tērps.
• Izvēlētais testa gadījums ir sadalīts divos gadījumos
  1. Atkārtoti lietojami testa futrāļi.
  2. Novecojuši pārbaudes gadījumi.
• Atkārtoti izmantojamos testa gadījumus var izmantot nākamajā regresijas ciklā.
• Novecojušus testa gadījumus nevar izmantot nākamajā regresijas ciklā.

3. Pārbaudes gadījumu prioritāšu noteikšana:

Nosakiet testa gadījuma prioritāti atkarībā no ietekmes uz uzņēmējdarbību, kritiskās un bieži izmantotās funkcionalitātes. Pārbaudes gadījumu atlase samazinās regresijas testu komplektu.

Kādi ir regresijas testēšanas rīki?

Regresijas pārbaude ir būtiska kvalitātes nodrošināšanas procesa sastāvdaļa; veicot regresiju, mēs varam saskarties ar šādām problēmām:

Laikietilpīgs
Regresijas testēšana aizņem daudz laika. Regresijas testēšana atkal ietver esošos testus, tāpēc testētāji nav satraukti par atkārtotu pārbaudi.Komplekss
Regresijas testēšana ir sarežģīta arī tad, ja ir nepieciešams atjaunināt jebkuru produktu; pieaug arī pārbaužu saraksti.Komunikācijas biznesa noteikums
Regresijas pārbaude nodrošina, ka esošās produkta funkcijas joprojām ir darba kārtībā. Komunikācija par regresijas testēšanu ar netehnisku vadītāju var būt grūts uzdevums. Vadītājs vēlas, lai produkts virzītos uz priekšu un ieguldītu ievērojamu laiku regresijas testēšanā, lai nodrošinātu, ka esošās funkcionalitātes darbība var būt sarežģīta.Identificējiet ietekmes zonu Pārbaudes gadījumi Palielina izlaidumu ar laidienu Mazāk resursu Nav precizitātes Atkārtots uzdevums Monotons darbs

Regresijas pārbaudes process

Regresijas pārbaudes procesu var veikt visā būvē un izlaidumi .

Regresijas pārbaude visās būvēs

Ikreiz, kad kļūda ir novērsta, mēs atkārtoti pārbaudām kļūdu un, ja ir kāds atkarīgs modulis, mēs veicam regresijas testēšanu.

Piemēram , Kā mēs veicam regresijas testēšanu, ja mums ir dažādas būves kā Būvējums 1, Build 2 un Build 3 , kam ir dažādi scenāriji.

Būvējums1

• Pirmkārt, klients nodrošinās biznesa vajadzības.
• Pēc tam izstrādes komanda sāk izstrādāt funkcijas.
• Pēc tam testēšanas komanda sāks rakstīt testa gadījumus; piemēram, viņi raksta 900 testa gadījumus produkta laidienam Nr. 1.
• Un tad viņi sāks ieviest pārbaudes gadījumus.
• Kad produkts ir izlaists, klients veic vienu pieņemšanas pārbaudes kārtu.
• Un beigās produkts tiek pārvietots uz ražošanas serveri.

Būvējums2

• Tagad klients lūdz pievienot 3–4 papildu (jaunas) funkcijas, kā arī sniedz prasības jaunajām funkcijām.
• Izstrādes komanda sāk izstrādāt jaunas funkcijas.
• Pēc tam testēšanas komanda sāks rakstīt jauno funkciju testa gadījumu, un viņi uzraksta aptuveni 150 jaunus testa gadījumus. Tāpēc kopējais uzrakstīto testa gadījumu skaits ir 1050 abiem laidieniem.
• Tagad testēšanas komanda sāk testēt jaunās funkcijas, izmantojot 150 jaunus testa gadījumus.
• Kad tas būs izdarīts, viņi sāks pārbaudīt vecās funkcijas, izmantojot 900 testa gadījumus, lai pārbaudītu, vai jaunās funkcijas pievienošana ir sabojājusi vecās funkcijas.
• Šeit veco funkciju testēšana ir pazīstama kā Regresijas pārbaude .
• Kad visas funkcijas (jaunās un vecās) ir pārbaudītas, prece tiek nodota klientam, un pēc tam klients veiks pieņemšanas pārbaudi.
• Kad pieņemšanas pārbaude ir pabeigta, produkts tiek pārvietots uz ražošanas serveri.

Būvējums3

• Pēc otrā laidiena klients vēlas noņemt kādu no līdzekļiem, piemēram, Pārdošana.
• Pēc tam viņš/viņa izdzēsīs visus pārbaudes gadījumus, kas pieder pārdošanas modulim (apmēram 120 testpiemēri).
• Pēc tam pārbaudiet citu līdzekli, lai pārbaudītu, vai visas pārējās funkcijas darbojas labi pēc pārdošanas moduļa testa gadījumu noņemšanas, un šis process tiek veikts regresijas testēšanas ietvaros.

Piezīme:

kopu algebra

• Stabilo līdzekļu testēšana, lai pārliecinātos, ka tas ir bojāts izmaiņu dēļ. Šeit veiktās izmaiņas nozīmē, ka modifikācija, pievienošana, kļūdu labošana vai dzēšana .
• Atkārtoti izpildot vienus un tos pašus testēšanas gadījumus dažādās versijās vai laidienos, lai nodrošinātu, ka izmaiņas (modifikācija, pievienošana, kļūdu labošana vai dzēšana) nerada kļūdas stabilajos līdzekļos.

Regresijas pārbaude visā laidienā

Regresijas testēšanas process sākas ikreiz, kad tam pašam projektam ir jauns laidiens, jo jaunais līdzeklis var ietekmēt iepriekšējos laidienos esošos elementus.

Lai izprastu regresijas testēšanas procesu, mēs izpildīsim tālāk norādītās darbības.

1. darbība

Nav regresijas pārbaudes Izlaidums Nr. 1 jo 1. laidienā izmaiņas nenotiek, jo pats laidiens ir jauns.

2. darbība

Regresijas testēšanas jēdziens sākas no 2. izlaidums kad klients kādu iedod jaunas prasības .

3. darbība

Pēc jauno prasību iegūšanas (funkciju modificēšanas) viņi (izstrādātāji un testēšanas inženieri) sapratīs vajadzības pirms došanās uz ietekmes analīze .

4. darbība

Pēc jauno prasību izpratnes mēs veiksim vienu kārtu ietekmes analīze lai izvairītos no lielākā riska, taču šeit rodas jautājums, kurš veiks ietekmes analīzi?

5. darbība

Ietekmes analīzi veic klientu pamatojoties uz viņu biznesa zināšanas , izstrādātājs pamatojoties uz viņu kodēšanas zināšanas , un pats galvenais, to dara pārbaudes inženieris jo viņiem ir produkta zināšanas .

Piezīme. Ja to dara viena persona, viņš/viņa var neaptvert visas ietekmes zonas, tāpēc mēs iekļaujam visas personas, lai mēs varētu aptvert maksimālo ietekmes zonu, un ietekmes analīze ir jāveic izlaidumu sākumposmā.

6. darbība

Kad esam pabeiguši ar ietekmes zona , tad izstrādātājs sagatavos ietekmes apgabals (dokuments) , un klientu sagatavos arī ietekmes zonas dokuments lai mēs varētu sasniegt ietekmes analīzes maksimālais aptvērums .

7. darbība

Pēc ietekmes analīzes pabeigšanas izstrādātājs, klients un testēšanas inženieris nosūtīs Ziņojumi Nr. no ietekmes zonas dokumentiem uz Testa vads . Un tikmēr testēšanas inženieris un izstrādātājs ir aizņemti, strādājot pie jaunā testa gadījuma.

8. darbība

Tiklīdz testa potenciālais klients saņems ziņojumu #, viņš/viņa to saņems konsolidēt atskaites un saglabātas pārbaudes gadījumu prasību repozitorijs laidienam Nr. 1.

Piezīme. Testa gadījumu krātuve: šeit mēs saglabāsim visus laidienu testa gadījumus.

9. darbība

Pēc tam testa vadītājs izmantos RTM palīdzību un izvēlēsies nepieciešamo regresijas testa gadījums no testa gadījumu krātuve , un šie faili tiks ievietoti mapē Regresijas testu komplekts .

Piezīme:

• Testa vads glabās regresijas testa gadījumu regresijas testa komplektā, lai izvairītos no turpmākas neskaidrības.
Regresijas testu komplekts: Šeit mēs saglabāsim visus trieciena zonas pārbaudes dokumentus.Regresijas pārbaudes gadījumi: šie ir veco laidienu teksta dokumenta pārbaudes gadījumi, kas ir jāizpilda atkārtoti, kā redzams tālāk esošajā attēlā:

10. darbība

Pēc tam, kad testa inženieris ir pabeidzis darbu pie jaunajiem testa gadījumiem, testa vadītājs to darīs piešķirt regresijas testa gadījumu testa inženierim.

11. darbība

Kad visi regresijas testa gadījumi un jaunās funkcijas ir stabili un cauri , pēc tam pārbaudiet trieciena zonā, izmantojot testa gadījumu līdz tas būs izturīgs vecajām funkcijām un jaunajām funkcijām, un pēc tam tas tiks nodots klientam.

Regresijas testēšanas veidi

Dažādi regresijas pārbaudes veidi ir šādi:

1. Vienības regresijas pārbaude [URT]
2. Reģionālā regresijas pārbaude[RRT]
3. Pilnīga vai pilnīga regresijas pārbaude [FRT]

1) Vienības regresijas pārbaude [URT]

Šajā gadījumā mēs pārbaudīsim tikai mainīto vienību, nevis trieciena zonu, jo tas var ietekmēt tā paša moduļa sastāvdaļas.

Piemērs1

Tālāk esošajā lietojumprogrammā un pirmajā versijā izstrādātājs izstrādā Meklēt pogu, kas pieņem 1-15 rakstzīmes . Pēc tam testēšanas inženieris pārbauda pogu Meklēt ar palīdzību testa lietas projektēšanas tehnika .

Tagad klients veic dažas izmaiņas prasībā un arī pieprasa, lai Meklēt poga var pieņemt 1-35 rakstzīmes . Testēšanas inženieris pārbaudīs tikai pogu Meklēt, lai pārbaudītu, vai tā aizņem 1–35 rakstzīmes, un nepārbauda nevienu citu pirmās versijas funkciju.

Piemērs2

Lūk, mums ir Būvējums B001 , un tiek konstatēts defekts, un ziņojums tiek piegādāts izstrādātājam. Izstrādātājs novērsīs kļūdu un nosūtīs kopā ar dažām jaunām funkcijām, kas ir izstrādātas otrajā Būvējums B002 . Pēc tam pārbaudes inženieris veiks pārbaudi tikai pēc defekta novēršanas.

• Testēšanas inženieris to identificēs, noklikšķinot uz Iesniegt poga pāriet uz tukšo lapu.
• Un tas ir defekts, un tas tiek nosūtīts izstrādātājam, lai to novērstu.
• Kad jaunais būvējums nāk kopā ar kļūdu labojumiem, testēšanas inženieris pārbaudīs tikai pogu Iesniegt.
• Un šeit mēs nepārbaudīsim citas pirmās versijas funkcijas un nepāriesim, lai pārbaudītu jaunās funkcijas, kas nosūtītas otrajā būvniecībā.
• Mēs esam pārliecināti, ka labojot Iesniegt poga neietekmēs citas funkcijas, tāpēc mēs pārbaudām tikai laboto kļūdu.

Tāpēc mēs varam teikt, ka, pārbaudot, tikai mainītā funkcija tiek saukta par Vienības regresijas pārbaude .

2) Reģionālā regresijas pārbaude [RRT]

Šajā gadījumā mēs pārbaudīsim modifikāciju kopā ar ietekmes zonu vai reģioniem, ko sauc par Reģionālās regresijas pārbaude . Šeit mēs pārbaudām ietekmes apgabalu, jo, ja ir uzticami moduļi, tas ietekmēs arī citus moduļus.

Piemēram:

Zemāk redzamajā attēlā redzams, ka mums ir četri dažādi moduļi, piemēram, A modulis, B modulis, C modulis un D modulis , ko izstrādātāji nodrošina testēšanai pirmās būves laikā. Tagad testa inženieris identificēs kļūdas D modulis . Kļūdas ziņojums tiek nosūtīts izstrādātājiem, un izstrādes komanda novērš šos defektus un nosūta otro būvējumu.

Otrajā būvniecībā tiek novērsti iepriekšējie defekti. Tagad testa inženieris saprot, ka kļūdu labošana D modulī ir ietekmējusi dažas funkcijas A modulis un C modulis . Tāpēc testēšanas inženieris vispirms pārbauda D moduli, kurā kļūda ir novērsta, un pēc tam pārbauda trieciena apgabalus A modulis un C modulis . Tāpēc šī pārbaude ir pazīstama kā Reģionālās regresijas testēšana.

Veicot reģionālo regresijas testu, mēs varam saskarties ar šādu problēmu:

Problēma:

Pirmajā versijā klients nosūta dažas prasības modifikācijas, kā arī vēlas produktam pievienot jaunas funkcijas. Vajadzības tiek nosūtītas abām komandām, t.i., izstrāde un testēšana.

parsējot virkni uz int

Pēc prasību iegūšanas izstrādes komanda sāk veikt modifikācijas un arī izstrādā jaunas funkcijas, pamatojoties uz vajadzībām.

Tagad testa potenciāls nosūta pastu klientiem un jautā, vai visas ir ietekmes zonas, kuras tiks ietekmētas pēc nepieciešamo izmaiņu veikšanas. Līdz ar to klients gūs priekšstatu, kuras visas funkcijas ir nepieciešamas, lai vēlreiz pārbaudītu. Viņš arī nosūtīs e-pasta ziņojumu izstrādes komandai, lai uzzinātu, kuras visas lietojumprogrammas jomas ietekmēs izmaiņas un jaunu funkciju papildinājumi.

Un tāpat klients nosūta e-pastu testēšanas komandai, lai iegūtu ietekmes apgabalu sarakstu. Tādējādi testa potenciāls apkopos ietekmes sarakstu no klienta, izstrādes komandas un arī testēšanas komandas.

Šis Ietekmes saraksts tiek nosūtīts visiem testēšanas inženieriem, kuri apskata sarakstu un pārbauda, ​​vai viņu funkcijas ir mainītas, un, ja jā, tad viņi to dara reģionālā regresijas pārbaude . Ietekmes zonas un modificētās zonas pārbauda attiecīgie inženieri. Katrs testēšanas inženieris pārbauda tikai to funkcijas, kuras varēja ietekmēt modifikācijas.

Problēma ar šo iepriekš minēto pieeju ir tāda, ka testa potenciāls var nesaņemt visu priekšstatu par ietekmes apgabaliem, jo ​​izstrādes komandai un klientam var nebūt tik daudz laika, lai atgrieztu savus e-pastus.

Risinājums

Lai atrisinātu iepriekš minēto problēmu, mēs rīkojamies šādi:

Kad tiks piegādāta jauna versija ar jaunākajām funkcijām un kļūdu labojumiem, testēšanas komanda organizēs tikšanos, kurā pārrunās, vai to funkcijas ietekmē iepriekš minētās izmaiņas. Tāpēc viņi veiks vienu apli Ietekmes analīze un ģenerēt Ietekmes saraksts . Šajā konkrētajā sarakstā testēšanas inženieris cenšas ietvert maksimāli iespējamās trieciena zonas, kas arī samazina defektu rašanās iespēju.

Kad nāks jauns būvējums, testēšanas komanda ievēros tālāk norādīto procedūru.

• Viņi veiks dūmu testu, lai pārbaudītu lietojumprogrammas pamata funkcionalitāti.
• Pēc tam viņi pārbaudīs jaunas funkcijas.
• Pēc tam viņi pārbaudīs mainītās funkcijas.
• Kad būs pārbaudītas mainītās funkcijas, testēšanas inženieris atkārtoti pārbaudīs kļūdas.
• Un tad viņi pārbaudīs ietekmes zonu, veicot reģionālās regresijas testu.

Vienības un reģionālās regresijas pārbaudes izmantošanas trūkums

Tālāk ir norādīti daži vienības un reģionālās regresijas pārbaudes lietošanas trūkumi:

• Mēs varam palaist garām kādu trieciena zonu.
• Iespējams, mēs varam noteikt nepareizu ietekmes zonu.

Piezīme. Mēs varam teikt, ka lielais darbs, ko veicam reģionālās regresijas testēšanā, liks mums iegūt vairāk defektu. Bet, ja mēs tikpat rūpīgi strādāsim pie pilnas regresējošās testēšanas, mēs iegūsim mazāku defektu skaitu. Tāpēc šeit mēs varam noteikt, ka testēšanas centienu uzlabošana nepalīdzēs mums iegūt vairāk defektu.

3) Pilnīga regresijas pārbaude [FRT]

Produkta otrās un trešās izlaiduma laikā klients lūdz pievienot 3-4 jaunas funkcijas, kā arī ir jānovērš daži defekti no iepriekšējās versijas. Pēc tam testēšanas komanda veiks ietekmes analīzi un noteiks, ka iepriekš minētās izmaiņas liks mums pārbaudīt visu produktu.

Tāpēc mēs varam teikt, ka testēšana pārveidotas funkcijas un visas atlikušās (vecās) funkcijas tiek saukts par Pilna regresijas pārbaude .

Kad mēs veicam pilnas regresijas testēšanu?

Mēs veiksim FRT, ja mums būs šādi nosacījumi:

• Kad produkta avota failā notiek modifikācija. Piemēram , JVM ir JAVA lietojumprogrammas saknes fails, un, ja JVM tiks veiktas izmaiņas, tiks pārbaudīta visa JAVA programma.
• Kad mums ir jāveic n-skaits izmaiņu.

Piezīme:

Reģionālā regresijas pārbaude ir ideāla regresijas pārbaudes pieeja, taču problēma ir tāda, ka, veicot reģionālās regresijas testēšanu, mēs varam palaist garām daudzus defektus.

Un šeit mēs atrisināsim šo problēmu, izmantojot šādu pieeju:

• Kad testēšanai ir iesniegts pieteikums, testa inženieris pārbaudīs pirmos 10–14 ciklu un veiks RRT .
• Pēc tam 15. ciklam mēs veicam FRT. Un atkal nākamajos 10-15 ciklā mēs to darām Reģionālās regresijas testēšana , un 31. ciklam mēs veicam pilna regresijas pārbaude , un mēs turpināsim šādi.
• Bet pēdējo desmit izlaiduma ciklu mēs uzstāsies tikai pilnīga regresijas pārbaude .

Tāpēc, ja ievērosim iepriekš minēto pieeju, mēs varam iegūt vairāk defektu.

Atkārtotas manuālas regresijas pārbaudes trūkums:

• Produktivitāte samazināsies.
• Tas ir grūts darbs.
• Testa izpildē nav konsekvences.
• Un tiek palielināts arī testa izpildes laiks.

Tāpēc mēs izmantosim automatizāciju, lai atrisinātu šīs problēmas; kad mums ir regresijas testa cikla n-skaitlis, mēs izmantosim automatizācijas regresijas testēšanas process .

Automatizēts regresijas testēšanas process

Parasti mēs izmantojam automatizāciju ikreiz, kad ir vairāki izlaidumi vai vairāki regresijas cikli vai atkārtojas uzdevums.

Automatizācijas regresijas testēšanas procesu var veikt šādās darbībās:

1. piezīme:

Lietojumprogrammas testēšanas process, izmantojot dažus rīkus, ir pazīstams kā automatizācijas testēšana.

Pieņemsim, ja mēs ņemam vienu piemēru a Pieteikšanās modulis , tad kā mēs varam veikt regresijas testēšanu.

Šeit pieteikšanos var veikt divos veidos, kas ir šādi:

Manuāli: Šajā gadījumā regresiju veiksim tikai vienu un divas reizes.

Automatizācija: Šajā gadījumā mēs veiksim automatizāciju vairākas reizes, jo mums būs jāraksta testa skripti un jāveic izpilde.

2. piezīme. Reāllaikā, ja esam saskārušies ar dažām problēmām, piemēram:

1. darbība

Kad sākas jaunais laidiens, mēs neveicam automatizāciju, jo nav regresijas testēšanas un regresijas pārbaudes gadījuma koncepcijas, kā mēs to sapratām iepriekš minētajā procesā.

2. darbība

Kad sākas jaunais laidiens un uzlabojumi, mums ir divas komandas, t.i., manuālā komanda un automatizācijas komanda.

3. darbība

Rokas darba grupa izskatīs prasības, kā arī noteiks ietekmes zonu un nodos prasību pārbaudes komplekts automatizācijas komandai.

4. darbība

Tagad manuālā komanda sāk strādāt pie jaunajām funkcijām, un automatizācijas komanda sāks izstrādāt testa skriptu, kā arī sāks automatizēt testa gadījumu, kas nozīmē, ka regresijas testa gadījumi tiks pārveidoti par testa skriptu.

5. darbība

Pirms viņi (automatizācijas komanda) sāk automatizēt testa gadījumu, viņi arī analizēs, kuras visas lietas var automatizēt vai nē.

6. darbība

Pamatojoties uz analīzi, viņi sāks automatizāciju, t.i., pārveidos katru regresijas testa gadījumu testa skriptā.

7. darbība

Šī procesa laikā viņi izmantos palīdzību Regresijas gadījumi jo viņiem nav tik labas zināšanas par produktiem rīks un pieteikumu .

8. darbība

Kad testa skripts būs gatavs, viņi sāks šo skriptu izpildi jaunajā lietojumprogrammā [vecā funkcija]. Tā kā testa skripts tiek rakstīts, izmantojot regresijas līdzekli vai veco līdzekli.

9. darbība

Kad izpilde ir pabeigta, mēs iegūstam citu statusu, piemēram, Ieskaitīts/neizturēts .

10. darbība

Ja statuss ir neizdevies, tas nozīmē, ka tas ir atkārtoti jāapstiprina manuāli, un, ja kļūda pastāv, tā ziņos attiecīgajam izstrādātājam. Kad izstrādātājs izlabo šo kļūdu, manuālās pārbaudes inženierim ir atkārtoti jāpārbauda kļūda kopā ar apgabalu Impact, kā arī automatizācijas pārbaudes inženierim ir atkārtoti jāizpilda skripts.

11. darbība

Šis process turpinās, līdz tiks nodoti visi jaunie līdzekļi un regresijas līdzeklis.

Regresijas testēšanas priekšrocības, izmantojot automatizācijas testēšanu:

Precizitātevienmēr pastāv, jo uzdevumu veic rīki, un instrumenti nekad neapnīk.
• Testa skriptu var atkārtoti izmantot vairākos laidienos.
Partijas izpildeir iespējams, izmantojot automatizāciju t.i.; visus rakstītos testa skriptus var izpildīt paralēli vai vienlaicīgi.
• Pat ja regresijas pārbaudes gadījumu skaits palielina izlaidumu katrā laidienā, un mums nav jāpalielina automatizācijas resurss, jo daži regresijas gadījumi jau ir automatizēti no iepriekšējā laidiena.
• Tas ir laiku taupošs process jo izpilde vienmēr ir ātrāka nekā manuālā metode.

Kā izvēlēties pārbaudes gadījumus regresijas testēšanai?

Tas tika konstatēts rūpnieciskajā pārbaudē. Vairāki defekti, par kuriem ziņo klients, radās pēdējā brīža kļūdu labojumu dēļ. Blakusparādību radīšana un līdz ar to testa gadījuma izvēle regresijas testēšanai ir māksla, nevis viegls uzdevums.

Regresijas testu var veikt:

• Testa gadījums ar biežiem defektiem
• Lietotājiem redzamākas funkcijas.
• Testa gadījumi pārbauda produkta galvenās funkcijas.
• Visi integrācijas pārbaudes gadījumi
• Visi sarežģītie testa gadījumi
• Robežvērtību pārbaudes gadījumi
• Veiksmīgu testa gadījumu paraugs
• Pārbaudes gadījumu neveiksme

Regresijas testēšanas rīki

Ja Programmatūra tiek bieži mainīta, palielinās arī regresijas testēšanas izmaksas. Šādos gadījumos manuāla testa gadījumu izpilde palielina testa izpildes laiku, kā arī izmaksas. Tādā gadījumā automatizācijas pārbaude ir labākā izvēle. Automatizācijas ilgums ir atkarīgs no testa gadījumu skaita, kas paliek atkārtoti izmantojami secīgiem regresijas cikliem.

Tālāk ir minēti galvenie regresijas testēšanas rīki:

Selēns

Selēns ir atvērtā koda rīks. Šis rīks tiek izmantots tīmekļa lietojumprogrammas automatizētai testēšanai. Pārlūkprogrammas regresijas testēšanai izmantots selēns. Selēns, ko izmanto UI līmeņa regresijas testā tīmekļa lietojumprogrammām.

Ranorex studija

Viss vienā regresijas testa automatizācija galddatoriem, tīmeklī un mobilajām lietotnēm ar iebūvētu Selenium Web Driver. Ranorex Studio ietver pilnu IDE plus rīkus bezkoda automatizācijai.

Ātrās pārbaudes profesionālis (QTP)

QTP ir automatizēts testēšanas rīks, ko izmanto regresijas un funkcionālajai pārbaudei. Tas ir uz datiem balstīts uz atslēgvārdiem balstīts rīks. Tā automatizācijai izmantoja VBScript valodu. Ja atveram QTP rīku, mēs redzam trīs pogas, kas ir Ierakstīt, atskaņot un apturēt . Šīs pogas palīdz reģistrēt katru klikšķi un darbību, kas veikta datorsistēmā. Tas ieraksta darbības un atskaņo to.

Rational Functional Tester (RTF)

Racionālais funkcionālais testeris ir Java rīks, ko izmanto programmatūras lietojumprogrammu testēšanas gadījumu automatizēšanai. RTF izmanto, lai automatizētu regresijas pārbaudes gadījumus, un tas arī integrējas ar racionālo funkcionālo testeri.

Papildinformāciju par regresijas un automatizācijas testēšanas rīkiem skatiet tālāk esošajā saitē:

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

Regresijas testēšana un konfigurācijas pārvaldība

Konfigurācijas pārvaldība regresijas pārbaudē kļūst obligāta Agile Environments, kur kods tiek nepārtraukti modificēts. Lai nodrošinātu derīgu regresijas testu, mums ir jāveic šādas darbības:

• Regresijas pārbaudes fāzē kodā izmaiņas nav atļautas.
• Regresijas pārbaudes gadījumam ir jābūt neietekmētām izstrādātāja izmaiņām.
• Regresijas testēšanai izmantotajai datubāzei jābūt izolētai; izmaiņas datu bāzē nav atļautas.

Atšķirības starp atkārtotu testēšanu un regresijas testēšanu

Atkārtota pārbaude Testēšana nozīmē vēlreiz pārbaudīt funkcionalitāti vai kļūdu, lai nodrošinātu koda labošanu. Ja tas nav iestatīts, defekti nav jāatver atkārtoti. Ja tas ir novērsts, defekts tiek slēgts.

Atkārtota testēšana ir testēšanas veids, kas tiek veikts, lai pārbaudītu, ka galīgajā izpildē neveiksmīgie testa gadījumi tiek veiksmīgi izieti pēc defektu novēršanas.

Regresijas pārbaude nozīmē programmatūras lietojumprogrammas testēšanu, kad tajā tiek mainīts kods, lai nodrošinātu, ka jaunais kods nav ietekmējis citas Programmatūras daļas.

Regresijas testēšana ir testēšanas veids, ko veic, lai pārbaudītu, vai kods nav mainījis esošās lietojumprogrammas funkcionalitāti.

Atšķirības starp atkārtotu testēšanu un regresijas testēšanu ir šādas:

Regresijas testēšanas priekšrocības

Regresijas pārbaudes priekšrocības ir:

• Regresijas pārbaude uzlabo produkta kvalitāti.
• Tas nodrošina, ka kļūdu labojumi vai izmaiņas neietekmē produkta esošo funkcionalitāti.
• Regresijas testēšanai var izmantot automatizācijas rīkus.
• Tas nodrošina, ka novērstās problēmas vairs neatkārtojas.

Regresijas testēšanas trūkumi

Regresijas testēšanai ir vairākas priekšrocības, taču ir arī trūkumi.

• Regresijas pārbaude jāveic nelielām koda izmaiņām, jo ​​pat nelielas izmaiņas kodā var radīt problēmas esošajā funkcionalitātē.
• Ja projektā testēšanai netiek izmantota automatizācija, atkārtotas pārbaudes veikšana būs laikietilpīgs un nogurdinošs uzdevums.

Secinājums

Regresijas testēšana ir viens no būtiskiem aspektiem, jo ​​tas palīdz nodrošināt kvalitatīvu produktu, kas ietaupa organizācijas laiku un naudu. Tas palīdz nodrošināt kvalitatīvu produktu, pārliecinoties, ka jebkādas koda izmaiņas neietekmē esošo funkcionalitāti.

Huffman kodēšanas kods

Regresijas pārbaudes gadījumu automatizēšanai ir pieejami vairāki automatizācijas rīki. Rīkam ir jābūt iespējai atjaunināt testa komplekts jo regresijas testa uzvalks ir bieži jāatjaunina.