Softwaretestmetoder: QA-modeller
⚡ Smart opsummering
Softwaretestmetoder definerer de strategier og testtyper, der bruges til at certificere, at en applikation opfylder kundens forventninger. Vandfalds-, iterativ-, agil- og ekstremprogrammering definerer hver især, hvornår testen starter, og hvordan feedback returneres.

Hvad er softwaretestmetode?
Softwaretestmetodologi er defineret som strategier og testtyper, der bruges til at bekræfte, at applikationen under test lever op til kundens forventninger. Testmetoder omfatter funktionel og ikke-funktionel test for at validere AUT. Eksempler på testmetoder er Enhedstest, Integrationstest, Systemtest, Test af ydeevne osv. Hver testmetode har et defineret testmål, teststrategi og leverancer.
Bemærk: Da softwaretest er en integreret del af enhver udviklingsmetodik, bruger mange virksomheder udtrykket udviklingsmetoder og testmetoder i daglig tale. Derfor kan testmetoder også henvise til vandfalds-, agile- og andre kvalitetssikringsmodeller i modsætning til ovenstående definition af testmetoder. Diskussion om forskellige testtyper tilføjer ikke værdi for læserne. Derfor vil vi diskutere de forskellige udviklingsmodeller.
Testmetode vs. testtype vs. teststrategi
Ovenstående note antyder en reel tvetydighed i branchen. Tre begreber bruges i flæng i samtalen, men betyder forskellige ting i et projektdokument, og at forveksle dem resulterer i testplaner, der besvarer det forkerte spørgsmål.
| Semester | Spørgsmål det besvarer | Besluttet af | Eksempler |
|---|---|---|---|
| Testmetode | Hvornår og hvordan passer test ind i udviklingscyklussen? | Udviklingsmodellen i brug | Vandfald, iterativ, agil, ekstrem programmering |
| Testtype | Hvilket aspekt af produktet verificeres? | Risiko- og kravdækning | Enhed, integration, system, ydeevne, sikkerhed |
| Testniveau | I hvilken dybde undersøges softwaren? | Placering i byggehierarkiet | Komponent, integration, system, accept |
| Test strategi | Hvad er vores organisatoriske tilgang til kvalitet? | QA-ledelse, gælder på tværs af projekter | Risikobaseret, automatisering først, skift til venstre |
| Testplan | Hvad vil dette projekt præcist teste, hvornår og af hvem? | Testleder, projektspecifik | Omfang, tidsplan, ressourcer, ind- og udgangskriterier |
En nyttig tommelfingerregel: metodologien sætter rytmen, typen sætter målet, og testplan registrerer forpligtelsen. Afsnittene nedenfor undersøger metoderne.
Vandfaldsmodel
Hvad er det?
I vandfaldsmodel, softwareudvikling fremskridt gennem forskellige faser som kravanalyse, design osv. – sekventielt.
I denne model begynder den næste fase først, når den tidligere fase er afsluttet.
Hvad er testmetoden?
Den første fase i vandfaldsmodellen er kravfasen, hvor alle projektets krav er fuldstændigt defineret, før testen påbegyndes. I denne fase brainstormer testteamet testomfanget, teststrategi og udarbejder en detaljeret testplan.
Først når designet af softwaren er færdig, vil teamet gå videre til udførelse af testcases for at sikre, at den udviklede software opfører sig, som den forventede.
I denne metode går testteamet først videre til næste fase, når den forrige fase er afsluttet.
| Fordele | Ulemper |
|---|---|
| Denne software Engineering-model er meget enkel at planlægge og administrere. Derfor kan projekter, hvor krav er klart defineret og angivet på forhånd, nemt testes ved hjælp af en vandfaldsmodel. | I vandfaldsmodellen kan du først begynde med den næste fase, når den forrige fase er afsluttet. Derfor kan denne model ikke rumme uplanlagte hændelser og usikkerhed. |
| Denne metode er ikke egnet til projekter, hvor kravene ændres ofte. |
Iterativ udvikling
Hvad er det?
I denne model opdeles et stort projekt i mindre dele, og hver del gennemgår flere iterationer af vandfaldsmodellen. Ved afslutningen af en iteration udvikles et nyt modul, eller et eksisterende modul forbedres. Dette modul integreres i softwarearkitekturen, og hele systemet testes samlet.
Hvad er testmetoden?
Så snart iterationen er afsluttet, testes hele systemet. Feedback fra test er umiddelbart tilgængelig og indarbejdes i næste cyklus. Den nødvendige testtid ved successive iterationer kan reduceres baseret på erfaringerne fra tidligere iterationer.
| Fordele | Ulemper |
|---|---|
| Den største fordel ved iterativ udvikling er, at testfeedback er umiddelbart tilgængelig i slutningen af hver cyklus. | Denne model øger kommunikationsomkostningerne betydeligt, da der i slutningen af hver cyklus skal gives feedback om leverancer, indsats osv. |
Agile metodologi
Hvad er det?
Traditionelle softwareudviklingsmetoder arbejder ud fra den forudsætning, at softwarekravene forbliver konstante gennem hele projektet. Men med en stigning i kompleksitet undergår kravene adskillige ændringer og udvikler sig løbende. Til tider er kunden ikke selv sikker på, hvad han vil have. Selvom den iterative model løser dette problem, er den stadig baseret på vandfaldsmodellen.
I Agile metodologi udvikles software i trinvise, hurtige cyklusser. Interaktioner mellem kunder, udviklere og klienter lægges vægt på frem for processer og værktøjer. Den agile metodologi fokuserer på at reagere på forandring frem for omfattende planlægning.
Hvad er testmetoden?
Inkrementel test bruges i agile udviklingsmetoder, og derfor testes hver udgivelse af projektet grundigt. Dette sikrer, at eventuelle fejl i systemet er rettet inden næste udgivelse.
| Fordele | Ulemper |
|---|---|
| Det er muligt at foretage ændringer i projektet til enhver tid for at overholde kravene. | Konstant klientinteraktion betyder øget tidspres på alle interessenter inklusive klienten selv, softwareudvikling og testteams. |
| Denne trinvise test minimerer risici. |
Ekstrem programmering
Hvad er det?
Ekstrem programmering er en form for agil metodologi, der tror på korte udviklingscyklusser. Et projekt er opdelt i simple ingeniøropgaver. Programmører koder et simpelt stykke software og vender tilbage til kunden for feedback. Revpoint fra kunden indarbejdes, og udviklerne går videre med næste opgave.
I ekstrem programmering arbejder udviklere normalt i par.
Ekstrem programmering bruges på steder, hvor kundernes krav konstant ændrer sig.
Hvad er testmetoden?
Ekstrem programmering følger en testdrevet udvikling, som beskrives som følger –
- Føj til Test sag til testsuiten for at verificere den nye funktionalitet, som endnu ikke er udviklet
- Kør alle testene, og det nye testtilfælde, der tilføjes, skal naturligvis mislykkes, da funktionaliteten ikke er kodet endnu
- Skriv noget kode for at implementere funktionen/funktionaliteten
- Kør testpakken igen. Denne gang skulle den nye test-case bestå, da den funktionelt er blevet kodet
| Fordele | Ulemper |
|---|---|
| Kunder med et vagt softwaredesign i tankerne kan bruge ekstrem programmering | Møder mellem softwareudviklingsteamet og kunder øger tidskravene. |
| Kontinuerlig test og kontinuerlig integration af små udgivelser sikrer, at softwarekoden er af høj kvalitet |
V-model og spiralmodel
To yderligere modeller optræder i de fleste projekter og fuldender billedet, fordi hver især imødekommer en svaghed ved vandfaldstilgangen på en forskellig måde.
V-model. V-modellen, ofte kaldet verifikation og validering, parrer hver udviklingsfase med en tilsvarende testfase, tegnet som de to arme af et V. Krav parres med accepttest, højniveaudesign med systemtest, lavniveaudesign med integrationstest og kodning med enhedstest. Fordelen er, at testdesign starter sammen med hver udviklingsfase snarere end efter kodning, så tvetydige krav findes af den person, der skriver accepttestene, måneder før en defekt kan opstå. Dens svaghed er arvet fra vandfaldsmodellen: modellen antager stadig, at kravene er stabile.
Spiralmodel. Spiralen omslutter iterationen omkring eksplicit risikoanalyse. Hver løkke indeholder fire aktiviteter: fastlægge mål, identificere og løse risici, udvikle og teste, og derefter planlægge den næste iteration. Testning koncentrerer sig derfor der, hvor risikoen er højest, i stedet for at fordele den jævnt. Det er egnet til store, dyre og langvarige programmer såsom luftfarts- eller bankkernesystemer, hvor omkostningerne ved en sen opdagelse er høje. For et lille webprojekt er overheaden ved formel risikoanalyse på hver løkke sjældent berettiget.
Begge modeller befinder sig mellem vandfaldsdisciplin og agil responsivitet. Hvor udgivelsesfrekvens betyder mere end begge dele, DevOps Pipeline skubber testning ind i kontinuerlig integration, så hver commit verificeres automatisk.
Hvilken softwaremetode skal man vælge?
Der er tonsvis af metoder tilgængelige til softwareudvikling og dens tilsvarende test. Hver testteknik og -metode er designet til et specifikt formål og har sine relative fordele og ulemper.
Valg af en bestemt metode afhænger af mange faktorer såsom et projekts art, kundekrav, projektplan osv.
Fra et testperspektiv presser nogle metoder på at teste input tidligt i udviklingslivscyklussen, mens andre venter, indtil en arbejdsmodel af systemet er klar.
Hvordan opsætter man softwaretestmetoder?
Softwaretestmetoder bør ikke konfigureres kun for at teste softwarekode. Det store billede bør overvejes, og det primære mål for projektet bør være tilfreds med testmetoden. Se denne liste over velrenommerede udbydere af softwaretesttjenester som kan hjælpe dig med at etablere effektive teststrategier, der er skræddersyet til dit projekts mål.
Planlægning
Realistisk planlægning er nøglen til implementering af en vellykket testmetodologi, og tidsplanen bør opfylde behovene hos hvert medlem af teamet.
Definerede leverancer
For at holde alle medlemmer af teamet på samme side, bør der gives veldefinerede leverancer. Leverancerne skal indeholde direkte indhold uden nogen tvetydighed.
Test tilgang
Når planlægningen er færdig, og definerede leverancer er gjort tilgængelige, bør testteamet være i stand til at formulere den rigtige testtilgang. Definitionsdokumenter og udviklermøder bør angive holdet om den bedste testmetode, der kan bruges til projektet.
Rapportering
Gennemsigtig rapportering er meget vanskelig at opnå, men dette trin bestemmer effektiviteten af den testmetode, der bruges i projektet.




