TDT4735 Systemutvikling, fordypning. Metoder for systemtest av websystemer

Transkript

1 TDT4735 Systemutvikling, fordypning Metoder for systemtest av websystemer Hong Trang Thi Nguyen Veileder: Tor Stålhane Høst Norges teknisk-naturvitenskapelige universitet

2 Forord Dette prosjektet er skrevet i forbindelse med fordypningsfaget TDT4735 Systemutvikling på NTNU i 5. årskurs ved Institutt for Datateknikk og Informasjonsvitenskap, IDI. Oppgaven handler om metoder for systemtesting med fokus på websystemer. Jeg vil gjerne sende en stor takk til IT-sjefen for Proxycom, Trond Johansen, for å ha delt sine praktiske erfaringer og gitt meg gode råd når det gjelder systemtesting. Jeg setter også stor pris på Proxycom og Sparebank 1 som har tatt seg tid til intervjuer, slik at jeg fikk mange gode opplysninger om deres arbeid innenfor dette emnet. Til slutt vil jeg gjerne takke min veileder, Tor Stålhane, for den gode oppfølgingen og hjelpen gjennom dette semesteret. Trondheim 20/ Hong Trang Thi Nguyen II

3 Innhold 1 Innledning Oppgavebeskrivelse Mål med prosjektet Testing Definisjon av testing Testklassifisering Black Box White Box Testfaser Modul/Enhetstest Integrasjonstest Systemtest Regresjonstest Usability test Akseptansetest Plassering av systemtesting i prosjektutviklingen Forstudium Kravspesifikasjon Design Programmering Testing Vedlikehold Praktiske erfaringer med systemtest Feilfinning Testplan Testteam Testrapport Risikoanalyse Konfigurasjonshåndtering Websystem Definisjon av websystem Struktur Krav til websystem Intervju med IT-bedrifter Proxycom Bedriftsintervju med Proxycom Sparebank Bedriftsintervju med Sparebank Krav til metoder for systemtesting av websystemer Metodeundersøkelse 23 III

4 7.1 Metoder for systemtesting Resultat fra metodeundersøkelsen Oversikt over aktiviteter ved systemtesting Generell fremgangsmåte for utførelsen av systemtesting Design for testcase Definisjon av testcase Fremgangsmåte for å lage testcase Illustrering av å lage testcase Oppsummering Validering av prosjektet 42 A Vedlegg - Spørsmål til bedriftsintervju 43 B Vedlegg - Bedriftsintervju med Proxycom 44 C Vedlegg - Bedriftsintervju med Sparebank 1 47 D Vedlegg - Ordforklaringer 50 Figurer 1 Testmodell Testrekkefølge V-modell Websystem arkitektur Use Case diagram for funksjonenene kunden har i systemet Use Case for Bestill produkt Tabell over alle hendelser i riktig rekkefølge Sekvensdiagram - Bestill produkt Tabeller 1 Tabell som viser ansvarsfordeling Tabell for risikoanalyse Kravmatrise for metodene A: Gradering av feil B: Gradering av feil Tabell over alle testene med tilhørende krav Malen for testtabell basert på IEEE std Liste over feil ved første systemtest Liste for testresultatene Use Case - Bestill produkt Testcase - Bestill produkt

5 1 Innledning 1.1 Oppgavebeskrivelse Testing er viktig for å kontrollere validering og verifikasjonsprosessen. Validering er å finne ut om vi har laget det rette produktet, mens verifikasjon ser på om man har laget produktet på riktig måte. Validering og verifikasjon brukes på alle trinn i systemutviklingen for å sikre at systemet 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 for systemtesting av websystemer. Dette syns jeg er et interressant emnet, for det er viktig å utføre så god systemtesting av websystemer som mulig, ellers kan det få katastrofale konsekvenser for bedrifter. I kapittel 2 vil jeg beskrive hva testing er og hvilke typer tester som man bør utføre for websystemer. Kapittel 3 handler om ulike faser i prosjektutviklingen med tilhørende dokumenter. Det er viktig å vite de praktiske erfaringer med systemtesting som er beskrevet i kapittel 4. Oppgaven går ut på å finne en systematisk metode eller retningslinjer for systemtesting og utforming av testcase manuelt, derfor har jeg foretatt metodeundersøkelser i kapittel 7 ved å intervjue to IT-bedrifter. Hvilke krav disse bedriftene har til systemtesting av websystemer er 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 testbare testcase er beskrevet i kapittel 8. Oppsummering og validering av prosjektet finnes i kapittel 9 og Mål med prosjektet Dårlig systemtesting av websystemer kan føre til store økonomiske konsekvenser, derfor er det behov for bedrifter å få mer informasjon om flere metoder for systemtesting av websystemer slik at man kan tilpasse en metode til sitt eget prosjekt. Det er mange bedrifter som ikke benytter noen bestemte metoder eller verktøy for systemtesting. Fremgangsmåten som mange benytter idag er manuell systemtesting basert på egne erfaringer. Å utføre systemtesting av websystemer systematisk er en god fremgangsmåte for å sikre at alle de viktige aktiviteter blir utført. Det er også viktig å ha en god fremgangsmåte til å lage testcase i systemutvikling. Målet med dette prosjektet er derfor å finne informasjoner om metoder for systemtest av websystemer, og samtidig beskrive en systematisk fremgangsmåte i systemtesting av websystemer og utforming av testcase slik at bedrifter kan høy sannsynlig utvikle et kvalitetsprodukt. Alle bedrifter vil at deres produkter og tjenester skal vise kvalitet og effektivitet, og det er essensielt at testing må være godt utført. Ved å ha en formalisert testprosess kan man oppdage feil som oppstår på et tidlig tidspunkt, og da har man mulighet til å rette dem opp før man lanserer produktet. Dette vil føre til mange fordeler for en bedrift som besparelse av tid, ressurser og kostnader. Jo senere en feil oppdages, desto mer alvorlig og større konsekvenser får den. 2

6 2 Testing Testing har lenge vært undervurdert i systemutvikling, og mange prosjekter mislykkes på grunn av dette. Testing er viktig i alle utviklingsarbeid, fordi testing vil kunne validere om kravene til et system er tilfredsstilt som forventet. Testing er nødvendig, så det er viktig å vite hva testing egentlig er. 2.1 Definisjon av testing Testing brukes for å kontrollere utførelse, pålitelighet og brukergrensesnitt og for å sjekke om kravene var riktig i forhold til hva brukeren ønsker [34]. Målet for testing er å sjekke hvor godt et system oppfyller kundenes krav, og resultatet av kjøringer blir sammenlignet med fasit. Det er derfor lønnsomt å teste tidlig og jevnlig under hele utviklingen. Når man snakker om testing vil man ofte forbinde det med kvalitetssikring. Hensikten med testing er å finne feil, og en vellykket test er en test der man finner feil i programkoden, designet, kravspesifikasjonen eller dokumentasjonen for systemet [27]. Fordelen med testing er at man kan finne feil i tidlig fase av utviklingen, slik at man kan spare tid og arbeid. Testing kan ikke garantere at systemet er feilfri, men testing kan brukes til å vurdere om man vil eller kan 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 å sjekke at feil er blitt fikset. Systematisk : random (tilfeldig) testing er ikke tilstrekkelig, derfor er det lurt å gjennomføre testing systematisk for å dekke alle brukstilfellene i systemet. Dokumentert : bedre oversikt når man har skrevet testdokumentet med resultater fra testene, slik at kunden kan også se hvilke tester som er blitt utført for systemet. Det er viktig å skille mellom debugging og testing. Debugging reparerer en påvist feil, og testing søker å påvise slike feil. Debugging er en prosess for lokalisering hvor i koden feilen ligger, og deretter blir feilen rettet opp. Debugging skjer på følgende måte [2]: Bruke minimal test som fremprovoserer feil. Lokaliser feil. Reparer feil. Teste igjen med minimal test. 3

7 Figur 1 viser en typisk testmodell i systemutvikling. Under testingen setter man opp et sett av inndata og forventede utdata basert på de gitte inndata, og kjører deretter testen for å sjekke 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 tester 2. Utføre tester 3. Skrive testrapport Inndata: det som skal testes Utdata: forventede resultater eller output 4

8 Et system kan befinne seg i ulike tilstander avhengig av hvor i utviklingsprosessen det er. De lagrede data i databasen bestemmer systemets tilstand. Systemets output bestemmes ikke bare av input, men også av systemets tilstand. Variablene i det kjørende programmet vil forandre seg under testingen, og systemets tilstand vil være avhengig av databasens innhold. Det er viktig å identifisere hver enkelt transaksjon med en transakjonsid som er generert automatisk av databasesystemet. Systemloggen lagres regelmessig på disk og brukes for å gjenopprette tilstanden i databasen rett før feilsituasjonen oppstod [17]. 2.2 Testklassifisering Nedenfor har jeg tatt for meg to måter å gjennomføre test på, Black box- og White box testing Black Box Black box testing eller funksjonell testing er en testmetode der testen bygger på programmet eller komponentspesifikasjon. Under black box testing velger man tester ved å se på systemets eller komponentens grensesnitt og ikke på hvordan komponenten er realisert [1]. Black box [11]: Sterke sider: Lett å bevare fokus på og teste funksjonaliteten. Lett å automatisere testen ut fra kravspesifikasjonen. Svake sider: Kan ikke hjelpe oss når vi skal finne feil i koden White Box White box er en metode der testene bygger på kunnskap om programvarestrukturen og implementasjon. White box testing skjer når man velger tester ut fra hvordan systemet eller komponenten er realisert. Hensikten er å teste alle veier gjennom systemet [1]. White box [11]: Sterke sider: Kan teste alle veier og ta hensyn til spesielle forhold ved implementasjonen. Svake sider: Lett å fortape seg i detaljer ved implementasjonen og glemme funksjonaliteten. 5

9 2.3 Testfaser Testing er en aktivitet som vil foregå under hele utviklingsprosjektets levetid. Det er viktig å gjennomføre testing på flere nivåer for å avdekke feil og kvalitetssikre produktet. Typiske former for testing underveis er enhetstesting av kodemoduler, integrasjonstesting når man setter sammen flere moduler eller skal ha systemet til å fungere sammen med eksterne systemer, brukbarhetstesting for å avdekke problemer med brukergrensesnitt. Vi kan begynne å teste modulene etterhvert som de blir utviklet, for så å teste om den fungerer i samspill med resten av systemet som er utviklet. Dermed vil feil bli oppdaget på et så tidlig tidspunkt som 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 ihvertfall bruke de fire testfasene enhetstest, integrasjonstest, systemtest og akseptansetest. Det er vanlig å gjennomføre disse testfasene i den rekkefølgen som er vist i figur 2, og gjerne i flere iterasjoner. 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

10 Alle disse testene utføres når systemet lages første gang og ved enhver senere endring av systemet. Enhetstest og integrasjonstest utføres med White box testing, fordi testene gjerne forutsetter innsikt i systemets indre oppbygning. Metoder og verktøy for disse to testfasene er ofte ganske like, og det er ikke uvanlig at de flettes mer eller mindre sammen. Systemtest og akseptansetest utføres med Black box testing, fordi testene ikke skal forutsette innsikt i systemets indre oppbygning. Metoder og verktøy for disse to fasene er ofte ganske like, så i prosjekter med sterk brukermedvirkning er det derfor er det vanlig at de flettes mer eller mindre sammen [28] Modul/Enhetstest Enhetstest eller modultest er testing av en avgrenset del av et system separat. Enheten som tester en enkelt modul som f.eks. en klasse eller kildekodefil uten de andre enhetene som den normalt kommuniserer med Integrasjonstest Integrasjonstest er testing av grensesnittet mellom enheter eller moduler i et system. Denne testingen utføres med White box testing og tar utgangspunkt i både koden og designet. Integrasjonstesten skal ikke dekke all kode, og heller ikke all funksjonalitet. Den har fokus på det som ikke er med i enhetstestene, det vil si fokusere på at de enhetstestede modulene fungerer sammen som de skal [28]. Integrasjonstesten kan godt inneholde noe ad hoc testing i tillegg, og ad hoc testing betyr i denne sammenheng å teste brukergrensesnittet på tvers av enhetene som systemet er bygget opp av. Ad hoc testing bør tas med når man har integrert seg opp til et nivå med brukergrensesnitt Systemtest Systemtest består i å teste systemet som helhet, og grunnlaget for testingen er kravspesifikasjonen for systemet. Her tester man om systemet oppfører seg korrekt i samspill med omgivelsene, og denne testingen blir ofte utført av en egen testgruppe. Systemtest skal ikke bare teste funskjonelle kravene, men skal også inkludere ikke-funksjonelle tester [28]. 7

11 De typiske testene innen systemtest for websystemer er ytelsestest, sikkerhetstest, stresstest, recoverability-test og nettlesertest. For websystemer trenger man [11]: Funksjonell test for å sjekke om en modul tilfresstiller de eksterne kravene man har satt til den. Ytelsestest for å teste hastigheten for en transaksjon. Sikkerhetstest for å sikre systemet mot inntrengere. Stresstest for å teste hastigheten på mange samtidige transaksjoner. Nettlesertest for å sørge at systemet støtter alle versjoner av nettleserne. Recoverability-test for å sjekke systemets håndtering av uforutsette avbrudd Regresjonstest Regresjonstest betyr gjentagelse av en eller flere testfaser for å verifisere at feilrettinger eller endringer ikke har introdusert nye feil eller uønskede effekter [28]. Denne testingen skal samtidig sjekke at systemet fremdeles tilfredsstiller de spesifiserte kravene. Man kjører bare en utvalgt del av de aktuelle testfasene for å spare tid. Regresjonstest er nødvendig i forbindelse med feilretting under nyutvikling, eller når man senere lager nye utgaver av systemet Usability test Usability testing, eller brukbarhetstesten er testen for å finne ut hvor lett systemet er å forstå og bruke [31]. Ved å observere brukere under brukbarhetstesten vil man få tilbakemeldinger på hva som bør forbedres i eksisterende systemer. Man trenger brukbarhetstest for å teste designet mot virkeligheten, altså av reelle brukere Akseptansetest Akseptansetest blir ofte kalt for en alfa test, og hensikten med denne testen er å få systemet godkjent av kunden [35]. For at systemet skal bestå akseptansetest må systemet fungere i henhold til brukernes krav. Akseptansetest er nesten samme som systemtest, men her blir testingen utført av kunden. 8

12 3 Plassering av systemtesting i prosjektutviklingen Det finnes mange forskjellige systemutviklingsmodeller idag. Fossefallsmodell og inkrementellutvikling er de mest brukte i prosjektutvikling. Systemutviklingsmodellene gir en oversikt over faser, aktiviteter og milepæler til et IT-prosjekt [20]. I fossefallsmodellen deles prosjektene opp i forstudie, kravspesifisering, design, programmering og vedlikehold, mens inkrementell utvikling innebærer at et system utvikles trinnvis i flere iterasjoner [25]. Uansett hvilke modell man bruker i systemutvikling, så bør den inneholde disse fasene: 1. Forstudium 2. Kravspesifikasjon 3. Design 4. Programmering 5. Testing 6. Vedlikehold Når man har analysert kundekravene grundig og konstruert en logisk modell for systemet, vil det være mer sannsynlig at prosjektet lykkes. Det er vanlig å bruke de fire testtypene enhetstest, 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

13 3.1 Forstudium Forstudiet fokuserer på å avklare omfanget av systemet, slik at man kan finne ut hvor stor kostnad og tid det vil være for å utvikle et bestemt system. Man trenger denne fasen for å avgjøre om det er lønnsomt for organisasjonen å gå videre med prosjektet eller om den bør stoppes. Noen av hovedaktivitene i denne fasen er [12]: Å definere målsetning og omfang for systemet. Å lage et overordnet systembeskrivelse. Organisering av prosjektgruppen. Estimering av kostnader og tid. Utarbeide risikoliste. Å vurdere alternative løsninger. Planlegging av videre arbeid. 3.2 Kravspesifikasjon I denne fasen er det viktig å forstå kundekravene, og for å sjekke om man har forstått kunden riktig bør man tenke gjennom hva kunden ønsker seg, hvilke problemer som skal løses og hvordan man kan omforme kundekrav til systemkrav på best mulig måte. En annen viktig del av kravspesifikasjonen er sporing av kundekravene. Sporing fra kode til krav og omvendt kan være viktig for å skjønne implementasjonen, og det vil lett oppstå problemer dersom kravene ikke er entydig spesifisert. Det finnes mange krav, så det er vanlig å 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 Når man har analysert kundekravene, kan man gå til designfasen. I denne fasen er det viktig at man lager modeller som for eksempel systemstruktur på en forståelig måte, slik at programmerer realiserer løsningen. 10

14 3.4 Programmering I programmeringsfasen skal man utvikle programsystemet med fokus på å tilfredsstille kundekravene. Programmerere skal realisere løsningen ut fra designdokumentet, og noen oppgaver som programmerer må utføre er [18]: Utarbeide programmoduler Utføre refaktorering: refaktorering er en teknikk som går ut på minst mulig kostnad å endre på programkoden. Skrive kode for metoder 3.5 Testing Det er viktig å teste grundig for å sikre kvaliteten på produktet. Testtypene som finnes er beskrevet i kapittel 2.3, og det er i denne fasen systemtest blir utført. Det er nødvendig å dokumentere testene slik at man får oversikt over hva man har testet og hvilke problemer som oppstår under testingen. Man kan velge mellom automatisert- eller manuell systemtesting, og det er fortsatt mange som benytter manuell testing siden dagens automatiserte verktøy er tidkrevende. 3.6 Vedlikehold Det finnes flere typer vedlikehold : man retter feil, tilpasser til nye omgivelser, legger til ny funksjonalitet eller endre eksisterende funksjonalitet [36]. 11

15 4 Praktiske erfaringer med systemtest 4.1 Feilfinning Når man har funnet feil i en test, må man lete etter feilkilden og rette den opp [32]. Det kan være vanskelig å finne kilden til feilen, særlig når det er flere som har bidratt i kodingen. Det er derfor vanlig å innskrenke området for hvor feilkilden ligger ved å legge inn utskrifter med meldinger om hvor langt kjøringen av programmet har kommet istedenfor å gjøre mange omkompileringer [11]. Når man observerer rekkefølgen av utskriftene etter at feilen har oppstått, vil man ha en viss anelse hvor feilen kommer fra. Dette er en systematisk måte å gjøre dette på, men endelig har man etterhvert feilfinningsverktøy som gjør det enklere for de som programmerer. 4.2 Testplan Systemtestplan Før man skal utføre systemtesting, lønner det seg å lage en systemtestplan. Uansett hvilke metode man velger for systemtesting bør man lage testplan basert på IEEE-standard [15] som inneholder: sammendrag innledning målsetting for systemtesting testverktøy: hvilke hardware/software som brukes under systemtesting klassifisering av feil gradering av feil rapportprosedyre: Testresultatene tidspunkt og personer til å utføre testing ansvarsfordeling for godkjenning av testingen: se eksempel i tabell 1 Hvorfor trenger vi en testplan? Det er nyttig å ha en testplan for alle store prosjekter, siden dette letter koordinering med andre aktiviteter i prosjektet [11]. Når man har en testplan vet man hvem som er ansvarlig for hvilke aktiviteter, hva som skal testes og hvordan man skal kjøre testene. Testplan er spesielt nødvendig å ha dersom kostnaden eller risikoen ved å feile er stor. Tabell 1 er et eksempel på ansvarsfordelingen mellom prosjektmedlemmer. 12

16 Test Tid timer Ansvarlig Systemtest timer Hong Trang Thi Nguyen Brukbarhetstest timer Berit Eleni Sirris Akseptansetest timer Olav Engelsåstrø Tabell 1: Tabell som viser ansvarsfordeling 4.3 Testteam Testing blir en stadig viktigere del av det totale utviklingsprosjektet. Et av problemene med testingen er at man ikke har fått nok opplæring i testing. Det kan være vanskelig å sette seg inn i brukerens situasjon eller at det har vært dårlig 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 Når man har fullført en test, skal man skrive en rapport som oppsummerer resultatet av testingen. Rapporten bør beskrive de feilene som er funnet, for små prosjekt holder det med testlogg [19]. 4.5 Risikoanalyse Risikoanalysen innebærer at man går gjennom alle aktiviteter i prosjektet, og tenker på hva som kan gå galt, hvor sannsynlig er det og hvilke konsekvenser det vil få [1]. Risikoanalyse er nødvendig for å prøve å forhindre slike situasjoner og eventuelt sette tiltak hvis tilfellet skjer [9]. For å oppnå en god kvalitetssikring av systemet er det viktig å utføre risikoanalyse i testing, slik at bedrifter kan vurdere hvilke tiltak som må iverksettes dersom en avvik oppstår. Risikoanalyse hjelper til å kontrollere hvorvidt endringene eller tiltak vil påvirke systemet [21].Tabell 2 er et eksempel på hvordan man kan sette opp en iverk risikoanalyse. 13

17 R3 Forandringer i kravspesifikasjon fra kunde Nr Risiko Beskrivelse Sannsynlighet Alvorlighetsgrad Begrenset innsikt i R1 Gruppen mangler kunnskap og erfaring verktøy kan forsinke prosjektarbeid eller av Høy Middels prosessen R2 Forfall i gruppen Sykdom Høy Lav R3 Feil i estimering Undervurdering av tids- Høy Høy forbruk Må gjøre deler av prosjektet på nytt. Tabell 2: Tabell for risikoanalyse Lav Høy 4.6 Konfigurasjonshåndtering En konfigurasjon er en samling av alle komponentene til et system, og der hver komponent er representert med nøyaktig en versjon. Konfigurassjonsstyring skal håndtere endringer og ulike versjoner av komponenter, og den er basert på et sett av standarder [13]. En konfigurasjonsstyringsplan 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

18 5 Websystem Websystemer representerer en stadig økende teknologi med mange internett brukere. Det som er utfordrende for slike applikasjoner er å benytte testing til å sikre pålitelighet, sikkerhet, robusthet og høy ytelse. Hva er kjennetegnet til websystemer og hvilke områder man bør teste når man utvikler websystemer vil bli beskrevet i kapittel 5. Hvordan vi skiller systemtesting av websystemer fra tradisjonelle programvarer blir diskutert i kapittel Definisjon av websystem Websystem innebærer lagdelte applikasjoner som aksesseres via en webbrowser; standard HTTP-protokoll, og det er den store forskjellen fra tradisjonelle programvarer. Testingen av internettløsninger vil ha tilnærmet samme strategier og metoder som testing av grafiske brukergrensesnitt. Den første utfordringen for websystemer er testing av flere nettlesere, og det bør også testes på ulike operativsystemer. Testingen går ut på å sette opp et sett av inndata og forventede utdata basert på de gitte inndata. Deretter blir testen kjørt, og man ser om de oppnådde resultatene stemmer overens med de forventede resultatene [27]. En annen utfordring er presset til å ha en time-to-market som er kort som mulig. Testene som blir gjennomført vil da ha fokus på å oppdage feil som kan forårsake uakseptable oppførsel. Det er viktig å finne en god metode eller et verktøy til å måle robusthet i websystemet, noe som jeg har utelatt på grunn av begrensing av oppgaven. Målet for alle prosjekter er å levere en feilfri vare, men i tillegg til det vil websystemer fokuserer mye på høy kvalitet, ytelse og stabilitet. Det er derfor nødvendig å benytte stabilitetstest og stresstest for å finne hvor bra systemet takler når en mengde brukere blir koplet til systemet samtidig (skalerbarhet) [14]. 5.2 Struktur Websystemer innebærer klienter som for eksempel er kundens nettleser, og en eller flere fysiske servere som bidrar til flere typer av service [14]. En server kan for eksempel være en webserver eller databaseserver som inneholder alle data. En webservice er en samling av protokoller og standarder som brukes for å dele data mellom applikasjoner. En nettleser (browser) er et program som brukes til å vise innhold ifra internett, og all spørringer vil gå fra klienten til serveren [1]. Figur 5 viser en typisk struktur for et websystem: 15

19 Figur 4: Websystem arkitektur Et websystem skal være organisert som en bok med sider, og koblingen mellom sidene bør være logisk og lett og oppfatte [22]. Det er viktig å ha et forståelig og godt brukergrensesnitt, slik at brukeren kan finne fram til den han/hun leter etter uten å måtte gå via for mange sider med linker. Linker bør plasseres slik at brukeren lett finner dem, og for å fremheve dem kan man skille linkene tydelig fra annen tekst med farge eller grafiske symboler. 5.3 Krav til websystem Følgende faktorer er viktige når vi utvikler et nettsted [37]: 1. Time-to-market: Hvor fort kan produktet leveres? Tiden det tar fra å starte produktutviklingen til produktet er ferdigstilt og tilgjengelig på markedet. 2. Robusthet: Tåler systemet uventede problemer? Et robust system må bygges på en solid fundament for ikke å feile. 16

20 3. Understøttelse: Støtter systemet eksisterende standarder og ulike versjoner av nettlesere og operativsystemer? Det bør støtte eksisterende standarder og tilrettelegge for enkle oppgraderinger. 4. Brukervennlighet: Er det lett å forstå logikken i systemet? For at systemet i det hele tatt skal få noen brukere så må det være brukervennlig og intuitivt. Hvor brukervennlig er navigasjonen på nettstedet, og hvor klart og lett forståelig er budskapet? 5. Testbarhet: Kunne alle kravene testes i det ferdige systemet? Det bør også være lett å 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 sårbar for inntrengere? Systemet bør ha en beskyttelse mot hackere, og en måte man kan finne ut om systemet kan hackes på er å prøve hacke det selv. 8. Flyttbarhet: Kan systemet kjører på ulike plattformer? Systemet bør være flyttbarhet, det vil si at for eksempel klientene er web-browsere og at database løsningen kan flyttes fritt fra web-server til web-server. 17

21 6 Intervju med IT-bedrifter Oppgaven går ut på å finne gode metoder for systemtesting av websystemer og hvilke krav metodene må tilfredstille. For å vite mer om dagens bedrifter innen systemtesting, har jeg intervjuet to bedrifter for å undersøke hvilke metoder disse bedriftene benytter idag. Etter at metodeundersøkelsen er utført, skal jeg beskrive hvilke framgangsmåte og teknikker som er effektiv for systemtesting av websystemer i kapittel 8. Hensikten med intervjuene er å finne ut hvordan bedriftene jobber med systemtesting spesielt av websystemer, og hvilke krav de har til metode av systemtesting. Jeg har fulgt rådene for hvordan man bør lage og forberede et intervju fra Norsk Nettskole [16]. Det er viktig å være klar over hva du skal spørre om under intervjuet, derfor laget jeg en liste over alle de spørsmålene som skal stilles. Begge bedriftene får samme spørsmål å svare på, siden dette gjør det lettere å sammenligne svarene [9]. Først kontaktet jeg bedriftene for å avtale tidspunkt for intervjuet med IT-sjefen, så sendte jeg en til intervjuobjektene om hva dette går ut på slik at de kan forberede seg og eventuelt finne personalet som har kompetanse innenfor emnet. Det er viktig å finne generell info om bedriften og hvilket forhold intervjuobjektet har til systemtesting. Referat fra disse intervjuene ble sendt ut til intervjuobjektene for godkjennelse fra dem om at det som står der er riktig før jeg legger dem inn i prosjektrapporten min. I kapittel 6.1 og 6.2 er det en liten oppsummering fra disse to intervjuene, selve referatene har jeg lagt som vedlegg på slutten av denne rapporten. 18