what is stlc v model
Što je STLC V-model?
Jedan od glavnih hendikepa model slapa STLC je da su nedostaci pronađeni u vrlo kasnoj fazi razvojnog procesa budući da je ispitivanje provedeno na kraju razvojnog ciklusa. Otklanjanje nedostataka postalo je vrlo izazovno i skupo jer je pronađeno u vrlo kasnoj fazi. Kako bi se prevladao ovaj problem, uveden je novi razvojni model nazvan „V model“
V model je sada jedan od najčešće korištenih procesa razvoja softvera. Uvođenje V modela zapravo je dokazalo provedbu testiranja već u fazi zahtjeva. V model se naziva i modelom provjere i potvrde.
Što ćete naučiti:
Vodič za Microsoft Dynamics AX 2012 za početnike
Provjera i provjera valjanosti
Da bismo razumjeli V model, prvo shvatimo što je provjera i provjera valjanosti u softveru.
Verifikacija : Provjera je tehnika statičke analize. U ovoj se tehnici testiranje vrši bez izvršavanja koda. Primjeri uključuju - Recenzije, pregled i prolaz.
Provjera valjanosti : Provjera valjanosti je tehnika dinamičke analize gdje se ispitivanje vrši izvršavanjem koda. Primjeri uključuju funkcionalne i nefunkcionalne tehnike ispitivanja.
V-model
U V modelu, razvoj i QA aktivnosti rade se istovremeno. Ne postoji diskretna faza koja se naziva testiranje, već testiranje započinje odmah od faze zahtjeva. Aktivnosti provjere i potvrde idu ruku pod ruku.
Da bismo razumjeli V model, pogledajmo donju sliku:
U tipičnom razvojnom procesu lijeva strana prikazuje razvojne aktivnosti, a desna testne aktivnosti. Ne bih trebao pogriješiti ako kažem da se u fazi razvoja provode i provjera i provjera valjanosti zajedno sa stvarnim razvojnim aktivnostima.
Sada da shvatimo brojku:
Lijeva strana
Kao što je ranije rečeno, aktivnosti s lijeve strane su razvojne aktivnosti. Obično se osjećamo, koja testiranja možemo napraviti u fazi razvoja, ali ovo je ljepota ovog modela koji pokazuje da se ispitivanje može provoditi i u svim fazama razvojnih aktivnosti.
Analiza zahtjeva : U ovoj fazi zahtjevi se prikupljaju, analiziraju i proučavaju. Ovdje kako je sustav implementiran nije važno, već je važno što sustav treba raditi. Sesije / prolaz kroz moždane oluje, intervjui se rade kako bi ciljevi bili jasni.
- Aktivnosti provjere : Pregledi zahtjeva.
- Aktivnosti provjere valjanosti : Stvaranje UAT-a ( Test prihvaćanja korisnika ) test slučajevi
- Proizvedeni artefakti : Dokument o razumijevanju zahtjeva, UAT test slučajevi.
Zahtjevi sustava / Dizajn visoke razine : U ovoj fazi izrađuje se dizajn softvera na visokoj razini. Tim proučava i istražuje kako bi se zahtjevi mogli primijeniti. Također se proučava tehnička izvedivost zahtjeva. Tim također dolazi s modulima koji bi se kreirali / ovisnosti, hardverskim / softverskim potrebama
- Aktivnosti provjere : Recenzije dizajna
- Aktivnosti provjere valjanosti : Stvaranje Plan ispitivanja sustava i slučajevi, Stvaranje mjernih podataka sljedivosti
- Proizvedeni artefakti : Test slučajevi sustava, izvješća o izvedivosti, plan ispitivanja sustava, hardversko-softverski zahtjevi i moduli koji će se kreirati itd.
Arhitektonski dizajn: U ovoj fazi, na temelju dizajna na visokoj razini , kreira se softverska arhitektura. Moduli, njihovi odnosi i ovisnosti, arhitektonski dijagrami, tablice baza podataka, tehnološki detalji finalizirani su u ovoj fazi.
- Aktivnosti provjere : Recenzije dizajna
- Aktivnosti provjere valjanosti : Plan integracijskog ispitivanja i test slučajevi.
- Proizvedeni artefakti : Projektni dokumenti, plan integracijskog ispitivanja i testovi, dizajniranje tablica baze podataka itd.
Dizajn modula / dizajn niske razine: U ovoj fazi svaki modul softverskih komponenti dizajniran je pojedinačno. Metode, klase, sučelja, tipovi podataka itd. Dovršeni su u ovoj fazi.
- Aktivnosti provjere : Recenzije dizajna
- Aktivnosti provjere valjanosti : Stvaranje i pregled jedinica testnih slučajeva.
- Proizvedeni artefakti : Jedinstveni test slučajevi,
Provedba / Kodeks : U ovoj se fazi vrši stvarno kodiranje.
- Aktivnosti provjere : Pregled koda, pregled test slučajeva
- Aktivnosti provjere valjanosti : Stvaranje funkcionalnih test slučajeva.
- Proizvedeni artefakti : test slučajevi, pregled kontrolne liste.
Desna strana
Desna strana prikazuje aktivnosti ispitivanja ili fazu provjere valjanosti. Krenut ćemo od dna.
Jedinstveno testiranje: U ovoj se fazi izvršavaju svi jedinični testni slučajevi stvoreni u fazi projektiranja niske razine.
* Jedinstveno testiranje je tehnika testiranja bijelog okvira, gdje je napisan komad koda koji poziva metodu (ili bilo koji drugi dio koda) za testiranje daje li isječak koda očekivani izlaz ili ne. Ovo testiranje u osnovi izvodi razvojni tim. U slučaju bilo kakve anomalije, kvarovi se bilježe i prate.
Proizvedeni artefakti : Rezultati izvršenja jediničnog testa
Ispitivanje integracije : U ovoj se fazi izvršavaju slučajevi integracijskih testova koji su stvoreni u fazi arhitektonskog dizajna. U slučaju bilo kakvih anomalija, kvarovi se bilježe i prate.
* Integracijsko testiranje: Integracijsko testiranje tehnika je kojom se integrirani moduli koji se testiraju integriraju i ispituju daju li integrirani moduli očekivane rezultate. Jednostavnijim riječima, provjerava rade li komponente aplikacije kako se očekuje.
Proizvedeni artefakti : Rezultati integracijskog ispitivanja.
Ispitivanje sustava : U ovoj se fazi izvršavaju svi testni slučajevi sustava, funkcionalni i nefunkcionalni test slučajevi. Drugim riječima, ovdje se odvija stvarno i cjelovito testiranje zahtjeva. Kvarovi se bilježe i prate kako bi se zatvorili. Izvještavanje o napretku također je glavni dio ove faze. Mjerni podaci sljedivosti ažuriraju se radi provjere pokrivenosti i ublažavanja rizika.
Proizvedeni artefakti : Rezultati ispitivanja, zapisnici ispitivanja, izvještaj o nedostacima, sažetak izvješća i ažurirane matrice sljedivosti.
Ispitivanje prihvaćanja korisnika : Ispitivanje prihvatljivosti u osnovi je povezano s ispitivanjem poslovnih zahtjeva. Ovdje se vrši testiranje kako bi se potvrdilo da su poslovni zahtjevi zadovoljeni u korisničkom okruženju. Ispitivanje kompatibilnosti i ponekad nefunkcionalno ispitivanje ( Opterećenje, stres i volumen ) ispitivanja se također rade u ovoj fazi.
Proizvedeni artefakti : UAT rezultati, Ažurirane matrice poslovnog pokrića.
Kada koristiti V model?
V model je primjenjiv kada:
- Zahtjev je dobro definiran i nije dvosmislen
- Kriteriji prihvaćanja dobro su definirani.
- Projekt je kratak do srednje veličine.
- Tehnologija i alati koji se koriste nisu dinamični.
Prednosti i nedostaci upotrebe V modela
| PROZ | PROTIV |
|---|---|
| - Razvoj i napredak vrlo su organizirani i sustavni | -Nije prikladno za veće i složene projekte |
| - Dobro radi za manje do srednje projekte. | - Nije prikladno ako zahtjevi nisu dosljedni. |
| - Testiranje započinje od početka pa se nejasnoće prepoznaju od početka. | - U međufazi se ne proizvodi radni softver. |
| - Lako se njime upravlja jer svaka faza ima dobro definirane ciljeve. | - Nema odredbi za analizu rizika, tako da postoje neizvjesnost i rizici. |
Preporučena literatura
- Vodič za SOA testiranje: Metodologija testiranja za model arhitekture SOA
- Najbolji alati za testiranje softvera 2021. [Alati za automatizaciju ispitivanja kvalitete]
- Statičko ispitivanje i dinamičko ispitivanje - razlika između ove dvije važne tehnike ispitivanja
- Spiralni model - što je SDLC spiralni model?
- Praktično testiranje softvera - nova BESPLATNA e-knjiga [preuzimanje]
- Alfa testiranje i beta testiranje (cjelovit vodič)
- Preuzimanje e-knjige za testiranje primera
- Onsite - Offshore model projekata testiranja softvera (i kako to učiniti za vas)