thumb|Ohjelmiston testaamista

Ohjelmiston testaaminen tai ohjelmistotestaus on ohjelmistotekniikassa tapa tutkia ohjelman virheettömyyttä ja muita laatuominaisuuksia sitä yksinkertaisesti sellaisenaan käyttämällä tai erityisiä testaamistekniikoilla käyttäen. Testaamisen vastakohta on ohjelman oikeaksi todistaminen, joka tosin tarkastelee vain ohjelman virheettömyyttä.

Testaaminen tarjoaa asiakkaalle tietoa testattavan tuotteen tai palvelun laadusta.Exploratory Testing, Cem Kaner, Florida Institute of Technology, Quality Assurance Institute Worldwide Annual Software Testing Conference, Orlando, FL, November 2006 Ohjelmistotestaaminen tarjoaa myös objektiivisen ja erillisen näkökulman ohjelmistoon, jonka avulla asiakas voi ymmärtää ohjelmiston implementoinnin riskejä. Testaustekniikka sisältää ohjelmiston suorittamista löytääkseen siitä ohjelmointivirheitä, mutta tekniikka ei rajoitu ainoastaan siihen. Ohjelmistotestaamisella voidaan myös osoittaa, että (1) ohjelmisto/palvelu/tuote täyttää kaupalliset ja tekniset vaatimukset, (2) ohjelmisto toimii oletetusti ja (3) ohjelmisto voidaan implementoida halutuilla ominaisuuksilla.

Ohjelmiston testaaminen voidaan suorittaa missä tahansa kehitysvaiheessa, riippuen valitusta testaustavasta. Suurin osa testauksesta kuitenkin suoritetaan, kun kaikki ohjelmistovaatimukset ovat määritelty ja ohjelmointivaihe on suoritettu.

Ohjelmistotestaamisen aiheet

Tavoite Testaamisen päätavoitteena on havaita ohjelmistossa ilmenevät häiriöt, jotta viat voidaan paljastaa ja korjata. Tavoite on hankalasti toteutettavissa: Testaaminen ei voi vahvistaa, että ohjelmisto toimii oikein kaikissa tilanteissa tai olosuhteissa, vaan se osoittaa pelkästään, että se toimii oikein tietynlaisessa ympäristössä. Ohjelmiston testaamisen tavoite käsittää usein koodin tutkimista sekä koodin läpiajoa erilaisissa ympäristöissä ja tilanteissa, siis tekeekö koodi, mitä sen pitäisi ja tarvitsee tehdä. Nykyisessä ohjelmistokehityksessä testaava organisaatio saattaa olla eri kuin ohjelmiston kehittäjä.

Viat ja häiriöt Kaikki ohjelmistoviat eivät johdu koodausvirheistä. Yksi yleinen kalliiden vikojen aiheuttaja on vaatimuksien välinen kuilu. Näitä ovat esimerkiksi tuntemattomat vaatimukset, jotka johtavat virheisiin, koska niitä ei ole otettu huomioon.

Ohjelmistoviat ilmenevät seuraavasti. Ohjelmoija tekee ohjelmointivirheen, jonka seurauksena syntyy vika ohjelmakoodiin. Jos viallinen ohjelmakoodi ajetaan, joissain tilanteissa järjestelmä tuottaa vääriä tuloksia aiheuttaen häiriön. Section 1.1.2, Certified Tester Foundation Level Syllabus, International Software Testing Qualifications Board Kaikki viat eivät välttämättä johda häiriöihin ohjelmistossa. Esimerkiksi virheet suorittamattomassa koodissa eivät johda koskaan häiriöihin. Vika saattaa muuttua häiriöksi, kun ympäristö vaihtuu. Esimerkiksi, kun ohjelmaa ajetaan uudella sovellusalustalla, muutokset lähdekoodissa tai vuorovaikutuksessa toisenlaisen ohjelmiston kanssa. Yksi virhe saattaa johtaa useisiin häiriöihin laajalla alueella ohjelmistoa.

Yhteensopivuus Usein esiintyvä ohjelmistovian aiheuttaja on yhteensopivuus toisen ohjelman kanssa, uusi käyttöjärjestelmä ja yhä useammin web-selaimen uusi versio. Usein taaksepäin yhteensopivuuden puute aiheutuu, kun ohjelmoijat ovat ajatelleet ohjelmoida ohjelmistonsa uusimmalle versiolle tai käyttöjärjestelmälle yhteensopivaksi. Tästä koituva ei-haluttu seuraus on että viimeisin työ ei ole yhteensopiva aiemman ohjelmiston/laitteiston tai toisen tärkeän käyttöympäristön kanssa. Tätä voitaisiin pitää "ennalta ehkäisevänä strategiana", joka sopii hyvin yhteen Dave Gelperin ja William C. Hetzelin testivaiheeseen.

Dynaaminen testaus Dynaaminen testaus on koodin läpiajamista testitapauksilla. Se toteutetaan, kun ohjelmistoa käytetään ensimmäistä kertaa. Dynaamista testausta voidaan suorittaa, vaikka ohjelma ei ole valmis.

Syöte yhdistelmät ja esiehdot Perustava ongelma ohjelmistotestaamisessa on, että kaikkien mahdollisten syötteiden ja esiehtojen testaaminen ei ole toteutettavissa, edes yksinkertaisten tuotteiden kohdalla. Tämä tarkoittaa, että lopullisessa ohjelmistotuotteessa voi olla hyvin suuriakin määriä vikoja, ja näitä harvoin esiintyviä vikoja voi olla hyvin vaikea havaita testauksessa ja virheenetsinnässä. Vielä merkittävämpää on ei-toiminnallisen laadun ulottuvuuksien testaaminen (Kuinka ohjelmisto on toteutettu verrattuna siihen, miten se olisi pitänyt toteuttaa). Tässä tarkasteltavia asioita ovat käytettävyys, skaalautuvuus, suorituskyky, yhteensopivuus ja luotettavuus, jotka voivat olla hyvin subjektiivisia. Siinä, missä joku kokee toiminnallisuuden kattavaksi, toiselle se voi olla liian monimutkainen ja siksi näiden ominaisuuksien testaaminen voi olla vaikeaa. Helpottaakseen näitä ongelmia testaamisessa tulee ennakkoon määritellä haluttu taso, mitä ohjelmistolta vaaditaan.

Ohjelmistokehittäjätkään eivät voi testata kaikkea, mutta he voivat käyttää yhdistelmätestien suunnittelua luodakseen vähimmäismäärän tarvittavia testejä halutun vaatimustason saavuttamiseksi ja varmistamiseksi. Yhdistelmätestien luominen mahdollistaa suuremman testikattavuuden vähemällä testien määrällä. Etsivätpä testaajat sitten nopeutta tai syvyyttä testeihinsä, he voivat käyttää yhdistelmätestien suunnittelumenetelmiä rakentaakseen jäsenneltyä vaihtelevuutta testitapauksiinsa.

Taloudellinen näkökulma NIST:n vuonna 2002 tekemän tutkimuksen mukaan ohjelmistovirheet aiheuttavat Yhdysvaltojen taloudelle 59,5 miljardin dollarin kustannukset vuosittain. Yli kolmannes näistä kustannuksista voitaisiin välttää, jos suoritettaisiin parempaa ohjelmistotestausta.

Ohjelmistotestauksen ulkoistaminen kustannussyistä on myös hyvin yleistä ja ulkoistaminen tapahtuu yleensä ulkomaille Kiinaan, Filippiineille tai Intiaan.

Yleisimpiä virheiden paikkoja

Uusi koodi: Useimmiten bugeja löytyy uudesta koodista enemmän, kuin pidempään käytössä olleesta. Uusien ominaisuuksien lisääminen vanhaan koodiin: Uudet ominaisuudet tuovat mukanaan myös uusia bugeja. Vanhan koodin muokkaaminen: Joskus jopa vanhan koodin muokkaaminen saattaa tuoda mukanaan bugeja, jotka pahimmillaan haittaavat koko ohjelmiston toimintaa. Uuden teknologian käyttö: Uuden teknologian kehittyessä, esimerkiksi vaihdettaessa tietokantamoottoria tai ohjelmointikieltä saattaa ilmetä uusia ongelmia. Nopeat "pikkufiksaukset": Joskus ohjelmoijalle saattaa esimerkiksi tulla kiire saada jokin ominaisuus julkaistua ja tulee tehtyä nopeita korjauksia koodiin. Näihin korjauksiin tulee helposti virheitä, sillä niitä ei välttämättä keretä testaamaan riittävästi ja pahimmassa tapauksessa niistä puuttuu kokonaan dokumentaatio. Ulkopuolisen toimijan koodi: Ulkopuolisen toimijan tekemä ohjelmisto tai sen osa tulee tarkasti testata myös itse varmistaakseen sen toimivuus osana omaa toimintaa, jotta se varmasti täyttää yrityksen omat standardit. Uusi asiakas Uusi työntekijä: Uusien työntekijöiden koodit kannattaa testata tarkasti, sillä etenkin kokemattomuus tuottaa paljon bugeja.Vanhala, Erno. 2022. LUT-yliopiston opettajan luento ohjelmistotestauksen periaatteet-kurssilla 13.9.2022. Historia

Vuonna 1979 Glenford J. Myers esitteli virheenkorjauksen ja testauksen erottamisen. Hänen huomionsa kohdistui rikkoutumistestaukseen (eng. breakage testing) ("Onnistunut testitapaus on sellainen, joka havaitsee vielä löytämättömän virheen.”). Se osoitti ohjelmistosuunnitteluyhteisön halun erottaa perustavanlaatuiset kehitystoiminnot, kuten virheenkorjauksen vahvistuksesta.

Testaustavat Laatikkomalli Ohjelmiston testaaminen jaetaan perinteisesti kahteen luokkaan, black box -testaamiseen ja white box -testaamiseen. Nämä kaksi lähestymistapaa kuvaavat testitapauksien suunnittelemisen lähtökohtia.

Black box -testaus Ohjelmisto kuvitellaan "mustana laatikkona" — implementoinnista ei ole tarkkaa tietoa. Mustalaatikkotestauksessa testaaja on tietoinen vain siitä, mitä ohjelmiston on tarkoitus tehdä, eikä niinkään miten ohjelma sen tekee. Black box -testaamistapoihin kuuluu: samanarvoisiin jaottelu, raja-arvoanalyysi, parien testaus, satunnaisella datalla testaaminen, mallipohjainen testaaminen, jäljitettävyysmatriisi, tutkiva testaaminen ja määrittelyyn perustuva testaus. Mustalaatikkotestauksessa on etuna se, että testaajalla ei ole pakko olla ohjelmointitaitoa. Ohjelmoijalla on taatusti ollut oma näkökulma siitä millaisia toiminnallisuuksia hän on korostanut, kun taas testaajalla on ollut omansa, mikä hyödyttää testaajaa löytämään ongelmia, joita koodin kirjoittaja ei olisi osannut arvatakaan. Koska testaajat eivät näe lähdekoodia, voi ilmetä tilanteita, joissa testaaja kirjoittaa liian monta testitapausta tiettyyn ominaisuuteen, johon olisi riittänyt vähempi määrä, tai häneltä jää jokin osa kokonaan testaamatta. Tämä testaustapaa voidaan soveltaa yksikkö-, integraatio-, systeemi-, ja hyväksymistestaamiseen. Yleensä mustalaatikkotestaus kattaa suurimman osan, ellei jopa kaiken, testaamisesta siirryttäessä korkeammille tasoille, mutta sitä voidaan myös hyödyntää tehokkaasti yksikkötestauksessa.

Hyödyt ja haitat: Black box -testaaminen ei ole sidottu koodiin, jolloin testaajan näkökulma on hyvin yksinkertainen: Koodin "täytyy" sisältää virheitä. Periaatteen "Kysy ja saat vastauksen" käyttäminen löytää virheitä sieltä, missä ohjelmoija ei niitä löydä. Toisaalta black box -testaaminen on kuin "kävelisi pimeässä ilman taskulamppua", koska testaaja ei tiedä, kuinka ohjelmisto on rakennettu. Tämän seurauksena tulee tilanteita, joissa (1) käyttäjä kirjoittaa monta testitapausta tarkastaakseen jotain, jonka voisi testata yhdellä tapauksella ja/tai (2) osa back-endistä jää testaamatta kokonaan.

Black box -testaamisen etu on sen "sitoutumaton mielipide" ja toisaalta sen haittana on "sokea etsiminen".

White box -testaus White box -testaamista sanotaan testaamiseksi, jossa testaajalla on pääsy tietorakenteisiin ja algoritmeihin sekä koko koodiin. White box -testaamisesta käytetään suomenkielisessä kirjallisuudessa termiä lasilaatikkotestaus. Lasilaatikkotestauksessa käytetään ohjelmiston sisäistä näkökulmaa, eli toisinkuin mustalaatikkotestauksessa, testaaja tarvitsee ohjelmointitaitoja testitapausten suunnittelua varten. Testaaja valitsee syötteet sen perusteella, mitkä niistä käyvät läpi koodin kaikki mahdolliset polut ja määrittelee sitten odotetut tulokset. Vaikka lasilaatikkotestausta voidaan soveltaa yksikkö-, integraatio- ja järjestelmätesteissä, sitä tehdään yleensä vain yksikkötasolla, sillä koodimäärän laajetessa, testaajan käy vaikeammaksi hahmottaa kokonaisuutta. Sillä voi testata polkuja yksikössä, yksiköiden välillä integraation aikana sekä alijärjestelmien välillä järjestelmätason testauksessa. Lasilaatikkotestauksella voidaan paljastaa monia virheitä, mutta sillä ei välttämättä havaita määrittelyssä toteuttamatta jääneitä osia tai puuttuvia vaatimuksia.

Tasot

Yksikkötestaus. White-box-testaus tehdään yksikkötestauksen aikana sen varmistamiseksi, että koodi toimii tarkoitetulla tavalla, ennen kuin se integroidaan aiemmin testatun koodin kanssa. Yksikkötestauksen aikana suoritettavalla white-box-testausmenetelmällä voidaan mahdollisesti havaita monia virheitä jo varhaisessa vaiheessa, ja se auttaa korjaamaan virheitä, jotka ilmenevät myöhemmin sen jälkeen, kun koodi on integroitu muuhun sovellukseen, ja vähentää siten virheiden vaikutuksia myöhemmin kehitystyön aikana. Integraatiotestaus. Tämän tason white-box-testauksessa testataan rajapintojen vuorovaikutusta keskenään. Yksikkötason testauksessa varmistettiin, että jokainen koodi testattiin ja ne toimivat asianmukaisesti eristetyssä ympäristössä, ja integroinnissa tarkastellaan käyttäytymisen oikeellisuutta avoimessa ympäristössä käyttämällä white-box-testausta ohjelmoijan tiedossa olevien rajapintojen vuorovaikutusten osalta. Regressiotestaus. Regressiotestauksessa käytetään kierrätettyjä white-box-testitapauksia yksikkö- ja integrointitestauksen tasoilla.

Perusmenettelyt