- Enhedstest vs. integrationstest vs. funktionel test
- Hvad er Unit Testing?
- Hvad er integrationstest?
- Test af enheder vs. integrationstest
- Funktionel afprøvning
- Konklusion
- Anbefalet læsning
En detaljeret sammenligning af enheds-, integrations- og funktionel test:
For enhver softwareapplikation er både enhedstest og integrationstest meget vigtige, da de hver især anvender en unik proces til at teste en softwareapplikation.
Men ingen af dem eller begge dele kan erstatte funktionel testning på noget tidspunkt.
Enhedstest vs. integrationstest vs. funktionel test
Test af enheder betyder at teste individuelle moduler i en applikation isoleret (uden interaktion med afhængigheder) for at bekræfte, at koden gør tingene rigtigt.
Integrationstest betyder at kontrollere, om forskellige moduler fungerer fint, når de kombineres sammen som en gruppe.
Funktionel afprøvning betyder at teste en del af funktionaliteten i systemet (kan interagere med afhængigheder) for at bekræfte, at koden gør de rigtige ting.
Funktionelle test er beslægtet med integrationstest, men de er test, der kontrollerer hele applikationens funktionalitet med al koden kørende sammen, næsten en super integrationstest.
Ved enhedsafprøvning kontrolleres en enkelt komponent i systemet, mens funktionalitetstestning kontrollerer, om en applikation fungerer i forhold til den tilsigtede funktionalitet, der er beskrevet i specifikationen af systemkravene. På den anden side kontrolleres integrerede moduler i systemet ved integrationstestning.
Og vigtigst af alt, for at optimere investeringsafkastet (ROI) bør din kodebase have så mange enhedstests som muligt, færre integrationstests og færrest mulige funktionelle tests.
Dette illustreres bedst i den følgende testpyramide:
Enhedstest er lettere at skrive og hurtigere at udføre. Tiden og indsatsen for at implementere og vedligeholde testene stiger fra enhedstest til funktionel testning, som vist i pyramiden ovenfor.
Eksempel:
Lad os forstå disse tre typer af testning med et forsimplet eksempel.
E.g De vigtigste dele, der er nødvendige for en funktionel mobiltelefon, er "batteri" og "sim-kort".
Eksempel på enhedsafprøvning - Batteriet kontrolleres med hensyn til levetid, kapacitet og andre parametre. Sim-kortet kontrolleres med hensyn til aktivering.
Eksempel på integrationstest - Batteri og sim-kort er integreret, dvs. samlet, for at mobiltelefonen kan starte.
Eksempel på funktionel afprøvning - En mobiltelefons funktionalitet kontrolleres med hensyn til dens funktioner og batteriforbrug samt simkortfaciliteter.
Vi har set et eksempel i lægmandstermer.
Lad os nu tage et teknisk eksempel på en login-side:
Næsten alle webapplikationer kræver, at brugerne/kunderne logger ind. Derfor skal alle applikationer have en "Login"-side, som indeholder disse elementer:
- Konto/brugernavn
- Adgangskode
- Knap til at logge ind/tilmelde dig
I forbindelse med enhedstest kan følgende være testcases:
- Feltlængde - felter for brugernavn og adgangskode.
- Indtastningsfeltets værdier skal være gyldige.
- Login-knappen aktiveres først, når der er indtastet gyldige værdier (format og længde) i begge felter.
I forbindelse med integrationstest kan følgende være testcases:
- Brugeren ser velkomstbeskeden efter at have indtastet gyldige værdier og trykket på login-knappen.
- Brugeren skal navigeres til velkomstsiden eller forsiden efter en gyldig indtastning og et klik på Login-knappen.
Når enheds- og integrationstest er udført, skal vi nu se de yderligere testcases, der tages i betragtning til funktionel testning:
- Den forventede adfærd kontrolleres, dvs. om brugeren er i stand til at logge ind ved at klikke på login-knappen efter at have indtastet et gyldigt brugernavn og en gyldig adgangskode.
- Er der en velkomstmeddelelse, der skal vises efter et vellykket login?
- Er der en fejlmeddelelse, der skal vises ved et ugyldigt login?
- Er der lagrede cookies på webstedet for loginfelter?
- Kan en inaktiveret bruger logge ind?
- Er der et link til at glemme adgangskoden for brugere, der har glemt deres adgangskode?
Der er mange flere tilfælde, som en funktionel tester kan komme til at tænke på, når han udfører funktionel testning. Men en udvikler kan ikke tage alle tilfælde med, når han opbygger enheds- og integrationstestcases.
Der er således masser af scenarier, som endnu ikke er testet, selv efter enheds- og integrationstest.
Det er nu tid til at gennemgå enheds-, integrations- og funktionstest en for en.
Hvad er Unit Testing?
Som navnet antyder, omfatter dette niveau test af en "enhed".
Her kan unit være den mindste del af en applikation, der kan testes, det være sig den mindste individuelle funktion, metode osv. Softwareudviklere er dem, der skriver unit-testcases. Målet her er at matche kravene og unitens forventede adfærd.
Nedenfor er nogle få vigtige punkter om unit testing og dets fordele:
- Enhedstest udføres før integrationstest af softwareudviklere ved hjælp af white box-testteknikker.
- Enhedstest kontrollerer ikke kun den positive adfærd, dvs. det korrekte output i tilfælde af gyldigt input, men også de fejl, der opstår ved ugyldigt input.
- Det er meget nyttigt at finde problemer/fejl på et tidligt tidspunkt, og det reducerer de samlede projektomkostninger. Da enhedstestning udføres før integration af kode, kan problemer, der findes på dette tidspunkt, meget let løses, og deres indvirkning er også meget mindre.
- En enhedstest tester små stykker kode eller individuelle funktioner, så de problemer/fejl, der findes i disse testcases, er uafhængige og påvirker ikke de andre testcases.
- En anden vigtig fordel er, at enhedstestcases forenkler og gør det nemmere at teste koden. Det bliver således også nemmere at løse problemerne på et senere tidspunkt, da det kun er den seneste ændring i koden, der skal testes.
- Enhedstest sparer tid og omkostninger, og de kan genbruges og er lette at vedligeholde.
JUnit (Java framework), PHPUnit (PHP framework), NUnit (.Net framework) osv. er populære enhedstestværktøjer, der bruges til forskellige sprog.
Hvad er integrationstest?
Integrationstestning er testning af integrationen af forskellige dele af systemet sammen. To forskellige dele eller moduler af systemet integreres først, og derefter udføres integrationstestning.
Formålet med integrationstest er at kontrollere systemets funktionalitet, pålidelighed og ydeevne, når det er integreret.
Integrationstest udføres på de moduler, der først er enhedstestet, og derefter defineres det ved integrationstest, om kombinationen af modulerne giver det ønskede resultat eller ej.
Integrationstest kan enten udføres af uafhængige testere eller også af udviklere.
Der findes 3 forskellige typer af integrationstestmetoder, som vi kort vil gennemgå hver enkelt af dem:
a) Big Bang-integrationstilgang
Ved denne fremgangsmåde integreres og testes alle moduler eller enheder som en helhed på én gang. Dette sker normalt, når hele systemet er klar til integrationstest på et enkelt tidspunkt.
Du må ikke forveksle denne tilgang til integrationstest med systemtest, da kun integrationen af moduler eller enheder testes og ikke hele systemet, som det er tilfældet i systemtest.
Big Bang-tilgangens vigtigste fordel er, at alt integreret testes på én gang.
En vigtig ulempe er, at det bliver vanskeligt at identificere fejlene.
Eksempel: I figuren nedenfor er enhed 1 til enhed 6 integreret og testet ved hjælp af Big bang-metoden.
b) Top-Down-tilgang
Integrationen af enhederne/modulerne testes trin for trin fra top til bundniveau.
Den første enhed testes individuelt ved at skrive test STUBS. Herefter integreres de lavere niveauer et efter et, indtil det sidste niveau er samlet og testet.
Top-down-tilgangen er en meget organisk måde at integrere på, da den er i overensstemmelse med, hvordan tingene foregår i det virkelige miljø.
Den eneste bekymring med denne fremgangsmåde er, at den vigtigste funktionalitet testes til sidst.
c) Bottom-up-tilgang
Enheder/moduler testes trin for trin fra det nederste til det øverste niveau, indtil alle niveauer af enheder/moduler er integreret og testet som én enhed. Stimulatorprogrammer kaldet DRIVERS Det er lettere at opdage problemer eller fejl på de lavere niveauer.
De vigtigste ulempe ved denne fremgangsmåde er, at de overordnede spørgsmål først kan identificeres til sidst, når alle enhederne er blevet integreret.
Test af enheder vs. integrationstest
Nu hvor vi har talt nok om enhedstest og integrationstest, skal vi hurtigt gennemgå forskellene mellem de to i følgende tabel:
| Test af enheder | Integrationstest |
|---|---|
| Tester den enkelte komponent af hele systemet, dvs. tester en enhed isoleret. | Test af systemkomponenter, der arbejder sammen, dvs. test af samarbejdet mellem flere enheder. |
| Hurtigere at udføre | Kan køre langsomt |
| Ingen ekstern afhængighed. Enhver ekstern afhængighed er mocked eller stubbed out. | Kræver interaktion med eksterne afhængigheder (f.eks. database, hardware osv.) |
| Enkel | Kompleks |
| Udført af bygherre | Udført af testeren |
| Det er en form for white box-testning | Det er en form for black box-testning |
| Udføres i den indledende fase af testen og kan derefter udføres når som helst | Skal udføres efter enhedsafprøvning og før systemafprøvning |
| Billig vedligeholdelse | Dyr vedligeholdelse |
| Udgår fra modulspecifikationen | Begynder fra grænsefladespecifikationen |
| Unit testing har et snævert anvendelsesområde, da det kun tjekker, om hvert enkelt lille stykke kode gør det, som det er beregnet til at gøre. | Den har et bredere anvendelsesområde, da den dækker hele ansøgningen |
| Resultatet af enhedstest er en detaljeret synlighed af koden | Resultatet af integrationstest er en detaljeret synliggørelse af integrationsstrukturen |
| Afdækker kun problemerne inden for de enkelte modulers funktionalitet. Afslører ikke integrationsfejl eller problemer på tværs af systemet. | Afdække de fejl, der opstår, når forskellige moduler interagerer med hinanden for at danne det samlede system |
Funktionel afprøvning
En black box-testteknik, hvor applikationens funktionalitet testes for at generere det ønskede output ved at give et bestemt input, kaldes "funktionel testning".
I vores softwaretestprocesser gør vi dette ved at skrive testcases i overensstemmelse med kravene og scenarierne. For enhver funktionalitet kan antallet af testcases, der skrives, variere fra én til mange.
Konklusion
Alle disse tre testtyper er korreleret.
For at opnå fuld dækning er det nødvendigt at have enhedstests for kodebaner/linjer, funktionelle tests og integrationstests for at sikre, at "enhederne" fungerer sammen på en sammenhængende måde.
Jeg håber, at denne artikel har givet dig en klar idé om enheds-, integrations- og funktionel testning samt deres forskelle, selvom der er meget mere til disse former for testning!!