Forord Dette er testdokumentasjonen skrevet i forbindelse med hovedprosjekt ved Høgskolen i Oslo våren 2010.

Transkript

1 TESTDOKUMENTASJON

2 Forord Dette er testdokumentasjonen skrevet i forbindelse med hovedprosjekt ved Høgskolen i Oslo våren Dokumentet beskriver hvordan applikasjonen er testet. Dokumentet er beregnet for sensor, vår veileder og andre skulle ha interesse for applikasjonen. Om leser søker utfyllende dokumentasjon om prosessen, testing og bruk av produktet henviser vi til prosess-, test- og brukerdokumentasjon.

3 Detaljert innholdsfortegnelse for testdokumentasjonen Innhold Detaljert innholdsfortegnelse for testdokumentasjonen Innlending Testing av parser Testing av eventer Testing av bilder Akseptansetester Resultater... 10

4 3.1 Innledning For å forsikre at applikasjon fungerer slik den er ment å fungere, har vi valgt å gjennomføre tester. Disse testene fungerer som en kvalitetssikring for at applikasjonen fungerer i tråd med kravene og at det er implementer riktig tiltenkt funksjonalitet. Det er gjennomført to typer tester av applikasjonen. Den ene tester parseren, for å forsikre at alle verdiene som skal visualiseres er i tråd med innholdet i loggfilen. Den andre testen en akseptansetest, som tester det grafiske brukergrensesnittet. 3.2 Testing av parser Testing av eventer Grunnmuren i applikasjonen vi har utviklet er parseren, som tar for seg hvert enkelt event i loggen og henter ut det vi trenger til visualiseringen. For å finne ut om parseren virket som det skal, har vi testet dataene som ligger i loggfilene mot det som er hentet ut og lagt i databasen. Måten vi har gjort dette på er ved å ta for oss alle eventene i hver logg, og sammenlignet disse med de som ligger i databasen. Eventene som skulle testes er listet opp under: Tab used Detail Tab Change Content Change Right mouseclick on tab Right mouseclick on detail tab Clicked empty tab Clicked empty detail Clicked selected tab Clicked selected detail For å illustrere hvordan vi gjennomførte disse testene skal ta vi for oss testing av eventen ContentChange. Det første vi gjorde var å laste inn en logg i databasen. Deretter ble det kjørt en SQL-spørring for å finne ut av hvor menge forekomster det var av denne eventen i databasen. Bildet under viser hvordan spørringen og resultatet av spørringen:

5 Som bildet viser er det 1170 forekomster av eventen ContentChange. For å finne ut om denne forekomsten i databasen stemte med antallet i loggfilen, brukte vi Notepad plus plus. Denne testeditoren har et verktøy som kan telle forekomster av en input fra brukeren. Bildet under viser dette: Ved å trykke på knappen Tell, får vi opp antall forekomster av ContentChange i loggfilen. Bildet under viser resultatet: Som vi ser ut fra testen så er det 1170 forekomster av eventen ContentChange i databasen og i loggen. Denne testen ble gjort for alle eventene og resultatet stemmet i alle tilfellene. Det er også viktig å finne ut av om innholdet i grafen som blir tegnet stemmer med antallet i databasen. For å finne ut av dette videreførte vi det antallet vi fikk i testen over og tegnet grafen. Bildet under viser SQL-spørringen som ble utført mot databasen:

6 Som vi ser av spørringen er det 322 forekomster av eventen ContentChange i gruppe 02 LNG. Når vi tegner grafen ut i fra disse spesifikasjonene, ser vi at grafen tegner den samme verdien som vi hentet ut fra databasen. Bildet under viser resultatet: Testing av bilder For å finne ut om parseren henter ut alle bildene som ligger i loggfilen, brukte vi samme metode som når vi testet eventene. Vi sammenligner også her antallet i loggen med det som er i databasen. For å vise hvordan vi gjennomførte denne testen skal vi ta for oss hvordan vi gikk frem for å finne verdiene til bildet PSA MED TAILGASS. I likhet med tidligere tester brukte vi også her Notepad pluss pluss for å finne ut av antallet i loggfilen. Resultatet vi fikk vises i bildet under:

7 Denne testen viser at det finnes 36 forekomster av bildet. Deretter utførte vi en SQL-spørring mot databasen for å se om alle disse bildene var blitt hentet ut. Bildet under viser spørringen og resultatet: Som vi ser av bildet er det 36 forekomster av bildet i databasen, som betyr at parseren også her gjennomfører sin oppgave med å hente ut riktig antall. For å forsikre oss om at histogrammet også viste riktig i forhold til denne testen, ble også her grafen tegnet. Bildet under viser resultatet av denne testen:

8 Som vi ser av grafen viser den også 36 forekomster av bilder PSA MED TAILGASS. Denne testen ble gjort med samtlige bilder og resultatet stemte i alle tilfellene. 3.3 Akseptansetester For å finne ut om systemet fungerer i sin helhet valgte vi å gjennomføre en akseptansetest. Med denne testingen finner vi ut av om applikasjonen inneholder den funksjonaliteten og brukeropplevelsen som ABB ønsket. Siden vi har gjennomført dette prosjektet med Scrum som utviklingsmodell, er det skrevet user stories, som forklarer den funksjonaliteten som er ønsket av applikasjonen (se Vedlegg 1). Disse storiene gjenspeiler også det som er av krav for den ferdige applikasjonen. På denne måten kan vi finne ut om det vi har implementert var det som var ønsket fra ABB. Testene er bygd opp på følgende måte: User story forteller hva som skal gjennomføres. Utføring hva brukeren foretar seg. Godkjenning om testen er godkjent, med en forklaring på hva som skjer i testen.

9 User story 1: Ny logg Bruker klikker på combobox, velger New log. Implementert og fungerer som den skal. Bruker kan hente en logg som er lagret på systemet. Parserne parser filen og leggen blir lagt i databasen. User story 2: Legge til logg Bruker klikker på combobox, velger Add logg. Implementert og fungere som det skal. Bruker velger den loggen som ønskes å legge til i databasen. Parseren parser filen og legger disse til i databasen. User story 3: Velge grupper og bilder Brukeren velger gruppe, bruker velger bilde. Implementert og fungerer som den skal. Bruker kan velge hvilke grupper og bilder som ønskes å visualisere. Denne er implementert i form av en treeview med checkboxer. User story 4: Liste med logger Bruker klikker på combobox, velger ny logg. Implementer og fungerer som den skal. Bruker velger en logg som skal legges inn i databasen. Denne loggen blir lagt til i en liste som er synlig for brukeren. User story 5: Liste over logger slettes Bruker klikker på combobox, velger ny logg. Implementert og fungerer som den skal. Brukeren velger å hente en ny logg som skal legges inn i databasen. Listen over logger som allerede er lastet inn blir slettet, og den nye loggen blir lagt til i en tom liste.

10 User story 6: Velge event Bruker klikker på ønsket event Implementer og fungerer som den skal. Brukeren kan velge mellom 9 forskjellige eventer. Dette gjelder for ett av eventene eller flere av dem. User story 7: Velge dato Bruker klikker på Dato-time-picker -> velger data fra, bruker klikker på Dato-time-picker -> velger dato til. Implementer og fungerer som den skal. Brukeren kan velge hvilke intervall som ønskes visualisert. User story 7: Tegne graf knapp Brukeren klikker på Draw graph -knapp. Implementert og fungerer som den skal. Etter at brukeren har gjennomført de valgene som er ønsket for visualiseringen, starter applikasjonen tegning av grafen. User story 8: Graf i prosent Bruker klikker på Precentage view, klikker så på Draw graph -knappen. Implementert og fungerer som den skal. Brukeren kan velg om verdiene skal vises i prosent eller antall. 3.4 Resultater Etter å ha testen applikasjonen har vi funnet ut av alt virker som det skal. Alle testene som er gjennomført er godkjente.