Versions Compared

Version Old Version 3 New Version Current
Changes made by

babak.tavassoli

babak.tavassoli

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
minLevel1
maxLevel73
typeflat
Info

Oversikt

Enhetstesting (også referert til som komponenttesting eller modultesting) utføres på enhet på laveste nivå for å teste en individuell metode, en funksjon eller en logisk gruppe med programmer som kan testes separat. Enhetstesting gjøres med det formål å finne feil fra koden i den tidlige fasen av programvarens livssyklus. NB! Enhetstesting validerer kodestrømmen mot brukerens krav men tester ikke ytelsen til systemet for belastning og belastningstesting

Akseptprøving bekrefter tjenesten mot forretningskravene for å fastslå om det skal aksepteres for forretningsbruk. Det etablerer tillit til systemet, deler av systemet eller spesifikke ikke-funksjonelle egenskaper ved systemet.

Beskrivelse av tjenesten:

opplastede dokument(er) eller lenke til interne eller eksterne nettside(r)

f. eks. en liste,

Siste oppdatering:

Testgrunnlag:

TESTSAMMENDRAG

key

verdi

Test versjon

  •  <versjon ‘tjeneste.integrasjon.flyt.komponent’>

  • utført:

  • Resultat godkjent:

Utviklingsmiljø

  •  Dev (debug)
  •  Test (overvåking)
  •  Prod (feilsøking)

Testmetoden

  •  hvite boksen - Uttalelsestesting og dekning
  •  hvite boksen - Beslutningstesting og dekning

Kildekoden for isolert komponenten

prosjekt/fil/flyt/prosess/<1>

Kravdokument eller brukerhistorie

en
Image Added

Testgrunnlag:

  •  Brukerkravspesifikasjoner (kravdokument)
  •  Brukssaker (use cases)
  •  Risikoanalyserapport

Testobjekter:

  •  Brukerprosedyrer
  •  Skjemaer
  •  Rapporter
  •  Konfigurasjonsdata

opplastede dokument(er) eller lenke til interne eller eksterne nettside(r)

  •  Brukerkravspesifikasjoner
  •  Forretningsprosess
  •  Brukssaker (use cases)
  •  Risikoanalyserapport

Testhistorikk:

<Free Text: referanse til tidligere/parallelle tester>

Siste oppdatering:

Drawiozoom1simple0inComment0pageId2455142404custContentId2457141290lbox0diagramDisplayNameUntitled Diagram.drawiocontentVer6revision6baseUrlhttps://unit.atlassian.net/wikidiagramNameUntitled Diagram.drawiopCenter0width426linkstbstyleheight1116
Info

Tester

ID

IOM-000

utført

akseptprøvingstrinn

  •  Planlegging
  •  Forutsetning
  •  Test miljø
  •  Testutførelse
  •  Evaluering av utgangskriterier
  •  Testavslutning

testbeskrivelse

  • Grad av testing uavhengighet: f. eks. ingen uavhengig tester (noen andre mulige alternativer: uavhengige utviklere eller testere innen utvikling/prosjektteam, uavhengig testteam eller gruppe i organisasjonen, uavhengige testere fra bedriftsorganisasjonen, uavhengige testere utenfor organisasjonen og Testers oppgaver)

  • Test strategi/tilnærming: f. eks. prosesskompatibel (standard kompatibel), noen andre mulige alternativer: analytisk (risikobasert testing), modellbasert, metodisk (forhåndsdefinert av taksonomibasert), regissert (rådgivende), motvilje mot regresjon og reaktiv tilnærming

  • Inngangskriterier: f. eks. testbare krav/modeller tilgjengelig, noen andre alternativer: testartikler tilgjengelig, testmiljø tilgjengelig, nødvendige testverktøy tilgjengelig, og testdata og andre nødvendige ressurser tilgjengelig

  • Utgangskriterier: f. eks. planlagte tester utført, noen andre alternativer: definert dekningsnivå (krav, risiko, kode etc.) er oppnådd, antall uavklarte mangler er innenfor en avtalt grense, antall estimerte gjenværende feil er tilstrekkelig lavt, og evaluerte nivåer av kvalitetsegenskaper (pålitelighet, ytelseseffektivitet, brukervennlighet, sikkerhet osv.) er tilstrekkelig

  • Testovervåking: f. eks.

    • antall tester kjørt/ikke kjørt:

    • antall testtilfeller bestått/ikke bestått

    • antall testbetingelser bestått/ikke bestått

, noen andre alternativer: prosentandel av planlagt arbeid utført i testcaseforberedelse, prosentandel av planlagt arbeid utført i forberedelse av testmiljø, defektintensitet, feil funnet og fikset, risikoer eller kodebekreftelsestester, testdekning av krav, brukerhistorier, akseptkriterier, risikoer eller kode, oppgavefullføring, ressursallokering og bruk, og kostnad for testing

  • Testkontroll: f. eks.

    • endring av testplanen på grunn av tilgjengelighet eller utilgjengelighet av testmiljø eller andre ressurser

    • omprioritering av tester når en identisk risiko oppstår

for å oppfylle testkravet (i kravdokumentet eller brukerhistorien/use case)

<en liste, opplastede dokument(er) eller lenke til interne eller eksterne nettside(r)

Funksjonelle/tekniske spesifikasjoner for komponenten som testes for a kryssverifisere testresultatene

<Free Text>

verktøyene brukes til enhetstesting

  •  MUnit (versjon: …)

Nødvendig spotter/Mock

<referanse til spottverdig komponent/element/flyt/eksterne systemutganger/tjenester/database strømning som kreves for testing kan etterlignes ved hjelp av spotter>

Tip

Enhetstestprosess

key

verdi

1. Enhetstesttilfeller

<Free Text: beskrivelse, resultat, kvalitets tilbakemelding osv.>

  •  Enhetstesttilfeller er identifisert.

2. Enhetstestingsramme

Etter identifikasjon blir testtilfeller implementert i en enhetstestingsramme

3. Testutførelse

<Det kan finne feil i metoder eller funksjoner, i datastrømmer og kan også finne logiske feil.>

  •  Ikke aktuelt
  •  Testutførelse er ferdig og feil blir funnet

4. Feil løses

  •  Ikke aktuelt
  •  Feil løses av utvikleren

5. Feil bekreftes på nytt

  •  Ikke aktuelt
  •  Bekreftes på nytt

6. Push koden til repo

  •  ikke nødvendig nå, da testresultatet ikke gjorde endringer
  •  Applikasjonen (versjon: 1.1.1) er nå deployed til Sandbox
  •  Applikasjonen (versjon: 1.1.1) er nå deployed til Prod

>

User-storiene tar utgangspunkt i at integrasjonen benytter PDF-filer fra Leganto direkte. (Alternativet ville ha vært å bruke Leganto-API). [1]

https://unit.atlassian.net/wiki/spaces/IPM/pages/1028096111/Arkivering+av+pensumlister+fra+Leganto#Brukerhistorier-%2F-Usecase%3A

resultat godkjent (av kunden)

  •  ikke godkjent
  •  delvis godkjent (ønsket endring ref. nr. RT#000000)
  •  godkjent ()

kryssreferanse til ønskede endringer

  •  ikke aktuelt (resultatet er godkjent)
  •  ref. nr. RT#000000
Tip

Resultatgodkjenning

Brukerhistorie hentet fra kravdokumentet:

#

brukerhistorien/use case

resultatgodkjenning

notat

1

Som administrator i biblioteksystemet Alma har vi opprettet pensumlister for alle emner som har gått en bestemt termin, for et bestemt emne ett bestemt år

  •  resultat godkjent av kunden

2

Som administrator i Alma kan jeg definere et sett med emner som jeg kan kjøre en jobb for å eksportere til PDF. Resultatet legges i et bestemt mappe-tre på SFTP-serveren

  •  resultat godkjent av kunden

3

PDF-filene vil ha en navngiving som ser slik ut: UE_203_SA6-410_1_2018_VÅR_1_0.7770285369568677_SA6-410 Politikk styring og endring i utdanningssektoren.pdf (intern ID_Emnekode tittel på emnet)

  •  resultat godkjent av kunden

4

Når det ligger eksporterte PDF-filer i mappe-treet på SFTp-serveren ønsker jeg at filene skal eksporteres til P360 og arkiveres

  •  resultat godkjent av kunden

5

Når PDF’ene er vellykket arkivert ønsker jeg at filene flyttes på SFTP-serveren til en mappe som heter “Arkivert”

  •  resultat godkjent av kunden

6

Hvis arkivering av PDF’ene feiler, flyttes de på SFTP-serveren til en mappe som heter “Feillet”

  •  resultat godkjent av kunden

7

Det vil uansett resultat, sendes e-post til alle e-postadresser oppgitt i feltet "epost-varsling" (kommaseparert liste)

  •  resultat godkjent av kunden

8

Som Administrator ønsker jeg kanskje å kunne selv starte arkiveringsjobben, eventuelt at den kjører regelmessig automatisk. Hva jeg ønsker avhenger litt av hvilke opplysninger/parametere som kreves for jobben

  •  resultat godkjent av kunden

9

Som administrator trenger jeg å kunne angi noen parametere for arkiveringsjobben; f.eks. saksbehandler, og e-postadresser for varsling av resultatet

  •  resultat godkjent av kunden

Ønskede endringer

Her kommer endringer som kommer i ettertid:

referanse nummer

RT#000000

dato

forespørselsbeskrivelse

f. eks. revurdere om et testelement oppfyller et inngangs- eller utgangskriterium på grunn av omarbeiding

objektiv (forventet resultat)

for å kontrollere om alle kravene er oppfylt

kryssreferanse til testversjon

IOM-001

dato for godkjening