Begreber og Redskaber 6

Afprøvning Formål: •Ekstern afprøvning (Funktionstest). •Hvordan dokumenterer man afprøvning i en rapport. •Hvordan konstuerer man et program så det kan afprøves. •Overblik over andre afprøvningsteknikker.

Faser i programmering Ikke tidsmæssigt separate faser: •Analyse og design –Afklar hvad der skal laves •Programmering •Indkøring (test) –Find fejl •Afprøvning –Dokumenter programmets pålidelighed

Programmering Generelt: •Undgå at programmere meget af gangen. –Gør det nemt at finde ud af hvor fejl er. Taktik: •Top-down (Step-wise refinement). –Del programmet i faser. Lav ”dummy” versioner af de fleste. Gentag evt for faserne. •Bottom-up –Programmer en mindre del, der kan bruges til programmet. Indkør og afprøv det separat.

Top-down (1) static public void main(String[] args){ System.out.println(”Hello”); } •Check at man faktisk kan få oversætteren til at virke og at man kan afvikle et program

Top-down (2) static public void main(String[] args){ indlaes(); behandl(); udskriv(); } int i,j; static public void indlaes(){ i=3; } static public void behandl(){ j=i; } static public void udskriv(){ System.out.println(j); } •Første opdeling i nogle faser.

Bottom-up •Find afgrænsede problemstillinger som kan løses separat. •Løs dem – og gerne lettere generaliseret. •Indkør og afprøv dem separat i kunstige indkøringsomgivelser (stubbe). •Når programdelen indsættes i det endelige program testes integrationen •(unit test – integration test)

Indkøring •Brug testudskrifter boolean test=true; if(test) System.out.println(..); •Kunsten er: ikke for få – så man ikke ved hvor der er fejl – og ikke for mange – så man mister overblik. •Slå dem fra når en del virker. Brug evt flere test-variable. •Test fejl, der ”ikke kan ske” •Robust software kan selv diagnosticere fejl

Afprøvning •Overvej Afprøvningsstrategi –Taktik, niveau af pålidelighed •White-box (hvor man kender programtekst) –Intern afprøvning (structural test) –Kode gennemgang (inspektion, review) –Bevisførelse (verification). •Black-box (hvor man kun kender programmets funktion). –Ekstern afprøvning (function test)

Ekstern afprøvning Funktionstest •Fra en beskrivelse af hvad programmet skal konstrueres testdata: –Prøv med forskellige typer af ”typiske data” –Prøv med grænsetilfælde af korrekt og forkert inddata. •Ide: Man prøver med mindst en repræsentant for hver gruppe af inddata, der forventes behandlet på samme måde

Testtilfælde Eksempel: Find største af liste tal. Testtilfælde: fejl1Tom liste fejl2Andre tegn end cifre i listen input1Kun et tal i listen input2To ens tal input3To tal, voksende input4To tal, faldende input5Tre tal, voksende input6Tre tal, faldende input7Tre tal, største i midten

Præsentation Test:inddataForventet uddata fejl1(ingenting)fejl fejl212 a 3fejl input113 input226 input input input input input

Opstilling af testtilfælde •Med for mange testtilfælde bliver det uoverskuelligt. Svært at overskue mere end 7-10 ting ad gangen. •Lav opdeling hierarkisk: måske 7-10 testgrupper a 7-10 testtilfælde. •Et inddata sæt kan måske dække flere testtilfælde. •I særlige tilfælde kan man overskue mere: –Grammatik –”prøv med første og sidste dato i hver måned”

Overvej •Vi har program der genkender palindrome binære tal (binære tal, med samme cifre læst forfra eller bagfra). •Konstruer ekstern afprøvning af programmet.

Principper for testtilfælde •Undgå at teste for kombinationer af mulige fejl. (antallet eksploderer bare). •Testtilfælde kan opstilles før programmering – evt til afklaring i analysen •Hellere få udvalgte gode testtilfælde. Forsøg på at ”tæppebombe” programmet er sjældent nyttigt. •Afprøvningen virker overbevisende ved at være systematisk og gennemtænkt.

Intern afprøvning Structural test •Alle kodelinier skal gennemløbes •Alle betingelser skal prøves med sand og falsk •Alle løkker skal prøves med mindste antal gennemløb og med flere gennemløb. •Tungt i projektrapporter

Programgennemgang Kode review •Programmøren gennemgår sit program for gruppen. Gruppen prøver at finde fejl ved opklarende spørgsmål. •Ofte viser fejl sig ved at programmøren pludselig har svært ved at forklare en del af programmet.

Andre afprøvningstyper •Maskinnedbrud –Hvordan reagerer programmet ved maskinnedbrud. Tabes data? Kan det bare genstartes? •Sikkerhedstest –Hvor modtageligt er programmet for indbrudsforsøg •Ydeevne –Stresstest, respondstider

Særligt for OO software •Bottom-up testing af klasser/objekter •Objektets tilstand og metodekald er ”input” i ekstern afprøvning •Metode interaktion: test rækkefølge af kald. Kan felter bruges før de initialiseres? •Test nedarvning. Test af om klasser også fungerer fornuftigt når der arbejdes med nedarvede klasser.

Sammenfatning •Ekstern afprøvning. •God måde at overbevise en læser af en rapport om at ens program faktisk virker. •Afprøvning kan tilrettelægges uafhængigt af programmering. •Andre afprøvningsteknikker kan også overvejes.