Dirbdami programinės įrangos testavimo srityje, galite taikyti dešimtis skirtingų testavimo metodų.
Programinės įrangos testavimas padeda kūrėjams pašalinti visus galimus programinės įrangos paketo trūkumus, kad jie galėtų pateikti visų suinteresuotųjų šalių poreikius ir lūkesčius atitinkantį produktą. Naudodamiesi tinkamu testavimo sprendimu gausite visas reikiamas žinias, tačiau teisingas testo parinkimas gali užtrukti.
Pilkosios dėžės testavimas yra viena iš universaliausių testavimo formų, kurią gali taikyti testuotojai, nes ji suteikia daug informacijos ir nereikalauja pernelyg daug išteklių.
Sužinokite daugiau apie tai, kas yra „pilkosios dėžės” testavimas, kai kuriuos „pilkosios dėžės” testavimo ypatumus ir priežastis, dėl kurių įmonės naudoja šį testavimo metodą.
Kas yra pilkosios dėžės testavimas?
Pilkosios dėžės testavimas – tai testavimo forma, kurioje derinamas baltosios ir juodosios dėžės testavimas, naudojant dalinį supratimą apie pagrindinį dizainą ir sistemos įgyvendinimo būdą.
Šis derinys reiškia, kad testuotojas žino dalį to, kas vyksta fone, nors iki galo nežino kodo, o tai leidžia geriau suprasti galimas programinės įrangos problemų priežastis, kai jos kyla.
Už pilkosios dėžės testavimo atlikimą atsakingi testuotojai, o kokybės užtikrinimo komanda dirba nepriklausomai nuo projekto kūrimo komandos.
1. Kada ir kodėl programinės įrangos testavime reikia atlikti pilkosios dėžės testavimą?
Kūrimo procese įmonės kelis kartus naudoja pilkosios dėžės testavimą.
Pavyzdžiui, kai norint, kad programa tinkamai veiktų, reikia sąveikauti su trečiosios šalies priemone, bandytojai neturi prieigos prie išeities kodo, kuris yra išorinės programinės įrangos dalis. Tai yra priverstinis QA testuotojo prieigos apribojimas, dėl kurio testavimas tampa „pilka dėžute” be galimybės rinktis.
2. Kai nereikia atlikti pilkosios dėžės testavimo
Testavimo procese yra keletas momentų, kai pilkosios dėžės testavimas nėra būtinas, pirmasis iš jų – kūrimo proceso pradžioje.
Funkcinis testavimas atliekamas, kai kūrėjai iš pradžių testuoja, kad įsitikintų, jog jų kodas atlieka pagrindines užduotis, kurios yra visiškai skaidrios. Kadangi nuo testuotojo nėra paslėpto kodo ar dokumentacijos, tai nelaikoma pilkosios dėžės testavimu.
Dar vienas atvejis, kai nereikia pilkosios dėžės testavimo, yra testavimas pačioje kūrimo pabaigoje, kai jau turite užbaigtą produktą. Tai atvejis, kai testuoti padeda galutinis vartotojas, ir jis dar vadinamas „beta testavimu” arba „testavimu nuo galo iki galo„.
Vartotojai testuoja programą neturėdami prieigos prie kodo ar projektavimo dokumentų, o vertindami programinę įrangą atsižvelgia į jos privalumus. Tai yra juodosios dėžės testavimo forma, nes procesas yra visiškai neskaidrus.
3. Kas dalyvauja atliekant pilkosios dėžės testavimą?
Pilkosios dėžės testavime dalyvauja keletas žmonių ir vaidmenų, o kai kurie iš svarbiausių vaidmenų šiame procese yra šie:
– Kokybės užtikrinimo vadybininkas:
Kokybės užtikrinimo vadybininkas arba kokybės užtikrinimo vadybininkas yra programinės įrangos kūrimo proceso darbuotojas, atsakingas už užduočių skyrimą testavimo komandai.
Tai apima darbo grafikų sudarymą, ataskaitų nagrinėjimą ir komandoje kylančių konfliktų sprendimą.
– Testeris:
Testuotojas yra specialistas, atsakingas už testavimo atvejų, kurie yra pilkosios dėžės testavimo proceso dalis, atlikimą.
Tam reikia didelio dėmesio detalėms rašant ataskaitas ir pakartotinai atliekant tikslius testavimo atvejus.
– Kūrėjas:
Programuotojai yra specialistai, atsakingi už kodo kūrimą ir jo koregavimą atsižvelgiant į pilkosios dėžės testavimo rezultatus.
Nors jie nebūtinai dalyvauja pačiame testavime, jie gauna pranešimus iš testuotojų apie rezultatus.
– QA analitikas:
QA analitiko vaidmuo yra įprastas testavimo procesuose, kuriuose naudojama daug automatizavimo. Analitikas rašo automatinių test ų testavimo atvejų kodus ir analizuoja duomenis, kuriuos testai grąžina proceso pabaigoje.
Pilkosios dėžės testavimo privalumai
Yra keletas pagrindinių pilkosios dėžės testavimo privalumų tikrinant programinę įrangą. Naudodamiesi šiais privalumais, laikui bėgant pagerinsite paraiškos standartą.
Kai kurios priežastys, dėl kurių įmonės naudoja šį testavimo būdą, yra šios:
1. Vidinių mechanizmų žinojimas padeda kurti testus
Vienas iš pagrindinių pilkosios dėžės testavimo darbe privalumų yra tas, kad žinote apie kai kuriuos vidinius programos mechanizmus. Tai reiškia, kad reikia suprasti, ką atlieka kiekviena funkcija ir kurie moduliai yra gatavi, palyginti su pagal užsakymą parašytu kodu, skirtu kai kurioms kitoms funkcijoms.
Žinodamas apie vidines funkcijas, testuotojas geriau supranta, ką jis testuoja, ir gali šiuos testus pritaikyti prie programos dizaino. Įmonės gauna tikslesnius rezultatus, kurie tinkamai atspindi programinę įrangą.
2. Klausimai išsprendžiami iš karto
Kai kuriais atvejais, kai bandyme iškyla problema, o bandytojas turi prieigą prie kodo, kuriame slypi problema, problemą galima išspręsti akimirksniu.
Tai prieštarauja „juodosios dėžės” testavimo metodikai, kai testuotojai nemato jokio kodo, esančio už tikrinamos programinės įrangos užkulisių. Matydami kodą, daug kūrimo patirties turintys bandytojai gali nurodyti kūrėjams, kokia tiksliai yra problema ir kaip ją išspręsti būsimu atnaujinimu.
Pilkosios dėžės testavimas sutaupo daug laiko, kuris kitu atveju būtų sugaištas problemoms tirti, ir padeda įmonėms efektyviau naudoti laiką.
3. Atskirti testuotojus ir kūrėjus
Naudojant pilkosios dėžės testavimą aiškiai atskiriami programos kūrėjai ir programinę įrangą testuojantys asmenys.
Taip yra todėl, kad pilkosios dėžės testavimas priklauso nuo to, ar testuotojai turi žinių apie programinės įrangos veikimą, o atstumas tarp jų tampa būtinybe siekiant tikslesnių testavimo rezultatų, kuriems neturi įtakos šališkumas.
Pilkosios dėžės scenarijų testuotojai dirba visiškai kitoje komandoje nei kūrėjai ir teikia tikslią informaciją be jokių esamų nuomonių, darančių įtaką jų rezultatams.
Tai naudinga ir kūrėjams, nes jie kritiškiau vertina savo darbą, o tai padeda tobulinti tiek esamą programą, tiek savo įgūdžius ateityje.
Pilkosios dėžės testavimo iššūkiai
Yra keletas pagrindinių trūkumų, susijusių su pilkosios dėžės testavimu kūrimo darbe.
Suprasdami šiuos trūkumus ir stengdamiesi juos sumažinti, kai tik įmanoma, padidinsite bendrą savo darbo standartą kokybės užtikrinimo etapo pabaigoje.
Pagrindiniai pilkosios dėžės testavimo trūkumai yra šie:
1. Galimybė nepastebėti kodo
Pilkosios dėžės testavimas reiškia, kad tam tikri kodo aspektai yra paslėpti nuo testuotojo, o testo metu iškilus problemoms, tai gali sukelti papildomų problemų.
Kai kodas nematomas, testavimo procese dalyvaujantiems darbuotojams sunku nukreipti savo testus taip, kad jie kuo geriau išnaudotų programos galimybes, ir jie netenka galimybės iš karto sužinoti problemos priežastį.
Klaidų taisymo procesas tampa dar labiau užgožtas, dėl to tampa būtinas ilgesnis atnaujinimo laikas, o įmonės stengiasi surasti problemas savo kode.
Dėl šio nematomo kodo galutiniai produktai gali turėti daugiau klaidų ir būti prastesnio standarto.
2. Bandymai gali būti netikslūs, jei nepavyksta atlikti operacijų
Tikslūs testai yra būtini atliekant bet kokį programinės įrangos testavimą, nes didesnis tikslumas padeda komandoms rasti atnaujinimus, kuriuos jos gali įdiegti į būsimas versijas, ir padeda kūrėjų komandai labiau pasitikėti savo produktais.
Šis tikslumas sumažėja, kai atliekant pilkosios dėžės bandymus operacijos nepavyksta. Jei bandytojai neturi prieigos prie kodo, iš programinės įrangos jie tiesiog gauna pranešimą „Operacija nepavyko”, todėl negali pateikti jokių atsiliepimų apie jos veikimą.
Norėdami gauti naudingus rodiklius, kūrėjai turi pataisyti programinę įrangą prieš kitą testavimo etapą. Priešingu atveju testuotojas gali tik pareikšti, kad funkcija neveikia dabartiniu pavidalu.
3. Kovos su paskirstytosiomis sistemomis
Paskirstytosios sistemos – tai programinės įrangos sistemos, kurios yra patalpintos keliose skirtingose vietose arba yra priklausomos nuo tokių funkcijų, kaip debesyje talpinamų duomenų ir apdorojimo paslaugų.
Tai labai apsunkina testavimą, nes didelė programinės įrangos dalis yra paslėpta už trečiosios šalies įstaigos, o testuotojai tiesiog gauna nežinomo proceso išvestį.
Kai kyla problemų su programine įranga, kurioje naudojamos trečiųjų šalių sistemos, gali būti sunku nustatyti, ar problema susijusi su pačia programa, trečiųjų šalių funkcijomis, ar su jų integravimo būdu, ypač kai testuotojas negali matyti veikiančio kodo.
Pilkosios dėžės bandymų charakteristikos
Yra keletas bendrų pilkosios dėžės testams būdingų bruožų, o šių testų atpažinimas padės jums parengti savo organizacijos strategiją.
Keletas pagrindinių pilkosios dėžės testavimo charakteristikų pavyzdžių ir tai, kad šios charakteristikos yra svarbios pilkosios dėžės testavimo proceso dalys:
– Didesnė aprėptis:
Galimybė susipažinti su dalimi pirminio kodo suteikia didesnį testų aprėpties laipsnį, o išsamesnė informacija padeda tiksliau rasti klaidas.
– Duomenų srautai:
Daugelyje pilkosios dėžės testų akcentuojamas duomenų srautas ir siekiama suprasti, kaip informacija juda sistemoje.
– Ne algoritminis:
Pilkosios dėžės testavimas neveikia nagrinėjant algoritmus, nes tai yra dar vienas kodo užmaskavimo lygis.
Ką tikriname pilkosios dėžės testais?
Kiekvieną skirtingą testavimo tipą geriausiai galima taikyti konkrečioms konkrečios programinės įrangos dalims. Tas pats pasakytina ir apie „pilkosios dėžės” testavimą – ši metodika naudingiausia kai kuriose išskirtinėse programėlės dalyse.
Keletas pavyzdžių, ką testuotojai vertina atlikdami pilkosios dėžės testus:
1. Programos saugumas
Pilkosios dėžutės testai idealiai tinka įsiskverbimo testams, kuriais tikrinamas taikomosios programos saugumas. Testuotojai gali matyti visą kodą ir ieškoti galimų pažeidžiamumų.
Etiniai įsilaužėliai yra idealūs programų saugumo testavimo specialistai, nes jie lengviau atpažįsta galimas programinės įrangos silpnąsias vietas ir trūkumus nei tie, kurie neturi programinės įrangos saugumo pažeidimų patirties.
2. Duomenų bazės testavimas
Daugelis įmonių duomenų bazių testavimui naudoja pilkosios dėžės testavimą, nes galima stebėti duomenis per kiekvieną programinės įrangos subfunkciją.
Testuotojai gali matyti visus programinės įrangos atliekamus pakeitimus ir įvertinti, ar jie yra teisingi.
Tai naudinga pilkosios dėžės testavimo priemonė, nes duomenų bazių testai dėl savo pobūdžio yra nuspėjami, nes įmonės naudoja duomenų bazes esamai informacijai tvarkyti, o ne naujiems duomenims generuoti.
3. Internetinės taikomosios programos
Žiniatinklio programoms naudinga naudoti pilkosios dėžės testavimą dėl šio testavimo metodo universalumo.
Pilkosios dėžutės testai gali būti naudojami saugumo, duomenų bazių, integracijos, vartotojo sąsajos ir naršyklės testams, kurie yra pagrindiniai žiniatinklio programų aspektai.
Nebereikia iš dalies keisti testavimo metodikų, todėl užtikrinamas didesnis tęstinumas.
Išaiškinti tam tikrą painiavą:
Pilkosios dėžės ir baltosios dėžės ir juodosios dėžės testavimas
Pilkosios dėžės testavimas – tai testavimo forma, gimininga ir baltosios, ir juodosios dėžės testavimui, o tai reiškia, kad tarp šių metodikų gali būti daug painiavos.
Sužinokite daugiau apie tai, kas yra „baltosios ir juodosios dėžės” testavimas ir kokie esminiai skirtumai tarp jų ir „pilkosios dėžės” testavimo kuriant programinę įrangą:
1. Kas yra „baltosios dėžutės” testavimas?
„Baltosios dėžutės” testavimas – tai toks taikomosios programos testavimo būdas, kai testuotojas gauna išsamią informaciją apie taikomąją programą.
Be kita ko, testuotojui suteikiama visiška prieiga prie pirminio kodo ir visų programinės įrangos projektavimo dokumentų, todėl jis daug geriau supranta, kaip veikia programinė įranga.
Testuotojai, naudodamiesi šiuo supratimu, mato daugiau problemų, esančių taikomojoje programoje, ir pateikia tikslesnę informaciją apie tai, kaip taikomoji programa veikia naudotojams.
„Baltosios dėžutės” testavimo pavyzdys – stebėti konkrečių įvestų duomenų srautą per programą, kad būtų galima nustatyti, kur programos procesuose kyla problema, o ne tiesiog patikrinti, ar problema yra, ar ne.
Kūrimo procesuose įmonės keletą kartų naudoja „baltosios dėžutės” testavimą.
Pirmasis iš jų – tai vienetų testavimas, kurio metu vertinama, ar kiekvienas atskiras programinės įrangos paketo kodas ar modulis atlieka kūrėjo numatytą darbą.
Vienetų testavimas padeda testuotojams rasti daugumą programos problemų, nes tikrinamos visos programos funkcijos.
„Baltosios dėžutės” testavimas taip pat padeda rasti atminties nutekėjimą. Išsamiai išnagrinėjęs visą kodą, QA analitikas nustato, kur programa naudoja įrenginio atmintį, ir galimas sritis, kuriose jos naudojama per daug.
Tai padeda programai greičiau ir efektyviau veikti būsimose iteracijose, nes atminties nutekėjimas kuo greičiau pataisomas.
Kuo skiriasi pilkojo ir baltojo langelio testai?
Yra keletas esminių skirtumų tarp baltosios ir pilkosios dėžės testų, o pirmasis skirtumas yra informacijos, su kuria gali susipažinti asmuo, lygis.
„Baltosios dėžės” testavimas turi visišką prieigą prie programos pirminio kodo ir projektavimo dokumentų, o „pilkosios dėžės” testavimas turi tik dalinę prieigą prie kai kurios šios informacijos, visų pirma prie projektavimo dokumentų.
Šis pokytis reiškia, kad skiriasi ir testus atliekantys asmenys – už baltosios dėžutės testavimą pirmiausia atsakingi patys kūrėjai.
Už pilkosios dėžutės testavimą, priešingai, atsakinga kokybės užtikrinimo komanda, nes testuotojai negali gerai išmanyti kodo.
Pilkosios dėžės testavimas taip pat užima mažiau laiko nei baltosios dėžės testavimas. „Baltosios dėžutės” testavimas yra ištisinis ir apima tiek programinės įrangos naudotojo pusę, tiek patį kodą. Tai užtrunka daug ilgiau, todėl daug greičiau galima atlikti pilkosios dėžės testavimo procesą.
Tačiau „baltoji dėžutė” turi daugiau automatizavimo galimybių, nes testuotojai žino, kaip veikia vidinis kodas.
2. Kas yra juodosios dėžės testavimas?
„Juodosios dėžės” testavimas reiškia, kad testuotojas tikrina programinės įrangos paketą, neturėdamas jokio supratimo apie sistemos veikimą.
Tai reiškia, kad neturite prieigos prie bet kokio kodo, kuris yra programos dalis, arba prie bet kokių turimų projektavimo dokumentų ar santraukų. Testuotojai tiesiog turi testuojamų funkcijų sąrašą ir keletą testavimo atvejų, kuriuos turi atlikti.
„Juodosios dėžės” testavimo pavyzdys yra „nuo galo iki galo” testavimas, kai testuotojas gauna visą programinės įrangos paketą ir išbando visą programą, kad įsitikintų, jog jos funkcijos veikia taip, kaip numatyta.
Dauguma idealių juodosios dėžės bandymų atvejų yra proceso pabaigoje, kai bandymai susiję su klientais ir jų požiūriu į produktą, o prieigos prie kodo nebuvimas užkerta kelią bet kokiam šališkumui, turinčiam įtakos naudotojo požiūriui.
Įmonės juodosios dėžės testavimą pirmiausia naudoja tada, kai baigiami visi taikomosios programos funkcijų bandymai. Atlikę visus vienetinius ir funkcinius testus, kūrėjai supranta, kad programa veikia taip, kaip jie tikisi, bent jau kai visi moduliai veikia izoliuotai.
„Juodosios dėžės” testavimas užtikrina, kad visa programa po kompiliavimo veiktų taip, kaip tikimasi, nes teoriškai visas pirminis kodas jau yra tvarkingas.
Kuo skiriasi pilkosios ir juodosios dėžės testavimas?
Pagrindinis pilkosios ir juodosios dėžės testavimo skirtumas yra tai, kokią prieigą prie informacijos gauna testuotojas.
Kai kuriais atvejais „juodosios dėžės” testuotojas gali dirbti su programa neturėdamas jokių išankstinių žinių apie programinę įrangą, tiesiog atlikti testavimo procesą ir naudotis programine įranga kaip įprastas naudotojas.
Kita vertus, „pilkosios dėžės” bandytojas turi prieigą prie kai kurių projektavimo dokumentų, todėl gali palyginti tai, ką programa turėtų daryti, su jos realiu veikimu ir suteikti kūrėjams grįžtamąją informaciją apie tai, kurios konkrečios programos dalys neatitinka standartų.
Kitas skirtumas – laikas, per kurį išsprendžiama problema, nes pilkosios dėžės testai užtrunka šiek tiek ilgiau.
Dokumentacijos ir kodo kryžminis palyginimas su tuo, kaip jūs patiriate programą, gali užtrukti, o tai prieštarauja „juodosios dėžės” testuotojų darbui, kai jie paprasčiausiai nagrinėja pačią programą ir visas funkcines problemas. Dėl šio derinio juodosios dėžės testavimas yra idealus procesas, kurį galima naudoti pačioje kūrimo proceso pabaigoje, kai ruošiamasi išleisti produktą, o pilkoji dėžė geriau tinka, kai esate vartotojo sąsajos kūrimo ir kompiliavimo etape.
3. Išvada: Pilkosios dėžės ir baltosios dėžės ir juodosios dėžės testavimas
Apibendrinant galima teigti, kad baltosios, pilkosios ir juodosios dėžės testavimas yra to paties spektro dalis, o skirtingas veiksnys yra prieigos lygis, kurį testuotojas turi viso proceso metu.
Kai testavimo forma tampa vis „juodesnė”, testavimas tampa vis neskaidresnis, o prieiga prie už programinės įrangos slypinčios informacijos yra ribota.
„Baltosios dėžės” testavimas idealiai tinka ankstyviausiems proceso etapams, o „juodosios dėžės” testavimas puikiai tinka tokiems etapams kaip „nuo galo iki galo” testavimas, kai visa programa nagrinėjama iš naudotojo perspektyvos.
Pilkosios dėžės testavimas yra tarpinė grandis tarp šių dviejų koncepcijų, padedanti rasti problemas kūrimo proceso viduryje, nes suteikia daugiau įžvalgų, tačiau dalis pirminio kodo lieka paslėpta nuo testuotojo.
Pilkosios dėžės testavimo metodai
Pilkosios dėžės testavimas apima daugybę metodų, kurių kiekvienas padidina testavimo standartą, padeda kūrėjui rasti daugiau klaidų ir proceso pabaigoje sukuria išbaigtesnį produktą.
Kai kurie iš dažniausiai QA komandų naudojamų „pilkosios dėžės” testavimo metodų yra šie:
1. Matricos testavimas
Atliekant matricinį testavimą nagrinėjama vykdomo projekto būklės ataskaita. Kai kuriais atvejais tai yra paprasta PASS/FAIL būsena, o vykstančiuose procesuose pateikiama daugiau informacijos apie tai, kaip procesai nuolat veikia.
Kai dauguma testavimo atvejų daugiausia dėmesio skiriama kodo įvestims ir išvestims, atliekant matricinį testavimą tiriama pačių procesų būklė, o ne jų rezultatai.
Naudojant matricinį testavimą daugiau dėmesio skiriama pačiai programai, todėl galima rasti klaidų ir problemų, net jei rezultatai atrodo teisingi.
2. Regresijos testavimas
Regresinis testavimas skirtas programinei įrangai išbandyti po kelių atnaujinimų. Tai apima funkcinius ir nefunkcinius testus, kuriais užtikrinama, kad keičiant kodą programa vis dar veiktų pakankamai kokybiškai.
Regresijos testus atliekantys testuotojai paprastai naudoja automatizavimą, nes regresijos testų apimtis didėja, kai kokybės užtikrinimo komanda randa vis daugiau defektų.
Tačiau kai kuriais atvejais rankinis testavimas yra būtinas – įmonės, kurios testuoja naudotojo sąsają, naudoja rankinius testus, kad pamatytų, kaip į meniu, mygtukų ir naršymo parinkčių pakeitimus reaguoja žmogus.
3. Modelio testavimas
Testavimas pagal modelį – tai testavimo forma, kai pagrindinis dėmesys skiriamas tam tikro modelio laikymuisi kiekviename organizacijos atliekamame teste.
Testavimo komandos šiuos testus rengia taip, kad jie būtų skirti kiekvienai programinės įrangos funkcijai, o kiekvienas testas įmonei suteiktų nuoseklios informacijos apie atskirų funkcijų veikimą.
Naudojant modelio testavimą kartais tenka keisti modelį, kad įsitikintumėte, jog vertinate kiekvieną veikiančią sistemą, tačiau kai jau turite veikiantį modelį, venkite nukrypimų, kad rezultatai būtų nuoseklesni.
4. Ortogonalių matricų testavimas
Ortogonalių masyvų testavimas – tai pirmiausia į juodąją dėžutę orientuotas testavimo metodas, taikomas tada, kai testuotojai naudoja didelį įvesties duomenų skaičių, kuris yra per didelis, kad būtų galima išsamiai išbandyti kiekvieną sistemą.
Tokiais atvejais kiekvienas atskiras duomenų elementas pateikia savo unikalią informaciją, nes gali trūkti koreliacijos tarp konkrečių informacijos elementų. Tai yra ortogoninis sistemos aspektas, kai unikalios informacijos dalys naudojamos siekiant pateikti kuo daugiau duomenų, o tam reikia kuo mažiau pastangų.
Sutrumpėja testavimo laikas, o jūs turite idealų duomenų, kuriuos galite pateikti kūrimo komandai, balansą.
Pilkosios dėžės testavimas programinės įrangos inžinerijos gyvavimo cikle
Pilkosios dėžės testavimas priklauso tam tikram programinės įrangos inžinerijos gyvavimo ciklo etapui. Šis gyvavimo ciklas – tai sudėtingas etapų ciklas, kurio įmonės laikosi kurdamos savo produktus, o kiekvienas etapas veda prie aukštesnio produkto standarto.
Nors testavimas yra nuolat vykstanti proceso dalis, pilkosios dėžės testavimui skiriama labai mažai laiko.
Tai atliekama po to, kai pradinis funkcionalumas užbaigiamas ir išbandomas atliekant „baltosios dėžutės” bandymus, ir prieš paruošiant programinę įrangą viešam išleidimui, o įmonės pirmenybę teikia „juodosios dėžutės” bandymams vėlesniuose etapuose.
„Grey box” yra puikus įrankis integruoti funkcijas ir užtikrinti, kad jos veiktų ne tik savarankiškai, bet ir kartu.
Rankiniai ar automatizuoti pilkosios dėžės bandymai?
Kaip ir atliekant bet kokį programinės įrangos testavimą, kokybės užtikrinimo komandos renkasi, ar testavimą atlikti rankiniu būdu, pasitelkiant ekspertus, ar automatiškai, t. y. sukoduoti keletą testavimo atvejų ir pakartotinai juos atlikti, kad būtų gauti tikslūs rezultatai.
Sužinokite daugiau apie rankinį ir automatinį testavimą, kai kuriuos jų privalumus ir iššūkius, taip pat apie tai, kuri iš šių dviejų testavimo formų idealiai tinka įmonei, norinčiai geriau suprasti savo produkto problemas.
Rankinis pilkosios dėžutės testavimas – nauda, iššūkiai, procesas
Rankinis testavimas yra pagrindinė daugelio testavimo tipų, įskaitant pilkosios dėžės testavimą, dalis.
Šio proceso metu žmonės testuotojai apžiūri programinę įrangą, patikrina, ar ji veikia taip, kaip tikitės, ir palygina ją su iš anksto parengtais projektavimo dokumentais ir matomu kodu, kad patikrintų, ar šioje informacijoje nėra akivaizdžių trūkumų, dėl kurių galėtų kilti problemų.
Rankinis testavimas dažniausiai taikomas sudėtingesnėms programoms, kurioms reikia žmogaus, kad jis suteiktų kokybinę įžvalgą.
Kitais atvejais gali būti naudojamos mažesnės įmonės, norinčios nuodugniai įvertinti savo programinę įrangą, nes mažoms programoms ir paketams įvertinti reikia palyginti nedaug išteklių, palyginti su didesnėmis didžiųjų įmonių sukurtomis programomis.
1. Rankinio pilkosios dėžės testavimo privalumai
Rankinis pilkosios dėžės testavimas bet kokiai programinei įrangai turi keletą privalumų. Žinodami šiuos privalumus, galite į juos orientuoti savo testavimą, aptikti daugiau programinės įrangos problemų ir pagerinti savo darbo standartus dėl geresnio testavimo režimo.
Pagrindiniai rankinio pilkosios dėžės testavimo privalumai:
Išsamūs atsiliepimai
Pirmasis svarbus rankinio pilkosios dėžutės testavimo privalumas yra tas, kad testuotojai gali suteikti kūrėjui reikšmingą grįžtamąjį ryšį.
Naudojant automatinį testavimą, testavimo atvejai yra sukurti taip, kad kartas nuo karto būtų gaunami labai konkretūs rodikliai, kurie analitikams suteikia įžvalgų, kai jie turi laiko įvertinti duomenis.
Naudojant rankinį testavimą situacija šiek tiek skiriasi, nes testuotojas, palyginęs su projektine dokumentacija, gali pateikti išsamesnę grįžtamąją informaciją apie tai, kokia konkreti funkcija neveikė, ir galimas problemos priežastis.
Naudodamiesi išsamiais atsiliepimais galite ne tik atnaujinti esamas funkcijas, bet ir galimas naujas funkcijas, kurias testuotojas rekomenduoja naudotojams.
Geresnės interpretacijos
Automatizuotas testavimas reiškia, kad bet kokios išvados daromos įvertinus testo metu gautus duomenis ir padarius racionalią išvadą, ką tai reiškia programinei įrangai.
Priešingai, rankiniu būdu dirbantys testuotojai turi kur kas daugiau žinių apie pačios programos veikimą.
Jie gali palyginti pilkosios dėžės kodą su tuo, kas vyksta realiuoju laiku, ir tuo metu atlikti tikslų vertinimą, o ne daryti išvadas vėliau.
Kai kurios automatizavimo platformos gali veikti panašiai, turėdamos atkūrimo funkciją, tačiau tam vis tiek reikia rankinio įsikišimo.
Lankstus testavimas
Testavimo automatizavimas apima labai konkrečių testavimo atvejų kodavimą platformoje, o tai reiškia, kad programinė įranga vis iš naujo atlieka tam tikrą užduočių rinkinį.
Nors tai idealiai tinka pasikartojimui, tačiau tai yra unikalus iššūkis, nes bandymai nėra lankstūs.
Tokiais atvejais idealiai tinka naudoti žmogaus testerį, nes tai suteikia daugiau lankstumo procesui. Jei testuotojas pastebi galimą problemą, kuri šiek tiek skiriasi nuo siaurai apibrėžto testavimo atvejo, jis gali ją išnagrinėti ir proceso pabaigoje pranešti rezultatus.
Taip įmonės gauna išsamesnę programinės įrangos aprėptį ir aptinka klaidų, kurių automatinė sistema negali aptikti.
2. Rankinio pilkosios dėžės testavimo iššūkiai
Nors rankinio testavimo naudojimas programinės įrangos kūrimo procese turi daug privalumų, yra ir keletas trūkumų. Tai priklauso nuo kelių veiksnių, įskaitant konkrečią programinę įrangą, su kuria dirba įmonė, kūrimo komandos dydį ir testavimo bei kūrimo komandų narių įgūdžių lygį.
Svarbūs rankinio testavimo iššūkiai yra šie:
Didelės darbo sąnaudos
Darbo užmokesčio išlaidos yra vienos didžiausių išlaidų, kurias patiria bet kuri įmonė, nes ji moka tam, kad gautų geriausius darbuotojus ir galėtų pagerinti savo darbo kokybę.
Kadangi pilkosios dėžės rankinis testavimas gali užtrukti daug laiko, įmonė turi mokėti savo testuotojams už darbą viso proceso metu. Kai kurioms didžiausioms programoms tai gali užtrukti kelias valandas ir dėl to gali išaugti rankinių testuotojų išlaidos.
Kūrėjai gali bandyti sušvelninti šią problemą derindami pilkosios dėžutės testavimo automatizavimą su rankiniu testavimu arba mažindami valandines darbo sąnaudas, tačiau dėl to gali nukentėti testavimo kokybė.
Žmogiškoji klaida
Automatizuotas testavimas veiksmingai atlieka paprastus procesus, pakartodamas juos labai tiksliai taip, kaip to negali padaryti žmogus.
Žmonės daro klaidų ir nedidelių klaidų, kurios gali atsirasti dėl bet ko – nuo netyčinio netinkamo mygtuko paspaudimo iki poros sekundžių dėmesio pasimetimo.
Dėl tokių klaidų duomenys gali būti netikslūs, o kūrėjai gali sutelkti dėmesį į netinkamą programinės įrangos dalį, atimdami daug brangaus kūrimo laiko ir pablogindami produkto kokybę.
Siekite išspręsti šią problemą atlikdami pakartotinius „pilkosios dėžutės” bandymus, jei įmanoma, kad patikrintumėte rezultatus, kai bandymai tęsiami.
Užtrunka ilgai
Kompiuteriai užduotis gali atlikti akimirksniu, o žmonėms reikia šiek tiek daugiau laiko.
Taip nutinka dėl įvairių priežasčių – nuo reakcijos laiko iki to, kad tam tikrais momentais tiesiog dirbama lėčiau nei optimaliu greičiu, o tai lėtina testavimo procesą.
Lėtesnis testavimo procesas reiškia, kad kūrimo komandos turi mažiau laiko šalinti produkto klaidas ir trūkumus, nes visas laikas pirmiausia skiriamas problemoms rasti.
Šią problemą nėra lengva sušvelninti, o vienas iš galimų sprendimų – hibridinis testavimo režimas, pavyzdžiui, rankinių testų derinimas su automatiniais pilkosios dėžės testais.
Pilkosios dėžės testavimo automatizavimas – nauda, iššūkiai, procesas
Testavimo automatizavimas – tai automatizavimo platformos naudojimo procesas, kurio metu automatizuojamos kai kurios pilkosios dėžės testavimo proceso dalys.
Procesas vyksta taip: testų kūrėjai sukuria keletą testavimo atvejų, o QA analitikai ar panašūs specialistai šiuos testus užkoduoja automatizavimo programose, kai kurie iš jų kaip papildomą priemonę naudoja robotizuotą procesų automatizavimą.
Tokiais atvejais kokybės užtikrinimo analitikai jau supranta kai kuriuos kodo ar projektavimo dokumentus.
Tokio tipo bandymai dažniau atliekami su daug didesniais programinės įrangos paketais, nes „pilkosios dėžės” bandytojai neturi laiko nuodugniai rankiniu būdu išbandyti visus proceso aspektus.
Po automatizuoto proceso platforma QA analitikui pateikia ataskaitą, kurioje nurodomos nesėkmių vietos ir keletas svarbių rodiklių.
1. Automatizuoto pilkosios dėžės testavimo privalumai
Yra keletas akivaizdžių automatinio pilkosios dėžės testavimo privalumų kokybės užtikrinimo komandos procesuose.
Sutelkusi dėmesį į šiuos privalumus ir jais pasinaudojusi, įmonė gali padidinti pilkosios dėžės testavimo veiksmingumą ir išspręsti kuo daugiau problemų šiame darbo eigos etape.
Kai kurie pagrindiniai automatizavimo naudojimo privalumai atliekant pilkosios dėžės testavimą yra šie:
Greitas testavimas
Automatizuotos sistemos sukurtos taip, kad būtų galima neįtikėtinai greitai atlikti bandymus ir kuo greičiau atlikti tam tikrus procesus. Šis privalumas dar labiau išryškėja atliekant pakartotinius pilkosios dėžės bandymus, nes kiekvienas atskiras bandymas užima mažiau laiko.
Laiko, kurį sutaupysite nuo vieno diegimo iki kito, gerokai padaugės, o jūsų įmonė turės daug daugiau laiko atlikti neatidėliotinas užduotis, pavyzdžiui, atnaujinti pačią programinę įrangą ir teikti grįžtamąjį ryšį klientams bei potencialiems klientams.
Greitesnis testavimas ypač naudingas dirbant po išleidimo, nes norint pagerinti žmonių požiūrį į verslą, būtina kuo greičiau pateikti funkcionalumo pataisas.
Tikslūs rodikliai
Metrikos yra svarbi programinės įrangos testavimo būdo dalis, nes jos suteikia testuotojui skaitinę informaciją, kuri parodo galimas problemas.
Kompiuteriai ir automatizavimo platformos siūlo labai tikslius rodiklius, pavyzdžiui, atsako laiką galima išmatuoti milisekundės tikslumu.
Turėdami tikslesnius rodiklius, galite stebėti nedidelius programėlės veikimo pokyčius ir suprasti, ar dėl atnaujinimo pagerėjo našumas, ar standartinės darbo eigos užtrunka ilgiau.
Sumažintos išlaidos
Viena iš didžiausių testavimo sąnaudų programinės įrangos pilkosios dėžutės kūrimo aplinkoje yra pačių pilkosios dėžutės testuotojų sąnaudos.
Programinės įrangos testavimo ekspertų samdymas yra brangus, ypač kai ieškote „pilkosios dėžės” testuotojų, kuriems reikia įvairesnių įgūdžių, kad jūsų organizacijai būtų užtikrinti aukščiausi įmanomi standartai.
Automatizavimas reiškia, kad mažiau žmonių atlieka rankinius pilkosios dėžutės testus, todėl šiame procese nebelieka daug personalo sąnaudų.
Nors automatizavimo platformos turi tam tikrų sąnaudų, dauguma jų yra mėnesinės prenumeratos, tačiau jos yra daug mažesnės, nei mokėti darbuotojams, kurie atliktų darbą už jus.
2. Automatizuoto pilkosios dėžės testavimo iššūkiai
Naudojant automatizavimą pilkosios dėžės testavimo procesuose kyla daug iššūkių.
Nors kai kurios organizacijos daugiausia dėmesio skiria privalumams, žinant pilkosios dėžės testavimo iššūkius ir į juos atsižvelgiant darbe yra daug privalumų.
Pilkosios dėžės testavimą galite įgyvendinti taip, kad išvengtumėte iššūkių ir ateityje nesusidurtumėte su apribojimais.
Pagrindiniai automatinio pilkosios dėžės testavimo iššūkiai yra šie:
Pradinė sąranka
Pradinė sąranka yra vienas didžiausių automatizavimo proceso iššūkių. Tai reiškia laiką, kurio reikia pereiti prie naujos testavimo platformos, įskaitant platformos įdiegimą, naudotojų mokymą, kaip su ja dirbti, ir pirmųjų testų programinėje įrangoje kodavimą.
Visa tai yra neproduktyvus laikas, kurį įmonė nori kuo labiau apriboti.
Šiuo atveju idealu naudoti aukščiausios kokybės automatizavimo programinę įrangą, kurios ekspertai prireikus yra pasirengę padėti, nes trečiosios šalies pagalba užtikrina, kad pilkosios dėžės automatizavimas ir kitų tipų testavimas nuo pat pradžių vyktų sklandžiai.
Aukšti įgūdžių reikalavimai
Nors rankiniam testavimui reikia aukštų įgūdžių, QA analitikai, dirbantys su automatizavimu, vis tiek turi turėti aukšto lygio įgūdžių.
Tai yra kodavimo įgūdžiai, kurie pirmiausia naudojami kuriant bandymų atvejus ir skaitant kodą, esantį pilkojo langelio scenarijuje.
Kūrėjai gali sušvelninti šią problemą specialiai samdydami testuotojus, kurie turi kūrimo patirties arba anksčiau yra dirbę su kodavimo projektais. Apribojate mokymo laiką darbo vietoje ir užtikrinate, kad kiekvienas naujas darbuotojas sugebėtų prisitaikyti prie pilkosios dėžės automatinio testavimo reikalavimų.
Kai kurios įmonės kaip alternatyvą pilkosios dėžės bandymams atlikti siekia naudoti bekodę automatizavimo sistemą, tačiau dėl to darbo vietoje gali sumažėti lankstumas.
Nuolatinė priežiūra
Automatinis testavimas iš dalies egzistuoja tam, kad nereikėtų pasikliauti žmonėmis, nes rankinio testavimo metu į procesus nuolat įtraukiami žmonės.
Tai neturi būti bandymų automatizavimo atvejis, tačiau įmonėms vis tiek reikia užtikrinti tinkamą priežiūrą.
Priežiūra apima pilkosios dėžutės testų rezultatų tikrinimą ir jų priežiūrą, siekiant įsitikinti, kad viskas vis dar veikia taip, kaip tikisi kūrėjas.
Įmonės gali padėti pagerinti turimos priežiūros standartus keliais būdais: geriausia, jei už bandymų priežiūrą būtų atsakingas vienas specialistas.
Tai leidžia pasiekti aukštesnį specializacijos lygį, o darbuotojas tampa pilkosios dėžės ekspertu testuotoju, kuris greičiau ir efektyviau dirba su automatizavimo priemonėmis.
Išvados: Rankinis ar pilkosios dėžės testavimo automatizavimas?
Apibendrinant galima teigti, kad tiek rankinis pilkosios dėžės testavimas, tiek automatinis testavimas turi savo vietą programinės įrangos testavimo procese.
Mažesnėms įmonėms ir startuoliams naudinga atlikti pilkosios dėžutės rankinį testavimą, kai jų kodas yra palyginti nedidelis ir lengvai valdomas, o automatizavimas tampa vis naudingesnis, kai programos auga ir turi daugiau funkcijų.
Vis dėlto rankinis testavimas visada bus reikalingas, nes įmonėms suteikia daugiau įžvalgų, detalumo ir lankstumo.
Idealus „pilkosios dėžės” sprendimas bet kuriai įmonei yra hibridinis modelis, kai rankinis ir automatinis testavimas atliekamas skirtingais etapais, kad būtų atsižvelgta į abiejų metodų stipriąsias ir silpnąsias puses.
Taikant holistinį požiūrį atskleidžiama daugiau programinės įrangos paketo problemų, todėl programinę įrangą galima ištaisyti veiksmingiau, o kūrimo pabaigoje klientai gauna daug geresnį produktą.
Ko reikia norint pradėti pilkosios dėžės testavimą?
Yra kelios būtinos sąlygos, kurių įmonės reikalauja prieš pradėdamos pilkosios dėžės testavimo procesus. Turint šias priemones, testavimo procesas tampa įmanomas arba programinės įrangos testavimas tampa daug paprastesnis kokybės užtikrinimo komandai, nes ji turi daugiau išteklių.
Pilkosios dėžės testavimui atlikti būtinos šios sąlygos:
1. Projektavimo dokumentai arba pirminis kodas
Pirmas dalykas, kurio reikia norint pradėti pilkosios dėžės testavimo procesą, yra projekto dokumentacija arba pradinis kodas. Kad testavimas būtų laikomas pilkosios dėžės testavimu, testuotojams turi būti suteikta galimybė susipažinti su šia informacija, kad jie galėtų įžvelgti vidinį pačios programinės įrangos veikimą.
Ši informacija turi būti kuo svarbesnė, pavyzdžiui, konkrečios funkcijos, kurią tikrina testuotojas, kodo eilutė.
Naudodami pilkosios, o ne baltosios dėžės testavimą, pateikiate tik dalį kodo ir projekto dokumentacijos, todėl būkite atsargūs dėl suteikiamos prieigos lygio.
2. Trumpas produkto aprašymas
Produkto santrauka arba taikomosios programos santrauka – tai dokumentas, kurį įmonės naudoja norėdamos išsiaiškinti, ko klientas ieško programinės įrangos pakete. Jame išsamiai nurodomas tikslus programinės įrangos funkcionalumas, kurio klientas pageidauja, kliento pageidaujamas dizainas ir visos kitos būtinos specifikacijos.
Perskaitęs produkto aprašymą, pilkosios dėžės testuotojas gali ieškoti visų kliento pageidaujamų funkcijų, įsitikinti, kad jos yra programinėje įrangoje, ir užtikrinti, kad produktas atitiktų visus įmonės taikomosios programos tikslus.
Kai kurios įmonės riboja informacijos, kurią gali matyti pilkosios dėžutės testeriai, kiekį, priklausomai nuo įmonės konfidencialumo politikos.
3. Testavimo tikslai
Kūrėjai ir įmonės, atlikdami testus, turi konkrečių tikslų, kurie kartais vadinami testų specifikacija. Tai labai svarbu pilkosios dėžutės testavimo procese, nes tai reiškia, kad kūrėjai gali pateikti pilkosios dėžutės testuotojams visą reikiamą informaciją, o kokybės užtikrinimo komanda sukuria testus, atitinkančius testavimo proceso tikslus.
Tokiu atveju visi dirba efektyviau, nes žino, ko siekia ir kaip geriausiai pasiekti šiuos tikslus.
Pilkosios dėžės testavimo procesas
Pilkosios dėžės testavimas atliekamas pagal gana nuoseklų procesą, kuriame aiškiai nurodyti atskiri etapai, kuriuos įmonė turi atlikti, kad pasiektų savo testavimo tikslus.
Aiškiai ir nuosekliai laikantis šio proceso, gaunami tikslūs ir nuoseklūs rezultatai, kurie informuoja kūrėjus apie problemas ir jų sprendimo būdus.
Pagrindiniai pilkosios dėžės testo etapai yra šie:
1. Įvesties ir išvesties nustatymas
Pirmasis proceso žingsnis – nustatyti įvesties ir išvesties duomenis, kurių tikitės iš programos.
Pasirinkite įvestį, kuri neviršytų įprastų programos galimybių, kad būtų atliktas sąžiningas bandymas, ir nustatykite, kokios išvesties tikitės iš tos įvesties.
Atlikę šį prognozavimą projekto pradžioje, žinote, ar bandymų pabaigoje kas nors nepavyko.
2. Nustatyti pirminius srautus
Pirminiai srautai – tai maršrutai, kuriais duomenys programinėje įrangoje pasiekia galutinį rezultatą.
Pirminio srauto nustatymas reiškia, kad galite geriau stebėti, kaip informacija keliauja per programinės įrangos procesus, nustatyti galimas trūkumų sritis ir, jei su programine įranga kyla problemų, stengtis jas ištaisyti.
3. Nustatykite subfunkcijas, įvestis ir išvestis
Subfunkcijos yra pagrindinės pirminio srauto operacijos. Kiekviena subfunkcija yra maitinama kitos subfunkcijos, o ši – kitos, ir galiausiai gaunama galutinė programinės įrangos išvestis.
Nustatykite, kokie turėtų būti kiekvienos subfunkcijos įvesties duomenys ir prognozuojama kiekvienos iš jų išeiga.
Jei tai atliekate subfunkcijos lygmeniu, tai suteikia papildomų žinių ieškant programinės įrangos problemų.
4. Sukurti testavimo atvejį
Testavimo atvejis – tai programinėje įrangoje vykstančių įvykių rinkinys, kuriuo tikrinama, ar programa veikia taip, kaip tikitės.
Užtikrinkite, kad šis pilkosios dėžės testo atvejis tinkamai ištiria nagrinėjamą programinės įrangos dalį.
Taip pat atkreipkite dėmesį į nuoseklumą ir įsitikinkite, kad testavimo atvejį lengva atkartoti, kad gautumėte tikslesnius pilkosios dėžės testo rezultatus.
5. Paleiskite testavimo atvejį
Pradėkite vykdyti testavimo atvejį.
Tai reiškia, kad reikia įvesti įvesties duomenis į kiekvieną iš subfunkcijų ir pažiūrėti, kokie yra išvesties duomenys, ir užrašyti visus rezultatus.
Atliekant automatinį pilkosios dėžės testavimą, įrašymo procesas yra automatinis, o rankiniu būdu dirbantys testuotojai patys užsirašo visus įvesties ir išvesties duomenis.
Jei galite, prieš paleisdami visą srautą iš karto, išbandykite visas subfunkcijas atskirai, kad patikrintumėte, ar kiekviena funkcija veikia nepriklausomai.
6. Patikrinkite rezultatus
Gavę bandomojo atvejo duomenis, pradėkite tikrinti šiuos rezultatus.
Tai reiškia, kad reikia išnagrinėti programinės įrangos gaunamus rezultatus ir palyginti juos su rezultatais, kurių tikėjotės proceso pradžioje.
Jei tarp jų yra skirtumas, tai reiškia, kad programinėje įrangoje gali būti klaida, nes ji veikia ne taip, kaip iš pradžių prognozavote.
7. Sukurkite ataskaitą
Pasibaigus pilkosios dėžės testavimo procesui, sukurkite testavimo rezultatų ataskaitą.
Tai apima pagrindinę santrauką apie programinės įrangos problemas, kai kurių galimų problemų sprendimo būdų įvertinimą ir, jei įmanoma, visus bandymų metu gautus duomenis.
Naudojant šią struktūrą skaitytojui pateikiama pagrindinė pamoka prieš pateikiant visus būtinus įrodymus, o galiausiai tai yra vientisas dokumentas, kuriame pateikiama daug rekomendacijų.
Geriausia pilkosios dėžutės testavimo praktika
Geroji praktika – tai procesai, užduotys ir principai, kuriuos darbuotojai atlieka atlikdami kokybės užtikrinimo bandymus, kad būtų pasiekti aukščiausi įmanomi standartai.
Kai kurie iš šių geriausios praktikos pavyzdžių, skirtų kokybės užtikrinimo komandoms, norinčioms pagerinti savo darbo standartus, yra šie:
1. Dirbkite kruopščiai
Kaip ir su bet kokiu bandymų metodu, neskubėkite ir dirbkite atidžiai. Vienintelė klaida gali lemti testo negaliojimą, todėl lėtai ir nuosekliai užtikrindami, kad jūsų darbas būtų tikslus, ilgainiui sutaupysite laiko ir kartu pagerinsite programinės įrangos standartą. Tai ypač aktualu atliekant pilkosios dėžutės testavimą, nes nežinote, su kuriomis šaltinio kodo dalimis dirbate bet kuriuo metu.
2. Nuolat bendraukite
Tarp kūrėjų ir pilkosios dėžės testuotojų turėtų būti nuolatinis bendravimas. Taip kūrėjai iš karto gauna grįžtamąjį ryšį apie bet kokias testavimo komandos aptiktas klaidas, o testuotojai žino, į ką atkreipti dėmesį.
Jei klaida yra matomo pilkojo langelio aspekto dalis, praneškite kūrėjams, kurioje tiksliai vietoje ji yra.
3. Nustatykite griežtus apribojimus
Kai atliekant pilkosios dėžutės testavimą dirbtinai ribojama informacija, o įmonė pati nusprendžia, kokią informaciją pateikti testuotojams, užtikrinkite, kad būtų nustatytos griežtos ribos.
Suteikite kokybės užtikrinimo komandai tik tuos leidimus, kurių jai reikia, antraip rizikuojate, kad jie „užbėgs už akių” ir pamatys dalį pirminio kodo ar kūrimo dokumentų, kuriuos stengiatės paslėpti.
7 klaidos ir spąstai įgyvendinant pilkosios dėžės testus
Kasmet per testavimo procesą išbandoma šimtai tūkstančių programų, todėl QA komandos daro tam tikras klaidas ir pasimeta.
Žinodami apie jas, galite veiksmingai jų išvengti, taip pagerindami savo darbą ir sumažindami tikimybę švaistyti išteklius netinkamoms testavimo strategijoms.
Kai kurios dažniausiai pasitaikančios pilkosios dėžės testų klaidos ir spąstai yra šie:
1. Paskirstytų sistemų testavimas
Pilkosios dėžutės testavimui reikia prieigos prie pirminio kodo, o paskirstytuose serveriuose naudojamas kodas iš kitų vietų. Dėl to kyla problemų atliekant pilkosios dėžutės bandymus, nes tai reiškia, kad yra problemų, kurių bandytojai gali nepastebėti.
2. Nenuoseklaus testavimo užbaigimas
Nenuoseklus testavimas – tai situacija, kai testavimo atvejis skiriasi tarp bandymų. Dėl to rezultatai gali būti netikslūs, o kūrėjai, remdamiesi klaidingais rodikliais, gali sutelkti dėmesį į našumo gerinimą.
Jei įmanoma, kiekvieną bandymą atlikite vienodai, kad padidintumėte bandymų tikslumą ir tikslumą.
3. Skubus testų atlikimas
Jei artėja siūloma produkto išleidimo data, kokybės užtikrinimo komandos gali būti linkusios paskubinti pilkosios dėžutės testavimo procesus.
Tačiau tai yra blogo planavimo požymis, į kurį nereikėtų reaguoti dar blogesniais sprendimais. Skubotas testavimas lemia netikslius rezultatus ir laiko švaistymą vėlesniame kūrimo etape.
4. Rankinio ir automatizuoto darbo nevykdymas kartu
Nei rankinis testavimas, nei automatizuotas testavimas nėra tobuli pilkosios dėžės testavimo metodai.
Naudodami abi šias priemones kartu, galite atsižvelgti į kiekvienos iš jų problemas ir galiausiai dirbti efektyviau.
Bent jau apsvarstykite galimybę derinti šiuos du metodus, kad būtų galima geriau atlikti bandymus.
5. Darbas be įrankių
Testavimo įrankiai sukurti taip, kad pilkosios dėžės testuotojo darbas būtų kuo paprastesnis. Dirbdami be jokių įrankių be reikalo ribojate savo galimybes.
Kruopščiai ištirkite ir įsigykite visas priemones, kurios galėtų padėti kurti, kad padidintumėte efektyvumą ir sumažintumėte klaidų tikimybę.
6. Prastas bendravimas
Vidinė komunikacija tarp skyrių gali būti sudėtinga, tačiau testavimo ir kūrimo skyriai privalo kuo aiškiau bendrauti.
Geresnis bendravimas reiškia, kad kūrėjai žino, kokius patobulinimus reikia atlikti nedelsiant, ir sprendžia problemas nesuklaidinami dėl prastų vidinių pranešimų.
7. Aktyvi klaidų paieška
Pilkosios dėžės testai skirti klaidoms rasti, jei jų esama, taip pat bendram programinės įrangos veikimui ištirti.
Per ilgai ieškodami klaidų galite sugaišti daug laiko ir atitraukti dėmesį nuo pagrindinio tikslo – patobulinti programėlės veikimą.
Pilkosios dėžės bandymų rezultatų tipai
Atliekant pilkosios dėžės testus proceso pabaigoje gaunama kelių skirtingų tipų informacija. Tai reiškia ne pačios programinės įrangos rezultatus, o duomenis, kuriuos kūrėjai gali naudoti programinei įrangai tobulinti.
Pagrindiniai išvesties tipai yra šie:
1. PASS/FAIL pranešimai
Paprastas PASS/FAIL pranešimas, kuriuo kūrėjas informuojamas apie tai, ar programinės įrangos operacija buvo sėkminga.
Tokia išvestis kūrėjui nesuteikia daug informacijos, tačiau pilkosios dėžės testavimas reiškia, kad testuotojas gali pamatyti, kuriame konkrečiame taške programinė įranga nesuveikė ir kodėl, o tai padeda išspręsti problemą.
2. Metrikos
Metrikos – tai paprasti statistiniai duomenys, apibūdinantys įvykį, pavyzdžiui, kiek laiko iki milisekundės tikslumu užtrunka atlikti tam tikrą užduotį. Tai įprasta atliekant automatinį pilkosios dėžės testavimą, kai kompiuterinės platformos automatiškai renka šią informaciją tiksliau, nei tai galėtų padaryti rankiniu būdu dirbantis testuotojas.
Ši informacija naudinga nustatant programėlės našumą.
3. Kokybiniai duomenys
Aprašomoji informacija, kurią gaunate iš pilkosios dėžutės testuotojo, remdamiesi jo patirtimi naudojant programinę įrangą. Neįmanoma įvertinti kiekybiškai, todėl sunkiau atlikti analizę, tačiau galima geriau suprasti naudotojo patirtį ir klientams patogiau naudotis programine įranga.
Pilkosios dėžės bandymų pavyzdžiai
Kai kuriais atvejais, žinant teoriją apie tam tikrą testavimo būdą, nepakanka įžvalgų ir nėra tinkamo supratimo. Norint geriau suprasti, kaip veikia testavimo metodika, būtina žinoti keletą pilkosios dėžės testų pavyzdžių.
Toliau rasite keletą pilkosios dėžės testų pavyzdžių, kuriuose pateikiama daugiau informacijos apie testus realiame pasaulyje ir teorijos taikymą praktinėse darbo vietose.
1. Sėkmingo saugumo testavimo pavyzdys
Įmonė kuria duomenų bazę, kurioje yra daug asmeninių duomenų, ir planuoja atlikti saugumo bandymus, kad įsitikintų, jog naudotojų duomenys yra apsaugoti.
Rankinis testuotojas atlieka procesą, ieškodamas galimų kodo trūkumų ir galimybių pasiekti programos dalis.
Radęs silpnąją vietą, testuotojas informuoja kūrėją apie tai, kur yra silpnoji vieta ir kaip ją išnaudojo.
Kai programinė įranga ištaisoma, testuotojas vėl atlieka tą patį testą, kad įsitikintų, jog sistema yra saugi.
2. Nesėkmingo duomenų bazės testavimo pavyzdys
Duomenų bazę kuriantys kūrėjai turi trumpą išleidimo terminą ir turi greitai atlikti bandymus.
Testuotojai paskubomis surenka keletą pagrindinių testavimo atvejų ir greitai juos užbaigia, darydami vykdymo klaidas, neparengia išvesties prognozių ir neišnagrinėja subfunkcijų.
Kadangi jie nerengia išvesties prognozių, jie nesuvokia išvesties problemų, todėl siunčia netinkamai veikiantį produktą.
Klaidų ir klaidų, aptiktų atliekant pilkosios dėžės testavimą, tipai
Vienas iš pagrindinių pilkosios dėžės testavimo tikslų – rasti programos klaidas ir klaidas, nes įmonės siekia pateikti aukštos klasės programas, kuriomis klientai galėtų pasitikėti, kai tik įmanoma.
Atliekant pilkosios dėžutės testavimą galima rasti kelių konkrečių tipų klaidų ir trikdžių, kurių kiekvienas gali reikšti skirtingą kodo problemą.
Atliekant pilkosios dėžės testavimą aptinkamos tokios klaidos ir klaidos:
1. Proceso gedimas
Pirmoji klaidos forma yra proceso nesėkmė.
Tai reiškia, kad testas negrąžina jokio rezultato ir tiesiog nutrūksta.
Egzistuoja kelios galimos šių problemų priežastys, o idealiu atveju pilkosios dėžės testuotojas gali nustatyti, iš kur kyla problema ir kaip programuotojas gali sukurti atsaką.
2. Neteisingas išėjimas
Kai kurios pilkosios dėžės testavimo klaidos atsiranda, kai proceso išvestis nėra tokia, kokios tikėjosi kūrėjai.
Tai rimta problema, pavyzdžiui, duomenų bazėje, kurioje būtina saugiai saugoti teisingą informaciją.
3. Saugumo klaidos
Saugumo klaidų pasitaiko, kai įmonės programa yra šiek tiek nesaugi ir leidžia trečiosioms šalims pasiekti joje saugomą informaciją.
Saugumo trūkumai taikomojoje programoje gali būti susiję su BDAR ir lemti, kad programa neatitinka daugelio tarptautinių reglamentų.
Bendrieji pilkosios dėžės testavimo rodikliai
Metrikos – tai nuolatiniai matavimai, kuriais tiriamas tam tikras įvykis ar įvykių serija, paprastai kiekybinių duomenų pavidalu.
Naudodami metrikas, testuotojai ir kokybės užtikrinimo komandos gali išnagrinėti „pilkosios dėžutės” testuojamą programinę įrangą ir tiksliai nustatyti, kas vyksta ne taip, nesvarbu, ar atsiranda daugiau klaidų, ar ilgiau užtrunka įvairių funkcijų įkėlimas.
Kai kurie iš labiausiai paplitusių pilkosios dėžės testavimo rodiklių, kuriuos QA testuotojai naudoja vertindami programinę įrangą, yra šie:
– Laikas iki išėjimo:
Laikas, per kurį programa pateikia išvestį po bandymo pradžios.
– Laikas iki atsakymo:
Laikas, per kurį programinė įranga reaguoja į naudotojo įvestį, nesvarbu, ar tai būtų rezultatas, ar tiesiog patvirtinimas apie įvestį.
– Klaidų skaičius:
Grynasis programinės įrangos procesų klaidų skaičius.
– Kiekvienos funkcijos klaidos:
Klaidų skaičius, padalytas iš programinės įrangos funkcijų skaičiaus, naudojamas klaidų tankiui nustatyti.
Geriausi pilkosios dėžės testavimo įrankiai
Atliekant pilkosios dėžės testavimą galima remtis išorinėmis priemonėmis, kurios pagerina jūsų darbo kokybę, automatizuoja kai kuriuos procesus ir padeda jums ištaisyti rastas klaidas.
Kuo geresnį testavimo įrankį naudosite, tuo daugiau problemų atskleisite ir tuo geresnis bus galutinio produkto standartas, o testavimo metu sutaupysite laiko ir išteklių.
Toliau rasite keletą geriausių pilkosios dėžės testavimo įrankių, taip pat kiekvienos platformos privalumus ir trūkumus.
5 geriausi nemokami pilkosios dėžės testavimo įrankiai
Kai mažesnė įmonė nori pradėti pilkosios dėžės testavimą, būtina turėti tinkamų įrankių, tačiau taip pat svarbu, kad jie būtų prieinami už priimtiną kainą. Mažoje įmonėje svarbus kiekvienas centas, o programėlių kūrėjas – ne kitaip, nes dėl riboto biudžeto tenka priimti sunkius sprendimus.
Naudojant nemokamus pilkosios dėžės testavimo įrankius galima užtikrinti kokybę naudojant minimalius išteklius.
Vieni geriausių nemokamų pilkosios dėžės testavimo įrankių yra šie:
1. „ZAPTEST” NEMOKAMAS LEIDIMAS
Nemokama „ZAPTEST” versija vartotojams siūlo aukštos kokybės automatizavimo patirtį, o pilnas programinės įrangos automatizavimas palaiko testavimą nuo pat kūrimo pradžios.
Naudodami lygiagretaus vykdymo funkciją galite vienu metu atlikti kelis testus ir taip pagreitinti procesus, o kai būsite pasiruošę pereiti į kitą lygį, „Enterprise” leidimas leis pereiti į kitą lygmenį kuo paprasčiau. Papildoma nauda – ZAPTEST taip pat siūlo moderniausią RPA technologiją be jokių papildomų išlaidų.
Puikus pasirinkimas tiems, kurie dar tik pradeda bandymus.
2. Appium
„Appium” yra kruopštaus testavimo įrankis, skirtas padėti įsitikinti, kad mobiliosios programėlės atitinka standartus, turi aktyvią palaikymo bendruomenę, tačiau testus atlieka palyginti lėtai. Dėl sudėtingos sąrankos tai nėra geriausias nemokamas įrankis daugeliui įmonių.
3. „Chrome Dev Tools
„Google Chrome” siūlo daugybę žiniatinklio programoms skirtų kūrimo įrankių, o integracija į populiariausią naršyklę atrodo būtina.
Tačiau ji apsiriboja tik dėžutės elementų testavimu, todėl yra ribota testavimo priemonė.
4. JUnit
„JUnit” – tai atvirojo kodo sistema, kuri leidžia naudotojams atlikti kartotinius testus „Java” kalba, apsiribojant tik viena kalba.
Pats savaime šis apribojimas nėra problema, tačiau paprastos API ir sąsajos nebuvimas gali atbaidyti naujesnius testuotojus.
5. DBUnit
„DBUnit” daugiausia dėmesio skiriama į duomenų bazes orientuotiems projektams, naudojant žinomas būsenas, kad būtų galima tiksliai patikrinti rezultatus ir visapusiškai išnagrinėti rezultatus.
Tai puikiai tinka duomenų bazėms ir panašioms programoms, tačiau dėl integracijos palaikymo trūkumo ji sunkiai atlieka įvairių platformų užduotis.
5 geriausi įmonių pilkosios dėžės testavimo įrankiai
Augant kūrėjui, didėja ir jo testavimo reikalavimai, o didesnėse įmonėse kuriamos didesnės programos, todėl joms reikia išsamesnių testavimo rinkinių.
Įmonių pilkosios dėžės testavimo įrankiai yra skirti padėti įmonėms tokioje situacijoje, nes suteikia daugiau galimybių naudotis išplėstinėmis funkcijomis, kurių mėgėjams ir nedidelės apimties kūrėjams gali neprireikti.
Kai kurios geriausios įmonės klasės testavimo priemonės, skirtos pilkosios dėžės testams atlikti, yra šios:
1. „ZAPTEST ENTERPRISE EDITION
Įmonės versijoje ZAPTEST suteikiama daugiau testavimo galimybių nei nemokamoje versijoje, o vienas iš pagrindinių privalumų – nuolatinė prieiga prie ZAP eksperto. „ZAP Expert” veikia kaip patarėjas ir jūsų komandos narys nuotoliniu būdu, padėdamas patenkinti visus jūsų įmonės testavimo poreikius.
Kūrėjai, investavę į „ZAPTEST Enterprise” versiją, gali gauti iki dešimties kartų didesnę investicijų grąžą dėl pažangių kompiuterinės regos technologijų, 1SCRIPT, skirtingų platformų, skirtingų įrenginių, skirtingų naršyklių vykdymo ir, svarbiausia, neribotų licencijų.
Neribotas licencijų skaičius ir pažangiausia testavimo ir RPA technologija reiškia, kad įmonės gali naudotis fiksuotomis išlaidomis, nepriklausomai nuo to, kaip greitai ir kiek jos auga.
2. TestRail
Testavimo atvejų valdymo sprendimas, leidžiantis visus atliktus testus suskirstyti pagal testavimo atvejus ir tiksliau registruoti duomenis.
Tačiau „TestRail” nebūtinai idealiai tinka „pilkosios dėžutės” testavimui, nes joje sunku suderinti rankinį testavimą ir automatinį testų įrašymą.
3. Testas
Testavimo platforma, kurioje daugiausia dėmesio skiriama stabiliems individualiems testams atlikti, įgyvendinant tiek koduotus testavimo atvejus, tiek nekoduotas alternatyvas.
Kadangi ši platforma yra nemokama tik tam tikram bandymų skaičiui per mėnesį, didesnėms organizacijoms gali būti sunku ja pasinaudoti.
4. TestRigor
„TestRigor” yra plačiai vertinama platforma, kurioje testams atlikti naudojamas dirbtinio intelekto variklis, o viena iš patrauklesnių funkcijų yra dirbtinio intelekto testų priežiūra.
Tačiau tai kainuoja nemažai, o kitos platformos užtikrina geresnę investicijų grąžą.
5. Kobiton
„Kobiton” yra testavimo platforma, kurios kainodara yra gana lanksti ir kuri, pasibaigus nemokamam bandomajam laikotarpiui, automatizuoja testus pagal kiekvieną vartotoją.
Kai kurie naudotojai nerimauja dėl „Kobiton”, nes „Kobiton” santykinai nepakankamai padeda spręsti testuotojų užklausas.
Kada turėtumėte naudoti „Enterprise”, o kada „Freemium” pilkosios dėžutės įrankius?
Tiek įmonės, tiek nemokami pilkosios dėžutės įrankiai suteikia naudotojams daug privalumų. Įmonėms geriausia pradėti nuo nemokamo produkto, kad susipažintų su testavimo procesu, o vėliau, didėjant poreikiams, pereiti prie įmonės versijos versijos.
Taip užtikrinamas projekto tęstinumas, o darbuotojams reikia mažiau mokytis iš naujo.
Perėjimo momentas kiekvienoje įmonėje skiriasi, tačiau tam tikru metu investicijų į įmonės produktą grąža tampa neišvengiama.
Pilkosios dėžės testavimo kontrolinis sąrašas, patarimai ir gudrybės
Pilkosios dėžės testavimas yra gana sudėtingas procesas, todėl kontrolinio sąrašo turėjimas padeda įsitikinti, kad atlikote viską, ką reikia atlikti atliekant testavimą.
Be kelių patarimų, kaip pagerinti testavimo kokybę, kai kurios pagrindinės pilkosios dėžės kontrolinio sąrašo savybės yra šios:
1. Kruopštus planavimas
Išsamus planavimas yra vienas pirmųjų dalykų, kuriuos reikia pažymėti teste, nes būtina suplanuoti absoliučiai visus testo aspektus.
Kuo daugiau planuojate, tuo labiau struktūruotas yra jūsų testavimas, nes žmonės žino, kokius testus jie atlieka ir kada juos atlieka.
Taip pat gaunami nuoseklūs duomenys, kurie puikiai tinka geresniems kūrėjų sprendimams.
2. Momentinės duomenų ataskaitos
Dirbdami su pilkosios dėžės testavimo procesu, stenkitės iš karto pateikti duomenis. Kurdami ataskaitas kuo greičiau, padidinsite ataskaitų teikimo procesų tikslumą, nes visa informacija dar šviežia.
Tai ypač pasakytina apie kokybinę informaciją, nes ją turi užrašyti testuotojas, o ne tiesiog saugoti testavimo platformoje.
3. Nustatykite atsakomybę
Per visą testavimo procesą užtikrinkite, kad visi darbo vietoje sutelktų dėmesį į konkrečias pareigas. Taip nustačius atsakomybę, kiekvienas žino, koks yra jo vaidmuo darbo vietoje, ir supranta, kaip produktyviai ir kuo mažiau trukdant atlikti užduotis.
Nors tai daugiau valdymo koncepcija, o ne testavimo kontrolinio sąrašo punktas, jis turi didelę įtaką rezultatams.
4. Nuolatinis palyginimas
Beveik nuolat lyginkite savo rezultatus su keliais dalykais. Galima palyginti pradinius projektinius dokumentus, ankstesnių bandymų rezultatus ir organizacijos projekto įgyvendinimo terminus.
Turėdami šiuos atskaitos taškus nuolat sužinote, kaip vyksta programinės įrangos kūrimo procesas, kokias sritis galima tobulinti ir ką reikėtų koreguoti.
Išvada
Apibendrinant galima teigti, kad „pilkosios dėžės” testavimas yra viena iš universaliausių galimų testavimo formų, kurioje derinamas baltosios dėžės funkcionalumas ir juodosios dėžės testų šališkumo apribojimas.
Derindamos rankinio ir automatinio testavimo metodus pilkosios dėžės srityje, įmonės gali gerokai sumažinti klaidų poveikį savo programinei įrangai ir ištaisyti klaidas, kad produktas būtų geresnis.
Pilkosios dėžutės testavimas yra puikus įrankis bet kuriam kūrėjui, o pirmiau pateikti patarimai padės užtikrinti, kad jį tinkamai naudosite.
DUK ir ištekliai
Jei turite klausimų apie pilkosios dėžės testavimą, peržvelkite dažniausiai užduodamus klausimus, kad sužinotumėte daugiau ir geriau suprastumėte šio tipo testus:
1. Geriausi pilkosios dėžės testavimo automatizavimo kursai
Yra palyginti nedaug kursų, skirtų būtent pilkosios dėžės testavimo automatizavimui, todėl šie bendrieji programinės įrangos testavimo kursai yra idealus būdas pradėti:
– „Programinės įrangos testavimo pagrindas su egzaminu” – Mokymo pasiūlymai
– „6 savaičių programinės įrangos testavimo pagrindų mokymai”- Futuretrend Technologies Ltd
– „Programinės įrangos testavimo kursai”- Royal Course
– „Juodosios ir baltosios dėžės testavimas”- „Coursera
– „Programinės įrangos testavimas – juodosios dėžutės strategijos ir baltosios dėžutės testavimas”- NPTEL
2. Kokie yra 5 svarbiausi interviu klausimai apie pilkosios dėžės testavimą?
– Kokios patirties turite dirbant su pilkosios dėžės testavimu ir kaip jums tai pavyko?
– Kodėl įmonės naudoja „pilkosios dėžės” testavimą ir kuriame proceso etape?
– Palyginkite baltosios, pilkosios ir juodosios dėžės bandymus
– Kokie yra didžiausi pilkosios dėžės testavimo iššūkiai ir kaip juos įveikti?
– Kaip veikia bandymų automatizavimas?
3. Geriausios „YouTube” pilkosios dėžutės testavimo pamokos
– „Kas yra pilkosios dėžės testavimas? Kokie metodai naudojami atliekant pilkosios dėžės testavimą? Su pavyzdžiu paaiškinta”- Software Testing Hacks
– „Pilkosios dėžės testavimas | programinės įrangos inžinerija |”- Education 4u
– „Juodosios dėžės, baltosios dėžės ir pilkosios dėžės testavimas”- „Miracle Education
– „Patarimai naujiems rankiniams QA testuotojams | Darbas su kūrėjais + dalykai, kurių išmokau kaip programinės įrangos testuotojas”- Madeline Elaine
– „Kas yra pilkosios dėžės testavimas? (Programinės įrangos testavimo interviu klausimas Nr. 54)”- QA Fox
4. Kaip išlaikyti pilkosios dėžės testus?
Pilkosios dėžės testų priežiūra yra gana paprastas procesas. Atlikdami rankinį testavimą, užtikrinkite, kad darbuotojai būtų gerai apmokyti ir kiekvieną kartą atliktų tas pačias užduotis. Atlikdami automatinį testavimą, patikrinkite visą testavimo atvejų kodą ir patikrinkite rezultatus, jei įmanoma, nuolat prižiūrėkite procesus.
5. Geriausios knygos apie pilkosios dėžės testavimą
Šiame skyriuje pateikiami ne tik knygos, bet ir žurnalų straipsniai, siekiant užtikrinti kuo aukštesnius rašytinės pagalbos kokybės užtikrinimo testuotojams standartus:
– „Programinės įrangos integracijos testavimo pilkojo langelio technika, pagrįsta pranešimu”- TanLi M. ir kt.
– „Baltosios, juodosios ir pilkosios dėžės testavimo metodų lyginamasis tyrimas”- Ehmer, M., Khan, F.
– „Grey-box FSM pagrįstos testavimo strategijos”- Petrenko, A.
– „Programinės įrangos inžinerija”- Saleh, K.A.
– „International Conference on Computer Applications 2012”- Kokula Krishna Hari K.
