1.08 Test

Debugging De fleste programmer har bugs (fejl). Det er vigtigt at sikre at der ikke er fejl der gør programmet ubrugeligt. Når en fejl opstår kan det være svært at finde årsagen. Den process hedder debugging. Debugging: er at finde, rette og fjerne bugs (fejl) Debugging: er at finde, rette og fjerne bugs (fejl)

Unit Test Unit test betyder direkte oversat “enheds test” Det betyder at man tester én enhed af gangen. Denne process kan automatiseres. Det er god programmeringskik altid at lave unit tests til sin kode. Denne kan automatiseres til at udføres hver gang et program køres med ny kode Dette kaldes at “builde” programmet. Unit test: tester automatisk hver gang, der sker en ny aktivitet f.eks. Ny programmering. Det vil sige at man bliver opdateret om problemer/fejl (bugs) med det samme. Det er derfor nemmere, at finde og rette bugsene. Unit test: tester automatisk hver gang, der sker en ny aktivitet f.eks. Ny programmering. Det vil sige at man bliver opdateret om problemer/fejl (bugs) med det samme. Det er derfor nemmere, at finde og rette bugsene.

Hvordan debugger man At debugge kan være rigtigt svært. Ofte er det sværeste skridt at identificere hvor fejlen opstår. Der findes værktøjer der kan gøre denne process nemmere. Eksempel: Developer tools. For at være en dygtig programmør skal man mestre debugging. Det er vigtigt at undgå at introducere nye fejl når man debugger. Det sværeste er ikke at rette fejlen, men at finde ud af hvor fejlen er opstået. Fejlen ligger ofte i programeringskoderne. Det sværeste er ikke at rette fejlen, men at finde ud af hvor fejlen er opstået. Fejlen ligger ofte i programeringskoderne.

Test I en vandfaldsmodel påbegyndes test når implementeringsfasen er slut. I agil udvikling er det lidt mere flydende. Man tester dele af systemet løbende. Tests udføres ved hjælp af testcases. Det er vigtigt at undgår at “skære” I testen pga. Deadlines.

Testcases Testcases udføres af testerne. En god testcase: Definerer de krav den tester. Beskriver de skridt der udføres. Beskriver det ventede resultat. Er målbar. At være tester kræver stor grundighed og endnu større tålmodighed.

Opgave 4.3 – c4067 i systime 10 Minutter

GUI Grafical User Interface eller Brugergrænseflade Modtager input fra brugeren Hvilke former for input kan man give en brugergrænseflade?

Brugervenlighed KISS er altid et godt mantra Eksempel: Google Hvor meget vil brugeren gøre? Det kommer an på motivationen. Er man motiveret kan man acceptere en dårligere brugergrænseflade (men er stadig irriteret) Er man ikke motiveret skal det være ekstremt nemt at bruge.

Brugerfeedback på GUI Dårlig brugergrænseflade God brugergrænseflade Dårligt produkt Brugere skifter produkt Brugere er kortvarigt glade pga. den gode grænseflade, men skifter så produkt Godt produkt Brugere ærgres og ender med at skifte produkt Brugere er tilfredse

Godt og skidt Godt: Brugercentrering Grænsefladen... Dårligt: Ingen brugercentrering Grænsefladen... er opbygget med udgangspunkt i brugerens viden er opbygget med udgangspunkt i specialviden, man ikke kan forvente af brugeren er opbygget med udgangspunkt i genkendelse er opbygget med udgangspunkt i genkaldelse giver brugerne en fornemmelse af at vide, hvad de laver forvirrer brugerne lader brugeren bruge de typer input, brugeren bedst kan lide skal bruges på én bestemt måde er organiseret efter brugernes brugsmønstre: De mest almindelige funktioner er de lettest tilgængelige er organiseret efter en dybere, men for brugere skjult logik: De funktioner, en bruger hyppigst ønsker at bruge, er ikke nødvendigvis nemme at komme til

Opgave 4.2 – c4064 10 minutter