Kvalitet og kvalitetssikring Review Test Tietgen Skolen Kriterier

Kvalitet og kvalitetssikring Review Test Tietgen Skolen

Kriterier for kvalitetssikring • Krav/mål skal være formulerede • Opfyldelsen de enkelte krav skal være målbar og skal være formuleret • Metode for måling skal være formuleret • Målbarheden skal være så objektiv som muligt • Målingen skal kunne dokumenteres • Der kan opstilles mål for såvel produkter som proces Tietgen Skolen

Design kriterier • Opdeling i – funktionelle egenskaber Kan de specificerede funktioner udføres – ikke funktionelle egenskaber (Se også OOAD side 181) • robusthed • brugervenlighed • effektivitet • vedligeholdelsesegnethed • flytbarhed • fleksibilitet og forståelighed (her er et princip at tilstræbe høj samhørighed og lav kobling) Tietgen Skolen

Reviewteknikker • • Walk through Fortolkende review Inspektion Godkendende review Tietgen Skolen

Review • Et møde, hvor et produkt vurderes: • Forløb: 1. 2. 3. 4. Mindst to reviewere Krav til produkt foreligger Produkt foreligger og reviewere er udpeget Evt. Orienteringsmøde Individuel forberedelse 5. Review 6. Referat og bilag foreligger Tietgen Skolen Godkendt, godkendt med mindre ændringer, nyt review, …

Roller • • Ordstyrer Referent Reviewere Producenter Ikke producenter, ikke producenters chefer Høre efter, ikke forsvare sig, men lære Tietgen Skolen

Om test • Test udføres altid i henhold til specifikationer. • En test kan aldrig påvise korrekthed - kun tilstedeværelse af fejl! • En succesfuld test finder fejl!!! • Udvikleren skal ikke teste sig selv. • Et system er færdigtestet, når hyppigheden af fejl er reduceret til et forretningsmæssigt acceptabelt niveau!! Tietgen Skolen

Testmodel – V-modellen Tietgen Skolen

Testmodel En samling af – test-cases – test-procedurer – eksekverbare komponenter, som tester Omfatter typer af test: – modultest eller unit-test (klasseniveau) – integrationstest – systemtest Tietgen Skolen

Modultest (unit-test) • Alle en klasses metoder skal testes • Black-box test udfra specifikation (preog post-betingelser) • White-box test udfra kendskab til intern struktur: – test grænsetilfælde og normaltilfælde • Brug drivere og stubbe Tietgen Skolen

Integrations- og systemtest • Integrationstest skal finde fejl i måden moduler spiller sammen på og udføres efter hvert build. (Design by Contract er vigtigt. ) • Systemtest skal finde fejl i systemet som helhed og udføres i slutningen af hvert gennemløb af implementationsprocessen Tietgen Skolen

Test-cases • Test-cases findes udfra brugsmønstre(use-case) modellen • Hver test-case tester et scenarium for et brugsmønster (use-case) • En test-case skal specificere input, forventet output og evt. betingelser for testen • Husk også belastningstest!!! Tietgen Skolen

Test-procedurer og komponenter • Test-procedurer specificerer hvordan en test gennemføres – kan være manuelle – eller - bedre - automatiske • Test-komponenter - eller drivere – automatisering af testprocedurer • Tilstræb design af test-procedurer og -komponenter, så der er så meget genbrug som muligt Tietgen Skolen

Nyt syn på test/XP e. Xtreme Programming (Kent Beck) • unit-test skrives før unit i en rytme, der siger: ”skriv en test - skriv unitten - test den - skriv den næste test. . . ” • dette har angiveligt følgende fordele: – unit-test bliver faktisk udført! – det giver en programmør tilfredshed at skrive en test, skrive noget kode og så se sin kode bestå testen – klassedesign bliver mere klart: man tvinges til at være helt præcis vedr. interface (metode-signaturer, specifikationer mv. ) – programverifikation bliver bedre dokumenteret – større lyst til at ændre eksisterende kode (refactoring), da testdriverne er klare og lige til at køre. Tietgen Skolen