Menu

Čo je model STLC V?

what is stlc v model

Čo je model STLC V?

Jedným z hlavných znevýhodnení vodopádový model STLC bolo, že chyby sa našli vo veľmi neskoršej fáze vývojového procesu, pretože testovanie sa uskutočnilo na konci vývojového cyklu. Opraviť chyby sa stalo veľmi náročným a nákladným, pretože sa to zistilo vo veľmi neskoršej fáze. Na prekonanie tohto problému bol predstavený nový vývojový model s názvom „V Model“

Model V je dnes jedným z najbežnejšie používaných procesov vývoja softvéru. Zavedenie modelu V skutočne preukázalo implementáciu testovania hneď od fázy požiadavky. Model V sa tiež nazýva model overovania a overovania.

STLC V-Model

Čo sa dozviete:

prevodník z YouTube na wav zadarmo na stiahnutie

Overenie a overenie

Aby sme porozumeli modelu V, najskôr pochopíme, čo je verifikácia a validácia v softvéri.

Overenie : Overenie je technika statickej analýzy. V tejto technike sa testovanie vykonáva bez vykonania kódu. Príklady zahŕňajú - Recenzie, Inšpekcia a návod.

Validácia : Validácia je technika dynamickej analýzy, pri ktorej sa testovanie vykonáva vykonaním kódu. Príklady zahŕňajú funkčné a nefunkčné testovacie techniky.

Model V

V modeli V sa vývoj a činnosti zabezpečovania kvality vykonávajú súčasne. Neexistuje diskrétna fáza nazývaná Testovanie, skôr sa testovanie začína priamo od fázy požiadavky. Aktivity spojené s overovaním a validáciou idú ruka v ruke.

Aby sme pochopili model V, pozrime sa na nasledujúci obrázok:

STLC V Model

V typickom vývojovom procese ukazuje ľavá strana vývojové aktivity a pravá strana zobrazuje testovacie činnosti. Nemal by som sa mýliť, ak poviem, že vo vývojovej fáze sa overovanie aj validácia vykonáva spolu so skutočnými vývojovými činnosťami.

Poďme teda pochopiť obrázok:

Strana po ľavej ruke

Ako už bolo povedané, ľavostranné činnosti sú rozvojové činnosti. Normálne cítime, aké testovanie môžeme vykonať vo vývojovej fáze, ale to je krása tohto modelu, ktorá ukazuje, že testovanie je možné vykonať aj vo všetkých fázach vývojových aktivít.

Analýza požiadaviek : V tejto fáze sa požiadavky zhromažďujú, analyzujú a študujú. Tu nie je dôležité, ako je systém implementovaný, ale je dôležité, čo má systém robiť. Relácie / útoky na mozog, rozhovory sa robia, aby boli ciele jasné.

  • Overovacie činnosti : Kontrola požiadaviek.
  • Validačné činnosti : Vytvorenie UAT ( Akceptačný test používateľa ) testovacie prípady
  • Vyrobené artefakty : Dokument porozumenia požiadaviek, testovacie prípady UAT.

Systémové požiadavky / Dizajn na vysokej úrovni : V tejto fáze sa vytvára vysokoúrovňový dizajn softvéru. Tím študuje a skúma, ako by sa dali požiadavky implementovať. Skúma sa aj technická realizovateľnosť požiadaviek. Tím tiež prichádza s modulmi, ktoré by sa vytvorili / závislosti, hardvérové ​​/ softvérové ​​potreby

  • Overovacie činnosti : Recenzie dizajnu
  • Validačné činnosti : Vytvorenie Plán skúšok systému a prípady, Tvorba metrík sledovateľnosti
  • Vyrobené artefakty : Prípady testovania systému, správy o uskutočniteľnosti, plán testovania systému, hardvérové ​​a softvérové ​​požiadavky a moduly, ktoré sa majú vytvoriť, atď.

Architektonický dizajn: V tejto fáze založené na dizajne vysokej úrovne , je vytvorená softvérová architektúra. V tejto fáze sú dokončené všetky moduly, ich vzťahy a závislosti, architektonické diagramy, databázové tabuľky, technologické detaily.

  • Overovacie činnosti : Recenzie dizajnu
  • Validačné činnosti : Plán integrácie a testovacie prípady.
  • Vyrobené artefakty : Dizajnové dokumenty, plán integrácie a testovacie prípady, návrhy databázových tabuliek atď.

Dizajn modulu / Dizajn na nízkej úrovni: V tejto fáze je každý modul softvérových komponentov navrhnutý individuálne. V tejto fáze sú dokončené metódy, triedy, rozhrania, dátové typy atď.

  • Overovacie činnosti : Recenzie dizajnu
  • Validačné činnosti : Tvorba a preskúmanie jednotkových testovacích prípadov.
  • Vyrobené artefakty : Jednotkové testovacie prípady,

Implementácia / kód : V tejto fáze sa vykoná skutočné kódovanie.

  • Overovacie činnosti : Kontrola kódu, kontrola testovacích prípadov
  • Validačné činnosti : Tvorba funkčných testovacích prípadov.
  • Vyrobené artefakty : testovacie prípady, kontrolný zoznam.

Pravá strana

Pravá strana demonštruje testovacie aktivity alebo fázu overenia. Začneme odspodu.

Testovanie jednotky: V tejto fáze sa vykonajú všetky testovacie prípady jednotky vytvorené vo fáze návrhu na nízkej úrovni.

* Testovanie jednotiek je technika testovania v bielom poli, kde je napísaný kúsok kódu, ktorý vyvolá metódu (alebo akýkoľvek iný kúsok kódu) na otestovanie, či útržok kódu poskytuje očakávaný výstup alebo nie. Toto testovanie v zásade vykonáva vývojový tím. V prípade akejkoľvek anomálie sa chyby zaznamenávajú a sledujú.

Vyrobené artefakty : Výsledky vykonania testu jednotky

Testovanie integrácie : V tejto fáze sa vykonávajú integračné testovacie prípady, ktoré boli vytvorené vo fáze architektonického návrhu. V prípade akýchkoľvek anomálií sa chyby zaznamenávajú a sledujú.

* Testovanie integrácie: Testovanie integrácie je technika, pri ktorej sú jednotky testované moduly integrované a testované, či integrované moduly poskytujú očakávané výsledky. Jednoduchšie povedané, overuje sa, či komponenty aplikácie spolupracujú podľa očakávania.

Vyrobené artefakty : Výsledky integračného testu.

Testovanie systémov : V tejto fáze sa vykonajú všetky systémové testovacie prípady, funkčné testovacie prípady a nefunkčné testovacie prípady. Inými slovami, tu sa uskutočňuje skutočné a úplné testovanie aplikácie. Poruchy sa zaznamenávajú a sledujú sa z hľadiska ich uzavretia. Podávanie správ o pokroku je tiež hlavnou súčasťou tejto fázy. Metriky sledovateľnosti sa aktualizujú, aby sa skontrolovalo pokrytie a riziko sa znížilo.

Vyrobené artefakty : Výsledky testov, protokoly testov, správa o chybách, súhrnná správa o teste a aktualizované matice vysledovateľnosti.

Testovanie prijatia používateľa : Testovanie prijatia v zásade súvisí s testovaním obchodných požiadaviek. Tu sa testuje, aby sa overilo, či sú v užívateľskom prostredí splnené obchodné požiadavky. Testovanie kompatibility a niekedy nefunkčné testovanie ( Zaťaženie, stres a objem ) sa v tejto fáze vykonávajú aj testy.

Vyrobené artefakty : Výsledky UAT, aktualizované matice pokrytia podnikania.

Kedy použiť model V?

Model V je použiteľný, ak:

  • Požiadavka je dobre definovaná a nejednoznačná
  • Kritériá prijatia sú dobre definované.
  • Projekt je malý až stredný.
  • Použité technológie a nástroje nie sú dynamické.

Výhody a nevýhody používania modelu V.

PROSZÁPORY
- Rozvoj a pokrok sú veľmi organizované a systematické-Nie je vhodný pre väčšie a zložité projekty
- Funguje dobre pre menšie až stredne veľké projekty.- Nevhodné, ak požiadavky nie sú konzistentné.
- Testovanie sa začína od začiatku, takže nejasnosti sa identifikujú od začiatku.- V medzistupni sa nevyrába žiadny funkčný softvér.
- Ľahko sa spravuje, pretože každá fáza má dobre definované ciele a úlohy.- Neexistuje ustanovenie na vykonávanie analýzy rizík, takže existuje neistota a riziká.

Odporúčané čítanie

^