Meny

Vad är STLC V-Model?

what is stlc v model

Prova Vårt Instrument För Att Eliminera Problem

Vad är STLC V-Model?

En av de största handikapparna i vattenfall STLC-modell var att defekter hittades i ett mycket senare skede av utvecklingsprocessen eftersom testning gjordes i slutet av utvecklingscykeln. Det blev mycket utmanande och kostsamt att åtgärda defekterna eftersom det hittades i ett mycket senare skede. För att övervinna detta problem introducerades en ny utvecklingsmodell som kallades 'V-modellen'

V-modellen är nu en av de mest använda programvaruutvecklingsprocesserna. Introduktion av V-modellen har faktiskt bevisat genomförandet av testning redan från kravfasen. V-modellen kallas också en verifierings- och valideringsmodell.

STLC V-modell

Vad du kommer att lära dig:

Verifiering och validering

För att förstå V-modellen ska vi först förstå vad som är verifiering och validering i programvara.

Verifiering : Verifiering är en statisk analysteknik. I denna teknik görs testning utan att koden körs. Exempel inkluderar - Recensioner, Inspektion och genomgång.

Godkännande : Validering är en dynamisk analysteknik där test utförs genom att koden körs. Exempel inkluderar funktionella och icke-funktionella testtekniker.

V-modell

I V-modellen görs utvecklingen och QA-aktiviteterna samtidigt. Det finns ingen diskret fas som kallas Testing, utan testning börjar direkt från kravfasen. Verifierings- och valideringsaktiviteterna går hand i hand.

För att förstå V-modellen, låt oss titta på figuren nedan:

STLC V-modell

hur man returnerar arrayer i java

I en typisk utvecklingsprocess visar vänster sida utvecklingsaktiviteterna och höger visar testaktiviteterna. Jag skulle inte ha fel om jag säger att i utvecklingsfasen utförs både verifiering och validering tillsammans med de faktiska utvecklingsaktiviteterna.

Låt oss nu förstå figuren:

Vänster sida

Som sagt tidigare är vänsteraktiviteter utvecklingsaktiviteter. Normalt känner vi, vilka tester kan vi göra i utvecklingsfasen, men detta är skönheten i den här modellen som visar att testning kan göras även i alla faser av utvecklingsaktiviteterna.

Kravsanalys : I denna fas samlas kraven, analyseras och studeras. Här är hur systemet implementeras inte viktigt men vad systemet ska göra är viktigt. Brain storming sessioner / genomgång, intervjuer görs för att ha målen klara.

  • Verifieringsaktiviteter : Krav recensioner.
  • Valideringsaktiviteter : Skapande av UAT ( Test av användaraccept ) testfall
  • Artefakter producerade : Krav på förståelse av dokument, UAT-testfall.

Systemkrav / högnivådesign : I denna fas byggs programvaran på hög nivå. Teamet studerar och undersöker hur kraven kan implementeras. Den tekniska genomförbarheten av kraven studeras också. Teamet kommer också med de moduler som skulle skapas / beroenden, hårdvaru- / programvarubehov

  • Verifieringsaktiviteter : Designrecensioner
  • Valideringsaktiviteter : Skapelse av Systemtestplan och fall, skapande av mätvärden för spårbarhet
  • Artefakter producerade : Systemtestfall, genomförbarhetsrapporter, systemtestplan, krav på hårdvaruprogramvara och moduler som ska skapas etc.

Arkitektonisk design: I den här fasen, baserat på designen på hög nivå , programvaruarkitektur skapas. Modulerna, deras förhållanden och beroenden, arkitektoniska diagram, databastabeller, teknologidetaljer slutförs alla i denna fas.

  • Verifieringsaktiviteter : Designrecensioner
  • Valideringsaktiviteter : Integrationstestplan och testfall.
  • Artefakter producerade : Designdokument, Integrationstestplan och testfall, Databasdesigner etc.

Moduldesign / lågnivådesign: I denna fas utformas varje modul av programvarukomponenterna individuellt. Metoder, klasser, gränssnitt, datatyper etc slutförs alla i denna fas.

  • Verifieringsaktiviteter : Designrecensioner
  • Valideringsaktiviteter : Skapande och granskning av fall med enhetstest.
  • Artefakter producerade : Enhetstestfall,

Implementering / kod : I denna fas är själva kodningen klar.

  • Verifieringsaktiviteter : Kodgranskning, granskning av testfall
  • Valideringsaktiviteter : Skapande av funktionella testfall.
  • Artefakter producerade : testfall, granskningslista.

Höger sida

Höger sida visar testaktiviteterna eller valideringsfasen. Vi börjar från botten.

Enhetstestning: I denna fas körs alla enhetstestfall som skapats i designfasen på låg nivå.

* Enhetstestning är en vitlåda-testteknik, där en kod kodas som använder en metod (eller någon annan kod) för att testa om kodavsnittet ger den förväntade utdata eller inte. Denna testning utförs i princip av utvecklingsteamet. Vid avvikelser loggas och spåras defekter.

Artefakter producerade : Exekveringsresultat för enhetstest

Integrationstestning : I den här fasen utförs integrationsprovfall som skapades i arkitektonisk fas. I händelse av avvikelser loggas och spåras defekter.

* Integrationstestning: Integrationstestning är en teknik där de enhetstestade modulerna integreras och testas om de integrerade modulerna ger de förväntade resultaten. Med enklare ord validerar det om komponenterna i applikationen fungerar som förväntat.

Artefakter producerade : Integrationstestresultat.

Systemtestning : I denna fas utförs alla systemtestfall, funktionstestfall och icke-funktionella testfall. Med andra ord sker den faktiska och fullständiga testningen av applikationen här. Fel loggas och spåras för att stängas. Framstegsrapportering är också en stor del av denna fas. Spårbarhetsstatistiken uppdateras för att kontrollera täckning och riskreducering.

Artefakter producerade : Testresultat, testloggar, defektrapport, testsammanfattningsrapport och uppdaterade spårbarhetsmatriser.

Test av användaracceptans : Acceptantestning är i grunden relaterad till testning av företagskrav. Här görs testning för att verifiera att företagets krav uppfylls i användarmiljön. Kompatibilitetstestning och ibland icke-funktionell testning ( Belastning, stress och volym ) testning görs också i denna fas.

Artefakter producerade : UAT-resultat, uppdaterade matriser för affärstäckning.

När ska jag använda V-modellen?

V-modellen är tillämplig när:

  • Kravet är väldefinierat och inte tvetydigt
  • Godtagandekriterierna är väl definierade.
  • Projektet är kort till medelstort.
  • Teknik och verktyg som används är inte dynamiska.

För- och nackdelar med att använda V-modellen

FÖRDELARNACKDELAR
- Utveckling och framsteg är mycket organiserad och systematisk-Inte lämpligt för större och komplexa projekt
- Fungerar bra för mindre till medelstora projekt.- Inte lämpligt om kraven inte är förenliga.
- Testning börjar från början så oklarheter identifieras från början.- Ingen fungerande programvara produceras i mellanstadiet.
- Lätt att hantera eftersom varje fas har väldefinierade mål och mål.- Ingen möjlighet att göra riskanalys så osäkerhet och risker finns.

Rekommenderad läsning

^