Struktureret ProgramUdvikling MM 5

Modul placering

Andre væsentlige Software discipliner Reviews konsekvent gennemført Projektstyring Programdokumentation Konfigurationsstyring Vedligeholdelse Projektgruppe sammensætning/Team building

ANSI/IEEE Standards(Gamle!)

Faser i SPU-modellen

V-model

SPU-Valuering

Holdning til test(Boris Beizar) Fase 0 holdning : Ingen forskel mellem test og debug Fase 1 holdning : Viser blot at software virker Fase 2 holdning : Viser at software ikke virker(Fjenden) Fase 3 holdning : Test skal reducere risikoen, Der vil være fejl Fase 4 holdning : Holdning der tænker test ind i design og implementation. Denne holdning reducere testarbejdet og gør programmerne testbare. Thinking = holdning

Test design ( Boris Beizar) Explicit testdesign: ikke: Design, kode, desk chesk, test and debug men: Design, testdesign, kode, test kode, programexpection, test inspektion, test debugging, test execution, program debugging testing

Endnu et formål ( Boris Beizar) Formålet med test er at vise at der er fejl Formålet med debug er at finde årsagen til fejlen og designe og implementere programændringer som retter fejlen

Mennesker laver fejl(Meizer) Ligegyldigt hvor godt vi koncentreret os og ligegyldigt hvor gode vi er til struktureret programmering, ligegyldigt hvilke værktøjer vi har tilrådighed, så laver vi fejl. DERFOR: Test og testdesign er midlet til at få foretaget ordentlige og grundige afprøvninger inden afleveringen (release) Har I eksempler på at ovenstående ikke er udført i tilstrækkeligt omfang???

Testvurdering Program kvalitet og pålidelighed er tilstrækkelig Testen er utilstrækkelig til at finde fejl Testfasen og dens planlægning er vigtig fordi: Design af test skal have den højest mulige sandsynlighed for at finde fejl, med den mindst mulige anstrengelse.

Testbarhed Operabilitet: Jo bedre det virker, jo mere effektivt kan det testes Observerbarhed: Hvad du ser er hvad du tester Kontrollerbarhed: Jo bedre vi kan kontrollere programmet, jo bedre kan vi automatisere eller optimere testen Dekomponerbarhed: Giver mulighed for hurtig isolation af og giver mulighed for smartere tests Simplicitet: Jo mindre der er at teste jo hurtigere kan det gøres Stabilitet: Ændringer foretaget på p.g.a. Fejl ændre ikke tidligere værdien af tidligere foretagne testprocedurer Forståelighed: Jo større forståelse for programmet jo smartere test

Fejlfordeling(Boris Beizer) Requirements 8% Egenskaber og funktionalitet 16% Struktur fejl 25% Data definition/adgang 22% Implementation 10% Integration 9% System Software arkitektur 2% Test definition/udførelse 3% Andet 5%

Testplanlægning/afvikling Program Fejl Korrektion Test Vurder Debug Fejl rate Testresultat Testprogram Pålideligheds model Prædikteret pålidelighed

Typer af test White Box: Lad os kontrollere det inden i Black Box: Lad os se om det virker systemmæssigt Event handling: Lad os se om data fra alle mulige events behandles og bringer os(vore processer) i ønskede tilstande

Testtid ved 100% gennemløb Loop<=20 Hver statement 0,1msek Testtid???

Basis sti-testning

Flow-graf præsentation

Fra Psedosprog til flowgraf Procedure average; {Initialiseringer} i=1; total.input=total.valid=sum=0; DO WHILE value[i] <> stop AND total.input < 100 i++; IF value[i] >= minimum AND value[i] <= maximum THEN total.valid++; sum = sum + value[i]; ELSE skip ENDIF ENDDO IF total.valid>0 THEN average = sum/ total.valid; ELSE average = stop; END average

Sløjfe typer

Eksempel på Modultest

Integrations rækkefølge Bottom up integration kræver drivere Top down integration kræver stuppe 2 enheder kædes ikke sammen uden at den ene er testet Enheder føjes til en efter en – godt for grænseflade kontrol

Proces-test

Proces-integrationstest

Realtids test Processererne er testede enkeltvis (White,Black box) Hændelser og typer af hændelser testes ordnet derefter i vilkårlig rækkefølge for den enkelte proces Proceskommunikation gennem køer eller datalager testes Testene øges til direkte stress-tests

Dogmer for nye IT-projekter http://www.ddf.dk/fagraad/organisation_og_it/dogmer.htm Forslagene er udtrykt som 10 dogmer for offentlige IT-projekter. Det er tanken, at efterlevelsen af disse dogmer kan reducere risikoen for skandaler og øge udbyttet af de offentlige IT-kroner. De 10 dogmer har følgende overskrifter: Foranalyse og planlægning Ansvarlig og kvalificeret kontraktindgåelse Modulopdelte projekter Konsulentkvalifikationer Kundens kvalifikationer Realistiske mål med politisk accept Projektansvar Standardkontrakter og udbudsregler Valg af system Organisatorisk implementering Dogmerne er beskrevet med en kort uddybende forklaring og forslag til konkrete initiativer.