Meny

Hva er STLC V-Model?

what is stlc v model

Prøv Instrumentet Vårt For Å Eliminere Problemer

Hva er STLC V-Model?

Et av de største ulempene ved foss STLC-modell var at feil ble funnet på et veldig senere stadium av utviklingsprosessen siden testing ble gjort på slutten av utviklingssyklusen. Det ble veldig utfordrende og kostbart å fikse feilene siden det ble funnet på et veldig senere tidspunkt. For å løse dette problemet ble en ny utviklingsmodell introdusert kalt 'V Model'

V-modellen er nå en av de mest brukte programvareutviklingsprosessene. Innføring av V-modellen har faktisk bevist implementeringen av testing helt fra kravfasen. V-modellen kalles også en verifiserings- og valideringsmodell.

STLC V-modell

Hva du vil lære:

Verifisering og validering

For å forstå V-modellen, la oss først forstå hva som er verifisering og validering i programvare.

Bekreftelse : Verifisering er en statisk analyseteknikk. I denne teknikken utføres testing uten å utføre koden. Eksempler inkluderer - Anmeldelser, inspeksjon og gjennomgang.

Validering : Validering er en dynamisk analyseteknikk der testing gjøres ved å utføre koden. Eksempler inkluderer funksjonelle og ikke-funksjonelle testteknikker.

V-modell

I V-modellen gjøres utviklingen og QA-aktivitetene samtidig. Det er ingen diskret fase som kalles Testing, men testing starter rett fra kravfasen. Verifiserings- og valideringsaktivitetene går hånd i hånd.

For å forstå V-modellen, la oss se på figuren nedenfor:

STLC V-modell

hvordan du returnerer matriser i java

I en typisk utviklingsprosess viser venstre side utviklingsaktivitetene og høyre side viser testaktivitetene. Jeg burde ikke ta feil hvis jeg sier at både verifisering og validering i utviklingsfasen utføres sammen med de faktiske utviklingsaktivitetene.

La oss nå forstå figuren:

Venstre side

Venstre side er som sagt utviklingsaktiviteter. Normalt føler vi, hvilke tester kan vi gjøre i utviklingsfasen, men dette er skjønnheten i denne modellen som viser at testing også kan gjøres i alle faser av utviklingsaktivitetene.

Kravsanalyse : I denne fasen blir kravene samlet, analysert og studert. Her er hvordan systemet implementeres, ikke viktig, men hva systemet skal gjøre, er viktig. Hjernestormingsøkter / gjennomgang, intervjuer gjøres for å ha målene klare.

  • Verifikasjonsaktiviteter : Krav omtaler.
  • Valideringsaktiviteter : Opprettelse av UAT ( Brukeraksept test ) prøvesaker
  • Artefakter produsert : Krav til forståelsesdokument, UAT-testtilfeller.

Systemkrav / Design på høyt nivå : I denne fasen bygges programvaren på høyt nivå. Teamet studerer og undersøker hvordan kravene kan implementeres. Den tekniske gjennomførbarheten til kravene blir også studert. Teamet kommer også med modulene som vil bli opprettet / avhengigheter, maskinvare / programvarebehov

  • Verifikasjonsaktiviteter : Designanmeldelser
  • Valideringsaktiviteter : Skapelse av, laget av Systemtestplan og saker, Opprettelse av sporbarhetsmålinger
  • Artefakter produsert : Systemtesttilfeller, gjennomførbarhetsrapporter, systemtestplan, krav til maskinvareprogramvare og moduler som skal opprettes osv.

Arkitektonisk design: I denne fasen, basert på design på høyt nivå , programvarearkitektur opprettes. Modulene, deres relasjoner og avhengigheter, arkitektoniske diagrammer, databasetabeller, teknologidetaljer blir alle avsluttet i denne fasen.

  • Verifikasjonsaktiviteter : Designanmeldelser
  • Valideringsaktiviteter : Integrasjonstestplan og testsaker.
  • Artefakter produsert : Designdokumenter, integrasjonstestplan og testtilfeller, databasetabelldesign m.m.

Moduldesign / lavt nivå design: I denne fasen er hver modul av programvarekomponentene designet individuelt. Metoder, klasser, grensesnitt, datatyper osv. Er ferdig i denne fasen.

  • Verifikasjonsaktiviteter : Designanmeldelser
  • Valideringsaktiviteter : Opprettelse og gjennomgang av enhetstestsaker.
  • Artefakter produsert : Enhetstesttilfeller,

Implementering / kode : I denne fasen er selve kodingen gjort.

  • Verifikasjonsaktiviteter : Kodegjennomgang, prøvesaker gjennomgang
  • Valideringsaktiviteter : Opprettelse av funksjonelle testtilfeller.
  • Artefakter produsert : testtilfeller, sjekkliste for gjennomgang.

Høyre side

Høyre side demonstrerer testaktivitetene eller valideringsfasen. Vi starter fra bunnen.

Enhetstesting: I denne fasen blir alle enhetstesttilfeller, opprettet i lavnivå-designfasen, utført.

* Enhetstesting er en testteknikk for en hvit boks, der det skrives et stykke kode som påkaller en metode (eller en hvilken som helst annen kode) for å teste om kodebiten gir den forventede effekten eller ikke. Denne testingen utføres i utgangspunktet av utviklingsteamet. I tilfelle avvik, blir mangler logget og sporet.

Artefakter produsert : Utførelsesresultater for enhetstest

Integrasjonstesting : I denne fasen gjennomføres integrasjonstestsakene som ble opprettet i arkitektonisk designfase. I tilfelle avvik, blir mangler logget og sporet.

* Integrasjonstesting: Integrasjonstesting er en teknikk der enhetstestede moduler er integrert og testet om de integrerte modulene gir de forventede resultatene. Med enklere ord validerer det om komponentene i applikasjonen fungerer sammen som forventet.

Artefakter produsert : Integrasjonstestresultater.

Systemtesting : I denne fasen utføres alle systemtestsaker, funksjonstestsaker og ikke-funksjonelle testsaker. Med andre ord, den faktiske og fullverdige testen av applikasjonen finner sted her. Mangler logges og spores for lukking. Fremdriftsrapportering er også en stor del av denne fasen. Sporbarhetsberegningene oppdateres for å kontrollere dekningen og risikoreduserende.

Artefakter produsert : Testresultater, testlogger, feilrapport, testoppsummeringsrapport og oppdaterte sporbarhetsmatriser.

Test av brukeraksept : Akseptprøving er i utgangspunktet knyttet til testing av forretningskrav. Her testes det for å validere at forretningskravene blir oppfylt i brukermiljøet. Kompatibilitetstesting og noen ganger ikke-funksjonell testing ( Last, stress og volum ) testing blir også gjort i denne fasen.

Artefakter produsert : UAT-resultater, oppdaterte forretningsdekkingsmatriser.

Når skal du bruke V-modellen?

V-modellen gjelder når:

  • Kravet er veldefinert og ikke tvetydig
  • Akseptkriterier er godt definert.
  • Prosjektet er kort til middels stort.
  • Teknologi og verktøy som brukes er ikke dynamiske.

Fordeler og ulemper ved å bruke V-modellen

PROSULEMPER
- Utvikling og fremgang er veldig organisert og systematisk-Ikke egnet for større og komplekse prosjekter
- Fungerer bra for mindre til mellomstore prosjekter.- Ikke egnet hvis kravene ikke er i samsvar.
- Testing starter fra begynnelsen, så uklarheter blir identifisert fra begynnelsen.- Det produseres ingen fungerende programvare i mellomfasen.
- Enkel å administrere da hver fase har veldefinerte mål og mål.- Ingen bestemmelser for å gjøre risikoanalyse, så usikkerhet og risiko er der.

Anbefalt lesing

^