Ohjelmiston testaaminen

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. 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.  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.

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. 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.

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.

Grey Box -testaus 
Grey box -testaamisessa testaajalla on pääsy tietorakenteisiin ja algoritmeihin testitapauksien suunnittelun tasolla. Testaaminen tapahtuu kuitenkin black box -tasolla.

Fuzzing 
Fuzzing tai fuzz testing on virheiden etsimisen menetelmä, jossa satunnaisilla syötteillä pyritään aiheuttamaan ohjelman kaatuminen. Menetelmä on periaatteeltaan mustan laatikon testaamista, mutta voidaan soveltaa myös kun lähdekoodit ovat saatavilla. Menetelmällä voi saada nopeasti yleiskuvan vikasietoisuudesta ja kriittisistä virheistä.
Menetelmä on peräisin vuodelta 1988 Wisconsinin yliopistosta.

Integraatiotestaus 
Integraatiotestaus on kaikentyyppistä testaamista, jossa pyritään todentamaan rajapintoja komponenttien ja ohjelmistosuunnittelun välillä. Ohjelmistokomponentit voivat olla integroitu iteratiivisesti tai kaikki yhdellä kertaa.

Regressiotestaus 
Regressiotestaus on kaikentyyppistä testaamista, jossa pyritään paljastamaan ohjelmistoregressioita. Regressio ilmenee, kun ohjelman toimiva osa lakkautetaan toimimasta tarkoituksellisesti. Tyypillisesti regressio tapahtuu tahattomasti ohjelmistoa muutettaessa, kun uudet osat törmäävät yhteen vanhojen kanssa. Tyypillisiä regressiotestauksen tapoja ovat ajaa vanhoja testejä läpi ja katsoa, ilmenevätkö jo korjatut virheet uudelleen.

Hyväksyttämistestaus 
Hyväksyttämistestausta ovat:
 Aloitustestaus. Sitä käytetään hyväksyttämistestauksena ohjelmiston uudelle versiolle ennen integraatio- ja regressiotestausta.
 Asiakkaalla hyväksyttäminen. Toteutetaan asiakkaan omassa työympäristössä asiakkaan laitteistolla (UAT).

Toimintaan liittymätön testaus
 Ohjelmiston suorituskykyä testaamalla selvitetään, voiko ohjelmisto käsitellä suurta määrää tietoa tai käyttäjiä. Tätä kutsutaan usein ohjelmiston skaalautuvuudeksi.
 Vakaustestaus testaa, toimiiko ohjelmisto normaalisti pitkiä aikoja. Sitä kutsutaan myös kestävyys- tai kuormitustestaamiseksi. 
 Käytettävyystestausta tarvitaan tarkastamaan, onko käyttöliittymä helppokäyttöinen ja helposti omaksuttavissa.
 Turvallisuustestaus on olennainen ohjelmistolle, joka prosessoi luottamuksellista tietoa. Testaamisella estetään mahdollisia tietoturva-aukkoja.
 Kansainvälistämis- ja lokalisointitestausta tarvitaan ohjelmiston osiin. Pseudolokalisointi-metodia voidaan käyttää tässä tapauksessa.

Destruktiivinen testaus 
Destruktiiviinen testaaminen yrittää kaataa ohjelmiston tai sen osan testatakseen ohjelmiston luotettavuutta.

Virheen syöttäminen 
Ohjelmistoa voidaan testata syöttämällä virhe (), jolloin voidaan testata vikasietoisuutta harvoin ilmenevissä tilanteissa. Tietyissä standardeissa kuten IEC 61508 vaaditaan tämän tyyppistä testaamista vikatilanteiden käsittelyn testaamiseksi. Perinteisiä kohteita ovat olleet laitteistokomponentit kuten suorittimet ja muistit, joissa tilaa voidaan seurata ja ohjata tietyllä tavalla. Vikoja voidaan mallintaa myös syöttämällä vikoja suoraan ohjelmaan tai lähdekoodiin.

Testiprosessi 
Yleinen käytäntö on, että ohjelmistotestaus suoritetaan itsenäisellä testausryhmällä, kun toiminnallisuus on valmis ja ennen kuin ohjelmisto toimitetaan asiakkaalle. Toinen tapa on aloittaa testaus yhdessä ohjelmiston implementoinnin kanssa, jolloin se on jatkuva prosessi.

Nykyiset suositummaksi tulevat kehitysmallit, kuten extreme programming ja ketterät kehitysmenetelmät luovat "Testitapaus-lähtökohtaisen" mallin. Tässä prosessissa ohjelmistokehittäjät kirjoittavat ensin yksikkötestit (usein pariohjelmointina extreme programming -mallissa). Tietysti nämä testit eivät mene aluksi läpi; niiden myös oletetaan epäonnistuvan. Kun koodia kirjoitetaan, se läpäisee suurimman osan testisarjoista. Testisarjoja päivitetään ja rajatapaukset huomioidaan, jonka jälkeen testit integroidaan regressiotestaukseen. Yksittäisiä testejä ylläpidetään ja ne integroidaan ohjelmiston koodiin.

Testaamista voidaan suorittaa seuraavilla tasoilla:
 Yksikkötestaus testaa pieniä ohjelmistokomponentteja tai -moduulia. Jokainen yksikkö testataan, jotta voidaan varmistaa, että yksikön yksityiskohtainen suunnittelu on toteutettu oikein. Objekti-orientoituneessa ympäristössä testaamista tehdään usein luokkatasolla ja minimaaliset testit sisältävät rakentajien ja purkajien testaamisen. 
 Integraatiotestaaminen paljastaa viat rajapinnoissa ja moduulien vuorovaikutuksessa.
 Järjestelmätestaus testaa kokonaan integroitua järjestelmää vahvistaakseen, että se vastaa vaatimuksia.
 Järjestelmän integraatiotestaus  vahvistaa, että järjestelmä on integroitu ulkopuolisten tai kolmannen osapuolen järjestelmien kanssa niin, että ne vastaavat järjestelmävaatimuksia

Ennen kuin ohjelmiston viimeinen versio julkaistaan,  suoritetaan usein lisäksi alpha- ja betatestaus:
 Alphatestaus on simuloitu tai oikea toiminnallinen testaus potentiaalisen käyttäjän tai asiakkaan tekemänä. Myös itsenäistä testiryhmää voidaan käyttää. Alphatestaus suoritetaan ennen betatestejä.
 Betatestaus. Ohjelmiston betaversiot julkaistaan rajatulle yleisölle, ohjelmistokehitysryhmän ulkopuolelle. Ohjelmisto julkaistaan ryhmille henkilöitä, jotta voidaan varmistua, että tuote sisältää vain vähän vikoja tai bugeja. Joskus tuote julkaistaan avoimesti kaikille palautteen saamiseksi tulevien käyttäjämäärien maksimoimiseksi.

Lopuksi tehdään hyväksyttämistestaus, jonka voi tehdä loppukäyttäjä tai asiakas.

Regressiotestaus
Ohjelmiston muokkauksen jälkeen suoritetaan regressiotestaus, jotta viat voidaan korjata. Regressiotestausta voidaan suorittaa millä tahansa yllä mainituista tasoista. Nämä testit ovat usein automatisoituja.

Benchmarkkaus voidaan suorittaa, jotta voidaan varmistua, että uusi, muokattu ohjelma on vähintään yhtä hyväksyttävä kuin vanha versio.

Esimerkki testauksen kulusta
Vaikka testaamisesta on useita variaatioita eri organisaatioissa, on olemassa kuitenkin tyypillinen testisykli.:
 Vaatimusanalyysi: Testaaminen tulisi aloittaa vaatimuksien keräysvaiheessa ohjelmistokehityksen kehitysvaiheista. Suunnitteluvaiheessa testaajat työskentelevät kehittäjien kanssa selvittääkseen, mitkä asiat ovat testattavissa ja millä parametreilla ne toimivat.
 Testaamisen suunnittelu: Koska useita toimenpiteitä tarvitaan testien läpiviemiseen, myös testaussuunnitelma on tehtävä.
 Testien kehittäminen: Testimenetelmät, testiskenaariot, testitapaukset, testidata , testiskriptit tarvitaan ohjelmiston testaamiseen.
 Testien ajo: Testaajat suorittavat testit ohjelmistolle ja raportoivat mahdolliset virheet kehitysryhmälle.
 Testien raportointi: Kun testaaminen on suoritettu, testaajat tuottavat kaaviot ja tekevät loppuraportin heidän testisuorituksestaan ja ilmoittavat, voidaanko ohjelmisto julkaista.
 Testituloksien analysointi: eli virheanalyysi; sen tekee tehdään kehitysryhmä usein yhdessä asiakkaan kanssa, jotta saadaan selville, miten virheet käsitellään, korjataan, hylätään tai lykätään myöhempään ajankohtaan.
 Vikojen uudelleen testaus: Kun vika on käsitelty kehitysryhmässä, testaajat toistavat testin.
 Regressiotestaus: Yleisesti mukana on myös alitestausta suorittava testausohjelma integroitua uutta, muokattua tai korjattua ohjelmistoa varten. Testaaminen suoritetaan, jotta uusimmat komponentit eivät aiheuta vikoja muualla ohjelmistossa ja ohjelmisto toimii edelleen kokonaisuudessaan oikein. 
 Testaamisen lopettaminen: Kun testaaminen on saatu loppuun, suoritetut toiminnot, kuten ulos tulevan datan kaappaus, tulokset, lokit ja kaikki dokumentit liittyen projektiin arkistoidaan myöhempiä projekteja varten.

Lähteet

Aiheesta muualla 

 
Seulonnan keskeiset artikkelit

kk:Тестілеу