Olisiko järkeä olla "bugin keksijän" ammatti tai harrastus, eli sellainen homma jossa yritetään keksiä ohjelmiston käyttötapoja, jotka kaatavat ohjelmiston tai tuovat esiin muita vikoja?
Eli "mitä jos laittaa nämä ohjelmat yhtä aikaa päälle tässä tilassa ja tekee sen ja sen, niin kaatuuko?"
Toinen jo tietääkseni käytetty metodi on laittaa automaattinen testausohjelmisto kokeilemaan ziljoonia tiloja, mutta kuten shakista ja go:sta on nähty, luovuus voi voittaa raa'an laskentavoiman, ja näin voi olla myös ohjelmistojen testauksessa.
Eli "mitä jos laittaa nämä ohjelmat yhtä aikaa päälle tässä tilassa ja tekee sen ja sen, niin kaatuuko?"
Toinen jo tietääkseni käytetty metodi on laittaa automaattinen testausohjelmisto kokeilemaan ziljoonia tiloja, mutta kuten shakista ja go:sta on nähty, luovuus voi voittaa raa'an laskentavoiman, ja näin voi olla myös ohjelmistojen testauksessa.
Vastaukset 3
Vanhimmat
saada sovellus tekemään virheen mieluummin kuin toimimaan oikein. näin ainakin virhetilanteet on tiedossa. muuten ollaan pian luulossa että käyttäjällä on sama ympäristö kuin kehittäjällä ja jos näin ei ole heh heh.
tietenkin työmäärää kantsii miettiä kumpi on helpompaa virhetilanteiden vai toimivien tilanteiden ennustaminen etukäteen.
Kuvaamasi "bugin keksijän" ammatti on olemassa. Heille on omia urapolkujakin, ja onpa monien suomalaisyritysten liikeideanakin myydä "bugin keksintäpalvelua". Tavallisemmin tosin puhutaan "bugin keksijöiden" sijaan "testaajista".
Testausta on hyvin monenlaista, koska bugeja voi etsiä monesta näkökulmasta lähtien. Matalimmalla tasolla, eli lähimpänä ohjelman toteutusta, lähtökohdaksi voidaan ottaa testattavan ohjelman lähdekoodi. Koodi kädessä koitetaan keksiä ohjelman palasille sellaiset syötteet, että esimerkiksi jokainen ohjelmarivi tulee suoritettua ainakin kerran testauksen aikana. Näin ajatellaan löydettävän virheelliset ohjelmarivit.
Kuten arvata saattaa, edellä kuvatulla tavalla testattu järjestelmä voi sisältää vielä kaikenlaisia yllätyksiä. Erään viimeaikoina silmiini sattuneen tutkimuksen mukaan testauksessa läpikäytyjen koodirivien määrä korreloi positiivisesti löydettyjen virheiden määrän kanssa, mutta kuitenkin heikommin kuin eräällä tavalla mitattu läpikäytyjen toiminnallisten vaatimusten määrä. Tämä havainto tuli yksittäisestä kokeesta, eivätkä sen tekijät tietenkään rohjenneet väittää tämän pitävän aina paikkaansa. Bugeja koitetaankin usein keksiä testaamalla toimivatko järjestelmän komponentit suunnitelman mukaan, tekeekö järjestelmä kokonaisuutena sen, mitä vaatimuksiin on kirjattu, tai toimiiko se kuten järjestelmän käyttäjä oikeasti haluaa.
Näiden näkökulmien lisäksi bugeja voi etsiä mm. rasittamalla järjestelmää rajusti (laitetaan palveluun kerralla 10.000 käyttäjää), kokeilemalla pääsekö ohjelma vaadittuihin vasteaikoihin, järjestämällä erilaisia vikatilanteita (irroitetaan yhtäkkiä ethernet- tai virtajohto), lähettämällä Fysikaalikon mainitsemia satunnaisia syötteitä, pyytämällä paikalle värisokea käyttäjä tai kokenut bugin keksijä vain naputtelemaan ja koputtelemaan järjestelmää, kokeilemalla kräkkereiden suosimia ilkeitä ja laittomia syötteitä, ja ajamalla ohjelmaa erilaisissa järjestelmäkonfiguraatioissa (toimiiko 800x600-näyttötilassa, entä jos tulostinta ei ole asennettu, selaimena onkin Opera, ilman ensimmäistäkään asennettua service packiä tai Linuxin 2.2-sarjan kernelillä?).
Ja vaikka kaikki nämä testit olisi tehty löytämättä bugeja, ei se tarkoita etteikö niitä ohjelmassa silti olisi. Koska testaus ei voi osoittaa ohjelmaa toimivaksi, sen tärkein tehtävä on paljastaa bugeja. Siksi "bugin keksijä" onkin mielestäni parempi tehtävänimike kuin "testaaja".
Fysikaalikon mainitsemaa raakaa laskentavoimaa voi hyvinkin käyttää testauksessa hyväksi. Esimerkiksi ns. mallipohjaisessa testauksessa tietokone ohjelma "suunnittelee" sopivia testejä. Omissa tutkimuksissanikin on tullut vastaan tilanteita, joissa prosessoritehoa kannattaa polttaa fiksuihin arvauksiin, jotta testattavasta softasta voitaisiin kaivaa bugeja nopeammin esiin. Toisaalta on tullut vastaan myös tilanne, jossa testattava ohjelma luki jopa kymmeniä tuhansia syötteitä sekunnissa. Silloin bugit löytyivät nopeimmin, kun laskennallisesti vaativan "suunnittelun" sijaan järjestelmää vain pommitettiin niin nopeasti kuin mahdollista.
..on keksinyt hienon tavan: MYYDÄÄN ihmisille ohjelmia testausta varten. Ei niitä bugeja tarvi edes korjata, riittää että ihmiset maksaa siitä hyvästä että saavat löytää jatkuvasti virheitä :)