Testing av system Gruppe 6 Henrik Bækhus Morten A. Iversen Mathias Bondeson Gunnar K. Kulleseid Svein Ivar Kristiansen Ronny Hulthin

Prinsipper ved systemtesting –Hovedobjektet er å forsikre seg om at systemet gjør det kunden vil at det skal gjøre ! –Vi begynner med å se på noen vanlige feil :

Kilder til softwarefeil Feilen kan ligge i koden, men trenger ikke å bli oppdaget hvis koden ikke blir eksekvert. –Dette kan føre til at vi aldri ser feilen. Softwarefeil kan være implementert i et krav, i designet eller i en kodekomponent.

Kan oppstå når som helst i utviklingen.Gjerne ved uklare krav. –Kunden kan ha vært usikker på hva han egentlig ville ha. Feiltolking av systemdesignet. –Man forstår kravet, men det er såpass uklart at det kan mistolkes. Feil i syntaks og/eller semantikken.

Retting av feil kan føre til nye feil i andre kodeblokker. –Disse kan være vanskelige å oppdage, fordi de kun forekommer når visse deler av koden blir eksekvert. Hvis dokumentasjonen er uklar eller uriktig kan systemet feile. –Her kommer den mennesklige faktoren inn. Bruker forstår ikke systemet og/eller misforstår dokumentasjonen.

Systemtesting – prosesser Det er flere steg i testing av et system –Function testing –Performance testing –Acceptance testing –Installation testing

Function test –Sjekker at det integrerte systemet utfører funksjonene slik de er spesifisert i kravdokumentet. Performance test –Sammenligner de integrerte komponentene med de ikke-funksjonelle systemkravene (sikkerhet, nøyaktighet, hastighet, pålitelighet, etc.) verifisert system validert system. Ved dette punktet fungerer systemet slik designeren vil ha det. Dette kalles et verifisert system. Deretter sammenlignes systemet mot kundens krav. Hvis disse også er oppfylt, har systemet blitt et validert system.

Acceptance test –Forsikrer kunden om at systemet de bestilte er det systemet som ble laget for dem. Man må da sjekke om alle kravene er innfridd. Installation test –Dette er den siste testen. Her blir systemet tatt med til sitt rette miljø for å se om det fungerer der. For eksempel kan dette være snakk om et radarsystem på et skip. Systemet kan fungere utmerket hos utvikleren, men resultatet trenger ikke nødvendigvis være det samme hos kunden.

System Functional requirements Other Software requirements Customer Requirements specification User Environment Integrated modules Function test Performance test Acceptance test Installation test System In use! Functioning sytem Verified, Validated software Accepted system Gangen i prosessene for systemtesting

Build or Integration Plan En plan for hvordan man skal teste et system. - Hvordan - Hvor - Når - Av hvem Systemet blir delt opp i mindre deler (subsystemer), gjerne etter funksjonalitet.

Et subsystem blir gjerne kalt en ”spin”, for å identifisere og avgrense hver del man tester. Man starter med “spin zero”, den første logiske biten å starte med. F.eks operativsystemet man skal kjøre systemet som utvikles på. På denne måten kan man oppdage feil i systemet og hvor de ligger. Er det en feil i spin 3, må feilen ligge mellom spin 2 og 3.

Configuration Management System Configuration er et oppsett som er levert til en kunde. F.eks til et Unix-system, Windows-system osv. For å teste et system som skal tilpasses forskjellige konfigurasjoner, trengs det en kontrollinstans som holder orden på hver konfigurasjon.

En konfigurasjon for et spesielt system, kalles gjerne en ”versjon”. En ”utgivelse” er en oppdatering av en ”versjon”. Disse to brukes i en kombinasjon. For eksempel Windows 3.10 og 3.11, Windows 95 og 98 osv. De som er med i et “Configuration Management Team” er ansvarlige for å oppdatere og rette opp feil før en ny utgivelse av produktet blir gitt ut.

Production-/Development System Et ”Production System” er en ferdigstilt versjon/utgivelse. Et ”Development System” er den nye versjonen man jobber med for å erstatte en eldre versjon. I ”Development System” retter man opp feil og tilfører nye funksjoner, slik at den nye versjonen skal bli ”feilfri”.

Regression Testing En ”Regression Test” blir brukt for å teste om en ny versjon/utgivelse er i stand til å utføre det som forrige versjon gjør, og at det ikke finnes noen feil i det nye systemet. Kan vises som følgende:

1.Sett inn ny feilfri kode. 2.Teste det som kan bli påvirket av ny kode. 3.Teste funksjoner i gammel versjon for å se om ny kode retter opp feil. 4.Teste den nye koden i ny versjon for å se om den forårsaker feil i de nye funksjonene.

Versjonskontroll Separate filer –Alle komponenter som er forskjellige er i utgangspunktet separate filer Delta –Forskjellsfil som inneholder kommandoer for å skape egne versjoner av koden Betinget kompilering –Koden inneholder kompileringsopsjoner som kan kompilere flere forskjellige versjoner med utgangspunkt i samme kode

Endringskontroll Styres av konfigurasjonshåndteringsteam De jobber tett opp mot testteamet Styrer endringstilgang overfor programmererene

Testteam Profesjonelle testere Analytikere Systemdesignere Konfigurasjonshåndterer Brukere

Takk for oss Presentasjonen legges ut på :