Programvaretesting In 140 Sommerville kap 20 Ml Forst

Programvaretesting In 140 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

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 Modell n – – 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 mengde inputdata 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

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

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 flytdiagrammer n

Flytkart for binærsøk

Flytdiagrammer 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 n Lage testdata som kjører alle løp. n Ikke 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 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 – Overflow – 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. – Finne feil som oppstår ved høy belastning n Spesielt relevant for distribuerte systemer

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

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

Tilstandsdiagram for værstasjon

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

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

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

Kollaborasjonsdiagram

Testbenk (Testing workbenches)