Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Programvaretesting In 140 Sommerville kap 20. Mål  Forstå noen test-teknikker som brukes for å finne programfeil  Kjenne til retningslinjer for testing.

Liknende presentasjoner


Presentasjon om: "Programvaretesting In 140 Sommerville kap 20. Mål  Forstå noen test-teknikker som brukes for å finne programfeil  Kjenne til retningslinjer for testing."— 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 –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 –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)


Laste ned ppt "Programvaretesting In 140 Sommerville kap 20. Mål  Forstå noen test-teknikker som brukes for å finne programfeil  Kjenne til retningslinjer for testing."

Liknende presentasjoner


Annonser fra Google