Ohjelmiston testaaminen

Wikipedia
Loikkaa: valikkoon, hakuun

Ohjelmiston testaaminen on empiiristä tutkimusta ohjelmiston laadukkuudesta kontekstissa, jossa ohjelmiston tulisi toimia. Testaaminen tarjoaa asiakkaalle tietoa testattavan tuotteen tai palvelun laadusta.[1] 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 vaatimukset ovat määritelty ja ohjelmointivaihe on suoritettu.

Ohjelmistotestaamisen aiheet[muokkaa | muokkaa wikitekstiä]

Tavoite[muokkaa | muokkaa wikitekstiä]

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ä.[2] 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ä.[3]

Viat ja häiriöt[muokkaa | muokkaa wikitekstiä]

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.[4]

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. [5] 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. [5] Yksi virhe saattaa johtaa useisiin häiriöihin laajalla alueella ohjelmistoa.

Yhteensopivuus[muokkaa | muokkaa wikitekstiä]

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[muokkaa | muokkaa wikitekstiä]

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[muokkaa | muokkaa wikitekstiä]

Laatikkomalli[muokkaa | muokkaa wikitekstiä]

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[muokkaa | muokkaa wikitekstiä]

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ävyys matriisi, 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 tarkistaakseen 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".[6]

White box -testaus[muokkaa | muokkaa wikitekstiä]

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[muokkaa | muokkaa wikitekstiä]

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

Integraatiotestaus[muokkaa | muokkaa wikitekstiä]

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

Regressiotestaus[muokkaa | muokkaa wikitekstiä]

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[muokkaa | muokkaa wikitekstiä]

Hyväksyttämistestausta ovat:

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

Toimintaan liittymätön testaus[muokkaa | muokkaa wikitekstiä]

  • Ohjelmiston suorituskyvyn testaaminen tarkistaa, 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.
  • Internationalisointi- ja lokalisointitestausta tarvitaan ohjelmiston osiin. Pseudolokalisointi-metodia voidaan käyttää tässä tapauksessa.

Destruktiivinen testaus[muokkaa | muokkaa wikitekstiä]

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

Testiprosessi[muokkaa | muokkaa wikitekstiä]

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

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. [9]
  • Integraatiotestaaminen paljastaa viat rajapinnoissa ja moduulien vuorovaikutuksessa.[10]
  • Järjestelmätestaus testaa kokonaan integroitua järjestelmää vahvistaakseen, että se vastaa vaatimuksia.[11]
  • 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ä.lähde?
  • 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.lähde?

Regressiotestaus[muokkaa | muokkaa wikitekstiä]

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[muokkaa | muokkaa wikitekstiä]

Vaikka testaamisesta on useita variaatioita eri organisaatioissa, on olemassa kuitenkin tyypillinen testisykli.[12]:

  • 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: tai virheanalyysi, tehdään kehitysryhmän toimesta 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.

Viitteet[muokkaa | muokkaa wikitekstiä]

  1. Exploratory Testing, Cem Kaner, Florida Institute of Technology, Quality Assurance Institute Worldwide Annual Software Testing Conference, Orlando, FL, November 2006
  2. Kaner, Cem, Falk, Jack and Nguyen, Hung Quoc: Testing Computer Software, 2nd Ed., s. 480. New York, et al: John Wiley and Sons, Inc., 1999. 0-471-35846-0.
  3. Kolawa, Adam, Huizinga, Dorota: Automated Defect Prevention: Best Practices in Software Management, s. 41-43. Wiley-IEEE Computer Society Press, 2007. ISBN 0-47004212-5.
  4. Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press, 426. ISBN 0470042125. 
  5. a b Section 1.1.2, Certified Tester Foundation Level Syllabus, International Software Testing Qualifications Board
  6. Savenkov, Roman (2008). How to Become a Software Tester. Roman Savenkov Consulting, 168. ISBN 978-0-615-23372-7. 
  7. e)Testing Phase in Software Testing:-
  8. Dustin, Elfriede (2002). Effective Software Testing. Addison Wesley, 3. ISBN 0-20179-429-2. 
  9. Binder, Robert V. (1999). Testing Object-Oriented Systems: Objects, Patterns, and Tools. Addison-Wesley Professional, 45. ISBN 0-201-80938-9. 
  10. Beizer, Boris (1990). Software Testing Techniques, Second, New York: Van Nostrand Reinhold, 21,430. ISBN 0-442-20672-0. 
  11. IEEE (1990). IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York: IEEE. ISBN 1559370793. 
  12. Pan, Jiantao: Software Testing (18-849b Dependable Embedded Systems) Topics in Dependable Embedded Systems. kevät 1999. Electrical and Computer Engineering Department, Carnegie Mellon University.
Käännös suomeksi
Tämä artikkeli tai sen osa on käännetty tai siihen on haettu tietoja vieraskielisen Wikipedian artikkelista.