Test og kvalitetssikring Lars Skjrbk UCH Pris for
Test og kvalitetssikring Lars Skjærbæk, UCH
Pris for ændringer x 150 Fejl skal findes så tidligt i processen som muligt! x 50 x 20 x 5 Specifikation Design Kodning Test Produktion
Software review typer Peer review (walk through – inspections) Formålet er at finde fejl i dokumentet og få dem rettet (formativ test), således at kvaliteten øges. Godkendelses review Formålet er at få andres (ledelsen, kunden, …) accept af et dokument
Formaliseret review Forberedelse – indkald de rigtige folk til review møde og sørg for at de rigtige dokumenter er tilgængelige Klar rollefordeling (review leder, referent, forfatter, reviewer – kompetencer) Alle deltagere skal være forberedt! Struktureret gennemgang af dokumentet Fejl/problemer noteres ned (stavefejl, kodefejl, funktionalitetsfejl, brugergrænseflade problemer, performance og sikkerhedsproblemer …) I nogle tilfælde diskuteres løsningsforslag (afhængig af om der er tid til det – dette styrer review lederen) Der tages evt. stilling til godkendelse af dokumentet (kan være betinget) Problemerne løses
God konstruktiv feedback Det er dokumentet der reviewes – ikke personen. Husk at gå efter bolden Husk det er godt når vi finder en fejl, mangel eller uklarhed, for så kan vi få den løst Vær positiv og konstruktiv når du giver feedback Man skal ikke diskutere om noget er et problem. Ser nogen et problem er det der. Forstår du ikke problemet så stil opklarende spørgsmål Husk at du SKAL være kritisk. Et review der ikke finder fejl, er spild af tid
Debugging er processen at finde fejl og rette dem Editoren kan ofte hjælpe med at påpege syntaks fejl – eksempelvis at vi har glemt et ; eller en } Andre fejl skal vi selv regne ud – eksempelvis en løkke, der ikke er sat rigtigt op Man kan gøre brug af debugging værktøjer: Break points, afviklingshastighed, variabel vinduer Man kan indføre debugging information i softwaren (eksempelvis printe en tekst eller indholdet af en variabel ud på skærmen)
Accept test En accept test bruges til at verificere at systemet overholder de specificerede krav. Denne test er en ”black box” test. Det vil sige, at man ikke behøver kende noget til, hvorledes softwaren er opbygget. Man skal bare kende til kravene Accepttesten skal føre en systematisk og struktureret igennem alle produktets funktioner Accepttesten ligger ofte til grund for kundens accept af produktet (heraf navnet). Laves der en ny release bør hele accepttesten gennemføres igen
Udfyldes når testen gennemføres Test Cases Navn: Kasseapp Step Input Forventet resultat Resultat af testen Dato: 1 Start Kasseapp vises. Det skal tydeligt fremgå at der ikke er indtastet data OK 2 Scan vare (Indtast 12. 75 og tryk ”Tilføj vare”) Man skal nu se at sum er 12. 75 OK 3 Indtast ugyldigt input (space) og tryk ”Tilføj vare” Input ignoreres Fejl #1 4 Indtast negativt tal (-456. 78) ? 5 Tryk ”Betal med kort” Man skal kunne se summen, og at der skal betales med kort
Udfyldes for hvert problem Problemrapport Problem fundet: 1/12 -19 af LSK Problem rapport nr. : 1 Problem vedrørende: Indtastning af ugyldige input Problem beskrivelse: Når man ikke indtaster noget, eller hvis man indtaster et ugyldigt input (bogstav eller tegn) og trykker ”Tilføj vare” går app’en i baglås. Årsag og løsning: Kun tal kan adderes til sum. Der skal derfor testes for, om input er et gyldigt tal, inden det lægges til sum. Den der finder problemet Den der løser problemet Kategori: A Problem rettet: 1/12 -19 af LSK Problemlister (Åbne, rettede, alvorlige fejl, statistik, m. m. )
- Slides: 9