Ohjelmistojen testaus on tutkimusprosessi, jossa testataan ohjelmistotuotetta , jonka tarkoituksena on tarkistaa ohjelman todellisen toiminnan ja sen odotetun toiminnan välinen vastaavuus tietyllä tavalla valitulla lopullisella testisarjalla ( ISO / IEC TR 19759:2005) [ 1] .
Testaukselle on annettu erilaisia määritelmiä eri aikoina ja eri lähteistä, mukaan lukien:
Ensimmäiset ohjelmistojärjestelmät kehitettiin osana tieteellisiä tutkimusohjelmia tai ohjelmia puolustuslaitosten tarpeisiin. Tällaisten tuotteiden testaus suoritettiin tiukasti muodollisesti ja kirjattiin kaikki testimenettelyt, testitiedot ja saadut tulokset. Testaus erotettiin erilliseksi prosessiksi, joka alkoi koodauksen valmistumisen jälkeen, mutta sen suoritti yleensä sama henkilökunta.
1960-luvulla painotettiin paljon "täydellistä" testausta, joka tulisi tehdä käyttäen kaikkia koodin polkuja tai kaikkia mahdollisia syötteitä. Todettiin, että näissä olosuhteissa täydellinen ohjelmistotestaus ei ole mahdollista, koska ensinnäkin mahdollisten tulojen määrä on erittäin suuri, toiseksi polkuja on monia, ja kolmanneksi on vaikea löytää ongelmia arkkitehtuurissa ja spesifikaatioissa. Näistä syistä "tyhjentävä" testaus hylättiin ja katsottiin teoriassa mahdottomaksi.
1970-luvun alussa ohjelmistotestaukseen viitattiin "prosessina tuotteen oikeellisuuden osoittamiseksi" tai "ohjelmiston oikean toiminnan varmentamiseen". Orastavassa ohjelmistosuunnittelussa ohjelmiston todentamista kutsuttiin "oikeuden todisteeksi". Vaikka konsepti oli teoriassa lupaava, käytännössä se oli aikaa vievä eikä tarpeeksi kattava. Todettiin, että oikeellisuuden todistaminen oli tehoton menetelmä ohjelmistojen testaamiseen. Joissain tapauksissa oikean toiminnan osoittamista käytetään kuitenkin vielä tänäkin päivänä, esimerkiksi vastaanottotestejä. 1970-luvun jälkipuoliskolla testauksen katsottiin ajavan ohjelmaa, jonka tarkoituksena oli löytää virheitä, ei sen toimivuuden osoittamista. Onnistunut testi on testi, joka löytää aiemmin tuntemattomia ongelmia. Tämä lähestymistapa on täysin päinvastainen kuin edellinen. Nämä kaksi määritelmää edustavat "testausparadoksia", joka perustuu kahteen vastakkaiseen väitteeseen: toisaalta testauksen avulla voit varmistaa tuotteen toimivuuden ja toisaalta se paljastaa virheitä ohjelmissa, mikä osoittaa, että tuote ei toimi. Testauksen toinen tavoite on tuottavampi laadun parantamisen kannalta, koska se ei salli ohjelmistovirheiden huomioimista.
1980-luvulla testaus laajeni koskemaan vikojen ehkäisyä. Testisuunnittelu on tehokkain tunnettu virheiden ehkäisytekniikka. Samalla alettiin ilmaista ajatuksia siitä, että testausmetodologiaa tarvitaan, erityisesti että testaukseen tulisi sisältyä koko kehityssyklin ajan tarkastuksia ja tämän pitäisi olla kontrolloitu prosessi. Testauksen aikana on tarpeen tarkistaa paitsi koottu ohjelma, myös vaatimukset, koodi, arkkitehtuuri ja itse testit. "Perinteinen" testaus, joka oli olemassa 1980-luvun alkuun asti, viittasi vain koottuun, valmiiseen järjestelmään (nykyään kutsutaan yleisesti järjestelmätestaukseksi), mutta siitä lähtien testaajat ovat olleet mukana kaikissa kehitysvaiheen elinkaaren osa-alueilla. Tämä mahdollisti vaatimuksiin ja arkkitehtuuriin liittyvien ongelmien havaitsemisen aikaisemmin, mikä pienensi kehitysaikaa ja budjettia. 1980-luvun puolivälissä ilmestyivät ensimmäiset työkalut automaattiseen testaukseen. Tietokoneen piti pystyä suorittamaan enemmän testejä kuin ihmisen ja tehdä se luotettavammin. Aluksi nämä työkalut olivat erittäin yksinkertaisia, eikä niissä kyetty kirjoittamaan skriptejä komentosarjakielillä.
1990-luvun alussa "testauksen" käsite alkoi sisältää testien ja testiympäristöjen suunnittelun, suunnittelun, luomisen, ylläpidon ja suorittamisen, mikä merkitsi siirtymistä testauksesta laadunvarmistukseen, joka kattaa koko ohjelmistokehityssyklin. Tällä hetkellä testausprosessin tukena alkoi ilmestyä erilaisia ohjelmistotyökaluja: edistyneempiä automaatioympäristöjä, joissa on mahdollisuus luoda komentosarjoja ja raportteja, testauksenhallintajärjestelmiä ja lataustestausohjelmistoja. 1990-luvun puolivälissä, kun Internet kehittyi ja suuri määrä verkkosovelluksia kehitettiin, "ketteri testaus" (samanlainen kuin ketterät ohjelmointimenetelmät) alkoi saada erityisen suosiota.
On olemassa useita kriteerejä, joiden mukaan on tapana luokitella testaustyypit. Yleensä siellä on seuraavat:
Testauksen kohteen mukaanUsein ilmaisissa ja avoimen lähdekoodin ohjelmistoissa alfatestausvaihe luonnehtii koodin toiminnallista sisältöä ja beta- testaus bugienkorjausvaihetta. Samaan aikaan pääsääntöisesti jokaisessa kehitysvaiheessa loppukäyttäjien saatavilla on työn välituloksia.
Alla kuvatut tekniikat - valkoisen laatikon testaus ja musta laatikko -testaus - olettavat, että koodi suoritetaan, ja ero on vain testaajan tiedoissa. Molemmissa tapauksissa tämä on dynaaminen testaus .
Staattisen testauksen aikana ohjelmakoodia ei suoriteta - ohjelma analysoidaan lähdekoodin perusteella, joka luetaan manuaalisesti tai analysoidaan erikoistyökaluilla. Joissakin tapauksissa lähdekoodia ei analysoida, vaan välikoodia (kuten tavukoodi tai MSIL -koodi ).
Staattinen testaus sisältää myös testausvaatimukset , tekniset tiedot ja dokumentaation .
Kun muutokset on tehty ohjelman seuraavaan versioon, regressiotestit vahvistavat, että tehdyt muutokset eivät vaikuttaneet sovelluksen muiden toimintojen suorituskykyyn. Regressiotestaus voidaan suorittaa sekä manuaalisesti että testiautomaatiotyökaluilla .
Testaajat käyttävät testiskenaarioita eri tasoilla: sekä komponenttien testauksessa että integraatio- ja järjestelmätestauksessa. Testausskriptit kirjoitetaan yleensä testaamaan komponentteja, jotka todennäköisimmin epäonnistuvat, tai virhe, jota ei löydy ajoissa, voi olla kallista.
Riippuen testin kehittäjän pääsystä testattavan ohjelman lähdekoodiin, erotetaan " valkoisen laatikon testaus (strategian mukaan) " ja " mustan laatikon testaus (strategian mukaan) ".
White box -testauksessa (kutsutaan myös läpinäkyväksi laatikkotestaukseksi ) testin kehittäjällä on pääsy ohjelmien lähdekoodiin ja hän voi kirjoittaa koodia, joka linkittää testattavan ohjelmiston kirjastoihin. Tämä on tyypillistä komponenttitestauksessa, jossa vain osia järjestelmästä testataan. Se varmistaa, että rakenneosat ovat tietyssä määrin toimivia ja vakaita. Valkoisen laatikon testaus käyttää koodin kattavuuden mittareita tai mutaatiotestausta .
Black box -testauksessa testaajalla on pääsy ohjelmaan vain samojen rajapintojen kautta kuin asiakas tai käyttäjä tai ulkoisten rajapintojen kautta, jotka mahdollistavat toisen tietokoneen tai muun prosessin yhteyden järjestelmään testausta varten. Testauskomponentti voi esimerkiksi virtuaalisesti painaa testattavan ohjelman näppäimiä tai hiiren painikkeita prosessiviestintämekanismin avulla luottaen siihen, että kaikki menee hyvin, että nämä tapahtumat aiheuttavat saman reaktion kuin oikeat näppäinpainallukset ja hiiren painikkeet. Pääsääntöisesti black box -testaus suoritetaan spesifikaatioiden tai muiden järjestelmän vaatimuksia kuvaavien asiakirjojen avulla. Tyypillisesti tämäntyyppisessä testauksessa kattavuuskriteeri on syötetietorakenteen kattavuuden, vaatimusten kattavuuden ja mallin kattavuuden (mallipohjaisessa testauksessa ) summa.
Harmaan laatikkotestauksessa testin kehittäjällä on pääsy lähdekoodiin, mutta suoritettaessa testejä suoraan koodiin pääsyä ei yleensä vaadita.
Vaikka "alfa" ja "beta-testaus" viittaavat vaiheisiin ennen tuotteen julkaisua (ja myös implisiittisesti testausyhteisön kokoon ja testausmenetelmien rajoituksiin), valkoinen laatikko ja musta laatikko -testaus viittaavat tapoihin, joilla testaaja saavuttaa tavoitteen.
Betatestaus rajoittuu yleensä black box -tekniikoihin (vaikkakin johdonmukainen testaajien osaryhmä jatkaa tavallisesti valkoisen laatikon testaamista samanaikaisesti betatestauksen kanssa). Siten termi "beta-testaus" voi tarkoittaa ohjelman tilaa (lähempänä julkaisua kuin "alfa"), tai se voi tarkoittaa tiettyä testaajien ryhmää ja tämän ryhmän suorittamaa prosessia. Toisin sanoen testaaja voi jatkaa valkoisen laatikon testaamista, vaikka ohjelma on jo "beta", mutta tässä tapauksessa se ei ole osa "beta-testausta".
Koodipeitto näyttää ohjelman lähdekoodin prosenttiosuuden, joka suoritettiin ("peitettiin") testauksen aikana. Mittausmenetelmien mukaan operaattorin kattavuus, kuntokattavuus, polun kattavuus, toimintopeitto jne.
| Ohjelmistokehitys | |
|---|---|
| Prosessi | |
| Korkean tason käsitteet | |
| Ohjeet |
|
| Kehittämismenetelmät _ | |
| Mallit |
|
| Merkittäviä lukuja |
|