Ero sivun ”Ohjelmiston testaaminen” versioiden välillä

Wikipediasta
Siirry navigaatioon Siirry hakuun
Selaa historiaa interaktiivisesti
[arvioimaton versio][arvioimaton versio]
← Vanhempi muutosUudempi muutos →
Poistettu sisältö Lisätty sisältö
VisuaalinenWikiteksti
Lisätty testaustapoihin visuaalinen testaus ja ad hoc -testaus. Käännetty englanninkieliseltä wikipedia-sivulta.
p Testauksen automatisaation lisäys
Rivi 91: Rivi 91:
* ''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 [[Ohjelmointivirhe|bugeja]]. Joskus tuote julkaistaan avoimesti kaikille palautteen saamiseksi tulevien käyttäjämäärien maksimoimiseksi.
* ''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 [[Ohjelmointivirhe|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}}
* Lopuksi tehdään hyväksyttämistestaus, jonka voi tehdä loppukäyttäjä tai asiakas. {{lähde}}


===Regressiotestaus===
===Regressiotestaus===
Rivi 109: Rivi 109:
* '''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.
* '''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.
* '''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.

== Automatisoitu testaaminen ==
Ohjelmistotestauksessa, '''testauksen automatisointi''' tarkoittaa ohjelmistopohjaista testausta, joka toimii erillään varsinaisesta testattavasta ohjelmistosta. Tällaisen ohjelmiston toiminta perustuu suoritettavien testien hallintaan ja todellisen lopputuloksen vertaukseen odotetun lopputuloksen kanssa.<ref>{{cite book|last=Kolawa|first=Adam|author2=Huizinga, Dorota|title=Automated Defect Prevention: Best Practices in Software Management|year=2007|publisher=Wiley-IEEE Computer Society Press|page=74|isbn=978-0-470-04212-0}}</ref> Testausautomaatio voi automatisoida osan toistuvista mutta välttämättömistä tehtävistä jo olemassa olevasta testausprosessista, tai suorittaa lisätestausta joka olisi hankala suorittaa manuaalisesti. Testausautomaatio on keskeisesti huomioitava seikka jatkuvan toimituksen ja jatkuvan testauksen näkökulmasta.<ref>{{Cite book|last1=O’Connor|first1=Rory V.|url=https://books.google.com/books?id=2xOcCgAAQBAJ&q=Systems%2C+Software+and+Services+Process+Improvement%3A+27th+European+Conference&pg=PA71|title=Systems, Software and Services Process Improvement: 22nd European Conference, EuroSPI 2015, Ankara, Turkey, September 30 -- October 2, 2015. Proceedings|last2=Akkaya|first2=Mariye Umay|last3=Kemaneci|first3=Kerem|last4=Yilmaz|first4=Murat|last5=Poth|first5=Alexander|last6=Messnarz|first6=Richard|date=2015-10-15|publisher=Springer|isbn=978-3-319-24647-5|language=en}}</ref>

=== Yleisiä lähestymistapoja ===
Testausautomaatioon liittyen on olemassa monia lähestymistapoja, alle on listattu näistä yleisimmät ja laajimmin käytössä olevat:

* '''Graafisen käyttöliittymän testaus [[:en:Graphical_user_interface_testing|(Graphical user interface testing).]]''' Testauskehys, joka generoi käyttöliittymätapahtumia, kuten näppäinten painalluksia ja hiiren klikkauksia, ja arvioi tuloksia käyttöliittymässä, validoidakseen että havaittu ohjelman käyttäytyminen on oikeanlaista.
* API vetoinen testaus ([[:en:API_testing|API driven testing]]). Testauskehys, joka käyttää ohjelmistokäyttöliittymää sovellukseen validoidakseen sovelluksen käyttäytymisen testatessa. Tyypillisesti API vetoinen testaus ohittaa sovelluksen käyttäjäkäyttöliittymän täysin. Sen avulla voidaan myös testata julkisia liitäntöjä luokille, moduuleita tai kirjastoja testataan useilla syöteargumenteilla sen varmistamiseksi, että palautetut tulokset ovat oikein.

=== Mallipohjainen testaus ===
Yksi tapa luoda testitapauksia automaattisesti on '''mallipohjainen testaus''' ([[:en:Model-based_testing|Model-based Testing]]) käyttämällä järjestelmän mallia testitapausten muodostamisessa. Joissain tapauksissa, mallipohjainen testaus lähestymistapa mahdollistaa ei-teknisten käyttäjien luoda automatisoituja liiketoiminta testitapauksia puhtaalla englanninkielellä, siten että minkäänlaista ohjelmointia ei tarvita näiden kokoamiseksi useammalle käyttöliittymälle, selaimelle tai älylaitteelle.<ref>{{cite book|title=Proceedings from the 5th International Conference on Software Testing and Validation (ICST). Software Competence Center Hagenberg. "Test Design: Lessons Learned and Practical Implications.|isbn=978-0-7381-5746-7|doi=10.1109/IEEESTD.2008.4578383}}</ref>


==Lähteet==
==Lähteet==

Versio 11. heinäkuuta 2023 kello 16.12

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

Visuaalinen testaus

Visuaalisessa testauksessa kehittäjille näytetään, mitä ohjelmistovirheen sattuessa tarkalleen tapahtui. Data esitellään siinä muodossa, että kehittäjän on siitä helppo löytää ongelman korjaamiseen tarvitsemansa tieto.

Visuaalisen testauksen pääideana on se, että on selkeämpää näyttää mitä on tapahtunut, sen sijaan, että vain kuvailtaisiin ongelmaa. Tämä vähentää huomattavasti riskiä väärinymmärryksille. Täten visuaalinen testaus edellyttää sitä, että koko testausprosessi tallennetaan videomuodossa, josta käy ilmi kaikki testaussysteemissä tapahtuva. Video täydennetään testaajan reaaliaikaisella, testauksen aikana tapahtuvalla, kommentaariolla, johon sisältyy web-kamera kuva sekä äänitallenne.

Visuaalisella testauksella testauksella on useita etuja. Se parantaa kommunikaatiota huomattavasti, kun testaajat voivat näyttää ongelman ja siihen johtaneet tapahtumat testaajille suoraan, sen sijaan, että vain kuvailisivat sitä. Tämä myös usein tekee tarpeettomaksi toistaa virhe uudelleen kehittäjien toimesta, kun he voivat tarkastella sitä videomateriaalilta. Testaajat saavat käyttöönsä heti kaikki tarvitsemansa tiedot virheestä ja voivat keskittyä paikantamaan virheen syytä ja sitä kuinka sen voi korjata.

Ad hoc -testaus

Ad hoc -testaus ja tutkiva testaus ovat tärkeitä metodeja ohjelman eheyttä testattaessa, koska niiden toteuttaminen ei vaadi niin paljoa valmistautumista, joten bugeja voidaan löytää nopeasti. Ad hoc -testauksessa, missä testaus tapahtuu improvisoidusti, testaajan kyky perustaa testaus dokumentoituihin menetelmiin ja sitten luoda näistä testeistä muunnelmia voi auttaa tekemään vikojen etsinnästä entistä tarkempaa. Yksi ad hoc -testauksen rajoitteista kuitenkin on, että ilman tarkkaa dokumentointia tehdyistä toimista, testejä on vaikea toistaa.

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.

Automatisoitu testaaminen

Ohjelmistotestauksessa, testauksen automatisointi tarkoittaa ohjelmistopohjaista testausta, joka toimii erillään varsinaisesta testattavasta ohjelmistosta. Tällaisen ohjelmiston toiminta perustuu suoritettavien testien hallintaan ja todellisen lopputuloksen vertaukseen odotetun lopputuloksen kanssa.[19] Testausautomaatio voi automatisoida osan toistuvista mutta välttämättömistä tehtävistä jo olemassa olevasta testausprosessista, tai suorittaa lisätestausta joka olisi hankala suorittaa manuaalisesti. Testausautomaatio on keskeisesti huomioitava seikka jatkuvan toimituksen ja jatkuvan testauksen näkökulmasta.[20]

Yleisiä lähestymistapoja

Testausautomaatioon liittyen on olemassa monia lähestymistapoja, alle on listattu näistä yleisimmät ja laajimmin käytössä olevat:

  • Graafisen käyttöliittymän testaus (Graphical user interface testing). Testauskehys, joka generoi käyttöliittymätapahtumia, kuten näppäinten painalluksia ja hiiren klikkauksia, ja arvioi tuloksia käyttöliittymässä, validoidakseen että havaittu ohjelman käyttäytyminen on oikeanlaista.
  • API vetoinen testaus (API driven testing). Testauskehys, joka käyttää ohjelmistokäyttöliittymää sovellukseen validoidakseen sovelluksen käyttäytymisen testatessa. Tyypillisesti API vetoinen testaus ohittaa sovelluksen käyttäjäkäyttöliittymän täysin. Sen avulla voidaan myös testata julkisia liitäntöjä luokille, moduuleita tai kirjastoja testataan useilla syöteargumenteilla sen varmistamiseksi, että palautetut tulokset ovat oikein.

Mallipohjainen testaus

Yksi tapa luoda testitapauksia automaattisesti on mallipohjainen testaus (Model-based Testing) käyttämällä järjestelmän mallia testitapausten muodostamisessa. Joissain tapauksissa, mallipohjainen testaus lähestymistapa mahdollistaa ei-teknisten käyttäjien luoda automatisoituja liiketoiminta testitapauksia puhtaalla englanninkielellä, siten että minkäänlaista ohjelmointia ei tarvita näiden kokoamiseksi useammalle käyttöliittymälle, selaimelle tai älylaitteelle.[21]

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. ↑ 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. ↑ a b c Matt Hillman: What is fuzzing? f-secure.com. toukokuu 2020. Viitattu 25.2.2021. (englanniksi)
  8. ↑ a b 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. ↑ a b c d 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.
  19. ↑ Kolawa, Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press, 74. ISBN 978-0-470-04212-0. 
  20. ↑ (2015-10-15) Systems, Software and Services Process Improvement: 22nd European Conference, EuroSPI 2015, Ankara, Turkey, September 30 -- October 2, 2015. Proceedings (in en). Springer. ISBN 978-3-319-24647-5. 
  21. ↑ Proceedings from the 5th International Conference on Software Testing and Validation (ICST). Software Competence Center Hagenberg. "Test Design: Lessons Learned and Practical Implications.. DOI:10.1109/IEEESTD.2008.4578383. ISBN 978-0-7381-5746-7. 

Aiheesta muualla

Käännös suomeksi
Käännös suomeksi
Tämä artikkeli tai sen osa on käännetty tai siihen on haettu tietoja muunkielisen Wikipedian artikkelista.
Noudettu kohteesta ”https://fi.wikipedia.org/w/index.php?title=Ohjelmiston_testaaminen&oldid=21677472”