TDT4735 Systemutvikling, fordypning

——————————————————————

Metoder for systemtest av websystemer

——————————————————————

Hong Trang Thi Nguyen

Veileder: Tor Stalhane

Høst 20-12-2005

Norges teknisk-naturvitenskapelige universitet

Forord

Dette prosjektet er skrevet i forbindelse med fordypningsfaget ’TDT4735 Systemutvikling’ paNTNU i 5. arskurs ved Institutt for Datateknikk og Informasjonsvitenskap, IDI.

Oppgaven handler om metoder for systemtesting med fokus pa websystemer. Jeg vil gjernesende en stor takk til IT-sjefen for Proxycom, Trond Johansen, for a ha delt sine praktiskeerfaringer og gitt meg gode rad nar det gjelder systemtesting. Jeg setter ogsa stor pris paProxycom og Sparebank 1 som har tatt seg tid til intervjuer, slik at jeg fikk mange godeopplysninger om deres arbeid innenfor dette emnet.

Til slutt vil jeg gjerne takke min veileder, Tor Stalhane, for den gode oppfølgingen og hjelpengjennom dette semesteret.

Trondheim 20/12-2005

- - - - - - - - - - - - - - - - - - -

Hong Trang Thi Nguyen

II

Innhold

1 Innledning 21.1 Oppgavebeskrivelse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Mal med prosjektet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Testing 32.1 Definisjon av testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Testklassifisering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 Black Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.2 White Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 Testfaser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.1 Modul/Enhetstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.2 Integrasjonstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.3 Systemtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.4 Regresjonstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.5 Usability test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.6 Akseptansetest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Plassering av systemtesting i prosjektutviklingen 93.1 Forstudium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Kravspesifikasjon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.4 Programmering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.5 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.6 Vedlikehold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Praktiske erfaringer med systemtest 124.1 Feilfinning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2 Testplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.3 Testteam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.4 Testrapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.5 Risikoanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.6 Konfigurasjonshandtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5 Websystem 155.1 Definisjon av websystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.2 Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.3 Krav til websystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6 Intervju med IT-bedrifter 186.1 Proxycom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.1.1 Bedriftsintervju med Proxycom . . . . . . . . . . . . . . . . . . . . . . . 206.2 Sparebank 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6.2.1 Bedriftsintervju med Sparebank 1 . . . . . . . . . . . . . . . . . . . . . 216.3 Krav til metoder for systemtesting av websystemer . . . . . . . . . . . . . . . . 22

7 Metodeundersøkelse 23

III

7.1 Metoder for systemtesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237.2 Resultat fra metodeundersøkelsen . . . . . . . . . . . . . . . . . . . . . . . . . . 25

8 Oversikt over aktiviteter ved systemtesting 268.1 Generell fremgangsmate for utførelsen av systemtesting . . . . . . . . . . . . . 278.2 Design for testcase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

8.2.1 Definisjon av testcase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328.2.2 Fremgangsmate for a lage testcase . . . . . . . . . . . . . . . . . . . . . 33

8.3 Illustrering av a lage testcase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

9 Oppsummering 41

10 Validering av prosjektet 42

A Vedlegg - Spørsmal til bedriftsintervju 43

B Vedlegg - Bedriftsintervju med Proxycom 44

C Vedlegg - Bedriftsintervju med Sparebank 1 47

D Vedlegg - Ordforklaringer 50

Figurer

1 Testmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Testrekkefølge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 V-modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Websystem arkitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Use Case diagram for funksjonenene kunden har i systemet . . . . . . . . . . . 356 Use Case for ’Bestill produkt’ . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 Tabell over alle hendelser i riktig rekkefølge . . . . . . . . . . . . . . . . . . . . 368 Sekvensdiagram - Bestill produkt . . . . . . . . . . . . . . . . . . . . . . . . . 37

Tabeller

1 Tabell som viser ansvarsfordeling . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Tabell for risikoanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Kravmatrise for metodene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 A: Gradering av feil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 B: Gradering av feil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Tabell over alle testene med tilhørende krav . . . . . . . . . . . . . . . . . . . . 287 Malen for testtabell basert pa IEEE std 829 . . . . . . . . . . . . . . . . . . . . 298 Liste over feil ved første systemtest . . . . . . . . . . . . . . . . . . . . . . . . . 309 Liste for testresultatene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3110 Use Case - Bestill produkt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3911 Testcase - Bestill produkt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

1

1 Innledning

1.1 Oppgavebeskrivelse

Testing er viktig for a kontrollere validering og verifikasjonsprosessen. Validering er a finne utom vi har laget det rette produktet, mens verifikasjon ser pa om man har laget produktet pariktig mate. Validering og verifikasjon brukes pa alle trinn i systemutviklingen for a sikre atsystemet følger spesifikasjonen og at man lager det som brukeren ønsker [35].

Testing er et stort emnet i systemutvikling, derfor har jeg begrenset oppgaven til metoder forsystemtesting av websystemer. Dette syns jeg er et interressant emnet, for det er viktig a utføresa god systemtesting av websystemer som mulig, ellers kan det fa katastrofale konsekvenserfor bedrifter. I kapittel 2 vil jeg beskrive hva testing er og hvilke typer tester som man børutføre for websystemer. Kapittel 3 handler om ulike faser i prosjektutviklingen med tilhørendedokumenter. Det er viktig a vite de praktiske erfaringer med systemtesting som er beskreveti kapittel 4.

Oppgaven gar ut pa a finne en systematisk metode eller retningslinjer for systemtesting ogutforming av testcase manuelt, derfor har jeg foretatt metodeundersøkelser i kapittel 7 ved aintervjue to IT-bedrifter. Hvilke krav disse bedriftene har til systemtesting av websystemerer beskrevet i kapittel 6, og nærmere beskrivelser av strukturen til websystemer i kapittel 5.Hvilke aktiviteter som finnes ved systemtesting, og hvordan man utformer gode og testbaretestcase er beskrevet i kapittel 8. Oppsummering og validering av prosjektet finnes i kapittel 9og 10.

1.2 Mal med prosjektet

Darlig systemtesting av websystemer kan føre til store økonomiske konsekvenser, derfor er detbehov for bedrifter a fa mer informasjon om flere metoder for systemtesting av websystemerslik at man kan tilpasse en metode til sitt eget prosjekt. Det er mange bedrifter som ikkebenytter noen bestemte metoder eller verktøy for systemtesting. Fremgangsmaten som mangebenytter idag er manuell systemtesting basert pa egne erfaringer. A utføre systemtesting avwebsystemer systematisk er en god fremgangsmate for a sikre at alle de viktige aktiviteterblir utført. Det er ogsa viktig a ha en god fremgangsmate til a lage testcase i systemutvikling.

Malet med dette prosjektet er derfor a finne informasjoner om metoder for systemtestav websystemer, og samtidig beskrive en systematisk fremgangsmate i systemtesting avwebsystemer og utforming av testcase slik at bedrifter kan høy sannsynlig utvikle etkvalitetsprodukt. Alle bedrifter vil at deres produkter og tjenester skal vise kvalitet oge!ektivitet, og det er essensielt at testing ma være godt utført. Ved a ha en formaliserttestprosess kan man oppdage feil som oppstar pa et tidlig tidspunkt, og da har man mulighettil a rette dem opp før man lanserer produktet. Dette vil føre til mange fordeler for en bedriftsom besparelse av tid, ressurser og kostnader. Jo senere en feil oppdages, desto mer alvorligog større konsekvenser far den.

2

2 Testing

Testing har lenge vært undervurdert i systemutvikling, og mange prosjekter mislykkes pagrunn av dette. Testing er viktig i alle utviklingsarbeid, fordi testing vil kunne validere omkravene til et system er tilfredsstilt som forventet. Testing er nødvendig, sa det er viktig avite hva testing egentlig er.

2.1 Definisjon av testing

Testing brukes for a kontrollere utførelse, palitelighet og brukergrensesnitt og for a sjekke omkravene var riktig i forhold til hva brukeren ønsker [34]. Malet for testing er a sjekke hvorgodt et system oppfyller kundenes krav, og resultatet av kjøringer blir sammenlignet medfasit. Det er derfor lønnsomt a teste tidlig og jevnlig under hele utviklingen.

Nar man snakker om testing vil man ofte forbinde det med kvalitetssikring. Hensikten medtesting er a finne feil, og en vellykket test er en test der man finner feil i programkoden,designet, kravspesifikasjonen eller dokumentasjonen for systemet [27]. Fordelen med testinger at man kan finne feil i tidlig fase av utviklingen, slik at man kan spare tid og arbeid. Testingkan ikke garantere at systemet er feilfri, men testing kan brukes til a vurdere om man vil ellerkan produksjonssette en release av et system. Det er større sannsynlig at testing blir vellykket,dersom den inneholder disse tre punktene [7]:

• Repeterbarhet : hvis man finner feil, repeterer man senere testen for a sjekke at feil erblitt fikset.

• Systematisk : random (tilfeldig) testing er ikke tilstrekkelig, derfor er det lurt agjennomføre testing systematisk for a dekke alle brukstilfellene i systemet.

• Dokumentert : bedre oversikt nar man har skrevet testdokumentet med resultater fratestene, slik at kunden kan ogsa se hvilke tester som er blitt utført for systemet.

Det er viktig a skille mellom debugging og testing. Debugging reparerer en pavist feil, ogtesting søker a pavise slike feil. Debugging er en prosess for lokalisering hvor i koden feilenligger, og deretter blir feilen rettet opp. Debugging skjer pa følgende mate [2]:

• Bruke minimal test som fremprovoserer feil.

• Lokaliser feil.

• Reparer feil.

• Teste igjen med minimal test.

3

Figur 1 viser en typisk testmodell i systemutvikling. Under testingen setter man opp et settav inndata og forventede utdata basert pa de gitte inndata, og kjører deretter testen for asjekke om de faktiske resultatene stemmer overens med de forventede resultatene.

Figur 1: Testmodell

Her er en nærmere beskrivelse av figuren:

• Testobjekt: systemet vi skal teste

• Testprogram: aktiviteter i testprosessen

1. Spesifisere tester2. Utføre tester3. Skrive testrapport

• Inndata: det som skal testes

• Utdata: forventede resultater eller output

4

Et system kan befinne seg i ulike tilstander avhengig av hvor i utviklingsprosessen det er. Delagrede data i databasen bestemmer systemets tilstand. Systemets output bestemmes ikkebare av input, men ogsa av systemets tilstand. Variablene i det kjørende programmet vilforandre seg under testingen, og systemets tilstand vil være avhengig av databasens innhold.Det er viktig a identifisere hver enkelt transaksjon med en transakjonsID som er generertautomatisk av databasesystemet. Systemloggen lagres regelmessig pa disk og brukes for agjenopprette tilstanden i databasen rett før feilsituasjonen oppstod [17].

2.2 Testklassifisering

Nedenfor har jeg tatt for meg to mater a gjennomføre test pa, Black box- og White boxtesting.

2.2.1 Black Box

Black box testing eller funksjonell testing er en testmetode der testen bygger pa programmeteller komponentspesifikasjon. Under black box testing velger man tester ved a se pa systemetseller komponentens grensesnitt og ikke pa hvordan komponenten er realisert [1].

Black box [11]:

• Sterke sider: Lett a bevare fokus pa og teste funksjonaliteten. Lett a automatisere testenut fra kravspesifikasjonen.

• Svake sider: Kan ikke hjelpe oss nar vi skal finne feil i koden.

2.2.2 White Box

White box er en metode der testene bygger pa kunnskap om programvarestrukturen ogimplementasjon. White box testing skjer nar man velger tester ut fra hvordan systemet ellerkomponenten er realisert. Hensikten er a teste ’alle’ veier gjennom systemet [1].

White box [11]:

• Sterke sider: Kan teste ’alle’ veier og ta hensyn til spesielle forhold ved implementasjo-nen.

• Svake sider: Lett a fortape seg i detaljer ved implementasjonen og glemme funksjonali-teten.

5

2.3 Testfaser

Testing er en aktivitet som vil forega under hele utviklingsprosjektets levetid. Det er viktiga gjennomføre testing pa flere nivaer for a avdekke feil og kvalitetssikre produktet. Typiskeformer for testing underveis er enhetstesting av kodemoduler, integrasjonstesting nar mansetter sammen flere moduler eller skal ha systemet til a fungere sammen med eksternesystemer, brukbarhetstesting for a avdekke problemer med brukergrensesnitt. Vi kan begynnea teste modulene etterhvert som de blir utviklet, for sa a teste om den fungerer i samspillmed resten av systemet som er utviklet. Dermed vil feil bli oppdaget pa et sa tidlig tidspunktsom mulig [29].

Teststrategien medfører følgende tester :

• Modul/Enhetstest

• Integrasjonstest

• Systemtest

• Regresjonstest

• Usability test

• Akseptansetest

Alle disse testfasene er ikke nødvendig for alle prosjekter, men i websystemer bør man ihvertfallbruke de fire testfasene enhetstest, integrasjonstest, systemtest og akseptansetest. Det ervanlig a gjennomføre disse testfasene i den rekkefølgen som er vist i figur 2, og gjerne i flereiterasjoner. En iterasjon er gjennomgang av hele rekken av arbeidsoppgaver. Man planlegger,spesifiserer, designer, implementerer, integrerer og tester litt av gangen for hver iterasjon.

Figur 2: Testrekkefølge

6

Alle disse testene utføres nar systemet lages første gang og ved enhver senere endring avsystemet. Enhetstest og integrasjonstest utføres med White box testing, fordi testene gjerneforutsetter innsikt i systemets indre oppbygning. Metoder og verktøy for disse to testfaseneer ofte ganske like, og det er ikke uvanlig at de flettes mer eller mindre sammen. Systemtestog akseptansetest utføres med Black box testing, fordi testene ikke skal forutsette innsikt isystemets indre oppbygning. Metoder og verktøy for disse to fasene er ofte ganske like, sai prosjekter med sterk brukermedvirkning er det derfor er det vanlig at de flettes mer ellermindre sammen [28].

2.3.1 Modul/Enhetstest

Enhetstest eller modultest er testing av en avgrenset del av et system separat. Enheten somtester en enkelt modul som f.eks. en klasse eller kildekodefil uten de andre enhetene som dennormalt kommuniserer med.

2.3.2 Integrasjonstest

Integrasjonstest er testing av grensesnittet mellom enheter eller moduler i et system. Dennetestingen utføres med White box testing og tar utgangspunkt i bade koden og designet.Integrasjonstesten skal ikke dekke all kode, og heller ikke all funksjonalitet. Den har fokuspa det som ikke er med i enhetstestene, det vil si fokusere pa at de enhetstestede modulenefungerer sammen som de skal [28].

Integrasjonstesten kan godt inneholde noe ad hoc testing i tillegg, og ad hoc testing betyri denne sammenheng a teste brukergrensesnittet pa tvers av enhetene som systemet erbygget opp av. Ad hoc testing bør tas med nar man har integrert seg opp til et niva medbrukergrensesnitt.

2.3.3 Systemtest

Systemtest bestar i a teste systemet som helhet, og grunnlaget for testingen er kravspesi-fikasjonen for systemet. Her tester man om systemet oppfører seg korrekt i samspill medomgivelsene, og denne testingen blir ofte utført av en egen testgruppe. Systemtest skal ikkebare teste funskjonelle kravene, men skal ogsa inkludere ikke-funksjonelle tester [28].

7

De typiske testene innen systemtest for websystemer er ytelsestest, sikkerhetstest, stresstest,recoverability-test og nettlesertest. For websystemer trenger man [11]:

• Funksjonell test for a sjekke om en modul tilfresstiller de eksterne kravene man har satttil den.

• Ytelsestest for a teste hastigheten for en transaksjon.

• Sikkerhetstest for a sikre systemet mot inntrengere.

• Stresstest for a teste hastigheten pa mange samtidige transaksjoner.

• Nettlesertest for a sørge at systemet støtter alle versjoner av nettleserne.

• Recoverability-test for a sjekke systemets handtering av uforutsette avbrudd.

2.3.4 Regresjonstest

Regresjonstest betyr gjentagelse av en eller flere testfaser for a verifisere at feilrettingereller endringer ikke har introdusert nye feil eller uønskede e!ekter [28]. Denne testingen skalsamtidig sjekke at systemet fremdeles tilfredsstiller de spesifiserte kravene. Man kjører bare enutvalgt del av de aktuelle testfasene for a spare tid. Regresjonstest er nødvendig i forbindelsemed feilretting under nyutvikling, eller nar man senere lager nye utgaver av systemet.

2.3.5 Usability test

Usability testing, eller brukbarhetstesten er testen for a finne ut hvor lett systemet er a forstaog bruke [31]. Ved a observere brukere under brukbarhetstesten vil man fa tilbakemeldingerpa hva som bør forbedres i eksisterende systemer. Man trenger brukbarhetstest for a testedesignet mot ’virkeligheten’, altsa av reelle brukere.

2.3.6 Akseptansetest

Akseptansetest blir ofte kalt for en alfa test, og hensikten med denne testen er a fa systemetgodkjent av kunden [35]. For at systemet skal besta akseptansetest ma systemet fungere ihenhold til brukernes krav. Akseptansetest er nesten samme som systemtest, men her blirtestingen utført av kunden.

8

3 Plassering av systemtesting i prosjektutviklingen

Det finnes mange forskjellige systemutviklingsmodeller idag. Fossefallsmodell og inkremen-tellutvikling er de mest brukte i prosjektutvikling. Systemutviklingsmodellene gir en oversiktover faser, aktiviteter og milepæler til et IT-prosjekt [20]. I fossefallsmodellen deles prosjekteneopp i forstudie, kravspesifisering, design, programmering og vedlikehold, mens inkrementellutvikling innebærer at et system utvikles trinnvis i flere iterasjoner [25]. Uansett hvilke modellman bruker i systemutvikling, sa bør den inneholde disse fasene:

1. Forstudium

2. Kravspesifikasjon

3. Design

4. Programmering

5. Testing

6. Vedlikehold

Nar man har analysert kundekravene grundig og konstruert en logisk modell for systemet,vil det være mer sannsynlig at prosjektet lykkes. Det er vanlig a bruke de fire testtypeneenhetstest, integrasjonstest, systemtest og akseptansetest i websystemer.

Her er en V-modell som skal vise sammenhengen mellom dokumenttyper og testfasene [28]:

Figur 3: V-modell

9

3.1 Forstudium

Forstudiet fokuserer pa a avklare omfanget av systemet, slik at man kan finne ut hvor storkostnad og tid det vil være for a utvikle et bestemt system. Man trenger denne fasen for aavgjøre om det er lønnsomt for organisasjonen a ga videre med prosjektet eller om den børstoppes. Noen av hovedaktivitene i denne fasen er [12]:

• A definere malsetning og omfang for systemet.

• A lage et overordnet systembeskrivelse.

• Organisering av prosjektgruppen.

• Estimering av kostnader og tid.

• Utarbeide risikoliste.

• A vurdere alternative løsninger.

• Planlegging av videre arbeid.

3.2 Kravspesifikasjon

I denne fasen er det viktig a forsta kundekravene, og for a sjekke om man har forstatt kundenriktig bør man tenke gjennom hva kunden ønsker seg, hvilke problemer som skal løses oghvordan man kan omforme kundekrav til systemkrav pa best mulig mate.

En annen viktig del av kravspesifikasjonen er sporing av kundekravene. Sporing fra kodetil krav og omvendt kan være viktig for a skjønne implementasjonen, og det vil lett oppstaproblemer dersom kravene ikke er entydig spesifisert. Det finnes mange krav, sa det er vanliga dele dem inn i to hovedgrupper:

• Funksjonelle krav :

Hva systemet skal gjøre.

• Ikke funksjonelle krav :

Hvordan systemet skal gjøre det, f.eks. responstid.

3.3 Design

Nar man har analysert kundekravene, kan man ga til designfasen. I denne fasen er detviktig at man lager modeller som for eksempel systemstruktur pa en forstaelig mate, slikat programmerer realiserer løsningen.

10

3.4 Programmering

I programmeringsfasen skal man utvikle programsystemet med fokus pa a tilfredsstillekundekravene. Programmerere skal realisere løsningen ut fra designdokumentet, og noenoppgaver som programmerer ma utføre er [18]:

• Utarbeide programmoduler

• Utføre refaktorering: refaktorering er en teknikk som gar ut pa minst mulig kostnad aendre pa programkoden.

• Skrive kode for metoder

3.5 Testing

Det er viktig a teste grundig for a sikre kvaliteten pa produktet. Testtypene som finnes erbeskrevet i kapittel 2.3, og det er i denne fasen systemtest blir utført. Det er nødvendig adokumentere testene slik at man far oversikt over hva man har testet og hvilke problemer somoppstar under testingen. Man kan velge mellom automatisert- eller manuell systemtesting, ogdet er fortsatt mange som benytter manuell testing siden dagens automatiserte verktøy ertidkrevende.

3.6 Vedlikehold

Det finnes flere typer vedlikehold : man retter feil, tilpasser til nye omgivelser, legger til nyfunksjonalitet eller endre eksisterende funksjonalitet [36].

11

4 Praktiske erfaringer med systemtest

4.1 Feilfinning

Nar man har funnet feil i en test, ma man lete etter feilkilden og rette den opp [32]. Det kanvære vanskelig a finne kilden til feilen, særlig nar det er flere som har bidratt i kodingen. Deter derfor vanlig a innskrenke omradet for hvor feilkilden ligger ved a legge inn utskriftermed meldinger om hvor langt kjøringen av programmet har kommet istedenfor a gjøremange omkompileringer [11]. Nar man observerer rekkefølgen av utskriftene etter at feilenhar oppstatt, vil man ha en viss anelse hvor feilen kommer fra. Dette er en systematisk matea gjøre dette pa, men endelig har man etterhvert feilfinningsverktøy som gjør det enklere forde som programmerer.

4.2 Testplan

Systemtestplan

Før man skal utføre systemtesting, lønner det seg a lage en systemtestplan. Uansett hvilkemetode man velger for systemtesting bør man lage testplan basert pa IEEE-standard [15] sominneholder:

——————————————————————————————————————–

• sammendrag

• innledning

• malsetting for systemtesting

• testverktøy: hvilke hardware/software som brukes under systemtesting

• klassifisering av feil

• gradering av feil

• rapportprosedyre: Testresultatene

• tidspunkt og personer til a utføre testing

• ansvarsfordeling for godkjenning av testingen: se eksempel i tabell 1

——————————————————————————————————————–

Hvorfor trenger vi en testplan?

Det er nyttig a ha en testplan for alle store prosjekter, siden dette letter koordinering medandre aktiviteter i prosjektet [11]. Nar man har en testplan vet man hvem som er ansvarlig forhvilke aktiviteter, hva som skal testes og hvordan man skal kjøre testene. Testplan er spesieltnødvendig a ha dersom kostnaden eller risikoen ved a feile er stor. Tabell 1 er et eksempel paansvarsfordelingen mellom prosjektmedlemmer.

12

Test Tid timer Ansvarlig

Systemtest 08.11.05 2 timer Hong Trang Thi NguyenBrukbarhetstest 10.11.05 2 timer Berit Eleni SirrisAkseptansetest 11.11.05 2 timer Olav Engelsastrø

Tabell 1: Tabell som viser ansvarsfordeling

4.3 Testteam

Testing blir en stadig viktigere del av det totale utviklingsprosjektet. Et av problemene medtestingen er at man ikke har fatt nok opplæring i testing. Det kan være vanskelig a sette seginn i brukerens situasjon eller at det har vært darlig testledelse i prosjektet.

Hvem burde teste hva ?

1. Testere og kundestøtte :

Tester det funksjonelle og grensesnittet.

2. Utviklere :

Testing av funksjoner og moduler.

4.4 Testrapport

Nar man har fullført en test, skal man skrive en rapport som oppsummerer resultatet avtestingen. Rapporten bør beskrive de feilene som er funnet, for sma prosjekt holder det medtestlogg [19].

4.5 Risikoanalyse

Risikoanalysen innebærer at man gar gjennom alle aktiviteter i prosjektet, og tenker pa hvasom kan ga galt, hvor sannsynlig er det og hvilke konsekvenser det vil fa [1]. Risikoanalyseer nødvendig for a prøve a forhindre slike situasjoner og eventuelt sette tiltak hvis tilfelletskjer [9].

For a oppna en god kvalitetssikring av systemet er det viktig a utføre risikoanalyse itesting, slik at bedrifter kan vurdere hvilke tiltak som ma iverksettes dersom en avvikoppstar. Risikoanalyse hjelper til a kontrollere hvorvidt endringene eller tiltak vil pavirkesystemet [21].Tabell 2 er et eksempel pa hvordan man kan sette opp en iverk risikoanalyse.

13

Nr Risiko Beskrivelse Sannsynlighet Alvorlighetsgrad

R1Gruppen mangler kunn-skap og erfaring

Begrenset innsikt iprosjektarbeid eller avverktøy kan forsinkeprosessen

Høy Middels

R2 Forfall i gruppen Sykdom Høy Lav

R3 Feil i estimering Undervurdering av tids-forbruk

Høy Høy

R3Forandringer i kravspe-sifikasjon fra kunde

Ma gjøre deler av pro-sjektet pa nytt. Lav Høy

Tabell 2: Tabell for risikoanalyse

4.6 Konfigurasjonshandtering

En konfigurasjon er en samling av alle komponentene til et system, og der hver komponenter representert med nøyaktig en versjon. Konfigurassjonsstyring skal handtere endringerog ulike versjoner av komponenter, og den er basert pa et sett av standarder [13]. Enkonfigurasjonsstyringsplan bør inneholde:

• Info om endringer og ulike versjoner.

• Definering av typer dokumenter og navngivningskonvensjon

• Beskrivelse av verktøyene som brukes for konfigurasjonsstyring, og deres begrensninger

• Ferdiglagde skjemaer for endringer

• Oppfølging og arkivering

• Definering av personansvar

14

5 Websystem

Websystemer representerer en stadig økende teknologi med mange internett brukere. Det somer utfordrende for slike applikasjoner er a benytte testing til a sikre palitelighet, sikkerhet,robusthet og høy ytelse. Hva er kjennetegnet til websystemer og hvilke omrader man bør testenar man utvikler websystemer vil bli beskrevet i kapittel 5. Hvordan vi skiller systemtestingav websystemer fra tradisjonelle programvarer blir diskutert i kapittel 5.1.

5.1 Definisjon av websystem

Websystem innebærer lagdelte applikasjoner som aksesseres via en webbrowser; standardHTTP-protokoll, og det er den store forskjellen fra tradisjonelle programvarer. Testingenav internettløsninger vil ha tilnærmet samme strategier og metoder som testing av grafiskebrukergrensesnitt.

Den første utfordringen for websystemer er testing av flere nettlesere, og det bør ogsa testespa ulike operativsystemer. Testingen gar ut pa a sette opp et sett av inndata og forventedeutdata basert pa de gitte inndata. Deretter blir testen kjørt, og man ser om de oppnadderesultatene stemmer overens med de forventede resultatene [27].

En annen utfordring er presset til a ha en time-to-market som er kort som mulig. Testene somblir gjennomført vil da ha fokus pa a oppdage feil som kan forarsake uakseptable oppførsel.Det er viktig a finne en god metode eller et verktøy til a male robusthet i websystemet, noesom jeg har utelatt pa grunn av begrensing av oppgaven.

Malet for alle prosjekter er a levere en feilfri vare, men i tillegg til det vil websystemer fokuserermye pa høy kvalitet, ytelse og stabilitet. Det er derfor nødvendig a benytte stabilitetstest ogstresstest for a finne hvor bra systemet takler nar en mengde brukere blir koplet til systemetsamtidig (skalerbarhet) [14].

5.2 Struktur

Websystemer innebærer klienter som for eksempel er kundens nettleser, og en eller flere fysiskeservere som bidrar til flere typer av service [14]. En server kan for eksempel være en webservereller databaseserver som inneholder alle data. En webservice er en samling av protokoller ogstandarder som brukes for a dele data mellom applikasjoner. En nettleser (browser) er etprogram som brukes til a vise innhold ifra internett, og all spørringer vil ga fra klienten tilserveren [1]. Figur 5 viser en typisk struktur for et websystem:

15

Figur 4: Websystem arkitektur

Et websystem skal være organisert som en bok med sider, og koblingen mellom sidene børvære logisk og lett og oppfatte [22]. Det er viktig a ha et forstaelig og godt brukergrensesnitt,slik at brukeren kan finne fram til den han/hun leter etter uten a matte ga via for mangesider med linker. Linker bør plasseres slik at brukeren lett finner dem, og for a fremheve demkan man skille linkene tydelig fra annen tekst med farge eller grafiske symboler.

5.3 Krav til websystem

Følgende faktorer er viktige nar vi utvikler et nettsted [37]:

1. Time-to-market: Hvor fort kan produktet leveres?

Tiden det tar fra a starte produktutviklingen til produktet er ferdigstilt og tilgjengeligpa markedet.

2. Robusthet: Taler systemet uventede problemer?

Et robust system ma bygges pa en solid fundament for ikke a feile.

16

3. Understøttelse: Støtter systemet eksisterende standarder og ulike versjoner av nettlesereog operativsystemer?

Det bør støtte eksisterende standarder og tilrettelegge for enkle oppgraderinger.

4. Brukervennlighet: Er det lett a forsta logikken i systemet?

For at systemet i det hele tatt skal fa noen brukere sa ma det være brukervennligog intuitivt. Hvor brukervennlig er navigasjonen pa nettstedet, og hvor klart og lettforstaelig er budskapet?

5. Testbarhet: Kunne alle kravene testes i det ferdige systemet?

Det bør ogsa være lett a teste systemet etter modifisering.

6. Yteevne: Oppfyller systemet kravene til responstid?

Her bør man definere krav for systemets ytelse i form av nedlastingstider for hver side.

7. Sikkerhet: Er systemet sarbar for inntrengere?

Systemet bør ha en beskyttelse mot hackere, og en mate man kan finne ut om systemetkan hackes pa er a prøve hacke det selv.

8. Flyttbarhet: Kan systemet kjører pa ulike ’plattformer’?

Systemet bør være flyttbarhet, det vil si at for eksempel klientene er web-browsere ogat database løsningen kan flyttes fritt fra web-server til web-server.

17

6 Intervju med IT-bedrifter

Oppgaven gar ut pa a finne gode metoder for systemtesting av websystemer og hvilke kravmetodene ma tilfredstille. For a vite mer om dagens bedrifter innen systemtesting, har jegintervjuet to bedrifter for a undersøke hvilke metoder disse bedriftene benytter idag. Etter atmetodeundersøkelsen er utført, skal jeg beskrive hvilke framgangsmate og teknikker som ere!ektiv for systemtesting av websystemer i kapittel 8.

Hensikten med intervjuene er a finne ut hvordan bedriftene jobber med systemtesting spesieltav websystemer, og hvilke krav de har til metode av systemtesting. Jeg har fulgt radenefor hvordan man bør lage og forberede et intervju fra Norsk Nettskole [16]. Det er viktig avære klar over hva du skal spørre om under intervjuet, derfor laget jeg en liste over alle despørsmalene som skal stilles. Begge bedriftene far samme spørsmal a svare pa, siden dettegjør det lettere a sammenligne svarene [9].

Først kontaktet jeg bedriftene for a avtale tidspunkt for intervjuet med IT-sjefen, sa sendtejeg en e-mail til intervjuobjektene om hva dette gar ut pa slik at de kan forberede seg ogeventuelt finne personalet som har kompetanse innenfor emnet. Det er viktig a finne generellinfo om bedriften og hvilket forhold intervjuobjektet har til systemtesting. Referat fra disseintervjuene ble sendt ut til intervjuobjektene for godkjennelse fra dem om at det som star derer riktig før jeg legger dem inn i prosjektrapporten min. I kapittel 6.1 og 6.2 er det en litenoppsummering fra disse to intervjuene, selve referatene har jeg lagt som vedlegg pa sluttenav denne rapporten.

18

6.1 Proxycom

Proxycom er et konsulentselskap som ble etablert i 1997. De har høy kompetanse blant annetinnenfor systemutvikling, kvalitetssikring og informasjonssikkerhet. Proxycom fokuserer paa dekke kundenes behov og ønsker a utvikle kvalifiserte løsninger som er kostnadse!ektiveog fremtidsdrevet. De er spesialister nar det gjelder a utvikle IT-systemer som krever høysikkerhet, palitelighet, tilgjengelighet, brukervennlighet og ytelse [20].

Proxycom benytter metoden TRIUMF (TRInnvis UtviklingsMetode For programsystemer)i systemutvikling, og TRIUMF er en framgangsmate for hvordan man bør gjennomføre allefaser i vedlikehold- og utviklingsprosjekter [12]. Proxycom har mange fagpersoner som harhøy kompetanse og erfaring innen flere fagomrader, derfor har selskapet ogsa en avdeling somtilbyr IT-radgivning. Proxycom bestar av tre avdelinger:

• Proxycom Consulting

• Proxycom Services

• Proxycom Research and Development

Proxycom setter ogsa fokus pa utnyttelse av ny teknologi, for det er fremtidsrettet og vil væreen fordel bade for selskapet og kunden. Proxycom kan tilby IT-løsninger for datatekniskeproblemer for bade store og sma bedrifter, f.eks:

• Webbasert lagringsstyring

• Ressursplanlegger

• Company Management System - CMS

• Timeregistrering pa web

• Kontorstøtte

• Reiseregning pa web

19

6.1.1 Bedriftsintervju med Proxycom

Proxycom bruker TRIUMF-modellen som sin utviklingsmodell i systemutvikling. Sidensystemutviklere har godt kjennskap til kravspesifikasjonen, er det naturlig at de utførersystemtesten. De bruker vanligvis disse testene for alle sine prosjekter:

• enhetstest

• integrasjonstest

• systemtest

• ytelsestest

• brukbarhetstest

• akseptansetest

Proxycom bruker hovedsakelig manuell systemtesting, men de er interessert i a finne et godtautomatisert verktøy. De har prøvd ut en del verktøy for automatisert testing, men de varikke fornøyd pa grunn av at det er tidkrevende. De konverterer kravene fra kravspesifikasjonentil testcase ut fra sine egne erfaringer, men har ingen spesiell metoder for dette. Proxycomønsker derfor a ha retningslinjer for spesielt utforming av testcase ut fra Use Case. Vanligvisbruker de omtrent 20 prosent av prosjekttiden til systemtesting, men det varierer fra prosjekttil prosjekt.

Det er viktig a fokusere pa brukervennligheten i websystemer for a øke tilliten hos brukere.Brukervennligheten blir avklart i kravspesifikasjonen, men det er ikke noe fullstendig listerover hva som kjennetegner brukervennlighet. Proxycom fokuserer pa at GUI skal henvise tilkravspesifikasjonen og skal se pent ut med tanke pa plassering av knapper og tomme linjer fora gi litt luft. Det er systemutviklere som utfører i systemtesten, og brukere i brukbarhetstesten.Det er e!ektiv a la de personene som har utarbeidet kravspesifikasjonen til a utføre systemtest,siden de har mest kjennskap til kravene. Det er nyttig a dokumentere testcasene sa godt sommulig, slik at kunden kan se hva som har blitt utført.

20

6.2 Sparebank 1

SpareBank 1 Gruppen er et finanskonsern med virksomheter innen bank, livs- og fondsforsik-ring, skadeforsikring, fond og eiendomsmegling. SpareBank 1 Gruppen er eid av SpareBank1-bankene, LO og svenske ForeningsSparbanken AB. De har ca 950 ansatte og kontorlokalersentralt plassert i Oslo. IT-seksjon koordinerer felles utviklings- og driftsoppgaver for enhetenei SpareBank 1 Gruppen og for SpareBank 1-alliansens 18 selvstendige banker [23].

6.2.1 Bedriftsintervju med Sparebank 1

Sparebank 1 bruker i utgangspunktet RUP som utviklingsmodell i systemutvikling. Det finnesmange risiko ved websystemer, derfor har Sparebank 1 egne tester for sine websystemer, somfor eksempel nettbank. Det er viktig a bruke nok tid til systemtesting for a holde systemenei stabil drift. Sparebank 1 bruker vanligvis disse testtypene:

• enhetstest

• funksjonelle test

• ytelsestest

• stabilitetstest

• tekniske test

• regresjonstest

• innstallasjonstest

• akseptansetest

• brukbarhetstest

Sparebank 1 bruker foreløpig manuell testing i regresjonstesting, men de har pa noen faomrader bygd opp automatiske script for dette (QTP). De har beskrevne retningslinjer forsystemtesting, men her er det avvik fra prosjekt til prosjekt alt etter erfaring fra de som utførersystemtesten. Det er som regel en gruppe som lager testcase basert pa kravspesifikasjonen, mende har tenkt a benytte et verktøy til a konvertere krav til testcase i fremtiden. Alle prosjekteneer Use Case orientert, men bruker i tillegg andre teknikker som sekvensdiagrammer i noenprosjekter.

Det er brukere som utfører bade i systemtest og brukbarhetstest hos Sparebank 1, fordi deter fordel a ha noen som ikke kjenner sa godt til kravspesifikasjonen enn systemutviklere til ateste systemet. Systemtest skal egentlig være en intern test utført av systemutviklere, men deter leverandør som har ansvaret for systemtesting av prosjektet og Sparebank 1 som mottakerer ansvarlig for akseptansetest. Testing er viktig for Sparebank 1, derfor har de lagt mye vektpa a sette av nok tid til det. Nar det gjelder systemer for ansatte sa gar omtrent 50 prosentav prosjekttiden til testing, og for eksterne systemer omtrent 70 prosent.

21

6.3 Krav til metoder for systemtesting av websystemer

Oppgaven fokuserer pa manuell systemtesting av websystemer, derfor bør metoden væreberegnet pa dette. I tillegg bør den være Use Case orientert og testcasene skal kunne skrivesi et uformelt sprak. Proxycom vil gjerne ha retningslinjer bade for utforming av testcaseog aktiviteter i systemtesting, og for hvordan testscript kan utformes slik at databasenkan tilbakestilles etter testen. Sparebank 1 vil gjerne ha mer av automatisert testingder testscriptene kan bygges og kjøres om natta. Automatisert testing er tidkrevende, saSparebank 1 haper at det kommer bedre verktøy i nærmeste fremtid.

Ved a sammenligne svarene fra Sparebank 1 med Proxycom, sa finner jeg en del ulikheterog likheter mellom dem. Andelen av prosjekttiden som brukes til testing er svært uliki de to bedriftene. Selv om Sparebank 1 bruker RUP, mens Proxycom bruker TRIUMFsom sin systemutviklingsmodell som er basert pa RUP. Begge bedriftene utfører manuellsystemtesting, men er pa utkikk etter gode verktøy til automatisert testing. Proxycom erinteressert i manuell systemtesting, mens Sparebank 1 ønsker mer automatisert testing. Dekravene som Proxycom nevnte under intervjuet brukes videre i metodeundersøkelsen for a sepa om det finnes metoder som tilfredsstiller alle dem.

22

7 Metodeundersøkelse

Jeg skal undersøke hvilke metoder som kan dekke mest mulig av bedriftens krav, og denmetoden som viser seg til a dekke flest mulig av kravene vil jeg beskrive i kapittel 8.

7.1 Metoder for systemtesting

Mange systemutvikler vil gjerne ha en metode som kan hjelpe dem til a lage bedre systemer ogsamtidig tilfredsstiller kundekravene. En god metode for et prosjekt betyr ikke at det passerlike godt til alle prosjekter eller applikasjoner. Det finnes mange metoder, derfor er det viktiga velge en metode som man kan tilpasse til eget formal. Jeg har valgt a undersøke noen avmetodene, og en beskrivelse for hver av dem er vist nedenfor.

1. RUP - Rational Unified Process

RUP er et prosessrammeverk for systemutvikling og ble utviklet av Rational Software [10].Dette rammeverket bestar av de beste arbeidsmetodene fra internasjonale industriledere. RUPer en plan-drevet metode, og i denne metoden lager man en liste over alle aktiviteter sombør utføres. Man vil fa en viss kontroll nar man har en punktvis liste over aktiviteter isystemtesting, for da kan man sørge for at disse viktige punktene blir berørt. Systemtestingblir gjennomført systematisk, og dette kan bidra til god oversikt over hva som skal testes oghvilke feil som ma gjenopprettes.

Metodikken for RUP er a redusere prosjektrisiko, forbedre kommunikasjonen i prosjektteamet,forbedre kontroll over prosjektplan og e!ektiv bruk av UML [10]. Metodikken gar ut pa:

• Lage en detaljert design dokumentasjon av Software.

• Software blir implementert.

• Software blir testet.

• Software blir innstallert hos kundene.

RUP gir en rettledning i hvordan man fordeler ansvar og arbeidsoppgaver innen etutviklingsprosjekt. Hele systemet er Use Case drevet og testing tar utgangspunktet i UseCasene. Nar man bruker RUP i systemutvikling, vil man alltid ha oversikt over hva som erneste skritt i prosessen. RUP bidrar til a oppna høy kvalitet pa det ferdige produktet ogtilfredsstiller kravene fra sluttbrukerne innen en bestemt tidsramme og budsjett.

23

2. XP - Extreme Programming

XP representerer en kodesentrisk utviklingsmetode med vanligvis fa personer involvert, ogdenne metoden bestar av parprogrammering og partesting. Metoden legger mye vekt pa kodeog ikke modeller, derfor begynner programmeringen tidligere enn i andre metoder [39]. MedXP far man tettere samarbeid med kunden, og kunden far vanligvis konkrete resultater tidligslik at han/hun har større muligheter til a gjøre endringer underveis. Metodikken gar ut pa:

• Kodegjennomgang

• Design: endre hele tiden

• Testing : teste hele tiden

• Enkelhet: Velge alltid den enkleste mulige løsning

3. ISO- og IEEE standard

Mange bedrifter bruker et kvalitetsstyringssystem basert pa ISO standarder for a leve opptil kundenes krav [15]. Standarden ble utviklet av den ’Internasjonale Organisasjon forStandardisering’, ISO, for a fastsette internasjonale krav til et ledelsessystem for kvalitets-styring [4]. Et kvalitetsstyringssystem med interne rutiner vil bidra til økt kundetilfredshet.Mange systemutviklere bruker ogsa standard for IEEE, og der finner det en retningslinje forsystemtesting nar man lager testplan eller testcase [24]. Standarder inneholder dokumentasjonfor kriterier, begreper og definisjoner og tekniske spesifikasjoner.

4. Scenariobasert testing

Noen prosjekter bruker scenariobasert testing til a dokumentere kravene, og for hvertbrukstilfelle lages det tester som skal verifisere at brukeren kan utføre de definerte funksjonersom forventet [15]. Scenariobasert testing er nødvendig i alle prosjekter for a sjekke at allebrukstilfellene fungerer, for problemer som oppstar trenger ikke komme fra en komponent,men fra interaksjonen mellom komponenter [38]. Scenario er relevant for de fleste testtypersom for eksempel systemtest, akseptansetest osv.

24

7.2 Resultat fra metodeundersøkelsen

RUP er en systemutviklingsmetode som har en meget omfattende dokumentasjon, sa enbedrift kan ta ut et subsett av metoden og tilpasser den for vedkommende bedrift eller prosjekt.TRIUMF er et slikt subsett og inneholder stort sett de samme aktiviteter og ansvarsfordelingsom RUP. Det som Proxycom savner, og som ikke RUP har, er en retningslinje for a skrivetestcase basert pa Use Case.

Metodeundersøkelsen viser at noen av metodene dekker aktiviteter og maler for systemtesting,men ingen av dem har noen form for regler eller retningslinjer for a lage testcase spesielt fraUse Case. Dette er en av bedriftenes krav, sa derfor har jeg skrevet i kapittel 8.2.2 om hvordanman kan lage testcase ut fra Use Case. Her er en matrise som viser hvilke krav hver metodedekker og ikke dekker i forhold til bedriftenes krav:

MetodeAktiviteter forsystemtesting

Dokumentasjonsmalerfor systemtesting

Regler for a utformetestcase fra Use Case

1. RUP Ja Ja Nei2. XP Ja Nei Nei3. ISO/IEEE-standard Nei Ja Nei4. Scenariobasert testing Ja Ja Nei

Tabell 3: Kravmatrise for metodene

Denne matrisen viser at ingen metode er perfekte, derfor er det lønnsomt a kombinere noenav de nevnte metodene til en ny metodikk for a dekke identifiserte gap. Nar noen spør hvorlangt man har kommet i testingen, sa har testere noen ganger vanskelighet med a svare. Detkan være at de ikke har klar oversikt over hva som er blitt testet eller hvilke krav de ferdigetestene hører til. A lage liste over alle aktiviteter vil være en fordel her, for da har man enplan som man kan ga ut ifra for a sjekke om alle definerte og funksjonelle testene blir kjørtriktig, samtidig unnga forsinkelser i prosjektet. I kapittel 8 har jeg kombinert metodene RUP,scenariobasert og ISO- og IEEE-standarder til en fremgangsmate for manuell systemtesting avwebsystemer. Metodeundersøkelsen viser at det ikke finnes noen spesifikke regler for utformingav testcase, og dette er noe mange bedrifter har behov for. Design av testcase vil bli beskrevetog illustrert i kapittel 8.2.

25

8 Oversikt over aktiviteter ved systemtesting

Det finnes mange mater a utføre en systemtest pa, og det er ikke noe fasit pa hvilke metodesom er best. Mange bedrifter bruker ikke noe bestemte metoder for systemtesting, men deutfører testene ut fra sine egne erfaringer. Det lønner seg allikevel a ha et oppskrift ellerretningslinje a følge etter nar man skal utføre tester pa kravene. Alle de viktigste punkteneblir berørt nar man har et systematisk metodikk til a utføre testing pa. Dette vil bidra tilgod oversikt over hva som er blitt testet og hva som ma reteste. Systemtesting er genereltUse Case orientert, men hvordan Use Case blir brukt pa er helt avhengig av hvilke type ogstørrelse pa prosjektet [15].

I kapittel 8.1 beskriver jeg en mate man kan ga fram trinnvis i systemtesting for websystemer.Maten a lage testcase i systemtesting er avhengig av hvordan systemet og kravene blirrepresentert i kravspesifikasjonen. Noen bruker Use Case diagrammer og tekstlig Use Case tila illustrere funksjonene til systemet, mens andre foretrekker a lage sekvensdiagram i tillegg.Det er nyttig a kombinere alle disse modellene for a fa en bedre oversikt over systemet, menom dette er mulig vil det komme an pa hvor mye tid man har til radighet i prosjektet. Ikapittel 8.2 vil jeg beskrive nærmere flere grunnlag til a designe testcase pa.

26

8.1 Generell fremgangsmate for utførelsen av systemtesting

Systemtest skal verifisere at de funksjonelle kravene er tilfredsstilt av det implementertesystemet. Den etterfølgende metode er bare et forslag til hvordan man kan ga fram isystemtesting. Det vil si at ikke alle punkter ma være gjennomført for at det skal bli envellykket systemtest, sa jobben til testlederen av prosjektet er a finne ut hvilke punktersom kan passe til sitt eget prosjekt. Det er e!ektiv a ha dokumenterte retningslinjer til agjennomføre systemtest for særlig store prosjekter med kompliserte funksjoner i systemet [1].

Her er en trinnvis beskrivelse av hvordan man kan utføre systemtesting pa:

1. Systemtestplan

Lage en systemtestplan som er beskrevet i kapittel 4.2.

2. Gradering av feil

Klassifisering og kategorisering av feil er nyttig. Ved a samle data om feil under utvikling, kanman dermed finne ut hvilke kategorier av feil som opptrer hyppigst. Da har man et redskaptil a sette inn tiltak for a eliminere arsaken til disse feilene [16]. Det er viktig a gradere hvorkritiske feilene er, slik at man kan bestemme om man kan fortsette med testingen eller omsystemet ma forkastes pa grunn av for alvorlige feil [32]. Tabell 4 viser en mate a gradere feilpa.

HøyFeil som har kategorier høy er de som forarsaker gale resultater og utilfredsstiltefunksjoner av systemet. Dette er en kritisk tilstand.

MiddelsMiddels feil er de som medfører unøyaktige resultater. Dette er ikke en kritisksituasjon hvis disse feil ikke blir gjenopprettet.

Lav Feil som har kategorier lav er de som er relatert til lav prioriterte krav.

Tabell 4: A: Gradering av feil

27

En annen mate man kan gradere feil pa er a sette en tidsfrist for a rette pa feilene i henholdtil alvorlighetsgrad [12]. Denne tabellen er vist i tabell 5.

Alvorlig feil Bør rettes straks.Middels alvorlige feil Bør rettes innen en uke.Liten feil Bør rettes innen to uker.

Tabell 5: B: Gradering av feil

3. Ga gjennom kravene i kravspesifikasjonen

Først bør man ga gjennom kravene som er blitt beskrevet i kravspesifikasjonen sammen medkunden. Vanligvis blir alle kravene testet, men i noen prosjekter kan ikke alle kravene blitestet pa grunn av streng tidsramme. I slike tilfeller bør man fokusere pa kravene som kundenhar satt høyest prioritet pa, og lager testcase for dem til systemtesting.

4. Lage en tabell over alle testene

Nar man har gatt gjennom alle kravene som skal teste, kan man lage en oversiktstabell overalle testene i systemtest. Denne tabellen bør inneholde tre elementer: Test ID, krav ID ogselve navnet pa hver test. Denne tabellen vil hjelpe til a holde kontroll over alle testene medtilhørende spesifiserte krav, slik at det blir enklere nar man skal lage testcasene til systemtest.Her illustrerer jeg hvordan tabellen kan se ut for et nettbank system:

Test ID Krav ID Navn

T1 Krav 1 Autentisering av brukerT2 Krav 2 Apne liste for kontoinformasjonT3 Krav 3 Foreta en utbetalingT4 Krav 4 Foreta flere utbetaling samtidigT5 Krav 5 Øverføring av penger til en annen kontoT6 Krav 6 Apne liste over alle transaksjoner for siste manedenT7 Krav 7 Avslutte nettbank

Tabell 6: Tabell over alle testene med tilhørende krav

28

5. Lage testcase ut fra kravspesifikasjon

Hva gar man ut ifra til a lage testcase er avhengig av hvilke modeller som benyttes ikravspesifikasjonen: for eksempel sekvensdiagram eller Use Case. Man kan bruke listen i punkt4 til a holde oversikten over hva som skal teste. Her er et eksempel pa en testcase [15] forautentisering av bruker:

Test ID and Navn T1. Autentisering av brukerTest type (systemtest, brukbarhetstest, akseptansetest)Ansvarlig personDatoEstimert tidMalet med testen (Beskrivelse)Systemets tilstand (Nettsiden til systemet er apnet)

Tekstlige beskrivelse avtesten:

1. Apne websystemet.

2. Skrive inn brukernavn og passord.

Godkjenningskriterie:

• Brukeren kommer inn i systemet etter at brukernavnog passord er identifisert av websystemet.

Beskrivelse av feilFeilgradering ( høy, middels, lav)TidsfristBeskrivelse av feiloppretting

Test utført avVirkelig tidsbruk av testen

Notater (Kommentar til testen)

Tabell 7: Malen for testtabell basert pa IEEE std 829

En testcase vil beskrive hva du skal gjøre i testen og i tillegg vil den inneholde hvilke hendelsersom skjer nar du utfører denne testen. Dermed kan man sjekke underveis om resultatet avtesten er lik det forventede utfallet. Det er en mer detaljert beskrivelse om hvordan man lagertestcase i kapittel 8.2.

29

6. Utføre systemtesting

Na kan man teste systemet ved a utføre hver testcase. Testeren skal utføre i henhold til depunktene som star testcasen, og observerer om de far det forventede resultatet. Hvis testcasengikk som planlagt, sa kan man notere ’OK’ i slutten av tabellen 7. Hvis det gikk galt, sa maman beskrive de feilene som har oppstatt slik at programmerer kan fikse dem.

7. Ajourfør systemtestlogg

Nar testcasene gjennomføres, lages det en liste over de testene som har feilet. Listen børinneholde test ID, beskrivelse av feil, gradering av feil og eventuelt hvilke konsekvenser detvil ha dersom en bestemt feil oppstar. Tabell 8 viser hvordan en slik tabell kan se ut.

Test ID Beskrivelse av feil GraderingT1 Kunne ikke identifisere bruker HøyT4 Kunne ikke foreta flere utbetalinger samtidig HøyT7 Brukeren far ikke logget ut av websystemet Middels

Tabell 8: Liste over feil ved første systemtest

8. Videresende listen til programmerer

Denne listen, gjerne sammen med skjermutskrifter, gir man videre til programmerer, slik atde kan se hvor feilen oppstar i koden og retter i koden før restesting.

9. Retesting etter feilrettingen

Nar feilene er blitt fikset og eventuelt endret pa Use Case tabellene, sa kan testere utføreprosessen fra punkt 6 igjen helt til det ikke oppstar noen feil. Det er bra a lage en liste herogsa for a ha kontroll over hvilke feil som er blitt rettet opp og hvem som har ansvar foropprettingen.

30

10. Lage en liste for testresultatene

Etter at systemtestingen er utført, kan man lage en resultatsliste over alle testene og markereom de er ’OK’. Det er bra a ha alle testcasene som vedlegg i selve testdokumentasjonen, slikat kunden kan se hva som har blitt utført. Tabell 9 er et eksempel pa en liste over testresultater.

Test ID Kommentar Resultater

T1 OKT2 OKT3 OKT4 OKT5 OKT6 OKT7 Brukeren far ikke logget ut av websystemet Ikke bestatt

Tabell 9: Liste for testresultatene

31

8.2 Design for testcase

Fremgangsmaten for a lage testcase som jeg har beskrevet i kapittel 8.2.2 er Use Case orientert,og i tillegg er det nyttig a bruke sekvensdiagrammer. Det er vanlig a kombinere disse toteknikkene i systemutvikling.

8.2.1 Definisjon av testcase

En testcase er et kravbasert dokument som beskriver en input, handling og forventet resultat(output), for a bestemme om en feature av et system fungerer riktig [8]. Utviklingsprosessenfor testcase vil hjelpe til med a finne problemer i kravene eller design av et system, sidenman ma tenke pa alle mulige operasjoner av systemet [3]. Det er derfor viktig a forberedetestcasene tidlig i utviklingsprosjektet.

En testcase bør inneholde disse faktorene [5]:

• Testcase navn

• Testcase identifikasjonsnummer

• Mal

• Oppsett av testen

• Input data for kravene: Beskriver trinn for trinn hva som skal gjøres

• Output data: Beskriver forventet resultatet ut fra testen

Malet med testcase er a lage tester som dekker alle kundekravene. Hva menes med en godtestcase?

En god testcase skal være [38]:

• E!ektiv: Finne feil

• Evaluerbar: Lett a verifisere resultatet

• Oversiktelig: Lett a se hvilke problem som har oppstatt

• Utviklerbar: Enkel a vedlikeholde

• Økonomisk: Billig a bruke eller gjenbruke

32

8.2.2 Fremgangsmate for a lage testcase

Testcase skal hovedsakelig dekke alle kundekravene fra kravspesifikasjonen. Dette kapitteletbeskriver hvordan man kan lage testcase, utføre testcase og evaluere resultatene. For akonvertere kravene til en eller flere testcase, bør man vite hvordan systemet virker. Det erogsa viktig a være klar over ’hva’ som skal testes og ’hvordan’ det skal testes [3].Her er fire punkter som man bør fokusere pa nar man lager testcase:

A. Identifisering av hva som skal testesB. Design av testcase for funksjoneneC. Gruppere alle testcasene under samme kravD. Henvisning testcasene til systemplan

A. Identifisering av hva som skal testes

Det er viktig a ha oversikt over hva som skal testes, og da bør man sette opp en liste over allefunksjonene for systemet som vi vil teste. Disse funksjonene skal være basert pa kundekravenesom er beskrevet i kravspesifikasjonen, og de kan bli identifisert ved for eksempel ved a brukesekvensdiagrammer eller Use Case modeller.

B. Design av testcase for funksjonene

Nar man har laget liste over alle funksjonene som skal testes, kan man bruke den for a lage etsett av testcase som skal dekke kundekravene. Her er det viktig a bestemme hvordan testeneskal bli utført, og finne ut hvilke input, handlinger og forventet resultat for hver test. Malenfor en testcase bør være basert pa IEEE std. 829 som er illustrert i tabell 7. Her vil jegbeskrive nærmere om kombinasjoenen av Use Case og sekvensdiagram som grunnlag til a lageen testcase pa.

Kombinasjon av Use Case og sekvensdiagrammer

Use case diagram viser interaksonene mellom omverden og systemet. Et Use Case eret dokument som beskriver hendelsessekvensen nar en bruker anvender systemet til agjennomføre oppgave [30]. Use Case brukes ofte som grunnlag til a lage testcase basert pakravene i systemtesting, fordi Use Case identifiserer hvilke operasjoner som skal utføres.

I mange prosjekter brukes sekvensdiagrammer i tillegg til Use Case for a beskrive hvordanscenarioene i et Use Case realiseres gjennom objekter som samarbeider. Man bør lagesekvensdiagrammer for viktige Use Case, og dette vil skape en bedre forstaelse av dynamikkeni systemet. Hovedpoenget med sekvensdiagrammet er at man skal kunne oppdage metoder,klasser og koblinger mellom klasser som mangler og tenke gjennom hvordan disse virkersammen [33].

33

Følgende fem punkter bør man ga gjennom for a lage testcase fra Use Case [15]:

1. Samle inn alle Use casene fra kravspesifikasjonen.

Først ma man se pa bade Use Case diagrammer og tekstlige Use Case som er beskrevet ikravspesifikasjonen, for a fa en god oversikt over alle funksjoner til systemet.

2. Analysere disse Use Casene for a se sammenhengen mellom dem.

Det er viktig a se sammenhengen mellom Use Casene, for a kunne bestemme hvilke funksjonsom ma testes først.

3. Analysere hver Use Case basert pa dens normale handlinger.

For hver Use Case bør man ha det klart hvilke hendelser som man forventer skal skje for etbestemt brukstilfelle. Her kan man bruke sekvensdiagrammer til a sjekke ut hvilke hendelsersom ma skje for at en bestemt melding kan sendes videre. Det a ha oversikt over alle testcasenesom henger sammen for en bestemt Use Case vil være til stor hjelp for programmerer nar detgjelder planleggingen av implementasjonen.

4. Analysere hver Use Case basert pa dens alternative handlinger.

Na ma man analysere hvert Use Case for a finne andre mulige hendelser som kan forekommefor en bestemt Use Case.

5. Lag testcase i form av tabell.

For a sikre at de handlingene som er beskrevet blir utført korrekte, ma man lage en eller fleretestcase for hver Use Case. Na kan man lage testcase direkte fra tekstlige Use Case ved a sepa alle hendelser som skjer for et bestemt brukstilfelle. Hvordan en testcase kan se ut er visti tabell 7.

34

8.3 Illustrering av a lage testcase

For a vise hvordan man bruker denne retningslinjen til a lage testcase ut fra Use Case, vil jegbruke et e-handlesystem som eksempel med en Use Case og tilhørende testcase. Her vil jegbruke de fem nevnte punktene for a illustrere trinnene fra Use Case til a lage testcase.

Eks.

1. Samle inn alle Use casene fra kravspesifikasjonen.

For a ska!e seg oversikt over hva som skal testes, ma man se pa alle Use Casene som erskrevet i kravspesifikasjonen. Her er et eksempel pa et Use Case diagram som presenterer allefunksjoner kunden har i systemet:

Figur 5: Use Case diagram for funksjonenene kunden har i systemet

35

Her har jeg tatt ut en enkel funksjon, ’Bestill produkt’, som eksempel for a illustrere hvordanman kan bruke retningslinjen som er beskrevet til a lage testcase ut fra Use Case.

Figur 6: Use Case for ’Bestill produkt’

2. Analysere Use Casene for a se sammenhengen mellom dem.

Figur 6 bestar av mange sub Use Case av hovedfunksjonen, ’Bestill produkt’. Det er viktig alage en liste over rekkefølgen av hendelser for dette brukstilfellet. Ved hjelp av denne listen,vil man se om noen av Use Casene er avhengige av hverandre nar det gjelder testing.

Figur 7: Tabell over alle hendelser i riktig rekkefølge

36

3. Analysere hver Use Case basert pa dens normale handlinger.

Her skal man tenke pa hvordan man gar frem i systemet for a bestille et eller flere produkter.Man kan utarbeide videre med lista fra punkt 2 for a spesifisere forventede hendelser for hvertbrukstilfelle, men her beskriver jeg bare normale hendelser for ’Bestill produkt’.

Normale hendelser for ’Bestill produkt’:

a. Logge inn - skrive inn passord og brukernavnb. Legg til produkt - velge produkter og legg i handlekurvenc. Betal produkt - velge betalingsmated. Bekrefte bestilling - trykke ’OK’ knappen for bekreftelse av bestillingen slik at systemetkan for eksempel trekke beløpet fra kundens konto og en kvittering pa mail til kunden ellersende kunden fakturae. Logge av - trykke pa logg ut knappen pa skjermen

Nar man har analysert de normale hendelser som man forventer for et brukstilfelle, bør man itillegg til Use Case lage et sekvensdiagram for dette. Her er et eksempel pa et sekvensdiagramfor bestilling av produkter:

Figur 8: Sekvensdiagram - Bestill produkt

Et sekvensdiagram har to dimensjoner: den vertikale retningen skal representere tiden og denhorisontale retningen kommunikasjonen mellom objekter [6]. Nar noe skal utføres sendes deten melding fra et element til et annet. Nar en operasjon utføres internt i et element, sa garmeldinger direkte tilbake til avsenderen. Det er viktig at metodenavn i sekvensdiagram er liki implementasjonen, slik at det blir lettere a finne kilden til feil senere. For a gjøre kodingenlettere for programmerer, er det noen som bruker metodenavn istedenfor a skrive oppgaverfor hver melding som sendes mellom objektene, og det er blitt gjort i figur 8.

37

4. Analysere hver Use Case basert pa dens alternative handlinger.

Nar man har analysert de normale handlinger for ’Bestill produkt’, ma man tenke paalternative hendelser eller feilmeldinger for hver hendelse som er nevnt i punkt 3. Her erdet viktig a bestemme hvordan systemet skal reagere i feilsituasjoner som kan forekomme isystemet. Spesielt for denne og forrige aktivitet savner Proxycom gode retningslinjer slik atde far med seg flest mulig av normale og alternative handlinger som kan skje.

a. Paloggingsprosess:

Feil passord eller brukernavn. Kunden kommer ikke inn i systemet, og en feilmelding kommeropp som sier at han/hun ma prøve pa nytt.

b. Legg til produkt:

Varen som kunden har valgt blir ikke markert pa grunn av at varen er utsolgt, og en meldingom det kommer ogsa opp pa skjermen.

c. Betalingsprosess:

Betalingen er ikke i orden pa grunn av at kunden har gitt feil informasjon om sitt kredittkort.

d. Bekreftingsprosess

d.1 Systemet kan ikke bekrefte ordren pa grunn av systemfeil, og en feilmelding dukker opppa skjermen.

d.2 Kvittering blir ikke sendt til kunden etter betalingen.

e. Avloggingsprosess:

Kunden klarer ikke a logge av pa grunn av systemfeil.

5. Lag testcase ut fra tekstlige Use Case.

Tekstlige Use case fra kravspesifikasjonen skal holde oversikt over alle hendelser for dettebrukermønsteret, slik at det blir lettere a lage testcase for det. Her er et eksempel pa en sliktekstlig Use case i form av en tabell:

38

Use Case ID og Navn 2.1 Bestill produktAnsvarlig personDato

Beskrivelse av handlinger:

1. Kunden apner websystemet. Systemet viser et vinduder man skal skrive inn passord og brukernavn.

2. Skrive inn brukernavn og passord. Brukeren kommerinn i systemet etter at brukernavn og passorder identifisert av websystemet og systemet viserhovedsiden.

3. Kunden velger et eller flere produkt, dato og tid forlevering.

4. Systemet ber om bekreftelse fra kunden.

5. Systemet viser mulige betalingsmater.

6. Kunden velger betalingsmate.

7. Systemet bekrefter bestillingen og kvittering blir sendtdirekte til kunden via e-mail.

8. Systemet sender ordren til bestemt avdeling.

9. Ansatte hos avdelingen pakker og sender varer tilkunden.

Alternativer:

2.a I punkt 2, brukeren taster inn feil brukernavn ellerpassord og da vil det komme en feilmelding opp paskjermen.3.a Kunden har valgt varer som har gatt tomt for, ogfeilmelding kommer opp.4.a Systemet fungerer ikke pga systemfeil.6.a Kunden vil betale med kort, taster inn kortinformasjonog systemet sjekker inntastet informasjonen motbanksystem.7.a Systemet kan ikke bekrefte bestillingen pga feilkortinformasjon og feilmelding kommer opp.7.b Systemet gir beskjed om betaling OK.8.a Systemet kan ikke sende ordren til avdelingen, og detkommer opp en melding om at kunden skal prøve igjensenere.9.a Ansatte leverer feil vare.

Tabell 10: Use Case - Bestill produkt

39

Na kan man lage flere testcase direkte ut fra denne tekstlige Use Case ved a lage en testcasefor hver normale og alternative hendelser. Man bør ogsa tenke pa hvilken form feilmeldingskal ha for a informere kunder. Feilmeldinger kan for eksempel være sma popup-vinduer. Herer et eksempel pa oppsettingen for tre av testcasene i samme tabell:

Use Case ID ognavn

2.1 Bestill produkt

Test ID T.1 T.2 T.3Beskrivelse avhandlinger

Skrive inn feil brukernavneller passord.

Velge en vare somhar gatt tomt.

Skrive inn feilkortinformasjon.

GodkjenningskriterieBrukeren kommer ikke inn isystemet, men far en feilmel-ding opp pa skjermen.

En feilmelding omat varen er tomtkommer opp paskjermen.

Systemet viser enmelding om atkortinformasjoner feil.

Beskrivelse av feilFeilgradering ( høy, middels, lav)TidsfristBeskrivelse avfeilopprettingTest utført avVirkelig tidsbrukav testen

Notater(Kommentar tiltesten)

Tabell 11: Testcase - Bestill produkt

C. Gruppere alle testcasene under samme krav

Det er ikke alltid bare en test for hvert krav eller funksjon. Ofte ma man dele testene inn ideltester for a dekke et krav. Her bør man ordne alle testene i samme kravkategori, slik atman vet hvilke tester som er avhengige av hverandre for a tilfredsstille et bestemt krav. Deter greit a beskrive aktuelle avhengigheter av testene i testdokumentasjonen.

D. Henvisning testcasene til systemplan

Nar testcasene er pa plass sa bør man forholde dem til systemplanen. Det lønner seg a lageen liste over nar hver test skal utføres og hvem som har ansvar for det i følge systemplanen.

40

9 Oppsummering

Det er viktig a bruke god tid pa testing, og mange systemutviklere vil anbefale at man brukerminst 1/3 del av tiden under utviklingsprosjektet [33]. Man kan aldri forvente at systemet er100 prosent perfekt og ikke feiler etter godkjenningsfasen. Tester hjelper til a finne mulige feilsom kan oppsta, og en Use Case modell er nyttig nar det gjelder systemtesting av websystemer.

Jeg fant ingen metoder fra metodeundersøkelsen som dekker regler for hvordan man kanutforme testcase ut fra Use Case, derfor er det behov for a utvikle metoder innen detteomradet slik at testing kan forega mer systematisk. Det finnes ingen perfekte metoder for alage testcase, derfor bør man i noen tilfeller kombinere Use Case med andre teknikker som foreksempel sekvensdiagrammer [26]. Dersom man finner mangler i Use Case, ma man fikse denslik at prosjektet ikke blir forsinket i forhold til planen. Nar en Use Case blir endret kan detogsa pavirke testcasene, og det kan ta lang tid før alt er rettet. Dersom godkjenningskriteriefor testingen ikke oppnas, ma man eventuelt lage og utføre flere testcase.

A lage testcase i form av tabeller vil være e!ektiv, for det vil bade spare tid og arbeid narman skal vedlikeholde dem. Nar man finner feil ved a utføre testcasene under testing, vil manha en god oversikt over de feilene som har oppstatt. Feilene blir dermed rettet raskere, ogbilligere blir det ogsa nar det gjelder gjenbrukbarhet av tabellene. Siden testcasene er basertpa kravspesifikasjonen, kan man evaluere om systemet har dekket alle kravene fra kunden.

41

10 Validering av prosjektet

Prosjektet gikk ut pa a finne metoder for systemtest av websystemer, og følgende aktiviteterskulle utføres:

1. Beskriv praktiske erfaringer med systemtesting.

2. Innsamling foretas fra Internett, litteratur og bedrifter.

3. Spesifiser krav til metoder for systemtesting basert pa praktiske erfaringer.

4. Gi en oversikt over metoder for systemtesting. Innsamling foretas fra Internett oglitteratur.

5. Evaluer metodene og vurder i hvilken grad de tilfredstiller kravene.

6. Apent: Utprøving av metode, formulere bedre metoder eller prototyper av verktøy.

I prosjektet er disse aktivitetene blitt utført, og det viste at det finnes metoder som beskriveraktiviteter og dokumentmaler, men det mangler metoder som gir retningslinjer for hvordantestcase kan skrives. I prosjektrapporten er det beskrevet en fremgangsmate for systemtestingbasert pa de eksisterende metodene. Videre arbeid med dette prosjektet kan være a laIT-bedrifter følge beskrevne fremgangsmaten til a gjennomføre systemtest og utformingav testcase pa, og til slutt fa tilbakemelding fra dem om det var noe forbedring i deressystemtesting. En annen ting som man kan jobbe videre med er a utvikle bedre metoder forsystemtesting og utforming av testcase.

42

A Vedlegg - Spørsmal til bedriftsintervju

Dette vedlegget inneholder spørsmal om systemtesting som jeg har utarbeidet før selveintervjuene, og de blir brukt under intervjuene med Proxycom og Sparebank 1.

1. Hvilke systemutviklingsmodell bruker dere?

2. Hvilke erfaringer har dere med systemtesting av websystemer?

3. Hvilke konsekvenser far dere nar det er darlig systemtesting av websystemer?

4. Hvilke typer tester tar dere?

5. Bruker dere manuell eller automatisert testing? Hvilke verktøy?

6. Hvilke metoder bruker dere til systemtesting?

7. Hvordan gar dere fra krav til a lage testcase?

8. Bruker dere mye tid til testing?

9. Hvordan tester dere GUI? Hvor viktig er brukervennlighetetn?

10. Hvem er det som tester? Systemutviklere eller brukere?

11. Hvor viktig er testing for dere?

12. Hvilke krav har du til en bedre metode for systemtesting?

43

B Vedlegg - Bedriftsintervju med Proxycom

Dette vedlegget er resultatene av intervjuet med Proxycom om systemtesting. Intervjuet medIT-sjefen, Trond Johansen, varte i nesten en time og dette ble avholdt onsdag 28.september iTrondheim. Etter dette intervjuet sa har jeg skrevet et referat fra intervjuet og sendt det tilTrond for a fa det godkjent før jeg la dette sammendraget i prosjektrapporten.

1. Hvilke systemutviklingsmodell bruker dere?

Vi bruker TRIUMF-modell.

2. Hvilke erfaringer har dere med systemtesting av websystemer?

Systemtesting er viktig, for man vil vanligvis finne 4-5 feil i hver brukstilfelle som er middelskritiske. Hvis man ikke legger vekt pa systemtesting, sa vil en del feil slippe igjennom igodkjenningsfasen. Det er e!ektiv a la de personene som har utarbeidet kravspesifikasjonentil a utføre systemtest, siden de har mest kjennskap til kravene. Det er nyttig a dokumenteretestcasene sa godt som milig, slik at kunden kan se hva som har blitt utført.

3. Hvilke konsekvenser far dere nar det er darlig systemtesting av websystemer?

Dersom vi har utført darlig systemtesting før lansering av produktet, sa vil det oppsta fleresystemfeil som kan være kritiske. For eksempel nar vi har laget et program med tusenvis avbrukere, sa kan feil berøre mange brukere og kan medføre økonomiske konsekvenser.

4. Hvilke typer tester tar dere?

Vi bruker disse testene i denne rekkefølgen for alle vare prosjekter:

1. enhetstest: per brukstilfelle

2. integrasjonstest : per brukstilfelle

3. systemtest : nar hvert brukstilfelle er ferdig

4. brukbarhetstest

5. akseptansetest

44

5. Bruker dere manuell eller automatisert testing? Hvilke verktøy?

Vi utfører hovedsakelig manuell systemtesting, men vi er pa jakt etter en god automatiserteverktøy. Vi har prøvd en del verktøy i dette feltet, men resultatet fra denne utprøvelsen varat det tok for lang tid til a endre testcasene.

Vi bruker verktøy for visse typer systemer, som for eksempel benytter vi et program til asimulere datautveksling. Det kan være et websystem som mottar XML meldinger fra et annetsystem. Dette verktøyet kan teste et bestemt system uten at andre systeme er i drift.

6. Hvilke metoder bruker dere til systemtesting?

Vi bruker vare egne erfaringer til a konvertere kravene fra kravspesifikasjonen til testcase. Iutgangspunktet sa er blir det laget en testcase eller flere testcase for hver tekstlig Use Case.Vi utfører i tillegg ytelsetest ved bruk av et program fra Microsoft. Dette programmet girstatistikk i tidsforbruk og responstid for hvert brukstilfelle.

7. Hvordan gar dere fra krav til a lage testcase?

Det har jeg allerede svart pa forrige spørsmal, og som sagt utgangspunktet fra egne erfaringer.

8. Bruker dere mye tid til testing?

En del tid bruker vi til testing, men det varierer om det er et enkelt eller komplisert program.Vanligvis bruker vi ca. 20 prosent til systemtesting.

9. Hvordan tester dere GUI? Hvor viktig er brukervennlighetetn?

GUI skal henvise til kravspesifikasjonen, og selvfølgelig skal det ogsa se pent ut med tankepa plassering av knapper og tomme linjer for a gi litt luft. Brukervennligheten blir avklarti kravspesifikasjonen, og den blir fokusert i brukbarhetstesten som utføres av en som hararbeidet med kravspesifikasjonen.

10. Hvem er det som tester? Systemutviklere eller brukere?

Det er systemutviklere som utfører i systemtesten, og brukere i brukbarhetstesten.

45

11. Hvor viktig er testing for dere?

Systemtest er veldig viktig for oss, fordi den hjelper oss til a finne feil før brukstilfelleroverleveres til oppdragsgiver eller settes i drift.

12. Hvilke krav har du til en bedre metode for systemtesting?

Metoden bør:

• være beregnet for manuell systemtest av websystemer

• være Use Case orientert

• ha et slags uformelt sprak for a skrive testscript(testcase)

• ha retningslinjer for hvordan man kan skrive testscript for a teste ulike krav ikravspesifikasjonen

• ha retningslinjer for hvordan testscript kan utformes slik at de kan tilbakestille databasenetter testen

46

C Vedlegg - Bedriftsintervju med Sparebank 1

Dette vedlegget er resultatene av intervjuet med Sparebank 1 om systemtesting. Intervjuetmed IT-sjefen, Ketil Berg, varte i nesten en time og dette ble avholdt mandag 10.oktober iTrondheim. Før intervjuet spurte jeg om jeg kunne ta opp samtalen under intervjuet, og detvar i orden for Ketil. Etter dette intervjuet sa har jeg skrevet et referat fra intervjuet og sendtdet til Ketil for a fa det godkjent før jeg la dette sammendraget i prosjektrapporten.

1. Hvilke systemutviklingsmodell bruker dere?

Vi bruker i utgangspunktet RUP som utviklingsmodell som vi har gjort tilpasning av den tilvart eget formal.

2. Hvilke erfaringer har dere med systemtesting av websystemer?

Vi har mange erfaringer innen systemtesting av websystemer. Det er helt klart at det finnesmange risiko ved websystemer, og for a sikre kravene sa har vi egne retningslinjer for testing.Vi har for eksempel egne tester for nettbank, og spesielle tester som blir utført her er ikkebare ytelsestest, men ogsa ulike tekniske tester samt innbruddsdtester.

3. Hvilke konsekvenser far dere nar det er darlig systemtesting av websystemer?

Dersom det er snakk om systemer for de ansatte, sa vil risikoen være at systemene stopperopp og de ansatte far da ikke behandle kundene. Nar det gjelder eksterne systemer som foreksempel nettbank, sa er det risiko for sikkerhetsinnbrudd. Dette vil da medføre til darligstabilitet og ytelse som kan være alvorlige økonomiske konsekvenser. Det er viktig for oss atdet skal være vare systemer i stabil drift.

4. Hvilke typer tester tar dere?

Det varierer litt pa hvilke tester vi bruker fra prosjekt til prosjekt. Rammeverket vart er atalle vare prosjekter ma ga gjennom enhetstest. Vi bruker som vanligvis ogsa funksjonelletest, integrasjonstest, systemtest, ytelsestest, stabilitetstest, tekniske test, regresjonstest,innstallasjonstest og akseptansetest. Stabilitetstest skal teste med høy trykk over lang tid, og itekniske test sa kjører vi avbrudd pa komponentene i koden for a sjekke hvordan applikasjonenreagerer. Brukbarhetstest bruker vi i noen tilfeller, og for a avgjøre om denne type testingskal gjennomføres sa ma vi kjøre vurdering pa det først.

47

5. Bruker dere manuell eller automatisert testing? Hvilke verktøy?

Det er manuell testing i regresjonstesting hittil, men vi er i ferd med a ga over til a brukefor eksempel verktøyet Mercury til automatisert testing. Vi har i mange ar benyttes LoadRunner fra Mercury Interactive. De verktøyene vi nettopp har starta med er Test Director ogQTP.

6. Hvilke metoder bruker dere til systemtesting?

Framgangsmate er a kjøre alle definerte og funksjonelle testene. Det er RUP rammeverk vi garut i fra her, men hvilke metoder vi benytter i systemtesting varierer litt med typer prosjekter.

7. Hvordan gar dere fra krav til a lage testcase?

Det varierer fra prosjekt til prosjekt, men som regel sa er det en gruppe som beskrivertestcasene basert pa kravspesifikasjonen. Vi er i ferd med a bruke verktøy til a konverterekrav til testcase. Alle vare prosjekter er Use Case orientert, men i noen tilfeller bruker vi ogsasekvensdiagram i tillegg.

8. Bruker dere mye tid til testing?

Vi bruker mye tid til testing, og det som tar mye tid er blant annet ytelsestest og stabilitetstest.Nar det gjelder interne systemer sa bruker vi omtrent 50 prosent til testing, og omtrent 70prosent for eksterne systemer.

9. Hvordan tester dere GUI? Hvor viktig er brukervennlighetetn?

Det er viktig for oss a ta vare pa brukervennligheten, og det er verdien for Sparebank 1.Det som er problemet her er at vi ikke far nok ressurser til a teste grundig nok som vikunne ha gjort. Det har kommet forslag om a danne en egen brukskvalitetslab der vi kanobservere brukbarheten til systemet, og nøkkelordet her er mer systematikk. Vi har en egengodkjenningskriterie for hvordan GUI skal være.

10. Hvem er det som tester? Systemutviklere eller brukere?

Det er brukere som tester i bade systemtest og brukbarhetstest. Vi føler at det kan værebra a la andre enn systemutvikleres til a teste systemet, siden de ikke kjenner godt tilkravspesifikasjonen.

48

11. Hvor viktig er testing for dere?

Testing har vært lenge undervurdert, og det har gitt alvorlige konsekvenser nar systemet skallanseres. Testing er som sagt veldig viktig for oss, derfor har vi brukt mye tid til det.

12. Hvilke krav har du til en bedre metode for systemtesting?

Det som kan bidra til bedre systemtesting er a utføre mere automatisert testing dertestscriptene kan bygges og kjøres om natta. Det som har holdt oss tilbake nar det gjelderautomatisert testing er at det er tidkrevende, men de verktøyene som har kommet i det sisteer bedre na.

49

D Vedlegg - Ordforklaringer

Akseptansetest :

Test gjennomført pa et system i den hensikt a fastsla at systemet fungerer i henhold tilbrukernes behov og krav.

Black-box testing :

Black-box testing eller funksjonell testing er en testmetode der testen bygger pa programmeteller komponentspesifikasjonen.

Database :

En stor samling av data som for eks. i en datamaskin, og den er organisert slik at man kanoppdatere, utvide og gjenopprette hurtig for flere brukere. En database pa nett kan ogsa bestaav linker til andre nettsider.

Enhetstest/Modultest :

En avgrenset del av et system (f.eks. en subrutine) testes for seg.

Feil :

Gal oppførsel som blir resultatet av en mangel.

Funksjonell test :

Sjekker om en modul tilfresstiller de eksterne kravene man har satt til den.

HTML :

HyperText Markup Language - er spraket som blir brukt til a publisere dokumenter painternett.

HTTP :

Hypertext Transfer Protocol - er en protokoll for a overføre data over internett. HTTP brukesfor wetjenester som for eksempel sørger den for at en hjemmeside er leselig pa internett.

IEEE-standard :

Inneholder maler og retningslinjer for blant annet testplan og testcase.

Input :

Det som skal testes.

50

Integrasjonstest :

Test av grensesnittet mellom enheter/moduler i et system. Grunnlaget for testingen er designetfor systemet (og koden).

ISO-standard :

ISO er en standardiseringsorganisasjon som gjelder ’world-wide’.

Klient :

En klient som er ansvarlig for interaksjon med brukeren, for eksempel ved a ta imot tastetrykk,og vise informasjon pa skjermen. Nar vi holder pa med publisering vil den typiske klientenvære nettleseren var.

Krav sporbarhet:

Brukerene ønsker at kravene er slik de ønsket. Test slik at hvert krav blir individuelt testet.

Output:

Forventet resultat.

Regresjonstest :

Her tester man hele systemet eller deler av systemet etter at ny kode er lagt til eksisterendekode.

RUP :

Er et prosessrammeverk for systemutvikling, utviklet av Rational Software.

Scenario :

Scenario er et sett av forventede handlinger som blir utført av en potensiell bruker av systemet.

Sekvensdiagram :

Interaksjonsdiagram som viser objektene som deltar i en bestemt interaksjon, og meldingenede utveksler, arrangert i en tidssekvens.

Sikkerhetstest :

Sikre systemet for inntrengere.

Skalerbarhet :

Hvor bra systemet takler dersom utallige brukere kopler til systemet samtidig.

51

Stabilitetstest:

Tester systemet med høy trykk over lang tid, og i tekniske test sa kjører man avbrudd pakomponentene i koden for a sjekke hvordan applikasjonen reagerer.

Stresstest :

Tester hastigheten pa mange samtidige transaksjoner.

Systemtesting :

Test av et system som en helhet, og grunnlaget for testingen er kravspesifikasjonen.

Testcase :

En testcase er et kravbasert dokument som beskriver en input, handling og forventet resultat(output), for a bestemme om en feature av et system fungerer riktig.

Testlogg :

Testlogg med beskrivelse av feil og deres løsning.

Testplan :

detaljert testplan som beskriver hver enkelt test som skal gjennomføresHver enkelt test beskrives ved a angi hva som skal testes, inndata, kommandoer/handgrep ogikke minst forventet resultat av testen

Time-to-market:

Tiden det tar fra a starte produktutviklingen til produktet er ferdigstilt og tilgjengelig pamarkedetonent.

TRIUMF:

TRInnvis UtviklingsMetode For programsystemer.

UML :

Er et modelleringssprak som blant annet brukes til a designe og dokumentere programmer ijava.

Usability test:

Usability testing er et verktøy for a finne ut hvor lett systemet er a forsta og bruke (og hvasom kan forbedres), ved a observere sluttbrukere i mest mulig realistiske brukssituasjoner

52

Use Case :

Et use case er en oppgave som brukeren vil utføre ved hjelp av systemet. Et use case beskriverhendelser i systemet.

Validering:

Validering er a finne ut om vi har laget det rette produktet.

Verifikasjon :

Verifikasjon er om man har laget produktet pa riktig mate.

Websystem :

Websystemer innebærer klienter, og en eller flere fysiske servere som bidrar til flere typer avservice.

Web-browser :

Et program som brukes til a vise innhold ifra internett, og nettleserens jobb er a oversetteHTML-kodene som angir posisjon av tekst og bilder og vise dette i henhold til koden.

Web-server :

Er en spesiell internett-tjeneste som lar et firma eller en person benytte et tilpassetdomenenavn pa Internett.

Web-service :

Er en samling av protokoller og standarder som brukes for a dele data mellom applikasjoner.

White-box testing :

White box er en metode der testene bygger pa kunnskap om programvarestrukturen ogimplementasjonen.

XP :

Extreme Programming.

Ytelsestest :

Tester hastigheten for en transaksjon.

53

Referanser

[1] Ash, Lydia, The Web Testing Companion - The Insider’s Guide to E!cient and E"ectiveTests”, Wiley 2003.

[2] Debugging , explorer 1, 05-10-2005. URL: http://en.wikipedia.org/wiki/Debugging.

[3] Developing software test cases, explorer 1, 13-10-2005. URL: www.testingeducation.org/conference/wtst3_collard1.pdf.

[4] Dnv - iso 9001 , explorer 1,23-10-2005. URL: dnv.no/sertifisering/systemsertifisering/kvalitet/.

[5] Falk, Jack, Testing Computer Software”, Wiley 1999.

[6] Flere uml-modeller , explorer 1, 29-10-2005. URL: www.iu.hio.no/~kirstenr/systemutvikling/slides2005/15_UML2.ppt.

[7] Fulp, E. W., Testing - Wake Forest Univerity”, Var 2002.

[8] Glossary, explorer 1, 13-10-2005. URL: http://www.geocities.com/r-davis/3021.html.

[9] Hutcheson, Marnie L., Software Testing Fundamentals - Methods and Metrics”, Wiley2003.

[10] Hva er rup, explorer 1,18-10-2005. URL: http://www.kantega.no/kurs/faglig/.

[11] Interaksjonsdiagrammer, explorer 1, 03-09-2005. URL: www.idi.ntnu.no/emner/tdt4140/losninger.htm.

[12] Johansen, Trond, TRIUMF”, Spartacus Oslo 1999.

[13] Konfigurasjonsstyring og systembygging, explorer 1, 07-09-2005. URL: http://folk.uio.no/ronnyw/in219/kap33.html.

[14] Lereng, Furuseth, Testing of Web Systems”, NTNU 2004.

[15] Nguyen, Hung Q., Testing Application on the Web - Test Planning for Mobiule andInternet-Based Systems”, Wiley 2003.

[16] Norsk nettskole, ressurssider, explorer 1, 07-11-2005. URL: http://www.ressurssidene.no.

[17] Note om systemudvikling , explorer 1, 04-10-2005. URL: www.vejlehs.dk/staff/amt/Kurser/Noter/Systemudvikling.pdf.

[18] Om systemutvikling og modeller, explorer 1,24-08-2005. URL: www2.hit.no/af/ifim/kurs/kurs853/foreles/Repetisjon.ppt.

[19] Prosjektplanlegging, explorer 1, 08-10-2005. URL: http://www.ifi.uio.no/in219/.

[20] Proxycom, systemutviklingsmetodikk, explorer 1,22-08-2005. URL: www.proxycom.no.

54

[21] Rausand, Marvin, Risikoanalyse”, Tapir forlag 1991.

[22] Sidestruktur, explorer 1,29-08-2005. URL: www.ia.hiof.no/~trondl/tekniskweb/pages/Sidestruktur.html.

[23] Sparebank1, explorer 1,15-10-2005. URL: www.sparebank1.no.

[24] Stalhane, Tor, Gjennomgang av IEEE Std 829 ”,.

[25] System-utviklingsmetodikk, explorer 1, 14-09-2005. URL: http://www.teknologihovedstaden.net/it-nett/psmaler.

[26] Test design for web, explorer 1, 15-09-2005. URL: www.softtest.org/sigs/material/rosscollard1.pdf.

[27] Testdokumentasjon, explorer 1, 02-10-2005. URL: www.idi.ntnu.no/emner/sif8018/dokumenter/Testdokumentasjon.doc.

[28] Testguide for saus, explorer 1, 08-10-2005. URL: http://www.usit.uio.no/saus/testguide/.

[29] Testprosessen - sum, explorer 1, 05-09-2005. URL: www.itea.ntnu.no/sum/prosesser/test.

[30] Uml, explorer 1, 06-10-2005. URL: http://home.c2i.net/ailin.moeller/UML-boka.doc.

[31] Usability-testing, explorer 1, 04-10-2005. URL: home.hia.no/~ledokked/is3410/F_6_16_11_Usabilitytesting.ppt.

[32] Validering og verifisering , explorer 1, 27-10-2005. URL: http://www.idi.ntnu.no/~stalhane/sif8054/notater/validering.pdf.

[33] Validering og verifisering, explorer 1, 11-10-2005. URL: http://www.iu.hio.no/~kirstenr/systemutvikling/slides2005/11_Validering_verifisering.ppt.

[34] Verification and validation, explorer 1, 07-09-2005. URL: www.home.online.no/~gusloek/skole/in140/VerificationandValidation.doc.

[35] Verifikasjon og validering, explorer 1, 06-10-2005. URL: folk.uio.no/ronnyw/in219/kap22.html.

[36] Verifikasjon og validering vedlikehold, explorer 1,28-08-2005. URL: www2.hit.no/af/ifim/kurs/kurs853/foreles/SU_test_vedlikehold.ppt.

[37] Webtest-test af webapplikation, explorer 1, 16-09-2005. URL: www.vrpartners.dk/Appendiks/stappWebtest.htm.

[38] What is a good test case? , explorer 1, 04-10-2005. URL: www.kaner.com/pdfs/GoodTest.pdf.

[39] What is extreme programming? , explorer 1,20-10-2005. URL: www.xprogramming.com/xpmag/whatisxp.htm.

55