Meni

Funkcionalno testiranje protiv testiranja izvedbe: treba li to istodobno?

functional testing vs performance testing

Funkcionalno testiranje protiv testiranja performansi:

Razlike između Ispitivanje performansi, ispitivanje opterećenja i ispitivanje naprezanja su objašnjeni s primjerima u našem zadnjem vodiču.

Testiranje softvera pokriva širok raspon područja u kojima se može dogoditi bilo kakva provjera ili potvrda funkcionalnosti softvera. Povremeno se nefunkcionalni aspekti manje odnose na funkcionalne aspekte. Ne izvode se praktično; istovremeno tijekom testiranja softvera.

=> Kliknite ovdje za cjelovitu seriju vodiča za testiranje izvedbe

Ovaj članak objašnjava dodatne prednosti kvalitete softverskog proizvoda tijekom različitih scenarija životnog ciklusa testiranja softvera kad se istovremeno uzimaju i funkcionalni i nefunkcionalni.

ispitivanje funkcionalnih performansi 5

Što ćete naučiti:

Brza razlika između ispitivanja performansi i funkcionalnog ispitivanja

Sl BRIspitivanje funkcionalnosti
Ispitivanje performansi
1Da biste provjerili točnost softvera s određenim ulazima u odnosu na očekivani izlazZa provjeru ponašanja sustava u različitim uvjetima opterećenja
dvaMože biti ručno ili automatizirano
Može se učinkovito izvesti ako je automatiziran
3Jedan korisnik koji izvodi sve radnje
Nekoliko korisnika koji izvode željene operacije
4Potrebno je uključivanje kupca, ispitivača i programeraPotrebno je uključivanje kupaca, ispitivača, programera, DBA-a i N / W menadžerskog tima
5Probno okruženje za proizvodnju nije obvezno, a zahtjevi za V / V su minimalniPotrebno je blizu testnog okruženja za proizvodnju i nekoliko H / W postrojenja za popunjavanje tereta

Zašto bi funkcionalno ispitivanje i ispitivanje performansi trebalo raditi istovremeno?

Funkcionalno testiranje postaje mnogo važnije za bilo koje izdanje softvera. Stvarno na temelju rezultata provjera i potvrda u repliciranom proizvodnom ili testnom okruženju gdje se testiranje obično događa.

Propuštanje nedostataka može postati jedan od najvećih problema:

Ispitivači imaju veću odgovornost od programera u pogledu kvalitete proizvoda. U osnovi, oni ne žele da testirani proizvod ima curenje nedostataka. Ispitivači obično obavljaju samo funkcionalna ispitivanja da bi to postigli.

ispitivanje funkcionalnih performansi 1

Slijedi razgovor izmeđuVoditelj ispitivanja i ispitivač :

(Voditelj ispitivanja naziva se „TM“, a ispitivač „TR“)

TM : Hej prijatelju ... Kako stojimo s testiranjem proizvoda 'A'?

TR : Da ... Napredujemo u većem načinu.

TM : To je fantastično ... A koji je naš opseg u smislu ispitivanja performansi dok je funkcionalno testiranje u toku?

TR : Ne pokrivamo ih, naši bi se proizvodi trebali nalaziti samo u funkcionalnom području, a ne u nefunkcionalnom području. Također, testno okruženje koje koristimo nije točna replika produkcije.

Iz gornjeg razgovora treba uzeti u obzir nekoliko pitanja:

  • Ima li funkcionalno testiranje faktor koji ovisi o izvedbi?
  • Što ako se performanse softvera pogoršaju, ali isporuka proizvoda dogodi se bez provjere izvedbe?
  • Ispitivanje performansi - postoji li ono u procesu funkcionalnog ispitivanja?

Opća je praksa da testeri ne rade na nefunkcionalnim aspektima, osim ako se to od njih traži. Uobičajeno je izbjegavati nefunkcionalno ispitivanje dok klijent ne prijavi probleme s izvedbom testiranog softvera.

Dakle, trebate razmotriti 2 pitanja:

  1. Izvedba - utječe li na funkcionalno testiranje?
  2. Držimo li ispitivanje performansi kao zaseban rezultat, čak i ako klijenta brine?

Ispitivanje performansi je važno !

Softver radi na temelju različitih arhitektura i sljedećih modela, uključujući:

  1. Potrebni modeli odgovora na odgovor
  2. Sustavi temeljeni na transakcijama
  3. Sustavi temeljeni na opterećenju
  4. Sustavi temeljeni na replikaciji podataka

Funkcionalno testiranje ponašanja gore spomenutog sustavnog modela ovisi o performansama sustava.

ispitivanje funkcionalnih performansi 2

Stajalište automatizacije zahtijeva veliku pažnju prema ispitivanju performansi.

Slijedi razgovor izmeđuklijent i voditelj ispitivanja.

(Klijent se naziva „CL“, a voditelj ispitivanja kao „TM“)

CL : Stoga dolazimo do rješenja koje smo zatražili, nadam se da će biti višestrukih ponavljanja testiranja koje se trenutno događa.

TM : Da, to se može učiniti. Kao što ste rekli, bit će veća vjerojatnost iterativnog ispitivanja, željeli bismo predložiti automatizaciju koja će se baviti funkcionalnim (regresijskim) ispitivanjem.

CL : U redu, molim vas, pošaljite nam svoj pristup kako bismo to mogli odobriti. Automatizacija će imati puno veći učinak uz minimalan napor.

TM : Točno. Poradit ćemo na pristupu i javit ćemo vam se s dokazom o konceptu.

Iz gornjeg razgovora jasno je da je potreba klijenata optimizacija učinkovitosti.

Studija slučaja

Tvrtka ABC radi na projektu za razvoj softvera A. Testiranje softvera A radi tvrtka XYZ.

Ugovor za tvrtke ABC i XYZ ima određena ograničenja za njihovu suradnju. Svaka rasprava između dvije tvrtke trebala bi se odvijati jednom tjedno ili tri puta mjesečno. Sustav radi na modelu načina odgovora na zahtjev. Fazu razvoja završila je tvrtka ABC.

Sada je vrijeme da tvrtka XYZ izvrši formalno funkcionalno testiranje softvera A. XYZ počinje raditi na testiranju softvera A. Pokazali su čist pristup softveru i dali 'Go' za implementaciju uživo nakon 2 ciklusa testiranja.

Unatoč potvrdi o kvaliteti od tima za testiranje, implementacija uživo nije dobro prošla. Bilo je puno post-produkcijskih bugova. Klijenti su se suočavali s velikim brojem problema, uključujući prekid u funkcionalnosti za sve poslovne procese.

Pa što je sadproblem?

ispitivanje funkcionalnih performansi 3

  • Je li problem s ograničenjem suradnje između razvojnog i ispitnog tima?
  • Je li to da zahtjevi nisu zabilježeni 100%?
  • Je li to što proizvod nije testiran u odgovarajućem testnom okruženju?
  • Ili neki drugi uzroci?

Nakon pažljivog istraživanja i analize,zaključeno je sljedeće:

ispitivanje funkcionalnih performansi 4

  1. Bilo je malo ovisnih i međuovisnih aplikacija koje su imale problema s izvedbom tijekom dohvaćanja odgovora.
  2. Upotrijebljeni testni ulazi nisu bili apsolutni.
  3. Nije se vodilo računa o robusnosti softvera.
  4. Puno problema sa sinkronizacijom između više neovisnih aplikacija.
  5. Testiranje softvera obavilo je više ponovnih radova koji nisu uzeti u obzir.

Stoga nakonpopravne radnjeusvojio se tim za planiranje, predloženo je sljedeće:

  1. Treba povećati interakciju između razvojnog tima i testnog tima.
  2. Sve ovisne aplikacije trebaju biti povezane i uključene u testiranje funkcionalnosti sustava
  3. Vrijednost vremenskog ograničenja zahtjeva i odgovora treba povećati kako bi se dao prostor neprodukcijskim okruženjima
  4. U funkcionalnom ispitivanju moraju se koristiti različiti unosi u rasponu od jednostavnih do složenih
  5. Nefunkcionalno ispitivanje, posebno ispitivanje performansi i opterećenja, mora se obaviti prema savjetu popravnog tima.
  6. Uz testiranje sustava, mora se provesti i testiranje integracije sustava.
  7. Mora se osigurati minimalni vremenski razmak između bilo koje dvije iteracije testiranja. Ovo je za ponovno testiranje prethodno identificiranih bugova.
  8. Sve pogreške identificirane u prethodnim iteracijama trebale bi biti ispravljene u trenutnoj iteraciji.

Ispitni tim proveo je sve predložene radnje i za malo vremena otkriven je velik broj nedostataka.

Promatranja:

  1. Raspored implementacije softvera uživo znatno se poboljšao optimiziranjem vremena testnog ciklusa.
  2. Ostvaren je dobar napredak u optimizaciji kvalitete softvera. Stoga je došlo do strahovitog smanjenja broja ulaznica za podršku nakon provedbe.
  3. Ponovni radovi su smanjeni i testirano je ponavljanje umjesto ponovnog rada. Između različitih ponavljanja primijećena su bolja poboljšanja kvalitete.

Zaključak

Izvođenje nefunkcionalnog testiranja tijekom izvršavanja funkcionalnog testa je povoljnije i dodat će više prednosti ukupnoj kvaliteti softvera. To će identificirati pogreške u izvedbi (ograničene na testno okruženje i ovisnost), a time će smanjiti situacije pretpostavki funkcionalnih problema.

Potrebno je napraviti dovoljno planiranja za izvođenje funkcionalnih i nefunkcionalnih ispitivanja (na minimalnu razinu) kako bi se održao čvrst odnos među ostalim dionicima projekta.

O autoru: Ovo je članak koji je napisao Nagarajan. Radi kao probni voditelj s preko 6 godina iskustva u testiranju u raznim funkcionalnim područjima poput bankarstva, zrakoplovnih kompanija, telekoma u pogledu ručnog i automatiziranja.

Naš predstojeći vodič objasnit će više o planu ispitivanja izvedbe i strategiji ispitivanja.

što je korisničko ime i lozinka za usmjerivač

=> Posjetite ovdje za cjelovitu seriju vodiča za testiranje izvedbe

PREV Vodič | SLJEDEĆA Vodič

Preporučena literatura

^