Programvaretesting In 140 Sommerville kap 20.

Presentasjon om: "Programvaretesting In 140 Sommerville kap 20."— Utskrift av presentasjonen:

1 Programvaretesting In 140 Sommerville kap 20

2 Mål Forstå noen test-teknikker som brukes for å finne programfeil
Kjenne til retningslinjer for testing av komponentgrensesnitt Forstå noen tilnærmingsmetoder for testing av komponenter og integrasjon av objektorienterte systemer Forstå hvordan CASE-verktøy kan støtte testing

3 Testing og OO OO skiller seg fra funksjonsorientert
Ikke klart skille mellom funksjoner og moduler. Ingen klar hierarkisk struktur. Ikke lett å skille komponent og integrasjonstesting

4 Defekttesting Finne feil før systemet leveres
Det gjelder å få systemet til å feile. Modell Test case Test data Test resultater Test rapport Testdata kan genereres automatisk Test case kan ikke genereres automatisk

5 Defekttestingsprosessen

6 Defekttesting – hvor grundig?
Uttømmende (Exhaustive) testing Sjekker alle mulige eksekveringsveier Umulig å gjennomføre Hvilket subset skal da testes? Alle programsetninger minst en gang Bygge på erfaringer fra bruk Alle menyfunksjoner testes Kombinasjoner av funksjoner på samme meny Teste alle innmatingsmuligheter med gyldige og ugyldige data

7 Black-box –testing 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

8 Black-box testing

9 Ekvivalenspartisjonering
Systemets inndata kan kategoriseres En ekvivalenspartisjon er en mengde inputdata som behandles likt Ekvivalenspartisjoner kan identifiseres fra spesifikasjonen Retningslinje: Velg data som ligger midt i ekvivalenspartisjone og på grensa – atypiske verdier. Disse blir ofte oversett og feilbehandlet av programmet.

10 Ekvivalenspartisjoner

11 Strukturell testing Kalles også White-Box testing
eller Glass-box, Clear box Bygger på kjennskap til programvarestrukturen Målet er å teste alle programsetninger Egnet for små programmoduler Analysere kode for å partisjonere

12 White-box testing

13 Path testing Formålet er å teste alle veier gjennom systemet
Alle vilkårssetninger kjøres med verdier som gir sann eller usann som resultat Antall muligheter proporsjonal med systemets størrelse. Metoden blir ugjennomførbar. Med sløyfer blir mulighetene fort "uendelige". Metoden tar utgangspunkt i flytdiagrammer

14 Flytkart for binærsøk

15 Flytdiagrammer Bare vilkårssetninger og sløyfer
Hensikten er å utføre alle uavhengige løp Et uavhengig løp går gjennom minst en ny kant Lage testdata som kjører alle løp. Ikke enkelt på kompliserte program Dynamiske programanalysatorer

16 Integrasjonstesting Utvikles fra spesifikasjon
Settes i gang så snart brukbare systemdeler foreligger Inkrementell integrasjon og testing Lettere å isolere feil Repetere tidligere tester Ikke enkelt

17 Inkrementell integrasjonstesting

18 Top-down testing

19 Bottom-up testing

20 Sammenlikning Top-down vs. Bottom up
Arkitekturvalidering Systemdemonstrasjons Testimplementering Testobservasjon I virkeligheten brukes ofte en blanding

21 Grensesnitt-testing

22 Grensesnittesting Skjer under integrasjon
Målet er å finne feil som oppstår pga av misoppfattelser av grensesnitt Viktig for objektorienterte systemer Grensesnittyper Parametergrensesnitt Delt hukommelsesgrensesnitt Prosedyralt grensesnitt Meldingsutvekslingsgrensesnitt

23 Grensesnittesting Feiltyper Kan være vanskelige å finne
Misbruk av grensesnitt Misforståelse av grensesnitt Feil ved timing Kan være vanskelige å finne Overflow Feil påvirker hverandre 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

24 Stress-testing Ferdigintegrerte systemer kan testes på ikke funksjonelle egenskaper Ytelsestester ofte med økende belastning forbi spesifisert ytelse til systemet svikter. Formål: Sjekke hvordan systemet ter seg under overbelastning. Finne feil som oppstår ved høy belastning Spesielt relevant for distribuerte systemer

25 Objektorientert testing
Forskjeller mellom OO og funksjonsorientert Objekter er større enn enkeltfunksjoner Objekter er løst koblet Ingen klar hierarkisk struktur Gjenbrukskomponenter kan mangle kildekode Fire testnivåer Test av enkeltoperasjoner Testing av enkeltobjektklasser Klyngetesting OO-systemtesting

26 Komplett objekttesting
Alle enkeltoperasjoner alene tilordning og spørring på alle attributter Gjennomkjøring av alle tilstander Alle tilstandsendrende hendelser for hver tilstand må prøves

27 Tilstandsdiagram for værstasjon

28 Objektklassetesting Arv/polymorfisme Ekvivalensklasser for attributter
Arvede operasjoner må testes i alle underklasser Polymorfe operasjoner må testes Ekvivalensklasser for attributter

29 Objektintegrasjon Moduler eksisterer ikke, bare samarbeidende objekter
Klynge (Cluster)-testing Intet hierarki, men danner funksjonalitet. Testemetoder Use Case/Scenario – basert Thread-testing Objektinteraksjonstesting Method-message path (Alle metodekall fullført) Atomic System Function (Input – Output)

30 Use Case/Scenariobasert testing
Ofte effektivt Bygger på Use Case Kryss av utførte metoder Alle metoder må være testet Kollaborasjonsdiagram kan brukes Planlegge hva som må settes opp og hva som må sjekkes

31 Kollaborasjonsdiagram

32 Testbenk (Testing workbenches)