Meni

Ključ uspješnog jediničnog testiranja - kako programeri testiraju vlastiti kôd?

key successful unit testing how developers test their own code

Isprobajte Naš Instrument Za Uklanjanje Problema

Black Box testeri ne brinu za jedinstveno testiranje. Njihov je glavni cilj potvrditi prijavu prema zahtjevima bez ulaska u detalje provedbe.

Ali kao zanimljivost odn Izvan okvira razmišljanja , jeste li se ikad zapitali kako programeri testiraju svoj kôd? Koju metodu koriste za testiranje prije puštanja koda na testiranje? Koliko je razvojno testiranje važno u agilnom procesu? Odgovor na sve ovo je Jedinstveno testiranje. Želim vas educirati o važnosti jedinstvenog testiranja kako bi timovi za razvoj i testiranje mogli zajednički raditi na dizajniranju, testiranju i objavljivanju izvrsne aplikacije.

Tko zna da će se u budućnosti neki od vas možda čak i prebaciti na testiranje bijelih kutija i koristiti ove tehnike provjere valjanosti i poboljšanja koda!

Jedinstveno ispitivanje

Što ćete naučiti:

Što je jedinstveno testiranje?

Jedinstveno testiranje nije novi koncept. Tamo je od ranih dana programiranja. Obično programeri i ponekad Ispitivači bijele kutije napisati Unit testove za poboljšanje kvalitete koda provjerom svake jedinice koda koja se koristi za implementaciju funkcionalnih zahtjeva (aka test-driven razvoj TDD ili test-first development).

Većina nas možda zna klasičnu definiciju -
'Jedinstveno testiranje metoda je provjere najmanjeg dijela provjerljivog koda u odnosu na njegovu svrhu.' Ako svrha ili zahtjev nisu uspjeli, tada jedinično ispitivanje nije uspjelo.

Jednostavnim riječima, to znači - pisanje dijela koda (jedinični test) za provjeru koda (jedinice) napisanog za provedbu zahtjeva.

Jedinstveno testiranje u SDLC-u

Jedinstveno testiranje u SDLC

U jedinstvenom testiranju, programeri koriste ručne ili automatizirane testove kako bi osigurali da svaka jedinica u softveru udovoljava zahtjevima kupca. Ova jedinica može biti pojedinačna funkcija, objekt, metoda, postupak ili modul u testiranom softveru.

Pisanje jedinstvenih testova za testiranje pojedinih jedinica olakšava pisanje sveobuhvatnih testova jer su sve jedinice sastavljene. Tijekom razvoja softvera to se radi kao prva razina testiranja.

Važnost pisanja jediničnih testova

Jedinstveno testiranje koristi se za dizajn robusnih softverskih komponenata koje pomažu u održavanju koda i uklanjanju problema u kodnim jedinicama. Svi znamo važnost pronalaženja i otklanjanja nedostataka u ranoj fazi ciklusa razvoja softvera. Ovo ispitivanje ima istu svrhu.

Sastavni je dio agilnog procesa razvoja softvera. Kada bi se trebao pokrenuti paket za testiranje jedinica za izradu svake noći i trebalo bi generirati izvještaj. Ako bilo koji od jediničnih testova nije uspio, QA tim ne bi trebao prihvatiti tu verziju za provjeru.

Ako ovo postavimo kao standardni postupak, mnogi bi se nedostaci uhvatili u ranom razvojnom ciklusu, štedeći puno vremena za testiranje.

Znam da mnogi programeri mrze pisati unit testove. Ili ignoriraju ili pišu loše jedinice testnih slučajeva zbog čvrstog rasporeda ili nedostatka ozbiljnosti (da, pišu prazne unit testove, pa ih 100% uspješno položi ;-)). Važno je napisati dobre jedinične testove ili ih uopće ne pisati. Još je važnije pružiti dovoljno vremena i podržavajuće okruženje za stvarne koristi.

Jedinstvene metode ispitivanja

Može se izvesti na 2 načina:

  1. Ručno ispitivanje
  2. Automatizirano ispitivanje

U Ručno ispitivanje , ispitivač ručno izvršava test slučajeve bez upotrebe bilo kakvog alata za automatizaciju. Ovdje se svaka faza testa izvršava ručno. Ručno testiranje je zamorno, posebno za testove koji se ponavljaju i zahtijeva više napora za stvaranje i izvršavanje test slučajeva. Ručno testiranje ne zahtijeva poznavanje bilo kojeg alata za testiranje.

Činjenica je da 100% automatizacije nije moguće i stoga će uvijek postojati određena razina ručnog ispitivanja.

U Automatsko testiranje, softverski alati za automatizaciju testiranja koriste se za automatizaciju testova / test slučajeva. Alat za automatizaciju može snimiti i spremiti vaš test i može se reproducirati onoliko puta koliko je potrebno bez daljnje ljudske intervencije.

Ovi alati mogu čak unijeti podatke o testiranju u sustav koji se testira, kao i usporediti očekivane rezultate sa stvarnim rezultatima i automatski generirati izvješća. Međutim, početni troškovi postavljanja alata za automatizaciju ispitivanja visoki su.

Tehnike unutar jedinstvenog ispitivanja

# 1) Testiranje bijele kutije:

pitanja za intervju za oracle pl sql za 8 godina iskustva

Tijekom testiranja bijele kutije, ispitivač poznaje unutarnju strukturu softvera, uključujući kôd, i može ga testirati u odnosu na dizajn i zahtjeve. Stoga je ispitivanje bijele kutije također poznato kao transparentno ispitivanje .

ispitivanje bijele kutije

# 2) Testiranje crne kutije:

U testiranju crne kutije, ispitivač ne poznaje unutarnje strukture niti kôd softvera.

ispitivanje crne kutije

# 3) Testiranje sive kutije:

To se također naziva i ispitivanje poluprozirne tehnike što znači, testeri su samo djelomično svjesni unutarnje strukture, funkcija i dizajna zajedno sa zahtjevima. Otklanjanje pogrešaka vrši se stvarnim unosom s prednjeg dijela kako bi se dobili precizni podaci u pozadini. Stoga se siva kutija smatra kombinacijom tehnika ispitivanja crne kutije i bijele kutije.

Ispitivanje sive kutije

Testiranje sive kutije obuhvaća sljedeće vrste ispitivanja:

  • Ispitivanje matrice.
  • Ispitivanje uzoraka.
  • Ispitivanje pravokutnog uzorka.
  • Ispitivanje regresije.

Prednosti jediničnog ispitivanja

  1. Proces postaje okretan: Za dodavanje novih funkcija ili značajki postojećem softveru moramo izmijeniti stari kod. Ali promjena stvari na već testirani kôd može biti i rizična, ali i skupa.
  2. Kvaliteta koda se poboljšava: Kvaliteta koda se automatski poboljšava kada se izvrši jedinstveno testiranje. Greške identificirane tijekom ovog testiranja ispravljene su prije slanja u fazu integracijskog testiranja. Rezultat je robustan dizajn i razvoj dok programeri pišu test slučajeve tako što će prvo razumjeti specifikacije.
  3. Rano otkriva bugove: Dok programeri pokreću jedinične testove, otkrivaju pogreške na početku životnog ciklusa razvoja softvera i rješavaju ih. To uključuje nedostatke ili nedostajuće dijelove u specifikaciji, kao i greške u implementaciji programera.
  4. Lakše promjene i pojednostavljene integracije: Izvođenjem jedinstvenog testiranja programeru je lako restrukturirati kôd, unijeti promjene i održavati kôd. Također olakšava testiranje koda nakon integracije. Rješavanje problema u jedinstvenom testiranju može riješiti mnoge druge probleme koji se javljaju u kasnijim fazama razvoja i testiranja
  5. Dostupnost dokumentacije: Programeri koji kasnije istražuju funkcionalnost mogu se obratiti dokumentaciji za testiranje jedinice i lako mogu pronaći sučelje za testiranje jedinice te ispraviti ili brzo i jednostavno raditi.
  6. Jednostavan postupak uklanjanja pogrešaka: Pomaže u pojednostavljenju postupka uklanjanja pogrešaka. Ako test ne uspije u bilo kojoj fazi, kod se mora ispraviti ili se postupak može nastaviti bez ikakvih prepreka.
  7. Niža cijena: Kad se tijekom jedinstvenog testiranja otkriju i riješe programske pogreške, smanjuju se troškovi i vrijeme razvoja. Bez ovog testiranja, ako se iste programske pogreške otkriju u kasnijoj fazi nakon integracije koda, postaje teže pronaći i riješiti ih, što skuplje čini i povećava vrijeme razvoja.
  8. Kompletnost koda može se pokazati pomoću jediničnih testova: Ovo je korisnije u agilnom procesu. Ispitivači ne dobivaju funkcionalne verzije za testiranje dok se integracija ne dovrši. Popunjavanje koda ne može se opravdati pokazivanjem da ste upisali i prijavili kôd. Ali pokretanje Unit testova može pokazati kompletnost koda.
  9. Štedi vrijeme za razvoj: Dovršenje koda može potrajati više vremena, ali zbog manje grešaka u testiranju sustava i prihvaćanja može se uštedjeti ukupno vrijeme razvoja.
  10. Pokrivenost kodom može se izmjeriti

Jedinstveni ciklus ispitivanja

Jedinstveni ciklus ispitivanja

(slika izvor )

Što čini dobar jedinični test?

Pa, nisam prava osoba koja može reći što čini dobar Unit Test, ali na temelju mojih zapažanja na raznim projektima mogu reći karakteristike dobrog Unit Test-a. Loš Unit Test ne dodaje vrijednost projektu. Umjesto toga, trošak projekta značajno se povećava pisanjem i upravljanjem lošim jediničnim testovima.

Kako napisati dobre jedinične testove?

  • Treba napisati Unit test kako bi se potvrdila pojedinačna jedinica koda, a ne integracija.
  • Mali i izolirani Unit testovi s jasnim imenovanjem olakšali bi pisanje i održavanje.
  • Promjena drugog dijela softvera ne bi trebala utjecati na Unit test ako su oni izolirani i napisani za određenu jedinicu koda.
  • Trebao bi brzo trčati
  • Jedinstveni test trebao bi se ponovno koristiti

Okviri jediničnog ispitivanja

Okviri za jedinično testiranje uglavnom se koriste za brzo i jednostavno pisanje jediničnih testova. Većina programskih jezika ne podržava jedinično testiranje s ugrađenim kompajlerom. Neovisni i komercijalni alati mogu se koristiti kako bi jedinstveno testiranje učinili još zabavnijim.

Popis popularnih Alati za jedinstveno ispitivanje za različite programske jezike:

  1. Java framework - JUNIT
  2. PHP okvir - PHPUnit
  3. C ++ okviri - UnitTest ++ i Google C ++
  4. .NET framework - NUnit
  5. Python okvir - py.test

Zablude i istine

  • Potrebno je više vremena za pisanje koda s Unit test slučajevima, a mi za to nemamo vremena - u stvarnosti to bi dugoročno uštedjelo vaše vrijeme za razvoj.
  • Jedinstveno testiranje pronaći će sve programske pogreške - Neće, jer namjera Unit testova nije pronaći programske pogreške, već razviti robusne softverske komponente koje će imati manje nedostataka u kasnijim fazama SDLC-a.
  • 100% pokrivenost koda znači 100% pokrivenost testom - To ne jamči da je kod bez pogrešaka.

Kako prihvatiti jedinstveno testiranje?

Dobro jedinstveno testiranje može se provesti u 3 osnovna dijela.

  1. Napiši kod jedinice za testiranje
  2. Pokrenite kod za testiranje jedinice kako biste provjerili ispunjava li sistemski zahtjev
  3. Izvršite softverski kod za testiranje na nedostatke i ispunjava li kôd sistemski zahtjev.

Nakon poduzimanja gornja 3 koraka, ako se čini da je kôd točan, tada se kaže da je položeno jedinstveno ispitivanje. A ako ne udovoljava zahtjevima sustava, test ne uspije. U tom slučaju, programer mora ponovno provjeriti i ispraviti kôd.

U nekim je slučajevima potrebno odvojiti kôd za preciznije provođenje ovog testiranja.

Najbolja vježba

Da biste stvorili najbolji kôd tijekom ovog testiranja, uzmite u obzir sljedeće točke:

  • Kôd bi trebao biti jak: Postoje slučajevi kada test ne uspije ili se u najgorim slučajevima uopće ne izvrši ako je kôd slomljen.
  • Razumljivo i razumno: Kôd bi trebao biti lako razumljiv. To programeru olakšava pisanje koda, pa će čak i drugim programerima koji će naknadno raditi na kodu biti lako otkloniti pogreške.
  • Treba biti pojedinačni slučaj: Testovi koji definiraju više slučajeva u jednom složeni su za rad. Stoga je pisanje koda jednog slučaja najbolja praksa, što olakšava razumijevanje i uklanjanje pogrešaka.
  • Dopusti automatizirane testove: Programeri bi se trebali pobrinuti da test radi u automatiziranom obliku. Trebao bi biti u kontinuiranom procesu isporuke ili integraciji.

Ostale točke koje treba imati na umu su sljedeće:

  • Umjesto stvaranja testnih slučajeva za sve uvjete, usredotočite se na test koji utječe na ponašanje sustava.
  • Postoje šanse za ponovnu pojavu programske pogreške zbog predmemorije preglednika.
  • Test slučajevi ne smiju biti međusobno ovisni.
  • Obratite pažnju i na stanje petlje.
  • Češće planirajte test slučajeve.

Zaključak

Jedinstveno testiranje dolazi na vidjelo kada je potrebno testirati svaku funkciju zasebno. Puno je razumno otkriti i ispraviti pogreške tijekom ovog testiranja i uštedjeti vrijeme i troškove, umjesto da ih nalazimo u kasnijoj fazi razvoja softvera.

Iako nudi brojne prednosti, postoje i ograničenja vezana uz njegovo korištenje. Tijekom postupka razvoja softvera potrebna je stroga disciplina i dosljednost prevladati ograničenja i ostvariti predviđene koristi.

Vaši komentari su najpoželjniji!
Kao tester crne kutije, kakva su vaša zapažanja o jedinstvenom testiranju u vašem timu? Ima li netko bolju ideju za uspješno jedinično testiranje?

Preporučena literatura

^