Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Programvaretesting In 140 Forelesning Nr 17 Sommerville kap 20.

Liknende presentasjoner


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

1 Programvaretesting In 140 Forelesning Nr 17 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 Introduksjon 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

4 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

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

6 Defekttestingsprosessen

7 Defekttesting – hvor grundig? Uttømmende (Exhaustive) testing –Sjekker alle mulige eksekveringsveier –Umulig å gjennomføre Hvilken delmengde 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

8 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

9 Black-box testing

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

11 Ekvivalenspartisjoner

12 Eksempel søkerutinespesifikasjon

13 Søkerutine 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.

14 Retningslinjer ved testing av sekvenser Test med sekvenser som bare har ett medlem Bruk sekvenser med forskjellig antall elementer Lag tester der du skal finne første siste eller midterste element

15 Inndatapartisjoner og testdata ArrayElement Enkelt elementI sekvens Enkelt elementIkke i Sekvens Mer enn 1 elementFørste element i sekvens Mer enn 1 elementSiste element i sekvens Mer enn 1 elementMidtre element i sekvens Mer enn 1 elementIkke i sekvens Inndata Sekvens ( T )Key ( Key )Utdata ( Found, L ) 1717Sann, 1 170Usann, ?? 17, 29, 21, 2317Sann, 1 41, 18, 9, 31, 30, 16, 4545Sann, 7 17, 18, 21, 23, 29, 41, 3823Sann, 4 21, 23, 29, 33, 38 25Usann, ??

16 Begrensninger ved Black Box testing Parametere med feil rekkefølge og type Datakorrupsjon pga feil utenfor modulen som testes Bruk heller –Inspeksjon –Automatisk statisk analyse

17 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

18 White-box testing

19 Binærsøk (Java)

20 Ekvivalenspartisjoner for binærsøkrutinen

21 Binary search - test cases

22 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 flytkart

23 Flytkart for binærsøk

24 Flytkart 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

25 Syklomatisk kompleksitet (Mc Cabe 1976) CC(G)=Antall kanter-Antall noder +2 Hvis ingen goto setninger er CC=antall vilkårssetninger +1 Lage testdata som kjører alle løp. Ikke like enkelt på kompliserte program Dynamiske programanalysatorer

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

27 Inkrementell integrasjonstesting

28 Top-down testing

29 Bottom-up testing

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

31 Grensesnitt-testing

32 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

33 Grensesnittesting Feiltyper –Misbruk av grensesnitt –Misforståelse av grensesnitt –Feil ved timing Kan være vanskelige å finne –Overflyt –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

34 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. Fail soft, Fail to safe. –Finne feil som oppstår ved høy belastning Spesielt relevant for distribuerte systemer

35 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

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

37 Tilstandsdiagram for værstasjon

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

39 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)

40 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

41 Kollaborasjonsdiagram

42 Testbenk (Testing workbenches)

43 Testbenkverktøy (Tools for testing workbenches) Testmanager Testdatagenerator Orakel Filkomparator Rapportgenerator Dynamisk simulator Simulator

44 Testbenk Tilpasning –Nye verktøy må legges til –Skript for brukersimulator –Mønstre for testdatageneratorer –Manuell beregning av ventede resultater –Spesiallagde filkomparatorer Brukes på store systemer for å gjøre testing mulig og redusere testkostnad

45 Hovedpoenger1 De mest brukte systemdelene bør testes mest. Ekvivalenspartisjonering for å finne testdata Grenseverdier gir ofte vellykket testing Black-box testing kan gjøres uten kildekode Strukturell (White-box testing) for å finne eksekveringsveier og testdata Integrasjonstesting fokuserer på interaksjoner og grensesnitt Grensesnittdefekter –manglende spesifikasjonsforståelse –Timingsproblemer

46 Hovedpoenger 2 Testing av objektklasser –Kjøre alle operasjoner –Sette og lese av alle attributter –Teste objektet i alle tilstander Objektorienterte systemer –integreres som naturlig objektklynger som hører til et bestemt use-case


Laste ned ppt "Programvaretesting In 140 Forelesning Nr 17 Sommerville kap 20."

Liknende presentasjoner


Annonser fra Google