Sftware Faults and Failure Testing Issues 8.1 / 8.2 Når du har kdet prgramkmpnenter må du e dem. Det er mange måter å e dem på. Vi er de ulike kmpnentene fr å finne faults (feil) g failure (svikt) slik at prduktet tilslutt har/får en bedre kvalitet. SW faults g failure. Grunner til at systemet kan innehlder feil er: - spesifikasjnen er gal - har ikke fått med alle kravene - spesifikasjnen kan innehlde krav sm er umulig å implementere - systemdesignet kan innehlde feil - prgramdesign kan innehlde feil - kden kan innehlde feil Ulike typer feil Når kding er ferdig ser man vanligvis ver kden fr å se m man finner nen feil. Deretter er man prgrammet fr å se m vi kan islere flere feil ved å lage tilstander hvr kder ikke fungere sm den skal. Hvilke feil ser man da etter? - Algritmefeil Algritmefeil frekmmer hvis algritmen ikke prdusere den rette utput til en gitt input - Syntaksfeil Syntaksfeil frekmmer hvis man ikke har brukt språket på en riktig måte Eks på hva man ser etter kan være at tegn er brukt riktig - Cmputatin/precisin (beregnings/nøyaktig)feil Disse feilene ppstår når en frmelsimplementasjn ikke er krrekt, eller hvis frmelen ikke beregner det nøyaktige resultatet sm den skal Eks det å kmbinere int g flat i et uttrykk kan prdusere uventede feil - Dkumentasjnsfeil Disse feil ppstår hvis prgrammet gjør ne annet enn det dkumentasjnen sier - Stress/verladfeil Disse feil ppstår hvis datastrukturer ikke har kapasitet til å prsessere det sm trengs - Kapasitet/grensefeil Dette er feil sm ppstår når systemets ytelse er uakseptabel Eks hvis kravene spesifisere at systemet skal håndtere 32 deler må man e prgrammet når alle 32 delene er tilkblet. Du bør gså e å se hva sm skjer hvis du kbler til flere enn 32 deler - Timing/crdinatins feil Dette er feil sm ppstår hvis systemet skal utføre flere prsesser samtidig g kden klarer ikke dette - Perfrmance feil: - Recvery feil Dette er feil sm frekmmer hvis systemet ikke klarer å utføre det det skal gjøre innenfr det tidspunktet sm er satt av kravene Dette er feil sm frekmmer hvis systemet ikke fungere slik designerne ønsker eller sm brukerne behøver Eks ved et strømbudd bør systemet ha en backup - HW g systemswfeil 1
Dette er feil sm ppstår når levert HW g systemsw ikke fungere sm det skal - Standard g prsedyre feil Dette er feil sm ppstår hvis kden ikke følger rganisasjnsstandarder g prsedyrer Testing issues Man utfører mange ulike er før vi kan levere systemet til kunden. Eksempler på hva sm es er: - Mduleing Hver kmpnent es, islert fra andre kmpnenter i systemet. Dette gjøres fr å sjekke at de ulike kmpnentene fungere med den typen input sm er beskrevet i kmpnentdesignet - Integrasjning Man har nå et m mduler fungere, det neste er å e m kmpnentene fungere sammen slik sm det står beskrevet i system g prgramdesignspesifikasjnen - Funksjnsing Man har nå et at mdulene fungere sammen, det neste er å e m systemet gir den ønskede funksjnaliteten - Perfrmanceing Tester systemet pp mt andre sw g hw krav - Acceptanceing Her es det m systemet funger ut i fra kundens frventninger, es pp mt kundens kravspesifikasjn - Installasjnsing Tester m systemet funger sm det skal i det miljøet det skal fungere i Unit Design spesifikasjner System funksjnelle krav Andre sw krav Kundens kravspesifikasjn Bruker miljø Unit Integrerings Funksjn Ytelses Gdkjennelse Installasjns Unit Integrerte mduler Fungerende system Verifisert, validert sw Gdkjent system Testing steg System i bruk 2
Hva sm sammenlignes mt under ing Hva sm er resultatet etter ing Hldninger til ing Oppdagelsesprsess Må se ing sm en ppdagelsesprsess. Et ledd i avdekking av feil g mangler i systemet, sm egentlig begynner allerede under kravprsessen g designprsessen. Selve prblemet Når man er må man se på selve prblemet, ikke bare på løsningene til prblemet. Velge riktige data Viktig å velge riktige data. Man velger fte psitive data, sm skal bevise at prgrammet fungerer eller hlder mål. Heller velge data sm virkelig sjekker fr feil g ha hldningen at man ønsker å finne feil. Finne flest mulig, uansett hvr i prgrammet, uansett hvem sm har skapt dem. Feil ikke kritikk Viktig å ikke se på feil i et prgram sm kritikk av ens evne til å prgrammere. Egless prgramming Utviklingsteknikk sm ser på prgrammer sm kmpnenter av et større system, ikke bare sm eiendm til den sm har prgrammert det. Har fte et team sm er ansvarlig fr kden, isteden fr individet. 3
Hvem utfører ingen Til trss fr egless prgramming, er det vanskelig å fjerne følelser fr prgram. Dessuten lett at det sniker seg inn feil ved: tlkning av design, når man skal bestemme prgramlgikk skrive dkumentasjn feil ved implementering av algritmer. Trenger uavhengig ingteam, sm er distansert fra kde g kan finne subtile feil. Uavhengig ingteam: Ingen persnlige følelser fr feil sm ppdages i kden Gjøre ingen bjektiv Prøve å unngå at nen føler persnlig ansvar. Fr da blir det vanskelig å freta en bjektiv evaluering fr å avdekke flest mulige feil Utviklingsteamet kan følge flere steg i utviklingsprsessen, enn bare ingen av selve kden: Se på kmpnentene gjennm hele utviklingen Teste krav g design Teste kde i kmpnentene individuelt Sette sammen kmpnenter, mens kdeteam frtsetter med uferdige kmpnenter Syn på bjektene Testbjekter kan være kmpnenter, gruppe av kmpnenter, subsystem eller systemet. Filsfien ved ing. Når man er bjekter kan synet på bjektene påvirke hvrdan ingen utvikler seg. Derfr har man t måter å se bjektene på. Clsed/black bx Se bjektene fra utsiden sm clsed bx eller black bx Innhldet er ukjent. Testingen fregår ved å gi input g å merke seg utput. Gi all slags input g se at utput tilsvarer det man frventer. Frdelen Fri fr begrensningene gitt av intern struktur g lgikken til bjektet. Ulempen Ikke alltid mulig å få kmplett ing på den måten. 4
Open/white bx Fr nen bjekter er det umulig å lage et sett med represenatative er sm beviser krrekt funksjnalitet fr alle tilfeller. Tar fr ss selve strukturen fr å e på frskjellige måter. Vi kan eksekvere alle statements eller alle cntrl paths i kmpnenten fr å være sikker på m den fungerer rdentlig. Kjøre gjennm lper, e if-setninger. Velge hvrdan man er kan man gjerne velge en kmbinasjn av pen- g clse bx. Open- g clse bx representerer ytterpunktene. Valget bygger på Generelt bygger valget av -filsfi på mange faktrer, sm bl.a.: Antall mulige lgiske veier (lgical path) Inputdataenes karakter Mengden av dataprsessering sm er invlvert Kmpleksiteten av algritmene 5
Eks. 1 Input til ligningen ax 2 + bx +c = 0 Umulig å e alle input fr a, b g c. Man nøyer seg med å e alle tre med psitive tall, null g negative tall. Dette gir 27 muligheter (3 3 ). Selv m man ikke får feil på nen av disse 27 inputene har man ingen garanti fr at det ikke eksisterer feil. Det kan fr eksempel ppstå feil ved avrunding eller ved inkmpatible datatyper (duble -> integer). Eks. 2 Kan være system sm beregner skatt, hvr man kun kan sjekke at utput stemmer ngenlunde, ut fra skattetabeller. Ved å se dette sm en clse bx, kan vi ikke velge representative er, frdi vi ikke vet nk m prsessen til å velge riktig. 6