Testdokumentasjon 1
Forord Denne rapporten omhandler testingen av systemet. Rapporten er først og fremst beregnet på sensor og intern veileder ved Høgskolen i Oslo, men kan gjerne leses av andre som måtte finne det interessant. Ønsker du ytterligere informasjon om prosessen, teknisk informasjon om produktet, eller bruk av produktet henviser vi til henholdsvis prosess-, test- og brukerdokumentasjonen som er selvstendige dokumenter. 2
Innholdsfortegnelse 1 Innledning... 5 2 Enhetstester... 5 3 Utfyllende testing... 8 3.1 Case 1: Innlogging... 8... 8... 8 Kommentarer... 8 3.2 Case 2: Utlogging... 8... 8... 8 3.3 Case 3: Opprette en bruker... 8... 8... 8 3.4 Case 4: Endre en bruker... 8... 8... 8 3.5 Case 5: Avbryte endringer... 9... 9... 9 3.6 Case 6: Slette en bruker... 9... 9... 9 Kommentarer... 9 3.7 Case 7: Opprette en stasjon... 9... 9... 9 3.8 Case 8: Legge til et nytt rom... 9... 9... 9 3.9 Case 9: Fjerne et rom... 9... 9... 10 3.10 Case 10: Administrere en stasjon... 10 3
... 10... 10 3.11 Case 11: Relasjon mellom rom og stasjon... 10... 10... 10 3.12 Case 12: Administrere rom... 10... 10... 10 3.13 Case 13: Gå til Stasjonsframvisning... 10... 10 3.14 Case 14: Tilkoblingsfeil... 10... 10... 10 Kommentarer... 11 3.15 Case 15: Stasjonsframvisning... 11... 11... 11 4 Konklusjon... 11 4
1 Innledning Testdokumentet er skrevet for å gi en beskrivelse for de ulike testene som er utført mot applikasjonen. Dokumentet vil også fungere som en kvalitetssikring for de ulike kravene som er satt for systemet det sjekkes her om kravene som er satt tilfredsstilles. Applikasjonen RomSys er bygget som en testbasert løsning. Det er utført enhetstester mot systemet. I neste kapittel i dokumentet vil vi se på oppbygningen av disse enhetstestene. Deretter vil vi beskrive tester vi har utført mot systemet for å fange opp situasjoner og uregelmessigheter som kan oppstå, men som ikke dekkes av enhetstester. 2 Enhetstester Enhetstesting er en vanlig måte for å teste at kodeblokkene i systemet gjør det de er tiltenkt at de skal gjøre. I etterkant av utviklingsprosessen forteller disse testene at alle deler av systemet gjør det som er forventet. Testene fungerer i grunn som en kjørbar dokumentasjon. Testfilene er skrevet i Visual Studio og ligger under Test -prosjektet. Figur 1: Liste av testklassene i prosjektet "Test". Figur 2 viser et eksempel på en enhetstest fra en av testklassene i prosjektet Test. 5
Figur 2: Eksempel på et enhetstest. Enhetstestene er avhengig av Stubklasser som befinner seg i DAL-prosjektet (Se figur 3). Figur 3: Stubklasse fra DAL-prosjektet. Den generelle gangen i enhetstesting er som følger: Det opprettes en Stubklasse som inneholder informasjon om slags verdier man forventer å hente ut når en bestemt test kjøres. En slik Stubklasse skal etterligne databasen som programmet normalt ville benyttet seg av. Enhetstestingen går da ut på at man sender inn en forespørsel, og en testmetode behandler forespørselen og sender tilbake data avhengig av hva forespørselen gjaldt. Deretter blir de returnerte data sammenlignet med den 6
verdien som Stubklassen har lagret som forventet verdi for nettopp denne enhetstesten. Hvis disse to dataene er identiske, betyr det at enhetstesten har passert uten feil. Hvis derimot dataene er forskjellige, genererer enhetstesten en feil. Hvis alle enhetstestene passerer uten feil, betyr det i utgangspunktet at programmet fungerer etter hensikten. Figur 4 viser at vårt program har kjørt alle enhetstester uten noen feil. Figur 4: et av enhestestene i RomSys. 7
3 Utfyllende testing Selv om enhetstesting er et kraftig verktøy for testing av deler i applikasjonen, vil den ikke av seg selv fastslå at systemet fungerer som helhet eller at funksjonaliteten og brukeropplevelsen er som ønsket. For å dokumentere også dette, har vi gjennomført manuelle tester der vi gjennom systemets brukergrensesnitt har testet ut systemets funksjonalitet. Testene er utført med tanke på å fange opp situasjoner og uregelmessigheter som kan oppstå under vanlig bruk av systemet. Noen av disse testene er også relatert til Use-case modellene vi har tegnet for systemet. 3.1 Case 1: Innlogging Skriv inn URL, skriv inn brukernavn og passord logg inn/enter. - Det logges inn, brukeren får se sitt innloggingsnavn på hjørnet i den nye sikrede siden som vises. Kommentarer Hvis du har valgt å logge inn med en bruker som kun har standardrettigheter vil du kun få innloggingstilgang på typen Standard, mens brukeren med administrator rettigheter kan du logge inn på begge typene (Admin og Standard). 3.2 Case 2: Utlogging Logg inn med brukernavn og passord logg deretter ut. - Blir ført tilbake til innloggingssiden. 3.3 Case 3: Opprette en bruker Velg type Admin, logg inn med administratorbruker Velg NY BRUKER Skriv inn nødvendig informasjon velg brukerrettighet Admin eller Standard Trykk på Registrer 3.4 Case 4: Endre en bruker Velg type Admin, logg inn med administratorbruker Velg en bruker Endre opplysninger eller passord på brukeren Trykk på Registrer 8
3.5 Case 5: Avbryte endringer Velg type Admin, logg inn med administratorbruker Velg en bruker Endre opplysninger eller passord på brukeren Trykk på Avbryte for å avbryte endringer 3.6 Case 6: Slette en bruker Velg type Admin, logg inn med administratorbruker Velg en bruker Trykk på slett Kommentarer For at systemet alltid skal ha minst én admin-bruker har vi satt en sperre på at man ikke kan slette seg selv som bruker. Denne funksjonen er også testet og fungerer som det skal. 3.7 Case 7: Opprette en stasjon Velger type Standard, logger inn med enten standardbruker eller administratorbruker Skriver inn nødvendig informasjon Velger visningslengde Velg sett inn rom nå JA eller Nei Trykk til slutt på Registrer 3.8 Case 8: Legge til et nytt rom Har du valgt Ja til å sette inn rom nå, blir du ført til en ny side for å gjøre dette. Vi går ut fra at du har gjort dette. I motsatt tilfelle, kan nytt rom kan også settes inn ved en senere anledning, og også et slikt tilfelle har blitt testet med vellykket resultat. Velg et eksisterende rom eller skriv inn et nytt Skriv inn riktig romkode Velg romtype Trykk på Legg til rom. 3.9 Case 9: Fjerne et rom Velg et eksisterende rom Trykk på Fjern rom 9
3.10 Case 10: Administrere en stasjon Trykk på Stasjonsadministrasjon i menyboksen Endre opplysninger, slette en stasjon eller endre visningslengde Trykk på Lagre endringer 3.11 Case 11: Relasjon mellom rom og stasjon Velg Rom og Stasjon på menyboksen Velg stasjon Om ønskelig kan vi også sette inn et nytt rom, trykk da på Nytt Rom Gjør som i Case 8. 3.12 Case 12: Administrere rom Velg Romadministrasjon i menyboksen Velg et rom på listen Trykk på Fjern rom for å fjerne fra listen om ønskelig Sett inn et nytt rom med romkode om ønskelig. 3.13 Case 13: Gå til Stasjonsframvisning Trykk på Stasjonsframvisning fra en av administrasjonssidene, eller fra innloggingssiden Siden for stasjonsframvisning startes. 3.14 Case 14: Tilkoblingsfeil Slå av nettilgangen på maskinen Trykk på Stasjonsframvisning på innloggingssiden Velg stasjon Trykk på Velg. En feilmelding dukker opp: Kunne ikke koble til, prøver igjen om 30 sekunder.... 10
Kommentarer Nettilgang er nødvendig for lasting av oppdaterte data i applikasjonen. Det hentes oppdatert informasjon fra en tredjepart to ganger hver dag. Når dette skjer, vil systemet forandre visning og det vil dukke opp en liten boks som viser framgangen. Hvis det er problemer med tredjeparten eller nettilgangen vil det dukke opp en feilmelding, og programmet vil etter 30 sekunder forsøke på nytt. 3.15 Case 15: Stasjonsframvisning Trykk på Stasjonsframvisning på innloggingssiden Velg stasjon Trykk på Velg Framvisning er i gang. Vi ser at informasjonene er riktig plassert og sideoppdatering virker som det skal. 4 Konklusjon Både enhetstestene og de utfyllende testene har vist at systemet stemmer i henhold til forventningene. Alle enhetstestene har passert med positivt resultat, og det har ikke dukket opp uventede situasjoner under de utfyllende testene. Enhetstestene i kombinasjon med utfyllende tester vil sannsynligvis medføre at oppstart og bruk av systemet vil by på minimale problemer for oppdragsgiveren. 11