Kada radite na testiranju softvera, potrebno je razmotriti desetke različitih metoda testiranja.
Testiranje softvera pomaže programerima da uklone sve nedostatke koji bi mogli postojati u softverskom paketu kako bi mogli isporučiti proizvod koji ispunjava potrebe i očekivanja svih dionika. Korištenje pravog rješenja za testiranje pruža vam svo potrebno znanje, ali ispravno odabiranje testa može potrajati.
Testiranje u sivoj kutiji jedan je od svestranijih oblika testiranja dostupnih testerima, koji nudi obilje uvida bez pretjeranog zauzimanja resursa.
Saznajte više o tome što je testiranje u sivoj kutiji, neke od specifičnosti funkcioniranja testiranja u sivoj kutiji i neke od razloga zašto tvrtke koriste ovu metodu testiranja.
Što je Grey box testiranje?
Testiranje sive kutije je oblik testiranja koji kombinira testiranje bijele kutije i testiranje crne kutije, koristeći djelomično razumijevanje temeljnog dizajna i načina na koji je sustav implementiran.
Ova kombinacija znači da ispitivač zna dio onoga što se događa u pozadini bez potpunog poznavanja koda, što pruža bolji uvid u moguće uzroke problema u softveru kada se pojave.
Završetak testiranja u sivoj kutiji odgovornost je testera, s timom za osiguranje kvalitete koji radi neovisno o razvojnom timu na projektu.
1. Kada i zašto trebate raditi testiranje u sivoj kutiji u testiranju softvera?
Nekoliko puta tvrtke koriste testiranje u sivoj kutiji u procesu razvoja.
Na primjer, kada aplikacija treba komunicirati s alatom treće strane da bi ispravno radila, testeri nemaju pristup izvornom kodu koji je dio vanjskog softvera. Ovo je prisilno ograničenje pristupa QA testera i čini testiranje sivim okvirom bez izbora.
2. Kada ne morate raditi testiranje u sivoj kutiji
Postoji nekoliko puta u procesu testiranja kada testiranje sive kutije nije potrebno, od kojih je prvi rani razvojni proces.
Funkcionalno testiranje odvija se kada programeri inicijalno testiraju kako bi bili sigurni da njihov kod ispunjava svoje osnovne zadatke, što je potpuno transparentno. Budući da nema koda ili dokumentacije skrivene od ispitivača, ovo se ne smatra testiranjem u sivoj kutiji.
Drugi put kada ne trebate testiranje u sivoj kutiji je kada testirate na samom kraju razvoja kada imate kompletan proizvod. To je slučaj kada dobijete pomoć krajnjeg korisnika s testiranjem, a poznato je i kao “beta testiranje” ili ” sveobuhvatno testiranje “.
Korisnici testiraju aplikaciju bez ikakvog pristupa kodu ili dizajnerskim dokumentima, umjesto da uzimaju softver sam po sebi. Ovo je oblik testiranja crne kutije jer je postupak potpuno neproziran.
3. Tko je uključen u Grey Box testiranje?
Postoji nekoliko osoba i uloga koje sudjeluju u testiranju sive kutije, a neke od najvažnijih uloga u procesu uključuju:
· QA Manager:
QA manager, ili manager za osiguranje kvalitete, član je osoblja u procesu razvoja softvera koji je odgovoran za dodjelu zadataka timu za testiranje.
To uključuje stvaranje rotacija, ispitivanje izvješća i rješavanje sukoba koji se javljaju u timu.
· Tester:
Tester je profesionalac odgovoran za dovršavanje testnih slučajeva koji su dio procesa testiranja u sivoj kutiji.
Ovo zahtijeva visoku razinu pozornosti na detalje prilikom pisanja izvješća i stalnog prolaska kroz precizne testne slučajeve.
· Programer:
Programeri su profesionalci odgovorni za kreiranje koda i njegovu prilagodbu ovisno o rezultatima testiranja u sivoj kutiji.
Iako oni nisu nužno uključeni u samo testiranje, primaju komunikaciju od ispitivača o rezultatima.
· QA analitičar:
Uloga QA analitičara uobičajena je u procesima testiranja koji koriste puno automatizacije. Analitičar piše kod testnog slučaja za automatske testove uz analizu podataka koje testovi vraćaju na kraju procesa.
Prednosti testiranja u sivoj kutiji
Postoji nekoliko glavnih prednosti korištenja testiranja u sivoj kutiji pri ispitivanju softvera. Iskorištavanjem ovih prednosti na najbolji način poboljšavate standard svoje aplikacije tijekom vremena.
Neki od razloga zašto tvrtke koriste ovaj oblik testiranja uključuju:
1. Poznavanje unutarnjih mehanizama pomaže u osmišljavanju testova
Jedna od glavnih prednosti korištenja testiranja u sivoj kutiji na radnom mjestu je činjenica da znate o nekim internim mehanizmima u aplikaciji. To uključuje razumijevanje što svaka od funkcija radi i koji su gotovi moduli u usporedbi s prilagođeno napisanim kodom za neke druge značajke.
Poznavanje unutarnje funkcionalnosti znači da tester bolje razumije što testira i može usmjeriti te testove na dizajn aplikacije. Tvrtke dobivaju preciznije rezultate koji ispravno predstavljaju softver.
2. Dovodi do trenutačnog rješavanja problema
U nekim slučajevima, kada se u testu pojavi problem i ispitivač ima pristup kodu iza problema, može postojati trenutačno rješenje problema.
To je u suprotnosti s metodologijom testiranja crne kutije, u kojoj ispitivači ne mogu vidjeti ništa od koda iza kulisa softvera koji ispituju. Vidjevši kod, testeri s puno iskustva u razvoju mogu uputiti programere na točno u čemu je problem i kako ga buduće ažuriranje može riješiti.
Testiranje u sivoj kutiji štedi puno vremena koje bi se inače potrošilo na istraživanje problema i pomaže tvrtkama da svoje vrijeme troše učinkovitije.
3. Odvaja testere i programere
Korištenje testiranja u sivoj kutiji ostavlja jasnu razliku između programera aplikacije i ljudi koji testiraju softver.
To je zato što se dovršavanje testiranja u sivoj kutiji oslanja na testere koji nemaju postojeće znanje o načinu na koji softver radi, a udaljenost između ta dva postaje nužna za točnije rezultate testa na koje ne utječe pristranost.
Testeri u scenarijima sive kutije u potpuno su različitom timu od programera, nudeći točne informacije bez da postojeći pogledi utječu na njihov rezultat.
Programeri također imaju koristi od ovoga jer dobivaju kritičniju perspektivu svog rada, što im pomaže da poboljšaju i postojeću aplikaciju i svoje vještine za budućnost.
Izazovi Grey Box testiranja
Postoji nekoliko velikih nedostataka korištenja testiranja u sivoj kutiji u vašem razvoju.
Razumijevanjem ovih nedostataka i radom na njihovom ublažavanju gdje god je to moguće, povećavate opći standard svog rada na kraju faze osiguranja kvalitete .
Neki od glavnih nedostataka testiranja u sivoj kutiji uključuju:
1. Mogućnost nevidljivosti koda
Testiranje u sivoj kutiji znači da postoje neki aspekti koda koji su skriveni od ispitivača, a u slučaju bilo kakvih problema koji se pojave u testu to može dovesti do daljnjih problema.
S nevidljivim kodom, članovi osoblja koji su uključeni u testiranje bore se s usmjeravanjem svojih testova kako bi maksimalno iskoristili aplikaciju i gube korist od trenutnog uviđanja uzroka problema.
Proces ispravljanja bugova postaje nejasniji, što dovodi do toga da duža vremena ažuriranja postaju nužnost, a tvrtke se bore da pronađu probleme u svom kodu.
Krajnji proizvodi mogu imati više grešaka i nižeg standarda kao rezultat ovog nevidljivog koda.
2. Testovi mogu biti netočni ako operacije ne uspiju
Imati točne testove neophodno je u bilo kojem obliku testiranja softvera, s višim stupnjem točnosti koji usmjerava timove prema ažuriranjima koja mogu izvršiti u budućim verzijama, uz pomoć razvojnom timu da bude sigurniji u svoje proizvode.
Ta se točnost smanjuje kada operacije ne uspiju u testiranju sive kutije. Testeri jednostavno primaju poruku “Operacija nije uspjela” od softvera ako nemaju pristup kodu, sprječavajući ih da daju povratne informacije o načinu na koji on radi.
Kako bi dobili korisne metrike, programeri moraju zakrpati softver prije sljedeće faze testiranja. U suprotnom, sve što tester može učiniti je izjaviti da značajka ne radi u svom trenutnom obliku.
3. Borbe s distribuiranim sustavima
Distribuirani sustavi odnose se na softverske sustave koji se nalaze na nekoliko različitih mjesta ili se oslanjaju na značajke kao što su podaci i usluge obrade smješteni u oblaku.
To čini testiranje izuzetno teškim, jer postoji značajan udio softvera koji je skriven iza tijela treće strane, a testeri jednostavno primaju izlaz od nepoznatog procesa.
Kada se pojave problemi sa softverom koji koristi sustave treće strane, može biti teško utvrditi je li problem u samoj aplikaciji, funkcionalnosti treće strane ili načinu na koji se to dvoje integrira, osobito kada tester može ne vidim kod kako radi.
Karakteristike Grey Box testova
Postoji nekoliko karakteristika koje testovi sive kutije dijele jedan s drugim, a prepoznavanje ovih testova pomaže vam da pripremite strategiju za svoju organizaciju.
Neki od glavnih primjera karakteristika testa sive kutije, uz to kako su te karakteristike važni dijelovi procesa testiranja sive kutije, uključuju:
· Povećana pokrivenost:
Pristup nekim izvornim kodovima pruža veći stupanj pokrivenosti u testovima, s dodatnim detaljima koji nude točnije pronalaženje grešaka.
· Tokovi podataka:
Mnogi testovi sive kutije naglašavaju protok podataka i razumijevanje načina na koji se informacije kreću kroz sustav.
· Nealgoritamski:
Testiranje sive kutije ne funkcionira pri ispitivanju algoritama jer je to još jedna razina zamagljivanja koda.
Što testiramo u testovima sive kutije?
Svaka različita vrsta testiranja najbolje je poslužiti kada ciljate na određene dijelove dotičnog softvera. Isto se odnosi i na testiranje sivog okvira, pri čemu je metodologija najkorisnija u nekim posebnim dijelovima aplikacije.
Neki primjeri onoga što ispitivači procjenjuju kada ispunjavaju testove sivog okvira uključuju:
1. Sigurnost aplikacije
Testovi sive kutije idealni su za testove prodora koji ispituju sigurnost aplikacije. Testeri mogu vidjeti sav kod i tražiti potencijalne ranjivosti u procesu.
Etički hakeri idealni su testeri za testiranje sigurnosti aplikacija, budući da prirodnije prepoznaju potencijalne slabosti i nedostatke u softveru od onih koji nemaju iskustva s probijanjem sigurnosti softvera.
2. Testiranje baze podataka
Mnoge tvrtke koriste testiranje sivih okvira za testiranje baze podataka jer možete pratiti podatke kroz svaku podfunkciju u softveru.
Testeri mogu vidjeti sve promjene koje softver napravi i procijeniti jesu li one točne.
Ovo je korisna implementacija testiranja sive kutije budući da su testovi baza podataka po svojoj prirodi predvidljivi, a tvrtke koriste baze podataka za organiziranje postojećih informacija, a ne za generiranje novih podataka.
3. Web aplikacije
Web aplikacije imaju koristi od upotrebe testiranja u sivoj kutiji zbog svestranosti metode testiranja.
Testovi sive kutije mogu se koristiti za testiranje sigurnosti, baze podataka, integracije , korisničkog sučelja i preglednika, od kojih je svaki ključni aspekt web aplikacija .
Nema potrebe mijenjati metodologije testiranja na pola puta, tako da imate koristi od veće razine kontinuiteta.
Razjašnjavanje zabune:
Testiranje sive kutije protiv bijele kutije protiv crne kutije
Testiranje sive kutije oblik je testiranja sličan testiranju bijele kutije i testiranja crne kutije, što znači da postoji velika mogućnost zabune između metodologija.
Saznajte više o tome što je testiranje bijele i crne kutije i neke od temeljnih razlika između njih i testiranja sive kutije u razvoju softvera:
1. Što je testiranje bijele kutije?
Testiranje bijele kutije oblik je testiranja aplikacije koji ispitivaču pruža sveobuhvatne informacije o aplikaciji.
To uključuje potpuni pristup izvornom kodu i svim projektnim dokumentima softvera, što testeru omogućuje puno bolje razumijevanje načina na koji softver radi.
Testeri koriste ovo razumijevanje kako bi vidjeli više problema koji su prisutni u aplikaciji, dajući točniju perspektivu o tome kako aplikacija radi za korisnike.
Primjer korištenja testiranja bijele kutije je vidjeti tok unosa određenih podataka kroz aplikaciju kako bi se vidjelo gdje se problem pojavljuje u procesima aplikacije, umjesto da se jednostavno vidi postoji li problem ili ne.
Nekoliko puta u razvojnim procesima tvrtke koriste testiranje bijele kutije.
Prvi od njih je dovršavanje jediničnog testiranja , kojim se procjenjuje obavlja li svaki pojedinačni dio koda ili modula u softverskom paketu posao koji programer očekuje.
Jedinično testiranje pomaže testerima da pronađu većinu problema u aplikaciji jer ispituje sve funkcije u aplikaciji.
Testiranje bijele kutije također pomaže pri pronalaženju curenja memorije. Detaljnim ispitivanjem cijelog koda QA analitičar otkriva gdje aplikacija koristi memoriju uređaja i potencijalna područja gdje koristi previše.
To pomaže da aplikacija radi brže i učinkovitije u budućim iteracijama jer curenje memorije dobije zakrpu što je prije moguće.
Koje su razlike između testova sive i bijele kutije?
Postoji nekoliko velikih razlika između testova bijele i sive kutije, pri čemu je prva promjena razina informacija kojima netko ima pristup.
Testiranje u bijeloj kutiji ima puni pristup izvornom kodu i dokumentima dizajna za program, dok testiranje u sivoj kutiji ima samo djelomičan pristup nekim od ovih informacija, prvenstveno dokumentima dizajna.
Ova promjena znači da također postoji razlika u ljudima koji ispunjavaju testove, pri čemu su sami programeri prvenstveno odgovorni za testiranje bijele kutije.
Za razliku od toga, testiranje u sivoj kutiji odgovornost je QA tima, budući da ispitivači ne mogu imati intimno znanje o kodu.
Testiranje sive kutije također traje kraće od testiranja bijele kutije. Testiranje bijele kutije je end-to-end i ispituje i korisničku stranu softvera i sam kod. Za to je potrebno puno više vremena da se dovrši i znači da je proces testiranja sivog okvira puno brži put naprijed.
Međutim, bijela kutija ima više potencijala za automatizaciju jer testeri znaju način na koji funkcionira interni kod.
2. Što je testiranje crne kutije?
Testiranje crne kutije odnosi se na slučaj kada tester ispituje softverski paket bez ikakvog razumijevanja načina na koji sustav funkcionira.
To znači da nemate pristup nijednom kodu koji je dio aplikacije ili bilo kojem dizajnerskom dokumentu ili sažetku koji je dostupan. Testeri jednostavno imaju popis značajki koje testiraju i niz testnih slučajeva koje moraju dovršiti.
Primjer testiranja crne kutije je end-to-end testiranje, u kojem ispitivač prima kompletan softverski paket i testira cijelu aplikaciju kako bi se uvjerio da funkcionalnost radi onako kako je dizajnirana.
Većina idealnih testnih slučajeva za testiranje crne kutije su oni pri kraju procesa i uključuju klijente i njihovu perspektivu o proizvodu, s nedostatkom pristupa kodu koji sprječava bilo kakvu pristranost koja utječe na pogled korisnika.
Tvrtke koriste testiranje crne kutije prvenstveno nakon što su sva testiranja funkcija na aplikaciji dovršena. S dovršenim jediničnim testiranjem i testiranjem funkcija, programeri shvaćaju da aplikacija radi kako očekuju, barem sa svim modulima koji rade izolirano.
Testiranje crne kutije osigurava da cjelokupna aplikacija radi kako se očekuje nakon kompajliranja, pri čemu je sav izvorni kod teoretski već u redu.
Koje su razlike između testiranja sive i crne kutije?
Glavna razlika između testiranja sive kutije i testiranja crne kutije je količina pristupa informacijama koju ispitivač ima.
U nekim slučajevima, tester crne kutije može pristupiti aplikaciji bez ikakvog prethodnog znanja o softveru, jednostavno prolazeći kroz proces testiranja i koristeći softver kao što to čini standardni korisnik.
S druge strane, tester u sivoj kutiji ima pristup nekim od dizajnerskih dokumenata i tako može usporediti ono za što je aplikacija namijenjena s njezinom stvarnom izvedbom, pružajući razvojnim programerima povratne informacije o tome koji određeni dijelovi aplikacije nisu u skladu sa standardima.
Još jedna razlika je količina vremena koja je potrebna za rješavanje problema, pri čemu testovi sive kutije oduzimaju malo više vremena.
Uspoređivanje dokumentacije i koda s načinom na koji doživljavate aplikaciju može potrajati, što je u suprotnosti s načinom na koji testeri crne kutije rade jednostavnim ispitivanjem same aplikacije zajedno s problemima s funkcionalnošću. Ova kombinacija čini testiranje crne kutije idealnim postupkom za korištenje odmah na kraju razvojnog procesa kada se pripremate za izdavanje proizvoda, a siva kutija radi bolje kada ste u fazi razvoja korisničkog sučelja i kompajliranja.
3. Zaključak: testiranje sive kutije nasuprot bijele kutije nasuprot crne kutije
Zaključno, testiranje bijele kutije, sive kutije i crne kutije dio je istog spektra, u kojem je različit faktor razina pristupa koju ispitivač ima tijekom cijelog procesa.
Kako obrazac za testiranje postaje sve “crniji”, testiranje je sve neprozirnije, a pristup informacijama iza softvera je ograničen.
Testiranje bijele kutije idealno je za najranije faze procesa, dok je testiranje crne kutije izvrsno za faze kao što je testiranje od kraja do kraja koje ispituje cijelu aplikaciju iz perspektive korisnika.
Testiranje u sivoj kutiji djeluje kao sredina između dva koncepta, pomažući u pronalaženju problema tijekom sredine razvojnog procesa nudeći bolji uvid dok dio izvornog koda i dalje ostaje skriven od ispitivača.
Tehnike testiranja sive kutije
Testiranje u sivoj kutiji uključuje širok raspon tehnika, od kojih svaka povećava standard testiranja, pronalazi više grešaka za programera i dovodi do potpunijeg proizvoda na kraju procesa.
Neke od najčešćih tehnika testiranja sive kutije koje QA timovi koriste uključuju:
1. Testiranje matrice
Matrix testiranje ispituje statusno izvješće projekta koji je u tijeku. To uključuje jednostavno PASS/FAIL stanje u nekim slučajevima, s tekućim procesima koji pružaju više pojedinosti o tome kako procesi kontinuirano rade.
Dok se većina testiranja fokusira na ulaze i izlaze dijela koda, matrično testiranje ispituje status samih procesa, a ne rezultate navedenih procesa.
Korištenje matričnog testiranja daje veći fokus na samu aplikaciju, pomaže u pronalaženju grešaka i problema čak i ako se rezultati čine točnima.
2. Regresijsko testiranje
Regresijsko testiranje postoji za testiranje softvera nakon niza ažuriranja. To uključuje i funkcionalne i nefunkcionalne testove koji osiguravaju da aplikacija i dalje radi prema dovoljno visokom standardu dok se kod mijenja.
Ispitivači koji koriste regresijsko testiranje obično koriste automatizaciju jer opseg regresijskih testova raste kako tim za osiguranje kvalitete pronalazi sve više nedostataka.
Međutim, ručno testiranje nužno je u nekim slučajevima, jer tvrtke koje testiraju korisničko sučelje koriste ručne testove kako bi vidjele kako ljudski korisnik reagira na promjene u izbornicima, gumbima i opcijama navigacije.
3. Testiranje uzorka
Testiranje uzorka je oblik testiranja koji se fokusira na praćenje određenog uzorka u svakom testu koji organizacija dovrši.
Timovi za testiranje dizajniraju ove testove tako da ciljaju svaku značajku softvera, pri čemu svaki dio testa pruža dosljednu razinu informacija za tvrtku u vezi s načinom na koji pojedinačne značajke funkcioniraju.
Korištenje testiranja uzoraka ponekad se oslanja na modificiranje uzorka kako vrijeme prolazi kako biste bili sigurni da prosuđujete svaki od sustava koji rade, ali kada imate obrazac koji funkcionira, izbjegavajte odstupanja kako biste osigurali veću dosljednost u svojim rezultatima.
4. Ispitivanje ortogonalnog niza
Testiranje ortogonalnog niza primarno je tehnika testiranja orijentirana na crnu kutiju koja se javlja kada ispitivači koriste značajan broj ulaza koji je prevelik za iscrpno testiranje svakog pojedinog sustava u procesu.
U tim slučajevima, svaki pojedinačni podatak daje svoju jedinstvenu informaciju zbog potencijalnog nedostatka korelacije između određenih informacija. Ovo je ortogonalni aspekt sustava, s jedinstvenim dijelovima informacija koji se koriste za pružanje maksimalne razine podataka uz minimalan napor.
Vrijeme testiranja je smanjeno, a vi imate idealnu ravnotežu podataka za pružanje razvojnom timu.
Testiranje sive kutije u životnom ciklusu softverskog inženjerstva
Testiranje u sivoj kutiji spada u određenu fazu životnog ciklusa softverskog inženjeringa. Ovaj životni ciklus zamršen je niz koraka koje tvrtke slijede kada razvijaju svoje proizvode, a svaki korak vodi do višeg standarda proizvoda.
Iako je testiranje dio procesa koji se neprestano odvija, postoji vrlo ograničeno vrijeme za testiranje u sivoj kutiji.
To se događa nakon što je početna funkcionalnost dovršena i testirana putem testiranja bijele kutije i prije nego što je softver spreman za javnu objavu, pri čemu tvrtke preferiraju testiranje crne kutije u najnovijim fazama.
Siva kutija je savršen alat za integraciju značajki zajedno i osiguravanje njihovog pravilnog rada u tandemu osim neovisno.
Ručni ili automatizirani Gray Box testovi?
Kao i kod bilo kojeg drugog oblika testiranja softvera, timovi za osiguranje kvalitete biraju između ručnog dovršavanja testiranja pomoću stručnih članova osoblja ili automatskog, što uključuje kodiranje niza testnih slučajeva i njihovo opetovano dovršavanje kako bi se osigurao točan skup rezultata.
Saznajte više o ručnom i automatiziranom testiranju, s nekim prednostima i izazovima svakog od njih, uz to koji je od dva oblika testiranja idealan za tvrtku koja želi bolje razumjeti probleme sa svojim proizvodom.
Ručno testiranje u sivoj kutiji – prednosti, izazovi, proces
Ručno testiranje temeljni je dio mnogih vrsta testiranja, uključujući testiranje u sivoj kutiji.
Ovaj proces uključuje navođenje ljudskih testera da ispitaju dio softvera, ispituju radi li softver kako očekujete i uspoređuju ga s već postojećim dizajnerskim dokumentima i kodom koji je vidljiv kako bi provjerili postoje li očiti nedostaci u tim informacijama koji bi mogli uzrokovati probleme.
Slučajevi u kojima je ručno testiranje uobičajeno uključuju kompliciranije dijelove softvera koji zahtijevaju da ljudsko biće pruži kvalitativni uvid.
Druge namjene uključuju manje tvrtke koje žele temeljito procijeniti svoj softver, jer male aplikacije i paketi zahtijevaju relativno malo resursa za tvrtke za procjenu u usporedbi s većim programima koje proizvode veće tvrtke.
1. Prednosti ručnog testiranja sive kutije
Nekoliko je prednosti ručnog testiranja u sivoj kutiji za bilo koji softver. Poznavanje ovih prednosti znači da svoje testiranje možete usmjeriti prema njima, otkrivajući više problema u svom softveru i povećavajući standard svog rada zahvaljujući boljem režimu testiranja.
Glavne prednosti ručnog testiranja sive kutije su:
Detaljne povratne informacije
Prva velika prednost korištenja ručnog testiranja u sivoj kutiji jest da ljudski testeri mogu pružiti značajnu razinu povratnih informacija razvojnom programeru.
Pri korištenju automatiziranog testiranja, testni slučajevi dizajnirani su tako da uvijek iznova proizvedu vrlo specifične metrike koje analitičarima daju uvid kada imaju vremena za procjenu podataka.
Ovo je donekle drugačije kada se koristi ručno testiranje, budući da tester može dati detaljnije povratne informacije o tome koja značajka nije radila i mogućim razlozima problema nakon što ih usporedi s dokumentacijom dizajna.
Korištenje detaljnih vodiča za povratne informacije ne samo da ažurira postojeće značajke, već i potencijalno nove značajke koje tester preporučuje korisnicima.
Bolje interpretacije
Automatizirano testiranje znači da su svi zaključci stvar procjene podataka koje dobijete iz testa i donošenja racionalnog zaključka o tome što to znači za softver.
Naprotiv, ručni testeri imaju daleko veću razinu uvida u način rada same aplikacije.
Oni mogu usporediti kod sivog okvira s onim što se događa u stvarnom vremenu, čineći točnu procjenu u tom trenutku umjesto da moraju izvoditi zaključke naknadno.
Neke platforme za automatizaciju mogu raditi slično ako imaju značajku ponavljanja, ali to još uvijek zahtijeva ručnu intervenciju.
Fleksibilno testiranje
Automatizacija testiranja uključuje kodiranje vrlo specifičnih testnih slučajeva u platformu, što znači da softver uvijek iznova izvršava taj određeni skup zadataka.
Iako je ovo idealno za ponavljanje, predstavlja jedinstveni izazov jer nema fleksibilnosti u testiranju.
Korištenje ljudskog ispitivača idealno je u tim slučajevima, što daje veću fleksibilnost procesu. Ako ljudski tester primijeti potencijalni problem koji je malo izvan usko definiranog testnog slučaja, može ga ispitati i prijaviti rezultate na kraju procesa.
To tvrtkama pruža sveobuhvatniju pokrivenost softverom, otkrivajući greške koje automatizirani sustav ne može.
2. Izazovi ručnog testiranja sive kutije
Iako postoji mnogo prednosti korištenja ručnog testiranja u procesu razvoja softvera, postoji i nekoliko nedostataka. Oni se razlikuju ovisno o nekoliko čimbenika, uključujući određeni softver na kojem tvrtka radi, veličinu razvojnog tima i standard vještina koje imaju članovi timova za testiranje i razvoj.
Značajni izazovi u ručnom testiranju uključuju:
Visoki troškovi rada
Troškovi rada jedan su od najznačajnijih izdataka kroz koje prolazi bilo koje poduzeće, jer se isplati dobiti najbolje raspoložive kadrove kako bi poduzeće poboljšalo standard svog rada.
Kako ručno testiranje u sivoj kutiji može potrajati puno vremena, tvrtka mora platiti svoje testere da rade tijekom cijelog procesa. Za neke od najvećih aplikacija to može potrajati satima i uzrokovati skokovito povećanje troškova ručnih testera.
Programeri mogu nastojati ublažiti ovaj problem balansiranjem automatizacije testiranja u sivoj kutiji s ručnim testiranjem ili smanjenjem troškova rada po satu, ali to riskira pad kvalitete testiranja.
Ljudska pogreška
Automatizirano testiranje učinkovito dovršava jednostavne procese, ponavljajući ih s visokim stupnjem točnosti na način koji osoba ne može.
Ljudska bića čine pogreške i manje pogreške, koje mogu biti rezultat bilo čega, od slučajnog pritiskanja pogrešnog gumba do gubitka pažnje na nekoliko sekundi.
Pogreške poput ove mogu dovesti do netočnih podataka i uzrokovati da programeri usredotoče svoju pozornost na krivi dio softvera, oduzimajući dragocjeno vrijeme razvoja i pogoršavajući proizvod.
Nastojte to riješiti ispunjavanjem ponovljenih testova sivog okvira gdje god je to moguće kako biste potvrdili svoje rezultate dok se testiranje nastavlja.
Dugo traje
Tamo gdje računala mogu obaviti zadatke u trenu, ljudima treba malo više vremena.
To je zbog svega, od vremena reakcije do jednostavnog rada sporije od njihove optimalne brzine u točkama, što sve usporava proces testiranja.
Sporiji proces testiranja znači manje vremena za razvojne timove da rade na uklanjanju grešaka i nedostataka u proizvodu, budući da sve vrijeme ide na pronalaženje problema na prvom mjestu.
To nije nešto što je lako ublažiti, a hibridni režim testiranja kao što je balansiranje ručnih testova s automatiziranim testovima sive kutije jedno je od potencijalnih rješenja.
Automatizacija testiranja sive kutije – prednosti, izazovi, proces
Automatizacija testiranja odnosi se na postupak korištenja platforme za automatizaciju kako bi se neki dijelovi procesa testiranja u sivoj kutiji učinili automatskim.
Proces funkcionira tako da se od kreatora testova traži da stvore niz testnih slučajeva s QA analitičarima ili sličnim profesionalcima koji kodiraju te testove u programe automatizacije, a neki koriste robotsku automatizaciju procesa kao daljnji alat.
U tim slučajevima QA analitičari već razumiju neke od kodova ili dizajn dokumenata.
Ova vrsta testiranja je češća na mnogo većim programskim paketima, budući da testeri sive kutije nemaju vremena temeljito ručno testirati sve aspekte procesa.
Nakon automatiziranog procesa, platforma vraća izvješće za QA analitičar, bilježeći gdje postoje propusti i niz važnih metrika.
1. Prednosti automatiziranog testiranja u sivoj kutiji
Postoji nekoliko jasnih prednosti korištenja automatiziranog testiranja u sivoj kutiji u procesima tima za osiguranje kvalitete.
Usredotočujući se na te prednosti i maksimalno ih iskorištavajući, tvrtka može povećati učinkovitost svog testiranja u sivoj kutiji i riješiti što više problema u ovoj fazi tijeka rada.
Neke od primarnih prednosti korištenja automatizacije u vašem radu testiranja u sivoj kutiji uključuju:
Brzo testiranje
Automatizirani sustavi dizajnirani su za nevjerojatno brzo testiranje, prolazeći kroz niz procesa što je brže moguće. Ova prednost postaje još izraženija kada se dovrše ponovljeni testovi sive kutije, budući da svako pojedinačno pokretanje traje kraće.
Količina vremena koju štedite od pokretanja do rada značajno se povećava, a vaša tvrtka ima mnogo više vremena za obavljanje hitnih zadataka kao što je ažuriranje samog softvera i pružanje povratnih informacija klijentima i potencijalnim kupcima.
Brže testiranje posebno je korisno kada se radi nakon izdavanja, jer je guranje popravaka funkcionalnosti što je prije moguće neophodno za poboljšanje načina na koji ljudi vide poslovanje.
Točna metrika
Mjerni podaci su značajan dio načina na koji funkcionira testiranje softvera, pružajući numeričke informacije testeru kako bi ukazao na moguće probleme.
Računala i platforme za automatizaciju nude vrlo precizne metrike, sa stvarima kao što su vremena odziva koja se mjere do milisekunde.
Točnija metrika znači da možete pratiti male pomake u načinu na koji aplikacija radi, što vam pomaže da shvatite je li ažuriranje poboljšalo izvedbu ili je dovelo do toga da standardni tijek rada traje više vremena.
Smanjeni troškovi
Jedan od najvećih troškova testiranja u okruženju razvoja softverske sive kutije je trošak samih testera sive kutije.
Angažiranje stručnjaka za testiranje softvera je skupo, pogotovo kada tražite testere u sivoj kutiji, koji zahtijevaju veći izbor vještina, kako bi isporučili najviše moguće standarde za vašu organizaciju.
Automatizacija znači da manje ljudi ispunjava ručne testove sive kutije, čime se eliminiraju mnogi troškovi osoblja iz procesa.
Iako platforme za automatizaciju imaju neke troškove, od kojih većina naplaćuje mjesečnu pretplatu, to je daleko niže nego da morate plaćati zaposlenicima da obavljaju posao za vas.
2. Izazovi automatiziranog testiranja u sivoj kutiji
Postoji mnogo izazova u korištenju automatizacije u vašim procesima testiranja u sivoj kutiji.
Dok se neke organizacije usredotočuju na prednosti, postoji mnogo prednosti poznavanja izazova testiranja u sivoj kutiji i njihovog razmatranja tijekom rada.
Testiranje sive kutije možete implementirati na način koji izbjegava izazove i sprječava vas da se u budućnosti borite s ograničenjima.
Glavni izazovi automatiziranog testiranja u sivoj kutiji su:
Početno postavljanje
Početno postavljanje jedan je od najvećih izazova prolaska kroz proces automatizacije. To se odnosi na vrijeme potrebno za prijelaz na novu platformu za testiranje, uključujući instaliranje platforme, podučavanje korisnika kako se s njome koristiti i kodiranje ranih testova na softveru.
Sve je to neproduktivno vrijeme koje će tvrtka željeti ograničiti što je više moguće.
Korištenje vrhunskog softvera za automatizaciju sa stručnjacima pri ruci kada vam je potrebno idealno je u ovom slučaju, budući da imate podršku treće strane koja osigurava da vaša automatizacija sive kutije i druge vrste testiranja po ovom pitanju teku glatko od samog početka.
Visoki zahtjevi za vještinama
Iako ručno testiranje zahtijeva visoku razinu vještina, QA analitičari koji rade s automatizacijom ipak moraju imati visoku razinu vještina.
To dolazi u obliku vještina kodiranja, koje se primarno koriste za izradu testnih slučajeva i čitanje koda koji je dostupan u scenariju sive kutije.
Programeri to mogu ublažiti izričitim angažiranjem testera koji imaju iskustva u razvoju ili su u prošlosti radili na projektima kodiranja. Ograničavate vrijeme obuke na radnom mjestu i osiguravate da svaki novi zaposlenik ima kapacitet da se prilagodi zahtjevima automatiziranog testiranja sive kutije.
Neke tvrtke namjeravaju koristiti sustav automatizacije bez koda za provođenje testiranja u sivoj kutiji kao alternativu, ali to može dovesti do manje fleksibilnosti na radnom mjestu.
Stalni nadzor
Automatizirano testiranje djelomično postoji kako bi se uklonio naglasak s oslanjanja na ljude, pri čemu ručno testiranje ima stalnu uključenost ljudi u procese.
To nije slučaj s automatizacijom testiranja, ali tvrtke ipak trebaju imati dobru razinu nadzora.
Nadzor uključuje ispitivanje rezultata testova sive kutije i njihovo održavanje kako bi se osiguralo da sve i dalje radi onako kako razvojni programer očekuje.
Tvrtke mogu pomoći u poboljšanju dostupnog standarda nadzora na nekoliko načina, a idealno je da samo jedan stručnjak bude odgovoran za nadgledanje testova.
To dovodi do veće razine specijalizacije, pri čemu taj član osoblja postaje stručnjak iz sive kutije u bržem i učinkovitijem radu s automatizacijom.
Zaključak: ručno ili automatizirano testiranje u sivoj kutiji?
Zaključno, ručno testiranje sive kutije i automatizirano testiranje imaju svoje mjesto u procesu testiranja softvera.
Manje tvrtke i startupi imaju koristi od implementacije ručnog testiranja sive kutije kada je njihov kod relativno malen i njime se može upravljati, a automatizacija postaje sve korisnija kako aplikacije nastavljaju rasti i imaju više značajki.
Međutim, uvijek će biti mjesta za ručno testiranje zahvaljujući povećanoj razini uvida, detalja i fleksibilnosti koje nudi tvrtkama.
Idealno rješenje sive kutije za svaku tvrtku je hibridni model, koji koristi ručno i automatizirano testiranje na različitim točkama kako bi se uzele u obzir prednosti i slabosti obiju tehnika.
Holistički pristup izlaže više problema koje programski paket ima, pomaže u učinkovitijem popravljanju softvera i u konačnici pružajući klijentima mnogo bolji proizvod na kraju razvoja.
Što vam je potrebno za početak Grey Box testiranja?
Postoji nekoliko preduvjeta koje tvrtke zahtijevaju prije započinjanja procesa testiranja u sivoj kutiji. Posjedovanje njih čini proces testiranja mogućim ili testiranje softvera čini mnogo jednostavnijim za tim za osiguranje kvalitete budući da imaju više dostupnih sredstava.
Preduvjeti za dovršetak testiranja u sivoj kutiji uključuju:
1. Dokumenti dizajna ili izvorni kod
Prva stvar koju trebate za početak procesa testiranja sive kutije je ili projektna dokumentacija ili izvorni kod. Ispitivači moraju imati pristup ovim informacijama kako bi se testiranje smatralo testom sive kutije, koji nudi određeni uvid u unutarnje funkcioniranje samog softvera.
Ove informacije nastoje biti što je moguće relevantnije, na primjer, niz koda za određenu funkciju koju ispitivač ispituje.
Kada koristite testiranje sive kutije umjesto testiranja bijele kutije, dajete samo dio koda i dizajn dokumentacije, stoga budite oprezni s razinom pristupa koju pružate.
2. Kratak opis proizvoda
Sažetak o proizvodu ili sažetak o aplikaciji je dokument koji tvrtke koriste kako bi stekle potpuno razumijevanje onoga što klijent traži u softverskom paketu. To na detaljan način utvrđuje točnu funkcionalnost koju klijent traži od softvera, dizajn koji klijent želi i sve druge specifikacije koje su potrebne.
Čitanje sažetka proizvoda znači da tester iz sive kutije može potražiti sve značajke koje klijent želi, provjeravajući da se nalaze u softveru i osiguravajući da proizvod odgovara svim ciljevima koje tvrtka ima za svoju primjenu.
Neke tvrtke ograničavaju količinu informacija koje testeri u sivoj kutiji mogu vidjeti, ovisno o politici povjerljivosti u tvrtki.
3. Ciljevi testa
Programeri i tvrtke imaju specifične ciljeve pri dovršavanju testova, koji se ponekad nazivaju specifikacijom testa. Ovo je vrlo važno u procesu testiranja u sivoj kutiji, jer znači da programeri mogu pružiti testerima u sivoj kutiji sve prave informacije, a tim za osiguranje kvalitete dizajnira testove koji odgovaraju ciljevima procesa testiranja.
U ovom slučaju svi rade učinkovitije jer znaju što traže i kako najbolje postići te ciljeve.
Proces testiranja sive kutije
Testiranje u sivoj kutiji slijedi relativno dosljedan proces, s jasnim koracima koji navode pojedinačne faze koje tvrtka mora dovršiti kako bi postigla svoje ciljeve testiranja.
Jasno i dosljedno praćenje procesa daje točne i dosljedne rezultate koji informiraju programere o tome gdje se problemi nalaze i kako se mogu riješiti.
Glavni koraci u testu sive kutije su:
1. Određivanje inputa i outputa
Prvi korak u procesu je određivanje ulaza i izlaza koje očekujete od aplikacije.
Odaberite unos koji je unutar granica onoga što bi aplikacija mogla normalno obraditi kako biste ga učinili poštenim testom i razradili izlaz koji očekujete od tog unosa.
Dovršavanjem ovog predviđanja na početku projekta znate je li nešto pošlo po zlu na kraju testova.
2. Identificirajte primarne tokove
Primarni tokovi su rute koje podaci slijede u dijelu softvera kako bi došli do konačnog izlaza.
Identificiranje primarnog toka znači da možete bolje pratiti način na koji informacije prolaze kroz softverske procese, utvrđujući potencijalna područja gdje se mogu pojaviti nedostaci i raditi na njihovom popravljanju ako postoji problem sa softverom.
3. Identificirajte podfunkcije, s ulazima i izlazima
Podfunkcije su osnovne operacije unutar primarnog toka. Svaku podfunkciju napaja druga i unosi se u sljedeću, što u konačnici dovodi do konačnog izlaza iz softvera.
Odredite kakav bi trebao biti input za svaku podfunkciju, zajedno s predviđenim izlazom za svaku.
Čineći to na razini podfunkcije, dobivate dodatnu razinu uvida prilikom lociranja problema sa softverom.
4. Razvijte test slučaj
Testni slučaj odnosi se na skup događaja koji se događaju u softveru koji ispituje radi li aplikacija onako kako očekujete.
Uvjerite se da ovaj testni slučaj sive kutije pravilno ispituje dio softvera koji gledate.
Također se usredotočite na dosljednost, pazeći da se testni slučaj lako replicira kako biste dobili preciznije rezultate iz vašeg testa sive kutije.
5. Pokrenite testni slučaj
Počnite izvoditi test slučaj.
To uključuje unos inputa u svaku od podfunkcija i vidjeti koji su izlazi, bilježeći sve rezultate.
U automatiziranom testiranju u sivoj kutiji, proces snimanja je automatski, s ručnim ispitivačima koji sami bilježe sve ulaze i izlaze.
Ako možete, testirajte sve podfunkcije pojedinačno prije pokretanja cijelog tijeka odjednom kako biste provjerili radi li svaka funkcija neovisno.
6. Provjerite rezultate
Nakon što primite podatke iz testnog slučaja, počnite provjeravati ove rezultate.
To znači promatrati rezultate koje dobijete od softvera i usporediti ih s rezultatima koje ste očekivali na početku procesa.
Ako postoji bilo kakva razlika između to dvoje, to znači da bi mogla postojati pogreška u softveru jer ne radi na način koji ste prvotno predvidjeli.
7. Napravite izvješće
Na kraju procesa testiranja sivog okvira izradite izvješće o rezultatima testa.
To uključuje osnovni sažetak problema sa softverom, procjenu nekih mogućih rješenja problema i, gdje je to moguće, sve podatke koje su testovi generirali.
Korištenje ove strukture daje naslovnu lekciju za čitatelja prije pružanja svih potrebnih dokaza, što u konačnici predstavlja kohezivni dokument koji nudi obilje smjernica.
Najbolji primjeri iz prakse za Greybox testiranje
Najbolje prakse odnose se na procese, zadatke i principe koje zaposlenici ispunjavaju u QA testu kako bi postigli najviše moguće standarde.
Neki od ovih najboljih primjera iz prakse za QA timove koji žele povećati standard svog rada uključuju:
1. Radite pažljivo
Kao i kod svake druge metode testiranja, uzmite si vremena i pažljivo radite. Jedna jedina pogreška može poništiti test, tako da sporost i postojanost kako biste osigurali da je vaš rad točan dugoročno štedi vrijeme dok istovremeno poboljšava standard softvera. To je posebno istinito u testiranju sivih okvira, jer ne znate s kojim dijelovima izvornog koda radite u bilo kojem trenutku.
2. Konstantno komunicirajte
Trebao bi postojati stalan lanac komunikacije između programera i testera sive kutije. To razvojnim programerima daje trenutnu povratnu informaciju o svim greškama koje tim za testiranje otkrije i znači da testeri znaju na što trebaju paziti.
Ako je bug dio vidljivog aspekta sivog okvira, neka programeri znaju gdje se točno nalazi.
3. Postavite stroga ograničenja
Kada testiranje u sivoj kutiji koristi umjetna ograničenja informacija, pri čemu tvrtka sama odlučuje koje će informacije dati ispitivačima, osigurajte da imate stroga ograničenja.
Dajte QA timu samo dopuštenja koja su im potrebna ili riskirate da “pogledaju iza zastora” i vide neke od izvornog koda ili razvojnih dokumenata koje pokušavate zadržati skrivenima.
7 pogrešaka i zamki u implementaciji testova sive kutije
Sa stotinama tisuća aplikacija koje svake godine prolaze kroz proces testiranja, postoje neke pogreške i zamke u koje QA timovi upadaju.
Poznavanje toga znači da ih možete učinkovito izbjeći, poboljšavajući svoj rad i smanjujući šanse za rasipanje resursa na loše strategije testiranja.
Neke od najčešćih pogrešaka i zamki u testovima sive kutije uključuju:
1. Testiranje distribuiranih sustava
Testiranje sive kutije zahtijeva pristup izvornom kodu, a distribuirani poslužitelji koriste kod s drugih lokacija. To uzrokuje probleme kod testiranja sivog okvira, jer znači da postoje problemi koje testeri možda neće moći vidjeti.
2. Dovršavanje nedosljednog testiranja
Nedosljedno testiranje odnosi se na situaciju u kojoj testni slučaj varira između pokretanja. To može uzrokovati netočne rezultate, a programeri se tada usredotočuju na poboljšanje performansi na temelju lažnih mjernih podataka.
Učinite svaki test identičnim gdje je to moguće kako biste povećali preciznost i točnost testiranja.
3. Žurba kroz testove
Ako se nazire predloženi datum izdavanja proizvoda, QA timovi mogu biti u iskušenju da požure s procesima testiranja sivih okvira.
Međutim, to je znak lošeg planiranja i na to ne treba reagirati još lošijim odlukama. Žurno testiranje dovodi do netočnih rezultata i gubljenja vremena kasnije u fazi razvoja.
4. Neprovođenje priručnika i automatizacije zajedno
Ni ručno ni automatizirano testiranje nisu savršene metode testiranja sive kutije.
Korištenje njih dvoje jedno uz drugo znači da možete odgovoriti na probleme svakoga, što u konačnici djeluje učinkovitije.
U najmanju ruku, razmislite o kombiniranju dviju metoda za bolje testiranje.
5. Rad bez alata
Alati za testiranje osmišljeni su kako bi rad kao gray box tester bio što lakši. Rad bez ikakvih alata nepotrebno ograničava vlastite mogućnosti.
Temeljito istražite i nabavite sve alate koji bi mogli pomoći vašem razvoju da povećate učinkovitost i smanjite mogućnost pogrešaka.
6. Loša komunikacija
Interna komunikacija između odjela može biti teška, ali što jasnija komunikacija između odjela za testiranje i razvoja neophodna je.
Bolja komunikacija znači da programeri znaju koja poboljšanja trebaju učiniti odmah i riješiti probleme bez da ih zavede loša interna razmjena poruka.
7. Aktivno traženje grešaka
Testovi sive kutije postoje kako bi se pronašli bilo kakvi bugovi tamo gdje postoje, ali i kako bi se ispitala opća izvedba softvera.
Predugo bavljenje pronalaženjem grešaka može oduzeti puno vremena i odvratiti pažnju od glavnog cilja poboljšanja načina na koji aplikacija funkcionira.
Vrste izlaza iz testova sive kutije
Testovi sive kutije generiraju nekoliko različitih vrsta informacija na kraju procesa. Ovo se ne odnosi na rezultate samog softvera, već na podatke koje programeri mogu koristiti za poboljšanje softvera.
Glavne vrste izlaza su:
1. PASS/FAIL poruke
Jednostavna PASS/FAIL poruka koja obavještava programera o tome je li operacija softvera bila uspješna.
Ova vrsta izlaza ne pruža razvojnom programeru puno uvida, ali korištenje testiranja u sivoj kutiji znači da tester može vidjeti u kojoj je točki softver zakazao i zašto, pomažući u rješavanju problema.
2. Mjerni podaci
Mjerni podaci odnose se na jednostavne statistike koje prikazuju događaj, kao što je vrijeme potrebno da se dovrši određeni zadatak sve do milisekunde. Oni su uobičajeni u automatiziranom testiranju sive kutije, pri čemu računalne platforme automatski prikupljaju te informacije na višoj razini preciznosti nego što bi to mogao učiniti ručni tester.
Ove su informacije korisne za utvrđivanje izvedbe aplikacije.
3. Kvalitativni podaci
Opisne informacije koje dobivate od testera sive kutije iz njihovog iskustva sa softverom. Nemjerljivo, što otežava analizu, ali pruža bolju razinu uvida u korisničko iskustvo i čini klijentima ugodnijim korištenje softvera.
Primjeri testova sive kutije
U nekim slučajevima, poznavanje teorije o obliku testiranja ne nudi dovoljan uvid i ne omogućuje pravilno razumijevanje. Poznavanje nekih primjera testova sive kutije ključno je za poboljšanje vašeg razumijevanja načina na koji metodologija testiranja funkcionira.
U nastavku pogledajte neke primjere testova sivih okvira koji pružaju više pojedinosti o testovima u stvarnom svijetu i kako se teorija primjenjuje na praktična radna mjesta.
1. Primjer uspješnog sigurnosnog testiranja
Tvrtka stvara bazu podataka s mnogo osobnih podataka i planira sigurnosno testiranje kako bi se uvjerila da su korisnički podaci zaštićeni.
Ručni tester prolazi kroz proces, tražeći moguće nedostatke u kodu i prilike za pristup dijelovima aplikacije.
Nakon pronalaska slabosti, tester obavještava programera gdje je slabost i kako ju je iskoristio.
Kada se softver zakrpi, ispitivač ponovno dovršava isti test kako bi se uvjerio da je sustav siguran.
2. Primjer neuspjelog testiranja baze podataka
Programeri koji stvaraju bazu podataka imaju kratak rok za objavu i moraju brzo testirati.
Ispitivači zajedno žure s nekoliko osnovnih testnih slučajeva i brzo ih dovršavaju, čineći pogreške u njihovom izvođenju, ne pripremajući predviđanja izlaza i ne uspijevajući ispitati podfunkcije.
Budući da ne pripremaju prognoze izlaza, ne shvaćaju probleme s rezultatima, isporučujući proizvod koji kao rezultat ne radi ispravno.
Vrste grešaka i grešaka otkrivenih testiranjem u sivoj kutiji
Jedan od glavnih ciljeva testiranja u sivoj kutiji je pronaći greške i bugove u programu, a tvrtke žele isporučiti vrhunske aplikacije na koje se njihovi klijenti mogu osloniti gdje god je to moguće.
Postoji nekoliko specifičnih vrsta pogrešaka i grešaka koje testeri mogu pronaći u procesu testiranja sivog okvira, a svaka od njih može ukazivati na drugačiji problem s kodom.
Vrste grešaka i grešaka otkrivenih u testiranju sivog okvira uključuju:
1. Kvar procesa
Prvi oblik pogreške je neuspjeh procesa.
Ovo se odnosi na slučajeve kada test ne vraća nikakav oblik rezultata i jednostavno se ruši.
Postoji nekoliko mogućih uzroka ovih problema, a u idealnom slučaju, tester iz sive kutije može utvrditi odakle dolazi problem i kako programer može kodirati odgovor.
2. Netočan izlaz
Neke pogreške u testiranju sivog okvira pojavljuju se kada rezultat procesa nije onakav kakav razvojni programeri predviđaju.
Ovo je ozbiljan problem u slučajevima kao što je baza podataka, u kojoj je sigurno čuvanje točnih informacija nužno.
3. Sigurnosne pogreške
Sigurnosne pogreške događaju se kada je aplikacija tvrtke donekle nesigurna i dopušta trećoj strani pristup informacijama koje se unutar nje nalaze.
Sigurnosni nedostaci u aplikaciji mogu biti problem GDPR-a i učiniti aplikaciju nesukladnom s nizom međunarodnih propisa.
Uobičajene metrike testiranja sivog okvira
Mjerni podaci se odnose na konstantna mjerenja koja ispituju određeni događaj ili niz pojavljivanja, obično u obliku kvantitativnih podataka.
Korištenjem metrike, ispitivači i timovi za osiguranje kvalitete mogu ispitati softver koji je podvrgnut testu sivog okvira i točno vidjeti što nije u redu, je li to u obliku većeg broja pogrešaka ili različitih značajki koje se dulje učitavaju.
Neke od najčešćih metrika testiranja u sivoj kutiji koje QA testeri koriste pri procjeni softvera uključuju:
· Vrijeme do izlaza:
Količina vremena koja je potrebna da aplikacija proizvede izlaz nakon početka testa.
· Vrijeme do odgovora:
Količina vremena koja je potrebna da softver odgovori na korisnički unos, bilo u obliku rezultata ili jednostavno potvrde unosa.
· Broj grešaka:
Čisti broj grešaka koje softver ima u svojim procesima.
· Pogreške po funkciji:
Broj pogrešaka koje postoje podijeljen s brojem funkcija u softveru, korišten za određivanje gustoće pogrešaka.
Najbolji Grey Box alati za testiranje
Testiranje sive kutije može se osloniti na vanjske alate za poboljšanje kvalitete vašeg rada, automatizirajući neke od procesa i podržavajući vas pri stvaranju popravka za sve pogreške koje pronađete.
Što je bolji alat za testiranje koji koristite, to ćete više problema otkriti i to će biti bolji standard vašeg konačnog proizvoda, uz uštedu vremena i resursa tijekom testiranja.
U nastavku pogledajte neke od najboljih alata za testiranje sive kutije, uz prednosti i nedostatke korištenja svake platforme.
5 najboljih besplatnih alata za testiranje Grey Boxa
Kada manja tvrtka želi započeti s testiranjem u sivoj kutiji, neophodno je imati prave alate na raspolaganju, ali imati ih po razumnoj cijeni može biti jednako važno. Svaki novčić se računa u maloj tvrtki, a razvojni programer aplikacija nije ništa drugačiji, s ograničenim proračunima koji dovode do teških odluka.
Korištenje besplatnih alata za testiranje sive kutije savršeno je za osiguranje kvalitete uz minimalna sredstva.
Neki od najboljih besplatnih alata za testiranje sive kutije uključuju:
1. ZAPTEST BESPLATNO IZDANJE
Besplatno izdanje ZAPTEST-a nudi visokokvalitetno iskustvo automatizacije za svoje korisnike, s punom softverskom automatizacijom koja podržava testiranje od samog početka razvoja.
S paralelnim izvođenjem možete dovršiti nekoliko testova odjednom kako biste ubrzali svoje procese, a kada ste spremni za skok na sljedeću razinu, izdanje Enterprise čini prijelaz što jednostavnijim. Kao dodatnu pogodnost, ZAPTEST također nudi vrhunsku RPA tehnologiju , bez dodatnih troškova.
Savršen izbor za nekoga u ranim danima testiranja.
2. Apijem
Alat za temeljito testiranje osmišljen kako bi se uvjerio da mobilne aplikacije zadovoljavaju standarde , Appium ima aktivnu zajednicu podrške, ali testove provodi relativno sporo. U kombinaciji s izazovnim postavkama, ovo nije najbolji besplatni alat za mnoge tvrtke.
3. Chrome Dev Alati
Google Chrome nudi niz razvojnih alata za web-aplikacije , a uz integraciju u najpopularniji preglednik, čini se kao obavezan.
Međutim, ograničen je na elemente okvira za testiranje, što ga čini restriktivnim alatom za testiranje.
4. JUnit
JUnit je okvir otvorenog koda koji korisnicima omogućuje dovršavanje ponovljivih testova uvijek iznova u Javi, ograničavajući je na jedan jedini jezik.
Samo po sebi, ovo ograničenje nije problem, ali nedostatak jednostavnog API-ja i sučelja može ga učiniti neugodnim za novije testere.
5. DBUnit
DBUnit se fokusira na podršku projektima orijentiranim na baze podataka, koristeći poznata stanja za točnu provjeru rezultata i sveobuhvatno ispitivanje ishoda.
Ovo je savršeno za baze podataka i slične aplikacije, ali nedostatak podrške za integraciju znači da ima poteškoća u zadacima na više platformi.
5 najboljih Enterprise Grey Box alata za testiranje
Kako razvojni programer raste, tako rastu i njegovi zahtjevi za testiranjem, pri čemu veće tvrtke imaju veće aplikacije i kao rezultat toga zahtijevaju sveobuhvatnije pakete za testiranje.
Alati za testiranje sive kutije za poduzeća postoje kako bi podržali tvrtke u ovoj situaciji, pružajući bolji pristup naprednim značajkama koje amaterski i mali programeri možda neće trebati.
Neki od najboljih alata za testiranje na poslovnoj razini pri provođenju testa sive kutije uključuju:
1. ZAPTEST PODUZEĆE IZDANJE
Enterprise izdanje ZAPTEST-a pruža veće mogućnosti testiranja od besplatne verzije, a jedna od glavnih prednosti je stalni pristup ZAP Expert-u. ZAP Expert učinkovito djeluje kao savjetnik i član vašeg tima na daljinu, podržavajući sve potrebe testiranja vaše tvrtke.
Programeri koji ulažu u izdanje ZAPTEST Enterprise mogu vidjeti do deset puta veći povrat svoje investicije zahvaljujući naprednim tehnologijama računalnog vida , 1SCRIPT-u, izvršavanju na više platformi, na različitim uređajima, na različitim preglednicima i prije svega neograničenim licencama.
Neograničene licence, uz najnaprednije testiranje i RPA tehnologiju, znače da poduzeća imaju koristi od fiksnih troškova, bez obzira na to koliko brzo i koliko rastu.
2. TestRail
Rješenje za upravljanje testnim slučajevima koje vam omogućuje da podijelite sve testove koje završite po testnom slučaju, točnije bilježeći podatke.
Međutim, TestRail nije nužno idealan za testiranje u sivoj kutiji jer mu je teško uravnotežiti ručno testiranje s automatiziranim snimanjem testova.
3. Testim
Platforma za testiranje koja se fokusira na ponudu stabilnih prilagođenih testova, implementirajući i kodirane testne slučajeve i nekodirane alternative.
Budući da je ovo besplatno samo za određen broj testova mjesečno, veće organizacije mogu imati problema da maksimalno iskoriste ovu platformu.
4. TestRigor
TestRigor je široko cijenjena platforma koja koristi AI mehanizam za dovršetak testova, a održavanje testa AI jedna je od atraktivnijih značajki.
Međutim, to ima značajnu cijenu jer druge platforme daju bolji povrat ulaganja.
5. Kobiton
Kobiton je platforma za testiranje koja je relativno fleksibilna u pogledu cijena, automatizira testove po korisniku nakon završetka besplatnog probnog razdoblja.
Jedna od briga koju neki korisnici imaju oko Kobitona je relativni nedostatak podrške od strane Kobitona kada je u pitanju rješavanje upita testera.
Kada biste trebali koristiti Enterprise a ne Freemium Grey box alate?
Alati sivih kutija za poduzeća i freemium pružaju svojim korisnicima mnoštvo pogodnosti. Tvrtke idealno počinju s besplatnim proizvodom kako bi naučile postupak testiranja prije nego što pređu na izdanje za poduzeća kako se njihove potrebe povećavaju.
Ovo uvodi razinu kontinuiteta u projekt, ograničavajući količinu prekvalifikacije kroz koju osoblje prolazi.
Točka prijelaza razlikuje se od posla do posla, ali u određenom trenutku povrat ulaganja u poslovni proizvod postaje neizbježan.
Kontrolni popis za testiranje sivog okvira, savjeti i trikovi
Dovršavanje testiranja u sivoj kutiji prilično je složen proces, tako da imate popis za provjeru na temelju kojeg možete raditi kako biste bili sigurni da ste učinili sve što ste trebali u testiranju.
Neke od glavnih značajki kontrolnog popisa sivog okvira, uz neke savjete za poboljšanje kvalitete vašeg testiranja, uključuju:
1. Temeljito planiranje
Sveobuhvatno planiranje jedna je od prvih stvari koje treba provjeriti u testu, budući da je obavezno planiranje apsolutno svakog aspekta testa.
Što više planirate, to više strukture stoji iza vašeg testiranja, jer ljudi znaju koje testove polažu i kada ih polažu.
To također dovodi do dosljednih podataka , što je idealno za bolja rješenja za razvojne programere.
2. Trenutno izvješćivanje podataka
Kada radite na procesu testiranja sivog okvira, pokušajte odmah prijaviti podatke. Izradom izvješća što je prije moguće povećavate točnost svojih procesa izvješćivanja jer su sve informacije svježe u vašem umu.
To je osobito slučaj s kvalitativnim informacijama, jer ih treba napisati ispitivač, a ne jednostavno pohraniti na platformu za testiranje.
3. Postavite odgovornosti
Tijekom procesa testiranja osigurajte da se svi na radnom mjestu usredotoče na specifične odgovornosti. Ovakvim raspoređivanjem odgovornosti svatko zna koja je njegova uloga na radnom mjestu i razumije kako svoje zadatke obavljati produktivno i uz minimalne smetnje.
Iako je ovo više koncept upravljanja nego točka kontrolne liste za testiranje, ima veliki utjecaj na rezultate.
4. Stalna usporedba
Uspoređujte svoje rezultate s nekoliko stvari gotovo stalno. Točke za usporedbu uključuju početnu projektnu dokumentaciju, prethodne rezultate testiranja i vremenski raspored organizacije za dovršetak projekta.
Posjedovanje ovih referentnih okvira dosljedno vas obavještava o tome kako napreduje proces razvoja softvera, područjima za poboljšanje i mogućim prilagodbama koje treba napraviti.
Zaključak
Zaključno, testiranje sive kutije jedan je od najsvestranijih dostupnih oblika testiranja, kombinirajući funkcionalnost bijele kutije s ograničenjem pristranosti testova crne kutije.
Kombiniranjem ručnih i automatiziranih metoda testiranja u vašim nastojanjima sive kutije, tvrtke mogu početi značajno smanjivati utjecaj grešaka na svoj softver donošenjem popravaka koji vode do boljeg proizvoda.
Testiranje sive kutije savršen je alat za svakog programera, a gornji savjeti mogu osigurati da ga pravilno koristite.
Često postavljana pitanja i resursi
Ako imate pitanja o testiranju u sivoj kutiji, pogledajte neka od naših često postavljanih pitanja kako biste saznali više i poboljšali svoje razumijevanje ove vrste testa:
1. Najbolji tečajevi o automatizaciji testiranja u sivoj kutiji
Postoji relativno malo tečajeva koji su posebno usmjereni na automatizaciju testiranja sive kutije, a ovi opći tečajevi testiranja softvera idealan su način za početak:
· “Osnova za testiranje softvera s ispitom” – ponude za obuku
· “6-tjedna obuka o osnovama testiranja softvera”- Futuretrend Technologies Ltd
· “Tečaj za testiranje softvera” – Kraljevski tečaj
· “Testiranje u crnoj i bijeloj kutiji” – Coursera
· “Testiranje softvera – strategije crne kutije i testiranje bijele kutije” – NPTEL
2. Kojih je top 5 pitanja za intervju na Grey Box Testingu?
· Kakvo iskustvo imate u radu s testiranjem u sivoj kutiji i kako ste ga pronašli?
· Zašto tvrtke koriste testiranje u sivoj kutiji i u kojem trenutku procesa?
· Usporedite testiranje bijele kutije, sive kutije i crne kutije
· Koji su neki od najvećih izazova testiranja u sivoj kutiji i kako ih možete prevladati?
· Kako funkcionira automatizacija testiranja?
3. Najbolji YouTube vodiči o testiranju Grey Boxa
· “Što je Grey Box testiranje? Koje se tehnike koriste u testiranju sive kutije? Uz objašnjenje primjera”- Hacks za testiranje softvera
· „Testiranje sive kutije | programsko inženjerstvo |”- Obrazovanje 4u
· “Testiranje crne kutije, bijele kutije i sive kutije” – Čudesno obrazovanje
· “Savjet za nove testere ručne provjere kvalitete | Rad s programerima + stvari koje sam naučila kao ispitivač softvera”- Madeline Elaine
· “Što je Grey Box testiranje? (Pitanje intervjua za testiranje softvera #54)”- QA Fox
4. Kako održavati Grey Box testove?
Održavanje vaših testova sive kutije prilično je jednostavan proces. Za ručno testiranje, osigurajte da su članovi osoblja dobro obučeni i da svaki put izvršavaju iste zadatke. Za automatizirano testiranje, provjerite sav kod za testne slučajeve i provjerite rezultate, koristeći stalni nadzor nad procesima gdje god je to moguće.
5. Najbolje knjige o testiranju sive kutije
Ovaj odjeljak osim knjiga sadrži članke iz časopisa, kako bi se pružili najviši mogući standardi pisane pomoći za QA testere:
· “Grey-Box tehnika testiranja integracije softvera na temelju poruke”- TanLi M. et al
· “Usporedna studija tehnika testiranja bijele kutije, crne kutije i sive kutije” – Ehmer, M., Khan, F.
· “Strategije testiranja temeljene na FSM-u sive kutije” – Petrenko, A.
· “Softversko inženjerstvo” – Saleh, KA
· “Međunarodna konferencija o računalnim primjenama 2012.”- Kokula Krishna Hari K.
