what is stlc v model
Hvad er STLC V-Model?
Et af de største handicap ved vandfald STLC model var, at der blev fundet fejl på et meget senere tidspunkt i udviklingsprocessen, da test blev udført i slutningen af udviklingscyklussen. Det blev meget udfordrende og dyrt at rette manglerne, da det blev fundet på et meget senere tidspunkt. For at løse dette problem blev der introduceret en ny udviklingsmodel kaldet 'V Model'
V-modellen er nu en af de mest anvendte softwareudviklingsprocesser. Introduktion af V-modellen har faktisk bevist implementeringen af test lige fra kravsfasen. V-model kaldes også en verifikations- og valideringsmodel.
Hvad du vil lære:
Verifikation og validering
For at forstå V-modellen skal vi først forstå, hvad der er verifikation og validering i software.
Verifikation : Verifikation er en statisk analyseteknik. I denne teknik udføres test uden at udføre koden. Eksempler inkluderer - Anmeldelser, inspektion og gennemgang.
Validering : Validering er en dynamisk analyseteknik, hvor test udføres ved at udføre koden. Eksempler inkluderer funktionelle og ikke-funktionelle testteknikker.
V-Model
I V-modellen udføres udviklingen og QA-aktiviteterne samtidigt. Der er ingen diskret fase kaldet Testing, snarere starter test lige fra kravsfasen. Verifikations- og valideringsaktiviteterne går hånd i hånd.
For at forstå V-modellen skal vi se på nedenstående figur:
prøve testplan til softwaretest
I en typisk udviklingsproces viser venstre side udviklingsaktiviteterne og højre side viser testaktiviteterne. Jeg burde ikke tage fejl, hvis jeg siger, at der i udviklingsfasen udføres både verifikation og validering sammen med de faktiske udviklingsaktiviteter.
Lad os nu forstå figuren:
Venstre side
Venstre side aktiviteter er som sagt udviklingsaktiviteter. Normalt føler vi, hvilke test kan vi udføre i udviklingsfasen, men dette er skønheden i denne model, der viser, at test også kan udføres i alle faser af udviklingsaktiviteterne.
Kravsanalyse : I denne fase samles kravene, analyseres og undersøges. Her er det ikke vigtigt, hvordan systemet implementeres, men hvad systemet skal gøre, er vigtigt. Brain storming sessioner / gennemgang, interviews udføres for at have målene klare.
- Verifikationsaktiviteter : Krav anmeldelser.
- Valideringsaktiviteter : Oprettelse af UAT ( Test af brugeraccept ) test tilfælde
- Producerede artefakter : Krav til forståelsesdokument, UAT-testtilfælde.
Systemkrav / Design på højt niveau : I denne fase bygges softwaren på højt niveau. Teamet studerer og undersøger, hvordan kravene kan implementeres. Den tekniske gennemførlighed af kravene undersøges også. Holdet kommer også med de moduler, der ville blive oprettet / afhængigheder, hardware / software behov
- Verifikationsaktiviteter : Designanmeldelser
- Valideringsaktiviteter : Oprettelse af System testplan og sager, Oprettelse af sporbarhedsmålinger
- Producerede artefakter : Systemtestsager, gennemførlighedsrapporter, systemtestplan, hardware-softwarekrav og moduler, der skal oprettes osv.
Arkitektonisk design: I denne fase, baseret på design på højt niveau , softwarearkitektur oprettes. Modulerne, deres forhold og afhængigheder, arkitektoniske diagrammer, databasetabeller, teknologidetaljer er alle afsluttet i denne fase.
- Verifikationsaktiviteter : Designanmeldelser
- Valideringsaktiviteter : Integrationstestplan og testcases.
- Producerede artefakter : Designdokumenter, integrationstestplan og testcases, databasetabeldesign mv.
Moduldesign / lavt niveau design: I denne fase er hvert modul af softwarekomponenterne designet individuelt. Metoder, klasser, grænseflader, datatyper osv. Er alle afsluttet i denne fase.
- Verifikationsaktiviteter : Designanmeldelser
- Valideringsaktiviteter : Oprettelse og gennemgang af enhedstestsager.
- Producerede artefakter : Enhedstestsager,
Implementering / kode : I denne fase udføres den faktiske kodning.
- Verifikationsaktiviteter : Gennemgang af kode, gennemgang af testsager
- Valideringsaktiviteter : Oprettelse af funktionelle testsager.
- Producerede artefakter : test tilfælde, gennemgang tjekliste.
Højre side
Højre side viser testaktiviteterne eller valideringsfasen. Vi starter fra bunden.
Enhedstest: I denne fase udføres alle enhedstestsagen, der er oprettet i designfasen på lavt niveau.
* Enhedstest er en testteknik for en hvid boks, hvor der skrives et stykke kode, der påkalder en metode (eller ethvert andet stykke kode) for at teste, om kodestykket giver den forventede output eller ej. Denne test udføres grundlæggende af udviklingsteamet. I tilfælde af en uregelmæssighed registreres og spores mangler.
Producerede artefakter : Enhedstest udførelsesresultater
Integrationstest : I denne fase udføres integrationstestsagerne, som blev oprettet i den arkitektoniske designfase. I tilfælde af uregelmæssigheder registreres og spores mangler.
* Integrationstest: Integrationstest er en teknik, hvor de enhedstestede moduler er integreret og testet, om de integrerede moduler giver de forventede resultater. Med enklere ord validerer det, om applikationens komponenter fungerer sammen som forventet.
Producerede artefakter : Integrationstestresultater.
Systemtest : I denne fase udføres alle systemtestsager, funktionstestsager og ikke-funktionelle testsager. Med andre ord finder den faktiske og fuldstændige test af applikationen sted her. Mangler logges og spores for lukning. Statusrapportering er også en stor del af denne fase. Sporbarhedsmålingerne opdateres for at kontrollere dækningen og risikoreduceret.
Producerede artefakter : Testresultater, testlogfiler, defektrapport, testoversigtsrapport og opdaterede sporbarhedsmatricer.
Test af brugeraccept : Acceptstest er grundlæggende relateret til forretningskravstest. Her udføres test for at validere, at forretningskravene er opfyldt i brugermiljøet. Kompatibilitetstest og undertiden ikke-funktionel test ( Belastning, stress og volumen ) test udføres også i denne fase.
Producerede artefakter : UAT-resultater, opdaterede forretningsdækningsmatricer.
Hvornår skal jeg bruge V-modellen?
V-modellen kan anvendes, når:
- Kravet er veldefineret og ikke tvetydigt
- Acceptkriterier er veldefinerede.
- Projektet er kort til medium i størrelse.
- Brugt teknologi og værktøjer er ikke dynamiske.
Fordele og ulemper ved at bruge V-modellen
| PROS | ULEMPER |
|---|---|
| - Udvikling og fremskridt er meget organiseret og systematisk | -Ikke egnet til større og komplekse projekter |
| - Fungerer godt til mindre til mellemstore projekter. | - Ikke egnet, hvis kravene ikke er i overensstemmelse. |
| - Test starter fra begyndelsen, så uklarheder identificeres fra starten. | - Der produceres ingen fungerende software i mellemfasen. |
| - Let at styre, da hver fase har veldefinerede mål og mål. | - Ingen mulighed for risikoanalyse, så usikkerhed og risici er der. |
Anbefalet læsning
- SOA Testing Tutorial: Test Methodology For a SOA Architecture Model
- Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
- Statisk test og dynamisk test - Forskellen mellem disse to vigtige testteknikker
- Spiral Model - Hvad er SDLC Spiral Model?
- Praktisk softwaretest - Ny GRATIS e-bog (Download)
- Alpha Testing og Beta Testing (En komplet guide)
- Test af Primer eBook Download
- Onsite - Offshore-model af softwaretestprojekter (og hvordan man får det til at fungere for dig)