Regressiotestaus ( eng. regression testing ← lat. regressio "liikkuminen takaisin, paluu, vetäytyminen") on yhteisnimi kaikenlaisille ohjelmistotestauksille, joiden tarkoituksena on havaita virheet jo testatuissa lähdekoodin osissa . Tällaisia virheitä - kun ohjelmaan tehtyjen muutosten jälkeen jokin, jonka olisi pitänyt toimia, lakkaa toimimasta - niitä kutsutaan regressiovirheiksi .
Regressiotestaus (joillekin[ mitä? ] lähteet) sisältää uuden virheenkorjauksen - äskettäin löydetyn vian korjauksen tarkistamisen, vanhan virheen korjauksen - tarkistamisen, ettei aiemmin korjattu ja varmennettu vika toistu järjestelmään uudelleen, sekä myös sivuvaikutuksen - tarkastetaan, että aiemmin toiminut toiminnallisuus ei ole rikki , jos sen koodiin voi vaikuttaa joidenkin muiden toimintojen vikojen korjaaminen. Yleisesti käytettyjä regressiotestausmenetelmiä ovat aikaisempien testien uudelleenajo sekä sen tarkistaminen, onko regressiovirheitä päässyt seuraavaan versioon koodin yhdistämisen seurauksena.
Ohjelmistokehityskokemuksesta tiedetään, että samojen virheiden toistuminen on melko yleinen tapaus. Joskus tämä johtuu heikkoista versionhallintatekniikoista tai inhimillisestä virheestä versionhallinnassa . Mutta yhtä usein ratkaisu ongelmaan on "lyhytaikainen": seuraavan ohjelman muutoksen jälkeen ratkaisu lakkaa toimimasta. Ja lopuksi, kun kirjoitat mitä tahansa koodin osaa uudelleen, esiin tulee usein samat virheet, jotka olivat edellisessä toteutuksessa.
Siksi virheen korjaamisen yhteydessä pidetään hyvänä käytäntönä luoda sille testi ja suorittaa se säännöllisesti ohjelman myöhempien muutosten kanssa. Vaikka regressiotestaus voidaan tehdä manuaalisesti, se tehdään useimmiten erikoisohjelmien avulla, joiden avulla voit suorittaa kaikki regressiotestit automaattisesti . Jotkut projektit käyttävät jopa työkaluja regressiotestien automaattiseen suorittamiseen tietyllä aikavälillä. Tämä tehdään yleensä jokaisen onnistuneen kokoamisen jälkeen (pienissä projekteissa) joko joka ilta tai joka viikko.
Regressiotestaus on olennainen osa Extreme Programming -ohjelmaa . Tämä menetelmä korvaa suunnitteludokumentaation laajennettavalla, toistettavissa olevalla ja automatisoidulla koko ohjelmistopaketin testauksella ohjelmistokehitysprosessin jokaisessa vaiheessa .
Regressiotestausta voidaan käyttää paitsi ohjelman oikeellisuuden tarkistamiseen, sitä käytetään usein myös tuloksen laadun arvioimiseen. Joten, kun kehitetään kääntäjää ja suoritettaessa regressiotestejä, otetaan huomioon tuloksena olevan koodin koko, sen suoritusnopeus ja kunkin testitapauksen käännösaika.
S. Yoo ja M. Harman [1] tarjoavat artikkelissaan seuraavan regressiotestauksen luokituksen:
Sarjan minimointitestillä pyritään pienentämään testijoukon kokoa poistamalla testitapaukset testijoukosta tietyn kriteerin perusteella. On olemassa kolme lähestymistapaa, joista ensimmäinen käyttää automaattista tietoturvatestausta haavoittuvuuksien havaitsemiseen tutkimalla sovellusviat, jotka voivat havaita tunnetut haittaohjelmat, kuten virukset tai madot. Tämä lähestymistapa ottaa huomioon, että vain edellisen version epäonnistuneet testit suoritetaan uudelleen järjestelmän uudessa versiossa ongelman korjaamisen jälkeen.
Toinen lähestymistapa on suunniteltu havaitsemaan ja korjaamaan verkkosovellusten pienissä julkaisuissa olevia haavoittuvuuksia. Se muodostaa kiinteän linkin edellisen version sivuihin käyttämällä iteraattoreita, jotka on valittu tutkimaan haavoittuvuuksia sisältäviä verkkosivuja.
Ja lopuksi, kolmas lähestymistapa tarjoaa testauksen, jossa järjestelmä mukautuu itseensä jo tunnettujen vikojen varalta. Kirjoittajat välttävät toistamasta jo tunnettuja virheitä harkitsemalla suoritettaviksi vain niitä testejä, jotka paljastivat aiempien versioiden tunnetut viat.
Priorisointitestin ongelmana on testien oikea järjestys, joka maksimoi halutut ominaisuudet, kuten vikojen varhaisen havaitsemisen. Myös nykyiset priorisointimenetelmät huomioivat vain haavoittuvuudet.
Eräs menetelmä tarjoaa virhepohjaisia prioriteettitestejä, jotka hyödyntävät suoraan tietoa kyvystään havaita vikoja.
Toinen tarjoaa vaihdettavan äänitystoistojärjestelmän, jonka avulla voit kirjoittaa tallennetun, suoritetun sovelluksen version uudeksi, muokatuksi. Niiden suoritus on priorisoitu, koska optimaalinen muokattu uudelleenkirjoitus määritetään kustannusfunktion perusteella ja mitataan alkuperäisen suorituksen ja muokatun suorituksen välinen ero uudelleen yrittäessä.
Valintamenetelmällä voit valita osajoukon tai kaikki testitapaukset ohjelmiston muuttuneiden osien testaamiseksi. Seuraavat lähestymistavat testaavat sekä suojausmekanismeja että haavoittuvuuksia.
Regressiotestaus suoritetaan, kun ohjelmiston olemassa olevaan toiminnallisuuteen tehdään muutoksia tai jos ohjelmistossa on virheenkorjaus. Regressiotestaus voidaan toteuttaa useilla lähestymistavoilla. Kaikkien testien läpäiseminen muokatun ohjelman toimesta antaa varmuuden siitä, että ohjelmistoon tehdyt muutokset eivät vaikuta olemassa olevaan toiminnallisuuteen, jonka tulee joka tapauksessa pysyä ennallaan.
Ketterässä projektinhallintaprosessissa, jossa ohjelmistokehityksen elinkaari on hyvin lyhyt, resurssit ovat niukat ja ohjelmistomuutoksia tehdään erittäin usein. Regressiotestaus voi aiheuttaa paljon tarpeettomia yleiskustannuksia.
Yleensä regressiotestaus tehdään automaatiotyökaluilla, mutta nykyisen sukupolven regressiotestaustyökaluja ei ole suunniteltu käsittelemään tietokantasovelluksia. Tästä syystä tietokantoja käyttävien sovellusten regressiotestin suorittaminen saattaa aiheuttaa odottamattomia kustannuksia, koska se vaatii paljon manuaalista työtä.
Ohjelmiston ylläpidon perusongelma on, että yhden vian korjaaminen aiheuttaa suurella todennäköisyydellä (20-50 %) uuden. Siksi koko prosessi noudattaa periaatetta "kaksi askelta eteenpäin, yksi askel taaksepäin".
Miksi emme voi korjata virheitä tarkemmin? Ensinnäkin, jopa piilotettu vika ilmenee epäonnistumisena yhdessä paikassa. Todellisuudessa sillä on usein seurauksia koko järjestelmään, jotka eivät yleensä ole ilmeisiä. Jokainen yritys korjata se pienellä vaivalla korjaa sen, mikä on paikallista ja ilmeistä, mutta ellei rakenne ole erittäin selkeä tai dokumentaatio on erittäin hyvä, tämän korjauksen pitkän aikavälin vaikutukset jäävät huomaamatta. Toiseksi, virheitä ei yleensä korjaa ohjelman tekijä, vaan usein nuorempi ohjelmoija tai harjoittelija.
Uusien bugien vuoksi ohjelman ylläpito vaatii paljon enemmän järjestelmän virheenkorjausta lauseketta kohden kuin mikään muu ohjelmointimuoto. Teoriassa jokaisen korjauksen jälkeen on suoritettava koko joukko testitapauksia, joita vastaan järjestelmä on tarkastettu aiemmin, jotta voidaan varmistaa, ettei se ole vaurioitunut jollain käsittämättömällä tavalla. Käytännössä tällaisen backtracking (regressio)testauksen pitäisi todellakin lähestyä tätä teoreettista ihannetta, ja se on erittäin kallista.
- F. Brooks Myyttinen mieskuukausi eli ohjelmistojärjestelmien luominen [2]