Menu

Co je STLC V-Model?

what is stlc v model

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Co je STLC V-Model?

Jeden z hlavních znevýhodnění vodopádový model STLC bylo, že vady byly nalezeny ve velmi pozdější fázi vývojového procesu, protože testování proběhlo na konci vývojového cyklu. Opravit závady se stalo velmi náročným a nákladným, protože bylo zjištěno ve velmi pozdější fázi. K překonání tohoto problému byl představen nový vývojový model s názvem „V Model“

Model V je nyní jedním z nejpoužívanějších procesů vývoje softwaru. Zavedení modelu V skutečně prokázalo implementaci testování již od fáze požadavku. Model V se také nazývá model ověřování a ověřování.

Natluču V-Model

Co se naučíte:

Ověření a ověření

Abychom porozuměli modelu V, pojďme nejprve porozumět tomu, co je verifikace a validace v softwaru.

Ověření : Ověření je technika statické analýzy. V této technice se testování provádí bez provedení kódu. Mezi příklady patří - Recenze, Inspekce a návod.

Validace : Ověření je technika dynamické analýzy, při které se testování provádí spuštěním kódu. Mezi příklady patří funkční a nefunkční testovací techniky.

V-model

V modelu V se vývoj a aktivity QA provádějí současně. Neexistuje žádná diskrétní fáze zvaná Testování, spíše testování začíná hned od fáze požadavku. Aktivity spojené s ověřováním a ověřováním jdou ruku v ruce.

Abychom porozuměli modelu V, podívejme se na následující obrázek:

Natluču V Model

jak převést znak na řetězec c ++

V typickém vývojovém procesu ukazuje levá strana vývojové aktivity a pravá strana testovací aktivity. Neměl bych se mýlit, když říkám, že ve vývojové fázi se provádí ověřování i ověřování spolu se skutečnými vývojovými činnostmi.

Nyní pochopme obrázek:

Levá strana

Jak již bylo řečeno, činnosti na levé straně jsou rozvojové činnosti. Normálně cítíme, jaké testování můžeme provést ve fázi vývoje, ale to je krása tohoto modelu, který ukazuje, že testování lze provádět také ve všech fázích vývojových aktivit.

Analýza požadavků : V této fázi jsou požadavky shromažďovány, analyzovány a studovány. Zde není důležité, jak je systém implementován, ale je důležité, co má systém dělat. Průběh / procházení mozkovými útoky, rozhovory se provádějí, aby byly cíle jasné.

  • Ověřovací činnosti : Kontrola požadavků.
  • Validační činnosti : Vytvoření UAT ( Akceptační test uživatele ) testovací případy
  • Vyrobené artefakty : Dokument porozumění požadavkům, testovací případy UAT.

Systémové požadavky / Design na vysoké úrovni : V této fázi je vytvořen návrh softwaru na vysoké úrovni. Tým studuje a zkoumá, jak by mohly být požadavky implementovány. Rovněž je studována technická proveditelnost požadavků. Tým také přichází s moduly, které by byly vytvořeny / závislosti, hardwarové / softwarové potřeby

  • Ověřovací činnosti : Recenze designu
  • Validační činnosti : Vytvoření Plán zkoušek systému a případy, Vytvoření metriky sledovatelnosti
  • Vyrobené artefakty : Testovací případy systému, Zprávy proveditelnosti, Plán testování systému, Hardwarové a softwarové požadavky a moduly, které mají být vytvořeny atd.

Architektonický design: V této fázi na základě návrhu na vysoké úrovni , je vytvořena softwarová architektura. V této fázi jsou dokončeny moduly, jejich vztahy a závislosti, architektonické diagramy, databázové tabulky, technologické detaily.

  • Ověřovací činnosti : Recenze designu
  • Validační činnosti : Plán integrace a testovací případy.
  • Vyrobené artefakty : Konstrukční dokumenty, integrační testovací plán a testovací případy, návrhy databázových tabulek atd.

Návrh modulu / Nízkoúrovňový design: V této fázi je každý modul softwarových komponent navržen individuálně. V této fázi jsou dokončeny metody, třídy, rozhraní, datové typy atd.

  • Ověřovací činnosti : Recenze designu
  • Validační činnosti : Vytvoření a kontrola jednotkových testovacích případů.
  • Vyrobené artefakty : Jednotkové testovací případy,

Implementace / Kodex : V této fázi se provádí vlastní kódování.

  • Ověřovací činnosti : Kontrola kódu, kontrola testovacích případů
  • Validační činnosti : Tvorba funkčních testovacích případů.
  • Vyrobené artefakty : testovací případy, kontrolní kontrolní seznam.

Pravá strana

Pravá strana ukazuje testovací aktivity nebo ověřovací fázi. Začneme zdola.

Testování jednotky: V této fázi se provedou všechny testovací případy jednotky vytvořené ve fázi návrhu na nízké úrovni.

* Testování jednotky je technika testování bílé skříňky, kdy je napsán kus kódu, který vyvolá metodu (nebo jakoukoli jinou část kódu), která otestuje, zda fragment kódu poskytuje očekávaný výstup nebo ne. Toto testování v zásadě provádí vývojový tým. V případě jakékoli anomálie se závady zaznamenávají a sledují.

Vyrobené artefakty : Výsledky provedení testu jednotky

Testování integrace : V této fázi se provádějí integrační testovací případy, které byly vytvořeny ve fázi architektonického návrhu. V případě jakýchkoli anomálií se závady zaznamenávají a sledují.

* Testování integrace: Testování integrace je technika, při které jsou jednotky testované moduly integrovány a testovány, zda integrované moduly poskytují očekávané výsledky. Jednoduše řečeno, ověřuje, zda komponenty aplikace spolupracují podle očekávání.

Vyrobené artefakty : Výsledky testu integrace.

Testování systémů : V této fázi jsou provedeny všechny systémové testovací případy, funkční testovací případy a nefunkční testovací případy. Jinými slovy se zde odehrává skutečné a úplné testování aplikace. Vady jsou protokolovány a sledovány kvůli jejich uzavření. Podávání zpráv o pokroku je také hlavní součástí této fáze. Metriky sledovatelnosti se aktualizují, aby se zkontrolovalo pokrytí a zmírnilo riziko.

Vyrobené artefakty : Výsledky testů, protokoly testů, zpráva o vadách, souhrnná zpráva o testu a aktualizované matice sledovatelnosti.

testování přijetí uživatele : Akceptační testování v zásadě souvisí s testováním obchodních požadavků. Zde se provádí testování, aby se ověřilo, že jsou v uživatelském prostředí splněny obchodní požadavky. Testování kompatibility a někdy nefunkční testování ( Zatížení, stres a objem ) testování se také provádí v této fázi.

Vyrobené artefakty : Výsledky UAT, aktualizované matice pokrytí firmy.

Kdy použít model V?

Model V je použitelný, když:

  • Požadavek je dobře definovaný a nejednoznačný
  • Kritéria přijetí jsou dobře definována.
  • Projekt je malé až střední velikosti.
  • Použité technologie a nástroje nejsou dynamické.

Výhody a nevýhody používání modelu V.

PROFESIONÁLOVÉNEVÝHODY
- Rozvoj a pokrok jsou velmi organizované a systematické-Není vhodné pro větší a složité projekty
- Funguje dobře pro menší až středně velké projekty.- Nevhodné, pokud požadavky nejsou konzistentní.
- Testování začíná od začátku, takže nejasnosti jsou identifikovány od začátku.- V mezistupni se nevyrábí žádný funkční software.
- Snadná správa, protože každá fáze má dobře definované cíle a cíle.- Žádné ustanovení pro provádění analýzy rizik, takže nejistota a rizika existují.

Doporučené čtení

^