Programvaretesting In 140 Forelesning Nr 17 Sommerville kap
- Slides: 35
Programvaretesting In 140 Forelesning Nr 17 Sommerville kap 20
Mål Forstå noen test-teknikker som brukes for å finne programfeil n Kjenne til retningslinjer for testing av komponentgrensesnitt n Forstå noen tilnærmingsmetoder for testing av komponenter og integrasjon av objektorienterte systemer n Forstå hvordan CASE-verktøy kan støtte testing n
Introduksjon n n n n Testfaser Komponenttesting vs. integrasjonstesting Ansvarsfordeling Kritiske systemer – formelle prosesser Normalt ikke tid til full spesifikasjon Intuitiv forståelse Integrasjonstesting – alltid formell. . testplan Testteori ('90 Beizer, '95 Kit, '95 Perry) – Funksjonsorientert
Testing og OO n OO skiller seg fra funksjonsorientert – Ikke klart skille mellom funksjoner og moduler. – Ingen klar hierarkisk struktur. n Ikke lett å skille komponent og integrasjonstesting
Defekttesting Finne feil før systemet leveres n Det gjelder å få systemet til å feile. n – motsetning til verifikasjonstest n Modell – – Test case Test data Test resultater Test rapport Testdata kan genereres automatisk n Test case kan ikke genereres automatisk n
Defekttestingsprosessen
Defekttesting – hvor grundig? n Uttømmende (Exhaustive) testing – Sjekker alle mulige eksekveringsveier – Umulig å gjennomføre Hvilket subset skal da testes? n Alle programsetninger minst en gang n Bygge på erfaringer fra bruk n – Alle menyfunksjoner testes – Kombinasjoner av funksjoner på samme meny – Teste alle innmatingsmuligheter med gyldige og ugyldige data
Black-box –testing n n n n Testene utledes fra spesifikasjonen Kalles også funksjonell testing Kan brukes på alle systemer Gi systemet inndata, sjekke utdata Det gjelder å finne inndata som fører til svikt Bruke kunnskaper om anvendelsesområdet Systematisk testdatautvalg
Black-box testing
Ekvivalenspartisjonering Systemets inndata kan kategoriseres n En ekvivalenspartisjon er en datamengde som behandles likt n Ekvivalenspartisjoner kan identifiseres fra spesifikasjonen n Retningslinje: Velg data som ligger midt i ekvivalenspartisjone og på grensa – atypiske verdier. n – Disse blir ofte oversett og feilbehandlet av programmet.
Ekvivalenspartisjoner
Eksempel søkerutinespesifikasjon
Søkerutine n n n Søker etter et element i en sekvens av elementer Returnerer posisjonen til elementet Forutsetning: Ikke tom sekvens Found satt hvis funnet Posisjon L udefinert hvis ikke funnet Partisjoner: – – Inndata der elementet er medlem sekvens Inndata der elementet ikke er medlem av sekvens Inndata der sekvens har ett element Inndata der sekvens har flere elementer.
Retningslinjer ved testing av sekvenser n Test med sekvenser som bare har ett medlem n Bruk sekvenser med forskjellig antall elementer n Lag tester du skal finne første siste eller midterste element
Inndatapartisjoner og testdata Array Enkelt element Mer enn 1 element Element I sekvens Ikke i Sekvens Første element i sekvens Siste element i sekvens Midtre element i sekvens Ikke i sekvens Inndata Sekvens (T) 17 17 17, 29, 21, 23 41, 18, 9, 31, 30, 16, 45 17, 18, 21, 23, 29, 41, 38 21, 23, 29, 33, 38 Key (Key) 17 0 17 45 23 25 Utdata (Found, L) Sann, 1 Usann, ? ? Sann, 1 Sann, 7 Sann, 4 Usann, ? ?
Begrensninger ved Black Box testing n Parametre med feil rekkefølge og type n Datakorrupsjon pga feil utenfor modulen som testes n Bruk heller – Inspeksjon – Automatisk statisk analyse
Strukturell testing n Kalles også White-Box testing – eller Glass-box, Clear box n Bygger på kjennskap til programvarestrukturen n Målet er å teste alle programsetninger n Egnet for små programmoduler n Analysere kode for å partisjonere
White-box testing
Binærsøk (Java)
Ekvivalenspartisjoner for binærsøkrutinen
Binary search - test cases
Path testing Formålet er å teste alle veier gjennom systemet n Alle vilkårssetninger kjøres med verdier som gir sann eller usann som resultat n Antall muligheter proporsjonal med systemets størrelse. Metoden blir ugjennomførbar. Med sløyfer blir mulighetene fort "uendelige". n Metoden tar utgangspunkt i flytkart n
Flytkart for binærsøk
Flytkart n Bare vilkårssetninger og sløyfer n Hensikten er å utføre alle uavhengige løp n Et uavhengig løp går gjennom minst en ny kant
Syklomatisk kompleksitet (Mc Cabe 1976) n CC(G)=Antall kanter-Antall noder +2 n Hvis ingen goto setninger er CC=antall vilkårssetninger +1 n Lage testdata som kjører alle løp. n Ikke like enkelt på kompliserte program n Dynamiske programanalysatorer
Integrasjonstesting n Utvikles fra spesifikasjon n Settes i gang så snart brukbare systemdeler foreligger n Inkrementell integrasjon og testing – Lettere å isolere feil – Repetere tidligere tester n Ikke alltid så enkelt
Inkrementell integrasjonstesting
Top-down testing
Bottom-up testing
Sammenlikning Top-down vs. Bottom up n Arkitekturvalidering n Systemdemonstrasjons n Testimplementering n Testobservasjon n. I virkeligheten brukes ofte en blanding
Grensesnitt-testing
Grensesnittesting n Skjer under integrasjon n Målet er å finne feil som oppstår pga av misoppfattelser av grensesnitt n Viktig for objektorienterte systemer n Grensesnittyper – Parametergrensesnitt – Delt hukommelsesgrensesnitt – Prosedyralt grensesnitt – Meldingsutvekslingsgrensesnitt
Grensesnittesting n Feiltyper – Misbruk av grensesnitt – Misforståelse av grensesnitt – Feil ved timing n Kan være vanskelige å finne – Overflyt – Feil påvirker hverandre n Retningslinjer for grensesnittesting – – – Inspiser kildekoden for å finne kall Lag tester med ekstreme verdier Lag tester med nullpekere Ved prosedyrale grensesnitt – lag feil Bruk stress-testing i meldingsformidlings grensesnitt Ved kommunikasjon gjennom delt hukommelse: Test med varierende tilgangsrekkefølge – Statiske teknikker er ofte lønnsomme ved grensesnittesting
Stress-testing Ferdigintegrerte systemer kan testes på ikke funksjonelle egenskaper n Ytelsestester ofte med økende belastning forbi spesifisert ytelse til systemet svikter. n Formål: n – Sjekke hvordan systemet ter seg under overbelastning. Fail soft, Fail to safe. – Finne feil som oppstår ved høy belastning n Spesielt relevant for distribuerte systemer
Objektorientert testing n Dette blir gitt 30. 10
- Referere til forelesning
- Kap kap kape voda
- Kap 140 autopilot ils approach
- Kap 140 autopilot
- Sommerville
- Sommerville software engineering slides
- Sommerville
- Inżynieria oprogramowania ian sommerville
- Sommerville
- Change management in software testing
- Sommerville
- Engineering software products ian sommerville
- Ian sommerville software engineering
- Sommerville
- Sommerville
- Elaine sommerville
- Damian sommerville
- Sommerville
- Vinkelakselerasjon
- Budget företagsekonomi
- Kap lithinon
- Kap heliantono dan rekan surabaya
- Kap tools
- Sawadeekrap
- Kp fastigheter
- Kap modellen
- Etapas de cambio de prochaska y diclemente
- Kap kut
- Hyreslagen jordabalken kapitel 12
- Kovalent binding
- Isi client representation letter
- 2. kap yemekler
- Kap framework
- Microsoft transaction server
- Lgr11 kap 4
- Kap 9