Tarkvara testimine on uskumatult keeruline ja intensiivne valdkond, kus ettevõtted ja sõltumatud arendajad püüavad kõik oma tooteid erinevate testimismeetoditega parandada.
Üks levinumaid meetodeid, mida ettevõtted kasutavad testimiseks, on musta kasti testimine, mis on tehnika, mis loob arendajate ja testijate vahele distantsi, et anda täpseid tulemusi ja kõrvaldada eelarvamused.
Selles üksikasjalikus juhendis saate rohkem teada, mis on mustade kastide testimine, kuidas mustade kastide testimist läbi viia ja millised on mustade kastide testimise rakendamise eelised tarkvaraarenduses.
Mis on musta kasti testimine?
Musta kasti testimine tähendab süsteemi või tarkvara testimist ilma eelnevate teadmisteta selle sisemisest toimimisest. See ei tähenda mitte ainult seda, et ei tea lähtekoodi ennast, vaid hõlmab ka seda, et ei ole näinud tarkvara ümbritsevat projekteerimisdokumentatsiooni. Testijad lihtsalt annavad sisendit ja saavad väljundit nagu lõppkasutaja. Kuigi see on lihtne musta kasti testimise määratlus, määrab see üldise süsteemi välja.
Musta kasti testimise eesmärk on panna kasutajad suhtlema tarkvaraga tavapärasest loomulikumalt, ilma et neil oleks juba olemasolevaid eelarvamusi, mis tulenevad tarkvara tundmisest.
Selle metoodika puhul on testide läbiviimise eest vastutavad inimesed erinevad nendest, kes tarkvara arendasid, luues kahe meeskonna vahele eraldatuse.
1. Millal ja miks on tarkvaratesti puhul vaja teha musta kasti testimist?
Arendustsüklis on mõned etapid, kus musta kasti testimine on ideaalne, kusjuures enamik musta kasti testimistestimistest toimub arenduse lõpus, vahetult enne väljalaskmist.
See hõlmab selliseid meetodeid nagu kasutaja vastuvõtutestimine, mille käigus tarkvara käivad tarkvara sihtrühma liikmed testimas tarkvara väljalaske-eelse testimise vormis. See on üldtuntud kui beetatestimine ja on ettevõtte jaoks ideaalne vahend, kuna suurem kokkupuude tähendab, et inimesed leiavad tõenäolisemalt võimalikud vead tarkvaras.
Töötamine musta kasti metoodikaga arendusringi lõpus on kohustuslik, sest see on versioon, millele kasutaja tõenäoliselt juurde pääseb. Üksikute funktsioonide puhul võiks kasutada musta kasti testimist, kuid see kaotaks testimise eesmärgi.
2. Kui te ei pea tegema musta kasti testimist
Mustas kastis testimisel on väga vähe eesmärki arenduse varajases etapis. Kui ettevõte ehitab oma tarkvara põhifunktsioone, kasutab ta valge kasti testimist, et arendaja saaks näha, millises punktis koodis on probleeme.
Samuti ei ole vaja musta kasti testimist, kui tarkvara on avatud lähtekoodiga või suhteliselt lihtne veebitööriist või mõeldud kolmanda osapoole kodeerimisprojektide abistamiseks, sest kasutajaliides on suhteliselt paljas ja kasutaja pääseb niikuinii ligi programmi lähtekoodile. Kui eeldate, et kasutaja pääseb ligi lähtekoodile, kaotab musta kasti testimine oma põhieesmärgi.
3. Kes on kaasatud musta kasti testimisse?
Mustas kastis testimise protsessis on palju rolle, millest mõned sõltuvad testimist teostava ettevõtte iseloomust.
Olulised rollid, mis on seotud musta kasti testimise protsessiga, on järgmised:
– Testija
Testija vastutab ettevõttes manuaalsete testjuhtumite täitmise eest, kirjutades põhjalikke testjuhtumeid, mis uurivad rakendust üksikasjalikult enne nende täitmist ja tulemuste esitamist. See roll eksisteerib peamiselt manuaalses testimisprotsessis, kusjuures automatiseeritud süsteemid võtavad selle rolli üle, kui testide automatiseerimine on olemas.
– QA analüütik
QA analüütik vastutab testjuhtumite programmeerimise eest QA protsessis, peamiselt siis, kui ettevõte kasutab QA testide automatiseerimise protsessi.
Protsess hõlmab nii põhjalike testjuhtumite kavandamist, mis tagavad funktsionaalsuse kõrge taseme, kui ka testjuhtumite täitmist, mille lõpptulemuste väljaselgitamist.
– Arendaja
Isik, kes vastutab tarkvara arendamise eest, mida QA meeskond testib. Arendaja saab testimismeeskonnalt tagasisidet ja uuendab tarkvara vastavalt sellele, töötades osana arendusmeeskonnast, kuid olles pidevas suhtluses testijatega.
– QA juht
Kvaliteedi tagamise juht on kvaliteedi tagamise meeskonna juht ja vastutab kõigi testerite poolt täidetavate ülesannete juhtimise eest.
See hõlmab testimisgraafiku koostamist, töötajate tööde nimekirja koostamist ja meeskonnas tekkivate konfliktide lahendamist. Samuti selgitavad nad mustade kastide testimist uute töötajate koolitusel.
– Projektijuht
Projektijuht vastutab lõpliku projekti kvaliteedi eest ja jälgib nii testimisprotsessi kui ka arendustegevust, tagades, et klient saab tarkvarapaketi, mis vastab kogu projektile.
Musta kasti testimise eelised
Mustas kastis testimise kasutamisel on mitmeid olulisi eeliseid. Mida rohkem te olete neist eelistest teadlik, seda rohkem saate neid ära kasutada, kasutades võimalikult palju eeliseid sellest tehnikast.
Mõned peamised eelised musta kasti testimise kasutamisest kvaliteedi tagamisel on järgmised:
1. Tehnilisi teadmisi ei ole vaja
Musta kasti lähenemisviis tähendab, et rakenduse uurimisel ei ole vaja tehnilisi teadmisi.
Musta kasti testimise eesmärk on uurida, kuidas rakendus töötab lõppkasutaja jaoks, ja tavakasutajal ei ole enamikus olukordades edasijõudnud tehnilisi teadmisi. See võib vähendada testimise kulusid, aidates organisatsioonil leida rohkem vigu väiksemate kuludega, muutudes seega rahaliselt tõhusamaks.
2. Modelleerida kasutaja täpselt
Musta kasti testimise eesmärk on mõista, millised on rakenduse probleemid, kui kasutaja igapäevaselt sellega suhtleb.
Mõned musta kasti testimise liigid – mis keskenduvad kasutaja käitumise jäljendamisele – modelleerivad kasutaja käitumist suure täpsusega. See kehtib eriti kasutajate vastuvõtutestide puhul, kus lõppkasutajad kogevad toodet, mitte lihtsalt modelleerides või simuleerides kasutaja käitumist, vaid rakendades seda tegelikult.
Täpne modelleerimine aitab avastada kõik vead, mis mõjutavad kasutaja tegelikke töövooge.
3. Võimalus testimise ühisrahastamiseks
Mustas kastis testimine on tänu suhteliselt madalatele oskustevajadustele väga kättesaadav testimisviis.
See tähendab, et ettevõtted ei saa mitte ainult palgata madalama tehniliste oskustega testijaid, vaid nad saavad testimist teha rahvahääletuse korras innukatele klientidele. See on mängutööstuses üha tavalisem, sest ettevõtted pakuvad varajase juurdepääsu versiooni, uuendades mängu aja jooksul, et lahendada kasutajate poolt leitud probleeme.
Sellisel juhul on vigade leidmine palju lihtsam, kuna kõik funktsioonid saavad palju suurema tähelepanu osaliseks.
Musta kasti testimise väljakutsed
Lisaks musta kasti testimise eelistele on ka mõned suured probleemid, millega peate arvestama. Nende probleemide teadvustamine tähendab, et saate nendega kohaneda, tõstes oma testimise taset, vähendades musta kasti testimise kahjulikke mõjusid.
Mõned neist väljakutsetest on järgmised:
1. Raske leida probleemi põhjuseid
Üks peamisi musta kasti testimise puudusi on see, et probleemide põhjuse leidmine võib olla raskem, kui testijatel ei ole juurdepääsu lähtekoodile.
Kuigi nad oskavad kirjeldada, mis on viga ja millal see ilmneb, ei ole neil mingit teavet selle kohta, milline osa lähtekoodist põhjustab probleeme või miks.
Testijad saavad seda mõnevõrra leevendada, kui nad teevad põhjalikke märkmeid, kusjuures arendaja üksikasjalikud veateated pakuvad ka täiendavaid teadmisi tulevaste uuenduste kohta.
2. Automatiseerimine on keerulisem
Kuna püüate aktiivselt jäljendada viisi, kuidas kasutaja suhtleb tarkvarapaketiga, võib musta kasti testimise automatiseerimine olla äärmiselt keeruline.
Esimene põhjus on asjaolu, et testijal puudub juurdepääs lähtekoodile, mis raskendab täpse testjuhtumi kodeerimist. See on seotud asjaoluga, et testimine on kavandatud nii palju kui võimalik jäljendama inimese käitumist, kusjuures automaatika on spetsiaalselt loodud käituma robotlikult.
Seda probleemi saab tasakaalustada, automatiseerides lihtsamaid ülesandeid ja kombineerides automatiseerimist võimaluse korral käsitsi tehtavate testidega.
3. Raskused suurte testide läbiviimisel
Eespool mainitud probleemid automatiseerimisega tähendavad, et testimine suuremates mõõtkavades on keerulisem. Suuremahuline testimine annab ettevõtetele palju rohkem andmeid tarkvara kohta ning tähendab, et vigu on lihtsam leida ja korrata.
Manuaalse testimise nõue kui prioriteet tähendab, et testimist võib olla keerulisem korraldada suuremates mõõtkavades. Mõned ettevõtted kasutavad selle vastu “avatud beetasüsteemi”, mille puhul kõik, kes on toote vastu huvitatud, saavad aidata väljaande-eelses testimises ja toetada ettevõtet, andes vabatahtlikult tagasisidet varajaste versioonide kohta.
Musta kasti testide omadused
Mustade kastide testimisel on mõned peamised omadused, mida tuleb silmas pidada ja mis eristavad seda testimist mis tahes muust tarkvara kvaliteedi tagamise vormist.
Nende omaduste hulka kuuluvad:
1. Puuduvad eelnevad sisemised teadmised
Musta kasti testid ei nõua eelnevaid sisemisi teadmisi tarkvarast. Mõnel juhul võib see olla keeruline, kuna testijatel on teatav ettekujutus tarkvara aspektidest, mida nad testivad, ja mõnest funktsioonist, mida nad otsivad, kuid see on laias laastus määratletud nii, et nad ei saa näha mingit sisemist dokumentatsiooni.
Lihtsamalt öeldes, kui teave oleks lõppkasutajale nähtav rakenduspoes või veebisaidi allalaadimislehel, siis võib testija seda näha.
2. Eraldi testijad ja arendajad
Testimis- ja arendusetapid viiakse lõpule erinevate inimeste poolt mustas kastis testimise olukorras. See erinevus tuleneb testijate teadmiste puudumisest, kuna arendajatel on teadmised lähtekoodist tänu sellele, et nad vastutavad selle väljatöötamise eest.
Ettevõtted lähenevad sellele mitmel erineval viisil, sõltuvalt nende konkreetsest olukorrast: mõned kasutavad testimise läbiviimiseks välist organisatsiooni ja suuremad ettevõtted kasutavad selleks spetsiaalseid testijate osakondi.
3. Hilisema etapi testimine
See viitab arenguetapile, milles see testimine toimub. Musta kasti testid tuginevad olemasoleva rakenduse suhteliselt täiustatud versioonile, millel on põhjalik kasutajaliides, mis võimaldab täielikku navigeerimist tarkvaras ja juurdepääsu iga funktsiooni esiotsale.
See tähendab, et musta kasti testid on võimalikud ainult mõnes testimisprotsessi hilisemas etapis, kui kõik see on algselt välja töötatud. Kuigi kasutajaliideseid ja juhtimisseadmeid võidakse aja jooksul muuta, peavad need olema mingil kujul olemas, et võimaldada mustas kastis toimivate testide juurdepääsu funktsionaalsusele.
Mida me testime musta kasti testides
Musta kasti testimine uurib tarkvarapaketi konkreetseid aspekte, andes lisateavet mõnes tarkvara valdkonnas, mis viib uuendusteni, mis tõstavad üldist elukvaliteeti.
Mõned peamised tarkvarapaketi osad, mida testijad musta kasti testi käigus uurivad, on järgmised:
1. Funktsionaalsus
Mõned arendajad kasutavad musta kasti testimist, et tagada, et tarkvara töötab nii, nagu see on ette nähtud kellelegi, kes ei oma olemasolevaid teadmisi.
Enamik inimesi, kes kasutavad mis tahes tarkvara kaubanduslikul eesmärgil, teevad seda ilma, et nad mõistaksid tarkvara sisemisi toiminguid, seega tähendab testimine nende teadmiste omamise ajal, et te teate, kuidas lahendada olemasolevaid probleeme.
Selline põhjalik funktsionaalsuse testimine tagab, et kõik saavad kogeda parimat, mida rakendusel on pakkuda, selle asemel, et kohtuda vigadega, mida valge kasti testimisel ei nähta.
2. Kasutajaliides
Kasutajaliides viitab igale viisile, kuidas kasutaja praktiliselt rakendusega suhtleb, et see täidaks teatud ülesandeid. See hõlmab menüüsid, millega kasutaja töötab, konkreetsed nupud, mis on rakenduses olemas, ja kogu tarkvaras kasutatav kaubamärk.
Arendajad kulutavad suurema osa oma ajast sellele, et rakendus ise töötaks ootuspäraselt, mis tähendab, et kasutajaliidesele pööratakse vähem tähelepanu.
Mustas kastis testimise käigus tutvuvad testijad ainult tarkvara kasutajapoolsete funktsioonidega, pöörates rohkem tähelepanu kasutajaliidesele kui enamikus muudes testimise etappides.
3. Tulemuslikkus
Lisaks tavapärasele toimimisele ja heale välimusele on klientide meeldimiseks oluline ka see, kuidas rakendus toimib.
Jõudlus viitab mitmele tegurile, sealhulgas rakenduse kiirusele kasutaja sisenditele reageerimisel ja ressurssidele, mida see kasutab mis tahes seadmes.
Selliste testimisvormide abil, nagu lõpuni testimine, mille käigus uuritakse kõiki tarkvara funktsioone, saavad arendajad näha, kui palju mälu rakendus kasutab ja millised funktsioonid koormavad vastavaid seadmeid kõige rohkem, suunates rakenduse hilisemate versioonide tõhususe ja jõudlusega seotud uuendusi.
Mõningate segaduste selgitamine:
Must kast vs. valge kast vs. Greybox testimine
Musta kasti testimine on kontseptsioon, mis kõlab sarnaselt halli kasti ja valge kasti testimisega, kuid need ideed on põhimõtteliselt väga erinevad. Nende segiajamine võib põhjustada tõsiseid kommunikatsiooniprobleeme arendusprotsessis ning põhjustada uuendamisprotsessi aeglustumist ja vähem tõhusust.
Lugege edasi, et selgitada mõningat segadust erinevate “kasti testimise” liikide ümber, kuidas need üksteisest erinevad ja millal neid kasutada.
1. Mis on valge kasti testimine?
Valge kasti testimine on mõnikord tuntud ka kui “klaasist kasti testimine” ja viitab testimisprotsessile, mille puhul testijal on täielik juurdepääs kogu tarkvaraga seotud teabele. See hõlmab juurdepääsu lähtekoodile ja projekteerimisdokumentidele ning paketi kliendikokkuvõtet.
Näiteks kui testija töötab arendusprotsessi kõige varasemates etappides, uurides ühte funktsiooni, tähendab võimalus näha selle funktsiooni lähtekoodi, et ta saab kohe leida probleemi põhjuse.
Üheks parimaks ajaks valge kasti testimise kasutamiseks on peamiselt sisemised ülesanded. See viitab rakenduse funktsionaalse poole varajasele arendamisele, kusjuures kiired parandused on ideaalsed, sest koodi hägustamisest ei ole kasu, kui te ei simuleeri kasutajakogemust. Valge koodi testimist kasutatakse ka avatud lähtekoodiga süsteemides, kuna sellisel juhul on lähtekood kõigile kasutajatele kättesaadav.
Millised on erinevused valge kasti ja musta kasti testimise vahel?
Peamine funktsionaalne erinevus musta kasti testimise ja valge kasti testimise vahel on testija juurdepääsu tase tarkvarale, kuid sellel on palju suurem mõju testimise aspektidele, näiteks ajastusele.
Musta kasti testimist kasutatakse järjepidevamalt hiljem, kui toode läheneb turuleviimisele, kusjuures põhilisemad arendusetapid saavad kasu valge kasti testimise läbipaistvusest ja reageerimisvõimest. Kui vaadelda musta kasti testi ja valge kasti testi, siis erinevad need kaks ka vajalike teadmiste taseme poolest, kuna valge kasti testimine nõuab teadmisi kodeerimise ja arenduse kohta, et olla tõhusam.
2. Mis on halli kasti testimine?
Hall kast testimine on testimise vorm, kus kasutajal on teatav arusaam koodist, kuid tal ei ole täielikku juurdepääsu. See hõlmab testitava funktsiooni lähtekoodi olemasolu või juurdepääsu mõnele disainidokumentatsioonile, et kasutaja saaks aru, mis on tarkvarapaketi üldine eesmärk.
Näiteks kui testija uurib ainult ühte tarkvarapaketi funktsiooni, võidakse talle anda juurdepääs selle rakenduse ühe osa lähtekoodile.
Ettevõtted kasutavad halli kasti testimist peamiselt siis, kui nad uurivad, kuidas rakendus on integreeritud kolmanda osapoole tööriistaga. Neil on juurdepääs ainult protsessi ühe osa lähtekoodile, mis piirab nende võimet viia lõpule põhjalik valge kasti testimine. Selle asemel näevad nad kolmanda osapoole integratsiooni sisendeid ja väljundeid ning integratsiooni eest vastutavat lähtekoodi.
Testijad kasutavad seda selleks, et hinnata, kas probleemid tekivad tarkvara, kolmanda osapoole rakenduse või nende kahe integreerimise tõttu.
Millised on erinevused musta kasti ja halli kasti testimise vahel?
Peamine erinevus musta kasti ja halli kasti testimise vahel on jällegi juurdepääs teabele, kusjuures testitava tarkvara tüüp on üks peamisi eristavaid tegureid nende testimisviiside vahel.
Hall kast testimine kipub hõlmama kolmanda osapoole vahendeid, nagu pilve andmesalvestus või välised töötlemisvahendid, samas kui musta kasti süsteemid kipuvad olema üks terviklik üksus. Paljud musta kasti testid on kolmandate osapoolte poolt katkestamata, samas kui integreeritud rakenduste puhul on vähe võimalusi, kui töötada halli kasti testimise metoodika alusel.
3. Kokkuvõte: Black Box vs. White Box vs. Grey Box testimine
Lõppkokkuvõttes on musta, halli ja valge kasti testimise vahel põhimõttelised erinevused, mis põhinevad kõik sellel, kas testimismeeskonnale esitatakse kulisside taga olev teave.
Musta kasti ja valge kasti testimine on selle spektri äärmused, kusjuures halli kasti testimine hõlmab kõike, mis ei näe kõike, välja arvatud kolmanda osapoole lähtekoodi, kuni ainult konkreetse funktsiooni koodi nägemiseni.
Kõigil neil testimismeetoditel on siiski oma roll tarkvara testimise valdkonnas, nii et nende õppimisele ja tõhusale rakendamisele tuleb kindlasti aega ja tähelepanu pöörata.
Mustade kastide testide tüübid
On olemas kolm peamist musta kasti testimise tüüpi, mis hõlmavad kõiki testimisi, mida ettevõte teostab musta kasti metoodika abil. Need on järgmised:
1. Funktsionaalne testimine
Funktsionaalne testimine hõlmab kõike, mis on seotud rakenduse mehaanilise tööga. See hõlmab selle tagamist, et see töötleb andmeid õigel viisil, võimaldab kasutajatel õigete volitustega sisse logida ning töötleb teavet ja sisendeid ootuspäraselt.
Funktsionaalsuse testimine on protsessi üks olulisemaid aspekte ja hõlmab nii rakenduse kohalikku funktsionaalsust kui ka seda, kuidas see suhtleb väliste tööriistade ja programmidega, näiteks pilvepõhiste teenuste või ühekordse sisselogimise vahenditega.
2. Mittefunktsionaalne testimine
Mittefunktsionaalne testimine tähendab testimist, mille käigus uuritakse tarkvara mis tahes aspekte, mis ei ole otseselt seotud rakenduse funktsionaalsusega. See hõlmab selle kindlakstegemist, kas rakendus on kasutatav ja kasutajatele kergesti arusaadav, kas see ühildub paljude erinevate seadmete ja operatsioonisüsteemidega ning kuidas see toimib märkimisväärse koormuse korral (kuigi see võib kohati minna üle funktsionaalseks testimiseks).
See toimub peamiselt arendusprotsessi lõpus, kui kogu rakendus on kompileeritud.
3. Regressioonitestimine
Pärast uuendamist vaatavad testijad rakenduse läbi, et veenduda, et see on täitnud kavandatud funktsiooni ja et ei ole tahtmatuid kõrvalmõjusid, mis põhjustavad rakenduse taandarengut.
Seda nimetatakse regressioonitestimiseks ja see on oluline osa selle tagamisel, et rakendus oleks valmis turule minekuks.
Pärast iga uuendust kasutatakse regressioonitestimist, et veenduda, et nii rakenduse funktsionaalsed kui ka mittefunktsionaalsed aspektid vastavad varem saavutatud standardile.
Musta kasti testimise tehnikad
Kui läbite musta kasti testimise protsessi, on olemas suur hulk tehnikaid, mida saate rakendada oma töö taseme parandamiseks. Mõned kõige olulisemad musta kasti testimise meetodid, mida kasutate kvaliteedi tagamise keskkonnas, on järgmised:
1. Paaripõhine testimine
Paartestimine on testimise vorm, mis keskendub iga võimaliku andmesisestuse kombinatsiooni proovimisele tarkvaras.
Näiteks kui ühes veerus on kõik kehtivad kirjed numbrite üks kuni kümme ja teises veerus kõik tähestiku tähemärgid, testitakse paarikaupa iga võimalikku kombinatsiooni 1A kuni 10Z. See on testimise vorm, mille läbiviimine võib võtta kasutajalt palju aega ja vaeva, mistõttu on see üks tehnikatest, mis on kõige avatum potentsiaalsele hüperautomaatikale. See on äärmiselt põhjalik ja leiab kõik võimalikud probleemid andmete sisestamisel.
2. Piirväärtuste analüüs
Paljud tarkvarad põhinevad andmete sisestamisel, kusjuures andmetel on konkreetsed piirid, mille piires klient peab töötama.
Näiteks võib süsteem, mis on loodud arvude arvutamiseks 1-100, olla hädas väärtustega 0 või sellest väiksemate või 100-st suuremate väärtuste puhul.
Piirväärtuste analüüs hõlmab nende piiride testimist, sisestades numbreid nende piiride juures ja ümber, mida tarkvara testib, et uurida, kas tarkvarapaketi eeldatava tööpiirkonna servas on vigu. See on kasulik eelkõige arvutustel põhinevates süsteemides ja aitab arendajatel kas piire korrigeerida või leida probleemide põhjuseid.
3. Riigi ülemineku testimine
Paljud programmid varieeruvad erinevate “seisundite” või “režiimide” vahel ja nõuavad üleminekut ühest selle protsessi etapist teise. Kui need üleminekud toimivad korralikult, tähendab see, et sait toimib nii, nagu kasutaja ootab, ja et ei esine ootamatuid viivitusi.
Seisundi ülemineku testimine on testimise vorm, mis uurib kõiki tarkvara seisundite vahelisi üleminekuid, tagades, et need on funktsionaalsed ja andes kindlustunde, et kasutaja liikumine läbi tarkvara toimib ilma ootamatute katkestusteta.
Mustade kastide testimine tarkvaraarenduse elutsüklis
Musta kasti testimine on distsipliin, mida kasutatakse peamiselt tarkvaraarenduse elutsükli lõpus. See hõlmab kõike, alates sellest, kuidas kasutajad tarkvaraga suhtlevad, kuni täieliku beeta-juurdepääsu võimaldamiseni, kusjuures musta kasti testimine toimub peamiselt siis, kui kogu funktsionaalsus töötab ootuspäraselt.
See säästab palju aega ja vaeva võrreldes valge kasti testimisega, mis nõuab kõrgetasemelisi teadmisi, ning seda on kõige parem rakendada siis, kui teil ei ole vaja arendusmeeskonda, et teha süsteemi tööpõhimõtetes koheseid muudatusi.
Käsitsi või automatiseeritud must kast testid?
Tarkvara testimine on kahes erinevas vormis, kusjuures käsitsi testimine on traditsiooniline vorm, mille puhul kasutatakse tarkvara testijaid protsessi igas etapis. See on kindlalt vastuolus automatiseeritud testimisega, mis kasutab üha enam tehisintellekti ja masinõpet, et täita ülesandeid ilma inimese sekkumiseta.
Lugege edasi, et saada rohkem teavet selle kohta, mis on käsitsi ja automatiseeritud testimine, millised on nende mõlema väljakutsed ja kumb neist kahest on ettevõtte jaoks ideaalne.
1. Käsitsi mustade kastide testimine – eelised, väljakutsed, protsess
Manuaalne musta kasti testimine tähendab musta kasti testimise iseseisvat läbiviimist, kasutades töötajaid kõikide ülesannete täitmiseks, mitte automatiseerimisplatvormi kui osa ettevõtte tööriistakomplektist.
Mõned peamised eelised, mida tarkvara arendamisel käsitsi testimise kasutamine annab, on see, et teil on suurem paindlikkus testimise lõpuleviimise viiside osas ning see, et arendajad saavad palju põhjalikumat tagasisidet, mis on oma olemuselt kvalitatiivne.
Siiski on manuaalses testimisprotsessis mõned loomupärased väljakutsed. Esimene neist on asjaolu, et käsitsi testimine võib võtta palju aega, kuna inimesed on oma ülesannete täitmisel aeglasemad kui automatiseeritud programmid.
Teiseks on suurem vigade tegemise võimalus, kuna inimesed võivad teha valesti või teha asju vales järjekorras. See võib lõppkokkuvõttes põhjustada ebatäpsusi testimisandmetes.
Käsitsi testimine on protsess, mis algab ettevõtte ootuste tundmaõppimisega rakenduse suhtes, enne kui kirjutatakse testjuhtumid, mis vaidlustavad selle lühikirjelduse, täidetakse testjuhtumid ja esitatakse tulemused arendusmeeskonnale.
2. Musta kasti testimise automatiseerimine – eelised, väljakutsed, protsess
Automatiseeritud testid viitavad testidele, mida ettevõte teeb tarkvarapaketile, täites testjuhtumeid automatiseeritud süsteemi abil. Need kasutavad kolmanda osapoole platvorme tarkvarapaketi automatiseerimiseks, kusjuures kõik automatiseeritud sammud järgivad spetsiaalselt ettevalmistatud testjuhtumeid.
Musta kasti testide automatiseerimise peamine eelis on selle kiirus, kuna automatiseeritud programmid võtavad palju vähem aega iga testi läbiviimiseks. See tähendab, et testimine võidab oluliselt aega, mida saate kasutada rakenduse arendamiseks.
Teine eelis on täpsus, sest hea automatiseerimisvahend täidab samu ülesandeid iga kord samas järjekorras.
Puudused võivad endiselt põhjustada probleeme musta kasti testide automatiseerimisel, kusjuures üks peamisi probleeme on keskendumine kvantitatiivsetele andmetele. See on hea mõõdikute jaoks, kuid tähendab, et kasutaja vastuvõetavuse testimisel on vähe väärtuslikku teavet.
Samuti on automatiseeritud testimine suhteliselt vähe paindlik, kuna analüütikud peavad iga kord, kui nad soovivad teha muudatusi, kodeerima täiesti uusi testjuhtumeid.
Testide automatiseerimise protsess algab mitme testjuhtumi kavandamisega, mis seejärel kodeeritakse süsteemi enne testide täitmist, mis annavad lõpetamisel aruande.
3. Kokkuvõte: Kas käsitsi või musta kasti testimise automatiseerimine?
Lõppkokkuvõttes on valik käsitsi ja automatiseeritud musta kasti testimise vahel keeruline ja sõltub sellest, mida te süsteemis otsite.
Kui otsite kvaliteetset kvalitatiivset teavet, mida saate kasutada disainimuudatuste tegemiseks lõppkasutajale, on manuaalne testimine kaugelt parem valik, kusjuures automatiseeritud testimine on ideaalne protsessi funktsionaalsete ja jõudlusetappide jaoks.
Mõelge läbi, mida otsite igas testimisprotsessi etapis, ja saate hõlpsasti juhendatud andmeid, mis parandavad teie tulemuslikkust.
Mida on vaja musta kasti testimise alustamiseks?
Enne musta kasti testimise alustamist on vaja mõningaid eeldusi, mis aitavad luua ühtsema testimisprotsessi.
Mõned asjad, mis peaksid olema olemas enne musta kasti testimise alustamist, on järgmised:
1. Tarkvara nõuded
Tarkvaranõuded viitavad konkreetsetele punktidele projekteerimisülesandes, mida tarkvara peab täitma. See võib hõlmata mitmesuguseid asju, alates vajadusest täita teatavaid ülesandeid kuni kindla välimuse ja tunnetamiseni selle kasutamisel.
Selle teabe olemasolu annab teile mõned konkreetsed eesmärgid, mille poole testimisel püüelda, kusjuures testijad koostavad testimise ajakava ja plaani, mille tulemuseks on sidusamad tulemused, mis teavitavad arendajaid tarkvara probleemidest.
Kuna mõnes ettevõttes on tegemist musta kasti testiga, piiravad arendajad testija juurdepääsu briifile.
2. Koostatud tarkvara
Enne tarkvara testimist peab kvaliteedi tagamise meeskond saama juurdepääsu tarkvarale. See hõlmab tavaliselt seda, et arendajad pakuvad tarkvara kõige uuemat versiooni, kusjuures meeskond saab kasu sellest, et tal on täiesti värskelt kompileeritud tarkvara versioon, millega ta saab teste teha.
Värskeim versioon tähendab, et testid sisaldavad kõige uuemaid parandusi, mis tähendab, et see annab täpse ülevaate tarkvara toimimisest.
3. Eesmärkide testimine
Testijatel on kombeks läheneda testimisperioodile, pidades silmas teatud kindlaid eesmärke. Need testimiseesmärgid sätestavad täpselt, mida nad eeloleval perioodil testivad, olgu selleks siis kasutaja vastuvõetavus, läbiv funktsionaalsus või läbitungitesti lõpuleviimine.
Kvaliteedijuhtidel on tavaliselt sellised eesmärgid, kusjuures järgmine testimise etapp sõltub tavaliselt sellest, millega arendusmeeskond on tegelenud ja milliseid tarkvara osi need arendused mõjutavad.
Musta kasti testimise protsess
Musta kasti testimise protsess on suhteliselt täpne ja ettevõtted saavad kasu, kui nad järgivad protsessi samme võimalikult täpselt. Musta kasti testimise protsessi erinevad etapid on järgmised:
1. Testi planeerimine
Alustage musta kasti testimise protsessi keerulise planeerimisprotsessiga. See tähendab, et tuleb arutada kõiki individuaalseid eesmärke, mis teil on testi jaoks, tarkvara konkreetseid aspekte, mida te uurite, ja ressursse, mida te testimiseks kasutate.
Põhjalikum planeerimine tähendab, et kõik teavad, mida ja millal nad peavad tegema, sealhulgas katsetega seotud meetodeid.
2. Testjuhtumite kirjutamine
Testjuhtumite kirjutamine on protsessi järgmine etapp. Testjuhtum viitab testis täidetavate sammude reale, kusjuures üksikasjalikumad testjuhtumid pakuvad kasutajale suuremat järjepidevust.
Automatiseeritud testimise puhul hõlmab see ka testjuhtumi kodeerimist mis tahes automatiseerimisvahendiga, mida kavatsete kasutada.
Kontrollige kõiki oma testjuhtumeid kaks korda, et veenduda, et need on põhjalikud ja et täidetavad sammud on selged.
3. Testjuhtumi täitmine
Kui olete oma testjuhtumid ette valmistanud, alustage nende täitmist. Kui kasutate automatiseerimist, võib see olla suhteliselt lihtne ülesanne, mis hõlmab programmi käivitamist ja tulemuste ootamist. Manuaalne testimine põhineb töötajate korduval testjuhtumite täitmisel, kusjuures rohkem kordusi viib järjepidevamate ja kvaliteetsemate andmete saamiseni.
Sooritage iga testjuhtum võimalikult hoolikalt, sest mida täpsem on testjuhtumite täitmine, seda suurem on tõenäosus, et andmed on arendusmeeskonnale kasulikud.
4. Lõplik aruandlus
Lõplik aruandlusetapp viitab protsessi sellele osale, kus testimismeeskond annab arendajatele aru.
Alustage kogutud teabe lihtsa kokkuvõttega, enne kui lisate sellele kõik testijate kogutud mõõdikud. See annab arendajatele esialgsed juhised järgmise uuenduste rea ideaalseks suunaks, enne kui neile näidatakse täielikke andmeid, mis võimaldab neil probleemidest sügavamalt aru saada.
Parimad praktikad musta kasti testimiseks
Sõltumata teie tööstusharust on parimate tavade järgimine iga ettevõtte jaoks kohustuslik. Parimad tavad viitavad reale käitumisviisidele ja tehnikatele, mida ettevõte saab kasutada oma igapäevatöös, suurendades ettevõtte tõhusust ja parandades ettevõtte kasutatava tarkvara standardit.
Mõned neist tavadest, mis aitavad ettevõttel parandada musta kasti testimise kvaliteeti, hõlmavad järgmist:
1. Keskendumine oskuste arendamisele
Kui teil on ettevõte, mis töötab korraga mitme tarkvara kallal, kaaluge võimalust keskenduda testimisoskuste ja -spetsialiseerumise arendamisele. Mida rohkem aega kulutate spetsialiseerumisele ja asjakohaste oskuste arendamisele, seda paremad on teie võimalused oma toodetes esinevate probleemide väljaselgitamiseks.
See sobib koos õigete oskustega inimeste palkamisega, kuid on kõige sobivam ettevõtetele, kus toimub peaaegu pidev tarkvara testimine, sest nende oskuste rakendamisest on alati kasu.
2. Tasakaalustada töökoormust
Mõned testimismeeskonnad võivad olla väga suured, kus on kümneid või isegi sadu töötajaid, kes kõik täidavad regulaarselt testjuhtumeid.
Parim tava nende töötajate parimaks ärakasutamiseks on võtta aega ja olla ettevaatlik, kui määrate inimestele konkreetseid ülesandeid. Läbipõlemine on tarkvaraarenduse valdkonnas põhjustanud tõsiseid probleeme, kuid seda on võimalik vältida parema töökoormuse juhtimisega.
3. Luua järjepidevad protsessid
Ettevõtted on üles ehitatud protsessidele, mida nende töötajad igapäevaselt täidavad, kusjuures testimisprotsessid hõlmavad viisi, kuidas ettevõte kirjutab oma testjuhtumeid, viib läbi uuringuid ja suhtleb osakondade vahel.
Järjepidevus on neil juhtudel võtmetähtsusega, sest see tähendab, et inimesed õpivad kiiremini, kui nad ettevõttesse tulevad. See toob kaasa kiirema kohanemise ja parema tulemuse palju varem kui ettevõttes, kus kõik ülesanded ei ole järjepidevad.
Kui saate, looge need protsessid nii, et töötajad oleksid kaasatud otsustusprotsessi, sest see tagab, et nad nõustuvad strateegiaga.
7 viga ja lõksu musta kasti testide rakendamisel
Vead on loomulikud igas valdkonnas, kuid vigade tundmine enne, kui teil on võimalus neid teha, võib säästa palju aega ja vaeva.
Mõned kõige levinumad vead ja lõksud, millesse musta kasti testijad satuvad, on järgmised:
1. Määratletud testimise ulatuse puudumine
Mõned organisatsioonid alustavad oma toodete testimist ilma protsesse korralikult planeerimata, mis on oluline viga.
Kui ettevõtted ei suuda planeerida, võivad nad kaotada ülevaate testimise ulatusest. Kokkulepitud ulatuse olemasolu aitab testil olla õiges ulatuses ja saavutada tõhusalt tulemusi.
Kui te ei lepi enne alustamist kokku oma testimise ulatuses, on tõsine oht, et testimine on liiga laiaulatuslik ja võtab liiga palju aega, et saada vähem asjakohaseid tulemusi.
2. Kiirendatud testimisprotsessid
Testimine võib tunduda protsessina, mis võtab väga kaua aega, eriti kui tegemist on pikkade testjuhtumitega, mis on mõeldud kogu rakenduse uurimiseks. Mõnel inimesel võib tekkida kiusatus kiirustada oma testidega, eriti varasemate testide kordamisel. See on tõsine viga. Testi kiirustamine võib põhjustada vigu testjuhtumite täitmisel, mis vähendab andmete väärtust ja tähendab lõpuks, et te peate samu teste ikkagi uuesti tegema.
3. Automatiseerimine ilma kontrollimisprotsessita
Testi automatiseerimine keskendub peamiselt selle tagamisele, et andmete väärtuse sisestamine viib protsessi lõpus õige väljundini. Nende testide automatiseerimine toimib automatiseeritud protsessi väljundite kontrollimise teel võrreldes sellega, millised peaksid olema tulemused.
Mõned testijad teevad olulise vea, kui nad ei arvuta ise väärtust, mis tähendab, et neil puudub võimalus kontrollida, kas väljund on õige või mitte, ja nad ei leia potentsiaalselt olulisi vigu kogu süsteemis.
4. Hübriidkatsete kasutamata jätmine
Hübriidtestimine viitab automatiseerimise ja käsitsi testimise tasakaalustamisele, kuna need kaks meetodit töötavad nii, et nad katavad üksteise puudused suurepäraselt.
Mõned organisatsioonid eelistavad siiski keskenduda ühele neist kahest meetodist. Sellega avate oma testimise tõsistele probleemidele ja ebatäpsustele.
Viige lõpule hübriidtestimine, et saavutada testimisel parem tasakaal ja vähendada vigade arvu võimalikult oluliselt.
5. Regressioonitestimise lõpetamata jätmine
Regressioonitestimine peaks olema pidev protsess igas tõhusas tarkvara testimise süsteemis, kusjuures selle testimisviisiga tehakse kindlaks, kas tarkvara uuendused on põhjustanud probleeme mujal süsteemis. Kui regressioonitestimist ei viida lõpule, tähendab see, et varakult testitud funktsioonid võivad ebaõnnestuda, ilma et te sellest aru saaksite.
Regressioonitestimise läbiviimisega tagate, et saadate kvaliteetsema toote, ilma et peaksite tegema liiga palju lisatööd kvaliteedi tagamise protsessis.
6. Aktiivne vigade jahtimine
Mõned arvavad, et musta kasti testimise eesmärk on leida tarkvarapaketis vead ja teatada neist arendusmeeskonnale, ja kuigi see on üks aspekt, ei ole see ainus fookus. Testimine on olemas selleks, et üldiselt parandada tarkvarapaketi standardit.
Kui keskendute liiga palju tarkvara vigadele, hakkate kalduma väljapoole standardseid töövooge, ületate oma testimise ulatust ja ignoreerite mõningaid asjakohasemaid probleeme tarkvaraga, et selle asemel otsida koodist välja potentsiaalselt ebaolulisi vigu.
7. Oma intuitsiooni eiramine
Käsitsi testimisel on testija roll, sest tal on olemas intuitsioon ja teadmised koodist, mis suunavad teda võimalike probleemide suunas ja annavad talle teavet valdkondade kohta, mida uurida, kui ta töötab.
Mõned otsustavad aga seda intuitsiooni testjuhtumitega töötades täielikult eirata. Märkides üles kõik, mida soovite testida, ja kontrollides seda uues testjuhtumis, saate kogu kasu oma tehnilistest teadmistest, samal ajal kui täidate ettevalmistatud testjuhtumid.
Musta kasti testide väljundite tüübid
Musta kasti testimise tulemusel on võimalik saada mitut liiki tulemusi, millest igaüks annab ettevõttele ainulaadset teavet, et teha oma toodetesse asjakohaseid uuendusi ja parandada klientide kogetud kvaliteeti.
Mõned peamised musta kasti testide väljundid on järgmised:
1. Kvalitatiivsed andmed
Esimene väljund, mida saate musta kasti testist saada, on kvalitatiivsed andmed. See on teave, mis kirjeldab peamiselt rakendust ja tuleneb sellistest testidest nagu otsestest testimine ja kasutatavuse testid.
Kvalitatiivsed andmed kirjeldavad tavaliselt rakenduse standardit, rääkides inimeste kogemustest rakendusega ja selgitades muudatusi, mida testija sooviks teha.
Nende andmete loomisel kirjutab testija tavaliselt põhjaliku aruande, milles esitab kõik tõendid oma punktide kohta, toetades kvalitatiivseid arvamusi lisafunktsioonidega, näiteks ekraanipiltidega, millele nad viitavad.
2. Kvantitatiivsed andmed
See viitab selgetele numbrilistele andmetele mõõdikute kujul, kusjuures testimise töötajad kas märgivad üles rakenduse konkreetseid osi või saavad numbrilisi andmeid automatiseeritud testimisprotokollist.
Kvantitatiivne teave on pigem kasulik, et pakkuda arendajatele selgeid parandusi, näidates selliseid rakenduse osi nagu selle jõudluse tase, selle tõhusus kasutatud ressursside osas ning rakenduses esinevate vigade ja probleemide arv.
Kvantitatiivset teavet on lihtsam analüüsida ja hinnata kui selle kirjeldavat vastet, kuna puudub vajadus tõlgendamiseks.
3. Veateated
Veateated ilmnevad siis, kui tarkvara funktsionaalsus ei toimi ootuspäraselt. See võib olla tingitud riist- või tarkvaraprobleemidest, tavaliselt koos lühikirjeldusega, milles probleem seisneb, ning lisaks veakoodile.
Arendajad loovad veakoodide süsteemi, mis aitab neil täpselt kindlaks teha, kus süsteemis probleem esineb, kusjuures mõned ideed, mida rakendada, hõlmavad esimese numbri kasutamist, et kitsendada funktsiooni, mille puhul probleem esineb, teise numbri kasutamist, et kirjeldada, mis konkreetselt ei õnnestunud, ja kolmanda numbri kasutamist, et märkida probleemi põhjus.
Selle veakoodide süsteemi kasutamine tähendab, et arendajad teavad kohe, milles probleem seisneb, ja saavad töötada selle lahendamise kallal.
Näiteid musta kasti testidest
Kuigi teooria musta kasti testimise taga on suhteliselt lihtne, võib selle praktiline rakendamine olla keeruline protsess, eriti esmakordse testija jaoks. Musta kasti testimise näide praktikas võib aidata teid testimise korraldamisel suunata.
Mõned näited musta kasti testimise meetoditest, sealhulgas mitut tüüpi testimine ja erineva edukuse tase, on järgmised:
1. Tõhus kasutajakõlblikkuse testimine
Ettevõte soovib oma toote lähinädalatel välja anda, kuid kasutajate heakskiitmise testimine peab veel toimuma. Rakendus on kudumise õpetus eakale publikule.
Arendajad püüavad seda protsessi kiirendada ja koguda kiiresti testijate rühma, kasutades testimiseks eranditult kolmekümnendate keskpaigast pärit mittekudujaid, kuna nad olid kättesaadavam rühm. See rühm ei näe taotluses mingeid probleeme ja annab rohelise tule avaldamiseks.
Kahe rühma tehniliste teadmiste vastuolulise taseme tõttu on sihtrühm tarkvara kasutamisel rohkem segaduses ja ei saa juurdepääsu paljudele funktsioonidele. Vastuseks on ettevõte sunnitud tegema kiireloomulisi uuendusi.
Sellised katsete ebaõnnestumised näitavad, kui oluline on põhjalik ettevalmistus.
2. Edukas läbiv testimine
Lõppkokkuvõtte testimine tähendab testimist, mis toimub pärast seda, kui rakenduse funktsionaalsus on esimest korda täielikult ühte tarkvarapaketti kompileeritud.
Ettevõte on hoolikalt planeerinud läbiva testimisprotsessi lõpuleviimise, palgates terve rea töötajaid spetsiaalselt testimisülesannete täitmiseks, kusjuures igale testimisjuhtumile on pühendatud kaks töötajat.
Pärast hoolikat protsessi täidavad nad oma testjuhtumid ja märgivad üles kõik kogutud andmed, kusjuures QA juht koostab testimise lõpus andmed ühtseks aruandeks.
Arendajad kasutavad seda aruannet järgmiste uuenduste ja muudatuste kavandamiseks rakenduses, parandades toodet märkimisväärselt.
3. Automatiseeritud regressioonitestimine
Üks arendaja on lõpetanud oma tarkvara uuenduste seeria, mis enne uuendusi töötas ootuspäraselt. Pärast uuendusi läbib testimismeeskond regressioonitestimise protsessi, keskendudes automatiseerimisele ja saades automatiseeritud platvormi, et täita kogu põhifunktsionaalsus.
Meeskond kirjutab testjuhtumi koodi ja täidab testjuhtumid, lugedes läbi kõik testide tulemused ja leides, kus on võimalikud probleemid.
See takistab probleemide tekkimist, kuna organisatsioon teeb uuendusi ja ei kontrolli, kas need on probleemiga seotud või mitte.
Musta kasti testimise käigus avastatud vigade ja vigade tüübid
Kuigi vead ja vead ei ole mustas kastis testimise protsessis kõik, on need siiski oluline osa sellest, kuidas ettevõtted testimisega tegelevad.
Mõne peamise vea ja vigade tüübi tundmine musta kasti testimisel aitab teil kategoriseerida kõik probleemid, millega te kokku puutute, ja mõista paremini, miks need esinevad.
Mõned peamised veatüübid ja vead, mida on võimalik tuvastada musta kasti testimise abil, on järgmised:
1. Kasutatavuse vead
Kasutatavusvead viitavad programmi puudustele, mis ei mõjuta tegelikult funktsionaalsust, kuid võivad tekitada probleeme kasutajale, kes üritab tarkvaraga suhelda.
Näiteks kui rakendusel on tõsine graafikahäire, on see tehniliselt endiselt toimiv, kuid ilma õigete ikoonide ja tekstita ei saa lõppkasutaja seda tõhusalt kasutada. Need probleemid ümbritsevad tavaliselt rakenduse disaini ja seda, kuidas disain kasutaja jaoks laetakse, kusjuures keerulisemad rakendused nõuavad rohkem graafikat, mis on keerulisem kui lihtsamate kasutajaliideste puhul.
2. Funktsionaalsed vead
Funktsionaalsed vead viitavad probleemidele, mis tekivad siis, kui mõni programmi osa ei tööta ootuspäraselt.
Näiteks kui te kasutate andmebaasi tarkvara ja püüate sorteerida teavet teatud kategooria järgi, kuid avastate, et see ei toimi. See kehtib nii nende funktsioonide kohta, mis ei tööta üldse, kui ka nende kohta, mis näivad toimivat, kuid teevad seda valesti.
Need võivad olla rakenduse jaoks ühed kõige olulisemad probleemid, mis põhjustavad kasutajatele märkimisväärseid ebamugavusi ja halvendavad arendaja mainet, kuna toode ei tööta nii, nagu on reklaamitud.
3. Õnnetused
Kui tarkvara jookseb kokku, siis on tarkvaras põhimõtteline probleem, mis takistab selle töötamist. Krahhi võib esineda mitmes erinevas vormis, sealhulgas siis, kui rakendus sulgub täielikult või lihtsalt külmutab ühes punktis.
Kukkumine on üks kõige tõsisematest probleemidest, mis võib tekkida, kuna rakenduse funktsionaalsuse taastamiseks ei ole muud võimalust kui selle täielik sulgemine ja uuesti avamine. Kuigi mõnes rakenduses toimuvad taustal endiselt protsessid, ei ole võimalik tarkvaraga pärast seda enam suhelda.
Ühised musta kasti testimise mõõdikud
Manuaalne mustade kastide testimine sobib suurepäraselt kvalitatiivsete andmete genereerimiseks, kuid kui keskendute kvantitatiivsetele andmetele, peate olema teadlik kontrollitavatest meetrikatestidest. Nende mõõdikute täielik mõistmine aitab teil mõista platvormi puudusi ja seada prioriteediks erinevad valdkonnad, mille kallal tööd teha.
Mõned levinumad musta kasti testimise mõõdikud, mida oma töös leiad, on järgmised:
1. Veamäär
Veamäär võib viidata mitmele asjale, kas tarkvara testimise käigus tekkivate vigade arvule või vigade arvule testimise tunni kohta. Tunnipõhised näitajad on paremad, sest need näitavad tarkvara vigade tihedust, mitte lihtsalt numbri esitamist, kusjuures suuremad rakendused võivad olla valesti esitatud.
Arendajad püüavad piirata veamäära oma rakendustes, sest mida vähem vigu on tarkvarapaketis, seda parem on kliendi kogemus süsteemi kasutamisel.
2. Reageerimisaeg
Kui testija soovib rohkem teada saada, milline on kasutajale pakutav jõudluse tase, on vastamisaeg üks peamisi aspekte, mida tuleb arvesse võtta. See viitab ajale, mis kulub tarkvaral ülesande täitmiseks pärast seda, kui kasutaja on sisestanud ülesande, kusjuures pikem reageerimisaeg näitab, et rakendus on suhteliselt ebatõhus. Suuremad vastamisajad on murettekitav, sest kasutajad võivad kaotada kannatuse liiga kaua kestva rakenduse suhtes.
3. Kasutaja rahulolu
Enamik mõõdikuid keskendub puhastele numbritele, mida tarkvarapakett ja testimistarkvara testis genereerib, kuid mõned mõõdikud keskenduvad arvamusele.
Kui ettevõte viib läbi beetatestimise, mille käigus kasutatakse näiteks 1000 testijat, saab ta koguda andmeid rahulolevate inimeste arvu kohta ja muuta selle protsentuaalseks. See on äärmiselt kasulik mõõdik, mis on kättesaadav tsükli lõpus, sest suurem kasutajate rahulolu näitab, et programm meeldib rohkematele inimestele ja näitab, et programmil on suurem tõenäosus tulevikus hästi toimida.
Parimad musta kasti testimise tööriistad
Mustas kastis testimine on testimise vorm, mis võib oluliselt sõltuda sellest, kas teil on käepärast vahendid nii mustas kastis testimise automatiseerimiseks kui ka testidest saadud teabe korraldamiseks.
Õige tööriistakombinatsiooni kasutamine aitab teil ja teie meeskonnal töötada palju tõhusamalt ja luua tõhusamaid protsesse kogu kvaliteedi tagamise osakonnas.
Vaadake allpool mõningaid parimaid musta kasti testimisvahendeid ja õppige, kuidas täpselt iga neist aitab teil edu saavutada:
5 parimat tasuta musta kasti testimise tööriista
Väikestel ja arenevatel ettevõtetel, näiteks sõltumatutel arendajatel, ei ole oma tarkvara loomisel suurt eelarvet. See võib tuua kaasa mitmeid probleeme, sealhulgas õigete töövahendite leidmise.
Järgnevalt on esitatud mõned parimad tasuta tööriistad, mis on kättesaadavad sõltumatutele arendajatele, kes soovivad oma töövooge eelarvega parandada:
1. ZAPTEST TASUTA VÄLJAANNE
ZAPTESTi tasuta versioon on ideaalne sissejuhatus tarkvara testimise automatiseerimisse. See tööriist on spetsiaalselt loodud toetama mis tahes ülesande automatiseerimist, aidates teil töötada kiiremini ja tõhusamalt, olenemata sellest, millist ülesannet te täidate.
ZAPTESTi tasuta versioon sisaldab tohutult palju funktsionaalsust, et toetada mis tahes rakenduse automatiseerimist… 1SCRIPT rakendamine cross browser, cross device, cross application ja paralleelne täitmine on üks olemasolevatest funktsioonidest.
2. JIRA
JIRA tasuta versioonid on ideaalsed vahendid vigade märkimiseks, nende detailide lisamiseks piletites ja nende tähtsuse järjekorda seadmiseks arendusmeeskonnaga suhtlemisel.
See on aga pigem spetsialiseerunud ainult testimisprotsessi projektijuhtimise poolele kui kõik-ühes-automatiseerimise abivahendile.
3. Selenium IDE
See on avatud lähtekoodiga rakendus, mis salvestab ja mängib tagasi testide automatiseerimist, ning on hea vahend, et näha, mida automatiseerimisplatvorm näeb testi lõpetamisel.
Seleniumi üks puudus on täiustatud funktsioonide, näiteks automatiseeritud ülesannete platvormideülese integreerimise suhteline puudumine.
4. AutoHotkey
AutoHotkey on täiesti tasuta ja avatud lähtekoodiga skriptikeel, mis on saadaval Windowsile ja mis aitab kasutajatel luua erineva suurusega skripte, mis täidavad pärast ühe klahvivajutuse sisestamist terve rea ülesandeid.
Kuigi AutoHotkey on hea lihtsate ülesannete automatiseerimiseks, võib see hakata vaeva nägema suuremate skriptide ja automatiseerimisnõuete puhul.
5. Appium
See tööriist, mis on eelkõige suurepärane iOS-rakenduste automatiseerimisel, on ideaalne programm, mida kasutada, kui soovite parandada oma mobiilirakenduste kvaliteeti.
Appiumi suurimaks puuduseks on asjaolu, et te olete piiratud väga väikese tootevalikuga, mis kärbib teie kättesaadavat turgu märkimisväärselt.
5 parimat ettevõtte musta kasti testimise tööriista
Tasuta tööriistad on kõik ilusad ja head, kuid ettevõtted ja suured ettevõtted vajavad oma tarkvara põhjalikuks testimiseks rohkem funktsioone. Õnneks on mõned parimad ettevõtte musta kasti testimise tööriistad laiaulatusliku funktsionaalsusega ja aitavad ettevõtetel saada märkimisväärset tulu oma QA-protsessidesse tehtud investeeringutest.
Mõned ideaalsed ettevõtte musta kasti testimise vahendid, millesse investeerimist võiks kaaluda, on järgmised:
1. ZAPTEST ENTERPRISE EDITION
ZAPTESTi Enterprise-versioon on üks olulisemaid automatiseerimisvahendeid turul ja võib anda teie tootele kuni 10-kordse investeeringutasuvuse.
Sellised funktsioonid nagu juurdepääs täistööajaga ZAPi eksperdile, kes on teie meeskonna eemal asuv osa, ja piiramatu arv litsentse tagavad, et saate rakendada musta kasti testide automatiseerimist ilma järsu õppimise vajaduseta ja fikseeritud hinnaga, olenemata sellest, kui kiiresti te kasvate.
2. TestRail
TestRail on platvorm, mis keskendub reaalajas testimisele ja mille eesmärk on ühendada teie testid ühtse projektijuhtimise platvormiga. Kuigi see on ideaalne meeskonnajuhtimise töö tsentraliseerimiseks, ei ole automatiseerimisfunktsioonid kaugeltki ideaalsed arendusmeeskonnale, kes soovib suurt rõhku panna automatiseeritud testidele.
3. Opkey
Opkey on platvorm, mis keskendub koodita automatiseerimisele, mis tähendab, et inimesed, kellel puuduvad tehnilised teadmised, saavad hakata automatiseerima oma testimisteenuseid.
Üks Opkey peamisi puudusi on tarkvara ümbritseva aktiivse kogukonna puudumine, mis võib jätta teid suhteliselt hätta, kui üritate automatiseerida teile uutmoodi.
4. Perfecto
Perfecto on tööriist, mis keskendub sellele, et aidata kasutajatel automatiseerida mobiilirakendusi ilma tõsiste probleemideta, töötades paljudes seadmetes ja keskendudes otsast lõpuni testimisele.
Rakendus töötab aga pigem reaalsetel seadmetel kui virtuaalmasinatel, mis lisab piiratud platvormide puhul veel ühe suure kulu niigi suhteliselt kallile testimisvahendile.
5. JIRA Enterprise
Lisaks testimise automatiseerimise lõpuleviimisele on oluline ka projektijuhtimine, mille puhul tuleb mängu JIRA. Enterprise JIRA-l on rohkem salvestusruumi ja see võimaldab rohkematel kasutajatel platvormile ligi pääseda, kuid see võib tekitada segadust, kuna iga kasutaja jaoks on vaja individuaalseid õigusi ja juurdepääsu. See võtab palju aega haldustöödeks.
Millal peaksite kasutama
Enterprise vs. Freemium Black Box tööriistad?
Alustuseks kasutab enamik ettevõtteid freemium black box’i vahendeid. See on majanduslikust seisukohast mõistlik, sest ükski arukas ettevõte ei taha investeerida tootesse, mida ta ei mõista täielikult, olgu see siis projektijuhtimise või automatiseerimise seisukohast.
Freemium-vahendid ei hõlma ainult täiesti tasuta rakendusi, vaid võivad hõlmata ka ettevõtte toodete tasuta versioone, mida ettevõte kasutab, kui ta õpib, kuidas tööriista oma protsessidesse rakendada.
Ideaalne aeg organisatsiooni jaoks, et uuendada oma valitud tööriist ettevõtte versioonile, on siis, kui ettevõte hakkab kogema hõõrdumist oma testimisprotsessides tasuta tööriista tõttu. Olenemata sellest, kas tegemist on tasuta tööriistaga, mis pakub ainult valitud arvu litsentse või testimismahtu, peaksite kohe, kui hakkate kogema oma protsesside ebaefektiivsust testimisvahendite tõttu, üle minema ettevõtte versioonile, mis vastab kõigile teie vajadustele.
Musta kasti testimise kontrollnimekiri, näpunäited ja nipid
Kuna musta kasti testimine on väga keeruline testimismeetod, mis pakub palju võimalusi tarkvarapaketi tundmaõppimiseks, on mõned asjad, mida peate silmas pidama.
Mõned olulised näpunäited ja nipid, mida tuleks lisada oma musta kasti testimise kontrollnimekirja, on järgmised:
– Briefi mõistmine
Enne testimise plaanide koostamist veenduge, et te mõistate testimisperioodi laiemat lähteülesannet. See hõlmab tarkvara mõistmist nii kaugele, kui teil on lubatud, ja selle õppimist, mida te täpselt testida kavatsete.
– Testjuhtumi korrektuur
Püüdke kõiki testimisse kaasatud isikuid kaasata, et hinnata testjuhtumeid, mida kasutate musta kasti testimisel. Mida rohkem silmi näeb testjuhtumit enne rakendamist, seda paremad on võimalused vigade kõrvaldamiseks.
– Korraldage nimekiri asjadest, mida tuleb teha
Musta kasti testimise ettevalmistamise mittetehniline pool võib olla sama oluline kui tehniline pool. Planeerimisel koostage sidus nimekiri asjadest, mida tuleb teha, mis korraldab, kes millisel konkreetsel ajal millist tarkvara osa testib. See vähendab nii segadust, võimalikku läbipõlemist kui ka muude ülesannete ülevõtmisest tingitud viivitusi.
– Registreerige tulemused kohe
Kirjutage kohe üles kõik testiga saadud tulemused. Kui ootate liiga kaua käsitsi tehtavate testidega, võite probleeme valesti meeles pidada, seega kiirmärkuste tegemine suurendab oluliselt täpsust.
– Koostöö arendajatega
Arutage oma testimise ajakava ja strateegiat arendajatega, et nad mõistaksid, mis toimub ja millal nad võivad oodata tööd uute uuendustega. See hõlmab selgete protsesside kehtestamist, mille abil osakonnad omavahel suhtlevad.
– Tegevuskõlblikud andmed
Aruande koostamisel veenduge, et kõik andmed, mida arendajale esitate, on rakendatavad. See aitab meeskonnal arendada toodet, mis vastab tema probleemidele, mitte arendajale, kes ei saa aru, milliseid muudatusi on vaja teha.
– Mõista oma prioriteete
Testimismeeskonnana on teie prioriteet lõpuks tagada, et ettevõte saadab kasutajatele kvaliteetse toote. Kui testimine võtab oodatust pisut kauem aega, siis pidage meeles, et see on väärt vahetus kvaliteedi tõusu eest, mida klient kogeb.
– Tunne hierarhiat
Ideaalses arendusettevõttes on arendajad ja testijad samal hierarhiatasandil ja neil on võrdselt oluline sõnaõigus selles, kuidas tarkvara areneb. Mõistke, milline on teie organisatsiooni hierarhia, ja püüdke tagada, et kõik mõistaksid hea testimise väärtust.
– Säilitage järjepidev dokumentatsioon
Hoidke koopiaid kõigist testimise käigus saadud andmetest ja aruannetest. Saate jälgida rakenduse muudatusi, mille eest testimismeeskond vastutab, lisaks sellele, et vaadata tagasi vanu vigu, et näha, kas need korduvad tulevastes väljaannetes.
Kokkuvõte
Musta kasti testimine on lõppkokkuvõttes tarkvara testimise protsessi üks olulisemaid osi. See aitab ettevõtetel veenduda, et see, mida nad tarnivad, on võimalikult heal tasemel, ning kasutab perspektiivi muutust, et pakkuda ainulaadset teavet selle kohta, kuidas väliskasutajad rakendust tajuvad ja rakendavad.
Iga ettevõte, kes ei lisa oma protsessidesse nii automaatset kui ka käsitsi tehtavat musta kasti testimist, jätab kasutamata võimaluse oma rakenduse kvaliteeti oluliselt parandada. Testige arukalt ja te saate kasu, kui teie kliendid saavad juurdepääsu teie tootele.
KKK ja ressursid
Sõltumata sellest, kui palju te teate musta kasti testimisest, võib teil olla veel küsimusi ja te soovite meetodist rohkem teada saada. Lugege allpool esitatud korduma kippuvaid küsimusi, et saada lisateavet musta kasti testimise kohta ja pääseda juurde ressurssidele, mis annavad teile rohkem teavet metoodika kohta.
1. Parimad kursused musta kasti testimise automatiseerimise kohta
On mitmeid kursusi musta kasti testide automatiseerimise kohta, mida saab jälgida, millest igaüks aitab inimestel saavutada erineva testimisstandardi.
Mõned kõige enam hinnatud mustade kastide testimise kursused on järgmised:
– “Black-box ja White-box testimine”, Coursera
– “Mustade kastide tarkvara testimise sari”, BBST
– “Sissejuhatus musta kasti tarkvara testimise tehnikatesse” Udemy poolt
– “Tarkvara automatiseerimise testimine”, London School of Emerging Technology
– “Kolm peamist musta kasti testimise tehnikat” by Udemy
2. Millised on 5 kõige olulisemat intervjuuküsimust musta kasti testimise kohta?
Tarkvara testimine on väga konkurentsivõimeline valdkond, kus igale vabale töökohale kandideerib palju kandidaate. Kui te saate intervjuu musta kasti testimisega seotud ametikohale, on need mõned küsimused, millele te võiksite valmistuda vastamiseks intervjuul:
– Millised on teie kogemused musta kasti testimisega?
– Millised on peamised erinevused musta kasti ja valge kasti testimise vahel?
– Kas teil on varasemates rollides olnud kogemusi tarkvara automatiseerimisega töötamisel?
– Kas te võiksite meile öelda, millal teil oli töökohal probleeme ja kuidas te neist üle saite?
– Milline on teie arvates musta kasti testimise tulevik ja kuidas sobivad teie oskused pikaajalise karjääri tegemiseks tarkvara testimisel?
3. Parimad Youtube’i õpetused musta kasti testimise kohta
YouTube on üks olulisemaid õppimisvahendeid, mis on kättesaadav inimestele, kes arendavad oma tarkvara testimise oskusi, sest see on tasuta teabeallikas, mida saate kasutada oma tehnika arendamiseks.
Mõned parimad õpetused, mida vaadata, kui õpid musta kasti testimist, on järgmised:
– “Musta ja valge kasti testimise sissejuhatus – Georgia Tech – Tarkvaraarendusprotsess” by Udacity
– “Black Box ja Glass Box Testing”, MIT OpenCourseWare
– “7 musta kasti testimise tehnikat, mida iga QA peaks teadma” (The Testing Academy)
– “Mustas kastis testimine | Mis on mustas kastis testimine | Õpi mustas kastis testimist”, mille on koostanud Intellipaat
– “Mis on valge vs. hall vs. must kast testimine?” by ITProTV
4. Kuidas hooldada musta kasti teste?
Mustade kastide testide haldamine, olgu need siis käsitsi või automatiseeritud testid, tähendab, et testidele tuleb tähelepanu pöörata, kui need jätkuvad, ja pidevalt otsida parandusi, kui esineb probleeme.
See tähendab, et tuleb veenduda, et kõik testjuhtumid toimiksid iga kord nii, nagu te ootate, ja kontrollida, et automatiseeritud tööriistad läbivad kõik õiged sammud. Tehke seda võimalikult sageli, et vältida oma standardite langemist, sest hästi hooldatud musta kasti test annab võimalikult täpseid tulemusi.
5. Parimad raamatud musta kasti testimise kohta
Kuigi mustade kastide testimine ja tarkvara testimine tervikuna on pidevalt arenev valdkond, on mitmeid raamatuid, mis on endiselt asjakohased ja pakuvad palju teadmisi testimistöö parandamiseks.
Mõned parimad raamatud musta kasti testimise kohta on järgmised:
– “Musta kasti testimine: Boris Beizer: “Techniques for Functional Testing of Software and Systems”.
– “Tarkvara testimine: Srinivasan Desikan, Gopalaswamy Ramesh.
– “Tarkvara testimise põhitõed” (Ralf Bierig, Stephen Brown, Edgar Galván)
– “Sissejuhatus tarkvara testimisse” (Paul Ammann, Jeff Offutt)
