White box on ohjelmistotestauksen luokka, joka viittaa testausmenetelmiin, joilla testataan, miten ohjelmiston sisƤinen rakenne ja suunnittelu toimivat. Se eroaa mustan laatikon testauksesta, joka on testausta, jossa ei kƤsitellƤ ohjelmiston sisƤisiƤ toimintoja vaan testataan vain ohjelmiston ulkoisia tuotoksia.
TƤssƤ artikkelissa tarkastelemme valkoisen laatikon testausta: mitƤ se on, miten se toimii ja millaiset ohjelmistotestaustyƶkalut voivat auttaa testaajia ja kehittƤjiƤ suorittamaan valkoisen laatikon testausta ohjelmistotestauksessa.
MitƤ on white box -testaus?
White box -testaus on ohjelmistotestausmenetelmƤ, jossa testataan ohjelmiston sisƤistƤ rakennetta ja suunnittelua, kun taas black box -testauksessa testataan ulkoisia tuotoksia tai loppukƤyttƤjƤkokemusta.
White box -testaus on sateenvarjotermi, joka sisƤltƤƤ monia erilaisia ohjelmistotestauksen tyyppejƤ, kuten yksikkƶtestaus ja integrointitestaus. Koska white box -testaus sisƤltƤƤ koodin ja ohjelmoinnin testausta, white box -testaus edellyttƤƤ yleensƤ jonkin verran tietokoneohjelmoinnin ymmƤrtƤmistƤ.
Ohjelmistotekniikan white box -testaukseen voi sisƤltyƤ ohjelmiston koodin ja sisƤisen suunnittelun testaamista, jotta voidaan varmistaa tulo- ja lƤhtƶvirta sekƤ tarkistaa ohjelmiston suunnittelu, kƤytettƤvyys ja tietoturva.
Valkoisen laatikon testauksen avulla testaajat voivat tarkastaa jƤrjestelmƤn sisƤisen toiminnan samalla, kun he varmistavat, ettƤ syƶtteet johtavat tiettyihin, odotettuihin tuotoksiin.
White box -testaus on olennainen vaihe ohjelmistotestauksessa, koska se on ainoa testaustyyppi, jossa tarkastellaan, miten itse koodi toimii.
1. Milloin ja miksi tarvitset valkoista laatikkoa
testausta ohjelmistojen testauksessa ja suunnittelussa?
Valkoisen laatikon testaus voidaan suorittaa testaussyklin eri vaiheissa sisƤisen koodin ja rakenteen toiminnan tarkistamiseksi.
Yleisimmin white box -testausta tehdƤƤn, kun kehittƤjƤt ja testaajat suorittavat yksikkƶtestausta ja joskus integrointitestauksen aikana.
MƤƤritelmƤn mukaan yksikkƶtestausta pidetƤƤn erƤƤnlaisena valkoisen laatikon testauksena, kun taas integrointitestauksessa voi olla sekƤ valkoisen ettƤ mustan laatikon testauksen piirteitƤ, mutta sitƤ pidetƤƤn yleensƤ mustan laatikon testauksena.
Muutoin white box -testausta voidaan kƤyttƤƤ myƶs tapauskohtaisesti ohjelmiston sisƤisten toimintojen tarkistamiseen. White box -testaus on taloudellisin tapa lisƤtƤ testien kattavuutta, jos siihen on tarvetta, ja se on myƶs helppo tapa tarkistaa, miten tietyt koodin osat toimivat, tai testata ohjelmiston osia, joiden testaajat epƤilevƤt olevan liian vƤhƤn testattuja.
Muodollisia koodin tarkistuksia, jotka suoritetaan white box -testauksen yhteydessƤ, voidaan myƶs kƤyttƤƤ tietoturva-aukkojen ja muiden haavoittuvuuksien tunnistamiseen. Samoin jos koodin osat ovat rikki, white box -testaus voi auttaa ohjelmistosuunnittelijoita mƤƤrittƤmƤƤn, missƤ virhe on.
2. Kun sinun ei tarvitse tehdƤ white box -testausta.
Useimmissa tapauksissa, kun ohjelmistosuunnittelijat ja testaajat testaavat uutta ohjelmistoa, tarvitaan jonkin verran white box -testausta koodin sisƤisten toimintojen tarkistamiseksi.
Yksikkƶtestaus on erƤƤnlaista white box -testausta, jonka kehittƤjƤt suorittavat varmistaakseen, ettƤ yksittƤiset yksikƶt toimivat odotetulla tavalla. TƤmƤn varhaisen testauksen avulla kehittƤjƤt voivat tunnistaa virheet ja puutteet ennen virallista testausta laadunvarmistusympƤristƶssƤ.
Yksikkƶtestauksen jƤlkeen suoritetaan integrointitestaus, jƤrjestelmƤtestausta ja kƤyttƤjƤn hyvƤksymistestaus. NƤitƤ pidetƤƤn yleensƤ mustan laatikon testauksen muotoina, joihin ei yleensƤ liity paljon valkoisen laatikon testaustekniikoita.
Joissakin tapauksissa testaajat ja kehittƤjƤt voivat kuitenkin kƤyttƤƤ white box -testausta nƤissƤ vaiheissa tunnistamaan tiettyjƤ virheitƤ koodissa. Jos tƤssƤ vaiheessa ei ole mitƤƤn merkkejƤ siitƤ, ettƤ koodissa olisi jotain vikaa, ja kaikki mustan laatikon testit lƤpƤisevƤt testit, monet testausryhmƤt saattavat katsoa, ettei valkoisen laatikon testausta tarvitse jatkaa.
3. Kuka osallistuu white box -testaukseen?
White box -testauksen suorittavat lƤhes aina ohjelmistokehittƤjƤt ja -insinƶƶrit. TƤmƤ johtuu siitƤ, ettƤ white box -testaus edellyttƤƤ yksityiskohtaista tietƤmystƤ tietokonekoodista ja koodaustekniikoista, ja useimmilla QA-testaajilla ei ole white box -testauksen suorittamiseen tarvittavia teknisiƤ taitoja.
Yksikkƶtestauksen, joka on ensisijainen valkoisen laatikon testauksen tyyppi, suorittavat aina kehittƤjƤt kehitysympƤristƶssƤ. KehittƤjƤt saattavat myƶs tehdƤ white box -testausta tarpeen mukaan, jotta voidaan tarkistaa, miten koodin eri osat toimivat, tai tarkistaa, ettƤ virheet on korjattu oikein.
Valkoisen laatikon testauksen edut
Valkoisen laatikon testauksen avulla kehittƤjƤt ja ohjelmistosuunnittelijat voivat testata enemmƤn koodin osa-alueita kuin mustan laatikon testauksen avulla.
Mustan laatikon testauksen avulla voidaan selvittƤƤ, miten ohjelmisto toimii loppukƤyttƤjien kannalta, kun taas valkoisen laatikon testauksen avulla voidaan kertoa enemmƤn siitƤ, miten ohjelmistokoodi toimii. Puhdas ja tehokas koodi on olennaista ohjelmistokehityksessƤ, etenkin jos kehittƤjƤt haluavat kƤyttƤƤ koodia myƶhemmin uudelleen tai lisƤtƤ korjauksia ja pƤivityksiƤ tulevaisuudessa.
1. Maksimoi testien kattavuus
White box -testaus voi auttaa testaajia maksimoimaan testien kattavuuden. Kun testataan mahdollisimman suuri osa ohjelmistokoodista, on yleensƤ todennƤkƶisempƤƤ, ettƤ koodissa olevat viat tai virheet havaitaan, ja valkoisen laatikon testauksen tarkoituksena on yleensƤ testata mahdollisimman suuri osa koodista.
Mustan laatikon testauksessa taas on kyse yksinkertaisesti testitapausten suorittamisesta, jotka voivat tarjota tai olla tarjoamatta laajaa koodin kattavuutta.
2. Etsi piilotettuja virheitƤ ja vikoja
Yksi valkoisen laatikon testauksen suurimmista eduista on se, ettƤ koska valkoisen laatikon testauksella todennetaan sisƤinen toiminnallisuus, kehittƤjien on helpompi lƶytƤƤ virheet ja viat, jotka muuten saattaisivat olla piilossa syvƤllƤ koodissa.
Vikojen tunnistamisen lisƤksi on yleensƤ helpompi paikantaa tarkalleen, missƤ kohtaa koodipohjaa vika on, kun suoritetaan white box -testausta, koska tƤmƤntyyppinen testausmenetelmƤ on luonteeltaan hyvin spesifinen.
3. Automaation helppous
Valkoisen laatikon testausta on erittƤin helppo automatisoida, erityisesti yksikkƶtestausta tehtƤessƤ. Yksikkƶtestit edellyttƤvƤt yleensƤ, ettƤ kehittƤjƤt testaavat pieniƤ koodin osia yksitellen nƤhdƤkseen, toimiiko se odotetulla tavalla. TƤmƤ on erittƤin helppo automatisoida, mikƤ tarkoittaa, ettƤ se on nopea ja tehokas ohjelmistotestauksen muoto.
TƤmƤ on yksi syy siihen, miksi yksikkƶtestaus suoritetaan ennen muita, aikaa vievƤmpiƤ testaustyyppejƤ.
4. Aikatehokas
White box -testaus on ajallisesti tehokasta monestakin syystƤ.
Kuten edellƤ mainittiin, useimmat white box -testaustyypit on suhteellisen helppo automatisoida, mikƤ tarkoittaa, ettƤ white box -testaus on usein nopeampaa kuin black box -testaus. TƤmƤn lisƤksi white box -testauksen avulla kehittƤjien on helppo lƶytƤƤ koodissa havaitut viat ja virheet, koska he lƶytƤvƤt ne itse koodia testatessaan.
5. Koodin laatu
White box -testauksen avulla kehittƤjƤt voivat tarkastella kirjoittamaansa koodia uudelleen ja arvioida sen laatua ja puhtautta.
Koodin lƤpikƤyminen pala palalta antaa kehittƤjille mahdollisuuden poistaa tarpeettomia koodin osia ja siistiƤ koodia, mikƤ helpottaa koodin uudelleenkƤyttƶƤ ja muokkaamista tulevaisuudessa.
Se voi myƶs pakottaa kehittƤjƤt miettimƤƤn, miten koodi toteutetaan ja skaalautuuko se hyvin tulevaisuudessa.
Valkoisen laatikon testauksen haasteet
Valkoisen laatikon testauksessa on omat haasteensa. On muutamia syitƤ, miksi jotkut kehitystiimit saattavat pitƤƤ white box -testausta vaikeampana toteuttaa kuin black box -testausta, sekƤ muita syitƤ, miksi jotkut saattavat pitƤƤ sitƤ vƤhemmƤn tƤrkeƤnƤ kuin black box -testausta.
1. Tekniset esteet
Valkoisen laatikon testaukseen liittyy teknisiƤ esteitƤ, joita mustan laatikon testauksessa ei ole. Valkoisen laatikon testausta varten testaajat tarvitsevat tietoa jƤrjestelmƤn sisƤisestƤ toiminnasta, mikƤ ohjelmistotestauksessa tarkoittaa yleensƤ ohjelmointitietƤmystƤ.
TƤmƤn vuoksi white box -testauksen suorittavat lƤhes aina ohjelmistosuunnittelijat ja -kehittƤjƤt eivƤtkƤ QA-testaajat, joilla harvoin on tƤmƤntyyppiseen testaukseen tarvittavia teknisiƤ taitoja.
2. Kustannukset
Valkoisen laatikon testaus voi olla kalliimpaa kuin mustan laatikon testaus, koska tƤmƤntyyppinen testaus on perusteellista.
KehittƤjƤt joutuvat kƤyttƤmƤƤn paljon aikaa intensiivisten yksikkƶtestien kirjoittamiseen, ja valkoisen laatikon testejƤ ei useinkaan voi kƤyttƤƤ uudelleen muissa sovelluksissa, mikƤ tarkoittaa, ettƤ valkoisen laatikon testaaminen maksaa yleensƤ melko paljon.
3. Tarkkuus
White box -testaus ei ole aina tarkin ohjelmistotestausmenetelmƤ, ja jos kehitystiimit luottaisivat pelkƤstƤƤn white box -testausmenetelmƤƤn, se johtaisi siihen, ettƤ paljon virheitƤ ja tapauksia jƤisi huomaamatta.
Valkoisen laatikon testauksella validoidaan vain jo olemassa olevat ominaisuudet, kun taas mustan laatikon testausta voidaan kƤyttƤƤ osittain toteutettujen ominaisuuksien testaamiseen tai sellaisten ominaisuuksien tunnistamiseen, jotka todella puuttuvat ohjelmistosta ja jotka olisi sisƤllytettƤvƤ myƶhempiin iteraatioihin.
4. Soveltamisala
White box -testaus ei yleensƤ kerro paljon kƤyttƤjƤkokemuksesta tai ohjelmistoon rakennettujen toimintojen lopputuloksesta.
Vaikka kehittƤjƤt voivat kƤyttƤƤ white box -testausta varmistaakseen, ettƤ koodi toimii kuten sen pitƤisi, he eivƤt voi pƤƤtellƤ, ettƤ toimiva koodi tuottaa oikeat tulokset loppukƤyttƤjille ilman white box -testauksen ja black box -testauksen yhdistƤmistƤ.
TƤmƤ tarkoittaa, ettƤ white box -testauksen laajuus ja se, kuinka paljon se voi kertoa meille ohjelmistosta, on rajoitettu.
White box -testien ominaisuudet
Valkoisen laatikon testaus voidaan mƤƤritellƤ tiettyjen ominaisuuksien perusteella, jotka erottavat sen muista testausmuodoista, kuten mustan laatikon ja harmaan laatikon testauksesta.
Useimpia nƤistƤ ominaisuuksista voidaan tarkastella siitƤ nƤkƶkulmasta, miten ne eroavat mustan laatikon testauksen ominaisuuksista ja miten tƤmƤ erottaa valkoisen laatikon testauksen ja mustan laatikon testauksen toisistaan.
1. YllƤpidettƤvyys
White box -testaus parantaa koodin yllƤpidettƤvyyttƤ, mikƤ helpottaa tiimisi tyƶtƤ jatkossa.
Koska koodia ja sen toimintaa tietojen kanssa seurataan jatkuvasti, sen yllƤpito on paljon yksinkertaisempaa, koska ymmƤrrƤt, missƤ ongelmat ilmenevƤt ja miksi ne ilmenevƤt. TƤmƤ pitƤƤ myƶs koodin yksinkertaisempana tulevia pƤivityksiƤ varten, koska et kehitƤ suuria ja monimutkaisia korjauksia tuntemattomiin ja yksinkertaisiin ongelmiin.
2. Joustavuus
White box -testaus suoritetaan koodilla, joka on riittƤvƤn joustavaa, jotta muutokset voidaan hyvƤksyƤ suhteellisen nopeasti. Joustamaton koodi, kuten kolmannen osapuolen moduuliin tai integraatioon kuuluva koodi, estƤƤ white box -testaajan tekemƤstƤ nopeita muutoksia.
Kun keskitytƤƤn koodiin, jota voidaan muuttaa heti ongelman havaitsemisen jƤlkeen, white box -testauksesta tulee erittƤin mukautuvaa ja ohjelman ongelmat saadaan ratkaistua paljon nopeammin.
3. Modulaarisuus
White box -testaus menestyy koodissa, joka on jossain mƤƤrin modulaarista, mikƤ tarkoittaa, ettƤ ohjelmiston erilliset osat on erotettu selkeƤsti toisistaan.
Jos ohjelmassa on “spagettikoodia”, jossa jokainen osa-alue on sidoksissa toisiinsa, white box -testauksesta tulee ƤƤrettƶmƤn paljon monimutkaisempaa, koska testaajan on tutkittava koko ohjelma eikƤ vain tiettyƤ yksikkƶƤ.
4. Integrointi
White box -testaus on erittƤin hyƶdyllistƤ integrointitestauksessa. Testaajat nƤkevƤt, toimiiko toiminto siihen asti, kun se poistuu kyseisestƤ ohjelmistosta, ja palaako se integroidusta jƤrjestelmƤstƤ odotetun toimivana.
TƤmƤ on erittƤin informatiivista ja antaa organisaatiolle tiedon siitƤ, onko ongelma paikallinen vai osa integroitua alustaa.
MitƤ testataan white box -testeissƤ?
Valkoisen laatikon testejƤ kƤytetƤƤn testaamaan koodin ominaisuuksia, joita ei voida todentaa mustan laatikon testausmenetelmillƤ. TƤmƤ voi tarkoittaa sitƤ, ettƤ testataan, miten itse koodi toimii, jolloin kehittƤjƤt voivat ymmƤrtƤƤ koodin eri osien syyn ja seurauksen.
KehittƤjƤt kƤyttƤvƤt white box -testausta testatakseen tietoturva-aukkoja, lausekkeita ja funktioita, ulostuloja ja polkuja koodissa.
1. SisƤiset turva-aukot
Valkoisen laatikon testauksen avulla voidaan etsiƤ koodista tietoturva-aukkoja ja haavoittuvuuksia, joita hakkerit ja tietoverkkorikolliset voisivat hyƶdyntƤƤ tulevaisuudessa.
Valkoisen laatikon testauksen avulla voidaan tarkistaa, onko kehitysvaiheessa noudatettu parhaita turvallisuuskƤytƤntƶjƤ, ja etsiƤ tietoturva-aukkoja, jotka voidaan korjata ennen kuin koodi siirtyy jatkotestaukseen.
2. Koodausprosessien polut
Valkoisen laatikon testauksen avulla kehittƤjƤt voivat testata polkuja, jotka yhdistƤvƤt koodin eri osia toisiinsa. KehittƤjƤt eivƤt testaa vain koodin logiikkaa, vaan he voivat myƶs tarkastella koodin rakennetta ja hygieniaa.
HyvƤssƤ, puhtaassa koodissa ei ole tarpeettomia rivejƤ tai rikkinƤisiƤ elementtejƤ, jotka eivƤt toimi odotetulla tavalla, vaikka mustalaatikkotestauksen ulkoiset tulokset olisivat odotetun kaltaisia.
3. Odotetut tuotokset
Valkoisen laatikon testauksessa voidaan myƶs testata koodin odotettuja tuotoksia aivan samalla tavalla kuin mustan laatikon testauksessa, vaikka testaajat tekevƤt sen tarkastelemalla koodia eivƤtkƤ kƤyttƤmƤllƤ sovellusta, kuten testaajat saattavat tehdƤ mustan laatikon testauksessa.
KehittƤjƤt testaavat odotettuja tuotoksia tarkistamalla syƶtteet yksi kerrallaan ja tarkistamalla, ettƤ tuloksena oleva tuotos vastaa odotuksia.
4. Lausekkeet, objektit ja funktiot
KƤyttƤmƤllƤ white box -testausmenetelmiƤ ohjelmistokehittƤjƤt voivat varmistaa, ettƤ koodin lausekkeet, objektit ja funktiot kƤyttƤytyvƤt loogisesti ja johtavat odotettuihin tuloksiin.
5. Ehdollisten silmukoiden toimivuus
Valkoisen laatikon testausta voidaan kƤyttƤƤ myƶs ehdollisten silmukoiden, kuten yksittƤisten, ketjutettujen ja sisƤkkƤisten silmukoiden, toimivuuden tarkistamiseen. KehittƤjƤt tarkistavat, ovatko nƤmƤ silmukat tehokkaita, tƤyttƤvƤtkƶ ne ehdollisen logiikan vaatimukset ja kƤsittelevƤtkƶ ne paikallisia ja globaaleja muuttujia oikein.
SelvitƤn hieman sekaannusta:
White box vs Black box vs Grey box -testaus
White box -testaus, black box -testaus ja grey box -testaus ovat termejƤ, joita ohjelmistotestaajat kƤyttƤvƤt viitatakseen eri testausluokkiin tai eri testausmenetelmiin.
Nykyaikainen nƤkemys nƤistƤ testauksen erotteluista on, ettƤ eri tyyppisten laatikkotestausten vƤliset rajat ovat hƤmƤrtymƤssƤ, koska eri testaustyypeissƤ yhdistetƤƤn usein sekƤ valkoisen ettƤ mustan laatikon testauksen elementtejƤ ja testit johdetaan eri abstraktiotasojen dokumenteista.
NƤiden testausmuotojen vƤlillƤ on kuitenkin edelleen tƤrkeitƤ eroja.
1. MitƤ on mustan laatikon testaus?
Mustan laatikon testaus on ohjelmistotestauksen muoto, jossa ohjelmiston toimivuuden tarkistavat testaajat, joilla ei ole tietoa koodin sisƤisestƤ rakenteesta tai siitƤ, miten koodi toteutetaan teknisemmƤllƤ tasolla.
Mustan laatikon testauksessa testataan vain ohjelmiston ulkoiset tuotokset eli toisin sanoen se, mitƤ loppukƤyttƤjƤ kokee kƤyttƤessƤƤn ohjelmistoa.
Mustan laatikon testaus tunnetaan myƶs nimellƤ kƤyttƤytymistestaus, koska siinƤ testataan, miten ohjelmisto kƤyttƤytyy tietyissƤ olosuhteissa.
Testaajat voivat kƤyttƤƤ mustan laatikon testausta arvioidakseen, miten ohjelmiston eri toiminnot kƤyttƤytyvƤt, ja verratakseen niitƤ odotuksiin varmistaakseen, ettƤ ohjelmisto tƤyttƤƤ kƤyttƤjien vaatimukset. Mustan laatikon testausta kƤytetƤƤn jƤrjestelmƤtestauksessa ja hyvƤksymistestauksessa eri toimintojen todentamiseen ja sen tarkistamiseen, ettƤ jƤrjestelmƤ toimii odotetulla tavalla, kun se toimii kokonaisuutena.
Mustan laatikon testauksessa kƤyttƤjƤt kirjoittavat testitapauksia, joissa eri elementit tarkistetaan yksitellen. Koska mustalaatikkotestaus ei vaadi samoja teknisiƤ taitoja kuin valkolaatikkotestaus, mustalaatikkotestauksen suorittavat yleensƤ testaajat laadunvarmistusympƤristƶssƤ eivƤtkƤ kehittƤjƤt.
Mustan laatikon testauksen automatisointi on yleensƤ helpompaa kuin valkoisen laatikon testauksen automatisointi kƤyttƤmƤllƤ ZAPTESTin kaltaisia pƤƤstƤ pƤƤhƤn -automaatiotyƶkaluja.
MitƤ eroja on seuraavien vƤlillƤ white box- ja black box -testauksen vƤlillƤ?
Mustan laatikon ja valkoisen laatikon testauksen tƤrkein ero on se, mitƤ testataan.
Mustan laatikon testauksessa testataan ohjelmiston rakentamisen ulkoisia tuotoksia, kun taas valkoisen laatikon testauksessa testataan, mitƤ konepellin alla tapahtuu.
Mustan laatikon ja valkoisen laatikon testauksen tƤrkeimmƤt erot ovat seuraavat:
KƤyttƶtarkoitus
Mustan laatikon testauksen tarkoituksena on varmistaa, ettƤ jƤrjestelmƤ toimii loppukƤyttƤjƤn odotusten mukaisesti, kun taas valkoisen laatikon testauksen tarkoituksena on tarkistaa ohjelmiston koodin laatu ja eheys.
Esimerkiksi videopelin mustan laatikon testauksessa loppukƤyttƤjƤ voi kokeilla peliƤ ja arvioida sen kokemuksiaan, ja saman projektin valkoisen laatikon testauksessa varmistetaan, ettƤ tiettyjen syƶtteiden syƶttƤminen johtaa siihen, ettƤ hahmo suorittaa oikean toiminnon.
Prosessi
Valkoisen ja mustan laatikon testauksessa kƤytettƤvƤt prosessit ovat hyvin erilaisia. Valkoisen laatikon testaus on paljon helpompi automatisoida kuin mustan laatikon testaus, ja yleensƤ mustan laatikon testaus on automatisoitava ohjelmistoautomaatiotyƶkalujen avulla.
Esimerkiksi tietokannan testauksessa valkoisen laatikon testauksessa automatisoidaan tietojen syƶttƶ ja tarkistetaan, ettƤ kaikki tulokset ovat oikeita, kun taas mustan laatikon testauksessa kƤyttƤjƤt toistavat manuaalisia prosesseja ja raportoivat niistƤ ilman automaatiojƤrjestelmƤƤ.
Testaajat
Mustan laatikon testauksen suorittavat lƤhes aina ammattimaiset ohjelmistotestaajat laadunvarmistusympƤristƶssƤ, kun taas valkoisen laatikon testauksen suorittavat ohjelmistokehittƤjƤt ja insinƶƶrit, joilla on yksityiskohtaisempaa teknistƤ tietoa koodilƤhteestƤ.
Tekniikat
Mustan laatikon testauksessa kƤytetƤƤn erilaisia tekniikoita, kuten ekvivalenssiosiointia, raja-arvoanalyysiƤ ja pƤƤtƶstaulukkotestausta. Valkoisen laatikon testauksessa kƤytetƤƤn tekniikoita, kuten pƤƤtƶsten kattavuutta, ehtojen kattavuutta ja lausekkeiden kattavuutta.
Toiminta
Mustalaatikkotestauksen testausmenetelmƤt sopivat ylemmƤn tason testaustoimintoihin, kuten jƤrjestelmƤtestaukseen ja hyvƤksymistestaukseen, kun taas valkolaatikkotestaus soveltuu paremmin alemman tason toimintoihin, kuten yksikkƶ- ja integrointitestaukseen.
TƤstƤ syystƤ white box -testaus suoritetaan yleensƤ ennen useimpia black box -testauksen muotoja.
2. MitƤ on harmaan laatikon testaus?
Harmaalaatikkotestaus on ohjelmistotestausmenetelmƤ, jota kƤytetƤƤn ohjelmistotuotteiden ja -sovellusten testaamiseen testaajilla, joilla voi olla osittainen tietƤmys sovelluksen sisƤisestƤ rakenteesta, mutta ei tƤydellistƤ tietoa siitƤ.
Harmaalaatikkotestauksessa voidaan yhdistƤƤ sekƤ mustalaatikko- ettƤ valkolaatikkotestauksen elementtejƤ, jotta kehittƤjƤt ja testaajat voivat tunnistaa koodin puutteita ja lƶytƤƤ kontekstisidonnaisia virheitƤ.
Harmaan laatikon testauksessa yhdistyvƤt sekƤ mustan laatikon ettƤ valkoisen laatikon testauksen ominaisuudet. Testaajilla on oltava jonkin verran tietoa jƤrjestelmƤn sisƤisestƤ toiminnasta, kuten valkoisen laatikon testauksessa, mutta he kƤyttƤvƤt tƤtƤ tietoa luodakseen testitapauksia ja suorittaakseen nƤmƤ testitapaukset toiminnallisuuden tasolla, kuten mustan laatikon testauksessa.
Harmaalaatikkotestaus tarjoaa monia sekƤ mustalaatikko- ettƤ valkolaatikkotestauksen etuja, mutta on samalla myƶs suhteellisen ajantehokasta ja joustavaa.
MitƤ eroja on seuraavien vƤlillƤ white box- ja grey box -testauksen vƤlillƤ?
Koska harmaalaatikkotestaus tarjoaa joitakin samoja toimintoja kuin mustalaatikkotestaus, harmaalaatikkotestauksen ja valkolaatikkotestauksen vƤlillƤ on joitakin suuria eroja, vaikka niitƤ ei ehkƤ olekaan niin paljon kuin mustalaatikkotestauksessa.
Suurimpia eroja harmaan laatikon testauksen ja valkoisen laatikon testauksen vƤlillƤ ovat:
Rakenteellinen tietƤmys
Valkoisen laatikon testauksessa koodin sisƤisen suunnittelun ja rakenteen pitƤisi olla tƤysin testaajan tiedossa. Harmaan laatikon testauksessa koodin sisƤinen rakenne tunnetaan yleensƤ vain osittain.
Asianomaiset henkilƶt
Valkoisen laatikon testauksesta vastaavat lƤhes yksinomaan ohjelmistokehittƤjƤt ja ohjelmistoinsinƶƶrit, kun taas harmaan laatikon testauksesta voivat vastata loppukƤyttƤjƤt, testaajat ja kehittƤjƤt.
Tehokkuus
Valkoisen laatikon testausta pidetƤƤn eniten aikaa vievƤnƤ ohjelmistotestaustyyppinƤ, kun taas harmaan laatikon testauksessa hyƶdynnetƤƤn joitakin mustan laatikon testauksen tehokkuusominaisuuksia testien suorittamiseen kuluvan ajan lyhentƤmiseksi.
Operaatio
Valkoisen laatikon testauksessa kehittƤjƤt yksinkertaisesti kirjoittavat koodia valkoisen laatikon testien toteuttamiseksi ja suorittavat tƤmƤn koodin. Harmaan laatikon testauksessa, kuten mustan laatikon testauksessa, testaajat tekevƤt toiminnallisia testejƤ arvioidakseen, miten jƤrjestelmƤ toimii ulkoisesti.
Kattavuus
Valkoisen laatikon testaus on kattavin testaustyyppi, kun taas harmaan laatikon testauksen kattavuus voi vaihdella sen mukaan, perustuvatko testitapaukset koodiin vai graafiseen kƤyttƶliittymƤƤn.
JohtopƤƤtƶkset:
Valkoinen laatikko vs. musta laatikko vs. harmaan laatikon testaus
White box -testaus, black box -testaus ja grey box -testaus ovat termejƤ, joita kƤytetƤƤn viittaamaan erilaisiin ohjelmistotestausmenetelmiin. Yleisesti ottaen kukin testaustyyppi voidaan mƤƤritellƤ sen perusteella, missƤ mƤƤrin testaajilla on oltava tietoa koodikannasta ja koodin toteutuksesta:
1. Mustan laatikon testaus:
Koodin sisƤinen rakenne on tuntematon.
2. Valkoisen laatikon testaus:
Koodin sisƤinen rakenne tunnetaan.
3. Harmaan laatikon testaus:
Koodin sisƤinen rakenne tunnetaan osittain.
Ohjelmistotestauksessa kaikki kolme testaustyyppiƤ ovat tƤrkeitƤ ohjelmiston toiminnan ja eheyden varmistamisessa. Valkoisen laatikon testaus kertoo enemmƤn koodin rakenteesta, kun taas harmaan laatikon ja mustan laatikon testauksella voidaan tarkistaa, miten jƤrjestelmƤ toimii ja tƤyttƤƤkƶ se loppukƤyttƤjƤn vaatimukset.
EhkƤ suurimmat erot nƤiden kolmen testaustyypin vƤlillƤ liittyvƤt siihen, kuka kunkin testaustyypin suorittaa, itse testauksen vaatimuksiin ja siihen, mitƤ testaus sisƤltƤƤ.
Valkoisen laatikon testauksella on korkeimmat kynnykset, koska sen suorittavat kehittƤjƤt, joilla on yksityiskohtaista tietoa itse koodipohjasta, ja koska se on aikaa vievin ja usein kallein testaustyyppi.
Sen sijaan mustan laatikon testaus on helpointa toteuttaa, ja sen voivat suorittaa testaajat, jotka eivƤt tunne taustalla olevaa koodia.
Valkoisen laatikon testien tyypit
On olemassa monia erilaisia valkoisen laatikon testejƤ, joista kutakin voidaan kƤyttƤƤ testaamaan hieman eri nƤkƶkohtia koodin sisƤisestƤ rakenteesta.
Alla on lueteltu joitakin yleisimpiƤ nykyisin kƤytettyjƤ white box -testaustyyppejƤ.
1. Polun testaus
Polkutestaus on erƤƤnlaista valkoisen laatikon testausta, joka perustuu ohjelman valvontarakenteeseen. KehittƤjƤt kƤyttƤvƤt kontrollirakennetta luodakseen kontrollivirtakaavion ja testatakseen erilaisia polkuja kaaviossa.
Polkutestaus on testaustyyppi, joka on riippuvainen ohjelman valvontarakenteesta, mikƤ tarkoittaa, ettƤ testaajilta vaaditaan perusteellista tietƤmystƤ tƤstƤ rakenteesta.
Jos esimerkiksi jƤrjestelmƤn on tarkoitus ottaa yhteyttƤ asiakkaisiin tietyissƤ myyntisuppilon vaiheissa, polkutestaus tarkoittaa sen varmistamista, ettƤ jƤrjestelmƤ noudattaa oikeita vaiheita datan asettamien ehtojen mukaan.
2. Silmukan testaus
Silmukkatestaus on yksi tƤrkeimmistƤ white box -testauksen tyypeistƤ, jossa testataan ohjelman koodin silmukoita. Silmukat on toteutettu koodin sisƤllƤ oleviin algoritmeihin, ja silmukoiden testauksella tarkistetaan, ovatko nƤmƤ silmukat kelvollisia.
Silmukoiden testauksella voidaan arvioida, onko tietyissƤ silmukoissa haavoittuvuuksia, ja nostaa esiin alueita, joilla kehittƤjien on ehkƤ korjattava koodia varmistaakseen, ettƤ silmukka toimii niin kuin sen pitƤisi.
Esimerkki silmukkatestistƤ on seurata silmukan lƤpi tietyllƤ joukolla datapisteitƤ, jotka kehottavat silmukkaa jatkamaan, kuten kieltƤytyminen hyvƤksymƤstƤ joitakin ehtoja, ennen kuin syƶtetƤƤn luku, joka nimenomaan katkaisee silmukan. Jos silmukka kƤyttƤytyy odotetulla tavalla, testi on onnistunut.
3. Ehdollinen testaus
Ehdollinen testaus on erƤƤnlainen valkoisen laatikon testaus, jossa tarkistetaan, ovatko koodissa olevien arvojen loogiset ehdot totta vai epƤtotta.
Ehdollinen testaus on yksi tƤrkeimmistƤ valkoisen laatikon testauksen muodoista, joka kertoo kehittƤjille, onko koodi looginen ja tƤyttƤƤkƶ se ohjelmointilogiikan vaatimukset.
Esimerkki ehdollisesta testauksesta on kirjanpitoalustassa. Kun syƶtƤt sarjan menoja ja tuloja, tuloksena pitƤisi olla oikeat juoksevat loppusummat, ja ohjelmisto antaa tarkat tulokset koko onnistuneen testin ajan.
4. Yksikkƶtestaus
Yksikkƶtestaus on tƤrkeƤ vaihe ohjelmistotestauksessa, jossa kehittƤjƤt testaavat yksittƤisiƤ komponentteja ja moduuleja ja varmistavat, ettƤ ne toimivat odotetulla tavalla, ennen kuin eri yksikƶt integroidaan yhteen.
Ohjelmistoinsinƶƶrit kƤyttƤvƤt yksikkƶtestauksessa white box -testausmenetelmiƤ testatakseen pieniƤ koodinpƤtkiƤ kerrallaan. TƤmƤ helpottaa vikojen ja virheiden tunnistamista, kun niitƤ esiintyy testauksen aikana.
Esimerkki yksikkƶtestauksesta on kehityksen alkuvaiheessa, kun yritys luo verkkosivustolle yksinkertaisen painikkeen, joka vie kƤyttƤjƤn toiselle sivulle. Jos yksikkƶ toimii odotetulla tavalla, se onnistuu, ja kehittƤjƤt tekevƤt muutoksia, kunnes se toimii.
5. Mutaatiotestaus
Mutaatiotestaus on testaustyyppi, jossa testataan muutoksia ja mutaatioita. Mutaatiotestauksessa kehittƤjƤt tekevƤt pieniƤ muutoksia lƤhdekoodiin nƤhdƤkseen, voiko tƤmƤ paljastaa koodissa olevia virheitƤ.
Jos testitapaus lƤpƤisee testin, se osoittaa, ettƤ koodissa on jokin ongelma, koska sen ei pitƤisi lƤpƤistƤ testiƤ muutosten jƤlkeen. Ihannetapauksessa mutaatiotestauksessa kaikki testitapaukset epƤonnistuvat.
Esimerkki mutaatiotestauksesta on koneoppimisessa. Koneoppimisohjelmat “mutantoituvat” automaattisesti uuden tiedon perusteella, joten nƤiden ohjelmien testaaminen jatkuvasti “mutaation” standardin mukaisesti antaa kehittƤjille tietoa siitƤ, toimiiko ohjelmisto odotetulla tavalla.
6. Integrointitestaus
Integrointitestaus on ohjelmistotestauksen pƤƤvaihe, jonka aikana testaajat varmistavat, ettƤ eri moduulit toimivat oikein, kun ne integroidaan muiden moduulien kanssa.
Integrointitestauksessa kƤytetƤƤn valkoisen laatikon testaustekniikoita, joilla tarkistetaan, ettƤ koodi toimii myƶs silloin, kun useat moduulit – jotka ovat usein eri kehittƤjien koodaamia – toimivat yhdessƤ.
Kun tietokanta saa tietoja esimerkiksi verkkolƤhteestƤ, integraatiotestauksella varmistetaan, ettƤ tiedot ovat tarkkoja ja pƤivittyvƤt kohtuullisen johdonmukaisesti.
7. Tunkeutumistestaus
Tunkeutumistestaus on erƤƤnlaista white box -testausta, jonka avulla voidaan simuloida tiettyjƤ jƤrjestelmƤƤn kohdistuvia verkkohyƶkkƤyksiƤ.
Tunkeutumistestauksessa testaajille annetaan pƤƤsy kaikkiin verkko- ja jƤrjestelmƤtietoihin, kuten salasanoihin ja verkkokarttoihin. Sen jƤlkeen he yrittƤvƤt pƤƤstƤ kƤsiksi jƤrjestelmƤssƤ oleviin tietoihin tai tuhota ne yrittƤmƤllƤ mahdollisimman monia eri hyƶkkƤysreittejƤ.
Tunkeutumistestaus on tƤrkeƤ osa tietoturvatestausta, joka olisi suoritettava kaikille ohjelmistokehityksille.
Esimerkiksi HR-alusta suorittaa penetraatiotestauksen ja etsii koodista haavoittuvuuksia varmistaakseen, ettƤ alusta on riittƤvƤn turvallinen tyƶntekijƶiden tietojen sƤilyttƤmiseen.
Valkoisen laatikon testaustekniikat
On olemassa monia erilaisia white box -testausmenetelmiƤ, joita voidaan kƤyttƤƤ edellƤ lueteltujen white box -testien suorittamiseen. Kuten aina, eri tekniikat soveltuvat parhaiten koodin eri osa-alueiden testaamiseen, mutta kaikki alla luetellut white box -tekniikat ovat tƤrkeitƤ.
1. Lausuman kattavuus
Yksi valkoisen laatikon testauksen ominaispiirteistƤ on, ettƤ testaajien tulisi pyrkiƤ kattamaan mahdollisimman suuri osa lƤhdekoodista suorittaessaan valkoisen laatikon testejƤ.
Koodin kattavuus on vahva mittari tƤlle, ja lausekkeiden kattavuus on yksi tekniikka, jota white box -testaajat voivat kƤyttƤƤ lisƤƤmƤƤn lausekkeiden kattavuutta koodissa.
Lausekkeiden kattavuus on mittari, joka mittaa suoritettujen lausekkeiden mƤƤrƤƤ jaettuna lausekkeiden kokonaismƤƤrƤllƤ ja kerrottuna sadalla. Valkoisen laatikon testaajien tulisi pyrkiƤ korkeaan lausuntojen kattavuuteen.
2. Haarojen kattavuus
Haarojen kattavuus, kuten lausekkeiden kattavuus, kuvastaa sitƤ, kuinka laaja kattavuus koodin tietyillƤ elementeillƤ on white box -testauksessa. Haarautumiset vastaavat logiikan ‘IF’-lauseita, joissa koodi haarautuu tosia ja vƤƤriƤ vaihtoehtoja varten, jotka vaikuttavat operaation lopputulokseen.
Kun kƤytetƤƤn haarojen kattavuusmenetelmiƤ, valkoisen laatikon testaajat tarkistavat, ettƤ kutakin haaraa kƤsitellƤƤn vƤhintƤƤn kerran, ja varmistavat, ettƤ molemmat haarat toimivat oikein.
3. Reitin kattavuus
Polun kattavuusmenetelmillƤ arvioidaan ohjelmistosovelluksen polkuja. Testipolkujen kattavuuden maksimointi tarkoittaa sen varmistamista, ettƤ kaikki ohjelman polut tutkitaan vƤhintƤƤn kerran. Se on samantyyppinen testaustekniikka kuin haarojen kattavuus, mutta sitƤ pidetƤƤn perusteellisempana ja tehokkaampana.
Polun kattavuuden testausta pidetƤƤn yleensƤ sopivimpana kokonaisten sovellusten testaamiseen kuin osittaisten rakennelmien testaamiseen.
4. PƤƤtƶksen kattavuus
PƤƤtƶskattavuus on yksi tƤrkeimmistƤ white box -tekniikoista, koska se antaa tietoa lƤhdekoodissa olevien boolean-lausekkeiden oikeista ja vƤƤristƤ tuloksista.
PƤƤtƶsten kattavuuden testaaminen validoi lƤhdekoodin varmistamalla, ettƤ jokaisen mahdollisen pƤƤtƶksen jokainen merkki kƤydƤƤn lƤpi vƤhintƤƤn kerran testauksen aikana.
Ratkaisupisteisiin kuuluvat kaikki tilanteet, joissa on mahdollisuus kahteen tai useampaan eri lopputulokseen.
5. Kunnon kattavuus
Ehdollinen kattavuus tunnetaan myƶs nimellƤ ilmaisun kattavuus. TƤmƤ white box -tekniikka arvioi koodin sisƤllƤ olevien ehdollisten lausekkeiden alamuuttujia kunkin loogisen ehdon tuloksen tarkistamiseksi.
TƤmƤntyyppisessƤ testauksessa otetaan huomioon vain lausekkeet, joissa on loogisia operandeja, kun taas pƤƤtƶksen kattavuuden testausta ja haarojen kattavuuden testausta kƤytetƤƤn muiden loogisten operaatioiden varmistamiseen.
6. Useiden sairauksien kattavuus
Usean ehdon kattavuustestissƤ testaajat tarkistavat eri ehtojen yhdistelmiƤ ja arvioivat pƤƤtƶksen, jonka koodi tekee kunkin yhdistelmƤn kohdalla.
Usean ehdon kattavuustesteissƤ voi olla monia erilaisia testitapauksia, koska ehtojen yhdistelmiƤ on valtava mƤƤrƤ, joten tƤmƤntyyppinen testaus on usein hyvin aikaa vievƤƤ.
7. Lopullisen tilakoneen kattavuus
Rajallisten tilakoneiden kattavuus on tƤrkeƤ testaustyyppi, mutta myƶs yksi vaikeimmista tavoista saavuttaa korkea koodin kattavuus white box -testauksessa. Se toimii suunnittelun toiminnallisuuden perusteella ja edellyttƤƤ, ettƤ kehittƤjƤt laskevat, kuinka monta kertaa tilassa kƤydƤƤn tai siirrytƤƤn testausprosessin aikana, sekƤ kuinka monta sekvenssiƤ kukin ƤƤrellinen tilajƤrjestelmƤ sisƤltƤƤ.
8. Ohjausvirran testaus
Ohjausvirtatestaus on white box -testausmenetelmƤ, jolla pyritƤƤn selvittƤmƤƤn ohjelman suoritusjƤrjestys yksinkertaisen ohjausrakenteen avulla.
KehittƤjƤt rakentavat ohjausvirtatestauksen testitapaukset valitsemalla tietyn ohjelman osan ja rakentamalla testauspolun. Ohjausvirtatestausta kƤytetƤƤn yleensƤ yksikkƶtestauksessa.
Valkoisen laatikon testauksen elinkaari
ohjelmistokehityksessƤ
White box -testaus on tƤrkeƤ vaihe ohjelmistokehityksen elinkaaressa, vaikka sillƤ ei olekaan tiettyƤ paikkaa elinkaaressa.
KehittƤjƤt voivat tehdƤ white box -testausta silloin, kun heidƤn on tarkistettava koodin toiminta, ja jotkut kehittƤjƤt saattavat olla toisia perusteellisempia tarkistamaan vasta kirjoitetun koodin varmistaakseen, ettƤ se on puhdasta ja ettƤ siinƤ ei ole tarpeettomia rivejƤ.
White box -testaus suoritetaan kuitenkin yleisimmin yksikkƶ- ja integrointitestauksen aikana. KehittƤjƤt suorittavat sekƤ yksikkƶ- ettƤ integrointitestauksen kehitysvaiheen aikana.
Ne tapahtuvat ennen toiminnallista testausta, kuten jƤrjestelmƤtestausta ja hyvƤksymistestausta, ja ne antavat kehittƤjille mahdollisuuden tunnistaa, paikantaa ja korjata tƤrkeimmƤt virheet testausvaiheen alkuvaiheessa ennen tuotteen luovuttamista laadunvarmistustiimille.
Manuaaliset vai automatisoidut white box -testit?
Kuten muunkinlaista ohjelmistotestausta, myƶs white box -testausta on mahdollista automatisoida. Se voi olla joko manuaalista tai automatisoitua, vaikka useimmissa tapauksissa valkoisen laatikon testauksen automatisointi on helpompaa kuin mustan laatikon testauksen automatisointi.
Koska white box -testaus on hyvin aikaa vievƤƤ testausta, automatisointi on yhƤ suositumpaa ohjelmistotiimien keskuudessa.
Manuaalinen white box -testaus: hyƶdyt, haasteet ja prosessit
Manuaalinen white box -testaus tarkoittaa white box -testien suorittamista manuaalisesti, ja se edellyttƤƤ, ettƤ kehittƤjillƤ on taitoja ja aikaa kirjoittaa yksittƤisiƤ testitapauksia, joilla testataan jokainen mahdollinen koodirivi ohjelmistokehityksessƤ. TƤmƤ voi viedƤ paljon aikaa, mutta tuloksena on myƶs perusteellisimmat testitulokset ja tuotokset.
Valkoisen laatikon testauksen manuaalisen suorittamisen etuja ovat muun muassa seuraavat:
1. Syvyys
Manuaalisen testauksen avulla testaajat voivat halutessaan tutkia ohjelmistokoodia syvƤllisemmin kuin automaattisen testauksen avulla, esimerkiksi lukemalla sovelluksen koko lƤhdekoodin sen sijaan, ettƤ he vain automatisoisivat tehtƤviƤ, jotka koskettavat pintatoimintoja.
2. Vikojen sijainti
Manuaalisen testauksen avulla on helppo lƶytƤƤ virheitƤ ja puutteita, koska kehittƤjien pitƤisi pystyƤ mƤƤrittƤmƤƤn tarkalleen, millƤ koodirivillƤ virhe on.
Jos esimerkiksi havaitset, ettƤ kuva ei lataudu, ja tarkastelet koodista rivejƤ, jotka liittyvƤt kuvien lataamiseen, pystyt merkittƤvƤsti rajaamaan syyn pois.
3. Nopeus
Manuaalinen testaus kestƤƤ yleensƤ kauemmin kuin automatisoitu testaus, mutta jos kehittƤjƤt haluavat suorittaa vain yhden tai kaksi nopeaa testiƤ, on luultavasti nopeampaa suorittaa ne manuaalisesti kuin ottaa kƤyttƶƶn automaatio.
Esimerkiksi yksikkƶtestauksessa tarkastellaan ominaisuutta ja katsotaan, toimiiko se, eikƤ kerƤtƤ valtavia mƤƤriƤ tietoa automatisoimalla prosessi. Manuaalisessa white box -testauksessa on kuitenkin myƶs haittoja.
Manuaalisen white box -testauksen haasteita ovat muun muassa seuraavat:
1. Tarkkuus
Manuaalisen testauksen avulla kehittƤjƤt voivat kattaa laajan valikoiman koodia, mutta ihmistestaajat ovat aina alttiimpia virheille ja virheille kuin tietokoneohjelmat, minkƤ vuoksi manuaalista testausta pidetƤƤn usein epƤtarkempana kuin automaattista testausta.
2. Aika
Manuaalinen testaus kestƤƤ kauemmin kuin automatisoitu testaus, ja manuaalinen white box -testaus on kaikkein aikaa vievintƤ testausta. TƤmƤ pidentƤƤ lƤpimenoaikaa ja voi vaikeuttaa tiukkojen kehitysaikataulujen noudattamista.
3. Kustannukset
Koska manuaaliseen white box -testaukseen tarvitaan paljon tyƶvoimaa ja resursseja, se on usein kalliimpaa kehitystiimille kuin automatisoitu testaus, joka vaatii yleensƤ vƤhemmƤn kehittƤjiƤ ja vƤhemmƤn aikaa.
4. Skaalautuvuus
Manuaalinen testaus soveltuu oikeastaan vain pienten sovellusten testaamiseen tai suurempien sovellusten yksittƤisten osien testaamiseen. Kun kyseessƤ ovat suuremmat sovellukset, kuten pilvipalveluna toimiva tietokanta, johon tulee tuhansia syƶtteitƤ minuutissa, automatisoitu testaus on suositeltavampi menetelmƤ vakiokuormien simuloimiseksi.
Automatisoitu white box -testaus: hyƶdyt,
haasteet ja prosessit
Automaatioteknologia helpottaa ohjelmistotestauksen osa-alueiden automatisointia joka pƤivƤ. Alan siirtyminen kohti hyperautomaatiota johtuu osittain tehokkuudesta ja kustannussƤƤstƶistƤ, joita automaatio tarjoaa kehitystiimeille, jotka tuntevat itsensƤ aina tiukasti puristetuiksi.
White box -testaus on yksi tarkoituksenmukaisimmista ja sopivimmista testaustyypeistƤ automatisoitavaksi, koska se on suhteellisen helppo automatisoida ja koska white box -testausautomaation aika- ja kustannussƤƤstƶt voivat olla merkittƤviƤ.
Automaattiseen white box -testaukseen voi kuulua, ettƤ kehittƤjƤt kirjoittavat itse testiskriptejƤ, tai prosessia voidaan nopeuttaa kƤyttƤmƤllƤ ZAPTESTin kaltaisia tƤysimittaisia tyƶkaluja, jotka tarjoavat uusinta ohjelmistojen testaustekniikkaa.
Valkoisen laatikon testauksen automatisoinnin etuja ovat muun muassa:
1. Tarkkuus
Tietokonepohjainen testaus poistaa virheriskin, koska tietokoneet eivƤt vƤsy tai tee virheitƤ.
2. Aika
Automatisoitu white box -testaus on huomattavasti nopeampaa kuin manuaalinen white box -testaus ja vapauttaa aikaa, jonka kehittƤjƤt voivat kƤyttƤƤ muihin tehtƤviin, kuten virheiden korjaamiseen tai pƤivityskorjausten kirjoittamiseen.
3. Mittakaava
Automatisoitu testaus skaalautuu paljon paremmin kuin manuaalinen testaus, joten jos ohjelmistosovelluksesi kasvaa tai jos haluat suorittaa kerralla laajamittaisen testauksen, automaatio on parempi vaihtoehto.
Esimerkiksi tietojen syƶtƶn lisƤƤminen tarkoittaa sitƤ, ettƤ automaatiossa tarvitaan enemmƤn syƶtteitƤ kuin manuaalisten testien yhteydessƤ, kun taas manuaalisissa testeissƤ palkataan lisƤƤ henkilƶstƶƤ.
4. Kustannukset
Automatisoidun testauksen kustannukset ovat yleensƤ alhaisemmat kuin manuaalisen testauksen kustannukset, koska automaatio sƤƤstƤƤ tyƶtunteja. ZAPTESTin 10-kertainen ROI osoittaa, miten automatisointi voi sƤƤstƤƤ kehittƤjien rahaa ja johtaa suurempiin tuottoihin. Automatisoinnilla on kuitenkin myƶs omat haittansa.
Valkoisen laatikon testauksen automatisointiin liittyviƤ haasteita ovat muun muassa seuraavat:
1. Vikojen seuranta
Automaatio ei aina helpota virheiden lƶytƤmistƤ koodista riippuen siitƤ, miten kehittƤjƤt automatisoivat testit tai mitƤ testaustyƶkaluja kƤytetƤƤn, varsinkin kun verrataan manuaaliseen white box -testiin, jossa testaajat nƤkevƤt suoritettavan koodin aina kun virhe ilmenee.
2. Taidot
Kaikki kehittƤjƤt eivƤt osaa automatisoida testejƤ tai kƤyttƤƤ automatisoituja testaustyƶkaluja, joten siirtyminen automatisointiin voi vaatia investointeja tƤrkeimpien taitojen kouluttamiseen, kuten koodaamiseen kyseisen testausalustan kielellƤ ja data-analyysitaitojen kƤyttƤmiseen ongelmien syyn ymmƤrtƤmiseksi white box -testissƤ.
JohtopƤƤtƶkset: Manuaalinen white box -testaus
vai white box -testausautomaatio?
Kaiken kaikkiaan ohjelmistotekniikan white box -testaus on yksi soveltuvimmista testaustyypeistƤ, joka voidaan mukauttaa automatisoituun testaukseen, mikƤ johtuu suurelta osin manuaalisen white box -testauksen aikaa vievƤstƤ ja monimutkaisesta luonteesta.
Automaattinen white box -testaus on nopeampaa, halvempaa, tehokkaampaa ja tarkempaa kuin manuaalinen testaus, erityisesti kun kyseessƤ ovat suuremmat sovellukset.
OhjelmistokehittƤjien olisi mahdollisuuksien mukaan automatisoitava white box -testausta ohjelmistotestauksessa, jotta testien luotettavuutta voidaan lisƤtƤ ja jotta testaamalla voidaan kattaa suurempi osa suuremmista sovelluksista kuin on kƤytƤnnƶssƤ mahdollista testejƤ manuaalisesti suoritettaessa. TƤmƤ johtuu huomattavista kustannuksista ja asiantuntemuksesta, joita tarvitaan, kun white box -testejƤ tehdƤƤn yksinomaan manuaalisilla menetelmillƤ.
MitƤ tarvitset aloittaaksesi
white box -testaus?
Ennen kuin aloitat white box -testauksen, varmista, ettƤ sinulla on kaikki tarvittava alkuun pƤƤsemiseksi. Riippuen siitƤ, teetkƶ manuaalista vai automatisoitua white box -testausta, et tarvitse paljon muita resursseja kuin aikaa ja rahaa.
Sinun on kuitenkin varmistettava, ettƤ tiimillƤsi on asianmukainen tietƤmys ja tyƶkalut white box -testauksen asianmukaista suorittamista varten.
1. LƤhdekoodin ymmƤrtƤminen
White box -testaus on testausta, jonka suorittavat ohjelmistokehittƤjƤt ja insinƶƶrit, joilla on tƤydet tiedot lƤhdekoodista ja ohjelmiston sisƤisestƤ rakenteesta.
Jos olet QA-testaajana ilman tƤtƤ tietoa, sinun on annettava ohjelmisto jollekin toiselle, ennen kuin white box -testaus voidaan aloittaa.
2. Testitapaukset
On vƤlttƤmƤtƶntƤ kirjoittaa testitapauksia ennen white box -testauksen suorittamista. Testitapaukset ovat yksittƤisiƤ ohjejoukkoja, jotka kuvaavat toimia, joita testaajat tai kehittƤjƤt voivat suorittaa jƤrjestelmƤn toimintojen ja toiminnan testaamiseksi.
Valkoisen laatikon testauksessa testitapauksia suunnittelevat henkilƶt, joilla on tƤydelliset tiedot jƤrjestelmƤn sisƤisestƤ rakenteesta, ja ne luodaan sen tarkistamiseksi, toimiiko jƤrjestelmƤ niin kuin sen pitƤisi.
3. Valkoisen laatikon testaustyƶkalut
Valkoisen laatikon testaukseen on saatavilla runsaasti tyƶkaluja, jotka tukevat pƤƤsyƤ lƤhdekoodiin ja suunnitteludokumentteihin testiautomaation suorittamisen ohella. NiitƤ on saatavana myƶs eri hintaluokissa, kuten ZAPTEST FREE- ja ZAPTEST ENTERPRISE -versioina, jotka tarjoavat enemmƤn joustavuutta.
Valitse tyƶkalut, joita haluat kƤyttƤƤ ennen testauksen aloittamista, ja painota sen varmistamista, ettƤ siinƤ on oikeat toiminnot, kuten alustarajat ylittƤvƤ toiminta ja tietokonenƤkƶtekniikka, jotta nƤet saman kuin automatisoidut testit nƤkevƤt.
Varmista, ettƤ kaikki testaukseen osallistuvat kehittƤjƤt ja insinƶƶrit tietƤvƤt, miten ja milloin niitƤ kƤytetƤƤn.
Valkoisen laatikon testausprosessi
Valkoisen laatikon testaukseen liittyy paljon enemmƤn jƤrjestelmƤn toiminnan tuntemusta kuin mustan laatikon testaukseen, ja jotkin valkoisen laatikon testauksen vaiheet ovat hieman erilaisia.
Valkoisen laatikon testaajien on ensin tunnistettava jƤrjestelmƤn ominaisuudet tai komponentit, jotka he haluavat todentaa, ennen kuin he suunnittelevat mahdollisia testipolkuja ja kirjoittavat testitapauksia suoritettavaksi.
Valkoisen laatikon testausprosessi voi myƶs vaihdella sen mukaan, mitƤ valkoisen laatikon testaustekniikkaa kƤytƤt. Seuraa alla olevia ohjeita, jotta saat selville, miten white box -testaus suoritetaan maksimoiden polun kattavuus.
Vaihe 1: Testattavien ominaisuuksien mƤƤrittƤminen
Ennen kuin teet white box -testauksen, mieti tarkkaan, mitƤ haluat testata ja miten aiot testata sen. TƤmƤ tarkoittaa yleensƤ sitƤ, ettƤ keskitytƤƤn pieneen joukkoon toimintoja tai ominaisuuksia ja luodaan joukko testitapauksia vain niiden testaamista varten.
Voit suorittaa tƤmƤn vaiheen uudelleen ja uudelleen jƤrjestelmƤn eri osa-alueille testien kattavuuden maksimoimiseksi, mutta on tƤrkeƤƤ jakaa eri osa-alueet yksittƤisiin testeihin.
MitƤ tarkemmin keskityt, sitƤ luotettavampia ja tarkempia testit voivat olla.
Vaihe 2: PiirrƤ kaikki mahdolliset reitit vuokaavioon.
MerkittƤvƤ osa white box -testauksen valmistelutyƶtƤsi on kaikkien mahdollisten testattavien reittien piirtƤminen vuokaavioon.
TƤmƤ vaihe voi auttaa sinua maksimoimaan polkujen kattavuuden ja varmistamaan, ettƤ tarkistat kaikki mahdolliset polut jokaisessa luomassasi testitapauksessa. PiirrƤ vuokaavio, joka kattaa kaikki mahdolliset reitit jokaiselle testaamallesi ominaisuudelle tai komponentille, esimerkiksi hahmottelemalla eri reitit, jotka syntyvƤt, kun eri arvoja syƶtetƤƤn.
Vaihe 3: Kaikkien mahdollisten reittien tunnistaminen
Katso vuokaaviota ja tunnista kaikki mahdolliset polut, joita kƤyttƤjƤt voivat kulkea, alkaen vuokaavion ensimmƤisestƤ vaiheesta ja pƤƤttyen viimeiseen vaiheeseen.
MitƤ enemmƤn haaroja ja pƤƤtƶksiƤ virtauskaaviossasi on, sitƤ enemmƤn ainutlaatuisia polkuja on olemassa. YmmƤrtƤmƤllƤ, kuinka monta ainutlaatuista mahdollista polkua on olemassa, voit varmistaa, ettƤ testitapaukset kattavat kaikki mahdollisuudet.
Vaihe 4: Luo testitapaukset
Seuraava vaihe white box -testauksessa on testitapausten kirjoittaminen, joissa tarkistetaan kaikki edellƤ tunnistamasi polut.
On tƤrkeƤƤ varmistaa, ettƤ testitapaukset kattavat kaikki mahdolliset reitit ja ettƤ niissƤ hahmotellaan selkeƤsti toimenpiteet, jotka testaajien tai kehittƤjien on tehtƤvƤ kunkin testitapauksen suorittamiseksi.
Ilmoita kunkin testitapauksen tunnus ja nimi sekƤ lyhyt kuvaus ja kunkin testin odotetut tulokset.
Vaihe 5: Testitapausten suorittaminen
Nyt on aika suorittaa testitapaukset, mitƤ useimmat pitƤvƤt itse white box -testauksena.
Testaajat suorittavat testitapaukset noudattamalla kussakin testitapauksessa esitettyjƤ lyhyitƤ ohjeita ja raportoivat kunkin testitapauksen tuloksen. TƤtƤ voidaan verrata testitapauksessa esitettyihin odotettuihin tuloksiin, jotta voidaan todeta, onko kukin white box -testi lƤpƤissyt vai epƤonnistunut.
Vaihe 6: Toista sykli tarvittaessa.
Kuten muissakin ohjelmistotestauksen muodoissa, myƶs white box -testauksessa on kyse siitƤ, ettƤ verrataan jƤrjestelmƤn todellista toimintaa testaajien odotuksiin siitƤ, miten jƤrjestelmƤn pitƤisi toimia.
Jos testaajat huomaavat, ettƤ jƤrjestelmƤ ei kƤyttƤydy odotetulla tavalla, se voi tarkoittaa, ettƤ white box -testaus on epƤonnistunut, ja kehittƤjien on korjattava koodirivit ennen jatkotestausta.
Toista edellƤ kuvattu prosessi ja tee lisƤƤ white box -testausta, kunnes jƤrjestelmƤ on testattu perusteellisesti ja kaikki virheet on korjattu.
Parhaat kƤytƤnnƶt white box -testauksessa
Parhaat kƤytƤnnƶt white box -testauksessa riippuvat siitƤ, minkƤ tyyppistƤ testausta olet tekemƤssƤ ja missƤ vaiheessa testausprosessia olet.
Koska suurin osa white box -testauksesta tapahtuu yksikkƶ- ja integrointitestauksen aikana, useimmat white box -testauksen parhaat kƤytƤnnƶt koskevat nƤitƤ vaiheita.
1. Maksimoi testien kattavuus
MƤƤritelmƤn mukaan on tƤrkeƤƤ maksimoida testien kattavuus white box -testauksessa, jotta varmistetaan, ettƤ suuri osa ohjelmistosta testataan tƤssƤ vaiheessa.
Voit tehdƤ tƤmƤn maksimoimalla polkujen ja haarojen kattavuuden ja kirjoittamalla testitapauksia, jotka tutkivat kaikki mahdolliset polut ja lopputulokset valmisteluvaiheessa.
2. Tarkista kƤyttƤytyminen ja suorituskyky
Kun kirjoitat testitapauksia valkoisen laatikon testauksessa, haluat luoda testitapauksia, jotka varmistavat, ettƤ jƤrjestelmƤ toimii odotetulla tavalla, sekƤ testitapauksia, jotka varmistavat jƤrjestelmƤn suorituskyvyn.
Sen lisƤksi, ettƤ tarkistat, ettƤ tietyt toiminnot johtavat tiettyihin tuloksiin, voit esimerkiksi tarkistaa, kuinka nopeasti jƤrjestelmƤ pystyy suorittamaan tietyt tehtƤvƤt tai kuinka eri muuttujat vaikuttavat suorituskykyyn.
3. Kirjoita testitapaukset toisistaan riippumatta
Jos haluat todentaa kaksi erillistƤ ominaisuutta, esimerkiksi jos koodiluokka on riippuvainen tietystƤ tietokannasta, luo abstrakti rajapinta, joka kuvastaa tƤtƤ tietokantayhteyttƤ, ja toteuta rajapinta pilkkuobjektilla tƤmƤn yhteyden testaamiseksi.
NƤin varmistetaan, ettƤ testitapaukset tarkistavat ne yhteydet, jotka haluat niiden tarkistavan, eikƤ jotain muuta.
4. Kattaa kaikki polut ja silmukat
Testauksen kattavuuden maksimointi tarkoittaa kaikkien mahdollisten polkujen kattamista, ehdollisten silmukoiden ja muiden koodissa olevien silmukkatyyppien huomioon ottamista.
Varmista, ettƤ suunnittelet testitapaukset, joissa tutkitaan kaikki mahdolliset polut ja varmistetaan, ettƤ silmukat kƤyttƤytyvƤt odotetulla tavalla syƶtteestƤ riippumatta.
7 virhettƤ ja sudenkuoppaa, kun
White box -testien toteuttaminen
Kun aloitat white box -testauksen, on tƤrkeƤƤ olla tietoinen joistakin yleisimmistƤ sudenkuopista, joihin kehittƤjƤt usein lankeavat white box -testausta tehdessƤƤn. Yleiset virheet white box -testauksessa voivat aiheuttaa viivƤstyksiƤ ja epƤtarkkuuksia, jotka voivat haitata ohjelmistojulkaisun laatua ja aikataulua.
1. Ajattelu, ettƤ white box -testausta ei tarvita.
Jotkut testaajat ajattelevat, ettƤ white box -testaus ei ole tarpeen, koska black box -testaus testaa kaikki ohjelmiston ulkoiset tuotokset, ja jos ne toimivat oikein, oletetaan, ettƤ myƶs jƤrjestelmƤn sisƤiset toiminnot toimivat.
Valkoisen laatikon testaus voi kuitenkin auttaa kehittƤjiƤ lƶytƤmƤƤn ongelmia ja virheitƤ, jotka eivƤt aina nƤy mustan laatikon testauksessa, ja se on tƤrkeƤƤ ohjelmistojƤrjestelmien turvallisuuden varmistamisessa.
Jos esimerkiksi ohjelmassa on muistivuoto, joka aiheuttaa suorituskyvyn heikkenemistƤ pitkiƤ aikoja ja jota mustalaatikkotestaus ei tutki, valkolaatikkotestaus on ainoa vaihtoehto koodin lƤpikƤymiseen ja ongelman lƶytƤmiseen ennen laajaa julkista julkaisua.
2. Suoritetaan kaikki white box -testaus manuaalisesti
Jotkut kehittƤjƤt saattavat ajatella, ettƤ white box -testaus on yhtƤ helppoa kuin black box -testaus.
White box -testaus on kuitenkin huomattavasti aikaa vievƤmpƤƤ, ja kehittƤjƤt, jotka yrittƤvƤt suorittaa white box -testauksen tƤysin manuaalisesti, saattavat huomata, ettƤ manuaalisia tarkastuksia on mahdotonta suorittaa haluttujen standardien mukaisesti tai maksimoiden testien kattavuus.
3. Testaajien osoittaminen testitapausten suorittamiseen
Valkoisen laatikon testauksen tulisi olla tƤysin kehittƤjien, ohjelmistosuunnittelijoiden ja sellaisten henkilƶiden suorittamaa, jotka ymmƤrtƤvƤt tƤysin ohjelmistojƤrjestelmƤn sisƤisen toiminnan.
Jotkut kehittƤjƤt luulevat, ettƤ he voivat siirtƤƤ white box -testauksen QA-testaajille, kun he ovat itse kirjoittaneet testitapaukset, mutta tƤmƤ johtaa vain huonoon toteutukseen ja heikentƤƤ dokumentoinnin laatua.
4. Testauksen kiirehtiminen
Ohjelmistotestaus on pitkƤ ja aikaa vievƤ prosessi, ja jotkut kehittƤjƤt saattavat joutua kiirehtimƤƤn white box -testauksen lƤpi siirtyƤkseen seuraavaan kehitysvaiheeseen. On tƤrkeƤƤ varata riittƤvƤsti aikaa ja resursseja white box -testaukseen, jotta varmistetaan, ettƤ kehittƤjƤt eivƤt tunne kiirettƤ ja ettƤ heillƤ on riittƤvƤsti aikaa maksimoida testien kattavuus.
5. Huono dokumentointi
Asianmukainen dokumentointi ennen testausta, testauksen aikana ja testauksen jƤlkeen varmistaa, ettƤ kaikilla ohjelmistokehitykseen ja testaukseen osallistuvilla on kƤytettƤvissƤƤn oikeat tiedot oikeaan aikaan.
Varmista, ettƤ jokainen kehitystiimin jƤsen osaa kirjoittaa selkeƤƤ dokumentaatiota ja raportoida white box -testauksen tulokset.
6. Automaatiotyƶkalujen virheellinen kƤyttƶ
Automaatiotyƶkalut voivat tehdƤ white box -testauksesta helppoa, mutta on tƤrkeƤƤ varmistaa, ettƤ koko tiimisi ymmƤrtƤƤ, mitƤ automaatiotyƶkaluja kƤytƤt ja miten niitƤ kƤytetƤƤn.
Eri tyƶkalut soveltuvat erityyppiseen testaukseen, joten on tƤrkeƤƤ valita valkoisen laatikon testaukseen sopivat automaatiotyƶkalut ja oppia kƤyttƤmƤƤn niiden ominaisuuksia oikein.
Jotkin tyƶkalut eivƤt esimerkiksi integroi automaatiota, vaan keskittyvƤt sen sijaan tiedonkeruuseen ja tikettien jƤrjestƤmiseen, mikƤ ei ole lƤheskƤƤn ihanteellista automatisoidulle testaukselle. PƤinvastoin, ZAPTESTin kaltaiset tƤysimittaiset tyƶkalut kattavat koko testausprosessin sellaisten ominaisuuksien avulla kuin Any Task Automation, joten ne soveltuvat tehokkaampaan white box -testaukseen.
7. Ei tyƶskentelyƤ laadunvarmistusryhmƤn kanssa
Vaikka kehittƤjƤt suunnittelevat ja suorittavat white box -testauksen, se ei tarkoita, ettƤ QA-ryhmƤn ei pitƤisi osallistua siihen millƤƤn tavalla.
On tƤrkeƤƤ vƤlittƤƤ valkoisen laatikon testauksen tulokset QA-ryhmƤlle, jotta he ymmƤrtƤvƤt, mitƤ tƤhƤn mennessƤ on testattu ja miten valkoisen laatikon testauksen tulokset voivat vaikuttaa siihen, miten QA-ryhmƤ lƤhestyy mustan laatikon testausta.
Jos et ota QA-ryhmƤƤ mukaan, eri osastojen vƤlille syntyy mahdollisesti epƤsuhta, mikƤ johtaa huonoon viestintƤƤn ja huonompaan palautteeseen testauksen myƶhemmƤssƤ vaiheessa. Lopputuloksena on lopputuotteen huomattavasti alhaisempi laatutaso.
Valkoisen laatikon testien tulostyypit
Kun suoritat white box -ohjelmistotestausta, saat erilaisia tuloksia suorittamiesi testien tuloksista riippuen. NƤiden white box -testien tulosten ymmƤrtƤminen voi auttaa sinua ymmƤrtƤmƤƤn, mitƤ toimia sinun on toteutettava seuraavaksi.
1. Testitulokset
Valkoisen laatikon testien tulokset kertovat, onko sinun jatkettava testausta, onko korjattavia virheitƤ ja onko kukin yksittƤinen testitapaus lƤpƤissyt vai epƤonnistunut. Perusteellinen dokumentointi on vƤlttƤmƤtƶntƤ, koska se auttaa kehittƤjiƤ ja testaajia ymmƤrtƤmƤƤn white box -testauksen tuloksia.
2. Viat
White box -testauksessa voidaan havaita virheitƤ, ja joskus white box -testien tuloksena on virheitƤ ja vikoja.
Jos ohjelmistojƤrjestelmƤ ei kƤyttƤydy odotetulla tavalla white box -testauksen aikana, se voi olla merkki siitƤ, ettƤ ohjelmassa on vakavia vikoja, jotka on korjattava ennen kuin kehittƤmistƤ ja testausta jatketaan.
3. Testiraportit
Testausraportit ovat raportteja, jotka kehittƤjƤt ja testaajat laativat ohjelmistotestauksen aikana ja sen jƤlkeen.
Ne sisƤltƤvƤt yksityiskohtaiset tiedot testauksen tuloksista, mukaan lukien testitapaukset, jotka lƤpƤisivƤt ja jotka eivƤt lƤpƤisseet testauksen, testauksen aikana havaitut virheet ja suositukset seuraaviksi vaiheiksi.
KehittƤjƤt kƤyttƤvƤt testiraportteja kommunikoidakseen muiden kehittƤjien kanssa, joiden tehtƤvƤnƤ voi olla testauksen aikana havaittujen vikojen ja virheiden korjaaminen.
EsimerkkejƤ white box -testeistƤ
Valkoisen laatikon testauksen avulla kehittƤjƤt voivat tarkistaa, ettƤ ohjelmistojƤrjestelmƤn sisƤinen rakenne toimii niin kuin sen pitƤisi, riippumatta jƤrjestelmƤn ulkoisista tuloksista ja tuotoksista.
Alla olevat esimerkit havainnollistavat, miten white box -testaus voi auttaa kehittƤjiƤ varmistamaan ohjelmiston sisƤiset toiminnot.
1. Esimerkki sƤhkƶisen kaupankƤynnin rekisterƶintisivusta
Yksi esimerkki white box -testauksesta on se, miten kehittƤjƤt testaavat verkkosivuston toimintoja. Jos yritƤt testata sƤhkƶisen kaupankƤynnin verkkosivuston rekisterƶintisivua, white box -testauksen avulla kehittƤjƤt voivat ymmƤrtƤƤ, toimivatko rekisterƶintiin liittyvƤt toiminnot ja luokat niin kuin niiden pitƤisi, kun rekisterƶintitoiminto suoritetaan.
TƤmƤ sisƤltƤƤ erityisesti kaikki kƤyttƤjƤn syƶttƤmƤt tiedot ja arvioi lomakkeen taustalla olevat parametrit, mukaan lukien pƤivƤmƤƤrƤt, jotka ovat voimassa ja jotka eivƤt ole voimassa, sekƤ sen, mitƤ lomake pitƤƤ laillisena sƤhkƶpostiosoitteena.
TƤmƤn jƤlkeen ryhmƤ syƶttƤƤ sarjan merkkijonoja, jotka testaavat lomaketta, joista osa on suunniteltu epƤonnistumaan ja osa onnistumaan, ennen kuin tulokset arvioidaan suhteessa ennustettuihin tuloksiin.
Mustan laatikon testauksessa taas tarkistetaan vain, toimiiko sivu itsessƤƤn, eikƤ analysoida sen enempƤƤ miksi tai miten.
2. Laskin esimerkki
Sovelluslaskurit ovat toinen esimerkki white box -testauksesta.
Jos olet luomassa laskinta, jota kƤytetƤƤn osana sovellusta, mustan laatikon testaajat testaavat yksinkertaisesti, onko laskimen tulostus oikein, kun laskinta kƤytetƤƤn tarkoitetulla tavalla.
Valkoisen laatikon testaajat tarkistavat laskimen sisƤiset laskutoimitukset tarkistaakseen, miten tulos on laskettu ja onko se oikea. TƤmƤ on hyƶdyllisempƤƤ monimutkaisemmissa laskutoimituksissa, joissa on useita vaiheita, kuten verojen laskemisessa. Testaajat tutkivat koodia nƤhdƤkseen, mitƤ vaiheita laskin suorittaa ja missƤ jƤrjestyksessƤ vaiheet ovat, ennen kuin he nƤkevƤt lopputuloksen jokaisen vaiheen jƤlkeen.
Jos laskimen syƶttƶ on (7*4) – 6 ja lƤhtƶ 22, tƤmƤ on oikein, ja mustan laatikon testaus lƤpƤisee tƤmƤn testin. TƤmƤ johtuu kuitenkin siitƤ, ettƤ 7*4 = 28 ja 28 – 6 on 22. White box -testaus voisi paljastaa, ettƤ ohjelmisto lƶysi tƤmƤn tuloksen suorittamalla 7*4 = 32 ja 32 – 6 = 22, joista kumpikaan ei ole oikein.
TƤmƤ parempi nƤkemys osoittaa, ettƤ laskelma on tarkka jokaisen tietyn vaiheen jƤlkeen, lƶytƤƤ vaiheen, jossa se ei ehkƤ ole tarkka, ja ratkaisee ongelman nopeammin, koska testaaja nƤkee selvƤsti, missƤ ongelma ilmenee.
Virheiden ja vikojen tyypit valkoisen laatikon testauksessa
Valkoisen laatikon testauksen aikana on mahdollista tunnistaa ja paikantaa virheitƤ, jotka voivat vaikuttaa siihen, miten jƤrjestelmƤ toimii konepellin alla. NƤmƤ viat voivat vaikuttaa ulkoisiin toimintoihin tai ne voivat vaikuttaa suorituskykyyn tai luotettavuuteen.
Alla on lueteltu joitakin yleisimpiƤ virheitƤ ja vikoja, joita esiintyy white box -testauksen aikana.
1. Loogiset virheet
Loogisia virheitƤ syntyy white box -testauksessa, koska white box -testit paljastavat alueita, joissa ohjelma ei toimi loogisesti tai joissa ohjelmistokoodin toimintoja ja ehtoja kƤytetƤƤn vƤƤrin.
Loogiset virheet voivat ilmetƤ jƤrjestelmƤvirheinƤ tai yksinkertaisesti johtaa odottamattomaan kƤyttƤytymiseen ja tuloksiin.
2. Suunnitteluvirheet
Valkoisen laatikon testaus voi auttaa kehittƤjiƤ tunnistamaan koodin suunnitteluvirheet. SuunnitteluvirheitƤ syntyy, kun ohjelmiston loogisen kulun ja ohjelmiston todellisen toteutuksen vƤlillƤ on ero. Ne voivat johtaa odottamattomaan kƤyttƤytymiseen ja suorituskykyyn liittyviin virheisiin.
3. Kirjoitusvirheet
Kirjoitus- ja syntaksivirheet ovat virheitƤ, jotka johtuvat inhimillisestƤ erehdyksestƤ – esimerkiksi siitƤ, ettƤ kehittƤjƤ on kirjoittanut tietyn lauseen vƤƤrin tai lisƤnnyt koodiriville vƤƤrƤt vƤlimerkit. TƤllaiset pienet virheet voivat johtaa rikkinƤisiin toimintoihin ja lausekkeisiin, joita ohjelmisto ei pysty lukemaan, mikƤ voi aiheuttaa suuria virheitƤ jƤrjestelmƤssƤ.
Yleiset valkoisen laatikon testauksen mittarit
Kun teet white box -testausta, yleiset testausmittarit voivat auttaa sinua mittaamaan, kuinka onnistuneita ja kattavia white box -testit ovat, sekƤ ymmƤrtƤmƤƤn kehittƤjien tyƶn laatua.
Testauksen mittarit vaikuttavat kehitysprosessiin, koska niiden avulla voidaan tunnistaa parannuskohteita tai ohjata testausprosessia eteenpƤin.
1. Koodin kattavuus
Yksi valkoisen laatikon testauksen tƤrkeimmistƤ ominaisuuksista on se, ettƤ sen pitƤisi kattaa mahdollisimman suuri osa koodista, ja voit mitata koodin kattavuutta mittaavilla mittareilla, kuinka paljon koodia olet kattanut.
Koodin kattavuusmittarit osoittavat, kuinka suuren osan sovelluksen kokonaiskoodista olet varmistanut white box -testauksen avulla. YleensƤ kehittƤjƤt pyrkivƤt kattamaan mahdollisimman 100 prosenttia ohjelmistokoodista white box -testauksella.
Koodin kattavuus voidaan jakaa eri mittareihin, kuten polkujen, segmenttien, lausekkeiden ja haarojen kattavuuteen.
Yhdistettyjen ehtojen kattavuus on toisenlainen koodin kattavuuden mittari, jossa tarkistetaan, ettƤ jokainen ehtojen joukkoihin sisƤltyvƤ ehto on tarkistettu useiden polkujen ja polkujen yhdistelmien ohella.
2. VirheitƤ koskevat mittarit
Vikamittarit kertovat, kuinka monta virhettƤ on lƶydetty, kuinka hyvin white box -testaus tunnistaa virheet ja kuinka suuri osa koodista lƤpƤisee white box -testauksen tai ei lƤpƤise sitƤ.
Virhemittarit voidaan esittƤƤ virheiden lukumƤƤrƤnƤ tuhatta koodiriviƤ kohti tai ohjelman kokonaisvirheiden lukumƤƤrƤnƤ. Vaikka vikojen vƤhƤinen mƤƤrƤ saattaa vaikuttaa myƶnteiseltƤ, kehittƤjien on varmistettava, ettƤ tƤmƤ ei johdu siitƤ, ettƤ virheet jƤƤvƤt testauksessa huomaamatta.
3. Testin suorittaminen
Testien suoritusmittarit auttavat kehittƤjiƤ nƤkemƤƤn nopeasti, kuinka suuri osa kaikista testeistƤ on tƤhƤn mennessƤ suoritettu ja kuinka monta testiƤ on vielƤ suorittamatta. Tekstin suoritusmittarit auttavat ohjelmistotiimejƤ ymmƤrtƤmƤƤn, kuinka pitkƤllƤ white box -testauksen edistyminen on ja sujuuko automatisoidut ohjelmistotestit odotetulla tavalla.
On kuitenkin mahdollista saada sekƤ vƤƤriƤ positiivisia ettƤ vƤƤriƤ negatiivisia tuloksia, jotka voivat vaikuttaa tƤmƤn mittarin tarkkuuteen.
4. Testin kesto
Testauksen kestomittarit kertovat, kuinka kauan automaattisten testien suorittaminen kestƤƤ, mikƤ on erityisen tƤrkeƤƤ white box -testauksessa, koska automatisointi on vƤlttƤmƤtƶntƤ testien tehokkuuden ja kattavuuden maksimoimiseksi.
Testien kesto on usein ketterƤn ohjelmistokehityksen pullonkaula, joten sen ymmƤrtƤminen, kuinka kauan ohjelmistotestien suorittaminen kestƤƤ, voi auttaa kehitystiimejƤ nopeuttamaan kehitysprosessia.
On kuitenkin tƤrkeƤƤ muistaa, ettƤ testien kestoa koskevat mittarit eivƤt kerro mitƤƤn suoritettavien testien laadusta.
Valkoisen laatikon testaustyƶkalut
Tyƶkalut ja teknologia voivat tehdƤ white box -testauksesta huomattavasti tarkempaa, tehokkaampaa ja kattavampaa. White box -testaustyƶkalut voivat auttaa ohjelmistosuunnittelijoita automatisoimaan white box -testauksen, tallentamaan ja dokumentoimaan white box -testausprosessin sekƤ hallinnoimaan white box -testausta alusta loppuun.
5 parasta ilmaista valkoisen laatikon testaustyƶkalua
Jos et halua vielƤ investoida kalliisiin white box -testaustyƶkaluihin, voit kokeilla lukuisia ilmaisia white box -testaustyƶkaluja verkossa maksamatta mitƤƤn.
Ilmaiset testaustyƶkalut eivƤt aina tarjoa kaikkia samoja toimintoja kuin yritystyƶkalut, mutta ne ovat hyvƤ lƤhtƶkohta valkoisen laatikon testauksen aloittelijoille, ja ne voivat auttaa kehitystiimejƤ ymmƤrtƤmƤƤn paremmin, mitƤ tyƶkaluja ja tekniikoita ne tarvitsevat.
1. ZAPTEST ILMAINEN painos
ZAPTEST on ohjelmistotestaustyƶkalu ja robottiprosessien automaatio-ohjelmisto, jonka avulla kehittƤjƤt ja QA-testaajat voivat automatisoida sekƤ white box – ettƤ black box -testauksen.
ZAPTESTin ilmaisversio mahdollistaa useita virtuaalisia kƤyttƤjiƤ, useita iteraatioita ja kƤyttƤjƤfoorumituen. Sovellus toimii sekƤ paikallisten ettƤ ulkoisten tietolƤhteiden kanssa ja integroituu HP ALM:n, Rallyn ja JIRAn kanssa. KƤyttƤjƤt, jotka pitƤvƤt ZAPTESTin ilmaisesta tarjonnasta ja haluavat nƤhdƤ enemmƤn yrityksen tarjonnasta, voivat myƶs tiedustella pƤivitystƤ yritysversioon, kun se on valmis.
2. Bugzilla
Bugzilla on erittƤin suosittu avoimen lƤhdekoodin ohjelmistotestityƶkalu, jonka avulla kehittƤjƤt voivat seurata ohjelmistossa olevia vikoja ja puutteita sekƤ hallita vikojen elinkaarta.
Bugzilla helpottaa vikojen jakamista kehittƤjille, vikojen priorisointia ja tarkistamista sekƤ niiden sulkemista, kun ne on korjattu. Bugzilla on loistava tyƶkalu tiimeille, jotka yrittƤvƤt vielƤ standardoida lƤhestymistapaansa vikailmoituksiin, ja sen kƤyttƶ on tƤysin ilmaista.
3. OpenGrok
OpenGrok on avoimen lƤhdekoodin koodiselain ja hakukone koodipohjalle. Se on yhteensopiva Java-, C++-, JavaScript- ja Python-koodin sekƤ muiden ohjelmointikielten kanssa.
Jos haluat navigoida nopeasti laajassa koodipohjassa white box -testauksen aikana, OpenGrok on tƤysin ilmainen ja helppokƤyttƶinen.
4. SQLmap
SQLmap on toinen avoimen lƤhdekoodin tyƶkalu, jota pidetƤƤn lƤhes vƤlttƤmƤttƶmƤnƤ white box -testauksessa. SQLmap sƤƤtelee SQL-injektiovirheiden hyƶdyntƤmistƤ ja havaitsemista.
SQLmap on itseƤƤn “tunkeutumistestaustyƶkaluksi” kutsuva tyƶkalu, joka voi auttaa white box -testaajia tunnistamaan ja paikantamaan lƤhdekoodin tietoturvavirheet ja korjaamaan ne ennen jatkamista.
5. Emma
Emma on avoimen lƤhdekoodin tyƶkalupakki, jolla voit mitata koodin kattavuutta, jos tyƶskentelet Javalla. Se on erittƤin nopea tapa selvittƤƤ koodin kattavuus nopeasti ja seurata, kuinka paljon koodia kukin kehitystiimin jƤsen on kattanut yksilƶllisesti.
Emma tukee luokkien, menetelmien, rivien ja peruslohkojen kattavuutta, ja se on tƤysin Java-pohjainen.
5 parasta yritystason white box -testaustyƶkalua
Jos etsit tyƶkaluja, jotka tarjoavat enemmƤn toimintoja tai parempaa tukea, yritysten white box -testaustyƶkalut saattavat sopia paremmin kehitystiimillesi.
1. ZAPTEST ENTERPRISE painos
ZAPTESTin yritysversio on ilmaisen ZAPTESTin parannettu versio. TƤssƤ versiossa kƤyttƤjƤt voivat hyƶdyntƤƤ rajattomasti OCR-malleja, rajattomasti iteraatioita ja rajattomasti VBScript- ja JavaScript-skriptejƤ.
ZAPTESTin yritysversio tarjoaa kattavamman tyƶkalupaketin kehitystiimeille, jotka haluavat siirtyƤ automatisointiin, ja yritysversio sisƤltƤƤ myƶs asiantuntijatukea, jotta tiimisi saa kaiken mahdollisen irti ZAPTESTin ohjelmistotestauksen automaatio- ja RPA-teknologiasta.
2. Fiddler
Fiddler on Telerikin tarjoama tyƶkalupaketti, joka on tarkoitettu verkkosovellusten white box -testaukseen. Fiddler voi kirjata kaiken HTTP-liikenteen jƤrjestelmƤsi ja internetin vƤlillƤ ja arvioida asetettuja taukopisteitƤ sekƤ sƤƤtƤƤ lƤhteviƤ ja saapuvia tietoja. Se on saatavana eri muodoissa budjetin ja vaatimusten mukaan, joten Fiddler-painos lƶytyy lƤhes kaikille joukkueille.
3. HP-vahvistus
HP Fortify, joka tunnettiin aiemmin nimellƤ Fortify, on toinen tietoturvatestaustyƶkalu, joka tarjoaa kattavia tietoturvaratkaisuja white box -testaukseen. Fortify-tyƶkalupakettiin kuuluu Fortify Source Code Analysis -tyƶkalu, joka skannaa lƤhdekoodisi automaattisesti haavoittuvuuksien varalta, jotka voivat jƤttƤƤ sovelluksesi alttiiksi verkkohyƶkkƤyksille.
4. ABAP-yksikkƶ
ABAP Unitin yritysversion avulla ohjelmistokehittƤjƤt voivat suorittaa sekƤ manuaalisen ettƤ automaattisen yksikkƶtestauksen nopeasti ja yksinkertaisesti. KehittƤjƤt kirjoittavat yksikkƶtestejƤ ABAP-sovellukseen ja kƤyttƤvƤt nƤitƤ testejƤ koodin toimintojen tarkistamiseen ja virheiden tunnistamiseen yksikkƶtestauksessa.
Ohjelmistotiimit, jotka haluavat kokeilla tƤtƤ tyƶkalua, voivat aloittaa ABAP Unitin ilmaisella versiolla ja siirtyƤ sitten yritysversioon.
5. LDRA
LDRA on oma tyƶkalupaketti, jota voidaan kƤyttƤƤ lausekkeiden, haarojen ja pƤƤtƶsten kattavuuteen white box -testauksessa. Se on erinomainen tyƶkalu, jos haluat tarkistaa, ettƤ lƤhdekoodisi tƤyttƤƤ standardien noudattamista, jƤljittƤmistƤ ja koodihygieniaa koskevat vaatimukset.
Milloin sinun pitƤisi kƤyttƤƤ yritystƤ
vs freemium white box -testaustyƶkalut?
SekƤ yritysten ettƤ ilmaisohjelmistojen testaustyƶkaluilla on paikkansa kaikissa nykyaikaisissa ohjelmistokehitystiimeissƤ. Kun tiimisi kasvaa ja automatisoidusta testauksesta tulee yhƤ tƤrkeƤmpƤƤ valkoisen laatikon testauksen lƤhestymistavassa, haluat todennƤkƶisesti siirtyƤ tyƶskentelemƤstƤ ensisijaisesti ilmaisten testaustyƶkalujen kanssa yritystyƶkaluihin, jotka tarjoavat enemmƤn toimintoja ja rajattomasti kƤyttƶmahdollisuuksia.
On kuitenkin tiettyjƤ tilanteita, joissa freemium-tyƶkalut voivat olla sopivampia kuin yritystyƶkalut.
Monet kehittƤjƤt aloittavat freemium-tyƶkaluilla kokeillessaan uusia ominaisuuksia ja tekniikoita ensisijaisesti arvioidakseen, sopivatko nƤmƤ tekniikat heidƤn tiimilleen, ennen kuin he investoivat yritystekniikkaan.
Voit myƶs kokeilla yritystyƶkalujen, kuten ZAPTESTin, ilmaisia versioita, jotta voit kokeilla niitƤ ennen ostamista ja saada lisƤtietoja yritystyƶkalujen tarjoamista mahdollisuuksista.
Jotkut freemium-tyƶkalut, kuten Emma ja Bugzilla, ovat erikoistuneet kapeisiin mutta tƤrkeisiin ominaisuuksiin, jotka tarjoavat jatkuvia etuja jopa niille ohjelmistotiimeille, jotka ovat valmiita maksamaan yritysteknologioista.
White box -testaus: tarkistuslista, vinkkejƤ ja temppuja
Kun olet valmis suorittamaan white box -testauksen, varmista, ettƤ sinulla on kaikki tarvittava ennen aloittamista. Alla on luettelo asioista, jotka on hyvƤ muistaa ennen white box -testauksen aloittamista, jotta voit maksimoida testien kattavuuden ja parantaa white box -testien tulosten tarkkuutta.
1. KƤytƤ automaatiotyƶkaluja
Automaatiotyƶkalut voivat nopeuttaa huomattavasti white box -testausprosessia sekƤ vƤhentƤƤ virheiden mƤƤrƤƤ ja lisƤtƤ yleistƤ tarkkuutta.
LƤhes kaikki ohjelmistotiimit kƤyttƤvƤt nykyƤƤn jonkinasteista automaatiota white box -testaukseen, joten eri automaatiotyƶkalujen ja -tekniikoiden kokeileminen ennen white box -testauksen aloittamista voi auttaa sinua valitsemaan haluamasi tyƶkalut ennen testauksen aloittamista.
2. Tavoittele 100 %:n testikattavuutta
Et luultavasti saavuta tavoitettasi 100 %:n testikattavuudesta, mutta on parasta pyrkiƤ mahdollisimman lƤhelle tƤtƤ lukua, kun suoritat white box -testausta.
KƤytƤ testin kattavuuden tyƶkaluja yksittƤisten mittareiden, kuten polkujen ja haarojen kattavuuden, seuraamiseen ja mittaamiseen ja varmista, ettƤ kaikki ohjelmiston tƤrkeimmƤt polut ja haarat on katettu white box -testauksen aikana.
3. Selkeiden testiraporttien laatiminen
Kuten muissakin ohjelmistotestauksen muodoissa, varmista, ettƤ tiimisi osaa laatia tarkat ja selkeƤt testiraportit kunkin testausvaiheen jƤlkeen.
Testausraportti on laadittava helposti ymmƤrrettƤvƤƤn muotoon, ja sen on sisƤllettƤvƤ yksityiskohtaiset tiedot testauksen lƤhestymistavasta sekƤ yhteenveto kunkin suoritetun testitapauksen tuloksista ja tuloksista. Loppuraportissa olisi perusteltava toteutetut toimet ja annettava suosituksia seuraavista toimista.
4. Mittaa menestystƤsi testauksen mittareilla
Testausmittarit auttavat ohjelmistotiimejƤ seuraamaan ja tallentamaan white box -testauksen edistymistƤ ja tarjoavat arvokasta tietoa, jota voidaan hyƶdyntƤƤ tulevissa kehitysprosesseissa.
On tƤrkeƤƤ, ettƤ kehittƤjƤt kƤyttƤvƤt mittareita ymmƤrtƤƤkseen, kuinka tehokasta heidƤn suorittamansa testaus on ja kuinka puhdasta heidƤn alkuperƤinen koodinsa oli, jotta he voivat parantaa tyƶtƤƤn tulevaisuudessa.
White box -testaus:
PƤƤtelmƤ
White box -testaus on ohjelmistotekniikassa olennainen ohjelmistotestauksen tyyppi, jolla tarkistetaan ohjelmistosovelluksen lƤhdekoodin sisƤinen rakenne ja logiikka.
YhdessƤ mustan laatikon testauksen kanssa valkoisen laatikon testauksella varmistetaan, ettƤ ohjelmisto toimii odotetulla tavalla ja ettƤ sisƤinen koodi on loogista, puhdasta ja tƤydellistƤ.
White box -testausta tehdƤƤn useimmiten yksikkƶ- ja integrointitestauksessa, ja sen suorittavat aina kehittƤjƤt ja ohjelmistosuunnittelijat, jotka tuntevat tƤysin ohjelmiston sisƤisen koodin.
Vaikka osa white box -testauksesta voidaan tehdƤ manuaalisesti, nykyƤƤn suuri osa white box -testauksesta on automatisoitua, koska white box -testauksen automatisointi parantaa nopeutta, tehokkuutta ja kattavuutta.
Usein kysytyt kysymykset ja resurssit
Jos haluat oppia lisƤƤ white box -testauksesta, voit tutustua moniin ilmaisiin verkkolƤhteisiin. Voit kƤyttƤƤ videoita, kirjoja ja muita resursseja opetellaksesi itsellesi, miten white box -testaus suoritetaan, ja varmistaaksesi, ettƤ white box -testausstandardit noudattavat parhaita kƤytƤntƶjƤ.
1. Parhaat kurssit white box -testausautomaatiosta
Jos haluat oppia lisƤƤ white box -testausautomaatiosta, voit kƤydƤ ohjelmistotestauksen ja white box -testauksen kurssin. Jotkut nƤistƤ kursseista ovat akkreditoituja ja tarjoavat virallisia pƤtevyyksiƤ, kun taas toiset ovat epƤvirallisia verkkokursseja, jotka on suunniteltu auttamaan kehittƤjiƤ ja ohjelmistotestaajia, jotka haluavat parantaa tietƤmystƤƤn tietystƤ aiheesta.
Joitakin parhaista nykyƤƤn verkossa saatavilla olevista white box -testauskursseista ovat:
2. MitkƤ ovat viisi tƤrkeintƤ haastattelukysymystƤ white box -testausautomaatiosta?
Jos valmistaudut haastatteluun, jossa saatat keskustella white box -testauksesta, white box -tekniikoista ja automaatiotyƶkaluista, on tƤrkeƤƤ, ettƤ tiedƤt.
- MitƤ eroa on valkoisen laatikon testauksella ja mustan laatikon testauksella?
- Miksi white box -testaus on tƤrkeƤƤ?
- Millaisia erilaisia lƤhestymistapoja white box -testaukseen voi kƤyttƤƤ?
- MitƤ prosesseja white box -testaukseen liittyy ja miten voimme parantaa niitƤ?
- MitƤ tyƶkaluja ja teknologioita voit kƤyttƤƤ nopeuttaaksesi tai tarkentaaksesi white box -testausta?
3. Parhaat YouTube-oppaat white box -testauksesta
Jos haluat oppia lisƤƤ valkolaatikkotestauksesta, YouTube-oppaiden katselu voi auttaa sinua ymmƤrtƤmƤƤn, miten valkolaatikkotestaus toimii, ja nƤkemƤƤn visuaalisia selityksiƤ valkolaatikkotestaukseen liittyvistƤ prosesseista ja lƤhestymistavoista.
Joitakin informatiivisimpia YouTube-oppaita verkossa on nyt muun muassa:
- Udacity: Udacity: White Box Testing Esimerkki
- Guru99: MikƤ on White Box -testaus?
- White Box vs. Black Box -testaus
- Valkoisen laatikon testaustekniikat
- Ohjelmistotestauksen mentori: White Box Testing: MikƤ on White Box Testing?
4. Miten white box -testejƤ yllƤpidetƤƤn
Ohjelmistotestien yllƤpidolla varmistetaan, ettƤ suoritetut testit ovat kerta toisensa jƤlkeen perusteellisia ja tarkoituksenmukaisia. On tƤrkeƤƤ yllƤpitƤƤ kaikentyyppisiƤ ohjelmistotestejƤ sekƤ mustalaatikko- ettƤ valkolaatikkotestauksessa, koska testejƤ suorittava koodi muuttuu jatkuvasti jokaisen bugikorjauksen ja iteraation myƶtƤ. TƤmƤ tarkoittaa, ettƤ testiskriptien on muututtava sen mukana.
Valkoisen laatikon testien yllƤpitƤminen edellyttƤƤ, ettƤ testausautomaatiokehys pidetƤƤn ajan tasalla ja ettƤ kƤytetƤƤn prosesseja, joilla varmistetaan, ettƤ testit ja testitapaukset pƤivitetƤƤn sƤƤnnƶllisesti.
Voit tehdƤ tƤmƤn seuraavasti:
YllƤpidon sisƤllyttƤminen testisuunnitteluun:
Kun otat huomioon white box -testauksen tulevaisuuden, kun rakennat ja suunnittelet white box -testejƤ, testien yllƤpito helpottuu tulevaisuudessa.
Mahdollistaa tiimien vƤlisen selkeƤn viestinnƤn:
Varmista, ettƤ kaikilla kehitystiimisi jƤsenillƤ on useita viestintƤkanavia, jotta koodiin tehdyt muutokset voidaan heijastaa nopeasti testeihin heti, kun niitƤ on tehty.
Ole sopeutumiskykyinen:
Joskus saatat tehdƤ koodiin muutoksia, joita et ole suunnitellut. Varmista, ettƤ tiimisi osaa mukautua nopeasti nƤihin muutoksiin ja ettƤ sillƤ on taidot seurata muutoksia testauksessa.
Arvioi testauskƤytƤnnƶt jatkuvasti uudelleen:
Testausprotokollat, jotka otit kƤyttƶƶn testauksen alussa, eivƤt vƤlttƤmƤttƤ ole enƤƤ sopivia, kun ohjelmistoosi on tehty erilaisia muutoksia ja parannuksia. Arvioi testauskƤytƤntƶjƤsi uudelleen sƤƤnnƶllisin vƤliajoin varmistaaksesi, ettƤ ne sopivat edelleen hyvin.
5. Parhaat kirjat white box -testauksesta
White box -testaus on syvƤllinen aihe, jonka hallitseminen voi viedƤ vuosia. Jos haluat tulla asiantuntijaksi nykyaikaisessa white box -testauksessa, voit lukea kehittƤjien, tutkijoiden ja insinƶƶrien kirjoittamia white box -testausta kƤsitteleviƤ kirjoja.
Parhaita kirjoja white box -testauksesta ja testiautomaatiosta ovat muun muassa seuraavat:
- Ohjelmistotestauksen taito, kolmas painos by Glenford J. Myers, Corey Sandler, Tom Badgett, Todd M. Thomas.
- Ohjelmistotestaus: Jorgensen: KƤsityƶlƤisen lƤhestymistapa, neljƤs painos.
- Kuinka rikkoa ohjelmistoja: James Whittaker: KƤytƤnnƶn opas testaukseen.
- Dan Mosleyn ja Bruce Poseyn Just Enough Software Test Automation -teos
NƤitƤ kirjoja pitƤisi lƶytyƤ joistakin kirjakaupoista ja kirjastoista sekƤ verkosta. LƶydƤt myƶs muuta luettavaa ja oppimateriaalia hyvien ohjelmistotestauskurssien ja -ohjelmien lukulistoista.