Regresjonstesting

I dagens verden er Regresjonstesting et tema med stor relevans og interesse for et bredt spekter av befolkningen. Dens innvirkning strekker seg til ulike aspekter av dagliglivet, fra vitenskap og teknologi til politikk og kultur. I denne artikkelen vil de ulike fasettene til Regresjonstesting bli utforsket, og analysere dens historiske betydning, dens utvikling over tid og dens innflytelse på dagens samfunn. Gjennom en tverrfaglig tilnærming søker vi å tilby en fullstendig og detaljert visjon av Regresjonstesting, slik at leseren kan forstå dens relevans og implikasjoner i dagens verden.

Regresjonstesting består av flere steg som kan standardiseres og kjøres automatisk

Regresjonstesting er når man på nytt kjører funksjonelle og ikke-funksjonelle tester for å sikre at programvare som tidligere har blitt utviklet og testet fortsatt fungerer som forventet etter en endring.[1][2] De brukes for å detektere om feilrettinger eller endringer har introdusert nye feil eller uønskede effekter.[3] Dersom regresjonstesten feiler kan oppdateringene ha ført til feil med tidligere fungerende kode, og man har fått en regresjon (tilbakesteg) som kan kreve videre avlusing.

Endringer som kan kreve regresjonstesting inkluderer vanlig fiks av programvarelus, forbedringer av programvare, konfigurasjonsendringer eller til og med bytte av maskinvare.[4] Testautomasjon brukes ofte med regresjonstesting ettersom testsuiter[5] for regresjonstester har en tendens til å vokse med hver funnede defekt. Det åpenbare unntaket er regresjonstester på grafisk brukergrensesnitt, som vanligvis må utføres manuelt. Noen ganger utføres en konsekvensanalyse for å bestemme en passende delmengde av tester (ikke-regresjonsanalyse[6]).

Når kode redesignes kan noen av de samme feilene som ble gjort i den opprinnelige implementasjonen også bli gjort i den redesignede versjonen. Derfor ansees det som god praksis når man har oppdaget og fikset en feil at man lager en test som vil avsløre slike feil og rekjøre slike tester med jevne mellomrom etter påfølgende endringer i programmet.[7]

Automatiserte regresjonstester

Selv om regresjonstesting kan gjøres med manuelle testprosedyrer gjøres det ofte ved hjelp av automatiserte testverktøy.[8] Testpakker kan brukes for å sette opp automatisk kjøring av regresjons-testtilfeller. Vanlige strategier er å kjøre tester etter hver vellykket kompilering (for små prosjekter), hver kveld eller en gang i uken. Hvis en regresjonstest feiler kan det også være at den er utdatert. Regresjonstesting utføres etter at funksjonell testing er avsluttet for å verifisere at de andre funksjonene fungerer.

I prosjekter

Regresjonstesting er en viktig del av ekstrem programmering (XP), en metode hvor designdokumenter erstattes av omfattende, repeterbare og automatiserte tester gjennom hele utviklingsprosessen. I smidig programvareutvikling, som har korte utviklingssykluser med lite ressurser og hyppige programvareendringer, kan regresjonstesting føre til mye unødvendig overhead.[9]

Regresjonstesting har tradisjonelt vært gjort etter at utviklingen er ferdig, men feil som finnes på dette stadiet kan være dyre å reparere. Dette problemet kan avhjelpes med enhetstesting. Selv om utviklere alltid har skrevet testtilfeller som en del av utviklingssyklusen har disse generelt vært enten funksjonelle tester eller enhetstester som bare bekrefter de planlagte resultatene. Utviklingstesting tvinger en utvikler til å fokusere på enhetstesting og å inkludere både positive og negative testtilfeller.[10]

Se også

Referanser

  1. ^ Pezzè, Mauro; Young, Michal (2008). Software testing and analysis: process, principles, and techniques (PDF). Wiley. ISBN 978-0-471-45593-6. «Testing activities that focus on regression problems are called (non) regression testing. Usually "non" is omitted» 
  2. ^ Basu, Anirban. Software Quality Assurance, Testing and Metrics. PHI Learning. ISBN 978-81-203-5068-7. 
  3. ^ «Arkivert kopi». data.skatteetaten.no. Arkivert fra originalen 13. august 2023. Besøkt 12. august 2023. 
  4. ^ Aging Avionics in Military Aircraft. Washington, D.C.: National Academies Press. 7. mai 2001. ISBN 978-0-309-07449-0. 
  5. ^ Erik van Veenendaal (engelsk), Ernst von Düring (norsk) (25. mai 2014). «Glossary Working Party, International Software Testing Qualifications Board» (PDF). «testsuite: En samling av flere testtilfeller for et testobjekt der etterbetingelsen til en test ofte blir brukt som forutsetning for neste test» 
  6. ^ Boulanger, Jean-Louis (2015). CENELEC 50128 and IEC 62279 Standards. Wiley. ISBN 978-1119122487. 
  7. ^ Kolawa, Adam; Huizinga, Dorota. Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. s. 73. ISBN 978-0-470-04212-0. 
  8. ^ Automate Regression Tests When Feasible, Automated Testing: Selected Best Practices, Elfriede Dustin, Safari Books Online
  9. ^ Yoo, S.; Harman, M. (2010). «Regression testing minimization, selection and prioritization: a survey». Software Testing, Verification and Reliability. 22 (2): 67–120. doi:10.1002/stvr.430. 
  10. ^ Dudney, Bill. «Developer Testing Is 'In': An interview with Alberto Savoia and Kent Beck». Besøkt 29. november 2007.