Laste ned presentasjonen
Presentasjon lastes. Vennligst vent
PublisertSiw Borgen Endret for 9 år siden
1
I dag snakker vi om : zLitt om 3. oblig ztesting zsluttdokumentasjon zProduktdokumentasjon
2
Om 3.oblig zTesting skal beskrives nøyaktig,presist og som et vitenskapelig forsøk. Hver del av testen må kunne kontrolleres zDel opp i følgende deler yBeskrivelse av testpersonene yHvordan testpersonene ble intervjuet og mottatt yHvilke oppgaver de fikk yHvordan testen forløp yHvilke konklusjoner dere trakk
3
Testing med papirprototyp. PAPIRPROTOTYP fordi zKan brukes tidlig i prosessen zLettere å rette opp feil tidlig zUhøytidelig, skremmer ikke bruker
4
Ulemper zMindre realistisk zVanskelig å se hvordan ting fungerer når det blir så lite fart i programmet
5
Det som kan testes tidlig, er yPrinsipiell vindusdesign yBegreper som brukes yRekkefølge og flyt yOm brukerens mentale modell stemmer noenlunde med utviklerens ide
6
Vanskelig å teste zArbeidet BAK skjermbildet zOm alle funksjoner er med zFarger, fonter
7
Viktig i all testing zHensikten er å finne feil i designet, ikke å bevise at gruppa er feilfri zMan må aldri bruke gruppa selv som prøvepersoner zDet er nødvendig med flere testpersoner fordi folk reagerer forskjellig zNår noen påpeker et problem, bør dere forklare hvordan dere har forholdt dere til det og hvorfor dere retter opp/ikke retter opp
8
TESTING znødvendig zsjelden perfekt zkan ikke teste alt ztesting av programmer kan være en egen jobb zi Norge vanligvis en del av programmerers jobb zTidlig testing - billige endringer
9
Kan ikke teste alt zteste de riktige tingene zdokumentere hva som er testet zsikre overensstemmelse med kravspesifikasjonen
10
Testing i ulike faser. Formativ testing zGjennomgang av kyndige mennesker (systemeringsfasen) zTidlig testing av design(prototyp) zFunksjonell testing yblack box-testing yglassbox-testing zprestasjonstesting zbåde top down og bottom up-testing zTesting av brukergrensesnitt med prøvepersoner – kan brukes i alle faser
11
Summativ testing zfor ferdige produkter: sammenligninger
12
Hovedprosjekt-testing: zgjennomgang : sammen med oppdragsgiver/brukere zevt. tidlig testing med papirprototyp zFormative testinger - hele veien zTesting etter hvert zvanligvis bare funksjonell testing zkombinasjon av kontinuerlig bottom up og top down zViktig å klargjøre hva som er testet (dokumentering)
13
Testplan for funksjonell testing zFinn ut:hva skal testes zLag plan foran hver aktuell testbit, noter: yformålet med testen yhvilken del av systemet som testes ytid, sted og organisering av testen yhvilke inndata - hvilke resultater ventes-hvilke menyer/veier som skal testes yeventuelle testprosedyrer zTenk på at planen bør kunne delvis gjenbrukes som rapport!
14
Testing av enkeltbiter - beregninger. Sett inn zen del «vanlige» verdier, + grenseverdier: ysærlig store verdier y0 -1 ydel med 0 ynegative verdier (-1) yulovlige/ugyldige verdier yblank yprøv ulike funksjonstaster
15
Testing av enkeltbiter zSjekk begge sider av if-else-setninger zPrøv ugyldig input - bl.a. ulike funksjonstaster zPrøv å fylle ut et felt med for mange tegn zSjekk æøå zStore og små bokstaver
16
Testing av helhet zSjekk overensstemmelse med kravspesifikasjonen zGå gjennom alle eventuelle veier i menyen zSjekk eventuelle grenseverdier for hele systemet zSjekk hva som skjer med «gale» eller ugyldige tastetrykk for hele systemet zSjekk for virus
17
I dag legges det stadig mer vekt på brukermedvirkning i tester
18
Vurder med prøvepersoner: zhvor lett å utføre oppgavene? yeffektivitet ybrukertilfredshet zFeilhåndteringen yblir det lett feil? ylett å rette opp feil? yhvor gode er feilmeldingene? zskjermhjelpen ysjekk stikkord yha helst både innholdsliste og stikkordliste (rokkert!)
19
Brukertesting kan inneholde zObservasjon av brukere zVideofilming zObservasjon mens bruker tenker høyt zSpørreskjemaer zTelling av feil zHurtighet
20
Test også brukerdokumentasjonen! zDen kan endres mye lengre ut i prosessen enn designet
21
Enhver retting medfører fare for nye feil zSjekk rettede deler etter rettingen
22
Testrapport= riktig oppsatt testplan med zresultater zdrøfting av resultater
23
Sluttdokumentasjonen består av zProsessdokumentasjon zKravspesifikasjon zProduktdokumentasjon zm. testdokumentasjon zBrukerdokumentasjon zKode – på diskett eller hjemmeside
24
Innbinding for papirversjon zFelles perm eller flere separate deler? zHvis felles perm: yfelles tittelside yfelles innholdsliste med hoveddeler ylett å finne de enkelte hoveddeler yegen innholdsliste, presentasjon og forord (evt. sammendrag) for hver hoveddel yNB! Innholdsliste, presentasjon og forord er forskjellige for hver del yNB! Pass på at hele utskriften er med
25
Produktdokumentasjon på papir zberegnet på 1) vedlikehold av program ymodifiseringer yutvidelser yfeilfinning og feilvurdering z2) faglærer og sensor yforståelse av programmet yvurdering av faglige kvaliteter
26
Leser av produktdokumentasjonen er zdatakyndig - men kjenner ikke alle detaljer i alle programmer – og slett ikke oppgaven zveileder har fått en del rapporter, men har neppe full oversikt zsensor kan møte problem og verktøy for første gang
27
Produktdokumentasjon på papir består av: zBeskrivelse av programmet z( Selve koden, på diskett eller hjemmeside - avtale med veileder ) zTestrapport zHUSK AT PRODUKT-DOKUMENTASJONEN SKAL KUNNE LESES SEPARAT!
28
Hoveddeler av produktbeskrivelsen zInnledende del zBeskrivelse av programmet zVurdering-drøfting
29
Innledende del zInnholdsliste zHva er hensikten med programmet, og hvem er det beregnet på?Forkunnskaper? zHvordan fungerer det i hovedtrekk
30
Beskrivelse av programmet zProgrammets virkemåte og prinsipielle oppbygging zDatastruktur - begrunnelse for valg zViktige trekk ved brukergrensesnittet zForholdet hovedprogram/ underprogrammer (ofte skjermbilder) zhver hoveddel presenteres kort zEVENTUELLE PROBLEMER SOM ER OPPDAGET VED KONSTRUKSJONEN
31
Andre sider ved programmet zforholdet til maskiner, lagerplass, operativsystemer zspesielle forhold ved implementasjonen zhvis aktuelt: om sikkerhet
32
Vurdering/drøfting (finn egne overskrifter) zBegrensninger (hva som ikke er med ) zUtviklings- og utvidelsesmuligheter zHva kunne vært gjort annerledes hvis - (NB! I prosessdokumentasjonen kan det også være aktuelt å si hva dere ville gjort annerledes, med den erfaring dere har. Hvis disse to punktene vil bli for like: vurder om stoffet hører hjemme i produktdokumentasjonen eller prosessdokumentasjonen)
Liknende presentasjoner
© 2024 SlidePlayer.no Inc.
All rights reserved.