Kur jeni duke punuar në testimin e softuerit, ka dhjetëra metoda të ndryshme testimi për t’u marrë parasysh.
Testimi i softuerit i ndihmon zhvilluesit të eliminojnë çdo të metë që mund të ekzistojë në një paketë softuerësh në mënyrë që ata të mund të dërgojnë një produkt që plotëson nevojat dhe pritshmëritë e të gjithë palëve të interesuara. Përdorimi i zgjidhjes së duhur të testimit ju siguron të gjitha njohuritë që ju nevojiten, por zgjedhja e saktë e një testi mund të marrë kohë.
Testimi i kutisë gri është një nga format më të gjithanshme të testimit në dispozicion të testuesve, duke ofruar shumë njohuri pa marrë burime të tepërta.
Mësoni më shumë se çfarë është testimi i kutisë gri, disa nga specifikat se si funksionon testimi i kutisë gri dhe disa nga arsyet që kompanitë përdorin këtë metodë testimi.
Çfarë është testimi i kutisë gri?
Testimi i kutisë gri është një formë testimi që kombinon testimin e kutisë së bardhë dhe testimin e kutisë së zezë, duke përdorur një kuptim të pjesshëm të dizajnit themelor dhe mënyrës se si zbatohet sistemi.
Ky kombinim do të thotë që testuesi di disa nga ato që po ndodhin në sfond pa e ditur plotësisht kodin, gjë që ofron më shumë informacion mbi shkaqet e mundshme të problemeve në softuer kur ato lindin.
Përfundimi i testimit të kutisë gri është përgjegjësi e testuesve, me një ekip të sigurimit të cilësisë që punon në mënyrë të pavarur nga ekipi i zhvillimit në projekt.
1. Kur dhe pse duhet të bëni testimin e kutisë gri në testimin e softuerit?
Ka disa herë që kompanitë përdorin testimin e kutisë gri në procesin e zhvillimit.
Për shembull, kur një aplikacion duhet të ndërveprojë me një mjet të palës së tretë për të funksionuar siç duhet, testuesit nuk kanë asnjë akses në kodin burimor që është pjesë e softuerit të jashtëm. Ky është një kufizim i detyrueshëm për aksesin e testuesit të QA dhe e bën testimin e kutisë gri pa pasur zgjedhje.
2. Kur nuk keni nevojë të bëni testimin e kutisë gri
Ka disa herë në procesin e testimit që testimi i kutisë gri nuk është i nevojshëm, e para prej të cilave është në fillim të procesit të zhvillimit.
Testimi funksional bëhet kur zhvilluesit fillimisht testojnë për t’u siguruar që kodi i tyre plotëson detyrat e tij më themelore, gjë që ka transparencë të plotë. Duke qenë se nuk ka asnjë kod ose dokumentacion të fshehur nga testuesi, ky nuk konsiderohet testim i kutisë gri.
Një herë tjetër që nuk keni nevojë për testimin e kutisë gri është kur testoni në fund të zhvillimit kur keni një produkt të plotë. Ky është rasti kur ju ndihmoni përdoruesin fundor me testimin dhe njihet gjithashtu si “testimi beta” ose ” testimi nga fundi në fund “.
Përdoruesit e testojnë aplikacionin pa asnjë akses në kodin ose dokumentet e dizajnit, në vend të kësaj e marrin softuerin sipas meritave të veta. Kjo është një formë e testimit të kutisë së zezë pasi procesi është plotësisht i errët.
3. Kush është i përfshirë në testimin e kutisë gri?
Ka disa njerëz dhe role me përfshirje në testimin e kutisë gri, me disa nga rolet më të rëndësishme në proces duke përfshirë:
· Menaxher i SC:
Një menaxher SC, ose menaxher i sigurimit të cilësisë, është një anëtar i stafit në procesin e zhvillimit të softuerit që është përgjegjës për caktimin e detyrave për ekipin e testimit.
Kjo përfshin krijimin e rrotullimeve, shqyrtimin e raporteve dhe trajtimin e konflikteve që lindin në ekip.
· Testues:
Një testues është një profesionist përgjegjës për plotësimin e rasteve të testimit që janë pjesë e procesit të testimit të kutisë gri.
Kjo kërkon një nivel të lartë vëmendjeje ndaj detajeve kur shkruani raporte dhe kaloni vazhdimisht nëpër raste të sakta testimi.
· Zhvilluesi:
Zhvilluesit janë profesionistët përgjegjës për krijimin e kodit dhe rregullimin e tij në varësi të rezultateve të testimit të kutisë gri.
Ndërsa këta nuk përfshihen domosdoshmërisht në vetë testimin, ata marrin komunikime nga testuesit në lidhje me rezultatet.
· Analist i SC:
Roli i analistit të QA është i zakonshëm në proceset e testimit që përdorin shumë automatizim. Një analist shkruan kodin e rastit të testimit për testet automatike përveç analizimit të të dhënave që testet kthehen në fund të procesit.
Përfitimet e testimit të kutisë gri
Ka disa përfitime kryesore të përdorimit të testimit të kutisë gri gjatë ekzaminimit të softuerit. Duke shfrytëzuar maksimalisht këto avantazhe, ju përmirësoni standardin e aplikacionit tuaj me kalimin e kohës.
Disa nga arsyet pse kompanitë përdorin këtë formë testimi përfshijnë:
1. Njohja e mekanizmave të brendshëm ndihmon në hartimin e testeve
Një nga përfitimet kryesore të përdorimit të testimit të kutisë gri në vendin e punës është fakti që ju dini për disa nga mekanizmat e brendshëm në aplikacion. Kjo përfshin të kuptuarit se çfarë bën secili prej funksioneve dhe cilat janë module të disponueshme në krahasim me kodin e shkruar me porosi për disa nga veçoritë e tjera.
Njohja për funksionalitetin e brendshëm do të thotë që një testues e kupton më mirë atë që po teston dhe mund t’i synojë këto teste në dizajnin e aplikacionit. Kompanitë marrin rezultate më të sakta që përfaqësojnë siç duhet softuerin.
2. Rezulton në zgjidhjen e menjëhershme të çështjeve
Në disa raste, kur shfaqet një problem në një test dhe testuesi ka akses në kodin që qëndron pas problemit, mund të ketë një zgjidhje të menjëhershme për problemin.
Kjo është në kundërshtim me një metodologji të testimit të kutisë së zezë, në të cilën testuesit nuk mund të shohin asnjë nga kodet prapa skenave të softuerit që po ekzaminojnë. Duke parë kodin, testuesit me shumë përvojë zhvillimi mund t’i tregojnë zhvilluesit se çfarë saktësisht është çështja dhe si mund ta zgjidhë atë një përditësim i ardhshëm.
Testimi i kutisë gri kursen shumë kohë që përndryshe do të shpenzohej për hetimin e çështjeve dhe i ndihmon kompanitë të kalojnë kohën e tyre në mënyrë më efikase.
3. Ndan testuesit dhe zhvilluesit
Përdorimi i testimit të kutisë gri lë një ndarje të qartë midis zhvilluesve të aplikacionit dhe njerëzve që testojnë softuerin.
Kjo për shkak se përfundimi i testimit të kutisë gri mbështetet në testuesit që nuk kanë njohuri ekzistuese për mënyrën se si funksionon softueri, me distancën midis të dyve duke u bërë një domosdoshmëri për rezultate më të sakta të testit që nuk ndikohen nga paragjykimi.
Testuesit në skenarët e kutisë gri janë në një ekip krejtësisht të ndryshëm nga zhvilluesit, duke ofruar informacion të saktë pa ndonjë pamje ekzistuese që ndikon në prodhimin e tyre.
Zhvilluesit gjithashtu përfitojnë nga kjo pasi marrin një perspektivë më kritike të punës së tyre, duke i ndihmuar ata të përmirësojnë si aplikacionin ekzistues ashtu edhe aftësitë e tyre për të ardhmen.
Sfidat e testimit të kutisë gri
Ka disa pengesa kryesore për përdorimin e testimit të kutisë gri në punën tuaj të zhvillimit.
Duke kuptuar këto të meta dhe duke punuar për t’i zbutur ato kudo që të jetë e mundur, ju rritni standardin e përgjithshëm të punës suaj në fund të fazës së SC .
Disa nga të metat kryesore të testimit të kutisë gri përfshijnë:
1. Potenciali që kodi të mos shihet
Testimi i kutisë gri do të thotë se ka disa aspekte të kodit që janë të fshehura nga testuesi dhe në rast të ndonjë problemi që lind në test, kjo mund të çojë në probleme të mëtejshme.
Me kodin e padukshëm, anëtarët e stafit të përfshirë në testim, të dy përpiqen të drejtojnë testet e tyre për të shfrytëzuar sa më shumë aplikacionin dhe humbasin përfitimin e shikimit të shkakut të një problemi menjëherë.
Procesi i rregullimit të gabimeve bëhet më i turbullt, duke çuar në kohë më të gjata të përditësimit duke u bërë një domosdoshmëri dhe kompanitë përpiqen të gjejnë problemet në kodin e tyre.
Produktet përfundimtare mund të jenë më të dëmshme dhe të një standardi më të ulët si rezultat i këtij kodi të padukshëm.
2. Testet mund të jenë të pasakta nëse operacionet dështojnë
Të kesh teste të sakta është një domosdoshmëri në çdo formë të testimit të softuerit, me një shkallë më të lartë saktësie që i drejton ekipet drejt përditësimeve që ata mund të plotësojnë në versionet e ardhshme, përveçse ndihmon një ekip zhvillimi që të jetë më i sigurt në produktet e tyre.
Kjo saktësi zvogëlohet kur operacionet dështojnë në testimin e kutisë gri. Testuesit thjesht marrin një mesazh “Operacioni dështoi” nga softueri nëse nuk kanë qasje në kod, duke i penguar ata të ofrojnë ndonjë reagim për mënyrën se si funksionon.
Për të marrë metrika të dobishme, zhvilluesit duhet të rregullojnë softuerin përpara fazës tjetër të testimit. Përndryshe, gjithçka që mund të bëjë një testues është të deklarojë se funksioni nuk funksionon në formën e tij aktuale.
3. Lufton me sistemet e shpërndara
Sistemet e shpërndara i referohen sistemeve softuerike që strehohen në disa vende të ndryshme, ose që mbështeten në veçori të tilla si të dhënat e strehuara në renë kompjuterike dhe shërbimet e përpunimit.
Kjo e bën testimin jashtëzakonisht të vështirë, pasi ekziston një pjesë e konsiderueshme e softuerit që fshihet pas një trupi të palës së tretë me testuesit që thjesht marrin një rezultat nga një proces i panjohur.
Kur shfaqen probleme me softuerin që përdor sisteme të palëve të treta, mund të jetë e vështirë të përcaktohet nëse problemi është me vetë aplikacionin, funksionalitetin e palës së tretë ose mënyrën se si të dyja integrohen, veçanërisht kur një testues mundet’ mos e shihni kodin ashtu siç funksionon.
Karakteristikat e testeve të kutisë gri
Ka disa karakteristika që testet e kutisë gri ndajnë me njëri-tjetrin, me njohjen e këtyre testeve që ju ndihmon të përgatisni një strategji për organizatën tuaj.
Disa nga shembujt kryesorë të karakteristikave të testit të kutisë gri, përveç se si këto karakteristika janë pjesë të rëndësishme të procesit të testimit të kutisë gri, përfshijnë:
· Mbulim i rritur:
Qasja në disa nga kodi burim ofron një shkallë më të madhe mbulimi në teste, me detaje të mëtejshme që ofrojnë gjetje më të saktë të gabimeve.
· Rrjedhat e të dhënave:
Shumë teste të kutisë gri theksojnë rrjedhën e të dhënave dhe të kuptuarit se si lëviz informacioni nëpër një sistem.
· Jo algoritmike:
Testimi i kutisë gri nuk funksionon kur ekzaminohen algoritmet, pasi ky është një nivel tjetër i turbullimit të kodit.
Çfarë testojmë në testet e kutisë gri?
Çdo lloj i ndryshëm testimi shërbehet më së miri kur synoni pjesë të veçanta të softuerit në fjalë. E njëjta gjë vlen edhe për testimin e kutisë gri, me metodologjinë që është më e dobishme në disa pjesë të veçanta të një aplikacioni.
Disa shembuj të asaj që vlerësojnë testuesit kur plotësojnë testet e kutisë gri përfshijnë:
1. Siguria e aplikacionit
Testet e kutisë gri janë ideale për testet e depërtimit që shqyrtojnë sigurinë e një aplikacioni. Testuesit mund të shohin të gjithë kodin dhe të kërkojnë dobësi të mundshme në proces.
Hakerët etikë janë testues idealë për testimin e sigurisë së aplikacioneve, pasi ata njohin dobësitë dhe të metat e mundshme në softuer më natyrshëm sesa ata që nuk kanë përvojë në shkeljen e sigurisë së softuerit.
2. Testimi i bazës së të dhënave
Shumë kompani përdorin testimin e kutisë gri për testimin e bazës së të dhënave pasi mund të gjurmoni të dhënat përmes secilit nënfunksion në softuer.
Testuesit mund të shohin të gjitha ndryshimet që bën softueri dhe të vlerësojnë nëse ato janë të sakta.
Ky është një zbatim i dobishëm i testimit të kutisë gri pasi testet e bazës së të dhënave janë të parashikueshme nga natyra e tyre, me kompanitë që përdorin bazat e të dhënave për të organizuar informacionin ekzistues në vend që të gjenerojnë të dhëna të reja.
3. Ueb aplikacionet
Aplikacionet në ueb përfitojnë nga përdorimi i testimit të kutisë gri për shkak të shkathtësisë së metodës së testimit.
Testet e kutisë gri mund të përdoren për sigurinë, bazën e të dhënave, integrimin , UI dhe testimin e shfletuesit, secila prej të cilave janë aspekte kryesore të aplikacioneve në internet .
Nuk ka nevojë për të ndryshuar metodologjitë e testimit, në mënyrë që të përfitoni nga një nivel më i madh vazhdimësie.
Pastrimi i një konfuzioni:
Testimi i kutisë gri kundër kutisë së bardhë kundër kutisë së zezë
Testimi i kutisë gri është një formë testimi e ngjashme me testimin e kutisë së bardhë dhe të kutisë së zezë, që do të thotë se ka shumë potencial për konfuzion midis metodologjive.
Zbuloni më shumë rreth asaj se çfarë janë testimi i kutisë së bardhë dhe të zezë dhe disa nga ndryshimet themelore midis këtyre dhe testimit të kutisë gri në zhvillimin e softuerit:
1. Çfarë është Testimi i Kutisë së Bardhë?
Testimi i kutisë së bardhë është një formë e testimit të aplikacionit që i siguron testuesit informacion të plotë rreth aplikacionit.
Kjo përfshin aksesin e plotë në kodin burimor dhe të gjitha dokumentet e projektimit të softuerit, gjë që i siguron testuesit një kuptim shumë më të mirë të mënyrës se si funksionon softueri.
Testuesit e përdorin këtë kuptim për të parë më shumë nga problemet që janë të pranishme në aplikacion, duke raportuar një perspektivë më të saktë se si funksionon aplikacioni për përdoruesit.
Një shembull i përdorimit të testimit të kutisë së bardhë është të shohësh rrjedhën e një futjeje specifike të të dhënave përmes një aplikacioni për të parë se ku ndodh një problem në proceset e aplikacionit, në vend që thjesht të shohësh nëse ka një problem apo jo.
Ka disa raste në proceset e zhvillimit kur kompanitë përdorin testimin e kutisë së bardhë.
E para nga këto është kur përfundoni testimin e njësisë , i cili vlerëson nëse çdo pjesë individuale e kodit ose modulit në një paketë softuerike bën punën që pret zhvilluesi.
Testimi i njësisë i ndihmon testuesit të gjejnë shumicën e problemeve në një aplikacion, pasi shqyrton të gjithë funksionalitetin në aplikacion.
Testimi i kutisë së bardhë gjithashtu ndihmon në gjetjen e rrjedhjeve të kujtesës. Duke ekzaminuar të gjithë kodin në detaje, një analist i QA gjen se ku aplikacioni po përdor kujtesën e një pajisjeje dhe zonat e mundshme ku po përdor shumë.
Kjo ndihmon që aplikacioni të funksionojë më shpejt dhe me efikasitet në përsëritjet e ardhshme pasi rrjedhja e kujtesës merr një rregullim sa më shpejt të jetë e mundur.
Cilat janë ndryshimet midis testeve të kutisë gri dhe kutisë së bardhë?
Ekzistojnë disa dallime të mëdha midis testeve të kutisë së bardhë dhe kutisë gri, me nivelin e informacionit në të cilin dikush ka akses është ndryshimi i parë.
Testimi i kutisë së bardhë ka akses të plotë në kodin burimor dhe dokumentet e projektimit për programin, ndërsa testimi i kutisë gri ka vetëm akses të pjesshëm në disa nga këto informacione, kryesisht dokumentet e dizajnit.
Ky ndryshim do të thotë se ka gjithashtu një ndryshim në njerëzit që përfundojnë testet, me vetë zhvilluesit që janë kryesisht përgjegjës për testimin e kutisë së bardhë.
Testimi i kutisë gri, nga ana tjetër, është përgjegjësi e një ekipi të QA, pasi testuesit nuk mund të kenë një njohuri intime të kodit.
Testimi i kutisë gri kërkon gjithashtu më pak kohë sesa testimi i kutisë së bardhë. Testimi i kutisë së bardhë është nga fundi në fund dhe shqyrton si anën e përdoruesit të softuerit ashtu edhe vetë kodin. Kjo kërkon shumë më shumë kohë për t’u përfunduar dhe do të thotë që një proces testimi i kutisë gri është një mënyrë shumë më e shpejtë përpara.
Kutia e bardhë ka më shumë potencial për automatizim, megjithatë, pasi testuesit e dinë mënyrën se si funksionon kodi i brendshëm.
2. Çfarë është testimi i kutisë së zezë?
Testimi i kutisë së zezë i referohet kur një testues ekzaminon një paketë softuerike pa pasur ndonjë kuptim ekzistues të mënyrës se si funksionon sistemi.
Kjo do të thotë të mos kesh akses në asnjë nga kodet që është pjesë e aplikacionit ose ndonjë nga dokumentet e projektimit ose përmbledhjet që janë në dispozicion. Testuesit thjesht kanë një listë të veçorive që po testojnë dhe një sërë rastesh testimi për të përfunduar.
Një shembull i testimit të kutisë së zezë është testimi nga fundi në fund, në të cilin një testues merr paketën e plotë të softuerit dhe teston të gjithë aplikacionin për t’u siguruar që funksionaliteti funksionon siç është projektuar.
Shumica e rasteve ideale të testimit për testimin e kutisë së zezë janë ato drejt fundit të një procesi dhe që përfshijnë klientët dhe këndvështrimin e tyre për një produkt, me mungesë aksesi në kod që parandalon çdo paragjykim që ndikon në pamjen e përdoruesit.
Kompanitë përdorin testimin e kutisë së zezë kryesisht pasi të ketë përfunduar i gjithë testimi i funksionit në një aplikacion. Me të gjithë testimin e njësisë dhe testimin e funksionit të përfunduar, zhvilluesit e kuptojnë se aplikacioni funksionon ashtu siç ata presin, të paktën me të gjitha modulet që punojnë të izoluar.
Testimi i kutisë së zezë siguron që aplikacioni i përgjithshëm të funksionojë siç pritej pasi të përpilohet, me të gjithë kodin burimor që teorikisht është tashmë në rregull.
Cilat janë ndryshimet midis testimit të kutisë gri dhe kutisë së zezë?
Dallimi kryesor midis testimit të kutisë gri dhe kutisë së zezë është sasia e aksesit që një testues merr në informacion.
Në disa raste, një testues i kutisë së zezë mund t’i qaset aplikacionit pa pasur fare njohuri paraprake për softuerin, thjesht duke kaluar procesin e testimit dhe duke përdorur softuerin si një përdorues standard.
Nga ana tjetër, një testues i kutisë gri ka akses në disa nga dokumentet e projektimit dhe kështu mund të krahasojë atë që duhet të bëjë aplikacioni me performancën e tij reale, duke u ofruar zhvilluesve komente se cilat pjesë specifike të aplikacionit nuk janë në përputhje me standardin.
Një tjetër ndryshim është sasia e kohës që duhet për të zgjidhur një problem, me testet e kutisë gri që marrin pak më shumë kohë.
Ndërlidhja e dokumentacionit dhe kodit me mënyrën se si e përjetoni aplikacionin mund të marrë pak kohë, gjë që është në kundërshtim me mënyrën se si funksionojnë testuesit e kutisë së zezë duke ekzaminuar thjesht vetë aplikacionin së bashku me çdo problem funksionaliteti. Ky kombinim e bën testimin e kutisë së zezë një proces ideal për t’u përdorur menjëherë në fund të një procesi zhvillimi kur përgatiteni për lëshimin e produktit, me kutinë gri që funksionon më mirë kur jeni në fazën e zhvillimit të ndërfaqes së përdoruesit dhe përpilimit të zhvillimit.
3. Përfundim: Testimi i kutisë gri kundër kutisë së bardhë kundër kutisë së zezë
Si përfundim, testimi i kutisë së bardhë, kutisë gri dhe kutisë së zezë janë të gjitha pjesë e të njëjtit spektër, në të cilin faktori i ndryshëm është niveli i aksesit që ka një testues gjatë gjithë procesit.
Ndërsa një formular testimi bëhet më “i zi”, testimi bëhet gjithnjë e më i errët me aksesin në informacionin pas softuerit është i kufizuar.
Testimi i kutisë së bardhë është ideal për fazat më të hershme të procesit, me testimin e kutisë së zezë që shkëlqen për faza të tilla si testimi nga fundi në fund i cili shqyrton të gjithë aplikacionin nga këndvështrimi i përdoruesit.
Testimi i kutisë gri vepron si një terren i mesëm midis dy koncepteve, duke ndihmuar në gjetjen e problemeve gjatë mesit të procesit të zhvillimit duke ofruar një pasqyrë më të madhe, ndërkohë që ende mban një pjesë të kodit burimor të fshehur nga testuesi.
Teknikat e testimit të kutisë gri
Testimi i kutisë gri përfshin një gamë të gjerë teknikash, secila prej të cilave rrit standardin e testimit, gjen më shumë gabime për zhvilluesin dhe çon në një produkt më të plotë në fund të procesit.
Disa nga teknikat më të zakonshme të testimit të kutisë gri që përdorin ekipet e QA përfshijnë:
1. Testimi i matricës
Testimi i matricës shqyrton raportin e statusit të projektit që është në proces. Kjo përfshin një gjendje të thjeshtë PASS/FAIL në disa raste, me procese të vazhdueshme që ofrojnë më shumë detaje se si proceset funksionojnë vazhdimisht.
Aty ku shumë testime fokusohen në hyrjet dhe daljet e një pjese të kodit, testimi i matricës shqyrton statusin e vetë proceseve sesa rezultatet e proceseve të përmendura.
Përdorimi i testimit të matricës siguron një fokus më të madh në vetë aplikacionin, duke ndihmuar në gjetjen e gabimeve dhe problemeve edhe nëse rezultatet duken të sakta.
2. Testimi i regresionit
Testimi i regresionit ekziston për të testuar softuerin pas një serie përditësimesh. Kjo përfshin teste funksionale dhe jofunksionale të cilat sigurojnë që aplikacioni të funksionojë ende në një standard mjaft të lartë ndërsa kodi ndryshon.
Testuesit që përdorin testimin e regresionit zakonisht përdorin automatizimin, pasi testet e regresionit rriten në shtrirje pasi gjithnjë e më shumë defekte gjenden nga ekipi i sigurimit të cilësisë.
Testimi manual është një domosdoshmëri në disa raste, megjithatë, me kompanitë që po testojnë ndërfaqen e përdoruesit duke përdorur teste manuale për të parë se si një përdorues njerëzor reagon ndaj ndryshimeve të bëra në menutë, butonat dhe opsionet e navigimit.
3. Testimi i modelit
Testimi i modelit është një formë testimi që fokusohet në ndjekjen e një modeli specifik në çdo test që një organizatë përfundon.
Ekipet e testimit i projektojnë këto teste për të synuar çdo veçori të softuerit, ku çdo pjesë e testit ofron një nivel të qëndrueshëm informacioni për kompaninë në lidhje me mënyrën se si funksionojnë veçoritë individuale.
Përdorimi i testimit të modelit ndonjëherë mbështetet në modifikimin e modelit me kalimin e kohës për t’u siguruar që ju të gjykoni secilin prej sistemeve që janë në punë, por pasi të keni një model që funksionon, shmangni devijimet për të siguruar më shumë qëndrueshmëri në rezultatet tuaja.
4. Testimi i vargut ortogonal
Testimi i grupit ortogonal është kryesisht një teknikë testimi e orientuar nga kutia e zezë që ndodh kur testuesit përdorin një numër të konsiderueshëm hyrjesh që është shumë i madh për të testuar në mënyrë shteruese çdo sistem të vetëm në proces.
Në këto raste, çdo pjesë individuale e të dhënave ofron informacionin e vet unik për shkak të mungesës së mundshme të korrelacionit midis pjesëve specifike të informacionit. Ky është aspekti ortogonal i sistemit, me pjesë unike të informacionit që përdoren për të siguruar nivelin maksimal të të dhënave duke shpenzuar përpjekje minimale.
Koha e testimit zvogëlohet dhe ju keni një bilanc ideal të të dhënave për t’i ofruar një ekipi zhvillimi.
Testimi i kutisë gri në ciklin jetësor të inxhinierisë softuerike
Testimi i kutisë gri bie në një fazë specifike të ciklit jetësor të inxhinierisë softuerike. Ky cikël jetësor është një seri e ndërlikuar hapash që kompanitë ndjekin kur zhvillojnë produktet e tyre, me çdo hap që çon në një standard më të lartë produkti.
Ndërsa testimi është një pjesë e procesit që ndodh vazhdimisht, ka një kohë shumë të kufizuar për testimin e kutisë gri.
Kjo ndodh pasi funksionaliteti fillestar është i plotë dhe i testuar përmes testimit të kutisë së bardhë dhe përpara se softueri të jetë gati për publikim, me kompanitë që preferojnë testimin e kutisë së zezë në fazat më të fundit.
Kutia gri është mjeti i përsosur për të integruar veçoritë së bashku dhe për të siguruar që ato të funksionojnë siç duhet së bashku, përveç në mënyrë të pavarur.
Testet manuale apo të automatizuara të kutisë gri?
Ashtu si me çdo formë të testimit të softuerit, ekipet e sigurimit të cilësisë zgjedhin midis përfundimit të testimit të tyre manualisht nëpërmjet përdorimit të anëtarëve ekspertë të stafit ose automatikisht, që përfshin kodimin e një sërë rastesh testimi dhe plotësimin e tyre në mënyrë të përsëritur për të siguruar një grup të saktë rezultatesh.
Mësoni më shumë rreth testimit manual dhe të automatizuar, me disa nga përfitimet dhe sfidat e secilit, përveç se cila nga dy format e testimit është ideale për një kompani që kërkon të kuptojë më mirë problemet me produktin e saj.
Testimi manual i kutisë gri – Përfitimet, Sfidat, Procesi
Testimi manual është një pjesë themelore e shumë llojeve të testimit, duke përfshirë testimin e kutisë gri.
Ky proces përfshin marrjen e testuesve njerëzorë për të ekzaminuar një pjesë të softuerit, duke shqyrtuar nëse softueri funksionon ashtu siç prisni dhe duke e krahasuar atë me dokumentet para-ekzistuese të projektimit dhe kodin që është i dukshëm për të kontrolluar nëse ka ndonjë të metë të dukshme në këtë informacion që mund të shkaktojnë probleme.
Rastet në të cilat testimi manual është i zakonshëm përfshijnë pjesë më të komplikuara të softuerit që kërkojnë që një qenie njerëzore të sigurojë njohuri cilësore.
Përdorime të tjera përfshijnë kompani më të vogla që kërkojnë të vlerësojnë plotësisht softuerin e tyre, pasi aplikacionet dhe paketat e vogla kërkojnë relativisht pak burime për kompanitë për t’u vlerësuar në krahasim me programet më të mëdha të prodhuara nga bizneset më të mëdha.
1. Përfitimet e testimit manual të kutisë gri
Ka disa përfitime të testimit manual të kutisë gri për çdo pjesë të softuerit. Njohja e këtyre përfitimeve do të thotë që ju mund të synoni testimin tuaj drejt tyre, duke zbuluar më shumë probleme në softuerin tuaj dhe duke rritur standardin e punës suaj falë një regjimi më të mirë testimi.
Përfitimet kryesore të testimit manual të kutisë gri janë:
Reagime të hollësishme
Përfitimi i parë kryesor i përdorimit të testimit manual të kutisë gri është se testuesit njerëzorë mund të ofrojnë një nivel të konsiderueshëm reagimesh për zhvilluesit.
Kur përdorni testimin e automatizuar, rastet e provës janë krijuar për të prodhuar metrikë shumë specifikë herë pas here që u japin analistëve njohuri kur ata kanë kohë për të vlerësuar të dhënat.
Kjo është disi e ndryshme kur përdorni testimin manual, pasi një testues mund të japë një reagim më të plotë mbi atë veçori specifike që nuk funksionoi dhe arsyet e mundshme për problemin pasi ta krahasojë atë me dokumentacionin e projektimit.
Përdorimi i udhëzuesve të detajuar të komenteve jo vetëm për përditësimet mbi veçoritë ekzistuese, por veçoritë e reja të mundshme që një testues u rekomandon përdoruesve.
Interpretime më të mira
Testimi i automatizuar do të thotë që çdo përfundim është një çështje e vlerësimit të të dhënave që merrni nga një test dhe arritjes së një zbritjeje racionale rreth asaj që do të thotë kjo për softuerin.
Përkundrazi, testuesit manualë kanë një nivel shumë më të madh të njohurive në mënyrën se si funksionon vetë aplikacioni.
Ata mund të krahasojnë kodin e kutisë gri me atë që po ndodh në kohë reale, duke bërë një vlerësim të saktë në atë moment në vend që të duhet të bëjnë zbritje pas faktit.
Disa platforma automatizimi mund të funksionojnë në mënyrë të ngjashme duke pasur një veçori riprodhimi, por kjo ende kërkon ndërhyrje manuale.
Testim fleksibël
Automatizimi i testimit përfshin kodimin e rasteve testuese shumë specifike në një platformë, që do të thotë se softueri e plotëson atë grup specifik detyrash përsëri dhe përsëri.
Ndërsa kjo është ideale për përsëritje, ajo paraqet një sfidë unike në atë që nuk ka fleksibilitet në testim.
Përdorimi i një testuesi njerëzor është ideal në këto raste, duke i shtuar më shumë fleksibilitet procesit. Nëse një testues njerëzor vëren një problem të mundshëm që është paksa jashtë një rasti testimi të përcaktuar ngushtë, ai mund ta ekzaminojë atë dhe të raportojë rezultatet në fund të procesit.
Kjo u siguron kompanive një mbulim më të plotë të softuerit, duke zbuluar gabime që një sistem i automatizuar nuk mundet.
2. Sfidat e testimit manual të kutisë gri
Përderisa ka shumë përparësi për të përdorur testimin manual në procesin e zhvillimit të softuerit tuaj, ka edhe disa disavantazhe. Këto ndryshojnë në varësi të disa faktorëve, duke përfshirë softuerin specifik me të cilin po punon kompania, madhësinë e ekipit të zhvillimit dhe standardin e aftësive që kanë anëtarët e ekipeve të testimit dhe zhvillimit.
Sfidat e rëndësishme në testimin manual përfshijnë:
Kostot e larta të punës
Kostot e punës janë disa nga shpenzimet më të rëndësishme që çdo kompani kalon, pasi ajo paguan për të marrë stafin më të mirë në dispozicion, në mënyrë që kompania të përmirësojë standardin e punës së saj.
Meqenëse testimi manual i kutisë gri mund të marrë shumë kohë, kompania duhet të paguajë testuesit e saj për të punuar gjatë gjithë procesit. Për disa nga aplikacionet më të mëdha, kjo mund të zgjasë me orë të tëra dhe të bëjë që kostoja e testuesve manualë të rritet.
Zhvilluesit mund të kërkojnë ta zbusin këtë problem duke balancuar automatizimin e testimit të kutisë gri me testimin manual ose duke ulur kostot e punës për orë, por kjo rrezikon një rënie të cilësisë së testimit.
Gabim njerëzor
Testimi i automatizuar përfundon proceset e thjeshta në mënyrë efektive, duke i përsëritur ato me një shkallë të lartë saktësie në një mënyrë që një person nuk mundet.
Qeniet njerëzore bëjnë gabime dhe gabime të vogla, të cilat mund të jenë rezultat i çdo gjëje, nga shtypja aksidentale e butonit të gabuar deri tek rrëshqitja e vëmendjes së tyre për disa sekonda.
Gabimet si ky mund të çojnë në të dhëna të pasakta dhe të bëjnë që zhvilluesit të përqendrojnë vëmendjen e tyre në pjesën e gabuar të softuerit, duke marrë kohën e çmuar të zhvillimit dhe duke përkeqësuar produktin.
Kërkoni ta zgjidhni këtë duke plotësuar testet e përsëritura të kutisë gri kudo që të jetë e mundur për të verifikuar rezultatet tuaja ndërsa testimi vazhdon.
Merr shumë kohë
Aty ku kompjuterët mund të kryejnë detyra në një çast, njerëzve u duhet pak më shumë kohë.
Kjo është për shkak të çdo gjëje, nga koha e reagimit deri tek puna më e ngadaltë sesa shpejtësia e tyre optimale në pika, të cilat të gjitha ngadalësojnë procesin e testimit.
Një proces më i ngadalshëm i testimit do të thotë më pak kohë për ekipet e zhvillimit për të punuar në eliminimin e gabimeve dhe të metave nga produkti, pasi e gjithë koha shkon drejt gjetjes së problemeve në radhë të parë.
Kjo nuk është diçka që është e lehtë për t’u zbutur, me një regjim testimi hibrid si balancimi i testeve manuale me testet e automatizuara të kutisë gri që është një zgjidhje e mundshme.
Automatizimi i testit të kutisë gri – Përfitimet, Sfidat, Procesi
Automatizimi i testimit i referohet procesit të përdorimit të një platforme automatizimi për të bërë automatike disa nga pjesët e procesit të testimit të kutisë gri.
Procesi funksionon duke kërkuar nga projektuesit e testeve të krijojnë një sërë rastesh testimi me analistë të QA ose profesionistë të ngjashëm që kodojnë këto teste në programet e automatizimit, me disa që përdorin automatizimin e procesit robotik si një mjet tjetër.
Në këto raste, analistët e QA tashmë i kuptojnë disa nga kodet ose dokumentet e projektimit.
Ky lloj testimi është më i zakonshëm në paketat softuerike shumë më të mëdha, pasi testuesit e kutisë gri nuk kanë kohë për të testuar plotësisht të gjitha aspektet e procesit me dorë.
Pas një procesi të automatizuar, platforma kthen një raport për analistin e QA, duke vënë në dukje se ku ka dështime dhe një sërë metrikash të rëndësishme.
1. Përfitimet e testimit të automatizuar të kutisë gri
Ka disa përfitime të qarta të përdorimit të testimit të automatizuar të kutisë gri në proceset e një ekipi të sigurimit të cilësisë.
Duke u fokusuar në këto përfitime dhe duke i shfrytëzuar sa më shumë prej tyre, një kompani mund të rrisë efektivitetin e testimit të kutisë së saj gri dhe të zgjidhë sa më shumë probleme të jetë e mundur në këtë fazë të rrjedhës së punës.
Disa nga përfitimet kryesore të përdorimit të automatizimit në punën tuaj të testimit të kutisë gri përfshijnë:
Testim i shpejtë
Sistemet e automatizuara janë krijuar për të testuar jashtëzakonisht shpejt, duke kaluar nëpër një sërë procesesh sa më shpejt që të jetë e mundur. Ky përfitim bëhet edhe më i dukshëm kur plotësohen testet e përsëritura të kutisë gri, pasi çdo vrapim individual kërkon më pak kohë.
Sasia e kohës që kurseni nga ekzekutimi në ekzekutim rritet ndjeshëm, me kompaninë tuaj që ka shumë më tepër kohë për të kryer detyra të ngutshme, si përditësimi i vetë softuerit dhe ofrimi i reagimeve për klientët dhe klientët e mundshëm.
Testimi më i shpejtë është veçanërisht i dobishëm kur punoni pas publikimit, pasi shtytja e rregullimeve të funksionalitetit sa më shpejt të jetë e mundur është një domosdoshmëri për të përmirësuar mënyrën se si njerëzit e shohin biznesin.
Metrikë të saktë
Metrikat janë një pjesë e rëndësishme e mënyrës se si funksionon testimi i softuerit, duke siguruar informacion numerik për një testues për të treguar problemet e mundshme.
Kompjuterët dhe platformat e automatizimit ofrojnë matje shumë të sakta, me gjëra të tilla si koha e përgjigjes që matet deri në milisekondë.
Të kesh matje më të sakta do të thotë që mund të gjurmosh ndërrime të vogla në mënyrën se si funksionon një aplikacion, duke të ndihmuar të kuptosh nëse një përditësim ka përmirësuar performancën ose ka çuar në rrjedhat standarde të punës që kërkojnë më shumë kohë.
Kostot e reduktuara
Një nga kostot më të mëdha të testimit në një mjedis të zhvillimit të kutisë gri të softuerit është ajo e vetë testuesve të kutisë gri.
Punësimi i ekspertëve të testimit të softuerit është i shtrenjtë, veçanërisht kur jeni duke kërkuar për testues të kutive gri, të cilat kërkojnë një larmi më të madhe aftësish, për të ofruar standardet më të larta të mundshme për organizatën tuaj.
Automatizimi do të thotë që ka më pak njerëz që kryejnë teste manuale të kutisë gri, duke eliminuar shumë kosto të personelit nga procesi.
Përderisa platformat e automatizimit kanë disa kosto, shumica e të cilave paguajnë një abonim në baza mujore, kjo është shumë më e ulët se sa duhet të paguani që punonjësit të bëjnë punën për ju.
2. Sfidat e testimit të automatizuar të kutisë gri
Ka shumë sfida për përdorimin e automatizimit në proceset e testimit të kutisë tuaj gri.
Ndërsa disa organizata fokusohen në përfitimet, ka shumë përparësi për të njohur sfidat e testimit të kutisë gri dhe për t’i konsideruar ato ndërsa punoni.
Ju mund të zbatoni testimin e kutisë gri në një mënyrë që shmang sfidat dhe ju pengon të luftoni me kufizimet në vazhdim.
Sfidat kryesore të testimit të automatizuar të kutisë gri janë:
Konfigurimi fillestar
Konfigurimi fillestar është një nga sfidat më të mëdha të kalimit të procesit të automatizimit. Kjo i referohet kohës që duhet për të kaluar në një platformë të re testimi, duke përfshirë instalimin e platformës, mësimin e përdoruesve se si të angazhohen me të dhe kodimin e testeve të hershme në softuer.
E gjithë kjo është kohë joproduktive që një kompani do të dëshirojë ta kufizojë sa më shumë që të jetë e mundur.
Përdorimi i softuerit premium të automatizimit me ekspertë në dispozicion kur ju nevojitet është ideal në këtë rast, pasi keni mbështetje nga palët e treta duke u siguruar që automatizimi i kutisë tuaj gri dhe llojet e tjera të testimit për këtë çështje, të shkojnë pa probleme që në fillim.
Kërkesa të larta për aftësi
Megjithëse testimi manual kërkon nivele të larta aftësish, analistët e QA që punojnë me automatizimin duhet ende të kenë një nivel të lartë aftësie.
Kjo vjen në formën e aftësive të kodimit, të cilat përdoren kryesisht për të krijuar raste testimi dhe për të lexuar kodin që është i disponueshëm në skenarin e kutisë gri.
Zhvilluesit mund ta zbusin këtë duke punësuar posaçërisht testues që kanë përvojë zhvillimi ose kanë punuar me projekte kodimi në të kaluarën. Ju kufizoni kohën e trajnimit në vendin e punës dhe siguroni që çdo punësim i ri të ketë kapacitetin për t’u përshtatur me kërkesat e testimit të automatizuar të kutisë gri.
Disa kompani synojnë të përdorin një sistem automatizimi pa kod për të kryer testimin e kutisë gri si një alternativë, por kjo mund të çojë në më pak fleksibilitet në vendin e punës.
Mbikëqyrja e vazhdueshme
Testimi i automatizuar ekziston pjesërisht për të hequr theksin nga mbështetja te njerëzit, me testimin manual që ka përfshirje të vazhdueshme njerëzore në procese.
Ky nuk është menduar të jetë rasti me automatizimin e testeve, por kompanitë ende duhet të kenë një nivel të mirë mbikëqyrjeje.
Mbikëqyrja përfshin ekzaminimin e rezultateve të testeve të kutisë gri dhe mirëmbajtjen e tyre për t’u siguruar që gjithçka funksionon ende ashtu siç pret zhvilluesi.
Kompanitë mund të ndihmojnë në përmirësimin e standardit të mbikëqyrjes së disponueshme në disa mënyra, me një profesionist të vetëm përgjegjës për mbikëqyrjen e testeve duke qenë ideale.
Kjo çon në një nivel më të madh specializimi, me atë anëtar të stafit që bëhet një testues ekspert i kutisë gri në punën me automatizimin më shpejt dhe më efektivisht.
Përfundim: Automatizimi i testit manual apo i kutisë gri?
Si përfundim, testimi manual i kutisë gri dhe testimi i automatizuar kanë të dyja vendet e tyre në procesin e testimit të softuerit.
Kompanitë më të vogla dhe startup-et përfitojnë nga zbatimi i testimit manual të kutisë gri kur kodi i tyre është relativisht i vogël dhe i menaxhueshëm, me automatizimin që bëhet gjithnjë e më i dobishëm ndërsa aplikacionet vazhdojnë të rriten dhe kanë më shumë veçori.
Megjithatë, do të ketë gjithmonë një vend për testim manual falë nivelit të rritur të njohurive, detajeve dhe fleksibilitetit që u ofron kompanive.
Zgjidhja ideale e kutisë gri për çdo kompani është një model hibrid, duke përdorur testime manuale dhe të automatizuara në pika të ndryshme për të llogaritur pikat e forta dhe të dobëta të të dyja teknikave.
Një qasje gjithëpërfshirëse ekspozon më shumë nga problemet që ka një paketë softuerësh, duke ndihmuar në rregullimin e softuerit në mënyrë më efektive dhe përfundimisht duke u ofruar klientëve një produkt shumë më të mirë në fund të zhvillimit.
Çfarë ju nevojitet për të filluar testimin e kutisë gri?
Ka disa parakushte që kërkojnë kompanitë përpara se të fillojnë proceset e tyre të testimit të kutisë gri. Pasja e këtyre ose e bën të mundur procesin e testimit ose e bën testimin e softuerit shumë më të thjeshtë për ekipin e sigurimit të cilësisë pasi ata kanë më shumë asete në dispozicion.
Parakushtet për përfundimin e testimit të kutisë gri përfshijnë:
1. Dokumentet e projektimit ose kodi burimor
Gjëja e parë që ju duhet për të filluar procesin e testimit të kutisë gri është ose dokumentacioni i projektimit ose kodi burimor. Testuesit duhet të jenë në gjendje t’i qasen këtij informacioni që testimi të konsiderohet një test i kutisë gri, duke ofruar një pasqyrë të funksionimit të brendshëm të vetë softuerit.
Ky informacion ka tendencë të jetë sa më i rëndësishëm që të jetë e mundur, për shembull, vargu i kodit për funksionin specifik që testuesi po shqyrton.
Kur përdorni testimin e kutisë gri në vend të kutisë së bardhë, ju jepni vetëm disa nga kodet dhe dokumentacionin e dizajnit, prandaj kini kujdes për nivelin e aksesit që ofroni.
2. Përmbledhje e produktit
Një përmbledhje e produktit ose përmbledhje e aplikacionit është një dokument që kompanitë përdorin për të kuptuar plotësisht atë që një klient kërkon në një paketë softuerike. Kjo përcakton në mënyrë të detajuar funksionalitetin e saktë që një klient kërkon nga softueri, dizajni që dëshiron një klient dhe çdo specifikim tjetër që është i nevojshëm.
Leximi i një përmbledhjeje produkti do të thotë që një testues i kutisë gri mund të kërkojë të gjitha veçoritë që dëshiron një klient, duke u siguruar që ato janë në softuer dhe duke u siguruar që produkti i përshtatet të gjitha qëllimeve që një kompani ka për aplikimin e tij.
Disa kompani kufizojnë sasinë e informacionit që testuesit e kutive gri mund të shohin, në varësi të politikave të konfidencialitetit në kompani.
3. Objektivat e testimit
Zhvilluesit dhe kompanitë kanë qëllime specifike kur plotësojnë testet, ndonjëherë të referuara si një specifikim testi. Kjo është shumë e rëndësishme në procesin e testimit të kutisë gri, pasi do të thotë që zhvilluesit mund t’u ofrojnë testuesve të kutisë gri të gjithë informacionin e duhur, me ekipin e sigurimit të cilësisë që harton teste që përputhen me qëllimet për procesin e testimit.
Të gjithë punojnë në mënyrë më efektive në këtë rast, pasi e dinë se çfarë kërkojnë dhe si t’i arrijnë më së miri këto objektiva.
Procesi i testimit të kutisë gri
Testimi i kutisë gri ndjek një proces relativisht të qëndrueshëm, me hapa të qartë që shënojnë fazat individuale që një kompani duhet të përfundojë për të arritur qëllimet e saj të testimit.
Ndjekja e procesit në mënyrë të qartë dhe të vazhdueshme siguron rezultate të sakta dhe të qëndrueshme që informojnë zhvilluesit se ku janë problemet dhe si mund të zgjidhen ato.
Hapat kryesorë në një test të kutisë gri janë:
1. Përcaktimi i inputeve dhe outputeve
Hapi i parë në proces është përcaktimi i hyrjeve dhe daljeve që prisni nga aplikacioni.
Zgjidhni një hyrje që është brenda kufijve të asaj që zakonisht pritet të trajtojë aplikacioni, në mënyrë që ta bëni atë një provë të drejtë dhe të arrini rezultatin që prisni nga ai hyrje.
Duke përfunduar këtë parashikim në fillim të projektit, ju e dini nëse diçka ka shkuar keq në fund të testeve.
2. Identifikoni flukset primare
Rrjedhat primare janë rrugët që ndjekin të dhënat në një pjesë të softuerit për të arritur rezultatin përfundimtar.
Identifikimi i rrjedhës parësore do të thotë që ju mund të gjurmoni më mirë mënyrën se si informacioni kalon nëpër proceset e një pjese të softuerit, duke krijuar zona të mundshme për shfaqjen e defekteve dhe duke punuar për t’i rregulluar ato nëse ka një problem me softuerin.
3. Identifikoni nënfunksionet, me hyrje dhe dalje
Nënfunksionet janë operacione bazë brenda një rryme parësore. Çdo nënfunksion ushqehet nga një tjetër dhe futet në tjetrin, duke çuar përfundimisht në një dalje përfundimtare nga softueri.
Përcaktoni se çfarë duhet të jetë e dhëna për secilin nënfunksion, së bashku me prodhimin e parashikuar për secilin.
Të bësh këtë në një nivel nën-funksioni ofron një nivel shtesë të njohurive kur lokalizohen problemet e softuerit.
4. Zhvilloni një rast testimi
Një rast testimi i referohet një grupi ngjarjesh që ndodhin në softuer që shqyrton nëse aplikacioni funksionon siç prisni.
Sigurohuni që ky rast testimi i kutisë gri të ekzaminojë siç duhet pjesën e softuerit që po shikoni.
Përqendrohuni gjithashtu te qëndrueshmëria, duke u siguruar që rasti i provës është i lehtë për t’u përsëritur për të marrë rezultate më të sakta nga testi juaj i kutisë gri.
5. Drejtoni rastin e testimit
Filloni të ekzekutoni rastin e provës.
Kjo përfshin futjen e inputeve në secilin nga nën-funksionet dhe shikimin se cilat janë rezultatet, duke shënuar të gjitha rezultatet.
Në testimin e automatizuar të kutisë gri, procesi i regjistrimit është automatik, me testues manual që bëjnë shënime për të gjitha hyrjet dhe daljet vetë.
Nëse mundeni, provoni të gjitha nënfunksionet individualisht përpara se të ekzekutoni të gjithë rrjedhën menjëherë për të kontrolluar që secili funksion funksionon në mënyrë të pavarur.
6. Verifikoni rezultatet
Pasi të keni marrë të dhënat nga rasti i testimit, filloni të verifikoni këto rezultate.
Kjo do të thotë të shikoni rezultatet që merrni nga softueri dhe t’i krahasoni ato me rezultatet që prisnit në fillim të procesit.
Nëse ka ndonjë ndryshim midis të dyve, kjo tregon se mund të ketë një gabim në softuer, pasi ai nuk po funksionon në mënyrën që keni parashikuar fillimisht.
7. Krijo një raport
Në fund të procesit të testimit të kutisë gri, krijoni një raport mbi rezultatet e testit.
Kjo përfshin një përmbledhje bazë të problemeve me softuerin, një vlerësim të disa zgjidhjeve të mundshme për problemet dhe, aty ku është e mundur, të gjitha të dhënat që gjeneruan testet.
Përdorimi i kësaj strukture jep një leksion kryesor për lexuesin përpara se të sigurojë të gjitha provat e nevojshme, në fund të fundit duke qenë një dokument koheziv që ofron shumë udhëzime.
Praktikat më të mira për testimin e Greybox
Praktikat më të mira i referohen proceseve, detyrave dhe parimeve që punonjësit plotësojnë në një test të cilësisë së cilësisë për të arritur standardet më të larta të mundshme.
Disa nga këto praktika më të mira për ekipet e SC që kërkojnë të rrisin standardin e punës së tyre përfshijnë:
1. Punoni me kujdes
Si me çdo metodë testimi, merrni kohën tuaj dhe punoni me kujdes. Një gabim i vetëm mund të zhvleftësojë një test, kështu që të qenit i ngadalshëm dhe i qëndrueshëm për t’u siguruar që puna juaj është e saktë, ju kursen kohë në planin afatgjatë, ndërkohë që përmirëson standardin e softuerit. Kjo është veçanërisht e vërtetë në testimin e kutisë gri, pasi nuk e dini se me cilat pjesë të kodit burimor po punoni në çdo moment.
2. Komunikoni vazhdimisht
Duhet të ketë një zinxhir të vazhdueshëm komunikimi midis zhvilluesve dhe testuesve të kutive gri. Kjo u jep zhvilluesve reagime të menjëhershme për çdo defekt që zbulon ekipi i testimit dhe do të thotë që testuesit e dinë se çfarë duhet të kenë kujdes.
Nëse defekti është pjesë e aspektit të dukshëm të kutisë gri, njoftoni zhvilluesit se ku ndodhet.
3. Vendosni kufij strikte
Kur testimi i kutisë gri përdor kufizime artificiale në informacion, me vetë kompaninë që vendos se çfarë informacioni t’u japë testuesve, sigurohuni që të keni kufizime strikte.
Jepini ekipit të QA vetëm lejet që i nevojiten ose rrezikoni që ata “të shikojnë prapa perdes” dhe të shohin disa nga kodet burimore ose dokumentet e zhvillimit që po përpiqeni t’i mbani të fshehura.
7 gabime dhe gracka në zbatimin e testeve të kutisë gri
Me qindra mijëra aplikacione që kalojnë procesin e testimit çdo vit, ka disa gabime dhe gracka në të cilat bien ekipet e SC.
Njohja për këto do të thotë që ju mund t’i shmangni ato në mënyrë efektive, duke përmirësuar punën tuaj dhe duke reduktuar shanset për të humbur burimet në strategji të dobëta testimi.
Disa nga gabimet dhe kurthet më të zakonshme në testet e kutisë gri përfshijnë:
1. Testimi i sistemeve të shpërndara
Testimi i kutisë gri kërkon qasje në kodin burimor dhe serverët e shpërndarë përdorin kodin nga vende të tjera. Kjo shkakton probleme për testimin e kutisë gri, pasi do të thotë se ka probleme që testuesit mund të mos jenë në gjendje t’i shohin.
2. Përfundimi i testimit jokonsistent
Testimi i paqëndrueshëm i referohet një situate në të cilën një rast testimi ndryshon midis ekzekutimeve. Kjo mund të shkaktojë rezultate të pasakta, me zhvilluesit që më pas fokusohen në përmirësimin e performancës bazuar në metrika të rreme.
Bëni çdo test identik aty ku është e mundur për të rritur saktësinë dhe saktësinë e testimit.
3. Nxitimi përmes testeve
Nëse një datë e propozuar e lëshimit të produktit është afër, ekipet e QA mund të tundohen të nxitojnë proceset e testimit të kutisë gri.
Megjithatë, kjo është një shenjë e planifikimit të keq dhe nuk duhet të përgjigjet me vendime më të këqija. Testimi i nxituar çon në rezultate të pasakta dhe humbje kohe më vonë në fazën e zhvillimit.
4. Mos zbatimi i manualit dhe automatizimit së bashku
As testimi manual dhe as testimi i automatizuar nuk janë metoda perfekte të testimit të kutisë gri.
Përdorimi i të dyjave krahas njëri-tjetrit do të thotë që ju mund të merrni parasysh çështjet e secilit, duke punuar në fund të fundit në mënyrë më efektive.
Së paku, merrni parasysh kombinimin e dy metodave për testim më të mirë.
5. Puna pa mjete
Mjetet e testimit janë krijuar për ta bërë sa më të lehtë punën si testues i kutisë gri. Të punosh pa asnjë mjet po kufizon pa nevojë aftësitë e tua.
Hulumtoni dhe merrni çdo mjet që mund të ndihmojë zhvillimin tuaj për të rritur efikasitetin dhe për të zvogëluar mundësinë e gabimeve.
6. Komunikimi i dobët
Komunikimi i brendshëm ndërmjet departamenteve mund të jetë një luftë, por komunikimi sa më qartë që të jetë e mundur është një domosdoshmëri midis departamenteve të testimit dhe zhvillimit.
Komunikimi më i mirë do të thotë që zhvilluesit i dinë përmirësimet që duhen bërë menjëherë dhe i zgjidhin problemet pa u mashtruar nga mesazhet e brendshme të dobëta.
7. Duke kërkuar në mënyrë aktive për defekte
Testet e kutisë gri ekzistojnë për të gjetur ndonjë defekt aty ku ato ekzistojnë, por edhe për të ekzaminuar performancën e përgjithshme të softuerit.
Shpenzimi i gjatë me vëmendjen për gjetjen e gabimeve mund të marrë shumë kohë dhe të largojë vëmendjen nga qëllimi kryesor i përmirësimit të mënyrës së funksionimit të një aplikacioni.
Llojet e rezultateve nga testet e kutisë gri
Testet e kutisë gri gjenerojnë disa lloje të ndryshme informacioni në fund të një procesi. Kjo nuk i referohet rezultateve nga vetë softueri, por më tepër të dhënave që zhvilluesit mund të përdorin për të përmirësuar softuerin.
Llojet kryesore të prodhimit janë:
1. Mesazhet PASS/FAIL
Një mesazh i thjeshtë PASS/FAIL që informon një zhvillues nëse funksionimi i softuerit ishte i suksesshëm.
Ky lloj prodhimi nuk i siguron një zhvilluesi shumë njohuri, por përdorimi i testimit të kutisë gri do të thotë që një testues mund të shohë se në cilën pikë specifike softueri dështoi dhe pse, duke ndihmuar në zgjidhjen e problemit.
2. Metrikë
Metrikat i referohen statistikave të thjeshta që portretizojnë një ngjarje, siç është sasia e kohës që duhet për të përfunduar një detyrë specifike deri në milisekondë. Këto janë të zakonshme në testimin e automatizuar të kutisë gri, me platformat kompjuterike që e mbledhin automatikisht këtë informacion në një nivel më të lartë saktësie sesa mund të mundte një testues manual.
Ky informacion është i dobishëm për të përcaktuar performancën e një aplikacioni.
3. Të dhëna cilësore
Informacion përshkrues që merrni nga një testues i kutisë gri nga përvoja e tyre me softuerin. E pamatshme, gjë që e bën analizën më të vështirë, por ofron një nivel më të mirë të njohurive për përvojën e përdoruesit dhe i bën klientët më të kënaqur me softuerin.
Shembuj të testeve të kutisë gri
Në disa raste, njohja e teorisë rreth një forme testimi nuk ofron njohuri të mjaftueshme dhe nuk ofron një kuptim të duhur. Njohja e disa shembujve të testeve të kutisë gri është thelbësore për të përmirësuar të kuptuarit tuaj se si funksionon metodologjia e testimit.
Shihni disa shembuj të testeve të kutisë gri më poshtë që ofrojnë më shumë detaje rreth testeve në botën reale dhe se si zbatohet teoria në vendet praktike të punës.
1. Shembull i suksesshëm i testimit të sigurisë
Një kompani po krijon një bazë të dhënash me shumë të dhëna personale dhe planifikon testimin e sigurisë për t’u siguruar që të dhënat e përdoruesit janë të mbrojtura.
Një testues manual kalon procesin, duke kërkuar për të meta të mundshme në kod dhe mundësi për të hyrë në pjesë të aplikacionit.
Pas gjetjes së një dobësie, testuesi informon zhvilluesin se ku është dobësia dhe si e kanë shfrytëzuar atë.
Kur softueri është rregulluar, testuesi kryen përsëri të njëjtin test për të siguruar që sistemi është i sigurt.
2. Shembull i dështuar i testimit të bazës së të dhënave
Zhvilluesit që krijojnë një bazë të dhënash kanë një afat të ngushtë për lëshimin dhe duhet të testojnë shpejt.
Testuesit nxitojnë disa raste bazë testimi së bashku dhe i plotësojnë ato shpejt, duke bërë gabime në ekzekutimin e tyre, duke mos përgatitur parashikimet e daljes dhe duke dështuar në ekzaminimin e nënfunksioneve.
Duke qenë se ata nuk përgatisin parashikimet e prodhimit, ata nuk i kuptojnë problemet e prodhimit, duke dërguar një produkt që nuk funksionon siç duhet si rezultat.
Llojet e gabimeve dhe gabimeve të zbuluara përmes Testimit të kutisë gri
Një nga qëllimet kryesore të testimit të kutisë gri është gjetja e gabimeve dhe defekteve në një program, me kompanitë që kërkojnë të ofrojnë aplikacione të nivelit të lartë ku klientët e tyre mund të mbështeten kudo që të jetë e mundur.
Ka disa lloje specifike gabimesh dhe defektesh që testuesit mund të gjejnë në procesin e testimit të kutisë gri, secila prej të cilave mund të tregojë një problem të ndryshëm me kodin.
Llojet e gabimeve dhe gabimeve të zbuluara në testimin e kutisë gri përfshijnë:
1. Dështimi i procesit
Forma e parë e gabimit është dështimi i procesit.
Kjo i referohet kur testi nuk kthen asnjë formë rezultati dhe thjesht rrëzohet.
Ekzistojnë disa shkaqe të mundshme të këtyre problemeve dhe në një rast ideal, një testues i kutisë gri mund të përcaktojë se nga vjen një problem dhe si një zhvillues mund të kodojë një përgjigje.
2. Prodhim i pasaktë
Disa gabime në testimin e kutisë gri ndodhin kur rezultati i një procesi nuk është ai që parashikojnë zhvilluesit.
Ky është një problem serioz në raste të tilla si një bazë të dhënash, në të cilat mbajtja e sigurt e informacionit të saktë është një domosdoshmëri.
3. Gabime sigurie
Gabimet e sigurisë ndodhin kur aplikacioni i një kompanie është disi i pasigurt dhe lejon aksesin e palëve të treta në informacionin e mbajtur brenda.
Të kesh të meta sigurie në një aplikacion mund të jetë një çështje GDPR dhe ta bëjë aplikacionin të mos jetë në përputhje me një sërë rregulloresh ndërkombëtare.
Metrikat e zakonshme të testimit të kutisë gri
Metrikat i referohen matjeve konstante që ekzaminojnë një ngjarje të caktuar ose seri dukurish, zakonisht në formën e të dhënave sasiore.
Duke përdorur metrikë, testues dhe ekipe të sigurimit të cilësisë mund të ekzaminojnë softuerin që po i nënshtrohet një testi të kutisë gri dhe të shohin saktësisht se çfarë po shkon keq, nëse kjo është në formën e më shumë gabimeve që ndodhin ose funksione të ndryshme që kërkojnë më shumë kohë për t’u ngarkuar.
Disa nga metrikat më të zakonshme të testimit të kutisë gri që përdorin testuesit e QA kur vlerësojnë softuerin përfshijnë:
· Koha për të dalë:
Sasia e kohës që i duhet aplikacionit për të prodhuar një rezultat pas fillimit të testit.
· Koha për përgjigje:
Sasia e kohës që i duhet softuerit për t’iu përgjigjur të dhënave të përdoruesit, qoftë në formën e një rezultati ose thjesht një njohje të hyrjes.
· Numri i gabimeve:
Numri i pastër i gabimeve që ka softueri në proceset e tij.
· Gabimet për funksion:
Numri i gabimeve që ekzistojnë pjesëtuar me numrin e funksioneve në softuer, i përdorur për të përcaktuar densitetin e gabimit.
Mjetet më të mira të testimit të kutisë gri
Testimi i kutisë gri mund të mbështetet në mjete të jashtme për të përmirësuar cilësinë e punës suaj, duke automatizuar disa nga proceset dhe duke ju mbështetur kur krijoni një rregullim për çdo defekt që gjeni.
Sa më i mirë të jetë mjeti i testimit që përdorni, aq më shumë probleme do të zbuloni dhe aq më i mirë do të jetë standardi i produktit tuaj përfundimtar, duke kursyer kohë dhe burime gjatë testimit.
Shihni disa nga mjetet më të mira të testimit të kutisë gri më poshtë, përveç përfitimeve dhe disavantazheve të përdorimit të secilës platformë.
5 Mjetet më të mira falas të testimit të kutisë gri
Kur një kompani më e vogël kërkon të fillojë testimin e kutisë gri, disponimi i mjeteve të duhura është një domosdoshmëri, por mbajtja e tyre me një çmim të arsyeshëm mund të jetë po aq e rëndësishme. Çdo qindarkë vlen në një biznes të vogël dhe një zhvillues aplikacionesh nuk është i ndryshëm, me buxhete të ngushta që çojnë në vendime të vështira.
Përdorimi i mjeteve falas të testimit të kutisë gri është i përsosur për sigurimin e cilësisë me burime minimale.
Disa nga mjetet më të mira falas të testimit të kutisë gri përfshijnë:
1. ZAPTEST EDICION FALAS
Edicioni falas i ZAPTEST ofron një përvojë automatizimi me cilësi të lartë për përdoruesit e tij, me automatizimin e softuerit të plotë që mbështet testimin që nga fillimi i zhvillimit.
Me ekzekutimin paralel, mund të kryeni disa teste në të njëjtën kohë për të shpejtuar proceset tuaja dhe kur të jeni gati për të bërë hapin në nivelin tjetër, edicioni Enterprise e bën kalimin sa më të thjeshtë që të jetë. Si një përfitim shtesë, ZAPTEST ofron gjithashtu teknologjinë më të fundit RPA , pa kosto shtesë.
Zgjedhja perfekte për dikë në ditët e para të testimit të tyre.
2. Apium
Një mjet i plotë testimi i krijuar për të ndihmuar në sigurimin që aplikacionet celulare janë në përputhje me standardin , Appium ka një komunitet aktiv mbështetës, por i ekzekuton testet relativisht ngadalë. I shoqëruar me një konfigurim sfidues, ky nuk është mjeti më i mirë falas për shumë kompani.
3. Chrome Dev Tools
Google Chrome ofron një sërë mjetesh zhvillimi për aplikacionet në ueb dhe me integrimin në shfletuesin më të njohur, duket si një domosdoshmëri.
Sidoqoftë, ai është i kufizuar në elementët e kutisë së testimit, duke e bërë atë një mjet testimi kufizues.
4. JUnit
JUnit është një kornizë me burim të hapur që i lejon përdoruesit të kryejnë teste të përsëritshme herë pas here në Java, duke e kufizuar atë në një gjuhë të vetme.
Në vetvete, ky kufi nuk është një problem, por mungesa e një API dhe ndërfaqe të thjeshtë mund ta bëjë atë të pakëndshëm për testuesit më të rinj.
5. DBUnit
DBUnit fokusohet në mbështetjen e projekteve të orientuara nga baza e të dhënave, duke përdorur gjendjet e njohura për të verifikuar me saktësi rezultatet dhe për të ekzaminuar në mënyrë gjithëpërfshirëse rezultatet.
Kjo është e përkryer për bazat e të dhënave dhe aplikacione të ngjashme, por mungesa e mbështetjes së integrimit do të thotë se ai ka vështirësi në detyrat ndër-platformë.
5 Mjetet më të mira të Testimit të Kutisë Gri të Ndërmarrjeve
Ndërsa një zhvillues rritet, rriten edhe kërkesat e tyre për testim, me kompanitë më të mëdha që kanë aplikacione më të mëdha dhe që kërkojnë komplete testimi më gjithëpërfshirëse si rezultat.
Mjetet e testimit të kutisë gri të ndërmarrjeve ekzistojnë për të mbështetur kompanitë në këtë situatë, duke ofruar më shumë akses në veçoritë e avancuara që zhvilluesit amatorë dhe të shkallës së vogël mund të mos kenë nevojë.
Disa nga mjetet më të mira të testimit të shkallës së ndërmarrjes kur kryeni një test të kutisë gri përfshijnë:
1. EDICIONI I NDËRMARRJES ZAPTEST
Edicioni Enterprise i ZAPTEST ofron aftësi më të mëdha testimi sesa versioni falas, me një nga përfitimet kryesore që është aksesi i vazhdueshëm tek një ekspert i ZAP. Një Ekspert ZAP vepron si një këshilltar dhe anëtar i ekipit tuaj në distancë, duke mbështetur të gjitha nevojat e testimit të kompanisë suaj.
Zhvilluesit që investojnë në edicionin ZAPTEST Enterprise mund të shohin deri në dhjetëfishin e kthimit të investimit të tyre falë teknologjive të përparuara të Vizionit Kompjuterik , 1SCRIPT, ndër-platformë, ndër-pajisje, ekzekutim ndër-shfletues dhe mbi të gjitha licencat e pakufizuara.
Licencat e pakufizuara, përveç testimit më të avancuar dhe teknologjisë RPA, nënkupton që Ndërmarrjet përfitojnë nga një kosto fikse, pavarësisht se sa shpejt dhe sa rriten.
2. TestRail
Një zgjidhje për menaxhimin e rasteve testuese që ju lejon të ndani të gjitha testet që përfundoni sipas rastit të testimit, duke regjistruar më saktë të dhënat.
TestRail nuk është domosdoshmërisht ideal për testimin e kutisë gri, megjithatë, pasi përpiqet të balancojë testimin manual me regjistrimin e automatizuar të testeve.
3. Dëshmi
Një platformë testimi që fokusohet në ofrimin e testeve të personalizuara të qëndrueshme, duke zbatuar si rastet e testimit të koduara ashtu edhe alternativa jo të koduara.
Meqenëse kjo është falas vetëm për një numër të caktuar testesh në muaj, organizatat më të mëdha mund të luftojnë për të shfrytëzuar maksimalisht këtë platformë.
4. Test Rigor
TestRigor është një platformë e vlerësuar gjerësisht që përdor një motor AI për të përfunduar testet, me mirëmbajtjen e testit të AI-së një nga karakteristikat më tërheqëse.
Sidoqoftë, kjo vjen me një çmim të konsiderueshëm, me platforma të tjera që japin kthime më të mira nga investimi.
5. Kobiton
Kobiton është një platformë testimi që është relativisht fleksibël në çmimet, duke automatizuar testet në bazë të përdoruesve pas përfundimit të një prove falas.
Një shqetësim që disa përdorues kanë rreth Kobiton është mungesa relative e mbështetjes nga Kobiton kur bëhet fjalë për zgjidhjen e pyetjeve të testuesit.
Kur duhet të përdorni veglat e kutisë Enterprise vs Freemium Grey?
Si mjetet e sipërmarrjes ashtu edhe ato të kutisë gri freemium u ofrojnë përdoruesve të tyre shumë përfitime. Kompanitë në mënyrë ideale fillojnë me një produkt freemium për të mësuar procesin e testimit përpara se të përparojnë më pas në një botim ndërmarrje ndërsa nevojat e tyre rriten.
Kjo prezanton një nivel të vazhdimësisë së projektit, duke kufizuar sasinë e rikualifikimit që kalon stafi.
Pika e kalimit ndryshon nga biznesi në biznes, por në një moment të caktuar kohor, kthimi i investimit të një produkti të ndërmarrjes bëhet i pashmangshëm.
Lista kontrolluese e testimit të kutisë gri, këshilla dhe truket
Përfundimi i testimit të kutisë gri është një proces mjaft kompleks, kështu që të kesh një listë kontrolli për të punuar, ndihmon për t’ju siguruar që keni bërë gjithçka që ju nevojitet në testim.
Disa nga veçoritë kryesore të një liste kontrolli me kuti gri, përveç disa këshillave për përmirësimin e cilësisë së testimit tuaj, përfshijnë:
1. Planifikimi i plotë
Planifikimi gjithëpërfshirës është një nga gjërat e para që duhet të kontrolloni në një test, pasi të siguroheni që të planifikoni absolutisht çdo aspekt të një testi është një domosdoshmëri.
Sa më shumë planifikim të bëni, aq më shumë strukturë ka pas testimit tuaj, pasi njerëzit e dinë se çfarë testesh po plotësojnë dhe kur po i plotësojnë ato.
Kjo gjithashtu çon në të dhëna të qëndrueshme , të cilat janë ideale për zgjidhje më të mira zhvilluesish.
2. Raportimi i menjëhershëm i të dhënave
Kur punoni në një proces testimi të kutisë gri, përpiquni të raportoni të dhënat në çast. Duke krijuar raporte sa më shpejt që të jetë e mundur, ju rritni saktësinë e proceseve tuaja të raportimit pasi i gjithë informacioni është i freskët në mendjen tuaj.
Ky është veçanërisht rasti për informacionin cilësor, pasi ai duhet të shkruhet nga testuesi dhe jo thjesht të ruhet në një platformë testimi.
3. Vendosni përgjegjësi
Gjatë gjithë proceseve të testimit, sigurohuni që të gjithë në vendin e punës të fokusohen në të paturit e përgjegjësive specifike. Duke vendosur përgjegjësitë në këtë mënyrë, të gjithë e dinë se cili është roli i tyre në vendin e punës dhe e kuptojnë se si t’i kryejnë detyrat e tyre në mënyrë produktive dhe me ndërprerje minimale.
Përderisa ky është më shumë një koncept menaxhimi sesa një pikë liste kontrolli testimi, ai ka një ndikim të madh në rezultatet.
4. Krahasimi i vazhdueshëm
Krahasoni rezultatet tuaja me disa gjëra në një bazë pothuajse konstante. Pikat e krahasimit përfshijnë dokumentacionin fillestar të projektimit, rezultatet e testimit paraprak dhe afatin kohor të organizatës për përfundimin e projektit.
Pasja e këtyre kornizave të referencës ju informon vazhdimisht se si po shkon procesi i zhvillimit të softuerit, fushat për përmirësim dhe rregullimet e mundshme për të bërë.
konkluzioni
Si përfundim, testimi i kutisë gri është një nga format më të gjithanshme të testimit në dispozicion, duke kombinuar funksionalitetin e kutisë së bardhë me kufizimin e paragjykimit të testeve të kutisë së zezë.
Duke kombinuar metodat manuale dhe të automatizuara të testimit në përpjekjet tuaja të kutisë gri, kompanitë mund të fillojnë të zvogëlojnë ndjeshëm ndikimin e gabimeve në softuerin e tyre duke miratuar rregullime që çojnë në një produkt më të mirë.
Testimi i kutisë gri është mjeti i përsosur për çdo zhvillues dhe këshillat e mësipërme mund të sigurojnë që ta përdorni siç duhet.
Pyetjet e shpeshta dhe burimet
Nëse keni ndonjë pyetje në lidhje me testimin e kutisë gri, hidhini një sy disa nga pyetjet tona të bëra shpesh për të mësuar më shumë dhe për të përmirësuar të kuptuarit tuaj për këtë lloj testi:
1. Kurset më të mira për automatizimin e testit të kutisë gri
Ka relativisht pak kurse që synojnë në mënyrë specifike automatizimin e testit të kutisë gri, me këto kurse të përgjithshme të testimit të softuerit që janë një mënyrë ideale për të filluar:
· “Fondacioni i Testimit të Softuerit me Provim”- Oferta Trajnimi
· “Trajnim 6-javor për testimin e softuerit Essentials”- Futuretrend Technologies Ltd
· “Kursi i testimit të softuerit”- Kursi mbretëror
· “Black-box and White-box Testing”- Coursera
· “Testimi i softuerit – Strategjitë e kutisë së zezë dhe testimi i kutisë së bardhë”- NPTEL
2. Cilat janë 5 pyetjet kryesore të intervistës mbi Testimin e Kutisë Greke?
· Çfarë eksperience keni nga puna me testimin e kutisë gri dhe si e gjetët atë?
· Pse kompanitë përdorin testimin e kutisë gri dhe në cilën pikë të procesit?
· Krahasoni testimin e kutisë së bardhë, kutisë gri dhe kutisë së zezë
· Cilat janë disa nga sfidat më të mëdha të testimit të kutisë gri dhe si mund t’i kapërceni ato?
· Si funksionon automatizimi i testimit?
3. Udhëzimet më të mira të YouTube për testimin e kutisë gri
· “Çfarë është testimi i kutisë gri? Cilat janë teknikat e përdorura në testimin e kutisë gri? Me shembullin e shpjeguar”- Hacks për testimin e softuerit
· “Testimi i kutisë gri | inxhinieri softuerike |”- Edukimi 4u
· “Black Box, White Box and Grey Box Testing”- Miracle Education
· “Këshilla për Testuesit e Ri Manual të QA | Puna me zhvilluesit + gjërat që kam mësuar si testues i softuerit”- Madeline Elaine
· “Çfarë është testimi i kutisë gri? (Pyetja e Intervistës për Testimin e Softuerit #54)”- QA Fox
4. Si të mirëmbahen testet e kutisë gri?
Mirëmbajtja e testeve të kutisë tuaj gri është një proces mjaft i thjeshtë. Për testimin manual, sigurohuni që anëtarët e stafit të jenë të trajnuar mirë dhe të kryejnë të njëjtat detyra çdo herë. Për testimin e automatizuar, korrigjoni të gjithë kodin për rastet e testimit dhe kontrolloni rezultatet, duke përdorur mbikëqyrje të vazhdueshme të proceseve kudo që të jetë e mundur.
5. Librat më të mirë për testimin e kutisë gri
Ky seksion përmban artikuj revistash përveç librave, në mënyrë që të ofrojë standardet më të larta të mundshme të asistencës me shkrim për testuesit e cilësisë së cilësisë:
· “Teknika Grey-Box e Testimit të Integrimit të Softuerit Bazuar në Mesazh”- TanLi M. et al
· “Një studim krahasues i teknikave të testimit të kutisë së bardhë, kutisë së zezë dhe kutisë gri” – Ehmer, M., Khan, F.
· “Strategjitë e testimit të bazuara në FSM në kutinë gri” – Petrenko, A.
· “Software Engineering”- Saleh, KA
· “Konferenca Ndërkombëtare për Aplikimet Kompjuterike 2012”- Kokula Krishna Hari K.
