Kompletan vodič za funkcionalno ispitivanje sa svojim vrstama i primjerima

complete functional testing guide with its types

Detaljni sveobuhvatni vodič za funkcionalno ispitivanje s vrstama, tehnikama i primjerima:

Što je funkcionalno testiranje?

Funkcionalno testiranje vrsta je crnog okvira koje se provodi kako bi se potvrdilo da se funkcionalnost aplikacije ili sustava ponaša prema očekivanjima.

To se radi kako bi se provjerila sva funkcionalnost aplikacije.

POPIS tutorijala obuhvaćenih ovom serijom:

Vodič br. 1: Što je funkcionalno ispitivanje (ovaj vodič)
Vodič br. 2: Pitanja za ispitivanje funkcionalnosti
Vodič br. 3: Vrh funkcionalnih alata za ispitivanje automatizacije
Vodič br. 4: Što je nefunkcionalno testiranje?
Vodič br. 5: Razlika između jedinice, funkcionalne i Integracija Testiranje
Vodič br. 6 : Zašto bi se ispitivanje funkcionalnosti i performansi trebalo provoditi istovremeno

Alati:

Vodič br. 7: Funkcionalna automatizacija ispitivanja sa Ranorex Studiom
Vodič br. 8: UFT funkcionalni alat Nove značajke
Vodič br. 9: Unakrsna funkcionalna automatizacija preglednika pomoću alata Parrot QA
Vodič br. 10: Vodič za alat za otvoreni izvor Jubula za testiranje funkcionalnosti

Što ćete naučiti:

• Uvod u funkcionalno ispitivanje
  • Vrste funkcionalnih ispitivanja
  • Postupak
  • Kriteriji za ulazak / izlazak
    • Kriteriji za prijavu:
    • Kriteriji izlaska:
  • Uključeni koraci
  • Pristup
  • Tehnike funkcionalnog ispitivanja
    • # 1) Testovi na temelju krajnjeg korisnika / sustava
    • # 2) Testovi ekvivalencije
    • # 3) Ispitivanja granične vrijednosti
    • # 4) Testovi zasnovani na odluci
    • # 5) Alternativni testovi protoka
    • # 6) Ad-hoc testovi
  • Automatizacija funkcionalnih ispitivanja
  • Prednosti
  • Ograničenja
  • Zaključak
  • Preporučena literatura

Uvod u funkcionalno ispitivanje

Mora postojati nešto što definira što je prihvatljivo ponašanje, a što ne.

To je navedeno u funkcionalnoj specifikaciji ili specifikaciji zahtjeva. To je dokument koji opisuje što je korisniku to dopušteno, da može utvrditi usklađenost aplikacije ili sustava s tim. Uz to, ponekad bi to moglo podrazumijevati i stvarne poslovne scenarije koje treba provjeriti.

Stoga se ispitivanje funkcionalnosti može provesti putem dvije popularne tehnike :

• Ispitivanje na temelju zahtjeva: Sadrži sve funkcionalne specifikacije koje su osnova za sva ispitivanja koja će se provesti.
• Testiranje na temelju poslovnih scenarija: Sadrži informacije o tome kako će se sustav percipirati iz perspektive poslovnog procesa.

Testiranje i osiguranje kvalitete ogroman su dio SDLC procesa. Kao tester, moramo biti svjesni svih vrsta testiranja, čak i ako nismo izravno u vezi s njima svakodnevno.

Kako je testiranje ocean, njegov je opseg doista tako velik, a mi imamo posvećene testere koji rade različite vrste ispitivanja . Najvjerojatnije svi mi moramo biti upoznati s većinom koncepata, ali neće škoditi ako se sve to organizira ovdje.

Vrste funkcionalnih ispitivanja

Funkcionalno testiranje ima mnogo kategorija i one se mogu koristiti na temelju scenarija.

U nastavku se ukratko raspravlja o najistaknutijim vrstama:

Jedinstveno ispitivanje :

Jedinstveno testiranje obično izvodi programer koji piše različite jedinice koda koje bi mogle biti povezane ili nepovezane kako bi se postigla određena funkcionalnost. Njegovo, to obično podrazumijeva pisanje jediničnih testova koji bi pozvali metode u svakoj jedinici i provjerili valjanost kada se zahtijevaju parametri, a njegova povratna vrijednost je onakva kakva se očekuje.

Pokrivenost kodom važan je dio jediničnog testiranja u kojem moraju postojati ispitni slučajevi kako bi se pokrila sljedeća tri:

i) Pokrivenost linije
ii) Pokrivenost putova koda
iii) Pokrivenost metode

Ispitivanje razuma : Testiranje koje je provedeno kako bi se osiguralo da sve glavne i vitalne funkcionalnosti aplikacije / sustava rade ispravno. To se obično radi nakon testa na dim.

Ispitivanje dima : Testiranje koje se provodi nakon svake gradnje pušta se kako bi se osiguralo stabilnost izrade. Također se naziva i testiranje provjere gradnje.

Regresijski testovi : Testiranje provedeno kako bi se osiguralo da dodavanje novog koda, poboljšanja, ispravljanje programskih pogrešaka ne narušava postojeću funkcionalnost niti uzrokuje bilo kakvu nestabilnost i još uvijek radi prema specifikacijama.

Regresijski testovi ne moraju biti toliko opsežni kao stvarni funkcionalni testovi, već bi trebali osigurati samo količinu pokrića kako bi se potvrdilo da je funkcionalnost stabilna.

Testovi integracije : Kada se sustav oslanja na više funkcionalnih modula koji mogu pojedinačno raditi savršeno, ali moraju koherentno raditi kad su povezani zajedno da bi se postigao kraj do kraja, provjera valjanosti takvih scenarija naziva se integracijskim testiranjem.

Beta / Ispitivanje upotrebljivosti : Proizvod je izložen stvarnom kupcu u proizvodnji poput okoliša i oni ga testiraju. Iz toga proizlazi korisnička udobnost i uzimaju se povratne informacije. Ovo je slično testiranju prihvaćanja korisnika.

Predstavimo ovo na laganom dijagramu tijeka:

Ispitivanje funkcionalnog sustava:

Ispitivanje sustava je ispitivanje koje se izvodi na cjelovitom sustavu kako bi se provjerilo radi li očekivano nakon što se integriraju svi moduli ili komponente.

Ispitivanje od kraja do kraja izvodi se radi provjere funkcionalnosti proizvoda. Ovo se ispitivanje provodi samo kada je testiranje integracije sustava završeno, uključujući i funkcionalne i nefunkcionalne zahtjeve.

=> Razlika između jedinstvenog, funkcionalnog i integracijskog ispitivanja

Postupak

Ovaj postupak testiranja ima tri glavna koraka:

Pristup, tehnike i primjeri

Funkcionalno ili bihevioralno testiranje generira izlaz na temelju zadanih ulaza i utvrđuje funkcionira li sustav ispravno prema specifikacijama.

Stoga će slikovni prikaz izgledati kako je prikazano u nastavku:

Kriteriji za ulazak / izlazak

Kriteriji za prijavu:

• Dokument o specifikaciji zahtjeva definiran je i odobren.
• Pripremljeni su test slučajevi.
• Podaci o testiranju su stvoreni.
• Okružje za testiranje je spremno, svi potrebni alati su dostupni i spremni.
• Potpuna ili djelomična aplikacija razvijena je i testirana u jedinici te je spremna za testiranje.

Kriteriji izlaska:

• Završeno je izvršavanje svih slučajeva funkcionalnih testova.
• Nisu otvorene kritične ili pogreške P1, P2.
• Prijavljeni bugovi su prepoznati.

Uključeni koraci

U nastavku su navedeni različiti koraci koji su uključeni u ovo ispitivanje:

• Prvi korak koji je uključen je utvrđivanje funkcionalnosti proizvoda koji treba testirati, a uključuje testiranje glavnih funkcionalnosti, stanja pogrešaka i poruka, ispitivanje upotrebljivosti, tj. Je li proizvod prilagođen korisniku ili ne, itd.
• Sljedeći je korak stvaranje ulaznih podataka za funkcionalnost koja će se testirati prema specifikaciji zahtjeva.
• Kasnije, iz specifikacije zahtjeva, izlaz se određuje za funkcionalnost koja se ispituje.
• Izvršeni su pripremljeni testovi.
• Stvarni izlaz, tj. Izlaz nakon izvršavanja testnog slučaja i očekivani izlaz (određeni iz specifikacije zahtjeva) uspoređuju se kako bi se utvrdilo radi li funkcionalnost prema očekivanjima ili ne.

Pristup

Mogu se zamisliti i napisati različite vrste scenarija u obliku 'test slučajeva'. Kao QA ljudi, svi znamo kako izgleda kostur testnog slučaja.

Uglavnom ima četiri dijela:

• Sažetak testa
• Preduvjeti
• Ispitni koraci i
• Očekivani rezultati.

Pokušaj pisanja svake vrste testa ne samo da je nemoguć već je i dugotrajan i skup.

Tipično bismo željeli otkriti maksimalan broj grešaka bez ikakvih bijegova pomoću postojećih testova. Stoga QA mora koristiti tehnike optimizacije i strategiju kako bi pristupili testiranju.

Objasnimo to s primjer.

Primjeri slučajeva upotrebe funkcionalnog testiranja:

Uzmite mrežni HRMS portal na koji se zaposlenik prijavljuje svojim korisničkim računom i lozinkom. Na stranici za prijavu nalaze se dva tekstna polja za korisničko ime i lozinku i dva gumba: Prijava i Odustani. Uspješna prijava vodi korisnika na početnu stranicu HRMS-a, a otkazivanje će otkazati prijavu.

Specifikacije su prikazane dolje:

# 1) Polje korisničkog identiteta zauzima najmanje 6 znakova, najviše 10 znakova, brojeve (0-9), slova (a-z, A-z), posebne znakove (dopušteni su samo podvlaka, točka, crtica) i ne može ostati prazno. Korisnički ID mora počinjati znakom ili brojem, a ne posebnim znakovima.

#dva) Polje za lozinku zauzima najmanje 6 znakova, najviše 8 znakova, brojeve (0-9), slova (a-z, A-Z), posebne znakove (svi) i ne može biti prazno.

Osnovni pristup testiranju ovog scenarija može se klasificirati u dvije široke kategorije:

1. Pozitivno ispitivanje i
2. Negativno testiranje

Naravno, svaka od ovih kategorija ima svoj pododjeljak testova koji će se provesti.

Pozitivni testovi su sretni testovi koji se rade kako bi se osiguralo da proizvod udovoljava - barem osnovnim zahtjevima koji su vitalni za upotrebu kupaca.

Negativni scenariji osigurajte da se proizvod ponaša ispravno čak i kad je izložen neočekivanim podacima.

Predloženo čitanje => Što je negativno testiranje i kako pisati negativne test slučajeve

Dopustite mi sada da pokušam strukturirati tehnike testiranja koristeći donji dijagram toka. Ući ćemo u detalje svakog od tih testova.

Tehnike funkcionalnog ispitivanja

# 1) Testovi na temelju krajnjeg korisnika / sustava

Testni sustav može imati mnogo komponenata koje kada se spoje zajedno postižu korisnički scenarij.

U Primjer , scenarij kupca uključivao bi zadatke poput učitavanja HRMS aplikacije, unosa ispravnih vjerodajnica, odlaska na početnu stranicu, izvođenja nekih radnji i odjave iz sustava. Ovaj određeni tijek mora raditi bez ikakvih pogrešaka za osnovni poslovni scenarij.

kako biste povećali sigurnost interne mreže vaše tvrtke

U nastavku su navedeni neki uzorci:

Ovo je osnovni primjer kako se ispituju slučajevi za određene situacije. Gornji format primijenit će se i na sve testove u nastavku. Radi jakog konceptualnog utemeljenja, stavio sam samo neke jednostavne testove gore i dolje.

# 2) Testovi ekvivalencije

U Ekvivalentna particija , podaci o ispitivanju odvojeni su u različite particije koje se nazivaju klase podataka ekvivalencije. Podaci na svakoj particiji moraju se ponašati na isti način, stoga treba testirati samo jedan uvjet. Slično tome, ako jedan uvjet u particiji ne radi, niti jedan od ostalih neće raditi.

Na primjer , u gornjem scenariju polje korisničkog ID-a može imati najviše 10 znakova, pa bi se unos podataka> 10 trebao ponašati na isti način.

# 3) Ispitivanja granične vrijednosti

Granični testovi podrazumijevaju ograničenja podataka za aplikaciju i potvrđuju kako se ona ponaša.

Stoga, ako se ulazi isporučuju izvan graničnih vrijednosti, tada se to smatra negativnim ispitivanjem. Dakle, minimalno 6 znakova za korisnika postavlja ograničenje granice. Testovi napisani da imaju korisnički ID<6 characters are boundary analysis tests.

# 4) Testovi zasnovani na odluci

Testovi zasnovani na odlukama usredotočeni su na ideologiju mogućih ishoda sustava kada je određeni uvjet zadovoljen.

U gore navedenom scenariju, mogu se odmah izvesti sljedeći testovi zasnovani na odluci:

1. Ako se unesu pogrešne vjerodajnice, to bi trebalo naznačiti korisniku i ponovo učitati stranicu za prijavu.
2. Ako korisnik unese ispravne vjerodajnice, trebao bi ga odvesti do sljedećeg korisničkog sučelja.
3. Ako korisnik unese ispravne vjerodajnice, ali želi otkazati prijavu, tada ga ne bi trebao odvesti na sljedeće korisničko sučelje i ponovo učitati stranicu za prijavu.

# 5) Alternativni testovi protoka

Pokreću se zamjenski testovi puta da bi se provjerili svi mogući načini koji postoje, osim glavnog toka za postizanje funkcije.

# 6) Ad-hoc testovi

Kada se većina bugova otkrije pomoću gore navedenih tehnika, ad-hoc testovi izvrstan su način za otkrivanje bilo kakvih odstupanja koja ranije nisu uočena. Oni se izvode s razmišljanjem da razbiju sustav i provjere reagira li graciozno.

Na primjer , uzorak testnog slučaja bio bi:

• Korisnik je prijavljen, ali administrator briše korisnički račun dok izvodi neke operacije. Bilo bi zanimljivo vidjeti kako aplikacija to graciozno rješava.

Funkcionalno vs nefunkcionalno testiranje:

Nefunkcionalni testovi usredotočite se na kvalitetu aplikacije / sustava u cjelini. Stoga se pokušava utvrditi koliko dobro sustav radi prema zahtjevima kupca za razliku od funkcije koju obavlja.

=> Točnu razliku pročitajte ovdje

Automatizacija funkcionalnih ispitivanja

Možemo li automatizirati funkcionalne testove?

Pomoću automatizacije može se smanjiti ručni napor, uštedjeti vrijeme, izbjeći klizanje bugova i povećati učinkovitost.

Međutim, nije moguće automatizirati sve i svašta. Ovo se testiranje može automatizirati, ali korisnik mora razraditi test slučajeve za automatizaciju. Važno je pronaći prave test slučajeve koji će se automatizirati zajedno s odgovarajućim alatom.

Automatizacija funkcionalnih slučajeva može imati nedostataka, poput ako je broj testnih slučajeva mnogo veći i ponavlja se iznova (što se mora učiniti), tada bi se programer mogao suočiti s problemom u izvršavanju promjena u kodu.

Čini se da mnogo puta tijekom izvođenja analize bijega, istaknuti i višegodišnji uzrok bijega nedostaje pokrivenosti testom u određenoj funkciji.

Opet, postoji nekoliko uzroka da se to dogodi, poput nedostatka okruženja, nedostatka testera, previše funkcija koje se isporučuju, manje vremena za pokrivanje svih aspekata testiranja, a ponekad i jednostavno previđanje.

Iako bi namjenski ispitni timovi mogli obaviti detaljna ispitivanja na svakom sprintu ili svakom ispitnom ciklusu, nedostaci će uvijek postojati i uvijek će biti nedostataka koji bi mogli propustiti. To je jedna od temeljnih potreba za uspostavljanjem automatizacije ispitivanja, čime se postiže značajno poboljšanje učinkovitosti cjelokupnog postupka ispitivanja i pokrivenosti ispitnih slučajeva.

Iako automatizirano testiranje nikada ne može zamijeniti ručno testiranje, pokazivanje idealne kombinacije njih dvoje pokazat će se vitalno za postizanje željene kvalitete u projektima softvera.

Razmatranja o automatizaciji:

# 1) Odaberite ispravni alat za automatizaciju : Na tržištu je dostupno nekoliko alata, odabir alata za automatizaciju pravi je zastrašujući zadatak! Međutim, mogli biste napraviti popis zahtjeva na temelju kojeg možete odabrati koji će se alat za automatizaciju koristiti.

Neki od primarnih aspekata kojih treba razmišljati uključuju:

• Odaberite alat koji će svi članovi QA tima biti lako koristiti ako već nemaju potrebne vještine.
• Alat se može koristiti u različitim okruženjima. Za Primjer : Mogu li se skripte stvarati na jednoj OS platformi, a izvoditi na drugoj? Trebate li CLI automatizaciju, automatizaciju korisničkog sučelja, automatizaciju mobilnih aplikacija ili sve?
• Alat mora imati sve značajke koje su vam potrebne. Za Primjer : Ako neki testeri nisu dobro upućeni u jezik skripti, alat bi trebao imati značajku snimanja i reprodukcije, a zatim podržati pretvorbu snimljene skripte u željeni jezik skriptiranja. Isto tako, ako vam je potreban i alat za podršku automatiziranim testovima gradnje, specifičnom izvještavanju i bilježenju, tada to mora biti u stanju i učiniti.
• Alat mora biti u mogućnosti podržati ponovnu upotrebu testnih slučajeva u slučaju promjena korisničkog sučelja.

Alati za automatizaciju : Postoji dosta alata koji su dostupni za funkcionalnu automatizaciju. Selen je vjerojatno omiljeni favorit, ali postoje i neki drugi alati otvorenog koda poput Sahi, Watir, Robotium, AutoIt itd.

Na tržištu je dostupno nekoliko alata za automatizaciju ispitivanja. Ali odabir odgovarajućeg alata vrlo je važan za organizaciju. To može ovisiti o zahtjevu, jednostavnosti upotrebe i trošku ovdje igra glavnu ulogu.

Dolje su dati neki od najboljih alata za funkcionalno testiranje:

• Selen
• QTP
• Junit
• Loadrunner
• SAPUN
• TestComplete

=> Pogledajte ovaj cjeloviti popis najboljih funkcionalnih alata za automatizaciju

#dva) Odaberite prave test slučajeve za automatizaciju : Ako želite iz automatizacije izvući najbolje, tada je vitalno biti pametan u pogledu vrsta testova koje odaberete za automatizaciju. Ako postoje testovi koji zahtijevaju uključivanje i isključivanje nekih postavki i konfiguracija tijekom izvođenja testa, tada ih je najbolje ne automatizirati.

Stoga možete automatizirati testove koji:

• Potrebno je izvoditi više puta.
• Pokrenite s različitim vrstama podataka.
• Neki slučajevi P1, P2 oduzimaju puno truda i vremena.
• Testovi skloni pogreškama.
• Skup testova koje je potrebno pokrenuti u različitim okruženjima, preglednicima itd.

# 3) Namjenski tim za automatizaciju : To je vjerojatno zanemareno u većini organizacija i automatizacija se nameće svim članovima QA tima.

Svaki član tima ima različite razine iskustva, skupove vještina, razine interesa, propusnost za podršku automatizaciji itd. Neki su pojedinci možda vještiji u izvršavanju ručnih testova, dok neki drugi mogu znati alate za skriptiranje i automatizaciju.

U ovakvim situacijama dobra je praksa uzeti analizu svih članova tima i neke članove posvetiti samo automatizaciji.

Automatizacijska aktivnost zahtijeva vrijeme, trud, znanje i predan tim koji će pomoći u postizanju potrebnih rezultata, umjesto da preoptereti sve članove tima ručnim i automatizacijskim ispitivanjem.

# 4) Podaci na temelju podataka: Automatizirani test slučajevi koji zahtijevaju više skupova podataka trebaju biti dobro napisani kako bi se mogli ponovno koristiti. Podaci se mogu pisati u izvore kao što su tekst ili datoteka svojstava, XML datoteke ili čitati iz baze podataka.

Koji god izvor podataka bio, stvaranje dobro strukturiranih podataka za automatizaciju čini okvir lakšim za održavanje i čini postojeće testne skripte iskorištenima u punom potencijalu.

# 5) Promjene korisničkog sučelja ne smiju prekinuti testove: Test slučajevi koje kreirate odabranim alatom moraju se nositi s potencijalnim promjenama korisničkog sučelja. Na primjer, ranije verzije selena koristile su mjesto za prepoznavanje elemenata stranice.

Stoga, ako se korisničko sučelje promijenilo, ti elementi više nisu pronađeni na tim mjestima, a zauzvrat će dovesti do masovnog neuspjeha testova.

Stoga je važno unaprijed razumjeti nedostatke alata i izraditi test slučajeve tako da su u slučaju promjena korisničkog sučelja potrebne samo minimalne promjene.

# 6) Česta ispitivanja: Nakon što pripremite osnovni segment za testiranje automatizacije, planirajte češće izvršavanje ovog područja. Ovo ima dvosmjernu prednost: jedna je ta što možete poboljšati okvir za automatizaciju i učiniti je robusnijim, a druga je što ćete uhvatiti više grešaka u procesu.

Prednosti

U nastavku su navedene razne prednosti funkcionalnog testiranja:

• Ovo ispitivanje reproducira ili je preslika stvarnog sustava, tj. Preslika je onoga što je proizvod u živom okruženju. Testiranje je usredotočeno na specifikacije prema korištenju korisnika, tj. Na specifikacije sustava, operativni sustav, preglednike itd.
• Ne radi ni na kakvim, ali ali na bilo kojim pretpostavkama o strukturi sustava.
• Ovo ispitivanje osigurava isporuku visokokvalitetnog proizvoda koji udovoljava zahtjevima kupca i osigurava da je kupac zadovoljan krajnjim rezultatima.
• Osigurava isporuku proizvoda bez grešaka koji ima sve funkcionalnosti prema zahtjevu kupca.
• Ispitivanje temeljeno na riziku vrši se kako bi se smanjile šanse za bilo kakvu vrstu rizika u proizvodu.

Ograničenja

Ovo se ispitivanje vrši kako bi se osiguralo da proizvod radi kako se očekivalo i da je cjelokupni zahtjev implementiran te da je proizvod točno prema zahtjevu kupca.

Međutim, ne uzima u obzir ostale čimbenike kao što su performanse proizvoda, tj. Odziv, vrijeme protoka itd., Koji su važni i koji su itekako potrebni da budu dio testiranja prije puštanja proizvoda.

Mane

• Mnogo je šansi da se izvrši suvišno testiranje.
• U proizvodu se mogu propustiti logičke pogreške.
• Ovo se ispitivanje temelji na zahtjevu, ako u slučaju da zahtjev nije potpun ili je složen ili nije jasan, izvođenje ovog ispitivanja u takvom scenariju postaje teško i također može potrajati.

Stoga su u osnovi obje ove vrste ispitivanja potrebne za kvalitetan proizvod.

Zaključak

Ovaj je vodič sveobuhvatno raspravljao o svemu što trebate znati o funkcionalnom testiranju, izravno iz osnova.

Funkcionalno testiranje jedan je od važnih postupaka testiranja jer se njime provjerava funkcionalnost proizvoda koji je najtraženiji i zaista važan aspekt bilo kojeg proizvoda ili aplikacije.

O autoru: Sanjay Zalavadia - kao potpredsjednik korisničke službe za Zephyr , donosi preko 15 godina vodstvenog iskustva u IT i službama tehničke podrške.

Nadam se da će neke od tehnika koje smo predložili dobro doći svim čitateljima. Javite nam svoje misli u komentarima ispod.

Predloženo čitanje => Vodič za testiranje značajki

Preporučena literatura

• Funkcionalno ispitivanje vs nefunkcionalno testiranje
• Alfa testiranje i beta testiranje (cjelovit vodič)
• Najbolji alati za testiranje softvera 2021. (Alati za automatizaciju ispitivanja kvalitete)
• Razlike između jedinstvenog testiranja, integracijskog ispitivanja i funkcionalnog ispitivanja
• Vrste testiranja softvera: različite vrste ispitivanja s pojedinostima
• Spock za integraciju i funkcionalna ispitivanja sa selenom
• Kompletni vodič za testiranje provjere izrade (BVT testiranje)
• Cjelovit nefunkcionalni vodič za testiranje za početnike