Osnove softverskog testiranja - pitanja i odgovori

Testiranje softvera aktivnost je u razvoju softvera. Istraga je koja se provodi protiv softvera radi pružanja informacija o kvaliteti softvera dionicima.

Što je testiranje softvera?

Različiti ljudi smislili su različite definicije za testiranje softvera, ali općenito je cilj:

  • Kako bi se osiguralo da softver ispunjava dogovorene zahtjeve i dizajn
  • Aplikacija radi kako se očekivalo
  • Aplikacija ne sadrži ozbiljne greške
  • Ispunjava namjeravanu upotrebu prema očekivanjima korisnika

Testiranje softvera često se koristi zajedno s pojmovima verifikacija i validacija .

Provjera valjanosti : Radimo li ispravan posao? Verifikacija : Radimo li posao kako treba?

Provjera je provjera ili ispitivanje predmeta, uključujući softver, radi usklađenosti i usklađenosti s pridruženom specifikacijom.

Provjera valjanosti postupak je provjere da li je navedeno ono što je korisnik zapravo želio.



Testiranje softvera samo je jedna vrsta provjere, koja također koristi tehnike poput pregleda, analize, inspekcije i prolaska.

Što je istraživačko ispitivanje i kada ga treba izvesti?

Definicija istraživačkog ispitivanja je 'simultani dizajn i izvođenje ispitivanja' na temelju aplikacije. To znači da ispitivač koristi svoje znanje iz domene i iskustvo testiranja kako bi predvidio gdje i pod kojim uvjetima bi se sustav mogao neočekivano ponašati. Kako tester započinje s istraživanjem sustava, nove ideje za dizajn testa smišljaju se u hodu i izvršavaju prema testiranom softveru.

Na sesiji istraživačkog testiranja ispitivač izvršava lanac radnji protiv sustava, a svaka radnja ovisi o rezultatu prethodne radnje, stoga bi ishod rezultata radnji mogao utjecati na ono što ispitivač dalje radi, stoga su test sesije nije istovjetan.

To je za razliku od skriptnog testiranja gdje su testovi unaprijed osmišljeni koristeći se zahtjevima ili projektnim dokumentima, obično prije nego što sustav bude spreman i izvrši te iste korake protiv sustava u neko drugo vrijeme.

Istraživačka ispitivanja obično se izvode dok se proizvod razvija (okretan) ili kao posljednja provjera prije izdavanja softvera. To je dopunska aktivnost automatiziranog regresijskog ispitivanja.

Koje ispitne tehnike postoje i koja je njihova svrha?

Ispitne tehnike prvenstveno se koriste u dvije svrhe: a) za identificiranje nedostataka, b) za smanjenje broja testnih slučajeva.

  • Ekvivalentna particija uglavnom se koristi za smanjenje broja testnih slučajeva identificiranjem različitih skupova podataka koji nisu isti i izvršavanjem samo jednog testa iz svakog skupa podataka
  • Analiza granične vrijednosti koristi se za provjeru ponašanja sustava na granicama dopuštenih podataka.
  • Ispitivanje prijelaza stanja koristi se za provjeru dopuštenih i nedopuštenih stanja i prijelaza iz jednog stanja u drugo različitim ulaznim podacima
  • Testiranje u paru ili u svim parovima vrlo je moćna tehnika testiranja i uglavnom se koristi za smanjenje broja testnih slučajeva, istovremeno povećavajući pokrivenost kombinacija značajki.

Zašto je testiranje potrebno?

Testiranje je potrebno kako bi se identificirali svi nedostaci prisutni u softveru koji mogu naštetiti. Bez odgovarajućeg testiranja mogli bismo izdati softver koji bi mogao kvariti i izazvati ozbiljne ozljede.

Primjeri mogu biti:

  • Softver u stroju za održavanje života koji može nanijeti ozbiljnu štetu pacijentu;
  • Softver u nuklearnoj elektrani koji prati nuklearnu aktivnost može naštetiti okolišu
  • Bankarska ili financijska aplikacija koja izračunava tečajeve može uzrokovati financijski gubitak u poslovanju

Koja je razlika između greške, kvara, pogreške, kvara, greške i pogreške?

Pogreška i pogreška su iste stvari. Bug, kvar i greška su ista stvar.

Općenito, ljudsko biće može pogriješiti (pogreška) koja uzrokuje kvar (grešku, kvar) u softverskoj aplikaciji koja može uzrokovati kvar.

Kvarovi se javljaju jer su ljudi skloni griješiti, a softverska aplikacija može biti vrlo složena pa integracija različitih komponenata može prouzročiti neobična ponašanja.

Koliko je testiranja dovoljno?

Na ovo pitanje nema konačnog odgovora. Testiranje nije apsolutno i nema ograničenja. Međutim, možemo koristiti metriku rizika (ispitivanje temeljeno na riziku) kako bismo identificirali vjerojatne scenarije koji mogu nanijeti najviše štete ili dijelove softvera koji se uglavnom koristi, tako da svoje vrijeme i trud usmjerimo na najvažnije odjeljke.

Testiranje bi trebalo pružiti dovoljno informacija o statusu ili zdravlju aplikacije, tako da dionici mogu donijeti utemeljenu odluku hoće li objaviti softver ili potrošiti više vremena na testiranje.

Što je temeljni postupak ispitivanja

Da bi se postigla većina ispitnih aktivnosti, mora se slijediti definirani postupak. No, prije nego što započne bilo koja aktivnost testiranja, velik dio napora trebao bi se potrošiti na izradu dobrog plana ispitivanja. Dobar plan ispitivanja uvelike osigurava pridržavanje aktivnosti ispitivanja onim što testiranje pokušava postići.

Možda je najprimjenjiviji za prilično formalno okruženje za testiranje (kao što je kritično za misiju). Većina komercijalnih organizacija ima manje rigorozne postupke ispitivanja. Međutim, bilo koji pokušaj testiranja može koristiti ove korake u nekom obliku.

Osnovni testni postupak sastoji se od pet aktivnosti:

  • Planiranje
  • Specifikacija
  • Izvršenje
  • Snimanje
  • Provjeravanje završetka ispitivanja

Proces ispitivanja uvijek započinje planiranjem testa i završava provjerom završetka testa.

Bilo koja i sve aktivnosti mogu se ponoviti (ili barem ponovno posjetiti), jer može biti potreban određeni broj ponavljanja prije nego što se ispune kriteriji dovršenja definirani tijekom aktivnosti planiranja ispitivanja.

Sedam principa testiranja softvera

Slijedi sedam principa testiranja softvera:

1. Testiranje pokazuje prisutnost bugova

Testiranje aplikacije može samo otkriti da postoji jedan ili više nedostataka u aplikaciji, međutim samo testiranje ne može dokazati da aplikacija ne sadrži pogreške. Stoga je važno dizajnirati ispitne slučajeve koji otkrivaju što više nedostataka.

2. Iscrpno ispitivanje je nemoguće

Ako aplikacija koja se testira (AUT) nema vrlo jednostavnu logičku strukturu i ograničen unos, nije moguće testirati sve moguće kombinacije podataka i scenarija. Iz tog se razloga rizik i prioriteti koriste za koncentraciju na najvažnije aspekte za testiranje.

3. Rano testiranje

Što prije započnemo s testiranjem, to bolje možemo iskoristiti dostupno vrijeme. Čim su dostupni početni proizvodi, takvi zahtjevi ili projektna dokumentacija, možemo započeti testiranje. Uobičajeno je da se faza testiranja stisne na kraju razvojnog životnog ciklusa, tj. Kada je razvoj završen, tako da ranim započinjanjem testiranja možemo pripremiti testiranje za svaku razinu razvojnog životnog ciklusa.

Sljedeća važna točka ranog testiranja jest da ih je puno lakše i jeftinije otkloniti kad se ranije u životnom ciklusu pronađu kvarovi. Mnogo je jeftinije promijeniti netočan zahtjev nego promijeniti funkciju u velikom sustavu koji ne radi kako je zatraženo ili kako je zamišljeno!

4. Grupiranje nedostataka

Tijekom ispitivanja može se primijetiti da se većina prijavljenih nedostataka odnosi na mali broj modula u sustavu. tj. mali broj modula sadrži većinu nedostataka u sustavu. Ovo je primjena Pareto principa na testiranje softvera: približno 80% problema nalazi se u 20% modula.

5. Paradoks pesticida

Ako nastavite izvoditi isti niz testova iznova i iznova, šanse su da ti slučajevi više neće otkriti nove nedostatke. Budući da se sustav razvija, mnogi prethodno prijavljeni nedostaci bili su otklonjeni, a stari primjeri više se ne primjenjuju.

Kad god se otkloni kvar ili doda nova funkcionalnost, moramo izvršiti regresijsko testiranje kako bismo bili sigurni da novi promijenjeni softver nije pokvario nijedan drugi dio softvera. Međutim, ti slučajevi regresijskog testa također se trebaju promijeniti kako bi odražavali promjene napravljene u softveru kako bi bile primjenjive i nadamo se da će otkloniti nove nedostatke.

6. Testiranje ovisi o kontekstu

Različite metodologije, tehnike i vrste ispitivanja povezane su s vrstom i prirodom prijave. Na primjer, softverska aplikacija u medicinskom uređaju treba više testiranja nego softver za igre.

Što je još važnije, softver za medicinske uređaje zahtijeva ispitivanje temeljeno na riziku, mora biti usklađen s regulatorima u medicinskoj industriji i moguće posebne tehnike dizajniranja testova.

Po istom principu, vrlo popularno web mjesto mora proći rigorozno testiranje performansi kao i testiranje funkcionalnosti kako bi se osiguralo da performanse ne utječu opterećenje na poslužiteljima.

7. Odsutnost zabluda pogrešaka

Samo zato što testiranje nije pronašlo nikakve nedostatke u softveru, to ne znači da je softver spreman za isporuku. Jesu li izvedeni testovi zaista osmišljeni kako bi uhvatili najviše nedostataka? ili gdje su dizajnirali kako bi vidjeli odgovara li softver korisnikovim zahtjevima? Prije donošenja odluke o isporuci softvera treba razmotriti mnogo drugih čimbenika.

Što je ispitivanje bijele kutije

Testiranje bijele kutije bavi se unutarnjom logikom i strukturom koda. Ispitivanje bijele kutije naziva se i ispitivanje stakla, konstrukcije, otvorene kutije ili prozirne kutije. Testovi napisani na temelju strategije testiranja bijelog okvira uključuju pokrivanje napisanog koda, grane, staze, izjave i unutarnju logiku koda itd.

Da bi proveo testiranje bijele kutije, ispitivač se mora nositi s kodom i stoga je potreban da bi posjedovao znanje o kodiranju i logici, tj. Internom radu koda. Test bijele kutije također treba ispitivač da pogleda kod i utvrdi koja jedinica / iskaz / dio koda ne radi ispravno.

Jedinstveno ispitivanje

Programer provodi jedinstveno testiranje kako bi provjerio radi li određeni modul ili jedinica koda u redu. Jedinstveno testiranje dolazi na vrlo osnovnoj razini jer se provodi kad i kada se razvije jedinica koda ili kada se izgradi određena funkcionalnost.

Statička i dinamička analiza

Statička analiza uključuje prolazak kroz kôd kako bi se otkrila moguća pogreška u kodu. Dinamička analiza uključuje izvršavanje koda i analizu rezultata.

Obuhvat izvještaja

U ovoj vrsti testiranja kôd se izvršava na takav način da se svaka izjava aplikacije izvrši barem jednom. Pomaže u osiguranju da se sve izjave izvršavaju bez ikakvih nuspojava.

Pokrivenost podružnice

Nijedna softverska aplikacija ne može se pisati u kontinuiranom načinu kodiranja, u nekom trenutku moramo razgranati kôd kako bismo izvršili određenu funkcionalnost. Testiranje pokrivenosti grana pomaže u provjeri valjanosti svih grana u kodu i osigurava da nikakvo grananje dovodi do abnormalnog ponašanja aplikacije.

Ispitivanje sigurnosti

Ispitivanje sigurnosti provodi se kako bi se utvrdilo koliko se dobro sustav može zaštititi od neovlaštenog pristupa, hakiranja, pucanja, oštećenja koda itd. Koji se bavi kodom aplikacije. Za ovu vrstu testiranja potrebne su sofisticirane tehnike ispitivanja.

Ispitivanje mutacija

Vrsta testiranja u kojem se aplikacija testira na kôd koji je modificiran nakon ispravljanja određene pogreške / kvara. Također pomaže u otkrivanju koji kod i koja strategija kodiranja mogu pomoći u učinkovitom razvoju funkcionalnosti.

Prednosti testiranja bijele kutije

Kako je poznavanje unutarnje strukture kodiranja preduvjet, postaje vrlo lako otkriti koja vrsta unosa / podataka može pomoći u učinkovitom testiranju aplikacije. Druga prednost testiranja bijele kutije je što pomaže u optimizaciji koda Pomaže u uklanjanju dodatnih redaka koda, što može dovesti do skrivenih nedostataka.

Mane testiranja bijele kutije

Kako je poznavanje koda i unutarnje strukture preduvjet, za provođenje ove vrste ispitivanja potreban je vješt ispitivač, što povećava troškove. Gotovo je nemoguće proučiti svaki djelić koda kako bi se otkrile skrivene pogreške, što može stvoriti probleme, što rezultira neuspjehom aplikacije.

Što je ispitivanje crne kutije

U testiranju crne kutije, ispitivač testira aplikaciju bez znanja o unutarnjem radu aplikacije koja se testira.

Budući da se ispitivanje crne kutije ne odnosi na temeljni kôd, tada se tehnike mogu izvesti iz dokumentacije zahtjeva ili projektnih specifikacija, a time i ispitivanje može započeti čim se zahtjevi napišu.

Tehnika ispitivanja granične vrijednosti

Analiza granične vrijednosti, BVA, ispituje ponašanje programa na granicama. Prilikom provjere raspona vrijednosti, nakon odabira skupa podataka koji leže u važećim particijama, slijedi provjera ponašanja programa na graničnim vrijednostima važećih particija. Analiza granične vrijednosti najčešća je kada se provjerava raspon brojeva.

Državna prijelazna tehnika

Tehnika ispitivanja prijelaza stanja koristi se tamo gdje se neki aspekt sustava može opisati u onome što se naziva „stroj konačnog stanja“. To jednostavno znači da sustav može biti u (konačnom) broju različitih stanja, a prijelazi iz jednog stanja u drugo određeni su pravilima 'stroja'.

Ovo je model na kojem se temelje sustav i testovi. Bilo koji sustav u kojem za isti ulaz dobivate drugačiji izlaz, ovisno o tome što se prije dogodilo, sustav je konačnog stanja.

Tehnika testa podjele ekvivalentnosti

Ideja tehnike ispitivanja particioniranja ekvivalencije je eliminirati skup ulaznih podataka koji čine da se sustav ponaša jednako i daje isti rezultat prilikom testiranja programa.

Proces tehnike ekvivalentne particije uključuje identificiranje skupa podataka kao ulaznog uvjeta koji daju isti rezultat prilikom izvršavanja programa i klasificiranje ih kao skupa ekvivalentnih podataka (jer oni čine da se program ponaša na isti način i generira isti izlaz ) i razdvajanje ih iz drugog ekvivalentnog skupa podataka.

Prednosti ispitivanja crnih kutija

  • Test je nepristran jer su dizajner i ispitivač neovisni jedni od drugih.
  • Ispitivaču nije potrebno znanje bilo kojeg određenog programskog jezika.
  • Test se provodi sa stajališta korisnika, a ne dizajnera.
  • Test slučajevi mogu se dizajnirati čim se dovrše specifikacije.

Mane ispitivanja crne kutije

  • Test može biti suvišan ako je dizajner softvera već pokrenuo testni slučaj.
  • Test slučajeve je teško dizajnirati.
  • Testiranje svakog mogućeg ulaznog toka je nerealno jer bi trajalo izvanredno puno vremena; stoga će mnogi programski putovi biti neprovjereni.