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

Ohjelmiston testaamista

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

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

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".[6]

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.[7][8] Menetelmä on periaatteeltaan mustan laatikon testaamista, mutta voidaan soveltaa myös kun lähdekoodit ovat saatavilla.[7] Menetelmällä voi saada nopeasti yleiskuvan vikasietoisuudesta ja kriittisistä virheistä.[7] Menetelmä on peräisin vuodelta 1988 Wisconsinin yliopistosta.[8][9][10]

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:

  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
  • 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 (engl. fault injection), jolloin voidaan testata vikasietoisuutta harvoin ilmenevissä tilanteissa.[11][12] Tietyissä standardeissa kuten IEC 61508 vaaditaan tämän tyyppistä testaamista vikatilanteiden käsittelyn testaamiseksi.[11] Perinteisiä kohteita ovat olleet laitteistokomponentit kuten suorittimet ja muistit, joissa tilaa voidaan seurata ja ohjata tietyllä tavalla.[11] Vikoja voidaan mallintaa myös syöttämällä vikoja suoraan ohjelmaan tai lähdekoodiin.[11]

Testiprosessi

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

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. [15]
  • Integraatiotestaaminen paljastaa viat rajapinnoissa ja moduulien vuorovaikutuksessa.[16]
  • Järjestelmätestaus testaa kokonaan integroitua järjestelmää vahvistaakseen, että se vastaa vaatimuksia.[17]
  • 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

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.[18]:

  • 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
  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. 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. Matt Hillman: What is fuzzing? f-secure.com. toukokuu 2020. Viitattu 25.2.2021. (englanniksi)
  8. What is fuzz testing? about.gitlab.com. Viitattu 1.8.2022. (englanniksi)
  9. Project List (PDF) pages.cs.wisc.edu. syksy 1988. Viitattu 1.8.2022. (englanniksi)
  10. An Empirical Study of the Reliability of UNIX Utilities (PDF) ftp.cs.wisc.edu. Arkistoitu . Viitattu 1.8.2022. (englanniksi)
  11. Benjamin Vedder: Testing Safety-Critical Systems using Fault Injection and Property-Based Testing (PDF) diva-portal.org. 2015. Viitattu 25.2.2021. (englanniksi)
  12. Development of a Fault Injection-Based Dependability Assessment Methodology for Digital I&C Systems Volume 1 (PDF) nrc.gov. joulukuu 2012. Viitattu 25.2.2021. (englanniksi)
  13. e)Testing Phase in Software Testing:-
  14. Dustin, Elfriede (2002). Effective Software Testing. Addison Wesley, 3. ISBN 0-20179-429-2.
  15. Binder, Robert V. (1999). Testing Object-Oriented Systems: Objects, Patterns, and Tools. Addison-Wesley Professional, 45. ISBN 0-201-80938-9.
  16. Beizer, Boris (1990). Software Testing Techniques, Second, New York: Van Nostrand Reinhold, 21,430. ISBN 0-442-20672-0.
  17. IEEE (1990). IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York: IEEE. ISBN 1559370793.
  18. 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.

    Aiheesta muualla
    This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.