Strādājot programmatūras testēšanas jomā, ir desmitiem dažādu testēšanas metožu, kas jāņem vērā.
Programmatūras testēšana palīdz izstrādātājiem novērst jebkādus trūkumus, kas varētu būt programmatūras paketē, lai varētu piegādāt produktu, kas atbilst visu ieinteresēto personu vajadzībām un vēlmēm. Izmantojot pareizo testēšanas risinājumu, iegūsiet visas nepieciešamās zināšanas, taču pareiza testa izvēle var prasīt laiku.
Pelēkās kastes testēšana ir viens no daudzpusīgākajiem testētājiem pieejamajiem testēšanas veidiem, kas sniedz daudz informācijas, neaizņemot pārāk daudz resursu.
Uzziniet vairāk par to, kas ir “pelēkās kastes” testēšana, par to, kā darbojas “pelēkās kastes” testēšana, un par dažiem iemesliem, kāpēc uzņēmumi izmanto šo testēšanas metodi.
Kas ir pelēkās kastes testēšana?
Pelēkās kastes testēšana ir testēšanas veids, kas apvieno “baltās kastes” un “melnās kastes” testēšanu, izmantojot daļēju izpratni par sistēmas pamatdizainu un veidu, kā tā tiek īstenota.
Šāda kombinācija nozīmē, ka testētājs zina daļu no tā, kas notiek fonā, pilnībā nepārzinot kodu, un tas ļauj labāk izprast iespējamos programmatūras problēmu cēloņus, kad tās rodas.
Par pelēkās kastes testēšanas pabeigšanu ir atbildīgi testētāji, un kvalitātes nodrošināšanas komanda strādā neatkarīgi no projekta izstrādes komandas.
1. Kad un kāpēc programmatūras testēšanā jāveic pelēkās kastes testēšana?
Uzņēmumi izstrādes procesā vairākkārt izmanto pelēkās kastes testēšanu.
Piemēram, ja lietojumprogrammas pareizai darbībai ir nepieciešama mijiedarbība ar trešās puses rīku, testētājiem nav piekļuves avota kodam, kas ir ārējās programmatūras daļa. Tas ir uzspiests ierobežojums QA testētāja piekļuvei un padara testēšanu par pelēko kastīti bez izvēles.
2. Kad nav nepieciešams veikt pelēkās kastes testēšanu
Testēšanas procesā ir pāris posmi, kad pelēkās kastes testēšana nav nepieciešama, pirmais no tiem ir izstrādes procesa sākumā.
Funkcionālā testēšana notiek, kad izstrādātāji sākotnēji testē, lai pārliecinātos, ka viņu kods izpilda galvenos uzdevumus, kas ir pilnīgi pārredzami. Tā kā testētājam nav slēpts kods vai dokumentācija, tas netiek uzskatīts par pelēkās kastes testēšanu.
Vēl viens gadījums, kad pelēkās kastes testēšana nav nepieciešama, ir testēšana pašā izstrādes beigās, kad izstrādājums ir pabeigts. Tas ir gadījums, kad testēšanā palīdz galalietotājs, un to sauc arī par “beta testēšanu” vai “testēšanu no gala līdz galam”.
Lietotāji testē lietojumprogrammu bez piekļuves kodam vai projektēšanas dokumentiem, tā vietā novērtējot programmatūru pēc tās nopelniem. Tā ir “melnās kastes” testēšana, jo process ir pilnīgi necaurspīdīgs.
3. Kas ir iesaistīts pelēkās kastes testēšanā?
Pelēkās kastes testēšanā ir iesaistīti vairāki cilvēki un lomas, un dažas no svarīgākajām lomām šajā procesā ir šādas:
– QA vadītājs:
QA vadītājs jeb kvalitātes nodrošināšanas vadītājs ir programmatūras izstrādes procesa darbinieks, kas ir atbildīgs par uzdevumu piešķiršanu testēšanas komandai.
Tas ietver darba grafiku izveidi, ziņojumu izskatīšanu un konfliktsituāciju risināšanu, kas rodas komandā.
– Testeris:
Testētājs ir profesionālis, kas ir atbildīgs par pelēkās kastes testēšanas procesa testēšanas gadījumu izpildi.
Tas prasa lielu uzmanību detaļām, rakstot ziņojumus un atkārtoti pārbaudot precīzus testēšanas gadījumus.
– Izstrādātājs:
Izstrādātāji ir profesionāļi, kas ir atbildīgi par koda izveidi un pielāgošanu atkarībā no pelēkās kastes testēšanas rezultātiem.
Lai gan tās ne vienmēr ir iesaistītas pašā testēšanā, tās saņem paziņojumus no testētājiem par testēšanas rezultātiem.
– QA analītiķis:
QA analītiķa loma ir izplatīta testēšanas procesos, kuros izmanto daudz automatizācijas. Analītiķis raksta automātisko testu gadījuma kodu, kā arī analizē datus, ko testi atgriež procesa beigās.
Pelēkās kastes testēšanas priekšrocības
Programmatūras pārbaudē, izmantojot pelēkās kastes testēšanu, ir dažas galvenās priekšrocības. Izmantojot šīs priekšrocības, jūs laika gaitā uzlabojat savas lietojumprogrammas standartu.
Daži no iemesliem, kāpēc uzņēmumi izmanto šo testēšanas veidu, ir šādi:
1. Iekšējo mehānismu pārzināšana palīdz izstrādāt testus
Viena no galvenajām priekšrocībām, izmantojot pelēkās kastes testēšanu darbavietā, ir tā, ka jūs zināt par dažiem lietojumprogrammas iekšējiem mehānismiem. Tas ietver izpratni par to, ko katra no funkcijām dara un kuri ir gatavie moduļi salīdzinājumā ar pēc pasūtījuma rakstīto kodu dažām citām funkcijām.
Zinot iekšējo funkcionalitāti, testētājs labāk saprot, ko testē, un var mērķtiecīgi veikt testus, ņemot vērā lietojumprogrammas dizainu. Uzņēmumi saņem precīzākus rezultātus, kas pareizi atspoguļo programmatūru.
2. Rezultāts ir tūlītējs jautājumu atrisinājums
Dažos gadījumos, kad testā rodas problēma un testētājam ir piekļuve kodam, kas ir problēmas pamatā, problēmu var atrisināt nekavējoties.
Tas ir pretēji melnās kastes testēšanas metodoloģijai, kurā testētāji nevar redzēt nevienu no pārbaudāmās programmatūras aizkulisēs esošajiem kodiem. Redzot kodu, testētāji ar lielu izstrādes pieredzi var norādīt izstrādātājiem, kur tieši ir problēma un kā to var atrisināt nākamajā atjauninājumā.
Pelēkās kastes testēšana ļauj ietaupīt daudz laika, kas citādi tiktu tērēts problēmu izpētei, un palīdz uzņēmumiem efektīvāk izmantot laiku.
3. Nodala testētājus un izstrādātājus
Izmantojot pelēkās kastes testēšanu, tiek skaidri nodalīti lietojumprogrammas izstrādātāji un programmatūras testētāji.
Tas ir tāpēc, ka pelēkās kastes testēšana ir atkarīga no tā, vai testētājiem ir zināšanas par to, kā programmatūra darbojas, un attālums starp abiem kļūst nepieciešams, lai iegūtu precīzākus testēšanas rezultātus, kurus neietekmē neobjektivitāte.
Testētāji pelēkās kastes scenārijos ir pavisam citā komandā nekā izstrādātāji, piedāvājot precīzu informāciju bez jebkādiem esošajiem uzskatiem, kas ietekmē viņu rezultātus.
Arī izstrādātāji gūst no tā labumu, jo viņi kritiskāk novērtē savu darbu, palīdzot uzlabot gan esošo lietotni, gan savas prasmes nākotnē.
Pelēkās kastes testēšanas izaicinājumi
Ir daži būtiski trūkumi, kas saistīti ar pelēkās kastes testēšanas izmantošanu izstrādes darbā.
Izprotot šos trūkumus un, ja iespējams, cenšoties tos mazināt, kvalitātes nodrošināšanas posma beigās jūs paaugstināsiet savu darbu vispārējo standartu.
Daži no galvenajiem pelēkās kastes testēšanas trūkumiem ir šādi:
1. Iespēja, ka kods nav redzams
Pelēkās kastes testēšana nozīmē, ka daži koda aspekti ir slēpti no testētāja, un gadījumā, ja testā rodas kādas problēmas, tas var radīt papildu problēmas.
Izmantojot neredzamu kodu, testēšanā iesaistītajiem darbiniekiem ir grūti vadīt testus, lai maksimāli izmantotu lietojumprogrammu, un viņi zaudē iespēju uzreiz redzēt problēmas cēloni.
Kļūdu labošanas process kļūst aizvien neskaidrāks, kā rezultātā kļūst nepieciešams ilgāks atjaunināšanas laiks un uzņēmumiem ir grūti atrast problēmas savā kodā.
Šī neredzamā koda dēļ galaprodukti var būt kļūdaināki un zemāka standarta.
2. Testi var būt neprecīzi, ja darbības neizdodas.
Precīzi testi ir obligāta prasība jebkurā programmatūras testēšanas veidā, jo augstāka precizitātes pakāpe norāda komandām uz atjauninājumiem, kurus tās var pabeigt nākamajās versijās, turklāt palīdz izstrādātāju komandai būt pārliecinātai par saviem produktiem.
Šī precizitāte samazinās, ja pelēkās kastes testēšanā darbības neizdodas. Ja testētājiem nav piekļuves kodam, viņi no programmatūras vienkārši saņem ziņojumu “Operācija nav izdevusies”, tādējādi viņi nevar sniegt nekādas atsauksmes par to, kā tā darbojas.
Lai iegūtu izdevīgus rādītājus, izstrādātājiem pirms nākamā testēšanas posma ir jālabo programmatūra. Pretējā gadījumā testētājs var tikai paziņot, ka funkcija tās pašreizējā formā nedarbojas.
3. Cīņas ar sadalītajām sistēmām
Izplatītās sistēmas attiecas uz programmatūras sistēmām, kas tiek izvietotas vairākās dažādās vietās vai ir atkarīgas no tādām funkcijām kā mākoņdatošanas un datu apstrādes pakalpojumi.
Tas ārkārtīgi apgrūtina testēšanu, jo ievērojama programmatūras daļa ir apslēpta aiz trešās puses struktūras, un testētāji vienkārši saņem nezināma procesa rezultātu.
Ja rodas problēmas ar programmatūru, kas izmanto trešo pušu sistēmas, var būt grūti noteikt, vai problēma ir pašā lietojumprogrammā, trešās puses funkcionalitātē vai abu integrācijas veidā, jo īpaši, ja testētājs nevar redzēt kodu tā darbības laikā.
Pelēkās kastes testu raksturlielumi
Ir dažas kopīgas pazīmes, kas raksturo pelēkās kastes testus, un šo testu atpazīšana palīdz jums sagatavot savas organizācijas stratēģiju.
Daži no galvenajiem “pelēkās kastes” testēšanas raksturlielumu piemēriem, kā arī to, ka šie raksturlielumi ir svarīgas “pelēkās kastes” testēšanas procesa daļas, ir šādi:
– Palielināts pārklājums:
Piekļuve daļai pirmkoda nodrošina lielāku pārklājuma pakāpi testos, un sīkāka informācija ļauj precīzāk atrast kļūdas.
– Datu plūsmas:
Daudzos pelēkās kastes testos uzsvars tiek likts uz datu plūsmu un izpratnes iegūšanu par to, kā informācija pārvietojas sistēmā.
– Nealgoritmiska:
Pārbaudot algoritmus, “pelēkās kastes” testēšana nedarbojas, jo tas ir vēl viens koda aizsegšanas līmenis.
Ko mēs testējam pelēkās kastes testos?
Katrs testēšanas veids ir vispiemērotākais, ja tas ir vērsts uz konkrētām attiecīgās programmatūras daļām. Tas pats attiecas arī uz pelēkās kastes testēšanu, un šī metodoloģija ir visnoderīgākā dažās atšķirīgās lietotnes daļās.
Daži piemēri, ko testētāji novērtē, veicot pelēkās kastes testus:
1. Lietojumprogrammu drošība
Pelēkās kastes testi ir ideāli piemēroti iekļūšanas testiem, kas pārbauda lietojumprogrammas drošību. Testētāji var apskatīt visu kodu un meklēt iespējamās ievainojamības.
Ētiskie hakeri ir ideāli piemēroti testētāji lietojumprogrammu drošības testēšanai, jo viņi daudz dabiskāk atpazīst iespējamās programmatūras vājās vietas un nepilnības nekā tie, kuriem nav pieredzes programmatūras drošības pārkāpumu jomā.
2. Datubāzes testēšana
Daudzi uzņēmumi izmanto pelēkās kastes testēšanu datubāzes testēšanai, jo var izsekot datiem, izmantojot katru programmatūras apakšfunkciju.
Testētāji var redzēt visas programmatūras veiktās izmaiņas un novērtēt, vai tās ir pareizas.
Tas ir noderīgs pelēkās kastes testēšanas veids, jo datubāzu testi pēc savas būtības ir paredzami, jo uzņēmumi izmanto datubāzes, lai organizētu esošo informāciju, nevis ģenerētu jaunus datus.
3. Tīmekļa lietojumprogrammas
Tīmekļa lietojumprogrammas gūst labumu no pelēkās kastes testēšanas, jo šī testēšanas metode ir daudzpusīga.
Pelēkās kastes testus var izmantot drošības, datubāzes, integrācijas, lietotāja saskarnes un pārlūkprogrammas testēšanai, kas ir galvenie tīmekļa lietojumprogrammu aspekti.
Daļēji nav nepieciešams mainīt testēšanas metodoloģiju, tāpēc jūs gūsiet labumu no lielāka nepārtrauktības līmeņa.
Dažu neskaidrību noskaidrošana:
Pelēkās kastes un baltās kastes vs. melnās kastes testēšana
Pelēkās kastes testēšana ir testēšanas veids, kas ir radniecīgs gan baltās kastes, gan melnās kastes testēšanai, kas nozīmē, ka starp šīm metodoloģijām var rasties daudz neskaidrību.
Uzziniet vairāk par to, kas ir “baltās” un “melnās kastes” testēšana, kā arī par dažām būtiskām atšķirībām starp tām un “pelēkās kastes” testēšanu programmatūras izstrādē:
1. Kas ir baltās kastes testēšana?
Baltās kastes testēšana ir lietojumprogrammas testēšanas veids, kas testētājam sniedz visaptverošu informāciju par lietojumprogrammu.
Tas ietver pilnīgu piekļuvi pirmkodam un visiem programmatūras izstrādes dokumentiem, kas testētājam nodrošina daudz labāku izpratni par programmatūras darbību.
Testētāji izmanto šo izpratni, lai redzētu vairāk problēmu, kas sastopamas lietojumprogrammā, un sniedz precīzāku pārskatu par to, kā lietojumprogramma darbojas lietotājiem.
Piemēram, “baltās kastes” testēšanas piemērs ir konkrētu datu ievades plūsmas pārbaude, lai redzētu, kur lietotnes procesos rodas problēma, nevis vienkārši pārbaudītu, vai problēma pastāv vai ne.
Izstrādes procesos ir dažas reizes, kad uzņēmumi izmanto “baltās kastes” testēšanu.
Pirmā no tām ir vienības testēšana, kas novērtē, vai katrs atsevišķs programmatūras paketes koda vai moduļa elements veic izstrādātāja paredzēto darbu.
Vienību testēšana palīdz testētājiem atrast lielāko daļu problēmu lietojumprogrammā, jo tiek pārbaudīta visa lietojumprogrammas funkcionalitāte.
Baltās kastes testēšana palīdz arī atrast atmiņas noplūdes. Detalizēti pārbaudot visu kodu, QA analītiķis atrod, kur lietojumprogramma izmanto ierīces atmiņu un potenciālās jomas, kurās tā izmanto pārāk daudz.
Tas palīdz lietojumprogrammai turpmākajās iterācijās darboties ātrāk un efektīvāk, jo atmiņas noplūde tiek labota pēc iespējas ātrāk.
Kādas ir atšķirības starp pelēkās un baltās kastes testiem?
Starp “baltās kastes” un “pelēkās kastes” testiem ir vairākas būtiskas atšķirības, un pirmā atšķirība ir informācijas līmenis, kas kādam ir pieejams.
Baltās kastes testēšanai ir pilnīga piekļuve programmas pirmkodam un projektēšanas dokumentiem, savukārt pelēkās kastes testēšanai ir tikai daļēja piekļuve daļai šīs informācijas, galvenokārt projektēšanas dokumentiem.
Šīs izmaiņas nozīmē, ka atšķiras arī testus veicošo personu loks, jo par “baltās kastes” testēšanu galvenokārt ir atbildīgi paši izstrādātāji.
Turpretī par “pelēkās kastes” testēšanu ir atbildīga QA komanda, jo testētājiem nevar būt padziļinātu zināšanu par kodu.
Pelēkās kastes testēšana arī aizņem mazāk laika nekā baltās kastes testēšana. Baltās kastes testēšana ir visaptveroša, un tā pārbauda gan programmatūras lietotāja pusi, gan pašu kodu. Tas aizņem daudz vairāk laika, un tas nozīmē, ka “pelēkās kastes” testēšanas process ir daudz ātrāks risinājums.
Tomēr “baltajai kastītei” ir lielākas automatizācijas iespējas, jo testētāji zina, kā darbojas iekšējais kods.
2. Kas ir “melnās kastes” testēšana?
Par melnās kastes testēšanu tiek uzskatīts gadījums, kad testētājs pārbauda programmatūras paketi, neizprotot, kā sistēma darbojas.
Tas nozīmē, ka jums nav piekļuves ne lietojumprogrammā iekļautajam kodam, ne arī pieejamajiem projektēšanas dokumentiem vai instrukcijām. Testētājiem vienkārši ir saraksts ar testējamām funkcijām un virkne testēšanas gadījumu, kas jāizpilda.
Melnās kastes testēšanas piemērs ir testēšana no gala līdz galam, kad testētājs saņem pilnu programmatūras paketi un testē visu lietojumprogrammu, lai pārliecinātos, ka funkcionalitāte darbojas tā, kā tā ir izstrādāta.
Lielākā daļa ideālo melnās kastes testēšanas gadījumu ir tie, kas ir procesa beigās un kuros ir iesaistīti klienti un viņu skatījums uz produktu, jo nav piekļuves kodam, lai novērstu jebkādu neobjektivitāti, kas ietekmē lietotāja viedokli.
Uzņēmumi galvenokārt izmanto melnās kastes testēšanu pēc tam, kad ir pabeigtas visas lietojumprogrammas funkciju pārbaudes. Kad visi vienību testēšanas un funkciju testēšanas darbi ir pabeigti, izstrādātāji saprot, ka lietojumprogramma darbojas tā, kā viņi sagaida, vismaz ar visiem moduļiem, kas darbojas izolēti.
Melnās kastes testēšana nodrošina, ka visa lietojumprogramma pēc kompilēšanas darbojas, kā paredzēts, jo teorētiski viss pirmkods jau ir kārtībā.
Kādas ir atšķirības starp “pelēkās kastes” un “melnās kastes” testēšanu?
Galvenā atšķirība starp “pelēkās kastes” un “melnās kastes” testēšanu ir piekļuves apjoms, ko testētājs iegūst informācijai.
Dažos gadījumos “melnās kastes” testētājs var izmantot lietojumprogrammu bez jebkādām priekšzināšanām par programmatūru, vienkārši veicot testēšanas procesu un izmantojot programmatūru kā standarta lietotājs.
No otras puses, “pelēkās kastes” testētājam ir piekļuve daļai no projekta dokumentiem, tāpēc viņš var salīdzināt lietojumprogrammas iecerēto darbību ar tās reālo veiktspēju, sniedzot izstrādātājiem atgriezenisko saiti par to, kuras konkrētas lietojumprogrammas daļas neatbilst standartiem.
Vēl viena atšķirība ir laiks, kas nepieciešams, lai atrisinātu problēmu, jo pelēkās kastes testi aizņem nedaudz vairāk laika.
Dokumentācijas un koda salīdzināšana ar to, kā jūs lietojat lietojumprogrammu, var prasīt laiku, kas ir pretēji tam, kā strādā melnās kastes testētāji, vienkārši pārbaudot pašu lietojumprogrammu un visas funkcionalitātes problēmas. Šī kombinācija padara melnās kastes testēšanu par ideālu procesu, ko izmantot izstrādes procesa beigās, gatavojoties produkta izlaišanai, savukārt pelēkā kaste labāk darbojas lietotāja saskarnes izstrādes un kompilēšanas posmā.
3. Secinājumi: Pelēkās kastes vs. baltās kastes vs. melnās kastes testēšana
Noslēgumā jāsecina, ka “baltās kastes”, “pelēkās kastes” un “melnās kastes” testēšana ir viena un tā pati spektra daļa, kurā mainīgais faktors ir piekļuves līmenis, kas testētājam ir pieejams visā procesa gaitā.
Tā kā testēšanas forma kļūst arvien “melnāka”, testēšana kļūst arvien nepārredzamāka, jo piekļuve informācijai, kas ir programmatūras pamatā, ir ierobežota.
Baltās kastes testēšana ir ideāli piemērota agrīnākajiem procesa posmiem, savukārt melnās kastes testēšana ir ideāli piemērota tādiem posmiem kā testēšana no gala līdz galam, kurā tiek pārbaudīta visa lietojumprogramma no lietotāja perspektīvas.
Pelēkās kastes testēšana ir vidusceļš starp abām koncepcijām, kas palīdz atrast problēmas visā izstrādes procesa vidū, sniedzot lielāku ieskatu, vienlaikus saglabājot daļu no pirmkoda neskaidru no testētāja.
Pelēkās kastes testēšanas metodes
Pelēkās kastes testēšana ietver plašu metožu klāstu, no kurām katra paaugstina testēšanas standartu, ļauj izstrādātājam atrast vairāk kļūdu un procesa beigās nodrošina pilnīgāku produktu.
Dažas no biežāk izmantotajām “pelēkās kastes” testēšanas metodēm, ko izmanto QA komandas, ir šādas:
1. Matricas testēšana
Matricas testēšanā tiek pārbaudīts statusa ziņojums par projektu, kas ir procesā. Dažos gadījumos tas ietver vienkāršu PASS/FAIL stāvokli, bet notiekošie procesi sniedz sīkāku informāciju par to, kā procesi nepārtraukti darbojas.
Ja liela daļa testēšanas koncentrējas uz koda ieejas un izejas datiem, tad matricas testēšana pārbauda pašu procesu statusu, nevis minēto procesu rezultātus.
Izmantojot matricas testēšanu, lielāku uzmanību pievēršat pašai lietojumprogrammai, palīdzot atrast kļūdas un problēmas pat tad, ja rezultāti šķiet pareizi.
2. Regresijas testēšana
Regresijas testēšana tiek veikta, lai pārbaudītu programmatūru pēc vairāku atjauninājumu veikšanas. Tas ietver gan funkcionālos, gan nefunkcionālos testus, kas nodrošina, ka lietojumprogramma joprojām darbojas pietiekami augstā līmenī, kad mainās kods.
Testētāji, kas izmanto regresijas testēšanu, parasti izmanto automatizāciju, jo regresijas testu apjoms pieaug, jo kvalitātes nodrošināšanas komanda atklāj arvien vairāk defektu.
Tomēr dažos gadījumos ir nepieciešama manuāla testēšana, jo uzņēmumi, kas testē lietotāja saskarni, izmanto manuālus testus, lai redzētu, kā lietotājs reaģē uz izvēlņu, pogu un navigācijas iespēju izmaiņām.
3. Modeļu testēšana
Testēšana pēc parauga ir testēšanas veids, kurā galvenā uzmanība tiek pievērsta tam, lai katrā testā, ko veic organizācija, tiktu ievērots konkrēts paraugs.
Testēšanas komandas šos testus izstrādā tā, lai tie būtu vērsti uz katru programmatūras funkciju, un katrs tests uzņēmumam sniedz konsekventu informāciju par to, kā darbojas atsevišķas funkcijas.
Izmantojot modeļa testēšanu, dažkārt ir jāmaina modelis, lai pārliecinātos, ka jūs novērtējat katru no sistēmām, kas darbojas, bet, tiklīdz jums ir modelis, kas darbojas, izvairieties no novirzēm, lai nodrošinātu lielāku rezultātu konsekvenci.
4. Ortogonālo masīvu testēšana
Ortogonālā masīva testēšana galvenokārt ir uz melno kastīti orientēta testēšanas metode, kas tiek izmantota, ja testētāji izmanto ievērojamu skaitu ievades datu, kas ir pārāk liels, lai visaptveroši testētu katru sistēmu procesā.
Šādos gadījumos katrs atsevišķs datu elements sniedz savu unikālu informāciju, jo starp konkrētiem informācijas elementiem var trūkt savstarpējas saistības. Tas ir sistēmas ortogonālais aspekts, kurā tiek izmantoti unikāli informācijas elementi, lai nodrošinātu maksimālu datu apjomu, vienlaikus ieguldot minimālas pūles.
Samazinās testēšanas laiks, un jums ir ideāls datu līdzsvars, ko sniegt izstrādes komandai.
Pelēkās kastes testēšana programmatūras inženierijas dzīves ciklā
Pelēkās kastes testēšana ietilpst īpašā programmatūras inženierijas dzīves cikla posmā. Šis dzīves cikls ir sarežģīts posmu kopums, ko uzņēmumi veic, izstrādājot savus produktus, un katrs posms nodrošina augstāku produkta standartu.
Lai gan testēšana ir procesa daļa, kas notiek nepārtraukti, pelēkās kastes testēšanai ir ļoti ierobežots laiks.
Tas notiek pēc tam, kad sākotnējā funkcionalitāte ir pabeigta un pārbaudīta, izmantojot “baltās kastes” testēšanu, un pirms programmatūra ir gatava publiskošanai, bet uzņēmumi dod priekšroku “melnās kastes” testēšanai vēlākajos posmos.
Pelēkā kaste ir lielisks rīks, lai integrētu funkcijas kopā un nodrošinātu, ka tās darbojas ne tikai neatkarīgi, bet arī tandēmā.
Manuāli vai automatizēti pelēkās kastes testi?
Tāpat kā jebkura cita veida programmatūras testēšanā, kvalitātes nodrošināšanas komandas izvēlas, vai testēšanu veikt manuāli, piesaistot ekspertus, vai arī automātiski, kas ietver testēšanas gadījumu sērijas kodēšanu un to atkārtotu izpildi, lai nodrošinātu precīzu rezultātu kopumu.
Uzziniet vairāk par manuālo un automātisko testēšanu, kā arī par to priekšrocībām un problēmām, kā arī par to, kurš no abiem testēšanas veidiem ir ideāli piemērots uzņēmumam, kas vēlas labāk izprast sava produkta problēmas.
Manuālā pelēkās kastes testēšana – priekšrocības, izaicinājumi, process
Manuālā testēšana ir būtiska daudzu testēšanas veidu, tostarp pelēkās kastes testēšanas, daļa.
Šis process ietver cilvēku testētāju iesaistīšanu programmatūras pārbaudē, pārbaudot, vai programmatūra darbojas tā, kā jūs sagaidāt, un salīdzinot to ar jau esošajiem projekta dokumentiem un redzamo kodu, lai pārbaudītu, vai šajā informācijā nav acīmredzamu trūkumu, kas varētu radīt problēmas.
Manuālā testēšana parasti tiek veikta sarežģītākos programmatūras veidos, kuros nepieciešams cilvēks, lai sniegtu kvalitatīvu ieskatu.
Citi lietojumi ietver mazākus uzņēmumus, kas vēlas rūpīgi novērtēt savu programmatūru, jo nelielas lietojumprogrammas un pakotnes prasa salīdzinoši maz resursu, lai tās novērtētu, salīdzinot ar lielākām programmām, ko ražo lielāki uzņēmumi.
1. Manuālās pelēkās kastes testēšanas priekšrocības
Jebkurai programmatūrai ir vairākas priekšrocības, ko sniedz manuāla pelēkās kastes testēšana. Zinot šos ieguvumus, jūs varat mērķtiecīgi veikt testēšanu, atklājot vairāk problēmu savā programmatūrā un paaugstinot sava darba standartu, pateicoties labākam testēšanas režīmam.
Galvenie manuālās pelēkās kastes testēšanas ieguvumi ir šādi:
Sīki izstrādātas atsauksmes
Pirmais galvenais ieguvums, izmantojot manuālo pelēkās kastes testēšanu, ir tas, ka testētāji var nodrošināt izstrādātājam būtisku atgriezeniskās saites līmeni.
Izmantojot automatizētu testēšanu, testēšanas gadījumi tiek izstrādāti tā, lai atkal un atkal radītu ļoti specifiskus rādītājus, kas analītiķiem sniedz ieskatu, kad viņiem ir laiks novērtēt datus.
Izmantojot manuālo testēšanu, tas ir nedaudz atšķirīgi, jo testētājs var sniegt detalizētāku atgriezenisko saiti par to, kura konkrētā funkcija nedarbojās, un par iespējamiem problēmas iemesliem pēc salīdzināšanas ar projekta dokumentāciju.
Izmantojot detalizētu atgriezenisko saiti, var ne tikai atjaunināt esošās funkcijas, bet arī iespējamās jaunās funkcijas, ko testētājs iesaka lietotājiem.
Labākas interpretācijas
Automatizēta testēšana nozīmē, ka visi secinājumi ir atkarīgi no testā iegūto datu novērtēšanas un racionāla secinājuma par to, ko tie nozīmē programmatūrai.
Gluži pretēji, manuālajiem testētājiem ir daudz lielāka izpratne par to, kā darbojas pati lietojumprogramma.
Viņi var salīdzināt pelēkās kastes kodu ar reāllaikā notiekošo, veicot precīzu novērtējumu tajā brīdī, nevis veicot secinājumus pēc fakta.
Dažas automatizācijas platformas var darboties līdzīgi, izmantojot atkārtošanas funkciju, taču tas joprojām prasa manuālu iejaukšanos.
Elastīga testēšana
Testu automatizācija ietver ļoti specifisku testu gadījumu kodēšanu platformā, kas nozīmē, ka programmatūra atkārtoti un atkārtoti izpilda konkrēto uzdevumu kopumu.
Lai gan tas ir ideāli piemērots atkārtošanai, tas rada unikālu izaicinājumu, jo testēšana nav elastīga.
Šādos gadījumos ir ideāli izmantot cilvēku testētāju, jo tas palielina procesa elastīgumu. Ja testētājs pamana iespējamu problēmu, kas nedaudz atšķiras no šauri definēta testa gadījuma, viņš var to pārbaudīt un procesa beigās ziņot par rezultātiem.
Tas uzņēmumiem nodrošina visaptverošāku programmatūras pārklājumu, atklājot kļūdas, ko automatizēta sistēma nespēj izdarīt.
2. Ar manuālo pelēkās kastes testēšanu saistītie izaicinājumi
Lai gan manuālās testēšanas izmantošana programmatūras izstrādes procesā sniedz daudz priekšrocību, ir arī vairāki trūkumi. Tie atšķiras atkarībā no vairākiem faktoriem, tostarp no konkrētās programmatūras, ar kuru strādā uzņēmums, izstrādes komandas lieluma un testēšanas un izstrādes komandas locekļu prasmju līmeņa.
Nozīmīgas manuālās testēšanas problēmas ir šādas:
Augstas darbaspēka izmaksas
Darbaspēka izmaksas ir vieni no nozīmīgākajiem izdevumiem, kas rodas jebkurā uzņēmumā, jo uzņēmums maksā, lai iegūtu labākos pieejamos darbiniekus un varētu uzlabot sava darba kvalitāti.
Tā kā pelēkās kastes manuālā testēšana var aizņemt daudz laika, uzņēmumam ir jāmaksā saviem testētājiem par darbu visā procesa gaitā. Dažām lielākajām lietojumprogrammām tas var aizņemt vairākas stundas un palielināt manuālo testētāju izmaksas.
Izstrādātāji var mēģināt mazināt šo problēmu, līdzsvarojot “pelēkās kastes” testēšanas automatizāciju ar manuālo testēšanu vai samazinot stundas darbaspēka izmaksas, taču tas rada risku, ka samazināsies testēšanas kvalitāte.
Cilvēka kļūda
Automatizētā testēšana efektīvi veic vienkāršus procesus, atkārtojot tos ar augstu precizitātes pakāpi tā, kā to nevar izdarīt cilvēks.
Cilvēki pieļauj kļūdas un nelielas kļūdas, kas var būt gan nejaušas nepareizas pogas nospiešanas, gan uzmanības zuduma uz pāris sekundēm rezultāts.
Šādas kļūdas var novest pie neprecīziem datiem un likt izstrādātājiem pievērst uzmanību nepareizai programmatūras daļai, aizņemot dārgo izstrādes laiku un pasliktinot produkta kvalitāti.
Meklējiet, kā to atrisināt, veicot atkārtotus “pelēkās kastes” testus, lai, turpinot testēšanu, pārbaudītu rezultātus.
Aizņem ilgu laiku
Ja datori uzdevumus var paveikt vienā mirklī, tad cilvēkiem ir nepieciešams nedaudz vairāk laika.
Tas ir saistīts gan ar reakcijas laiku, gan arī ar to, ka dažos punktos vienkārši strādā lēnāk nekā optimālais ātrums, un tas viss palēnina testēšanas procesu.
Lēnāks testēšanas process nozīmē, ka izstrādes komandām ir mazāk laika, lai strādātu pie kļūdu un trūkumu novēršanas produktā, jo viss laiks tiek veltīts problēmu atklāšanai.
To nav viegli mazināt, un viens no iespējamiem risinājumiem ir hibrīda testēšanas režīms, piemēram, manuālo testu līdzsvarošana ar automatizētiem pelēkās kastes testiem.
Pelēkās kastes testēšanas automatizācija – ieguvumi, izaicinājumi, process
Testēšanas automatizācija ir automatizācijas platformas izmantošana, lai dažas pelēkās kastes testēšanas procesa daļas padarītu automātiskas.
Process darbojas tā, ka testu izstrādātājiem tiek uzdots izveidot virkni testu gadījumu, bet QA analītiķi vai līdzīgi speciālisti šos testus kodē automatizācijas programmās, dažos gadījumos kā papildu rīku izmantojot robotizētu procesu automatizāciju.
Šādos gadījumos QA analītiķi jau saprot daļu no koda vai projektēšanas dokumentiem.
Šāda veida testēšana ir biežāk sastopama daudz lielākos programmatūras komplektos, jo “pelēkās kastes” testētājiem nav laika, lai manuāli rūpīgi pārbaudītu visus procesa aspektus.
Pēc automatizēta procesa veikšanas platforma QA analītiķim sniedz ziņojumu, kurā norādītas kļūdas un virkne svarīgu rādītāju.
1. Automatizētas pelēkās kastes testēšanas priekšrocības
Automatizētas pelēkās kastes testēšanas izmantošana kvalitātes nodrošināšanas komandas procesos sniedz vairākas acīmredzamas priekšrocības.
Koncentrējoties uz šiem ieguvumiem un maksimāli izmantojot tos, uzņēmums var palielināt pelēkās kastes testēšanas efektivitāti un atrisināt pēc iespējas vairāk problēmu šajā darba procesa posmā.
Dažas no galvenajām priekšrocībām, ko sniedz automatizācijas izmantošana pelēkās kastes testēšanā, ir šādas:
Ātra testēšana
Automatizētās sistēmas ir izstrādātas tā, lai testēšana notiktu neticami ātri, pēc iespējas ātrāk veicot virkni procesu. Šī priekšrocība kļūst vēl pamanāmāka, veicot atkārtotus pelēkās kastes testus, jo katra atsevišķa darbība aizņem mazāk laika.
Ievērojami palielinās laika ietaupījums, kas tiek ietaupīts no vienas darbības līdz otrai, un jūsu uzņēmumam ir daudz vairāk laika, lai veiktu steidzamus uzdevumus, piemēram, atjauninātu pašu programmatūru un sniegtu atsauksmes klientiem un potenciālajiem klientiem.
Ātrāka testēšana ir īpaši noderīga, strādājot pēc izlaišanas, jo, lai uzlabotu to, kā cilvēki uztver uzņēmumu, ir nepieciešams pēc iespējas ātrāk ieviest funkcionalitātes labojumus.
Precīzi rādītāji
Metrikas ir nozīmīga programmatūras testēšanas darbības daļa, kas sniedz testētājam skaitlisku informāciju, lai norādītu uz iespējamām problēmām.
Datori un automatizācijas platformas piedāvā ļoti precīzus rādītājus, piemēram, reakcijas laiku var noteikt milisekundes precizitātē.
Precīzāki rādītāji nozīmē, ka varat izsekot nelielām izmaiņām lietotnes darbībā, palīdzot jums saprast, vai atjauninājums ir uzlabojis veiktspēju vai veicinājis standarta darba plūsmas ilgāku laiku.
Samazinātas izmaksas
Viena no lielākajām testēšanas izmaksām programmatūras pelēkās kastes izstrādes vidē ir pašu pelēkās kastes testētāju izmaksas.
Programmatūras testēšanas ekspertu nolīgšana ir dārga, jo īpaši, ja meklējat “pelēkās kastes” testētājus, kam nepieciešamas daudzveidīgākas prasmes, lai nodrošinātu jūsu organizācijai visaugstākos iespējamos standartus.
Automatizācija nozīmē, ka ir mazāk cilvēku, kas manuāli veic “pelēkās kastes” testus, tādējādi novēršot daudz personāla izmaksu.
Lai gan automatizācijas platformām ir zināmas izmaksas, un vairums no tām iekasē ikmēneša abonēšanas maksu, tās ir daudz zemākas nekā maksājumi darbiniekiem, kas veic darbu jūsu vietā.
2. Automatizētas pelēkās kastes testēšanas problēmas
Automatizācijas izmantošana pelēkās kastes testēšanas procesos ir saistīta ar daudziem izaicinājumiem.
Lai gan dažas organizācijas koncentrējas uz ieguvumiem, ir daudz priekšrocību, ja zināsiet par pelēkās kastes testēšanas izaicinājumiem un ņemsiet tos vērā, strādājot.
Jūs varat īstenot pelēkās kastes testēšanu tā, lai izvairītos no problēmām un izvairītos no turpmākas cīņas ar ierobežojumiem.
Automatizētas pelēkās kastes testēšanas galvenās problēmas ir šādas:
Sākotnējā iestatīšana
Sākotnējā iestatīšana ir viens no lielākajiem automatizācijas procesa izaicinājumiem. Tas attiecas uz laiku, kas nepieciešams pārejai uz jaunu testēšanas platformu, tostarp platformas instalēšanu, lietotāju apmācīšanu, kā ar to strādāt, un agrīno testu kodēšanu programmatūrā.
Tas viss ir neproduktīvs laiks, ko uzņēmums vēlas pēc iespējas vairāk ierobežot.
Šajā gadījumā ir ideāli izmantot augstākās klases automatizācijas programmatūru, kurā vajadzības gadījumā ir pieejami eksperti, jo jums ir trešās puses atbalsts, kas nodrošina, ka pelēkās kastes automatizācija un cita veida testēšana jau no paša sākuma norit gludi.
Augstas prasmju prasības
Lai gan manuālā testēšana prasa augstu prasmju līmeni, QA analītiķiem, kas strādā ar automatizāciju, joprojām ir nepieciešamas augsta līmeņa prasmes.
Tas izpaužas kā kodēšanas prasmes, kas galvenokārt tiek izmantotas, lai izveidotu testēšanas gadījumus un nolasītu kodu, kas ir pieejams pelēkās kastes scenārijā.
Izstrādātāji var mazināt šo problēmu, īpaši pieņemot darbā testētājus, kuriem ir pieredze izstrādē vai kuri iepriekš ir strādājuši ar kodēšanas projektiem. Jūs ierobežojat apmācības laiku darba vietā un nodrošināsiet, lai katrs jaunais darbinieks spētu pielāgoties pelēkās kastes automatizētās testēšanas prasībām.
Dažu uzņēmumu mērķis ir izmantot bezkodēšanas automatizācijas sistēmu, lai veiktu “pelēkās kastes” testēšanu kā alternatīvu, taču tas var mazināt elastību darba vietā.
Pastāvīga uzraudzība
Automatizētā testēšana daļēji pastāv, lai novērstu nepieciešamību paļauties uz cilvēkiem, jo manuālā testēšana ir saistīta ar pastāvīgu cilvēku iesaistīšanu procesos.
Testēšanas automatizācijas gadījumā tas nav paredzēts, taču uzņēmumiem joprojām ir nepieciešama laba līmeņa pārraudzība.
Uzraudzība ietver pelēkās kastes testu rezultātu pārbaudi un to uzturēšanu, lai pārliecinātos, ka viss joprojām darbojas tā, kā izstrādātājs ir paredzējis.
Uzņēmumi var palīdzēt uzlabot pieejamo pārraudzības standartu vairākos veidos, un ideāli būtu, ja par testu pārraudzību būtu atbildīgs viens speciālists.
Tādējādi tiek paaugstināts specializācijas līmenis, un darbinieks ātrāk un efektīvāk kļūst par pelēkās kastes ekspertu testētāju darbā ar automatizāciju.
Secinājums: Manuālā vai pelēkās kastes testēšanas automatizācija?
Nobeigumā jāsecina, ka gan manuālai pelēkās kastes testēšanai, gan automatizētai testēšanai ir sava vieta programmatūras testēšanas procesā.
Mazāki uzņēmumi un jaunuzņēmumi gūst labumu no pelēkās kastes manuālās testēšanas, ja to kods ir salīdzinoši neliels un pārvaldāms, bet automatizācija kļūst arvien noderīgāka, jo lietojumprogrammas turpina augt un tām ir vairāk funkciju.
Tomēr vienmēr būs vieta manuālajai testēšanai, jo tā uzņēmumiem sniedz lielāku ieskatu, detalizētību un elastību.
Ideāls “pelēkās kastes” risinājums jebkuram uzņēmumam ir hibrīda modelis, kurā dažādās vietās tiek izmantota manuāla un automatizēta testēšana, lai ņemtu vērā abu metožu stiprās un vājās puses.
Holistiskā pieeja atklāj vairāk programmatūras paketes problēmu, palīdzot efektīvāk novērst programmatūru un galu galā nodrošinot klientiem daudz labāku produktu izstrādes beigās.
Kas nepieciešams, lai sāktu pelēkās kastes testēšanu?
Ir daži priekšnoteikumi, kas uzņēmumiem ir nepieciešami pirms pelēkās kastes testēšanas procesa uzsākšanas. To esamība vai nu padara testēšanas procesu iespējamu, vai arī padara programmatūras testēšanu daudz vienkāršāku kvalitātes nodrošināšanas komandai, jo tās rīcībā ir vairāk līdzekļu.
Priekšnosacījumi pelēkās kastes testēšanas veikšanai ir šādi:
1. Projektēšanas dokumenti vai pirmkods
Lai sāktu pelēkās kastes testēšanas procesu, vispirms ir nepieciešama vai nu projekta dokumentācija, vai avota kods. Testētājiem ir jābūt iespējai piekļūt šai informācijai, lai testēšanu varētu uzskatīt par pelēkās kastes testu, kas sniedz zināmu ieskatu pašas programmatūras iekšējā darbībā.
Šī informācija parasti ir pēc iespējas atbilstošāka, piemēram, konkrētās funkcijas, kuru testētājs pārbauda, koda virkne.
Izmantojot “pelēkās kastes”, nevis “baltās kastes” testēšanu, jūs sniedzat tikai daļu no koda un projekta dokumentācijas, tāpēc esiet uzmanīgi attiecībā uz piekļuves līmeni, ko sniedzat.
2. Produkta kopsavilkums
Produkta kopsavilkums vai lietojumprogrammas kopsavilkums ir dokuments, ko uzņēmumi izmanto, lai gūtu pilnīgu izpratni par to, ko klients meklē programmatūras paketē. Tajā ir sīki izklāstīta precīza funkcionalitāte, ko klients vēlas saņemt no programmatūras, kā arī klienta pieprasītais dizains un citas nepieciešamās specifikācijas.
Produkta apraksta izlasīšana nozīmē, ka pelēkās kastes testētājs var meklēt visas funkcijas, ko klients vēlas, pārliecinoties, ka tās ir programmatūrā, un nodrošinot, ka produkts atbilst visiem uzņēmuma mērķiem, kas izvirzīti attiecībā uz lietojumprogrammu.
Daži uzņēmumi ierobežo informācijas apjomu, ko pelēkās kastes testētāji var redzēt, atkarībā no uzņēmuma konfidencialitātes politikas.
3. Testa mērķi
Izstrādātājiem un uzņēmumiem, veicot testus, ir konkrēti mērķi, ko dažkārt dēvē par testu specifikāciju. Tas ir ļoti svarīgi pelēkās kastes testēšanas procesā, jo tas nozīmē, ka izstrādātāji var sniegt pelēkās kastes testētājiem visu pareizo informāciju, bet kvalitātes nodrošināšanas komanda izstrādā testus, kas atbilst testēšanas procesa mērķiem.
Šādā gadījumā visi strādā efektīvāk, jo zina, ko meklē un kā vislabāk sasniegt šos mērķus.
Pelēkās kastes testēšanas process
Pelēkās kastes testēšana notiek pēc salīdzinoši konsekventa procesa, kurā ir skaidri norādīti atsevišķi posmi, kas uzņēmumam jāizpilda, lai sasniegtu testēšanas mērķus.
Skaidra un konsekventa procesa ievērošana nodrošina precīzus un konsekventus rezultātus, kas informē izstrādātājus par problēmām un to, kā tās var atrisināt.
Galvenie pelēkās kastes testa posmi ir šādi:
1. Ieejas un izejas datu noteikšana
Pirmais solis šajā procesā ir ievades un izvades datu, ko sagaidāt no lietojumprogrammas, noteikšana.
Izvēlieties ievades datus, kas nepārsniedz to, ko no lietotnes varētu sagaidīt, lai nodrošinātu taisnīgu testu, un noskaidrojiet, kādu rezultātu sagaidāt no šiem ievades datiem.
Veicot šo prognozēšanu projekta sākumā, jūs zināt, vai testēšanas beigās kaut kas nav aizgājis greizi.
2. Identificēt primārās plūsmas
Primārās plūsmas ir maršruti, pa kuriem dati programmatūrā sasniedz galīgo rezultātu.
Primārās plūsmas identificēšana nozīmē, ka varat labāk izsekot, kā informācija tiek virzīta cauri programmatūras procesiem, nosakot iespējamās nepilnību jomas un strādājot pie to novēršanas, ja programmatūrā ir problēmas.
3. Identificējiet apakšfunkcijas ar ievades un izejas datiem.
Apakšfunkcijas ir pamatdarbības primārajā plūsmā. Katra apakšfunkcija ir atkarīga no citas apakšfunkcijas, un no tās ir atkarīga nākamā apakšfunkcija, kas galu galā noved pie programmatūras galīgās izejas.
Nosakiet, kādiem jābūt katras apakšfunkcijas ievades datiem, kā arī katras apakšfunkcijas prognozēto izlaidi.
Ja to darāt apakšfunkciju līmenī, tas sniedz papildu ieskatu, meklējot programmatūras problēmas.
4. Izstrādāt testa gadījumu
Testa gadījums ir programmatūrā notiekošu notikumu kopums, kas pārbauda, vai lietojumprogramma darbojas, kā jūs sagaidāt.
Pārliecinieties, ka šis pelēkās kastes testa gadījums pienācīgi pārbauda apskatāmo programmatūras daļu.
Pievērsiet uzmanību arī konsekvencei, pārliecinoties, ka testa gadījumu ir viegli atkārtot, lai iegūtu precīzākus pelēkās kastes testa rezultātus.
5. Palaist testa gadījumu
Sākt testa gadījuma izpildi.
Tas nozīmē ievadīt ievaddatus katrā no apakšfunkcijām un redzēt, kādi ir rezultāti, un pierakstīt visus rezultātus.
Automatizētā pelēkās kastes testēšanā ierakstīšanas process ir automātisks, un manuāli testētāji paši veic visu ievades un izvades datu pierakstus.
Ja varat, pārbaudiet visas apakšfunkcijas atsevišķi, pirms palaist visu plūsmu uzreiz, lai pārliecinātos, ka katra funkcija darbojas neatkarīgi.
6. Pārbaudiet rezultātus
Pēc tam, kad esat saņēmis datus no testa gadījuma, sāciet pārbaudīt šos rezultātus.
Tas nozīmē aplūkot rezultātus, ko saņemat no programmatūras, un salīdzināt tos ar rezultātiem, ko gaidījāt procesa sākumā.
Ja starp abiem rādītājiem ir kāda atšķirība, tas norāda, ka programmatūrā varētu būt kļūda, jo tā nedarbojas tā, kā sākotnēji prognozējāt.
7. Izveidojiet pārskatu
Pelēkās kastes testēšanas procesa beigās izveidojiet pārskatu par testa rezultātiem.
Tas ietver pamata kopsavilkumu par to, kādas bija problēmas ar programmatūru, dažu iespējamo problēmu risinājumu novērtējumu un, ja iespējams, visus testos iegūtos datus.
Izmantojot šo struktūru, lasītājam tiek sniegta galvenā pamācība, pirms tiek sniegti visi nepieciešamie pierādījumi, un galu galā tas ir saskanīgs dokuments, kas sniedz daudz norādījumu.
Labākā pelēkās kastes testēšanas prakse
Labākā prakse attiecas uz procesiem, uzdevumiem un principiem, ko darbinieki veic kvalitātes nodrošināšanas testā, lai sasniegtu visaugstākos iespējamos standartus.
Dažas no šīm labākajām praksēm QA komandām, kas vēlas paaugstināt sava darba standartus, ir šādas:
1. Rūpīgi strādājiet
Tāpat kā ar jebkuru testēšanas metodi, nesteidzieties un strādājiet uzmanīgi. Viena vienīga kļūda var padarīt testu nederīgu, tāpēc, lai nodrošinātu, ka jūsu darbs ir precīzs, strādājiet lēni un neatlaidīgi, tādējādi ilgtermiņā ietaupot laiku un vienlaikus uzlabojot programmatūras standartu. Tas jo īpaši attiecas uz pelēkās kastes testēšanu, jo jūs nezināt, ar kurām avota koda daļām jūs strādājat jebkurā brīdī.
2. Pastāvīgi sazinieties
Starp izstrādātājiem un pelēkās kastes testētājiem ir jābūt pastāvīgai saziņas ķēdei. Tas nodrošina izstrādātājiem tūlītēju atgriezenisko saiti par jebkādām kļūdām, ko atklāj testēšanas komanda, un nozīmē, ka testētāji zina, kam jāpievērš uzmanība.
Ja kļūda ir daļa no pelēkā lauka redzamā aspekta, paziņojiet izstrādātājiem, kur tieši tā atrodas.
3. Nosakiet stingrus ierobežojumus
Ja “pelēkās kastes” testēšanā tiek izmantoti mākslīgi noteikti informācijas ierobežojumi un uzņēmums pats lemj, kādu informāciju sniegt testētājiem, pārliecinieties, ka jums ir noteikti stingri ierobežojumi.
Piešķiriet kvalitātes nodrošināšanas komandai tikai tās atļaujas, kas tai ir nepieciešamas, pretējā gadījumā riskējat, ka viņi “ielūkosies aiz priekškara” un redzēs daļu no avota koda vai izstrādes dokumentiem, kurus jūs mēģināt paturēt apslēptus.
7 kļūdas un slazdi, īstenojot pelēkās kastes testus
Katru gadu testēšanas procesā tiek pārbaudīti simtiem tūkstošu lietojumprogrammu, tāpēc kvalitātes nodrošināšanas komandas pieļauj dažas kļūdas un slazdus.
Zinot par tām, varat efektīvi izvairīties no tām, uzlabojot savu darbu un samazinot iespēju izšķērdēt resursus nepareizām testēšanas stratēģijām.
Dažas no visbiežāk sastopamajām kļūdām un nepilnībām pelēkās kastes testos ir šādas:
1. Izplatīto sistēmu testēšana
Pelēkās kastes testēšanai ir nepieciešama piekļuve pirmkodam, un izplatītajos serveros tiek izmantots kods no citām vietām. Tas rada problēmas “pelēkās kastes” testēšanā, jo tas nozīmē, ka pastāv problēmas, kuras testētāji var nespēt pamanīt.
2. Neatbilstošas testēšanas pabeigšana
Nekonsistenta testēšana attiecas uz situāciju, kad testa gadījums mainās starp testēšanas reizēm. Tas var radīt neprecīzus rezultātus, un izstrādātāji tad koncentrējas uz veiktspējas uzlabošanu, pamatojoties uz nepareiziem rādītājiem.
Ja iespējams, veiciet identiskus testus, lai palielinātu testēšanas precizitāti un pareizību.
3. Steidzīga testu kārtošana
Ja tuvojas plānotais produkta izlaišanas datums, kvalitātes nodrošināšanas komandas var būt kārdinājums pasteidzināt “pelēkās kastes” testēšanas procesus.
Tomēr tā ir sliktas plānošanas pazīme, un uz to nevajadzētu reaģēt ar vēl sliktākiem lēmumiem. Pārsteidzīga testēšana noved pie neprecīziem rezultātiem un laika izšķērdēšanas vēlāk izstrādes posmā.
4. Manuālas un automatizētas darbības neīstenošana kopā
Ne manuālā testēšana, ne automatizētā testēšana nav ideālas pelēkās kastes testēšanas metodes.
Ja abas šīs metodes izmantojat paralēli, varat ņemt vērā ar katru no tām saistītās problēmas, tādējādi strādājot efektīvāk.
Vismaz apsveriet abu metožu apvienošanu, lai uzlabotu testēšanas kvalitāti.
5. Darbs bez instrumentiem
Testēšanas rīki ir izstrādāti tā, lai pēc iespējas atvieglotu pelēkās kastes testētāja darbu. Strādājot bez jebkādiem rīkiem, nevajadzīgi ierobežojat savas iespējas.
Rūpīgi izpētiet un iegādājieties visus rīkus, kas varētu palīdzēt jūsu izstrādē, lai palielinātu efektivitāti un samazinātu kļūdu iespējamību.
6. Slikta saziņa
Iekšējā saziņa starp nodaļām var būt sarežģīta, taču pēc iespējas skaidrāka saziņa starp testēšanas un izstrādes nodaļām ir obligāta.
Labāka saziņa nozīmē, ka izstrādātāji zina, kādi uzlabojumi jāveic nekavējoties, un var atrisināt problēmas, neļaujot sevi maldināt sliktas iekšējās saziņas dēļ.
7. Aktīva kļūdu meklēšana
Pelēkās kastes testi tiek veikti, lai atrastu kļūdas, ja tādas pastāv, kā arī lai pārbaudītu programmatūras vispārējo veiktspēju.
Pārāk ilgs laiks, kas veltīts kļūdu meklēšanai, var aizņemt daudz laika un novērst uzmanību no galvenā mērķa – uzlabot lietotnes darbību.
Pelēkās kastes testu rezultātu veidi
Pelēkās kastes testi procesa beigās ģenerē vairāku veidu informāciju. Tas neattiecas uz pašas programmatūras rezultātiem, bet gan uz datiem, kurus izstrādātāji var izmantot, lai uzlabotu programmatūru.
Galvenie produkcijas veidi ir šādi:
1. PASS/FAIL ziņojumi
Vienkāršs PASS/FAIL ziņojums, kas informē izstrādātāju par to, vai programmatūras darbība ir bijusi veiksmīga.
Šāda veida rezultāti nesniedz izstrādātājam lielu ieskatu, taču pelēkās kastes testēšanas izmantošana nozīmē, ka testētājs var redzēt, kurā konkrētā brīdī programmatūra nav darbojusies un kāpēc, tādējādi palīdzot atrisināt problēmu.
2. Metrikas
Metrikas attiecas uz vienkāršu statistiku, kas raksturo notikumu, piemēram, laiku, kas nepieciešams, lai izpildītu konkrētu uzdevumu, ar precizitāti līdz milisekundēm. Tie ir izplatīti automatizētajā pelēkās kastes testēšanā, kad datoru platformas automātiski apkopo šo informāciju ar lielāku precizitāti, nekā to varētu izdarīt manuāli testētājs.
Šī informācija ir noderīga, lai noteiktu lietotnes veiktspēju.
3. Kvalitatīvie dati
Aprakstoša informācija, ko saņemat no pelēkās kastes testētāja, pamatojoties uz viņa pieredzi ar programmatūru. Neizsakāmi skaitļos, kas apgrūtina analīzi, bet nodrošina labāku ieskatu lietotāja pieredzē un padara klientus ērtāk lietojamus ar programmatūru.
Pelēkās kastes testu piemēri
Dažos gadījumos teorijas pārzināšana par kādu testēšanas veidu nesniedz pietiekamu ieskatu un nenodrošina pienācīgu izpratni. Lai labāk izprastu, kā darbojas testēšanas metodoloģija, ir svarīgi zināt dažus pelēkās kastes testu piemērus.
Zemāk skatiet dažus pelēkās kastes testu piemērus, kuros sniegta sīkāka informācija par testiem reālajā pasaulē un par to, kā teorija piemērojama praktiskajās darba vietās.
1. Veiksmīgas drošības testēšanas piemērs
Uzņēmums izveido datubāzi ar daudziem personas datiem un plāno drošības testēšanu, lai pārliecinātos, ka lietotāju dati ir aizsargāti.
Manuālais testētājs veic testēšanu, meklējot iespējamos trūkumus kodā un iespējas piekļūt lietojumprogrammas daļām.
Pēc vājās vietas atklāšanas testētājs informē izstrādātāju par to, kur ir vājā vieta un kā to izmantoja.
Kad programmatūra ir labota, testētājs vēlreiz veic to pašu testu, lai pārliecinātos, ka sistēma ir droša.
2. Neveiksmīgas datubāzes testēšanas piemērs
Izstrādātājiem, kas veido datubāzi, ir noteikts īss izdošanas termiņš, un viņiem ir ātri jāveic testēšana.
Testētāji steigšus sastāda dažus pamata testēšanas gadījumus un ātri tos izpilda, pieļaujot kļūdas to izpildē, nesagatavo izvades prognozes un nepārbauda apakšfunkcijas.
Tā kā viņi nesagatavo izvades prognozes, viņi neapzinās izvades problēmas, nosūtot produktu, kas rezultātā nedarbojas pareizi.
Kļūdu un kļūdu veidi, kas atklāti, izmantojot pelēkās kastes testēšanu
Viens no galvenajiem “pelēkās kastes” testēšanas mērķiem ir atrast kļūdas un defektus programmā, jo uzņēmumi cenšas nodrošināt augstas klases lietojumprogrammas, uz kurām klienti var paļauties, kad vien iespējams.
Ir daži specifiski kļūdu un kļūdu veidi, ko testētāji var atrast “pelēkās kastes” testēšanas procesā, un katrs no tiem var norādīt uz atšķirīgu problēmu kodā.
Veicot pelēkās kastes testēšanu, tiek atklāti šādi kļūdu un kļūdu veidi:
1. Procesa kļūme
Pirmais kļūdas veids ir procesa kļūda.
Tas attiecas uz gadījumiem, kad tests neatgriež nekādu rezultātu un vienkārši sabrūk.
Pastāv vairāki iespējamie šo problēmu cēloņi, un ideālā gadījumā “pelēkās kastes” testētājs var noteikt, no kurienes rodas problēma un kā izstrādātājs var uz to reaģēt.
2. Nepareizs izvads
Dažas pelēkās kastes testēšanas kļūdas rodas, ja procesa izvades rezultāts nav tāds, kādu to paredzēja izstrādātāji.
Tā ir nopietna problēma tādos gadījumos kā datubāze, kur ir nepieciešams droši glabāt pareizu informāciju.
3. Drošības kļūdas
Drošības kļūdas rodas, ja uzņēmuma lietojumprogramma ir nedaudz nedroša un ļauj trešajām personām piekļūt tajā esošajai informācijai.
Drošības nepilnības lietojumprogrammā var būt GDPR problēma un padarīt lietojumprogrammu neatbilstošu virknei starptautisko noteikumu.
Bieži sastopamie pelēkās kastes testēšanas rādītāji
Metrikas attiecas uz pastāvīgiem mērījumiem, kas pārbauda noteiktu notikumu vai notikumu virkni, parasti kvantitatīvu datu veidā.
Izmantojot metriku, testētāji un kvalitātes nodrošināšanas komandas var pārbaudīt programmatūru, kas tiek pārbaudīta “pelēkajā kastē”, un precīzi redzēt, kas notiek nepareizi – vai tas izpaužas kā lielāks kļūdu skaits, vai dažādu funkciju ielādēšana aizņem vairāk laika.
Dažas no visbiežāk sastopamajām “pelēkās kastes” testēšanas metrikām, ko QA testētāji izmanto, novērtējot programmatūru, ir šādas:
– Izvades laiks:
Laiks, kas nepieciešams, lai lietojumprogramma pēc testa sākuma radītu rezultātu.
– Reakcijas laiks:
Laiks, kas nepieciešams, lai programmatūra reaģētu uz lietotāja ievadītajiem datiem – vai nu kā rezultāts, vai vienkārši kā ievadīto datu apstiprinājums.
– Kļūdu skaits:
Programmatūras procesos konstatēto kļūdu skaits.
– Kļūdas katrā funkcijā:
Lai noteiktu kļūdu blīvumu, kļūdu skaits tiek dalīts ar programmatūras funkciju skaitu.
Labākie pelēkās kastes testēšanas rīki
Pelēkās kastes testēšana var paļauties uz ārējiem rīkiem, lai uzlabotu jūsu darba kvalitāti, automatizējot dažus procesus un palīdzot jums, kad radāt jebkuru atrasto kļūdu labojumu.
Jo labāku testēšanas rīku izmantosiet, jo vairāk problēmu atklāsiet un jo labāks būs jūsu galaprodukta standarts, turklāt testēšanas laikā ietaupīsiet laiku un resursus.
Zemāk apskatiet dažus no labākajiem pelēkās kastes testēšanas rīkiem, kā arī katras platformas izmantošanas priekšrocības un trūkumus.
5 labākie bezmaksas pelēkās kastes testēšanas rīki
Ja mazāks uzņēmums vēlas sākt pelēkās kastes testēšanu, ir svarīgi, lai tam būtu pieejami pareizie rīki, bet tikpat svarīgi ir, lai tie būtu pieejami par saprātīgu cenu. Mazajā uzņēmumā ir svarīgs katrs cents, un ne citādi ir arī ar lietotņu izstrādātājiem, kuriem ierobežotais budžets liek pieņemt sarežģītus lēmumus.
Bezmaksas pelēkās kastes testēšanas rīku izmantošana ir ideāli piemērota kvalitātes nodrošināšanai ar minimāliem resursiem.
Daži no labākajiem bezmaksas pelēkās kastes testēšanas rīkiem ir šādi:
1. ZAPTEST BEZMAKSAS IZDEVUMS
ZAPTEST bezmaksas izdevums lietotājiem piedāvā augstas kvalitātes automatizācijas pieredzi ar pilnu programmatūras automatizāciju, kas atbalsta testēšanu no paša izstrādes sākuma.
Izmantojot paralēlo izpildi, varat veikt vairākus testus vienlaicīgi, lai paātrinātu procesus, un, kad esat gatavs pāriet uz nākamo līmeni, Enterprise izdevums padara pāreju tik vienkāršu, cik vien iespējams. Kā papildu ieguvums ZAPTEST bez papildu maksas piedāvā arī modernāko RPA tehnoloģiju.
Ideāla izvēle tiem, kas vēl tikai sāk testēšanas procesu.
2. Appium
Appium ir pamatīgs testēšanas rīks, kas izstrādāts, lai palīdzētu pārliecināties, vai mobilās lietotnes atbilst standartiem, un tam ir aktīva atbalsta kopiena, taču tas testus izpilda salīdzinoši lēni. Tas nav labākais bezmaksas rīks daudziem uzņēmumiem, jo ir sarežģīti to iestatīt.
3. Chrome Dev rīki
Google Chrome piedāvā virkni tīmekļa lietojumprogrammu izstrādes rīku, un, pateicoties integrācijai populārākajā pārlūkprogrammā, šķiet, ka tas ir obligāti nepieciešams.
Tomēr tas aprobežojas tikai ar kastes elementu testēšanu, tāpēc tas ir ierobežojošs testēšanas rīks.
4. JUnit
JUnit ir atvērtā pirmkoda ietvars, kas ļauj lietotājiem atkal un atkal veikt atkārtojamus testus Java valodā, ierobežojot to ar vienu valodu.
Pats par sevi šis ierobežojums nav problēma, taču tas, ka nav vienkāršas API un saskarnes, jaunākos testētājus var atturēt.
5. DBUnit
DBUnit koncentrējas uz datubāzes orientētu projektu atbalstu, izmantojot zināmus stāvokļus, lai precīzi pārbaudītu rezultātus un visaptveroši pārbaudītu rezultātus.
Tas ir lieliski piemērots datu bāzēm un līdzīgām lietojumprogrammām, taču integrācijas atbalsta trūkums nozīmē, ka tas rada grūtības starpplatformu uzdevumu veikšanā.
5 labākie uzņēmumu pelēkās kastes testēšanas rīki
Augot izstrādātājam, pieaug arī tā testēšanas prasības, jo lielākiem uzņēmumiem ir lielākas lietojumprogrammas, tāpēc tiem ir nepieciešami visaptverošāki testēšanas komplekti.
Uzņēmumu pelēkās kastes testēšanas rīki pastāv, lai atbalstītu uzņēmumus šādā situācijā, nodrošinot plašāku piekļuvi uzlabotām funkcijām, kas amatieriem un neliela mēroga izstrādātājiem var nebūt nepieciešamas.
Daži no labākajiem uzņēmuma klases testēšanas rīkiem, kas ļauj veikt pelēkās kastes testu, ir šādi:
1. ZAPTEST ENTERPRISE EDITION
ZAPTEST Enterprise versija nodrošina plašākas testēšanas iespējas nekā bezmaksas versija, un viena no galvenajām priekšrocībām ir pastāvīga piekļuve ZAP ekspertam. ZAP eksperts darbojas kā konsultants un jūsu komandas loceklis attālināti, atbalstot visas jūsu uzņēmuma testēšanas vajadzības.
Izstrādātāji, kas iegulda ZAPTEST Enterprise izdevumā, var gūt līdz pat desmitkārt lielāku peļņu no ieguldījumiem, pateicoties uzlabotām datorredzes tehnoloģijām, 1SCRIPT, starpplatformu, starpierīču un pārlūkprogrammu izpildei un, pats galvenais, neierobežotām licencēm.
Neierobežots licenču skaits, kā arī vismodernākās testēšanas un RPA tehnoloģijas nozīmē, ka uzņēmumi gūst labumu no fiksētām izmaksām neatkarīgi no tā, cik ātri un cik ļoti tie aug.
2. TestRail
Testēšanas gadījumu pārvaldības risinājums, kas ļauj sadalīt visus veiktos testus pa testēšanas gadījumiem, precīzāk reģistrējot datus.
Tomēr TestRail ne vienmēr ir ideāli piemērots “pelēkās kastes” testēšanai, jo tajā ir grūti sabalansēt manuālo testēšanu ar automātisko testu reģistrēšanu.
3. Tests
Testēšanas platforma, kas koncentrējas uz stabilu pielāgotu testu piedāvāšanu, īstenojot gan kodētus testēšanas gadījumus, gan nekodētus alternatīvus testus.
Tā kā šī platforma ir bezmaksas tikai noteiktam testu skaitam mēnesī, lielākām organizācijām var būt grūti izmantot šīs platformas priekšrocības.
4. TestRigor
TestRigor ir plaši atzīta platforma, kas testu veikšanai izmanto mākslīgā intelekta dzinēju, un viena no tās pievilcīgākajām funkcijām ir mākslīgā intelekta testu uzturēšana.
Tomēr tas ir saistīts ar ievērojamu cenu, jo citas platformas nodrošina labāku ieguldījumu atdevi.
5. Kobiton
Kobiton ir testēšanas platforma, kas ir samērā elastīga cenu ziņā, jo pēc bezmaksas izmēģinājuma testa pabeigšanas testus automatizē par katru lietotāju.
Dažiem lietotājiem bažas par Kobiton rada tas, ka Kobiton nesniedz relatīvi pietiekamu atbalstu, lai atrisinātu testētāju jautājumus.
Kādos gadījumos jāizmanto uzņēmuma rīki salīdzinājumā ar bezmaksas pelēkās kastes rīkiem?
Gan uzņēmumu, gan bezmaksas pelēkās kastes rīki saviem lietotājiem sniedz daudz priekšrocību. Vislabāk, ja uzņēmumi sāk ar bezmaksas produktu, lai apgūtu testēšanas procesu, un pēc tam, palielinoties vajadzībām, pāriet uz uzņēmuma versiju.
Tas nodrošina projekta nepārtrauktību, ierobežojot darbinieku pārkvalifikācijas apjomu.
Pārejas brīdis katrā uzņēmumā ir atšķirīgs, taču noteiktā brīdī uzņēmuma produkta investīciju atdeve kļūst neizbēgama.
Pelēkās kastes testēšanas kontrolsaraksts, padomi un triki
Pelēkās kastes testēšana ir diezgan sarežģīts process, tāpēc, izmantojot kontrolsarakstu, varat pārliecināties, ka testēšanā esat izdarījis visu nepieciešamo.
Dažas no galvenajām pelēkās kastes pārbaudes saraksta iezīmēm, kā arī daži padomi, kā uzlabot testēšanas kvalitāti, ir šādi:
1. Rūpīga plānošana
Visaptveroša plānošana ir viena no pirmajām lietām, kas jāizsver testā, jo ir obligāti jāplāno pilnīgi visi testa aspekti.
Jo vairāk plānojat, jo strukturētāka ir jūsu testēšana, jo cilvēki zina, kādus testus viņi veic un kad tos veic.
Tādējādi tiek iegūti arī konsekventi dati, kas ir ideāli piemēroti, lai izstrādātu labākus izstrādātāju risinājumus.
2. Tūlītēja datu ziņošana
Strādājot pie pelēkās kastes testēšanas procesa, mēģiniet uzreiz ziņot datus. Izveidojot pārskatus pēc iespējas ātrāk, jūs paaugstināt pārskatu sagatavošanas procesu precizitāti, jo visa informācija ir svaiga jūsu atmiņā.
Tas jo īpaši attiecas uz kvalitatīvo informāciju, jo tā ir jāraksta testētājam, nevis vienkārši jāuzglabā testēšanas platformā.
3. Nosakiet pienākumus
Visā testēšanas procesā pārliecinieties, ka ikviens darba vietā koncentrējas uz konkrētiem pienākumiem. Šādi nosakot pienākumus, katrs zina, kāda ir viņa loma darbavietā, un saprot, kā produktīvi un ar minimāliem pārtraukumiem veikt savus uzdevumus.
Lai gan tas ir vairāk vadības koncepcija, nevis pārbaudes kontrolsaraksta punkts, tam ir būtiska ietekme uz rezultātiem.
4. Pastāvīgs salīdzinājums
Salīdziniet savus rezultātus ar vairākām lietām gandrīz nepārtraukti. Salīdzinājumam var izmantot sākotnējo projekta dokumentāciju, iepriekšējās testēšanas rezultātus un organizācijas projekta pabeigšanas grafiku.
Šādu atskaites punktu esamība pastāvīgi informē jūs par to, kā norit programmatūras izstrādes process, uzlabojamām jomām un iespējamām korekcijām, kas jāveic.
Secinājums
Nobeigumā jāsecina, ka pelēkās kastes testēšana ir viens no visdaudzpusīgākajiem pieejamajiem testēšanas veidiem, kas apvieno baltās kastes funkcionalitāti ar melnās kastes testu neobjektivitātes ierobežojumiem.
Apvienojot manuālās un automatizētās testēšanas metodes, uzņēmumi var ievērojami samazināt kļūdu ietekmi uz programmatūru, ieviešot labojumus, kas uzlabo produktu.
Pelēkās kastes testēšana ir lielisks rīks jebkuram izstrādātājam, un iepriekš minētie padomi var nodrošināt, ka jūs to izmantojat pareizi.
Biežāk uzdotie jautājumi un resursi
Ja jums ir kādi jautājumi par “pelēkās kastes” testēšanu, aplūkojiet dažus no mūsu bieži uzdotajiem jautājumiem, lai uzzinātu vairāk un uzlabotu izpratni par šāda veida testiem:
1. Labākie kursi par pelēkās kastes testēšanas automatizāciju
Ir salīdzinoši maz kursu, kas īpaši vērsti uz pelēkās kastes testu automatizāciju, un šie vispārējie programmatūras testēšanas kursi ir ideāls veids, kā sākt:
– “Software Testing Foundation with Exam” – mācību piedāvājumi
– “6 nedēļu programmatūras testēšanas pamatprasmju apmācība” – Futuretrend Technologies Ltd
– “Programmatūras testēšanas kursi”- Royal Course
– “Black-box un White-box testēšana”- Coursera
– “Programmatūras testēšana – melnā kastes stratēģijas un baltā kastes testēšana” – NPTEL
2. Kādi ir 5 svarīgākie intervijas jautājumi par pelēkās kastes testēšanu?
– Kāda ir jūsu pieredze, strādājot ar pelēkās kastes testēšanu, un kā jums tā padevās?
– Kāpēc uzņēmumi izmanto pelēkās kastes testēšanu un kurā procesa posmā?
– Salīdziniet “baltās kastes”, “pelēkās kastes” un “melnās kastes” testēšanu
– Kādas ir dažas no lielākajām “pelēkās kastes” testēšanas problēmām un kā jūs varat tās pārvarēt?
– Kā darbojas testēšanas automatizācija?
3. Labākās YouTube pamācības par pelēkās kastes testēšanu
– “Kas ir pelēkās kastes testēšana? Kādi paņēmieni tiek izmantoti pelēkās kastes testēšanā? Ar piemēru paskaidrots”- Software Testing Hacks
– “Gray box testēšana | programmatūras inženierija |”- Education 4u
– “Melnās kastes, baltās kastes un pelēkās kastes testēšana”- Miracle Education
– “Padomi jaunajiem manuālās QA testētājiem | Darbs ar izstrādātājiem + lietas, ko esmu iemācījusies kā programmatūras testētāja”- Madeline Elaine
– “Kas ir pelēkās kastes testēšana? (Programmatūras testēšanas intervijas jautājums #54)”- QA Fox
4. Kā uzturēt pelēkās kastes testus?
Pelēkās kastes testu uzturēšana ir diezgan vienkāršs process. Veicot manuālo testēšanu, pārliecinieties, ka darbinieki ir labi apmācīti un katru reizi veic vienus un tos pašus uzdevumus. Automatizētai testēšanai pārbaudiet visu testa gadījumu kodu un pārbaudiet rezultātus, izmantojot pastāvīgu procesu pārraudzību, kur vien iespējams.
5. Labākās grāmatas par pelēkās kastes testēšanu
Šajā sadaļā ir ne tikai grāmatas, bet arī žurnālu raksti, lai kvalitātes nodrošināšanas testētājiem nodrošinātu visaugstākos iespējamos rakstiskās palīdzības standartus:
– “Programmatūras integrācijas testēšanas tehnika, kas balstīta uz ziņojumu” – TanLi M. et al.
– “Baltās kastes, melnās kastes un pelēkās kastes testēšanas metožu salīdzinošs pētījums”- Ehmer, M., Khan, F.
– “Grey-box FSM balstītas testēšanas stratēģijas”- Petrenko, A.
– “Programmatūras inženierija”- Saleh, K.A.
– “International Conference on Computer Applications 2012”- Kokula Krishna Hari K.
