Arbejdsmetoder

Log på

Brugernavn:
Email:
Kodeord:

Kontakt ZieglerSoft

Navn:
Email:
Afhængigt af kundens ønsker, og den enkelte opgaves karakter, kan vi benytte en eller flere metoder i vores programmering af løsningen.

På denne side vil vi vise nogle af disse metoder, sammen med en kort beskrivelse af disse.
En af de mest brugte metoder, selvom der findes mange nu om dage, er almindeligt cirkulært design, der er vist i dette diagram.



Denne metode består i, at der startes op med en analyse af behovet (hvilket kan være en stor del af et projekt).
Næste punkt i cyklussen er, at få lavet et design der lever op til det der blev fundet ud af under analysen.

Designet testes (hvis muligt) sammen med kunden, og eventuelle ændringer udføres.
Herefter laves den egentlige programmering, der efterfølges af test af det (næsten) færdige produkt.

Endeligt sættes produktet i drift (implementering).

Fra dette punkt, vil det være muligt at genstarte cyklussen med en analyse del igen (f.eks. for at nå frem til næste version af produktet).

Unit Testing

Unit testing kan være en del af TDD (Test Driven Development), men kan også bruges alene eller som en del af en udvikling.

Unit testing er en metode, hvor individuelle dele af softwaren bliver testet. Formålet er at teste de enkelte smådele af et program udfører den ønskede opgave uden fejl.

Unit test isolerer en sektion kode og kontrollerer at det virker korrekt. En unit kan være en enkelt funktion, en metode, en procedure, et modul eller f.eks. et objekt.

Testen skrives af programmøren, og som regel inden der skrives nogen kode.

Unit testing hjælper med at finde fejl meget tidligt i kodningen, og vil på den måde spare tid.

Unit testing hjælper programmøren til hurtigt at forstå og ændre i koden.

De skrevne test kan også benyttes som en del af dokumentationen.

Integration Testing

Her testes integrationen mellem dele af projektet med hinanden som grupper. Et softwareprojekt består normalt af mange forskellige moduler, måske endda programmeret af flere forskellige programmører.

Formålet med denne type test er, at finde defekter ved samarbejdet mellem alle disse software moduler, når de sættes til at tale sammen.

Et modul er måske programmeret af en programmør, der forstår hele opgaven anderledes end øvrige programmører på det samlede projekt. Derfor skal disse test finde, afsløre og endeligt resultere i at evt. forskelle udbedres.

System Testing

Næste skridt, når alt er testet og fundet OK, er System Testing, hvor det komplette og fuldt integrerede software produkt valideres.

Formålet med denne test er at teste systemet igennem fra ende til anden i forhold til specifikationerne.

Normalt er softwaren jo bare en del af et helt system.

Ultimativt vil softwaren blive testet op mod de øvrige systemer det skal samarbejde med. System testing er en serie af forskellige test, hvis samlede formål er at gennemprøve det fulde computer-baserede system.

TDD - Test Driven Development

En simpel men effektiv teknik i programudvikling. Den består i korte træk af tre ting:
  • Skriv en test, så simpelt som muligt, der fejler
  • Skriv så lidt kode som muligt, der får testen til at virke
  • Ryd op i koden, og udvid den, men uden at testen fejler

Hver gang du er igennem en cirkel i udviklingen, startes forfra igen.

Logiske fejl i koden opdages nemmere, og er lettere at rette. Samtidig giver en omfattende pakke af tests gode muligheder for at opdage, hvis en rettelse skaber en fejl i et andet modul. En omfattende test-pakke giver en højere fortrolighed med produktet, og gladere og mindre stressede programmører.

Tests er en fremragende måde at dokumentere softwaren på, da de giver konkrete eksempler på brugen af softwaren. Samtidig giver tests et godt overblik over softwarens aktuelle tilstand.

BDD - Behavior Driven Development

En udvidelse af TDD - Test Driven Development, er BDD - Behavior Driven Development.

Også her startes med en test, der fejler, men her ses det fra brugerens synspunkt, og ikke programmørens.

I TDD, der er jeg ligeglad med hvad der kommer ud (så længe det passer med testen). Testen skal bestås.

I BDD, der er jeg ligeglad med, hvordan vi kommer frem til et output, sålænge outputtet er korrekt.

BDD har en stor fordel her, da selve testen er skrevet i et beskrivende engelsk, og ikke i kode. Dette betyder at slutbrugeren forstår testen, og kan levre feedback på denne.

I TDD er det ikke forståeligt for andre end programmøren, hvordan testen virker.

Selvom vi siger at BDD måske er bedre end TDD, skal vi huske, at BDD er udviklet fra TDD, for at fjerne de evt. dårligdomme der kunne opstå ved brug af TDD. Så at bruge begge vil faktisk være en fordel - en metode til at sikre god kvalitet i koden, og en der tilgodeser slutbrugeren, ved at beskrive systemet set fra dennes side.
 f     in     t    +45 9811 3772    UK  
Kontakt ZieglerSoft