Meniu

Ce este modelul STLC V?

what is stlc v model

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Ce este modelul STLC V?

Unul dintre handicapurile majore ale model STLC cascadă a fost că defectele au fost găsite într-un stadiu foarte târziu al procesului de dezvoltare, deoarece testarea a fost făcută la sfârșitul ciclului de dezvoltare. A devenit foarte dificil și costisitor să se remedieze defectele, deoarece a fost găsit într-un stadiu foarte târziu. Pentru a depăși această problemă, a fost introdus un nou model de dezvoltare numit „Modelul V”

Modelul V este acum unul dintre cele mai utilizate procese de dezvoltare software. Introducerea modelului V a dovedit de fapt implementarea testării încă din faza cerințelor. Modelul V se mai numește și model de verificare și validare.

Modelul STLC V

Ce veți învăța:

Verificare si validare

Pentru a înțelege modelul V, să înțelegem mai întâi ce înseamnă verificarea și validarea în software.

Verificare : Verificarea este o tehnică de analiză statică. În această tehnică, testarea se face fără a executa codul. Exemplele includ - Recenzii, Inspecție și ghid.

Validare : Validarea este o tehnică de analiză dinamică în care testarea se face prin executarea codului. Exemplele includ tehnici de testare funcționale și nefuncționale.

Modelul V

În modelul V, activitățile de dezvoltare și QA sunt realizate simultan. Nu există o fază discretă numită Testare, ci mai degrabă testarea începe chiar de la faza de cerință. Activitățile de verificare și validare merg mână în mână.

Pentru a înțelege modelul V, să analizăm figura de mai jos:

Modelul STLC V

care este cel mai bun curățător gratuit de computer

Într-un proces tipic de dezvoltare, partea stângă arată activitățile de dezvoltare, iar partea dreaptă arată activitățile de testare. Nu ar trebui să mă înșel dacă spun că în faza de dezvoltare atât verificarea, cât și validarea sunt efectuate împreună cu activitățile de dezvoltare propriu-zise.

Acum să înțelegem figura:

Partea stângă

După cum sa spus mai devreme, activitățile din partea stângă sunt activități de dezvoltare. În mod normal simțim, ce teste putem face în faza de dezvoltare, dar aceasta este frumusețea acestui model care demonstrează că testarea se poate face și în toate fazele activităților de dezvoltare.

Analiza cerințelor : În această fază, cerințele sunt colectate, analizate și studiate. Aici modul în care este implementat sistemul nu este important, dar ceea ce ar trebui să facă sistemul este important. Sesiuni de brainstorming / parcurs, interviurile se fac pentru a avea obiectivele clare.

  • Activități de verificare : Revizuirea cerințelor.
  • Activități de validare : Crearea UAT ( Test de acceptare a utilizatorului ) cazuri de testare
  • Artefacte produse : Document de înțelegere a cerințelor, cazuri de testare UAT.

Cerințe de sistem / Proiectare la nivel înalt : În această fază, este construit designul la nivel înalt al software-ului. Echipa studiază și investighează modul în care cerințele ar putea fi implementate. Fezabilitatea tehnică a cerințelor este, de asemenea, studiată. Echipa vine, de asemenea, cu modulele care ar fi create / dependențe, hardware / software are nevoie

  • Activități de verificare : Recenzii de proiectare
  • Activități de validare : Creatia lui Planul de testare a sistemului și cazuri, Crearea de indicatori de trasabilitate
  • Artefacte produse : Cazuri de testare a sistemului, rapoarte de fezabilitate, plan de testare a sistemului, cerințe hardware-software și module care trebuie create etc.

Design arhitectural: În această fază, pe baza designului la nivel înalt , se creează arhitectura software. Modulele, relațiile și dependențele acestora, diagrame arhitecturale, tabele de baze de date, detalii tehnologice sunt toate finalizate în această fază.

  • Activități de verificare : Recenzii de proiectare
  • Activități de validare : Planul de testare a integrării și cazurile de testare.
  • Artefacte produse : Documente de proiectare, plan de testare integrare și cazuri de testare, proiecte de tabele de baze de date etc.

Proiectare modul / Proiectare la nivel scăzut: În această fază, fiecare modul al componentelor software este proiectat individual. Metode, clase, interfețe, tipuri de date etc. sunt toate finalizate în această fază.

  • Activități de verificare : Recenzii de proiectare
  • Activități de validare : Crearea și revizuirea cazurilor de testare unitară.
  • Artefacte produse : Cazuri de testare unitară,

Implementare / Cod : În această fază, se realizează codarea propriu-zisă.

  • Activități de verificare : Revizuirea codului, revizuirea cazurilor de testare
  • Activități de validare : Crearea cazurilor de testare funcțională.
  • Artefacte produse : cazuri de testare, lista de verificare a revizuirii.

Partea dreaptă

Partea dreaptă demonstrează activitățile de testare sau faza de validare. Vom începe de jos.

Testarea unitara: În această fază, sunt executate toate cazurile de testare a unității, create în faza de proiectare la nivel scăzut.

* Testarea unității este o tehnică de testare a casetei albe, în care este scrisă o bucată de cod care invocă o metodă (sau orice altă bucată de cod) pentru a testa dacă fragmentul de cod oferă sau nu rezultatul așteptat. Această testare este practic realizată de echipa de dezvoltare. În cazul oricărei anomalii, defectele sunt înregistrate și urmărite.

Artefacte produse : Rezultatele executării testelor unitare

Testarea integrării : În această fază, sunt executate cazurile de testare a integrării care au fost create în faza de proiectare arhitecturală. În cazul unor anomalii, defectele sunt înregistrate și urmărite.

* Testarea integrării: Testarea integrării este o tehnică în care modulele testate pe unitate sunt integrate și testate dacă modulele integrate dau rezultatele așteptate. În cuvinte mai simple, validează dacă componentele aplicației funcționează împreună așa cum era de așteptat.

Artefacte produse : Rezultatele testului de integrare.

Testarea sistemelor : În această fază sunt executate toate cazurile de testare a sistemului, cazurile de testare funcțională și cazurile de testare nefuncționale. Cu alte cuvinte, testarea reală și completă a aplicației are loc aici. Defectele sunt înregistrate și urmărite pentru închiderea acestuia. Raportarea progreselor este, de asemenea, o parte majoră a acestei etape. Metricele de trasabilitate sunt actualizate pentru a verifica acoperirea și reducerea riscului.

Artefacte produse : Rezultatele testelor, jurnalele de testare, raportul defectelor, raportul rezumat al testelor și matricele de trasabilitate actualizate.

Testarea acceptării utilizatorului : Testarea acceptării este în principiu legată de testarea cerințelor afacerii. Aici testarea se face pentru a verifica dacă cerințele de afaceri sunt îndeplinite în mediul utilizatorului. Testarea compatibilității și uneori testarea nefuncțională ( Încărcare, stres și volum ) testarea se face și în această fază.

Artefacte produse : Rezultate UAT, matrice actualizate de acoperire a afacerii.

Când se folosește modelul V?

Modelul V este aplicabil atunci când:

  • Cerința este bine definită și nu este ambiguă
  • Criteriile de acceptare sunt bine definite.
  • Proiectul este de dimensiuni scurte spre medii.
  • Tehnologia și instrumentele utilizate nu sunt dinamice.

Puncte pro și contra utilizării modelului V.

PROSCONTRA
- Dezvoltarea și progresul sunt foarte organizate și sistematice-Nu este potrivit pentru proiecte mai mari și complexe
- Funcționează bine pentru proiecte de dimensiuni mici și mijlocii.- Nu este adecvat dacă cerințele nu sunt consistente.
- Testarea începe de la început, astfel încât ambiguitățile sunt identificate de la început.- Nu este produs niciun software de lucru în etapa intermediară.
- Ușor de gestionat, deoarece fiecare fază are obiective și obiective bine definite.- Nu există prevederi pentru efectuarea analizei riscurilor, astfel încât există incertitudine și riscuri.

Lectură recomandată

^