TDT4735 Systemutvikling, fordypning. Metoder for systemtest av websystemer

Størrelse: px
Begynne med side:

Download "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

Livsløpstesting av IT-systemer

Livsløpstesting av IT-systemer Livsløpstesting av IT-systemer Testing, validering og evaluering Teste Undersøke ved hjelp av tester om systemet fungerer slik det er beskrevet Validere Bekrefte hvordan systemet virkelig fungerer, om

Detaljer

GJENNOMGANG UKESOPPGAVER 9 TESTING

GJENNOMGANG UKESOPPGAVER 9 TESTING GJENNOMGANG UKESOPPGAVER 9 TESTING INF1050 V16 KRISTIN BRÆNDEN 1 A) Testing viser feil som du oppdager under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil.

Detaljer

Validering og verifisering. Kirsten Ribu

Validering og verifisering. Kirsten Ribu Validering og verifisering Kirsten Ribu 2005 1 I dag Validering og verifisering Inspeksjon Testing 2 Noen ord om prosjektet Sjekk kurssidene jevnlig. Endringer forekommer (forelesningsplanen) Hvordan fungerer

Detaljer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesten Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesting Formell testing med hensyn til brukerbehov, krav, og forretningsprosesser som utføres for å avklare om et system oppfyller

Detaljer

TESTRAPPORT Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS

TESTRAPPORT   Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS TESTRAPPORT Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS Medlemmer av gruppe 35: Joakim Larsen, s150070, 3AB Kristian Kjelsrud, s147787, 3IA Anastasia Poroshina, s140720, 3AB Prosjektperiode:

Detaljer

Inf1055 Modul B 26 april 2017:

Inf1055 Modul B 26 april 2017: Inf1055 Modul B 26 april 2017: Del 1: - Testing Yngve Lindsjørn ynglin@ifi.uio.no 1 Oversikt - Testing Hva er testing? Validering &Verifisering Testfaser Enhetstesting Integrasjonstesting Systemtesting

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Prøveeksamen i: INF1050 Eksamensdag: 0. mai, 2011 Tid for eksamen: 00:00 00:00 Oppgavesettet er på 6 sider Vedlegg:

Detaljer

Systemutvikling - oppsummering. Alexander Nossum blog.eksplisitt.net 22. mai 2006

Systemutvikling - oppsummering. Alexander Nossum blog.eksplisitt.net 22. mai 2006 Systemutvikling - oppsummering Alexander Nossum alexander@nossum.net blog.eksplisitt.net 22. mai 2006 INNHOLD 2 Innhold 1 Utviklingsprosessmodeller 3 1.1 Fossefall/waterfall................................

Detaljer

Kort om evaluering og testing av It-systemer. Hvordan vurdere, verdsette, velge og teste?

Kort om evaluering og testing av It-systemer. Hvordan vurdere, verdsette, velge og teste? Kort om evaluering og testing av It-systemer Hvordan vurdere, verdsette, velge og teste? Evaluere - Bokmålsordboka Evaluere Vurdere, verdsette, gi karakter for. Vurdere Bedømme, verdsette. Bedømme Dømme

Detaljer

Statisk testing. Testing uten datamaskin, men med vår egen evne til å vurdere og analysere

Statisk testing. Testing uten datamaskin, men med vår egen evne til å vurdere og analysere Statisk testing Testing uten datamaskin, men med vår egen evne til å vurdere og analysere Hva er statisk testing Analyser som utføres på skrevne dokumenter Hensikten er å finne avvik fra spesifikasjonene

Detaljer

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR INF 1050 UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR Oppgave 1 a) Foranalyse: Foranalysen kan med fordel gjøres i to trinn. Den første er å undersøke finansiering og øvrige

Detaljer

Grunnleggende testteori

Grunnleggende testteori 1 Grunnleggende testteori Industri - og software produkt Industriprodukt: Fysisk produkt Testes under produksjon og til slutt om produktet oppfyller kravene Tilpasses, endres, redesignes, og justeres så

Detaljer

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser 1 Ulike typer prosessmodeller Systemutvikling Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu 19.05.2004 De røde er viktige i kurset: Evolusjonær (prototyping) Inkrementell (RUP) XP fossefall

Detaljer

Grunnleggende testteori

Grunnleggende testteori 1 Grunnleggende testteori Error-Fault-Failure 2 Error : når en programmerer koder feil eller utelater kode (evt. miljøpåvirkning) årsaken til en fault Fault (defect eller bug): feil i kode kan lede til

Detaljer

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas Prosjekt nr. 2011 22 Testrapport Hovedprosjektets tittel Implementering av plugin og utvikling av wizard for Det Norske Veritas Prosjektdeltakere Magnus Strand Nekstad s156159 Jørgen Rønbeck s135779 Dato

Detaljer

Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu

Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu Systemutvikling Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu 19.05.2004 1 Ulike typer prosessmodeller De røde er viktige i kurset: Evolusjonær (prototyping) Inkrementell (RUP) XP fossefall

Detaljer

Grunnleggende testteori. Etter Hans Schaefer

Grunnleggende testteori. Etter Hans Schaefer Grunnleggende testteori Etter Hans Schaefer Industri- og softwareprodukt Industriprodukt Fysisk produkt Testes under produksjon og til slutt om produktet oppfyller kravene Tilpasses, endres, redesignes,

Detaljer

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kirsten Ribu beskriver kravene til systemet,

Detaljer

Kirsten Ribu

Kirsten Ribu Validering og verifisering Kirsten Ribu 03.03.04 1 I dag Validering og verifisering Prototyping Inspeksjon Testing 2 Validering og verifisering Å sørge for at et datasystem tilfredsstiller brukerens behov

Detaljer

GJENNOMGANG UKESOPPGAVER 7 REPETISJON

GJENNOMGANG UKESOPPGAVER 7 REPETISJON GJENNOMGANG UKESOPPGAVER 7 REPETISJON INF1050 V16 KRISTIN BRÆNDEN DAGENS TEMA Oppgaver hentet fra tidligere eksamensoppgaver om temaene vi har gått gjennom til nå DAGENS PLAN Gjennomgang av oppgaver Repetisjon

Detaljer

Krav som bør stilles til leverandørens verifikasjon og test

Krav som bør stilles til leverandørens verifikasjon og test Krav som bør stilles til leverandørens verifikasjon og test Av Hans Schaefer Versjon 1.2, 14.9.2005 Dette dokument beskriver krav en bør stille til verifikasjon under utviklingen og test hos en seriøs

Detaljer

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen Hensikten med denne delen av kurset Objektorientert systemutvikling Rational Unified Process (RUP) Gurholt og Hasle kap. 6 UML Distilled kap. 2 Å lære modellerings- og designprinsipper og øve opp teknikker

Detaljer

Kravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo,

Kravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, Kravspesifikasjon Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 12.01.2013 Public 2013 Aker Solutions Page 1 of 7 Table of Contents Forord... 3 Om bakgrunnen... 3 Presentasjon...

Detaljer

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case?

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? 1/15/2004 1 Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kapittel 8 i Gurholt og Hasle Kirsten

Detaljer

Overordnet Testplan. MUSIT Ny IT-arkitektur, Pilot og Hovedprosjekt. Page 1 of 11

Overordnet Testplan. MUSIT Ny IT-arkitektur, Pilot og Hovedprosjekt. Page 1 of 11 Overordnet Testplan MUSIT Ny IT-arkitektur, Pilot og Hovedprosjekt Page 1 of 11 Innhold 1 Innledning... 4 1.1 Hensikten med dette dokumentet... 4 1.2 Grensesnitt.... 4 1.3 Omfang av dokumentet... 4 1.4

Detaljer

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås,

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, System integration testing Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, Innhold Presentasjon Hva er integration testing (pensum) Pros og cons med integrasjonstesting Når bruker vi integration

Detaljer

Testing av programvare. INF1050: Gjennomgang, uke 08

Testing av programvare. INF1050: Gjennomgang, uke 08 Testing av programvare INF1050: Gjennomgang, uke 08 Kompetansemål Testing av programvare Hva og hvorfor? Testfaser Ulike nivåer Testtyper Spesifikasjonsbasert testing / Strukturbasert testing Testdrevet

Detaljer

Finansportalen Historiske bankdata

Finansportalen Historiske bankdata Bilag 5: Testing og godkjenning For Finansportalen Historiske bankdata Bilag 5 Testing og godkjenning Innholdsfortegnelse 1.1 OMFANG... 3 1.1.1 Systemtest 3 1.1.2 Godkjenningsprøve 3 1.2 GJENNOMFØRING...

Detaljer

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011 TESTRAPPORT Forord Denne testrapporten har som formål å beskrive all testing som er utført på systemet, både under utviklingen og etter ferdigstilling. Målet for testingen er for å verifisere at vi har

Detaljer

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk Produktdokumentasjon Madison Møbler Administrasjonsside og Nettbutikk 1 1. Forord 1.1 Dokumentasjonen Dette er en teknisk dokumentasjon på produktet som er utviklet. Denne er tiltenkt personer med teknisk

Detaljer

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser?

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser? UML Use case drevet analyse og design 31.01.2005 Kirsten Ribu I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 1 2 Domenemodell visualisering

Detaljer

Lykke til! Eksamen i fag SIF8018 Systemutvikling. 20 mai, 2003 kl 0900-1400. Fakultet for fysikk, informatikk og matematikk

Lykke til! Eksamen i fag SIF8018 Systemutvikling. 20 mai, 2003 kl 0900-1400. Fakultet for fysikk, informatikk og matematikk NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: XX Eksamen i fag SIF8018 Systemutvikling

Detaljer

ISTQB Foundation Level Prøveeksamen

ISTQB Foundation Level Prøveeksamen ISTQB Foundation Level Prøveeksamen Svar på følgende spørsmål For hvert spørsmål er der ETT og BARE ETT rett svar! (Unntak er avmerket spesielt). Spørsmål til Kap 1 ("Fundamentals") 1.1. (K2) Hva er betydningen

Detaljer

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG INF1050 V16 HVA ER EN SYSTEMUTVIKLINGSPROSESS? De aktivitetene som utføres for å utvikle et IT-system Eksempler på aktiviteter:

Detaljer

Testbilag til IT kontrakter

Testbilag til IT kontrakter Testbilag til IT kontrakter Grunner til å lage dette testbilaget Unngår å diskutere de samme problemstillingene i hver kontrakt testfaglige selvfølgeligheter blir landet av testfaglig personell en gang

Detaljer

Test i Praksis. NTNU Februar 2014. Copyright 2014 Accenture All Rights Reserved.

Test i Praksis. NTNU Februar 2014. Copyright 2014 Accenture All Rights Reserved. Test i Praksis NTNU Februar 2014 Hvem er vi? Erik Gjerdrum Master i Kommunikasjonssystemer fra IFI UiO Jobbet med test i siden 2006 Markus Living Master i Industriell Økonomi fra Linköping, Sverige Jobbet

Detaljer

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO DRI 2001 13.9 : Introduksjon til systemutvikling. Introduksjon til systemutvikling Systemutvikling og nettstedsutvikling Om ulike typer offentlige nettsteder Kvalitetskrav til offentlige nettsteder Litt

Detaljer

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 29.04.2009. IMT2243 : Systemutvikling 1

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 29.04.2009. IMT2243 : Systemutvikling 1 Oppsummering : IMT2243 Systemutvikling Målformuleringen i emnebeskrivelsens : Studentene skal ha forståelse for grunnleggende administrative og teknologiske aspekter ved spesifisering, utvikling, innføring

Detaljer

Oppsummering. Thomas Lohne Aanes Thomas Amble

Oppsummering. Thomas Lohne Aanes Thomas Amble Oppsummering Thomas Lohne Aanes Thomas Amble 14.11.04 Kapittel 2: Data Modell Mål: Data som skal brukes av applikasjonen blir spesifisert på en formell og likevel intuitiv måte. Resultat: Vi får et konseptuelt

Detaljer

BlackBox, WhiteBox og andre testmetoder. Etter ønske fra studentene 26. november 2009

BlackBox, WhiteBox og andre testmetoder. Etter ønske fra studentene 26. november 2009 BlackBox, WhiteBox og andre testmetoder Etter ønske fra studentene 26. november 2009 Hva er testing? Testing er å undersøke IT-systemer eller deler av det for å vurdere om kravene til det som testes er

Detaljer

Kravhåndtering. INF1050: Gjennomgang, uke 03

Kravhåndtering. INF1050: Gjennomgang, uke 03 Kravhåndtering INF1050: Gjennomgang, uke 03 Kompetansemål Kravhåndtering Anvende metoder og teknikker for å Innhente / Analysere / Spesifisere krav Ulike typer krav Funksjonelle krav Ikke-funksjonelle

Detaljer

Kvalitet og programvare. Når bare det beste er godt nok. Produktet prosessen eller begge deler?

Kvalitet og programvare. Når bare det beste er godt nok. Produktet prosessen eller begge deler? Kvalitet og programvare Når bare det beste er godt nok. Produktet prosessen eller begge deler? To nøtter Hva forbinder du med et IT-system som har (høy) kvalitet? Formuler 3 kriterier for (høy) kvalitet

Detaljer

Prøv å skrive alle svar på alle spørsmål i det tomme rom i disse sidene. Hvis du trenger mer plass, bruk ekstra sider.

Prøv å skrive alle svar på alle spørsmål i det tomme rom i disse sidene. Hvis du trenger mer plass, bruk ekstra sider. 1 For hver del, alle sub deler teller likt. Prøv å skrive alle svar på alle spørsmål i det tomme rom i disse sidene. Hvis du trenger mer plass, bruk ekstra sider. For hvert spørsmål, hvis du trenger å

Detaljer

Kapittel 7 & 8. Kravspesifikasjoner & Data design. Thomas Tjøstheim og Thomas Edvinsen. 20 September Kapittel 7 & 8 p.1/20

Kapittel 7 & 8. Kravspesifikasjoner & Data design. Thomas Tjøstheim og Thomas Edvinsen. 20 September Kapittel 7 & 8 p.1/20 Kapittel 7 & 8 p.1/20 Kapittel 7 & 8 Kravspesifikasjoner & Data design Thomas Tjøstheim og Thomas Edvinsen 20 September 2004 Kapittel 7 & 8 p.2/20 Introduksjon Kravspesifikasjoner består av to underdeler:

Detaljer

A tool for collaborating to success in a development project Experience with Visual Studio 2010 and Test Manager at Lånekasse

A tool for collaborating to success in a development project Experience with Visual Studio 2010 and Test Manager at Lånekasse A tool for collaborating to success in a development project Experience with Visual Studio 2010 and Manager at Lånekasse 21.mars.2013 Heza Wasfy Hvem er Sogeti? Sogeti Norge er et heleid datterselskap

Detaljer

Innholdsfortegnelse. 1. Testing Feiltesting av koden Funksjonstesting: Kilder.10

Innholdsfortegnelse. 1. Testing Feiltesting av koden Funksjonstesting: Kilder.10 1 Innholdsfortegnelse 1. Testing... 3 1.1 Feiltesting av koden... 3 1.2 Funksjonstesting:... 7 2. Kilder.10 2 1. Testing Testing av et system er nødvendig for å finne ut om systemet fungere slik det skal

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Kravspesifikasjonen skal beskrive applikasjonens funksjonalitet og betingelsene som oppdragsgiver krever. Det skal også hjelpe utviklerne med å begrense applikasjonen slik at den

Detaljer

Forfattere: Daníelsdóttir, Drífa Meland, Maiken Mijalkovic, Biljana Svendsen, Simen H. Gruppelærer: Zarei, Amir Hossein. 5.

Forfattere: Daníelsdóttir, Drífa Meland, Maiken Mijalkovic, Biljana Svendsen, Simen H. Gruppelærer: Zarei, Amir Hossein. 5. 2 Forfattere: Daníelsdóttir, Drífa Meland, Maiken Mijalkovic, Biljana Svendsen, Simen H. Gruppelærer: Zarei, Amir Hossein 5. april 2017 Innhold 1 Klassediagram 2 Sekvensdiagram 2.1 Oppgave 2a 2.2 Oppgave

Detaljer

Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling

Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling Innledning Læringsmål Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling 21.1.2009 Forstå hvorfor systemutviklingsprosessen er viktig Forstå de viktigste prinsippene for ulike prosesser

Detaljer

Kostnadseffektivt eller bortkastet tid? Øyvind Woll Seniorkonsulent, Vivento AS

Kostnadseffektivt eller bortkastet tid? Øyvind Woll Seniorkonsulent, Vivento AS Kostnadseffektivt eller bortkastet tid? Øyvind Woll Seniorkonsulent, Vivento AS Input Output Hvordan kan vi fastslå om systemet er testbart? Hvordan kan vi lære mer om systemet? Hvordan kan vi bli bedre

Detaljer

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu UML 1 Use case drevet analyse og design 20.01.2004 Kirsten Ribu 1 I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 2 Domenemodell visualisering

Detaljer

Modernisering av IKT i NAV

Modernisering av IKT i NAV Modernisering av IKT i NAV Test, Leverandørperspektiv Vedtaksløsningen 28.05.13 Kristian Bjerke-Gulstuen Innhold Kort introduksjon til Moderniseringsprogrammet i NAV Overordnet oversikt over test i NAV

Detaljer

Test og kvalitet To gode naboer. Børge Brynlund

Test og kvalitet To gode naboer. Børge Brynlund Test og kvalitet To gode naboer Børge Brynlund To gode naboer som egentlig er tre Kvalitetssikring, kvalitetskontroll og testing Kvalitet I Betydningen Kvalitet er den viktigste faktoren for å avlede langsiktig

Detaljer

UKE 14 Versjonshåndtering og testing. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

UKE 14 Versjonshåndtering og testing. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski UKE 14 Versjonshåndtering og testing Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski UKENE FREMOVER OBS! Ikke forelesning 17. mai ikke gruppetime 19. og 23. mai Felles gruppetime for alle fredag

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 31. Mai, 2011 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 6 sider Vedlegg:

Detaljer

Løsningsforslag Sluttprøve 2015

Løsningsforslag Sluttprøve 2015 Høgskolen i Telemark Løsningsforslag Sluttprøve 2015 Emne: IA4412 Systemutvikling og dokumentasjon Fagansvarlig: Hans- Petter Halvorsen, Olav Dæhli Klasse: IA2, A- vei Dato: 2015.05.27 Time: 09:00-12:00

Detaljer

Testing av programvare

Testing av programvare Inf1050 07 mars 2017: Testing av programvare Yngve Lindsjørn ynglin@ifi.uio.no 1 Oversikt Hva er testing? Validering &Verifisering Testfaser Enhetstesting Integrasjonstesting Systemtesting Akseptansetesting

Detaljer

Oppgraderinger i SAP. Planlegge, organisere og gjennomføre en oppgradering til ECC 5.0/ECC 6.0. Sveinung Gehrken

Oppgraderinger i SAP. Planlegge, organisere og gjennomføre en oppgradering til ECC 5.0/ECC 6.0. Sveinung Gehrken Oppgraderinger i SAP Planlegge, organisere og gjennomføre en oppgradering til ECC 5.0/ECC 6.0. Sveinung Gehrken Gehrken Systems Agenda Vurdere 1 2 oppgradering 4 Erfaringer og hjelpemidler Planlegge oppgradering

Detaljer

4.1. Kravspesifikasjon

4.1. Kravspesifikasjon 4.1. Kravspesifikasjon Dette delkapittelet beskriver nærgående alle deler av systemet, hvordan det er tenkt ferdigutviklet med fokus på oppdragsgivers ønsker. 4.1.1. Innledning Informasjon om hvordan kravspesifikasjonens

Detaljer

Produktrapport Gruppe 9

Produktrapport Gruppe 9 Forord Dette dokumentet er ment for personer som skal vedlikeholde, endre eller utvikle systemet. Produktdokument innholder informasjoner om programmets funksjoner og hvordan de fungerer. Før bruk av dette

Detaljer

Eksamen i fag TDT4140 Systemutvikling. 22. mai, 2008 kl 0900-1300

Eksamen i fag TDT4140 Systemutvikling. 22. mai, 2008 kl 0900-1300 Side 1 av 11 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: 15. juni, 2008 Eksamen

Detaljer

Kirsten Ribu

Kirsten Ribu Validering og verifisering Kirsten Ribu 03.03.04 1 I dag Om prosjektet Validering og verifisering Prototyping Inspeksjon Testing 2 Prosjektet Status: Bra framgang Solid arbeid Roller: Definer rollene tydelig.

Detaljer

Brukbarhet ved benyttelse av fri programvare i systemutvikling - en praktisk studie

Brukbarhet ved benyttelse av fri programvare i systemutvikling - en praktisk studie Brukbarhet ved benyttelse av fri programvare i systemutvikling - en praktisk studie Tarjei Eriksen Ormestøyl Anders Kløvrud Rognstad Master i datateknikk Oppgaven levert: Juni 2010 Hovedveileder: Dag Svanæs,

Detaljer

Kap 11 Planlegging og dokumentasjon s 310

Kap 11 Planlegging og dokumentasjon s 310 Kap 11 Planlegging og dokumentasjon s 310 11.1 Ulike arbeidsmetoder Systemutvikling Som systemutvikler er du i stand til å omsette din innsikt i brukerbehov til praktiske programbaserte løsninger. Samarbeid:

Detaljer

BRUKERMANUAL. Telsys Online Backup

BRUKERMANUAL. Telsys Online Backup BRUKERMANUAL Telsys Online Backup TELSYS AS - 06.08.2009 Innhold Generelt... 3 Kom i gang... 4 Installasjon av Telsys Online Backup Proff/Standard... 4 Start opp klienten for første gang!... 10 Logg inn...

Detaljer

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5 Testrapport Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 24.5.2013 Public 2013 Aker Solutions Page 1 of 5 Innledning I denne rapporten vil vi skrive om testingen som

Detaljer

AP226 Use Case Diagram - TUL

AP226 Use Case Diagram - TUL AP226 Use Case Diagram - TUL Use Case Diagram Dette dokumentet inneholder det komplette use case-diagrammet for Tjenesteutviklingsløsningen. Figur 1 har en grafisk oversikt over alle aktører og use case.

Detaljer

Repository Self Service. Hovedoppgave våren 2010

Repository Self Service. Hovedoppgave våren 2010 Forprosjektrapport for Repository Self Service Hovedoppgave våren 2010 Christer Berg (070604 07HBDRA) Ron Stangvik (070427 07HBDRA) 1 Innholdsfortegnelse 1. MÅL OG RAMMER...3 1.1. Bakgrunn...3 1.2. Prosjektmål...3

Detaljer

Oppgave 1. Finn krav. Finn krav. Finn test

Oppgave 1. Finn krav. Finn krav. Finn test Oppgave 1 1. Hensikten med use case er å oppnå en felles forståelse av krav til systemet mellom brukere / kunder og utviklere. Et use case er et scenario, ikke en komplett, deltaljert kravspesifikasjon.

Detaljer

Test Beskrivelse Resultat Innhenting CBIS Programmet mottar data fra CBIS OK, men kun. Innhenting Tellus Programmet mottar data fra Tellus OK

Test Beskrivelse Resultat Innhenting CBIS Programmet mottar data fra CBIS OK, men kun. Innhenting Tellus Programmet mottar data fra Tellus OK Forord Denne testrapporten beskriver testingen som har blitt utført i løpet av prosjektet. Vi har gjennom hele utviklingsprosessen testet koden manuelt ved hjelp av debugging og ved kjøring med sammenligning

Detaljer

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 VERSJON: PROSJEKTPLAN (1.0) 24. SEPTEMBER, 2004 prosjektplan.doc GRUPPE 12 PROSJEKTPLAN: PROSJEKTLEDELSE: USE CASE: KVALITETSSIKRING: ANDRÉ

Detaljer

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning Systemutviklingsarbeidet et overblikk DRI2001 forelesning 12. sept. 06 Forholdet mellom informasjonssystemet og virkeligheten Hva innebærer utvikling av et IS (systemutvikling: SU) Å utvikle et IS det

Detaljer

Erfaring med funksjonell testing i en integrert ALM prosess

Erfaring med funksjonell testing i en integrert ALM prosess Erfaring med funksjonell testing i en integrert ALM prosess Forutsetninger for å kunne gjennomføre effektiv test Høy testdekning ved hjelp av regresjonstesting Feilhåndtering gjennom hele livssyklusen

Detaljer

Krav. Beskriver tjenestene produktet skal håndtere Kravene kan testes

Krav. Beskriver tjenestene produktet skal håndtere Kravene kan testes Krav og terminologi Krav Et utsagn som gjelder produktet vi skal teste og evaluere. Vi skal vurdere graden av sannhet i kravet opp mot funksjonen i produktet Funksjonelle krav Beskriver tjenestene produktet

Detaljer

Konfigurasjonsstyring. INF1050: Gjennomgang, uke 11

Konfigurasjonsstyring. INF1050: Gjennomgang, uke 11 Konfigurasjonsstyring INF1050: Gjennomgang, uke 11 Kompetansemål Konfigurasjonsstyring Hva og hvorfor? I en smidig sammenheng Endringshåndtering Versjonhåndtering Systembygging Release -håndtering Del

Detaljer

Presentasjon 1, Requirement engineering process

Presentasjon 1, Requirement engineering process Presentasjon 1, Requirement ing process Prosessodeller Hvorfor bruke prosessmodeller? En prosessmodell er en forenklet beskrivelse av en prosess En prosessmodell er vanligvis lagd ut fra et bestemt perspektiv

Detaljer

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning Systemutviklingsarbeidet et overblikk DRI2001 forelesning 21. sept. 05 Informasjonssystem og datasystem Hva er systemutvikling (SU) Et enkelt eksempel å bygge et hus Rammer og perspektiver for SU-arbeidet

Detaljer

UML-Unified Modeling Language

UML-Unified Modeling Language UML-Unified Modeling Language Use case realisering Designmodellering 21.01.2004 Kirsten Ribu Use Case diagram Klassediagram Oppførselsdiagrammer: Sekvensdiagram Kollaborasjonsdiagram Tilstandsdiagram Aktivitetsdiagram

Detaljer

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO Høgskolen i Telemark 2 Lars- Martin Hejll Høgskolen I Telemark Oppgave 1 Spørsmål fra pensum (20%) 1. Nødvendige aktiviteter i systemutvikling:

Detaljer

Characteristics of a good design

Characteristics of a good design Characteristics of a good design (PPT. side 1) Innledning Høykvalitetsdesign bør ha visse karakteristikker for å oppnå kvalitetsprodukter, dvs.: enkelt å forstå enkelt å implementere enkelt å teste enkelt

Detaljer

Testrapport for Sir Jerky Leap

Testrapport for Sir Jerky Leap Jasmine Garry (s135600) Line Sørensen (s135590) Fredrik Hoem Grelland (s135595) Tor Anders Gustavsen (s127668) 1 1. Forord Dette dokumentet inneholder informasjon og redegjøring av tester foretatt i forbindelse

Detaljer

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006 Forstudierapport Magne Rodem og Jan-Erik Strøm 18. juni 2006 Innhold 1 Introduksjon 3 2 Bakgrunn for prosjektet 3 2.1 Beskrivelse av problemer og behov........................... 3 2.2 Kort om dagens systemer................................

Detaljer

Kvalitet i programvaresystemer Dokumentasjon av tester

Kvalitet i programvaresystemer Dokumentasjon av tester Kvalitet i programvaresystemer Dokumentasjon av tester Dette notatet handler om dokumentasjon av tester. Gjennom utforming og gjennomføring av tester søker man å avdekke så mange feil i et program som

Detaljer

Elhub Strategi Aktørtesting

Elhub Strategi Aktørtesting Elhub Strategi Aktørtesting Versjon 2.0 29.septemper 2016 Innholdsfortegnelse 1 Introduksjon... 2 1.1 Endringslogg... 2 2 Definisjoner... 2 3 Om aktørtesting... 3 3.1 Formål... 3 3.2 Deltakere... 3 3.3

Detaljer

UKE 11 UML modellering og use case. Gruppetime INF1055

UKE 11 UML modellering og use case. Gruppetime INF1055 UKE 11 UML modellering og use case Gruppetime INF1055 Hva skal vi i dag? Analyse og design - kapittel 5 og 7 UML modellering Ukesoppgaver 3: Modellering av krav UML UML Kompetansemål Modellering av krav

Detaljer

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 2 Hovedprosjekt 2014, Høgskolen i Oslo og Akershus 1 INNHOLD 2 Presentasjon... 2 2.1 Gruppen medlemmer... 2 2.2 Oppgave... 2 2.3 Oppdragsgiver... 2 2.4 Veileder... 2 3 Sammendrag...

Detaljer

KRAVSPESIFIKASJON FOR SOSIORAMA

KRAVSPESIFIKASJON FOR SOSIORAMA KRAVSPESIFIKASJON FOR SOSIORAMA Innhold 1. Forord... 2 2. Definisjoner... 3 3. Innledning... 4 3.1 Bakgrunn og formål... 4 3.2 Målsetting og avgrensninger... 4 4. Detaljert beskrivelse... 8 4.1 Funksjonelle

Detaljer

Modellering av krav. INF1050: Systemutvikling 11. februar 2015. Universitetslektor Yngve Lindsjørn

Modellering av krav. INF1050: Systemutvikling 11. februar 2015. Universitetslektor Yngve Lindsjørn INF1050: Systemutvikling 11. februar 2015 Modellering av krav Universitetslektor Yngve Lindsjørn INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 1 Temaer i dagens forelesning Modellering

Detaljer

Prosjektet - leveranser. Testing og evaluering av systemer. Hva er sikkerhetskritiske systemer? I dag: Systemfeil og testing. Robust kraftforsyning?

Prosjektet - leveranser. Testing og evaluering av systemer. Hva er sikkerhetskritiske systemer? I dag: Systemfeil og testing. Robust kraftforsyning? Testing og evaluering av systemer Kirsten Ribu 23.10.2007 Prosjektet - leveranser Utfyll prosjektplanen etterhvert: Estimat Risikoplan Kravspesifikasjon Roller og arbeidsoppgaver Lag mappe med gruppenavn,

Detaljer

Vedlegg Brukertester INNHOLDFORTEGNELSE

Vedlegg Brukertester INNHOLDFORTEGNELSE Vedlegg Brukertester INNHOLDFORTEGNELSE Vedlegg Brukertester... 1 Testrapport Wireframe... 2 1. INTRODUKSJON... 2 1.1 Systemoversikt... 2 1.2 Meningen med testen... 2 2 TESTPLAN... 2 2.1 Funksjoner som

Detaljer

KTN1 - Design av forbindelsesorientert protokoll

KTN1 - Design av forbindelsesorientert protokoll KTN1 - Design av forbindelsesorientert protokoll Beskrivelse av A1 A1 skal tilby en pålitelig, forbindelsesorientert tjeneste over en upålitelig, forbindelsesløs tjeneste A2. Det er flere ting A1 må implementere

Detaljer

Studentdrevet innovasjon

Studentdrevet innovasjon Studentdrevet innovasjon Hovedprosjekt 2013 Høgskolen i Oslo og Akershus Forprosjektrapport av Gruppe 11 Karoline Sanderengen, Mona Isabelle Yari og Randi Ueland 25.01.2013 Studentdrevet innovasjon 9 Innhold

Detaljer

Oppgave 1 Multiple Choice

Oppgave 1 Multiple Choice Oppgave Multiple Choice a 2c 3a 4c 5d 6d 7a 8b 9b 0a b 2c 3c 4a 5b 6b 7a 8d 9c 20b Se video fra forelesningen (Kahoot) for mer detaljer) Eksamen INF050-204 Oppgave 2 a Aktivitetsdiagram Enkelt Eksamen

Detaljer

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen.

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen. Artist webside Innhold Artist webside...1 Gruppe medlemmer...1 Oppdragsgiver...1 Kontaktperson...2 Veileder...2 Oppgaven...2 Muligheter...2 Sammendrag...2 Dagens situasjon...2 Mål og rammebetingelser...3

Detaljer

Forslag til ny læreplan for informatikk studieretningsfag

Forslag til ny læreplan for informatikk studieretningsfag Forslag til ny læreplan for informatikk studieretningsfag Jens Kaasbøll, undervisningsleder, Institutt for Informatikk Foredrag på Faglig-pedagogisk dag Universitetet i Oslo, 4. januar 2000 1 Behov for

Detaljer

Agenda. TDT4140: Kravinnhenting. Kravprosessen Forståelsesproblemet Teknikker for innhenting av krav. Den organisatoriske dimensjonen

Agenda. TDT4140: Kravinnhenting. Kravprosessen Forståelsesproblemet Teknikker for innhenting av krav. Den organisatoriske dimensjonen TDT4140: Kravinnhenting Torbjørn Skramstad IDI / NTNU Introduksjon til objektorientert design Agenda Kravprosessen Forståelsesproblemet Teknikker for innhenting av krav Intervju Scenarier Etnografi Eksempel

Detaljer

1. Hvilke type krav angår sikkerhet og pålitelighet?

1. Hvilke type krav angår sikkerhet og pålitelighet? 1. Hvilke type krav angår sikkerhet og pålitelighet? a) Funksjonelle b) Ikke-funksjonelle Svar: b) 2. Verdien av etnografi er at den hjelper til å oppdage som reflekterer hvordan folk faktisk jobber a)

Detaljer

Kontrakter og test i smidige prosjekter. Fagmøte Dataforeningen i Trondheim 12.Mars 2012

Kontrakter og test i smidige prosjekter. Fagmøte Dataforeningen i Trondheim 12.Mars 2012 Kontrakter og test i smidige prosjekter Fagmøte Dataforeningen i Trondheim 12.Mars 2012 Agenda Smidige manifest Smidige prosjekter og testing Samarbeid og tillit teori Hva er en kontrakt Gjennomgang av

Detaljer

Kandidat nr. 1, 2 og 3

Kandidat nr. 1, 2 og 3 Kandidat nr. 1, 2 og 3 Rapport 1 IT202E Bacheloroppgave i Informatikk Vår 2011 Mobilapplikasjonsutvikling med Scrum 1 Innhold Innledning... 3 Overordnet Prosjektplan... 3 Produktbacklog... 5 Sprint planning

Detaljer

PROSJEKTBESKRIVELSE. Morten Ohren STUDENTNUMMER

PROSJEKTBESKRIVELSE. Morten Ohren STUDENTNUMMER PROSJEKTBESKRIVELSE Morten Ohren STUDENTNUMMER Innhold Bakgrunn... 2 Behov... 2 Om Eiendomsdrift SA... 2 Idèvurdering... 2 Personlig input... 2 Forutsetninger og rammeverk... 2 Tid... 2 Ressurser og materiell...

Detaljer