Testplan (Software Test Plan)

Transkript

1 Testplan (Software Test Plan) Amanuel K. Tedla Eleonora Ntreska Ingrid Vik Hansen Joakim Moen

2 Innholdsfortegnelse Innholdsfortegnelse 1.. Introduksjon Definisjoner Antagelser ved testing av produktet Testprosessen Testkategorier Black-box testing White-box testing Testnivåer Enhetstest Regresjonstest Integrasjonstest Systemtest Godkjenningstest Testmetoder GUI-test Funksjonell test Ikke-funksjonell test Ressurser Risiko Prioriteringsliste Testplan Referanser BetaKey Payment System 2

3 1 Introduksjon Introduksjon Dette dokumentet omhandler testingen som skal utføres på produktet BetaKey. Dette for å finne ut om det tilfredsstiller kravene til kunden og utviklerne, og løse eventuelle feil. Å utføre grundige tester beviser ikke at systemet er feilfritt, men det reduserer sjansen for å finne feil etter at produktet er tatt i bruk. Ressurser, risiko ved testing og en testplan blir fremstilt i dette dokumentet. Alle utførte tester dokumenters i testdokumentasjonen. STP samt testdokumentasjonen skal publiseres på hjemmesiden. 1.1 Definisjoner Under følger en tabell over begrep og beskrivelse av disse. Tabell 1.1: Definisjoner Begrep GUI RC RFID RTM Software SQL STP VSTS VSUTF VTE Beskrivelse Graphical User Interface Release Candidate Radio Frequency Identification Release to manufacturing Systemprogramvare Structured Query Language Software Test Plan Visual Studio Team Server Visual Studio Unit Test Framework Virtuelt Test Environment 1.2 Antagelser ved testing av produktet Ved testing av dette produktet vil det oppdages/oppstå feil som skal rapporteres i VSTS. Ved rapportering i VSTS skal det registreres navnet til utvikleren som har jobbet med delen det har oppstått feil på, og en kommentar som beskriver så godt som mulig hva som er feil og en eventuell løsning. BetaKey Payment System 3

4 2 Testprosessen Testprosessen Dette kapittelet beskriver kort de to hoved testkategoriene samt testnivåene og testmetodene som blir tatt i bruk i testprosessen. Alle feil som blir oppdaget skal bli registrert i VSTS. Hvis en test avdekker feil, må en rette feilen og deretter ta testen på nytt. 2.1 Testkategorier Utviklingsteamet velger å teste funksjonalitet, kodestruktur og implementering ved hjelp av to testkategorier. Både Black-box testing og White-box testing blir forklart under Black-box testing Black box testing er en testmetode som fokuserer på funksjonaliteten til systemet, uten å se på kodestrukturen og implementeringen. Testingen er basert kun på programvarekravene. [1] Fordelen med denne testmetoden er at det er lett å fokusere på og teste funksjonaliteten, og det er lett å sammenligne med kravspesifikasjonen. En ulempe med Black-box testing er at den ikke finner feil i koden White-box testing White box er en testmetode som tester kodestrukturen og implementeringen. Den fokuserer primært på å styrke sikkerheten, innganger og utganger i programmet, design og brukervennlighet. [2] Fordeler med denne testmetoden er at den tester «alle» veier og implementasjonen. Ulemper er at det er lett å fokusere for mye på implementasjonen og glemme funksjonaliteten. 2.2 Testnivåer Det er flere testnivåer, dette gjør at systemet blir testet grundig både hver del for seg og sammen som et system Enhetstest Enhetstestene er skrevet av utviklerne som en del av programmering. Det opprettes et klassebibliotek som heter enhetstesting, i dette biblioteket vil det bli laget klasser hvor enhetstestene blir implementert. Hver del (klasser og metoder) blir testet separat. Ved testingen av dette systemet skal ikke alle klasser og metoder testes som en enhetstest, det skal velges ut noen få metoder. Enhetstestene skal bli utført i Visual Studio Unit Test Framework. Ingen installasjon er nødvendig for å bruke VSUTF Regresjonstest Regresjonstesting er testing av systemet for å se om endringer har ødelagt tidligere skrevet kode. Dette kan gjøres ved å utføre funksjonell testing på nytt etter at dette er utført en gang. BetaKey Payment System 4

5 Testprosessen Integrasjonstest Integrasjonstesting betyr at systemet er satt sammen og testet for å være sikker på at alt fungerer sammen. Sjekker at komponentene er kompatible, at komponentene samhandler korrekt og at de sender riktig data til riktig tid Systemtest Systemtesting er typisk Black-box tester som validerer hele systemet mot kravene. Sjekker om systemet møter kravene i SRD Godkjenningstest Kunden må teste og godkjenne produktet før produktet blir tatt i bruk. 2.3 Testmetoder Følgende testmetoder vil bli brukt under testing av programmet, samt testene under GUI-test GUI-testing er prosessen å teste det grafiske brukergrensesnittet av systemet. [3] Eksempler på hva som kan analyseres: Plassering og størrelse på knapper, bilder, tekstbokser osv. Skriftstørrelse Farger og bakgrunner Plassering på feilmeldinger Funksjonell test Funksjonell testing bekrefter at hver funksjon i programmet opererer i samsvar med kravspesifikasjonen. Innebærer hovedsakelig black-box testing. Sammenligner faktiske resultater med forventede resultater. [4] Ikke-funksjonell test Ikke-funksjonell testing er vanskeligere å gjennomføre enn funksjonell testing. Ikkefunksjonelle tester undersøker hvor godt produktet er Stresstest Stresstesting anvendes for å teste stabiliteten og påliteligheten til systemet. Denne testen avgjør systemets robusthet og feilhåndtering under press. [5] Sikkerhetstest Sikkerhetstesting handler om å finne alle smutthull og svakheter i systemet som kan føre til at informasjonen som ligger lagret i systemet havner i feil hender. Målet med sikkerhetstesting er å identifisere trusler i systemet og måle dens sårbarhet. Testingen hjelper også med å oppdage alle mulige sikkerhetstrusler i systemet, slik at utviklerne kan løse dette problemet gjennom koding. [6] BetaKey Payment System 5

6 Testprosessen Test av brukervennlighet Test av brukervennligheten fokuserer på å hvor enkelt det er å bruke programmet, fleksibilitet og om systemet møter sine mål. Test om systemet er lett å lære seg og bruke, og om en brukermanual er lett tilgjengelig ved behov Installasjonstest Installasjonstest går ut på å prøve å laste ned programmet på en datamaskin som ikke har systemet fra før av. Samt at installasjonsveiledningen er lett å forstå, og at den stemmer med hvordan installasjonen faktisk foregår. BetaKey Payment System 6

7 3 Ressurser For å utføre testingen er det nødvendig med følgende utstyr: Datamaskin med nødvendig software Internett Strekkode-skriver Strekkode-leser RFID-leser RFID-kort Ressurser Testene skal utføres i VTE. VTE er et testmiljø som skal lastes ned og fungerer som en egen datamaskin, uavhengig av det som allerede ligger på datamaskinen fra før av. VMware Workstation Player blir brukt fordi det er gratis og lett å bruke. Etter at VMware er lastet ned og installert skal Windows 10, VMware tools og SQL Server lastes ned og installeres i testmiljøet. Deretter skal software til BetaKey kopieres og gjøres klart til testing. Personene som skal utføre testene er oppgitt i Tabell 3.1: Testpersoner. Tabell 3.1: Testpersoner Tester Ansvar Testerfaring Amanuel K. Tedla Utvikler og tester Medium Eleonora Ntreska Utvikler og tester Medium Ingrid Vik Hansen Utvikler og testleder Medium Joakim Moen Utvikler og tester Medium Testlederen sitt hovedansvar er å følge med på at testerne utfører testingen i henhold til STP. Testlederen bestemmer også hvem som skal utføre hvilken tester. Godkjenningstestingen skal utføres av kunden Halvorsen & Co, personene er oppgitt i Tabell 3.2: Godkjenningstestpersoner. Tabell 3.2: Godkjenningstestpersoner Tester Hans Petter Halvorsen Olav Dæhli Bedrift Halvorsen & Co Halvorsen & Co BetaKey Payment System 7

8 4 Risiko Ved testing av et produkt er det viktig å se for seg mulige risikoer som kan oppstå, innvirkning på testingen og hvordan dette skal håndteres. Hvordan risikoer håndteres er viktig å vite for å være forberedt på alle senarioer. Risiko Utsatt start: Defekter/Feil er funnet rett før testingen skal startes. Dette kan eventuelt ta tid å rette opp, og testingen vil derfor bli utsatt. Det er viktigere å fikse problemet enn å teste produktet, og problemet kan også hindre at testingen kan bli utført. Stram timeplan: Timeplanen er stram, noe som gjør at det er stor risiko for at en ikke klarer å holde tidsfristene. For eksempel at en ikke er ferdig med en test når en allerede skal ha startet på neste. Utsettinger i testingen: Det kan fort forekomme nye problemer i testprosessen, da må dette fikses før testingen kan fortsette. Dette fører til utsettinger i timeplanen. Ikke nok ressurser: Eksempler på ikke nok ressurser kan være at sykdom hos testerne, ferie i testperioden og ikke nok teknisk kunnskap hos testerne. Uforutsigbare hendelser: Uventede naturlige problemer kan være strømbrudd, dataproblemer eller problemer med internett. I Tabell 4.1: Risiko er de forskjellige risikoene satt opp, sammen med sannsynligheten for at de inntreffer, innvirkningen de har på testingen og en skadebegrensning. Sannsynligheten og innvirkningen er rangert med lav, medium og høy. I skadebegrensningen er det forklart hva som kan gjøres for at risikoen ikke har for stort negativt utfall på testingen. BetaKey Payment System 8

9 Risiko Tabell 4.1: Risiko Risiko Sannsynlighet Innvirkning Skadebegrensning Utsatt start Medium Høy Hvis dette er tilfelle må teamet prøve å «ta igjen» timeplanen, og prøve å holde denne. Stram timeplan Høy Medium Timeplanen bør holdes, hvis en bruker lengre tid på en test enn planlagt, må en prøve å gjøre neste test på kortere tid. Hvis det er umulig å bli ferdig med alle testene før tidsfristen, er det laget en prioriteringsliste, der de nederste testene må bli nedprioritert. Utsettinger i testingen Høy Medium Timeplanen vil bli påvirket her. Problemet må løses før testingen kan fortsette. Ikke nok ressurser Medium Medium Ferier skal være med i timeplanen, og det skal ikke være satt opp tester innenfor denne tidsperioden. Ved sykdom hos en av testerne må en annen tester gjøre testene for han/hun. Ved manglende teknisk kunnskap, kan testerne samarbeide og dermed styrke kunnskapen. Uforutsigbare hendelser Lav Medium Ved strøm- eller internettbrudd må testerne vente til dette fungerer igjen. Ved dataproblemer kan en samarbeide med en annen tester på dens fungerende datamaskin. BetaKey Payment System 9

10 Risiko 4.1 Prioriteringsliste Dersom det er umulig å få gjort alle testene er det laget en prioriteringsliste slik at testerne kan følge denne, og de nederste testene må bli nedprioritert ved utløpt tidsfrist. 1. Enhetstester 2. Funksjonell testing 3. Ikke-funksjonell testing a) Brukervennlighet b) Sikkerhetstest c) Stresstest d) Installasjonstest 4. Systemtest 5. Regresjonstest 6. GUI-testing a) Logg inn b) Administratorside c) Kassasystem d) Ansatt e) Produkt f) Leverandør g) Rapport h) Web-søk BetaKey Payment System 10

11 5 Testplan Testplan I dette kapittelet blir det presentert en timeplan for testingen av produktet BetaKey, se Tabell 5.1: Testplan. Hele prosjektet er delt opp i fire iterasjoner, Alpha, Beta, RC og RTM. All testing foregår i iterasjon RC. Tabell 5.1: Testplan Testplan for BetaKey AS Uke Dag Hva skal gjøres? Hvem? 13 Tirsdag, 28.3 Lage software test plan (STP) Ingrid Vik Hansen, med innspill fra resten av BetaKey AS Fredag, 31.3 Lage virtuell test miljø (VTE) Testerne Tirsdag, 04.4 Teste software, utføre testtilfeller Testerne Fredag, 07.4 Lage enhetstester i VS Testerne 15 Påskeferie Alle Tirsdag, 18.4 Enhetstester Testerne Fredag, 21.4 Enhetstester Testerne 18 og 19 Torsdag, 4.5 og Mandag, 8.5 Regresjonstest Joakim Moen og Amanuel Tedla 20 Mandag, 15.5 Godkjenningstest Halvorsen & Co BetaKey Payment System 11

12 Referanser 6 Referanser [1] [2] [3] [4] [5] [6] BetaKey Payment System 12