TechCodeview

Regressiotestaus on mustan laatikon testaustekniikka. Sitä käytetään todentamaan ohjelmiston koodin muutos, joka ei vaikuta tuotteen olemassa olevaan toiminnallisuuteen. Regressiotestaus varmistaa, että tuote toimii hyvin uusien toimintojen, virheenkorjausten tai olemassa olevan ominaisuuden muutosten kanssa.

Regressiotestaus on eräänlainen ohjelmistojen testaus . Testitapaukset suoritetaan uudelleen, jotta tarkistetaan, että sovelluksen aiemmat toiminnot toimivat hyvin, eivätkä uudet muutokset ole aiheuttaneet virheitä.

Regressiotestaus voidaan suorittaa uudelle versiolle, kun alkuperäisessä toiminnallisuudessa tapahtuu merkittävä muutos. Se varmistaa, että koodi toimii edelleen, vaikka muutoksia tapahtuu. Regressio tarkoittaa, että testaa uudelleen ne sovelluksen osat, jotka ovat muuttumattomia.

Regressiotestit tunnetaan myös verifiointimenetelmänä. Testitapaukset ovat usein automatisoituja. Testitapaukset on suoritettava useita kertoja, ja saman testitapauksen suorittaminen uudelleen ja uudelleen manuaalisesti on myös aikaa vievää ja työlästä.

Esimerkki regressiotestauksesta

Tässä aiomme ottaa tapauksen määrittääksemme regressiotestauksen tehokkaasti:

Harkitse tuotetta Y, jossa yksi toiminnoista on käynnistää vahvistus, hyväksyntä ja lähetetyt sähköpostit. Se on myös testattava sen varmistamiseksi, että koodin muutos ei vaikuttanut niihin. Regressiivinen testaus ei riipu mistään ohjelmointikielestä, kuten Java , C++ , C# jne. Tätä menetelmää käytetään tuotteen testaamiseen muutosten tai tehtyjen päivitysten varalta. Se varmistaa, että tuotteen muutokset eivät vaikuta tuotteen olemassa olevaan moduuliin. Varmista, että korjatut virheet ja uudet lisätyt ominaisuudet eivät aiheuttaneet ongelmia Ohjelmiston aiemmassa toimivassa versiossa.

Milloin voimme suorittaa regressiotestauksen?

Teemme regressiotestauksen aina, kun tuotantokoodia muutetaan.

Voimme suorittaa regressiotestauksen seuraavassa skenaariossa, nämä ovat:

pilvilaskentasovellukset

1. Kun sovellukseen on lisätty uusia toimintoja.

Esimerkki:

Verkkosivustolla on kirjautumistoiminto, jonka avulla käyttäjät voivat kirjautua sisään vain sähköpostilla. Nyt tarjolla uusi ominaisuus kirjautumiseen Facebookin kautta.

2. Kun on olemassa muutosvaatimus.

Esimerkki:

Muista kirjautumissivulta poistettu salasana, joka oli voimassa aiemmin.

3. Kun vika on korjattu

Esimerkki:

Oletetaan, että kirjautumispainike ei toimi kirjautumissivulla ja testaaja ilmoittaa virheestä, jonka mukaan kirjautumispainike on rikki. Kun kehittäjät ovat korjanneet vian, testaaja testaa sen varmistaakseen, että kirjautumispainike toimii odotetun tuloksen mukaisesti. Samanaikaisesti testaaja testaa muita toimintoja, jotka liittyvät kirjautumispainikkeeseen.

4. Kun suorituskykyongelma on korjattu

Esimerkki:

Kotisivun lataaminen kestää 5 sekuntia, jolloin latausaika lyhenee 2 sekuntiin.

5. Kun ympäristö muuttuu

Esimerkki:

Kun päivitämme tietokannan MySql:stä Oracleen.

Kuinka regressiotestaus suoritetaan?

Regressiotestauksen tarve syntyy, kun ohjelmiston ylläpitoon kuuluu parannuksia, virheenkorjauksia, optimointia ja olemassa olevien ominaisuuksien poistamista. Nämä muutokset voivat vaikuttaa järjestelmän toimintaan. Regressiotestaus on tässä tapauksessa tarpeen.

Regressiotestaus voidaan suorittaa seuraavilla tekniikoilla:

1. Testaa kaikki uudelleen:

Uudelleentestaus on yksi regressiotestauksen menetelmistä. Tässä lähestymistavassa kaikki testitapauspuvut tulisi suorittaa uudelleen. Tässä voimme määritellä uudelleentestauksen niin, että testi epäonnistuu, ja määritämme, että epäonnistumisen syy on ohjelmistovika. Vika on raportoitu, voimme odottaa uutta ohjelmistoversiota, jossa vika korjattu. Tässä tapauksessa meidän on suoritettava testi uudelleen varmistaaksemme, että vika on korjattu. Tätä kutsutaan uudelleentestaukseksi. Jotkut kutsuvat tätä vahvistustestiksi.

Uusintatestaus on erittäin kallista, koska se vaatii valtavasti aikaa ja resursseja.

2. Regressiotestin valinta:

• Tässä tekniikassa valittu testitapauspuku suoritetaan koko testitapauspuvun sijaan.
• Valittu testitapaus sopii jaettuna kahteen tapaukseen
  1. Uudelleenkäytettävät testikotelot.
  2. Vanhentuneet testitapaukset.
• Uudelleenkäytettäviä testitapauksia voidaan käyttää seuraavassa regressiosyklissä.
• Vanhentuneita testitapauksia ei voi käyttää seuraavassa regressiosyklissä.

3. Testitapausten priorisointi:

Priorisoi testitapaus liiketoimintavaikutusten, kriittisten ja usein käytettyjen toimintojen mukaan. Testitapausten valinta vähentää regressiotestisarjaa.

Mitä regressiotestaustyökalut ovat?

Regressiotestaus on olennainen osa laadunvarmistusprosessia; Suorittaessamme regressiota voimme kohdata seuraavat haasteet:

Aikaavievä
Regressiotestauksen suorittaminen vie paljon aikaa. Regressiotestaus sisältää olemassa olevat testit uudelleen, joten testaajat eivät innostu suorittamaan testiä uudelleen.Monimutkainen
Regressiotestaus on myös monimutkaista, kun jokin tuote on päivitettävä; myös testiluettelot lisääntyvät.Liiketoiminnan sääntö ilmoittaminen
Regressiotestaus varmistaa, että nykyiset tuoteominaisuudet ovat edelleen toimintakunnossa. Regressiotestausta koskeva viestintä ei-teknisen johtajan kanssa voi olla vaikea tehtävä. Johtaja haluaa nähdä tuotteen etenevän ja investoivan huomattavasti aikaa regressiotestaukseen varmistaakseen, että nykyisten toimintojen toiminta voi olla vaikeaa.Tunnista vaikutusalue Testitapaukset lisää julkaisua julkaisulta Vähemmän resursseja Ei tarkkuutta Toistuva tehtävä Yksitoikkoista työtä

Regressiotestausprosessi

Regressiotestausprosessi voidaan suorittaa kaikkialla rakentaa ja julkaisut .

Regressiotestaus rakennelmien välillä

Aina kun vika on korjattu, testaamme virheen uudelleen, ja jos on riippuvainen moduuli, menemme regressiotestaukseen.

Esimerkiksi , Kuinka suoritamme regressiotestauksen, jos meillä on erilaisia ​​koontiversioita Rakennus 1, rakennus 2 ja rakennus 3 , joilla on erilaiset skenaariot.

Rakenna 1

• Ensin asiakas toimittaa liiketoiminnan tarpeet.
• Sen jälkeen kehitystiimi alkaa kehittää ominaisuuksia.
• Sen jälkeen testausryhmä alkaa kirjoittaa testitapauksia; esimerkiksi he kirjoittavat 900 testitapausta tuotteen julkaisulle #1.
• Ja sitten he alkavat toteuttaa testitapauksia.
• Kun tuote on julkaistu, asiakas suorittaa yhden hyväksymistestauksen.
• Ja lopulta tuote siirretään tuotantopalvelimelle.

Rakenna 2

• Nyt asiakas pyytää 3-4 (uutta) lisäominaisuuden lisäämistä ja ilmoittaa myös uusien ominaisuuksien vaatimukset.
• Kehitystiimi alkaa kehittää uusia ominaisuuksia.
• Sen jälkeen testaustiimi alkaa kirjoittaa uusien ominaisuuksien testitapausta ja kirjoittaa noin 150 uutta testitapausta. Siksi molempien julkaisujen testitapausten kokonaismäärä on 1050.
• Nyt testaustiimi alkaa testata uusia ominaisuuksia 150 uudella testitapauksella.
• Kun se on tehty, he alkavat testata vanhoja ominaisuuksia 900 testitapauksen avulla varmistaakseen, onko uuden ominaisuuden lisääminen vahingoittanut vanhoja ominaisuuksia vai ei.
• Täällä vanhojen ominaisuuksien testaus tunnetaan nimellä Regressiotestaus .
• Kun kaikki ominaisuudet (uudet ja vanhat) on testattu, tuote luovutetaan asiakkaalle, jonka jälkeen asiakas suorittaa hyväksymistestauksen.
• Kun hyväksymistestaus on suoritettu, tuote siirretään tuotantopalvelimelle.

Rakenna 3

• Toisen julkaisun jälkeen asiakas haluaa poistaa yhden ominaisuuksista, kuten Myynnin.
• Sitten hän poistaa kaikki myyntimoduuliin kuuluvat testitapaukset (noin 120 testitapausta).
• Testaa sitten toista ominaisuutta varmistaaksesi, että kaikki muut ominaisuudet toimivat hyvin myyntimoduulin testitapausten poistamisen jälkeen, ja tämä prosessi suoritetaan regressiotestauksen alla.

Huomautus:

• Vakaiden ominaisuuksien testaus sen varmistamiseksi, että se on rikki muutosten takia. Tässä muutokset tarkoittavat, että muokkaus, lisäys, virheenkorjaus tai poistaminen .
• Suorittamalla samat testitapaukset uudelleen eri koontiversioissa tai julkaisuissa on tarkoitus varmistaa, että muutokset (muokkaus, lisäys, virheenkorjaus tai poistaminen) eivät aiheuta bugeja vakaisiin ominaisuuksiin.

Regressiotestaus koko julkaisun ajan

Regressiotestausprosessi alkaa aina, kun samalle projektille tulee uusi julkaisu, koska uusi ominaisuus saattaa vaikuttaa aiempien julkaisujen vanhoihin elementteihin.

Ymmärtääksemme regressiotestausprosessin, noudatamme seuraavia vaiheita:

Vaihe 1

Siinä ei ole regressiotestausta Julkaisu nro 1 koska julkaisussa nro 1 ei tapahdu muutoksia, koska julkaisu itsessään on uusi.

Vaihe 2

Regressiotestauksen käsite alkaa Julkaisu nro 2 kun asiakas antaa uusia vaatimuksia .

Vaihe 3

Saatuaan ensin uudet vaatimukset (muokkausominaisuudet) he (kehittäjät ja testiinsinöörit) ymmärtävät tarpeet ennen kuin he siirtyvät vaikutusanalyysi .

Vaihe 4

harhaa ja varianssia

Kun ymmärrämme uudet vaatimukset, suoritamme yhden kierroksen vaikutusanalyysi suuren riskin välttämiseksi, mutta tässä herää kysymys, kuka tekee vaikutusanalyysin?

Vaihe 5

Vaikutusanalyysin tekee asiakas heidän perusteellaan liiketoiminnan tuntemus , kehittäjä heidän perusteellaan koodaustietoa , ja mikä tärkeintä, sen tekee testiinsinööri koska heillä on Tuotetieto .

Huomaa: Jos yksittäinen henkilö kattaa, hän ei välttämättä kata kaikkia vaikutusalueita, joten otamme mukaan kaikki henkilöt, jotta voimme kattaa suurimman vaikutusalueen, ja vaikutusanalyysi tulee tehdä julkaisujen alkuvaiheessa.

Vaihe 6

Kun olemme tehneet vaikutusalue , sitten kehittäjä valmistelee vaikutusalue (asiakirja) , ja asiakas valmistelee myös vaikutusalueen asiakirja jotta voimme saavuttaa vaikutusanalyysin enimmäiskattavuus .

Vaihe 7

Vaikutusanalyysin suorittamisen jälkeen kehittäjä, asiakas ja testiinsinööri lähettävät Raportit# vaikutusalueen asiakirjoista Testijohto . Ja sillä välin testiinsinööri ja kehittäjä työskentelevät kiireisenä uuden testitapauksen parissa.

Vaihe 8

Kun testijohto saa Raportit#, hän saa sen lujittaa raportit ja tallennettu testitapausvaatimusten arkisto julkaisulle #1.

Huomautus: Testitapausvarasto: Tallennamme tähän kaikki julkaisujen testitapaukset.

Vaihe 9

Sen jälkeen testijohto ottaa RTM:n avun ja valitsee tarvittavat regressiotestin tapaus alkaen testitapausten arkisto , ja kyseiset tiedostot sijoitetaan kansioon Regression Test Suite .

Huomautus:

• Testijohto tallentaa regressiotestitapauksen regressiotestisarjaan, jotta sekaannuksia ei enää synny.
Regressiotestisarja: Tallennamme tähän kaikki vaikutusalueen testiasiakirjat.Regressiotestitapaukset: Nämä ovat vanhojen julkaisujen tekstiasiakirjan testitapauksia, jotka on suoritettava uudelleen, kuten alla olevasta kuvasta näkyy:

Vaihe 10

Sen jälkeen, kun testiinsinööri on työskennellyt uusien testitapausten parissa, testijohto tekee määrittää regressiotestin tapaus testiinsinöörille.

Vaihe 11

Kun kaikki regressiotestitapaukset ja uudet ominaisuudet ovat vakaa ja läpäisevä , tarkista sitten iskualue testitapauksen avulla kunnes se kestää vanhoja ominaisuuksia ja uusia ominaisuuksia, ja sitten se luovutetaan asiakkaalle.

Regressiotestauksen tyypit

Regressiotestien eri tyypit ovat seuraavat:

1. Yksikköregressiotestaus [URT]
2. Alueellinen regressiotestaus[RRT]
3. Täydellinen tai täydellinen regressiotestaus [FRT]

1) Yksikköregressiotestaus [URT]

Tässä testataan vain muuttunutta yksikköä, ei iskualuetta, koska se voi vaikuttaa saman moduulin komponentteihin.

Esimerkki1

Alla olevassa sovelluksessa ja ensimmäisessä koontiversiossa kehittäjä kehittää Hae painiketta, joka hyväksyy 1-15 merkkiä . Sitten testiinsinööri testaa Haku-painiketta testitapauksen suunnittelutekniikka .

Nyt asiakas tekee joitain muutoksia vaatimukseen ja pyytää myös, että Haku-painike voi hyväksyä 1-35 merkkiä . Testausinsinööri testaa vain Hae-painiketta varmistaakseen, että se kestää 1–35 merkkiä, eikä tarkista ensimmäisen koontiversion muita ominaisuuksia.

Esimerkki2

Tässä meillä on Rakenne B001 , ja vika tunnistetaan ja raportti toimitetaan kehittäjälle. Kehittäjä korjaa virheen ja lähettää mukana joitakin uusia ominaisuuksia, jotka kehitetään toisessa Rakenne B002 . Sen jälkeen testausinsinööri testaa vasta vian korjaamisen jälkeen.

• Testausinsinööri tunnistaa sen napsauttamalla Lähetä -painike siirtyy tyhjälle sivulle.
• Ja se on vika, ja se lähetetään kehittäjälle sen korjaamista varten.
• Kun uusi versio tulee virheenkorjausten mukana, testiinsinööri testaa vain Lähetä-painiketta.
• Ja tässä emme aio tarkistaa ensimmäisen koontiversion muita ominaisuuksia ja siirtyä testaamaan toisessa koontiversiossa lähetettyjä uusia ominaisuuksia.
• Olemme varmoja, että korjaamme Lähetä -painike ei vaikuta muihin ominaisuuksiin, joten testaamme vain korjattua vikaa.

Siksi voimme sanoa, että testaamalla vain muuttunutta ominaisuutta kutsutaan nimellä Yksikköregressiotestaus .

2) Alueellinen regressiotestaus [RRT]

Tässä aiomme testata muutosta yhdessä vaikutusalueen tai -alueiden kanssa, joita kutsutaan nimellä Alueellinen regressiotestaus . Tässä testaamme vaikutusaluetta, koska jos on luotettavia moduuleja, se vaikuttaa myös muihin moduuleihin.

Esimerkiksi:

Alla olevassa kuvassa kuten voimme nähdä, että meillä on neljä erilaista moduulia, kuten Moduuli A, moduuli B, moduuli C ja moduuli D , jotka kehittäjät tarjoavat testausta varten ensimmäisen koontiversion aikana. Nyt testiinsinööri tunnistaa virheet Moduuli D . Virheraportti lähetetään kehittäjille, ja kehitystiimi korjaa nämä viat ja lähettää toisen koontiversion.

Toisessa rakennuksessa aiemmat viat korjataan. Nyt testiinsinööri ymmärtää, että moduulin D virheenkorjaus on vaikuttanut joihinkin ominaisuuksiin Moduuli A ja moduuli C . Tästä syystä testiinsinööri testaa ensin moduulia D, jossa vika on korjattu, ja tarkistaa sitten törmäysalueet Moduuli A ja moduuli C . Siksi tämä testi tunnetaan nimellä Alueellinen regressiotestaus.

Suorittaessamme alueellista regressiotestausta saatamme kohdata seuraavan ongelman:

Ongelma:

Ensimmäisessä koontiversiossa asiakas lähettää vaatimuksena joitain muutoksia ja haluaa myös lisätä tuotteeseen uusia ominaisuuksia. Tarpeet lähetetään molemmille tiimeille eli kehitykseen ja testaukseen.

näkymät ja pöydät

Vaatimusten saamisen jälkeen kehitystiimi aloittaa muokkauksen ja myös kehittää uusia ominaisuuksia tarpeiden mukaan.

Nyt testijohto lähettää sähköpostia asiakkaille ja kysyy heiltä, ​​että kaikki ovat ne vaikutusalueet, jotka vaikuttavat tarvittavien muutosten tekemisen jälkeen. Näin asiakas saa käsityksen, mitä kaikkia ominaisuuksia tarvitaan testattavaksi uudelleen. Hän myös lähettää kehitystiimille sähköpostin, jossa hän tietää, mihin kaikkiin sovelluksen alueisiin muutokset ja uusien ominaisuuksien lisäykset vaikuttavat.

Vastaavasti asiakas lähettää testitiimille sähköpostin vaikutusalueluettelon saamiseksi. Näin ollen testijohto kerää vaikutusluettelon myös asiakkaalta, kehitystiimiltä ja testaustiimiltä.

Tämä Vaikutusluettelo lähetetään kaikille testiinsinööreille, jotka tarkastelevat luetteloa ja tarkistavat, onko heidän ominaisuuksiaan muutettu, ja jos on, niin he tekevät alueellinen regressiotestaus . Vastaavat insinöörit testaavat kaikki vaikutusalueet ja muokatut alueet. Jokainen testiinsinööri testaa vain ominaisuuksiaan, joihin muutos olisi voinut vaikuttaa.

Tämän yllä olevan lähestymistavan ongelmana on, että testijohto ei välttämättä saa koko käsitystä vaikutusalueista, koska kehitystiimillä ja asiakkaalla ei ehkä ole niin paljon aikaa palauttaa sähköpostinsa.

Ratkaisu

Yllä olevan ongelman ratkaisemiseksi noudatamme alla olevaa prosessia:

Kun uusi versio tulee uusimpien ominaisuuksien ja virheenkorjausten kanssa, testaustiimi järjestää tapaamisen, jossa keskustellaan, vaikuttavatko heidän ominaisuudet yllämainitun muutoksen vuoksi. Siksi he tekevät yhden kierroksen Vaikutusanalyysi ja luoda Vaikutusluettelo . Testi-insinööri yrittää sisällyttää tähän luetteloon suurimmat todennäköiset iskualueet, mikä myös vähentää mahdollisuutta saada vikoja.

Kun uusi versio tulee, testaustiimi noudattaa alla olevaa menettelyä:

• He tekevät savutestauksen tarkistaakseen sovelluksen perustoiminnallisuuden.
• Sitten he testaavat uusia ominaisuuksia.
• Sen jälkeen he tarkistavat muuttuneet ominaisuudet.
• Kun he ovat tarkistaneet muuttuneet ominaisuudet, testiinsinööri testaa virheet uudelleen.
• Ja sitten he tarkistavat vaikutusalueen suorittamalla alueellisen regressiotestin.

Yksikkö- ja alueregressiotestauksen käytön haittapuoli

Seuraavassa on joitain yksikkö- ja alueregressiotestauksen käytön haittoja:

• Saatamme unohtaa jonkin vaikutusalueen.
• On mahdollista, että tunnistamme väärän vaikutusalueen.

Huomaa: Voimme sanoa, että suuri työ, jonka teemme alueellisessa regressiotestauksessa, johtaa siihen, että saamme enemmän virheitä. Mutta jos suoritamme saman omistautumisen työskennelläksemme täydellisen regressiivisen testauksen parissa, saamme vähemmän virheitä. Tästä syystä voimme päätellä, että testaustyön tehostaminen ei auta meitä saamaan lisää vikoja.

3) Täysi regressiotestaus [FRT]

Tuotteen toisen ja kolmannen julkaisun aikana asiakas pyytää lisäämään 3-4 uutta ominaisuutta, ja myös joitain virheitä on korjattava edellisestä julkaisusta. Sitten testaustiimi tekee vaikutusanalyysin ja tunnistaa, että yllä oleva muutos johtaa meidät testaamaan koko tuotetta.

Siksi voimme sanoa, että testaus muokatut ominaisuudet ja kaikki jäljellä olevat (vanhat) ominaisuudet kutsutaan nimellä Täysi regressiotestaus .

Milloin suoritamme täyden regressiotestin?

Suoritamme FRT:n, kun meillä on seuraavat ehdot:

• Kun muutos tapahtuu tuotteen lähdetiedostossa. Esimerkiksi , JVM on JAVA-sovelluksen juuritiedosto, ja jos JVM:ssä tapahtuu muutoksia, koko JAVA-ohjelma testataan.
• Kun meidän on suoritettava n-määrä muutoksia.

Huomautus:

Alueellinen regressiotestaus on ihanteellinen lähestymistapa regressiotestaukseen, mutta ongelmana on, että saatamme missata monia virheitä suorittaessamme alueellista regressiotestausta.

Ja tässä aiomme ratkaista tämän ongelman seuraavan lähestymistavan avulla:

• Kun testaushakemus on annettu, testiinsinööri testaa ensimmäiset 10-14 sykliä ja suorittaa RRT .
• Sitten 15. sykliä varten teemme FRT:n. Ja jälleen, seuraavan 10-15 syklin ajan Alueellinen regressiotestaus , ja 31. syklille teemme täydellinen regressiotestaus , ja jatkamme näin.
• Mutta julkaisun viimeisen kymmenen jakson aikana suoritamme vain täydellinen regressiotestaus .

Siksi, jos noudatamme yllä olevaa lähestymistapaa, voimme saada lisää vikoja.

Toistuvan manuaalisen regressiotestauksen haittapuoli:

• Tuottavuus laskee.
• Se on vaikea tehtävä.
• Testin suorittamisessa ei ole johdonmukaisuutta.
• Ja myös testin suoritusaika pidennetään.

Siksi lähdemme automaatioon päästäksemme yli näistä ongelmista; kun meillä on n-luku regressiotestisyklistä, lähdemme käyttämään automaation regressiotestausprosessi .

Automatisoitu regressiotestausprosessi

Yleensä lähdemme automaatioon aina, kun on useita julkaisuja tai useita regressiojaksoja tai toistuvia tehtäviä.

Automaatioregressiotestausprosessi voidaan suorittaa seuraavissa vaiheissa:

Huomautus1:

Sovelluksen testausprosessia käyttämällä joitain työkaluja kutsutaan automaatiotestaukseksi.

Oletetaan, jos otamme yhden esimerkkiesimerkin a Kirjautumismoduuli , kuinka voimme suorittaa regressiotestin.

Täällä kirjautuminen voidaan tehdä kahdella tavalla, jotka ovat seuraavat:

Käsin: Tässä suoritamme regression vain kerran ja kahdesti.

Automaatio: Tässä teemme automatisoinnin useita kertoja, kun meidän on kirjoitettava testiskriptit ja suoritettava.

Huomautus2: Reaaliajassa, jos olemme kohdanneet joitain ongelmia, kuten:

Vaihe 1

Kun uusi julkaisu alkaa, emme ryhdy automaatioon, koska ei ole olemassa käsitettä regressiotestauksesta ja regressiotestaustapauksesta, kuten ymmärsimme yllä olevassa prosessissa.

Vaihe 2

Kun uusi julkaisu ja parannus alkavat, meillä on kaksi tiimiä, eli manuaalinen tiimi ja automaatiotiimi.

Vaihe 3

Manuaalitiimi käy läpi vaatimukset ja tunnistaa myös vaikutusalueen ja luovuttaa sen vaatimustestipaketti automaatiotiimille.

Vaihe 4

Manuaalitiimi alkaa nyt työstää uusia ominaisuuksia ja automaatiotiimi aloittaa testiskriptin kehittämisen ja myös testitapauksen automatisoinnin, mikä tarkoittaa, että regressiotestitapaukset muunnetaan testiskriptiksi.

Vaihe 5

Ennen kuin he (automaatiotiimi) alkavat automatisoida testitapausta, he myös analysoivat, mitkä kaikki tapaukset voidaan automatisoida vai ei.

Vaihe 6

Analyysin perusteella he aloittavat automatisoinnin eli muuntavat jokaisen regressiotestitapauksen testiskriptiksi.

Vaihe 7

java abstrakti luokka

Tämän prosessin aikana he käyttävät apua Regressiotapaukset koska heillä ei ole yhtä hyvää tuotetietoa kuin työkalu ja sovellus .

Vaihe 8

Kun testiskripti on valmis, he aloittavat näiden komentosarjojen suorittamisen uudessa sovelluksessa [vanha ominaisuus]. Koska testiskripti kirjoitetaan regressioominaisuuden tai vanhan ominaisuuden avulla.

Vaihe 9

Kun suoritus on valmis, saamme erilaisen tilan, kuten Hyväksytty/hylätty .

Vaihe 10

Jos tila epäonnistuu, mikä tarkoittaa, että se on vahvistettava uudelleen manuaalisesti, ja jos virhe on olemassa, se raportoi asianomaiselle kehittäjälle. Kun kehittäjä korjaa tämän virheen, manuaalisen testausinsinöörin on testattava Bug uudelleen Impact-alueen kanssa, ja myös automaatiotestausinsinöörin on suoritettava komentosarja uudelleen.

Vaihe 11

Tämä prosessi jatkuu, kunnes kaikki uudet ominaisuudet ja regressioominaisuus ohitetaan.

Automaatiotestauksen regressiotestauksen edut:

Tarkkuuson aina olemassa, koska työ tehdään työkaluilla ja työkalut eivät koskaan kyllästy tai väsy.
• Testiohjelmaa voidaan käyttää uudelleen useissa julkaisuissa.
Eräsuorituson mahdollista käyttämällä automaatiota eli; kaikki kirjoitetut testiskriptit voidaan suorittaa rinnakkain tai samanaikaisesti.
• Vaikka regressiotestitapausten määrä lisää julkaisua julkaisua kohti, eikä meidän tarvitse lisätä automaatioresurssia, koska osa regressiotapauksista on jo automatisoitu edellisestä julkaisusta.
• Se on a aikaa säästävä prosessi koska suoritus on aina nopeampi kuin manuaalinen menetelmä.

Kuinka valita testitapaukset regressiotestausta varten?

Se löytyi teollisuustarkastuksesta. Useat asiakkaan ilmoittamat viat johtuivat viime hetken virheenkorjauksista. Nämä sivuvaikutusten luominen ja siten testitapauksen valitseminen regressiotestausta varten on taidetta, ei helppo tehtävä.

Regressiotesti voidaan tehdä seuraavasti:

• Testitapaus, jossa on usein vikoja
• Käyttäjille paremmin näkyvät toiminnot.
• Testitapaukset varmistavat tuotteen ydinominaisuudet.
• Kaikki integraatiotestitapaukset
• Kaikki monimutkaiset testitapaukset
• Raja-arvotestitapaukset
• Esimerkki onnistuneista testitapauksista
• Testitapausten epäonnistuminen

Regressiotestaustyökalut

Jos ohjelmistoa muutetaan usein, myös regressiotestauksen kustannukset kasvavat. Näissä tapauksissa testitapausten manuaalinen suorittaminen lisää testin suoritusaikaa ja lisää kustannuksia. Siinä tapauksessa automaatiotestaus on paras valinta. Automatisoinnin kesto riippuu testitapausten määrästä, jotka ovat käytettävissä uudelleen peräkkäisissä regressiojaksoissa.

Seuraavat ovat tärkeimmät työkalut, joita käytetään regressiotestaukseen:

Seleeni

Seleeni on avoimen lähdekoodin työkalu. Tätä työkalua käytetään verkkosovelluksen automaattiseen testaukseen. Seleeniä käytetty selainpohjaiseen regressiotestaukseen. Seleeniä käytetään verkkopohjaisten sovellusten käyttöliittymätason regressiotestissä.

Ranorex Studio

Kaikki yhdessä regressiotestin automaatio työpöytä-, verkko- ja mobiilisovelluksille sisäänrakennetulla Selenium-verkkoohjaimella. Ranorex Studio sisältää täyden IDE:n ja työkalut koodittomaan automaatioon.

Quick Test Professional (QTP)

QTP on automaattinen testaustyökalu, jota käytetään regressio- ja funktionaaliseen testaukseen. Se on tietoihin perustuva avainsanapohjainen työkalu. Se käytti VBScript-kieltä automaatioon. Jos avaamme QTP-työkalun, näemme kolme painiketta, jotka ovat Tallenna, toista ja lopeta . Nämä painikkeet auttavat tallentamaan jokaisen tietokonejärjestelmän napsautuksen ja toiminnon. Se tallentaa toiminnot ja toistaa ne.

Rational Functional Tester (RTF)

Rationalfunctional tester on Java-työkalu, jota käytetään ohjelmistosovellusten testitapausten automatisointiin. RTF:ää käytetään regressiotestitapausten automatisointiin, ja se integroituu myös rationaalisen toiminnallisen testaajan kanssa.

Lisätietoja regressio- ja automaatiotestaustyökaluista on alla olevasta linkistä:

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

Regressiotestaus ja konfiguraatioiden hallinta

Regressiotestauksen konfiguraatioiden hallinnasta tulee välttämätön ketterissä ympäristöissä, joissa koodia muokataan jatkuvasti. Varmistaaksemme oikean regressiotestin, meidän on noudatettava vaiheita:

• Muutokset koodiin eivät ole sallittuja regressiotestausvaiheen aikana.
• Regressiotestitapauksessa on oltava kehittäjän muutokset, joilla ei ole vaikutusta.
• Regressiotestaukseen käytettävä tietokanta on eristettävä; muutokset eivät ole sallittuja tietokannassa.

Erot uudelleentestauksen ja regressiotestauksen välillä

Uudelleentestaus Testaus tarkoittaa toiminnallisuuden tai bugin testaamista uudelleen varmistaakseen, että koodi on korjattu. Jos sitä ei ole asetettu, vikoja ei tarvitse avata uudelleen. Jos vika korjataan, vika sulkeutuu.

Uudelleentestaus on eräänlainen testaus, jolla tarkistetaan lopullisessa suorituksessa epäonnistuneet testitapaukset, jotka läpäistään onnistuneesti vikojen korjaamisen jälkeen.

Regressiotestaus tarkoittaa ohjelmistosovelluksen testaamista sen koodin muutoksen aikana sen varmistamiseksi, että uusi koodi ei ole vaikuttanut Ohjelmiston muihin osiin.

Regressiotestaus on eräänlainen testaus, joka suoritetaan sen tarkistamiseksi, eikö koodi ole muuttanut sovelluksen olemassa olevia toimintoja.

Erot uudelleentestauksen ja regressiotestauksen välillä ovat seuraavat:

Regressiotestauksen edut

Regressiotestin edut ovat:

• Regressiotestaus parantaa tuotteen laatua.
• Se varmistaa, että virheenkorjaukset tai muutokset eivät vaikuta tuotteen olemassa oleviin toimintoihin.
• Automaatiotyökaluja voidaan käyttää regressiotestaukseen.
• Se varmistaa, että korjatut ongelmat eivät toistu.

Regressiotestauksen haitat

Regressiotestauksella on useita etuja, vaikka niissä on myös haittoja.

• Regressiotestaus tulisi tehdä pienille koodin muutoksille, koska pienikin koodin muutos voi aiheuttaa ongelmia olemassa olevaan toiminnallisuuteen.
• Jos automaatiota ei käytetä projektissa testaamiseen, on testin suorittaminen yhä uudelleen ja uudelleen aikaa vievää ja työlästä.

Johtopäätös

Regressiotestaus on yksi olennaisista näkökohdista, koska se auttaa toimittamaan laadukkaan tuotteen, joka säästää organisaation aikaa ja rahaa. Se auttaa tarjoamaan laadukkaan tuotteen varmistamalla, että koodin muutokset eivät vaikuta olemassa oleviin toimintoihin.

Regressiotestitapausten automatisointiin on saatavilla useita automaatiotyökaluja. Työkalulla tulee olla kyky päivittää testisarja koska regressiotestin puku on päivitettävä usein.