Testing av programvare. INF1050: Gjennomgang, uke 08

Størrelse: px
Begynne med side:

Download "Testing av programvare. INF1050: Gjennomgang, uke 08"

Transkript

1 Testing av programvare INF1050: Gjennomgang, uke 08

2 Kompetansemål Testing av programvare Hva og hvorfor? Testfaser Ulike nivåer Testtyper Spesifikasjonsbasert testing / Strukturbasert testing Testdrevet utvikling

3 Bakgrunn for testing Hva er testing? Hvorfor er testing viktig? De syv testprinsippene

4 Testing: Hva og hvorfor? Testing Utforsker et system / systemkomponenter for å avdekke feil eller mangler Nødvendig for kvalitetssikring av et system Sørge for at systemet som bygges holder høy standard Etablere gode kunderelasjoner Påser at systemet innfrir funksjonelle og ikke-funksjonelle krav Forsikre seg om at man har laget det man skal lage, og på en god måte Økonomisk gevinst Avdekking av feil under utvikling er ofte rimeligere enn når systemet er tatt i bruk Et svært viktig tema i systemutvikling!

5 De syv testprinsippene 1. Testing viser feil Testing kan bare vise at feil / defekter eksisterer Testing kan ikke bevise at et program er feilfritt 2. Fullstendig testing er umulig Det er umulig å teste alt Kan ikke teste alle mulige kombinasjoner mellom input og betingelser 3. Tidlig testing Testing bør starte så tidlig som mulig i utviklingsprosessen Testinnsatsen bør fokuseres på tydelig definerte mål

6 De syv testprinsippene 4. Konsentrasjon av feil (defect clustering) Et samlet mindretall av komponenter / moduler inneholder de fleste feilene Feil er ikke jevnt fordelt i kildekoden Noen komponenter er mer komplekse å utvikle enn andre Enkelte utviklere kan være mindre kompetente og dermed produsere flere feil 5. Plantevernmiddelparadokset (pesticide paradox) Hvis de samme testene kjøres gang på gang, vil de til slutt ikke finne flere feil Tester bør oppdateres og tilpasses jevnlig Nye tester bør inkluderes ved behov Øker sannsynligheten for å oppdage ytterligere feil i systemet

7 De syv testprinsippene 6. Testing er kontekstavhengig Testinnsatsen avhenger av konteksten Ulike systemer bør testes på ulike måter Testfokus varierer fra system til system Eksempel: Sikkerhetskritiske system testes ikke på samme måte som trivielle spill 5. Fravær av feil -fellen Et feilfritt system er ikke nødvendigvis et brukbart system Validering Bygger vi det riktige produktet? Verifisering Bygger vi produktet riktig?

8 Gjennomgang av ukesoppgaver Ukens tema: Testing av programvare

9 Oppgave 1(a) Testing viser feil som oppdages under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil.

10 Oppgave 1(a): Løsningsforslag Forklar hvorfor testing ikke kan bevise fravær av feil Absence of evidence is not evidence of absence

11 Oppgave 1(a): Løsningsforslag Forklar hvorfor testing ikke kan bevise fravær av feil Kun fordi det ikke oppdages, betyr ikke at det ikke finnes Å bevise et negativ: Kan man bevise at julenissen ikke eksisterer? Hvordan vite det man ikke vet? Tester kan være skrevet av utviklere Tunnelsyn: Fokuserer bare på det man forventer av feil Utfordrende å sette seg fullt inn i brukerens perspektiv Tester kan være skrevet feil / inneholde mangler

12 Oppgave 1(b) Forklar hvorfor det ikke er nødvendig for et program å være fullstendig feilfritt før det overleveres til kunden

13 Oppgave 1(b): Løsningsforslag Forklar hvorfor det ikke er nødvendig for et program å være fullstendig feilfritt før det overleveres til kunden Enkelte feil kan aksepteres / ignoreres De fleste programmer er ikke så kritiske at de ikke kan inneholde feil Feil i systemet betyr ikke nødvendigvis at systemet er ubrukelig Det kan være feil i områder brukeren aldri oppdager Økonomisk motivasjon Som regel lite lønnsomt å avdekke / rette opp alle feilene før release

14 Oppgave 2 Diskuter fordeler og ulemper med at utviklere selv tester sin egen kode

15 Oppgave 2: Løsningsforslag Diskuter fordeler og ulemper med at utviklere selv tester sin egen kode Fordeler Ressursbesparende Redusert tid og reduserte kostnader Unødvendig at eksterne team skal finne feil utviklere selv kan finne Utviklere kjenner allerede til den interne strukturen og koden i systemet Desto mindre kode, desto lettere er testingen Utviklere kan derfor delta i testinnsatsen tidlig i utviklingsprosessen

16 Oppgave 2: Løsningsforslag Diskuter fordeler og ulemper med at utviklere selv tester sin egen kode Ulemper Testing og utvikling er to forskjellige grener Testere og utviklere har derfor helt ulike utgangspunkt

17 Oppgave 2: Løsningsforslag Diskuter fordeler og ulemper med at utviklere selv tester sin egen kode Ulemper Vanskelig å skille mellom hvordan det virker og hvordan det skal virke Utviklere kan se seg blinde på egen kode Utviklere har ofte en formening om hvor feilene ligger, og fokuserer ensidig på disse Kan være vanskelig å løsrive seg fra utviklermentaliteten Utviklere er ikke nødvendigvis kompetente testere Løsningen Bruk eksterne testere / team til å gjennomføre testingen

18 Oppgave 2: Løsningsforslag Diskuter fordeler og ulemper med at utviklere selv tester sin egen kode Interne eller eksterne testere? Testing er en vurdering av kvalitet Interne testere kan oppleve det som vanskelig å poengtere medarbeideres feil Eksterne testere / testteam Eksterne testere kan ofte se (andre) feil / mangler som utviklere selv ikke oppdager Kommer inn med andre antakelser og forutsetninger enn utviklerne Eksterne testere nyter ofte mer troverdighet hos organisasjonen / ledelsen Kan uttrykke feil på en ærlig og kritisk måte

19 Oppgave 3 Hva er regresjonstesting? Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting.

20 Oppgave 3: Løsningsforslag Hva er regresjonstesting? Ulike testkategorier

21 Oppgave 3: Løsningsforslag Hva er regresjonstesting? Regresjonstesting Testing relatert til endringer Når? Etter at kildekoden / systemet har blitt endret Mål Avdekke eventuelle feil som har blitt introdusert i kildekoden etter endring Konsekvensanalyse gjennomføres i forkant Kartlegger deler av kildekoden som har stor sannsynlighet for å bli påvirket Teknikker for regresjonstesting Test alt (full regresjonstest) Test utvalg Prioriter tester Kombinasjon av disse Regresjonstester og konfirmasjonstester er ikke det samme! Konfirmasjonstester skal bekrefte at eventuelle feil er blitt rettet opp

22 Oppgave 3: Løsningsforslag Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting Automatisering av tester Testing Nødvendig aktivitet for å sikre kvalitet Ønsker å dekke mest mulig funksjonalitet / avdekke feil gjennom testing Testinnsatsen kan være tidkrevende, kostbar, og ikke minst repetitiv Umulig å dekke testbehovet manuelt (spesielt for større systemer) Programvare og rammeverk forenkler testinnsatsen Kan overlate testingen til automatiserte prosesser

23 Oppgave 3: Løsningsforslag Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting Automatiserte tester og rammeverk Bruk av programvare / verktøy for å gjennomføre testing Tester kildekode om og om igjen, uten at dette må gjøres manuelt Fordeler Tester utføres på nøyaktig samme måte som tidligere Umiddelbar sammenligning av forventet og faktisk utfall av testene Økt testomfang Ressursbesparende Tid / Innsats / Penger

24 Oppgave 3: Løsningsforslag Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting Eksempel: Enkel side for innlogging (krever grundig testing!) Input Brukernavn og passord Regler Riktig kombinasjon skal gi tilgang til siden Vi skriver tester for to ulike scenarioer Brukeren er allerede registrert Brukeren er ikke registrert

25 Oppgave 3: Løsningsforslag Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting Spesifikasjon for test_1 og test_2 ID Beskrivelse Pre-betingelse Input Prosedyre Forventet resultat 1 Gyldig bruker logges inn Brukeren er allerede registrert 1. Oppgi input (brukernavn og Gyldig brukernavn passord) Gyldig passord 2. Klikk "logg inn" Bruker logges inn Ugyldig 1. Oppgi input (brukernavn og 2 Ugyldig bruker avvises Brukeren er ikke registrert brukernavn passord) Ugyldig passord 2. Klikk "logg inn" Bruker avvises

26 Oppgave 3: Løsningsforslag Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting Vi kjører begge testene, og antar at vi har følgende innhold i databasen

27 Oppgave 3: Løsningsforslag Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting Vi har nå oppdaget en feil i systemet! Test 1 var vellykket En registrert bruker fikk logget inn Test 2 var mislykket En uregistrert bruker fikk logget inn Vi gjør de nødvendige endringene Eksempel: Endre kildekode / Restrukturer databasen / Endre koblingen mellom disse Kjører en konfirmasjonstest for å bekrefte at feilen er rettet Kjører en regresjonstest for å avdekke eventuelle nye feil i systemet

28 Oppgave 3: Løsningsforslag Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting Vi kjører testene på nytt, og anta vi nå har følgende scenario:

29 Oppgave 3: Løsningsforslag Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting Selv om feilen er rettet opp, har vi nå introdusert nye feil Hvordan går vi frem? Vi må gjøre ytterligere endringer for å rette opp nye feil Vi må bekrefte at nye feil er rettet opp Vi må igjen bekrefte at endringer ikke har introdusert nye feil Både før og etter kjøring av testene Dette er svært tidkrevende, spesielt for større systemer!

30 Oppgave 3: Løsningsforslag Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting Bruker heller automatiserte tester og rammeverk Kan mate verktøyet med data Mange ulike kombinasjoner av input og betingelser Kan la programvaren, og ikke menneskene, gjøre jobben Slipper å teste 100, eller 1000 kombinasjoner for hånd! Kan lage samlinger av ulike (regresjons)tester Kan kjøre flere (regresjons)tester etter hverandre

31 Oppgave 4(a) Hva forstår du med begrepet stresstesting?

32 Oppgave 4(a): Løsningsforslag Hva forstår du med begrepet stresstesting? Stresstesting Stresse systemet under test Kartlegge systemets stabilitetsegenskaper Avdekke antall transaksjoner / operasjoner et system er i stand til å takle Fremprovosere systemkollaps Hensikt Eksponere breaking points Avdekke kapasitet i henhold til systemkrav og spesifikasjon Avdekke hvordan systemet håndterer kollaps

33 Oppgave 4(b) Foreslå hvordan du vil stressteste et minibanksystem der det er mulig å sjekke saldo på konto og ta ut kontanter

34 Oppgave 4(b): Løsningsforslag Foreslå hvordan man kan stressteste et minibanksystem Formål med stresstester Stresse systemet til det kollapser En vellykket stresstest avdekker systemets breaking points Fremgangsmåte La minibanksystemet utføre mange transaksjoner samtidig Sjekk deretter om alle transaksjoner ble behandlet korrekt Redegjør for hvorvidt systemet taklet stresset / hvordan? Utvid stresstesten til systemet krasjer / tilfredsstiller spesifikasjonen

35 Oppgave 5 Hva er forskjellen på enhetstest og integrasjonstest?

36 Oppgave 5: Løsningsforslag Hva er forskjellen på enhetstest og integrasjonstest? Ulike testnivåer Testing av programvare er en omfattende prosess Bør stykkes opp Man kan (bør) ikke teste alt på en gang Testing bør starte så tidlig som mulig Hvordan teste så tidlig som mulig? Det er begrenset hvor mye man kan teste tidlig i utviklingsfasen Testing deles ofte opp i ulike testnivåer Hvert nivå er tydelig definert med tanke på formål og aktiviteter

37 Oppgave 5: Løsningsforslag Hva er forskjellen på enhetstest og integrasjonstest? Ulike testnivåer

38 Oppgave 5: Løsningsforslag Hva er forskjellen på enhetstest og integrasjonstest? Enhetstesting Tester individuelle enheter / komponenter (kildekode) Eksempel: Enheter i programmering Klasser / Metoder Enheten testes isolert fra resten av systemet Gjennomføres ofte tidlig i utviklingen / testingen Formål Forsikre seg om at enheten gjør akkurat som den skal Uavhengig av samspill med øvrige komponenter

39 Oppgave 5: Løsningsforslag Hva er forskjellen på enhetstest og integrasjonstest? Karakteristikker for god enhetstesting Isolasjon Testene til en klasse X avhenger ikke av å ha implementert andre klasser Testene i en klasse X skal ikke feile på grunn av feil i øvrige klasser Uavhengighet Hver enhetstest skal være selvforsynt Skal virke uavhengig av andre enhetstester som kjøres Enkelhet En enhetstest = Ett scenario

40 Oppgave 5: Løsningsforslag Hva er forskjellen på enhetstest og integrasjonstest? Eksempel: Enhetstesting Anta at vi har satt navn til Anders Forventer at hentnavn() skal returnere en tekststreng med verdien Anders For hver gang Anders returneres, regnes testen som vellykket Hvis andre verdier returneres (feil datatype, null, osv.), regnes testen som mislykket

41 Oppgave 5: Løsningsforslag Hva er forskjellen på enhetstest og integrasjonstest? Integrasjonstesting Sammensetning av flere enkeltstående enheter til komponenter Tester disse komponentene sammen Avdekker hvordan komponentene interagerer med hverandre

42 Oppgave 6(a) Hva er forskjellen på blackbox- og whitebox-testing?

43 Oppgave 6(a): Løsningsforslag Hva er forskjellen på blackbox- og whitebox-testing? Blackbox-testing Spesifikasjonsbasert testing Tester funksjonaliteten til en komponent i henhold til spesifikasjonen Hva skal komponenten gjøre? Gjør den det? Ikke fokus på underliggende intern struktur / logikk

44 Oppgave 6(a): Løsningsforslag Hva er forskjellen på blackbox- og whitebox-testing? Whitebox-testing Strukturbasert testing Tester den interne strukturen til et system Hvordan realiseres funksjonaliteten? Hvilken logikk ligger i grunn? Eksaminerer kildekoden Brukes ofte for å måle dekningsgrad av testene Hvor mye har vi testet?

45 Oppgave 6(a): Løsningsforslag Eksempel: Blackbox-testing Beslutningstabeller Årsak-virkning Viser forretningslogikk Ulike scenarioer gir ulike utfall Viser forventet resultat basert på input-verdier Ikke nødvendig å vite hvordan dette er implementert internt i systemet Vi er kun interesserte i spesifikasjonen Hva systemet skal gjøre

46 Oppgave 6(a): Løsningsforslag Eksempel: Blackbox-testing Ekvivalensinndeling Dele dataverdier inn i grupper som skal behandles likt Datasamlingene kalles ekvivalensklasser Alle verdier internt i klassen skal håndteres på samme måte av systemet Eksempel: Ruters beregning av priser for enkeltbilletter De aller minste (under 4 år) Barn (fra 4 til og med 15 år) Voksen (fra og meg 16 til og med 66 år) Honnør (fra og med 67 år) 0 NOK 17 NOK 33 NOK 17 NOK

47 Oppgave 6(a): Løsningsforslag Eksempel: Blackbox-testing Eksempel: Teste om Ruters system beregner korrekt billettpris? Vi kan teste alle aldre, én etter én Tester først om 0 år gir forventet pris Tester deretter om ett år gir forventet pris Tester deretter om to år gir forventet pris Osv. Problem? Dette er både tidkrevende og unødvendig Vi har ulike verdier (alder) som behandles på samme måte

48 Oppgave 6(a): Løsningsforslag Eksempel: Blackbox-testing Eksempel: Teste om Ruters system beregner korrekt billettpris? Siden noen intervaller (alder) gir samme utfall (pris), lar vi disse tilhøre samme klasse Vi lager ekvivalensklasser for dataverdiene Ekvivalensklasser Holder å teste én verdi fra hver klasse, fremfor alle verdier

49 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Hvordan og hvorfor måle instruks- og forgreningsdekning? Vi ønsker å teste så mye som mulig Må kunne vite hva som har blitt testet Programinstruksdekning Antall instrukser som testes i et program Forenklet: Én instruks = Én kodelinje Forgreningsdekning Antall forgreninger (mulige utfall) som testes i et program Oppstår ved IF, ELSE-IF, CASE, osv.

50 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Pseudokode for et enkelt program 1 READ A 2 READ B 3 C = A + 2 * B 4 IF C > 50 THEN 5 PRINT LARGE C 6 ENDIF

51 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Programinstruksdekning Test 1_1: A = 2, B = 3 Test 1_2: A = 0, B = 25 Test 1_3: A = 47, B = 1 Hvilke instrukser dekkes av testene?

52 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Programinstruksdekning Test 1_1: A = 2, B = 3 // C = 8 Test 1_2: A = 0, B = 25 Test 1_3: A = 47, B = 1 Hvilke instrukser dekkes av testene?

53 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Programinstruksdekning Test 1_1: A = 2, B = 3 Test 1_2: A = 0, B = 25 // C = 50 Test 1_3: A = 47, B = 1 Hvilke instrukser dekkes av testene?

54 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Programinstruksdekning Test 1_1: A = 2, B = 3 Test 1_2: A = 0, B = 25 Test 1_3: A = 47, B = 1 // C = 49 Hvilke instrukser dekkes av testene?

55 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Programinstruksdekning Vi dekker 5 av 6 instrukser Instruksdekning = 83 % Hvordan nå 100 % dekning? Trenger en annen test Test 1_4: A = 20, B = 25

56 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Programinstruksdekning Test 1_4: A = 20, B = 25 // C = 70 Instruksdekning = 100 % Trenger egentlig bare én test C > 50

57 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Forgreningsdekning Avgjørelser har minst ett enten/eller-utfall Disse utfallene skaper forgreninger i koden 1 READ A 2 READ B 3 IF A > B THEN C = 0 4 ENDIF Hvor mange tester trenger vi for å nå 100 % forgreningsdekning?

58 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Først: Instruksdekning Kun én test er nødvendig for 100 % instruksdekning A = 12, B = 10 // Alle instrukser blir eksekvert Forgreningsdekning Hver gren må eksekveres T/F, Y/N Testforutsetninger A må være mindre enn eller lik B

59 Oppgave 6(a): Løsningsforslag Eksempel: Whitebox-testing Forgreningsdekning A må være mindre enn eller lik B A = 2, B = 4 // Alle grener er nå eksekvert Vi vet nå hvor mye som har blitt testet Vi har 100 % forgreningsdekning Vi har 100 % instruksdekning

60 Oppgave 6(b) Forklar fordeler og ulemper med hver av teknikkene

61 Oppgave 6(b): Løsningsforslag Forklar fordeler og ulemper med hver av teknikkene Fordeler: Blackbox-testing Krever ikke teknisk kompetanse Enkelte tester kan gjennomføres av ulike brukergrupper Planlegging av testinnsatsen kan starte tidlig Vi vet hva systemet skal gjøre Kan bruke uavhengige testere (ikke involvert i utviklingen) Resultater kan tolkes uten kjennskap til systemets interne strukturer Finner krav som ikke er implementert riktig / mangler

62 Oppgave 6(b): Løsningsforslag Forklar fordeler og ulemper med hver av teknikkene Ulemper: Blackbox-testing Usikkerhet rundt hvor mye / hvilke deler av systemet som er testet Vet ikke hva som forårsaker problemet Hvor i kildekoden ligger feilen? Hva trigget feilen? Vanskelig å utforme tester uten en tydelig kravspesifikasjon Tester kan vise seg å være redundante Utviklere har allerede kjørt tilsvarende tester

63 Oppgave 6(b): Løsningsforslag Forklar fordeler og ulemper med hver av teknikkene Fordeler: Whitebox-testing Kan utføres tidlig i systemutviklingsprosessen Trenger ikke vente på at grensesnittet skal lages Ser nærmere på underliggende logikk / struktur i koden Optimalisering av kode / Fjerne unødvendige kodelinjer Grundigere analyse av hva som forårsaker eventuelle problemer Kartlegger data / input som mest effektivt tester programmet Utviklere må begrunne kode / beslutninger rundt implementasjon

64 Oppgave 6(b): Løsningsforslag Forklar fordeler og ulemper med hver av teknikkene Ulemper: Whitebox-testing Krever teknisk kompetanse Programmerings- og testeferdigheter Bør være ekspert og allerede ha kjennskap til koden Krever tid og tilgang til kildekoden Utfordrende å gjennomføre hvis implementasjonen endres hyppig Finner ikke krav eller mangler som ikke er implementert

65 Oppgave 7 Foreslå testcases for use caset ta ut penger. Ta for deg enhetstesting og integrasjonstesting.

66 Oppgave 7: Løsningsforslag Foreslå testcases for use caset ta ut penger. Ta for deg enhetstesting og integrasjonstesting. Enhetstester Blir PIN-koden validert korrekt? Blir kortet godkjent korrekt? Blir kortet returnert korrekt? Integrasjonstester Henter man saldo fra rett konto? Trekkes korrekt beløp fra rett konto? Blir saldo oppdatert korrekt etter uttak?

67 Oppgave 8 Hvorfor er det viktig å utføre både funksjonell og ikkefunksjonell testing?

68 Oppgave 8: Løsningsforslag Hvorfor er det viktig å utføre både funksjonell og ikkefunksjonell testing? Funksjonell testing HVA systemet gjør Tester hvorvidt de funksjonelle kravene fra systemspesifikasjonen innfris Ikke-funksjonell testing HVORDAN systemet virker Tester ikke-funksjonelle krav Kvalitetsattributter (brukervennlighet, effektivitet) Samlet testinnsats øker produktkvaliteten

69 Oppgave 8: Løsningsforslag Hvorfor er det viktig å utføre både funksjonell og ikkefunksjonell testing? Validering Bygger vi det riktige produktet? Programvaren gjør det brukerne virkelig ønsker seg Fokus på hele systemet Verifisering Bygger vi produktet riktig? Stemmer det med kravspesifikasjonen? Fokus på komponenter / delsystemer

70 Oppgave 9 Hvorfor er det viktig å utføre vedlikeholdstesting?

71 Oppgave 9: Løsningsforslag Hvorfor er det viktig å utføre vedlikeholdstesting? Vedlikeholdstesting Testing etter at systemet er tatt i bruk Vanlig med endringer i et system Korrigeringer / Utvidelser / Øvrige forandringer Plattformer endres eller fjernes Avdekker om vedlikehold har introdusert nye feil / mangler Først: Kjør tester for endringene som ble utført Deretter: Kjør regresjonstest for systemet

72 Spørsmål? Ta kontakt Yulai Fjeld uio.no Husk å inkludere emnekoden! Andre gruppelærere Delta på gruppetimene

73 Takk til Foilene er basert på Tidligere presentasjoner laget av Emilie Hallgren og Kristin Brænden Eksisterende forelesningsnotater av Dag Sjøberg og Yngve Lindsjørn Sommerville, I. (2010). Software Engineering (9th Edition). Pearson.

74 Takk for meg Neste uke : Kontrakter

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

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

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

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

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

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

Forskningsmetoder. INF1050: Gjennomgang, uke 13

Forskningsmetoder. INF1050: Gjennomgang, uke 13 Forskningsmetoder INF1050: Gjennomgang, uke 13 Kompetansemål Forskningsmetoder Hva? Hvorfor? Empiriske forskningsmetoder Eksperiment Case-studier Etnografi Aksjonsforskning Spørreskjema Systematisk litteraturstudie

Detaljer

Eksamen INF1050: Gjennomgang, uke 15

Eksamen INF1050: Gjennomgang, uke 15 Eksamen 2012 INF1050: Gjennomgang, uke 15 Overblikk Varierte spørsmål fra pensum Modellering Use case Tekstlig beskrivelse Sekvensdiagram Klassediagram Krav Empiriske metoder Smidig metodikk Varierte spørsmål

Detaljer

Systemutvikling. Universitetet i Oslo, Institutt for informatikk Vår 2017

Systemutvikling. Universitetet i Oslo, Institutt for informatikk Vår 2017 Systemutvikling Universitetet i Oslo, Institutt for informatikk Vår 2017 Dagens plan Introduksjon Emnets oppbygging Praktisk om ukesoppgaver og obligatoriske oppgaver Gjennomgang av ukesoppgaver Registrering

Detaljer

Use Case-modellering. INF1050: Gjennomgang, uke 04

Use Case-modellering. INF1050: Gjennomgang, uke 04 Use Case-modellering INF1050: Gjennomgang, uke 04 Kompetansemål Modellering av krav Kunne modellere ulike typer krav UML-diagrammer Innføring i grunnleggende UML-modellering Bruksmønster (use case) Sekvensdiagram

Detaljer

Kontrakter. INF1050: Gjennomgang, uke 12

Kontrakter. INF1050: Gjennomgang, uke 12 Kontrakter INF1050: Gjennomgang, uke 12 Kompetansemål Kontrakter I plandrevet utvikling I smidig utvikling Behov for smidige kontrakter Kontraktsmodeller PS2000 Del I: Kontrakter Grunnleggende: Hva? Plandrevet

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

Fra krav til objekter. INF1050: Gjennomgang, uke 05

Fra krav til objekter. INF1050: Gjennomgang, uke 05 Fra krav til objekter INF1050: Gjennomgang, uke 05 Kompetansemål Systemmodellering og systemperspektiv Utvikle abstrakte modeller av et system Ulike modeller representerer ulike perspektiver av systemet

Detaljer

Løsningsforslag: Oblig 1. INF1050: Gjennomgang, uke 12

Løsningsforslag: Oblig 1. INF1050: Gjennomgang, uke 12 Løsningsforslag: Oblig 1 INF1050: Gjennomgang, uke 12 Obligatorisk oppgave 1: Pensum Bakgrunn for systemet Aktører og interessenter Utviklingsprosesser Kravhåndtering og kravspesifikasjon Use case-modellering

Detaljer

Estimering. INF1050: Gjennomgang, uke 09

Estimering. INF1050: Gjennomgang, uke 09 Estimering INF1050: Gjennomgang, uke 09 Kompetansemål Estimering Hva og hvorfor? Estimeringsprinsipper Estimeringsprosessen Spesifikasjonsbasert testing / Strukturbasert testing Estimeringsmodeller COCOMO

Detaljer

Prosjektledelse, planlegging og teamarbeid. INF1050: Gjennomgang, uke 10

Prosjektledelse, planlegging og teamarbeid. INF1050: Gjennomgang, uke 10 Prosjektledelse, planlegging og teamarbeid INF1050: Gjennomgang, uke 10 Kompetansemål Prosjektstyring og prosjektledelse Hva og hvorfor? Risikohåndtering Ledelse av mennesker og motivasjon Teamarbeid og

Detaljer

Prosessmodeller og smidig programvareutvikling. INF1050: Gjennomgang, uke 02

Prosessmodeller og smidig programvareutvikling. INF1050: Gjennomgang, uke 02 Prosessmodeller og smidig programvareutvikling INF1050: Gjennomgang, uke 02 Kompetansemål Prosessmodeller Kunne redegjøre for hva som kjennetegner ulike prosessmodeller Vurdere prosesser for utvikling

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

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

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

Testplan (Software Test Plan)

Testplan (Software Test Plan) Testplan (Software Test Plan) Amanuel K. Tedla Eleonora Ntreska Ingrid Vik Hansen Joakim Moen Innholdsfortegnelse Innholdsfortegnelse 1.. Introduksjon... 3 1.1 Definisjoner... 3 1.2 Antagelser ved testing

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

Objektorientering og UML. INF1050: Gjennomgang, uke 06

Objektorientering og UML. INF1050: Gjennomgang, uke 06 Objektorientering og UML INF1050: Gjennomgang, uke 06 Kompetansemål Objektorientert design Objektdesign og ansvarstilordning Bruk av UML Fokus på klassediagrammer Designmodeller Designmønstre ( design

Detaljer

Systemarkitektur. INF1050: Gjennomgang, uke 07

Systemarkitektur. INF1050: Gjennomgang, uke 07 Systemarkitektur INF1050: Gjennomgang, uke 07 Kompetansemål Systemarkitektur Hva og hvorfor? Arkitektoniske modeller Kjennetegn Fordeler og ulemper Arkitektoniske stiler Ulike typer: Pipe-and-Filter /

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

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

Prøveeksamen INF1050: Gjennomgang, uke 15

Prøveeksamen INF1050: Gjennomgang, uke 15 Prøveeksamen 2016 INF1050: Gjennomgang, uke 15 Overblikk Multiple choice Modellering Aktivitetsdiagram Sekvensdiagram Klassediagram Tilstandsdiagram Krav Ikke-funksjonelle krav og målbarhet Smidig metodikk

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

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

Obligatorisk oppgave 3. INF1050: Gjennomgang, uke 16

Obligatorisk oppgave 3. INF1050: Gjennomgang, uke 16 Obligatorisk oppgave 3 INF1050: Gjennomgang, uke 16 Pensum for oppgaven Estimering Arkitektur 4+1 view-modellen og lagdeling Arkitektoniske stiler UML-modellering Tilstands- og aktivitetsdiagrammer Testing

Detaljer

Testdekning og automatisering - Er 100% testdekning et mål?

Testdekning og automatisering - Er 100% testdekning et mål? Testdekning og automatisering - Er 100% testdekning et mål? Shomaila Kausar, Senior prosjektleder/testleder Ole Fingal Harbek, Senior Testleder Testdagen Odin 2017 Kort om oss Shomaila Kausar - cand scient

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

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

UKE 10 Kravhåndtering. Gruppetime INF1055

UKE 10 Kravhåndtering. Gruppetime INF1055 UKE 10 Kravhåndtering Gruppetime INF1055 Hva skal vi i dag? Kravhåndtering - kapittel 4 Ukesoppgaver: Smidig programvareutvikling og kravhåndtering Krav KRAV KOMPETANSEMÅL: Kravhåndtering: anvende metoder

Detaljer

GJENNOMGANG OBLIGATORISK OPPGAVE 1

GJENNOMGANG OBLIGATORISK OPPGAVE 1 GJENNOMGANG OBLIGATORISK OPPGAVE 1 INF1050 V16 KRISTIN BRÆNDEN 1 Systemet for utleie av markasykler ønsker a benytte seg av en eksisterende betalingsløsning, og valget har falt pa det samme betalingssystemet

Detaljer

Konfigurasjonsstyring

Konfigurasjonsstyring INF1050: Systemutvikling 28. mars 2017 Konfigurasjonsstyring Yngve Lindsjørn ynglin@ifi.uio.no INF1050 Systemutvikling ->Konfigurasjonsstyring 1 Temaer i dagens forelesning Versjonshåndtering Systembygging

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

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

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

GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING

GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING INF1050 V16 HVA ER KRAVHÅNDTERING? Kravhåndtering er prosessen å identifisere, analysere og spesifisere kravene til et nytt system eller et system som skal forbedres

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

Repetisjon av testing. Vi undersøker om systemet virker slik det skal

Repetisjon av testing. Vi undersøker om systemet virker slik det skal Repetisjon av testing Vi undersøker om systemet virker slik det skal Test av software For å teste om alle kravene er oppfylt må kravspesifikasjon og utviklingsdokumenter gjennomgås. Hvordan programmet

Detaljer

Mellom barken og veden Smidig testing i krevende terreng TTC 2015

Mellom barken og veden Smidig testing i krevende terreng TTC 2015 Mellom barken og veden Smidig testing i krevende terreng TTC 2015 FOREDRAGSHOLDERE Kristian Bjerke-Gulstuen Accenture siden 1999 Fra utvikler til Testleder og Kvalitetsansvarlig Leder Accenture Norway

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

UKE 15 Prosjektledelse, planlegging og teamarbeid. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

UKE 15 Prosjektledelse, planlegging og teamarbeid. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski UKE 15 Prosjektledelse, planlegging og teamarbeid Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski Hva skal vi i dag? Se på oblig 5 Prosjektledelse og teamarbeid (kap. 22) Prosjektplanlegging og

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

EKSAMEN. Evaluering av IT-systemer. Eksamenstid: kl 0900 til kl 1300

EKSAMEN. Evaluering av IT-systemer. Eksamenstid: kl 0900 til kl 1300 EKSAMEN Emnekode: ITL24006 Dato: 4. desember 2007 Hjelpemidler: Emne: Evaluering av IT-systemer Eksamenstid: kl 0900 til kl 1300 Faglærer: Ingen, heller ikke kalkulator eller mobiltelefon Kåre Sorteberg

Detaljer

Repetisjon av testing. Vi undersøker om systemet virker slik det skal

Repetisjon av testing. Vi undersøker om systemet virker slik det skal Repetisjon av testing Vi undersøker om systemet virker slik det skal Test av software For å teste om alle kravene er oppfylt må kravspesifikasjon og utviklingsdokumenter gjennomgås. Hvordan programmet

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

UKE 9 Prosesser og prosessmodeller inkludert smidige metoder. Gruppetime INF1055

UKE 9 Prosesser og prosessmodeller inkludert smidige metoder. Gruppetime INF1055 UKE 9 Prosesser og prosessmodeller inkludert smidige metoder Gruppetime INF1055 Hva skal vi i dag? Introduksjon til modul B - systemutvikling (kap. 1, 2 og 3) Prosesser og prosessmodeller + smidig utvikling

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

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

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

3.3 Case 3: Opprette en bruker Case 4: Endre en bruker... 8

3.3 Case 3: Opprette en bruker Case 4: Endre en bruker... 8 Testdokumentasjon 1 Forord Denne rapporten omhandler testingen av systemet. Rapporten er først og fremst beregnet på sensor og intern veileder ved Høgskolen i Oslo, men kan gjerne leses av andre som måtte

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

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Testrapport 1 INNHOLDSFORTEGNELSE 1 INNHOLDSFORTEGNELSE... 1 2 Innledning... 2 3 Formål med testing... 3 3.1 Funksjonalitet...

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

GJENNOMGANG UKESOPPGAVER 4 USE CASE MODELLERING HELGA NYRUD & KRISTIN BRÆNDEN

GJENNOMGANG UKESOPPGAVER 4 USE CASE MODELLERING HELGA NYRUD & KRISTIN BRÆNDEN GJENNOMGANG UKESOPPGAVER 4 USE CASE MODELLERING INF1050 V16 HELGA NYRUD & KRISTIN BRÆNDEN TEMAER SÅ LANGT I KURSET Forelesning 1: Systemutvikling og systemutviklingsprosesser Forelesning 2: Prosessmodeller

Detaljer

RUTEPLANLEGGINGSSYSTEM TESTDOKUMENTASJON

RUTEPLANLEGGINGSSYSTEM TESTDOKUMENTASJON RUTEPLANLEGGINGSSYSTEM TESTDUMENTASJON Prosjekt 18 Jørgen Mobekk Sørensen Morten Evje Tor Andreas Baakind Anders Gabrielsen Side 1 1 FORORD Testdokumentasjonen har som formål å beskrive all testing som

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

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

Eksamen 2013 Løsningsforslag

Eksamen 2013 Løsningsforslag Eksamen 2013 Løsningsforslag Oppgave 1. Multiple choice 1b# 2a# 3b# 4c# 5b# 6a# 7a# 8b# 9d# 10b# Oppgave 2 - Bibliotek - Utlån av bøker a) Måle størrelse eller mengde funksjonalitet Denne oppgaven ser

Detaljer

Systemutviklingen er ferdig når et system er operativt. Med operativt menes når systemet blir brukt av brukerne på et faktisk arbeidssted.

Systemutviklingen er ferdig når et system er operativt. Med operativt menes når systemet blir brukt av brukerne på et faktisk arbeidssted. Presentasjon nummer 5 The changing system and the nature of maintenance Silde 1 Gruppen introduseres Slide 2 The changing system and the nature of maintenance The Changing system Systemutviklingen er ferdig

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

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 2. juni 2014 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 4 sider Vedlegg: Ingen Tillatte hjelpemidler:

Detaljer

Testdokumentasjon (Test Documentation)

Testdokumentasjon (Test Documentation) Testdokumentasjon (Test Documentation) Amanuel K. Tedla Eleonora Ntreska Ingrid Vik Hansen Joakim Moen Innholdsfortegnelse Innholdsfortegnelse 1.. Introduksjon... 3 1.1 Definisjoner... 3 2.. Testtilfeller...

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

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

UKE 16 Kontrakter. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

UKE 16 Kontrakter. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski UKE 16 Kontrakter Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski Hva skal vi i dag? OBS!! Siste ordinære gruppetime Kontrakter Ukesoppgaver Gjennomgang av oblig 4 Kontrakter Kompetansemål - Kontrakter

Detaljer

Why Desperate Houswives make Excellent Test Managers Testprosjektet som suksessfaktor i et hvert prosjekt

Why Desperate Houswives make Excellent Test Managers Testprosjektet som suksessfaktor i et hvert prosjekt Why Desperate Houswives make Excellent Managers prosjektet som suksessfaktor i et hvert prosjekt dagen ODIN 21.November 2012 Hvem er jeg Astrid Notø Larsen Cand Scient i Informatikk fra UiO 15 års erfaring

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

Del VII: Kravspesifikasjon

Del VII: Kravspesifikasjon 1 2 Forord Dette dokumentet inneholder retningslinjer for gruppen vår og beskrivelse av betingelsene for utviklingen av vårt prosjekt. Vår gruppe benyttet dette dokumentet som et styringsdokument for å

Detaljer

UKE 13 Mer UML modellering. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

UKE 13 Mer UML modellering. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski UKE 13 Mer UML modellering Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski Hva skal vi i dag? Objektorientert design - kapittel 5 og 7 UML modellering Aktivitetsdiagrammer Klassediagram Ukesoppgaver

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

Dårlige tider gir gode verktøy - visualisering av komplekse feilsituasjoner -

Dårlige tider gir gode verktøy - visualisering av komplekse feilsituasjoner - Dårlige tider gir gode verktøy - visualisering av komplekse feilsituasjoner - Rune Sørensen Statens pensjonskasse mai 2011 Agenda System: Pensjonsberegning Black-box testing, Regresjonstesting PERFORM

Detaljer

Shellscripting I. Innhold

Shellscripting I. Innhold Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Shellscripting I Tor Halsan 19.08.2010 Lærestoffet er utviklet for faget LN199D Scripting av Servere Resymé: Leksjonen er første innføring

Detaljer

Test i smidig. Laila Sandbæk Testrådgiver og testleder Sogeti

Test i smidig. Laila Sandbæk Testrådgiver og testleder Sogeti Test i smidig Laila Sandbæk Testrådgiver og testleder Sogeti 03.03.2016 Produktkøen til foredraget Sprintrytme Plassering av testaktivitetene i sprintrytmen Teamet Test som en integrert del av gjennomføringsmodellen

Detaljer

STE6221 Sanntidssystemer Løsningsforslag kontinuasjonseksamen

STE6221 Sanntidssystemer Løsningsforslag kontinuasjonseksamen HØGSKOLEN I NARVIK Avdeling for teknologi MSc.-studiet EL/RT Side 1 av 3 STE6221 Sanntidssystemer Løsningsforslag kontinuasjonseksamen Tid: Mandag 06.08.2007, kl: 09:00-12:00 Tillatte hjelpemidler: Godkjent

Detaljer

Automatisert Robusthetstesting. Erik Arisholm Testify AS

Automatisert Robusthetstesting. Erik Arisholm Testify AS Automatisert Robusthetstesting Erik Arisholm Testify AS 21. september Robusthetstesting Robusthetstesting er testing som avslører sårbarheter i et system overfor uventede (kombinasjoner av) input stressende

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

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

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

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

- analyse og implementasjon

- analyse og implementasjon - analyse og implementasjon Hvem er vi? Vi heter Anders S Finnerud Dennis JMJ Lundh studerer til bachelorgraden i ingeniørfag for data ved Høgskolen i Oslo. Oppgaven Lage et lett system som kan utføre

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), IS side 88, lærebok s.96 2. Verdien av etnografi er at den hjelper til å oppdage som reflekterer hvordan

Detaljer

TDT4102 Prosedyre og Objektorientert programmering Vår 2014

TDT4102 Prosedyre og Objektorientert programmering Vår 2014 Norges teknisk naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap TDT4102 Prosedyre og Objektorientert programmering Vår 2014 Øving 10 Frist: 2014-04-11 Mål for denne øvinga:

Detaljer

Automatisert test som leveransekrav

Automatisert test som leveransekrav Automatisert test som leveransekrav Testdagen Odin 2015 Marianne Rynning, Skatteetaten Magnus Halvorsen, Testify Skatteetatens IT- og servicepartner (SITS) Skatteetatens leverandør av IT- og administrative

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

Sikkerhet i Pindena Påmeldingssystem

Sikkerhet i Pindena Påmeldingssystem Sikkerhet i Pindena Påmeldingssystem Versjon: 1.6.9 Oppdatert: 26.11.2014 Sikkerhet i Pindena Påmeldingssystem 2 Innhold OM DOKUMENTET... 3 SIKKERHET PÅ KLIENTSIDEN... 3 SIKKERHETSTILTAK... 3 ROLLESIKKERHET...

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

Kapittel 5 - Advanced Hypertext Model Kapittel 6 - Overview of the WebML Development Process

Kapittel 5 - Advanced Hypertext Model Kapittel 6 - Overview of the WebML Development Process INF 329 Web-teknologier Kapittel 5 - Advanced Hypertext Model Kapittel 6 - Overview of the WebML Development Process Navn: Bjørnar Pettersen bjornarp.ii.uib.no Daniel Lundekvam daniell.ii.uib.no Presentasjonsdato:

Detaljer

Lykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet

Lykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet Side 1 av 10 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist:

Detaljer

Derfor er forretningssystemet viktig for bedriften

Derfor er forretningssystemet viktig for bedriften Innhold Derfor er forretningssystemet viktig for bedriften... 2 Når er det på tide å bytte forretningssystem?... 2 Velg riktig forretningssystem for din bedrift... 3 Velg riktig leverandør... 4 Standard

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

KRAVSPESIFIKASJON DAGSPLANAPPLIKASJON FOR NETTBRETT. Gruppe 28 Hovedprosjekt våren 2015

KRAVSPESIFIKASJON DAGSPLANAPPLIKASJON FOR NETTBRETT. Gruppe 28 Hovedprosjekt våren 2015 KRAVSPESIFIKASJON Kravspesifikasjon er en beskrivelse av hvilke krav oppdragsgiver har til systemet som skal utvikles. Den fungerer som en kontrakt mellom oppdragsgiver og utviklere. DAGSPLANAPPLIKASJON

Detaljer

Modellering av krav. INF1050: Systemutvikling 07. februar Førstelektor Yngve Lindsjørn

Modellering av krav. INF1050: Systemutvikling 07. februar Førstelektor Yngve Lindsjørn INF1050: Systemutvikling 07. februar 2017 Modellering av krav Førstelektor Yngve Lindsjørn INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 1 Temaer i dagens forelesning Modellering av

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

Visma Rapportering og Analyse Selvbetjente rapporter som dekker behovene til hele bedriften

Visma Rapportering og Analyse Selvbetjente rapporter som dekker behovene til hele bedriften Visma Rapportering og Analyse Selvbetjente rapporter som dekker behovene til hele bedriften Et webbasert verktøy som gjør tallene og informasjonen i bedriftens forretningssystemer tilgjengelig for alle

Detaljer