9. Olio-ohjelmien testaaminen

9. Olio-ohjelmien testaaminen Nykyään suurin osa ohjelmistoista suunnitellaan ja toteutetaan käyttäen oliotekniikoita. Miten oliojärjestelmien testaus eroaa perinteisistä proseduraalisista ohjelmista? Mika Katara: Ohjelmistojen testaus, 2011 415 Mukailtu lähteestä [Pezzè&Young 07] Pohjimmiltaan tekniikat proseduraalisten ohjelmien testaukseen toimivat myös olio-ohjelmien tapauksessa Olioiden erityispiirteistä johtuen joitain tärkeitä kohtia saattaa kuitenkin jäädä testaamatta Tästä syystä on kehitetty joukko oliospesifisiä tekniikoita, joilla nämä muuten katveeseen jäävät alueet saadaan testattua Vaikuttavat testaukseen lähinnä yksikkö- ja integrointitasoilla Mika Katara: Ohjelmistojen testaus, 2011 416

Oliojärjestelmien hyviä puolia testaajan näkökulmasta Olio-ohjelmoinnin myötä on alettu kiinnittää enemmän huomiota ohjelman suunnitteluun (suunnittelumallit yms.) toisaalta, sama ongelma voidaan ratkaista hyvin eri tavoilla Metodit ovat yleensä lyhyempiä kuin vastaavat proseduurit yleensä metodin lyhyys tarkoittaa helpompaa yksikkötestausta toisaalta niitä voi olla enemmän Testitapaukset ovat potentiaalisesti uudelleenkäytettäviä siinä missä koodikin Mika Katara: Ohjelmistojen testaus, 2011 417 Suurin olio-ohjelmien erityispiirre testauksen näkökulmasta on se, että oliolla on tila Järjestelmän käyttäytyminen tietyllä hetkellä riippuu siitä, mitkä ovat sen olioiden sisäiset tilat sillä hetkellä Tekniikat, jotka eivät ota huomioon olioiden tilaa, eivät yksinään välttämättä riitä oliojärjestelmien testaamiseen Olion elinkaari rakentamisesta purkamiseen Mika Katara: Ohjelmistojen testaus, 2011 418

Toinen tärkeä erityispiirre on tiedon kätkentä Osa olion muuttujista, jotka määrittelevät sen tilan, on kätketty ulkopuolisilta Tiedon kätkentä voi parantaa koodin laatua ja sitä kautta vähentää testauksen tarvetta Täytyy kuitenkin huolehtia siitä, että myös kätkettyjen muuttujien arvot tulevat tarkastettua kun tutkitaan miten järjestelmä käyttäytyy Mika Katara: Ohjelmistojen testaus, 2011 419 Perintä Voidaanko lapsiluokka jättää testaamatta sillä perusteella, että kantaluokka on jo testattu? Testaajien täytyy päättää tarvitseeko lapsiluokan metodeja varten kehittää uusia testitapauksia tarvitseeko kantaluokan testitapauksia ajaa uudelleen lapsiluokalle mitä lapsiluokan metodeja ei tarvitse testata Mika Katara: Ohjelmistojen testaus, 2011 420

Polymorfismi ja dynaaminen sitominen Muuttujan edustaman olion luokka ei ole selvillä käännösaikana, joten siihen tehtävän metodikutsun todellinen kohde päätetään vasta ajoaikana järjestelmän tilan perusteella tämä hankaloittaa suunnittelun ja koodin ymmärtämistä Perinteiset tekniikat, jotka olettavat sitomisen olevan staattista, eivät kata kaikkia mahdollisia sitomisia (käyttäytymisiä) Eri sidontamahdollisuudet tulee siis testata voitaisiinko soveltaa päätöskattavuutta? Useamman kutsun tapauksessa myös niiden mahdolliset sitomiskombinaatiot tulisi testata Mika Katara: Ohjelmistojen testaus, 2011 421 Abstraktit luokat Abstraktit luokat voivat olla tärkeitä osasia kirjastojen tai komponenttien rajapinnoissa, mutta niitä ei voida sinänsä instantioida tai testata Joskus voi olla mahdotonta tietää kuinka ko. luokkia tullaan todellisuudessa käyttämään Testaajien täytyy yrittää tehdä valistuneita arvauksia tärkeistä käyttötavoista ja testata sen mukaisesti Mika Katara: Ohjelmistojen testaus, 2011 422

Poikkeukset Oliokielten poikkeusmekanismeja hyödynnetään yleisesti Poikkeus voidaan heittää aivan toisaalla lähdekoodissa kuin missä se käsitellään Dynaaminen sitominen tuo mukanaan oman monimutkaisuutensa Poikkeustapausten testaamiseen on syytä kiinnittää erityistä huomiota Mika Katara: Ohjelmistojen testaus, 2011 423 Rinnakkaisuus Oliokielissä säikeiden käyttöön kannustetaan tai sitä jopa vaaditaan esim. Javan käyttöliittymäkirjastot Valitettavasti rinnakkaisuus on testauksen kannalta varsinainen viidakko yleensä tapahtuma A tapahtuu ennen tapahtumaa B, mutta pitääkö tämä aina paikkansa vai riippuuko se vuorontajasta? toimiiko keskinäinen poissulkeminen kaikissa tilanteessa? Mika Katara: Ohjelmistojen testaus, 2011 424

Oliot vaikuttavat testaukseen V-mallin alimmilla tasoilla Lähinnä yksikkö- ja integrointitestauksessa Muissa vaiheissa perinteiset menetelmät purevat hyvin Nyrkkisääntönä voidaan sanoa, että kukin edellä mainittu erityispiirre pitäisi testata erikseen Poikkeuksen muodostavat piirteet, jotka interferoivat keskenään kuten perintä ja tilasta riippuva käyttäytyminen Mika Katara: Ohjelmistojen testaus, 2011 425 Yksikkötestaus Metodeita ei yleensä kannata ajatella testattavina yksikköinä, koska niiden käyttäytyminen riippuu usein ympäröivän olion tilasta Luokka tuntuu sopivammalta testattavalta yksiköltä priorisointi kannattaa muistaa; kaikki luokat eivät ole yhtä tärkeitä luokkaa ei voi testata testaamatta sen metodeita Mika Katara: Ohjelmistojen testaus, 2011 426

Luokan yksikkötestaus Jos luokka on abstrakti, instantioidaan sen lapsiluokista olioita joiden avulla luokka testataan mikäli lapsiluokkia ei ole, niitä pitää määritellä pelkästään testausta varten Suunnittele testitapaukset, jotka testaavat perittyjen ja ylimääriteltyjen metodien kutsumista arvioi, mitkä perityistä metodeista pitää testata uudelleen arvioi, voidaanko kantaluokan testitapauksia uudelleenkäyttää älä unohda rakentajia ja purkajia (resurssien vapauttaminen) Mika Katara: Ohjelmistojen testaus, 2011 427 Harmaalaatikkotestaus: mikäli luokan käyttäytyminen on spesifioitu tilakoneen avulla, suunnittele joukko testitapauksia ko. spesifikaation avulla mikäli tilakonespesifikaatiota ei ole, sellainen ehkä kannattaa tehdä testauksen helpottamiseksi Lasilaatikkotestaus: täydennä testitapausten joukkoa käyttäen apuna koodia ja sen rakennetta Suunnittele testitapauksia, jotka testaavat poikkeustenkäsittelyä poikkeukset, joita tämän luokan metodit voivat heittää, ottaa kiinni ja käsitellä Mika Katara: Ohjelmistojen testaus, 2011 428

Täydennä testitapausten joukkoa testeillä, jotka testaavat tämän luokan metodeihin kohdistuvia polymorfia metodikutsuja Kannattaa kiinnittää huomiota myös luokan sisällä tapahtuvaan vuorovaikutukseen metodit voivat käyttää samoja muuttujia metodit voivat kutsua toisia, saman luokan metodeita Mika Katara: Ohjelmistojen testaus, 2011 429 Luokkien integrointitestaus Vertaa kokoava inkrementaalinen integrointistrategia Aloitetaan pienistä luokkien muodostamista klustereista, joiden kokoa kasvatetaan vähitellen Ensin pitää kuitenkin selvittää luokkien väliset riippuvuudet luokka A riippuu B:stä mikäli A:n instanssit kutsuvat B:n instanssien metodeja A:n instanssit sisältävät viitteitä B:n instansseihin perintäsuhteet ja abstraktit luokat voidaan jättää huomioimatta huom! call-back tyyppisten kutsujen tapauksessa (esim. käyttöliittymäkirjastot) sovellus riippuu aina kirjastosta eikä päinvastoin Mika Katara: Ohjelmistojen testaus, 2011 430

Hyvin suunnitelluissa ohjelmistoissa riippuvuudet eivät yleensä muodosta silmukoita, jolloin klusterin luokat ja niiden väliset riippuvuudet muodostavat puumaisen rakenteen mikäli silmukoita löytyy, ne tulee purkaa korvaamalla jokin luokka tyngällä Aloitetaan testaus klusterin lehtiluokista, jotka eivät riipu muista luokista Liitetään mukaan lehtiluokkien kantaluokkia jne. edeten kohti puun juurta Mika Katara: Ohjelmistojen testaus, 2011 431 Jokaisessa vaiheessa suunnitellaan/ajetaan klusterille sen toiminnallisuutta testaavia mustalaatikkotestejä Tarvittaessa suunnitellaan/ajetaan lisäksi lasilaatikkotestejä esim. kunnes tavoitteeksi asetettu kattavuus on saavutettu Testitapauksien pitäisi testata erityisesti myös sellaisia poikkeuksia, jotka heitetään eri luokassa kuin missä ne käsitellään (klusterin sisällä) klusterin luokkien välillä tapahtuvia polymorfisia metodikutsuja Mika Katara: Ohjelmistojen testaus, 2011 432

Oliotestauksen skaalaaminen riskien suhteen Pöyhösen ja Stenbergin (NRC) mukaan (www.cs.tut.fi/tapahtumat/olio2002/): Pieni riski: 100% metodikattavuus ekvivalenssiluokkien käyttö (lailliset ekvivalenssiluokat) raja-arvoanalyysin käyttö (laillisten ekvivalenssiluokkien rajaarvot) keskeisten perintäsuhteiden testaus dynaaminen sitominen testataan perinnän yhteydessä muistinhallinnan testauksessa testataan tärkeimmät rakentajat sekä kaikki purkajat joitakin osia koodista tarkastetaan käytetään koodin staattista analysointia olio-mallit tarkastetaan epämuodollisesti Mika Katara: Ohjelmistojen testaus, 2011 433 Keskisuuren riskin tapauksessa edellisten lisäksi: 100% metodikattavuus ekvivalenssiluokkien käyttö (lailliset + laittomat ekvivalenssiluokat) enemmän perintäsuhteita poikkeuksien testaus dynaaminen sidonta testataan erikseen ei kuitenkaan kaikkia kombinaatioita kaikki rakentajat testataan olio-mallit tarkastetaan Mika Katara: Ohjelmistojen testaus, 2011 434

Suuren riskin tapauksessa edellisten lisäksi: 100% metodikattavuus raja-arvoanalyysin käyttö (laillisten + laittomien ekvivalenssiluokkien raja-arvot ) kaikki perintäsuhteet testataan dynaamisen sidonnan kaikki kombinaatiot testataan järjestelmälliset tarkastukset koodille Mika Katara: Ohjelmistojen testaus, 2011 435 Mock-oliot Olioiden yksikkötestauksessa havaittuja käytännön ongelmia: Riippuvuuksien korvaaminen tyngillä voi olla työlästä (tietokannat, protokollapinot, käyttöliittymät) testattavan yksikön koko kasvaa Testien toistettavuus usein heikko ad-hoc tyyppistä käsityötä Järjestelmää ei ole suunniteltu testattavaksi Mackinnon, Freeman, Craig: Endo-testing: Unit testing with Mock Objects, XP2000 Mock-olioita voidaan ajatella älykkäinä tynkinä Mika Katara: Ohjelmistojen testaus, 2011 436

Strukturoidumpi tapa luoda ja ohjata alkuperäisiä palveluita korvaavaa testikoodia Vaatii sovelluskohteelta hyvien tapojen mukaista oliosuunnittelua Mock-olioiden käyttö voi vaatia refaktorointia Mock-olioiden edut Halutun tilan asettaminen helppoa Toiminnallisuuksien muuttaminen helppoa Tilan tarkastaminen helppoa Mika Katara: Ohjelmistojen testaus, 2011 437 Esimerkki: testataan yksinkertaista valuuttamuunninta: public class Converter_math { public static void Eur2fim(String euroja_str, PrintStream out){ double markkoja_d = 0.0; try { markkoja_d = Double.parseDouble(euroja_str)*5.94573; out.println("tulos: " + euroja_str + " euroa vastaa " + markkoja_d + " markkaa."); } catch (NumberFormatException e) { out.println("virheellinen euromäärä: " + euroja_str); }}} Mika Katara: Ohjelmistojen testaus, 2011 438

Pääohjelma: public class Converter_main { public static void main(string[] args) { if(args.length >= 1) { if(args[0].equals("testaus")) { test_converter_math(); } else { Converter_math.Eur2fim(args[0], System.out); }} else { System.err.println("Käyttö: Anna konvertoitava " + "euromäärä parametrina");}}} Mika Katara: Ohjelmistojen testaus, 2011 439 Testaus hyödyntäen mock objecteja: public static void test_converter_math() { MockPrintStream mock = new MockPrintStream(System.out); // Testitapaus 1 mock.setexpectedprintlncalls(1); mock.setexpectedstringsegment("virheellinen euromäärä: " + "virhetilanne"); Converter_math.Eur2fim("virhetilanne", mock); mock.verify(); // Testitapaus 2 mock.setexpectedprintlncalls(1); mock.setexpectedstringsegment("tulos: 100 euroa vastaa + 594.573 " + "markkaa"); Converter_math.Eur2fim("100", mock); mock.verify(); } Mika Katara: Ohjelmistojen testaus, 2011 440

Sovelluskehyksiä/kirjastoja, jotka tarjoavat erilaisia tapoja ja ympäristöjä käyttää mock-olioita: POCMock/NMock (.NET) Mockrunner (J2EE) EasyMock DynaMock Mika Katara: Ohjelmistojen testaus, 2011 441 Kehittäjällä vastuu testattavuuden rakentamisesta Suunnittelumallit auttavat Vastuuta ei voi siirtää työkaluille tai menetelmille Yksikkötestaus vaatii hikeä/asennemuutosta, varsinkin alussa kun testiympäristö täytyy pystyttää Mock-olioiden käytöstä voi seurata se, että testattava yksikkö suunnitellaan paremmin Mika Katara: Ohjelmistojen testaus, 2011 442

Testauspatternit Viimevuosina on tunnistettu testauspatterneja, joita voi hyödyntää testauksessa samaan tapaan kuin suunnittelumalleja (design pattern) oliopohjaisessa suunnittelussa Esimerkkinä mainittakoon self-shunt-yksikkötestauspatterni Ideana on, että testitapausta mallintava olio välittää itsensä parametrina testikohteelle teeskennellen olevansa jokin oikea olio, jonka kanssa testikohteen pitäisi kommunikoida Mika Katara: Ohjelmistojen testaus, 2011 443 10. Tietoturvan testaaminen Vielä pari vuotta sitten tietoturva oli aika pienen piirin mielenkiinnon kohteena. Valitettavasti nykypäivänä kaikkien on oltava siitä kiinnostuneita. Miten sitten tietoturvaan liittyviä seikkoja pitäisi testata? Mika Katara: Ohjelmistojen testaus, 2011 444

Mukailtu lähteestä [Whittaker&Thompson 03] Tietoturvan testaaminen on tärkeää ja sen merkitys tulee vain korostumaan tulevaisuudessa Tietokoneita (PC, kännykkä, PDA jne.) käytetään yleisesti luottamuksellisten ja salaisten tietojen säilyttämiseen Verkkoa halutaan käyttää yhä enemmän myös tällaisen tiedon siirtämiseen paikasta toiseen Mikäli jätät tietoturvan testauksen tekemättä, murtautujat tekevät sen puolestasi! Mika Katara: Ohjelmistojen testaus, 2011 445 Kuten aiemmin on nähty, jotkin ohjelmistoissa lymyävistä virheistä aiheuttavat häiriöitä esim. ohjelmiston käyttäjälle näkyvään toiminnallisuuteen, jotkin toiset taas voivat haitata suorituskykyä Tietoturvan testauksessa on sitä vastoin tarkoituksena löytää virheitä, jotka joissain tilanteissa saattavat vaarantaa järjestelmän tietojen turvallisuuden Esim. nettipankin avainluvut jäävät selaimen välimuistiin vaikka sen tyhjentäisikin session lopuksi Mika Katara: Ohjelmistojen testaus, 2011 446

Ohjelmisto voi toimia muuten täysin oikein, mutta se voi silti sisältää virheitä, jotka voivat vaarantaa tietoturvan Tietoturvaan liittyviä vaatimuksia ei vielä nykyään ymmärretä kovin laajasti Verkko on täynnä softaa, jonka tekemisessä ei ole kiinnitetty yhtään huomiota tietoturvaan Esim. käyttöjärjestelmiä joudutaan jatkuvasti paikkaamaan tietoturvapäivityksillä Mika Katara: Ohjelmistojen testaus, 2011 447 Tietoturvatestauksen tarpeita voi selvittää riskianalyysin avulla, jolla saadaan selville tietojen ja liiketoiminnan suojauksen kannalta tärkeimmät seikat Tietoturvaa voidaan varmistaa ja täytyy varmistaa monella tasolla, esim. serverin fyysinen sijoittelu vs. palomuurit vs. käyttäjien autentikointi Julkishallinto on ohjeistanut tietoturvakysymyksissä tietojärjestelmien käyttäjiä ja toimittajia: http://www.vm.fi/vm/fi/16_ict_toiminta/009_tietoturvallisu us/02_tietoturvaohjeet_ja_maaraykset/index.jsp Mika Katara: Ohjelmistojen testaus, 2011 448

OWASP Top 10 2010 (www.owasp.org) A1 Injection A2 Cross-Site Scripting (XSS) A3 Broken Authentication and Session Management A4 Insecure Direct Object References A5 Cross-Site Request Forgery (CSRF) A6 Security Misconfiguration (NEW) A7 Insecure Cryptographic Storage A8 Failure to Restrict URL Access A9 Insufficient Transport Layer Protection A10 Unvalidated Redirects and Forwards (NEW) Mika Katara: Ohjelmistojen testaus, 2011 449 Tietoturvassa on pohjimmiltaan kyse salaisuuksien pitämisestä Tyypillisiä tietoturvaan liittyviä huolen aiheita ovat esimerkiksi: Haluan myydä softaani kovasta rahasta ja varmistua siitä, ettei kukaan pääse levittämään laittomia kopioita Haluan, että vain tietyt henkilöt pääsevät käsiksi tiettyihin osiin ohjelmistosta (access control) Haluan suojata palvelinohjelmistoni hyökkäyksiä vastaan (ja silti sallia käyttäjän tarjoaman koodin suorittamisen ) Haluan pitää ohjelmistoni käsittelemät tiedot salaisina sekä levyllä, muistissa että siirrettäessä verkon yli Mika Katara: Ohjelmistojen testaus, 2011 450

Toisin kuin perinteisessä testauksessa, tietoturvan testauksessa on vähemmän hyötyä spesifikaatioista Sen sijaan, että testattaisiin täyttääkö ohjelmisto spesifikaationsa, kannattaa erityisesti tutkia Mitä sivuvaikutuksia toteutus sallii puskurin ylivuodon seurauksena voidaan suorittaa vierasta koodia Miten ohjelmisto käyttäytyy ympäristönsä kanssa käyttöjärjestelmäkutsut, verkkoliikenne yms. Mika Katara: Ohjelmistojen testaus, 2011 451 Käyttöliittymän kautta tulevat uhat Käyttöliittymän suojaus luvattomilta käyttäjiltä esim. salasanan avulla toimiiko käyttäjän tunnistaminen oikein? hyväksytäänkö heikkoja salasanoja? kelpaako esim. käyttäjätunnus salasanaksi? mikäli käyttäjä saa päästä käsiksi vain osaan tiedoista (esim. kotihakemisto monen käyttäjän käyttöjärjestelmässä) toimivatko rajoitukset oikein? Mika Katara: Ohjelmistojen testaus, 2011 452

voiko salaista tietoa saada ohjelmasta ulos esim. copy/paste toiminnon tai ruudunkaappauksen avulla? voidaanko käyttöliittymän kenttiin syöttää laittomia syötteitä kuten liian pitkiä merkkijonoja? seurauksena voi olla esim. puskurin ylivuoto, jonka seurauksena taas voi vierasta koodia päästä suoritukseen järjestelmä voi myös kaatua, mikä voi tarkoittaa palvelunestoa eli järjestelmän tarjoamia palveluja ei voida käyttää (denial of service) Mika Katara: Ohjelmistojen testaus, 2011 453 Tiedostojärjestelmän kautta tulevat uhat Ohjelmistojen liitynnät tiedostojärjestelmään jäävät usein huonolle testaukselle Tiedostoihin kuitenkin tallennetaan salaisuuksia kuten salasanoja, lisenssiavaimia yms. Windows-maailmassa registry on erityisen huono paikka tallentaa salaisuuksia Unix-maailmassa sama pätee tietysti ohjelmien omiin konfiguraatiotiedostoihin (.emacs tms.) Tiedostoformaattien perusteella voidaan tehdä fuzz-testausta, joka tarkistaa kuinka robustisti tiedosto-operaatiot on toteutettu Mika Katara: Ohjelmistojen testaus, 2011 454

Käyttöjärjestelmän kautta tulevat uhat Mikäli ohjelma säilyttää muistissaan kryptattuna salaista tietoa, on tämä yleensä turvassa; ongelmia syntyy silloin kun tietoa käsitellään kryptaamattomana Mikäli käyttöjärjestelmän tarjoamat resurssit vähenevät, kuten käytettävissä olevan muistin määrä, seurauksena saattaa olla esim. palvelunesto ohjelman kontrolloimaton kaatuminen voidaanko salaiset tiedot dumpata levylle selväkielisinä? Mika Katara: Ohjelmistojen testaus, 2011 455 Toisten ohjelmien kautta tulevat uhat Yhä suuremmassa määrin ohjelmat käyttävät muita ohjelmia erilaisten rajapintojen kautta Mitä tapahtuu, jos jokin toinen ohjelma joutuu hyökkäyksen uhriksi tai kaatuu? Testaajan täytyy selvittää kytkennät muihin ohjelmiin ja selvittää tilanteet, joissa nämä saattavat aiheuttaa uhan tietoturvalle Esimerkiksi kommunikoitaessa verkon kautta on syytä varmistaa, että ohjelmisto toimii oikein laittomien pakettien, liian lyhyiden ja liian pitkien pakettikehysten yms. kanssa fuzz-testaus on tässä jälleen paikallaan vastaavia huolen aiheita liittyy myös tavallisiin rajapintoihin Mika Katara: Ohjelmistojen testaus, 2011 456

Ohjelmiston itsensä suojaaminen Joskus ohjelma sisältää algoritmeja yms., jotka antavat edun kilpailijoihin nähden Tällöin on järkevää suojautua takaisinmallintajia vastaan, jotka voivat yrittävät selvittää koodin sisältöä esim. disassembleria käyttäen Mika Katara: Ohjelmistojen testaus, 2011 457 Monesti hyökkäykset saattavat tulla monelta rintamalta yhtä aikaa Esim. blokataan sovelluksen pääsy johonkin kirjastoon ja annetaan käyttöliittymän kautta laiton syöte samanaikaisesti Joskus myös ohjelmistoon sisäänrakennetut ominaisuudet saattavat tarjoa turvallisuusreikiä Binääriin on esimerkiksi saattanut jäädä mukaan instrumentoitua testikoodia, joka tarjoaa valmiita koukkuja testitapausten suorittamista varten Yksittäisen komponentin kehittäjä on saattanut olla tietämätön kokonaisuudesta, johon komponentti kuuluu Mikäli esim. parametrina välitettävä tieto on salaista, sitä ei saa kirjoittaa edes väliaikaisesti selväkielisenä levylle Mika Katara: Ohjelmistojen testaus, 2011 458

Esimerkkihyökkäyksiä Blokkaa sovelluksen kutsut (dynaamisiin) kirjastoihin Käytetään työkalua, jonka avulla voidaan tarkkailla mitä kirjastoja sovellus kutsuu missäkin tilanteessa ja blokataan kutsut johonkin tiettyyn kirjastoon Tarkoituksena testata, että sovellus ei vaaranna tietoturvaa vaikka kirjastoa ei olisikaan saatavilla Mika Katara: Ohjelmistojen testaus, 2011 459 Usein kehittäjät olettavat, että kirjastot ovat aina saatavilla tämä on erityisen vaarallinen oletus, mikäli kirjastofunktiota käytetään jonkin tietoturvaan liittyvän asian varmistamiseen (esim. käyttäjien oikeudet) mikäli yritetään kutsua kirjastofunktiota, johon pääsy on blokattu, seurauksena on yleensä poikkeuskäsittelyn käynnistyminen usein poikkeustenkäsittelijöitä ei ole testattu niin hyvin kuin muuta koodia Mika Katara: Ohjelmistojen testaus, 2011 460

seurauksen voi olla sovelluksen kaatuminen ja salaisten tietojen dumppaaminen näytölle tai levylle sovellus voi myös näyttää jatkavan toimintaa normaalin tapaan, vaikka kirjastofunktion tarjoamaan palvelua ei olisikaan käytettävissä tämä voi olla merkki esimerkiksi siitä, että sovelluksessa ei tarkasteta jotain paluuarvoa vaikka pitäisi seurauksena voi olla jopa väärien oikeuksien myöntäminen käyttäjälle Mika Katara: Ohjelmistojen testaus, 2011 461 Etsi epäilyttäviä optioita ja niiden yhdistelmiä Sekä komentoriviltä, että graafisen käyttöliittymän kautta annettavien optioiden testaus on vaikeaa mahdollisten kombinaatioiden suuren määrän vuoksi Mikäli testauksessa keskitytään vain käyttäjän kannalta oleellisimpiin vaihtoehtoihin, on hyvinkin mahdollista, että joidenkin optioiden valinnan seurauksena sovellus suorittaa testaamatonta koodia Kannattaa yrittää etsiä sellaisia optioiden kombinaatioita, joiden yhteisvaikutuksesta tietoturva voi vaarantua Mikäli kyseessä on vanhan ohjelman uusi versio, kannattaa tutustua myös edelliseen versioon ja sen dokumentaatioon Mika Katara: Ohjelmistojen testaus, 2011 462

mikäli jokin optio on kadonnut uuden version dokumentaatiosta, kannattaa kokeilla vieläkö toteutus tukee sitä ja jos tukee, toimiiko se turvallisesti Käyttäjältä tulevan syötteen tarkastaminen voi olla toteutettu vain osalle optioista jos sovellus kysyy esimerkiksi osoitetta, ja maa voidaan valita ennalta määrätystä joukosta valikkoa käyttäen, voi postinumerokentän tarkastaminen riippua siitä mikä maa valitaan sovellus voi sallia ylipitkän ja kontrollimerkkejä sisältävän postinumeron syöttämisen» olisiko mahdollista syöttää SQL-lauseita ja suorittaa niitä? vai koodataan postinumerontarkastusalgoritmi myös Norsunluurannikon osoitteille? Mika Katara: Ohjelmistojen testaus, 2011 463 Porttiskannaus Verkkoa hyödyntävien sovellusten on suojauduttava porttiskannaajia vastaan Käytetään testauksen apuna porttiskanneria Testataan erityisesti sovellusspesifisten porttien käyttö (numerot 1024-65535) Mikäli sovellus yrittää salata avoinna olevan portin antamalla virheilmoituksen kytkeytymisyrityksestä, täytyy virheilmoituksen olla standardimuotoa, ettei se herättäisi epäilyksiä Mika Katara: Ohjelmistojen testaus, 2011 464

Etsi vaihtoehtoisia tapoja tehdä sama asia Kuinka monella eri tavalla voit Windowsissa avata Wordasiakirjan? Ovatko kaikki tavat varmasti testattu olevan turvallisia? How to break software security -kirjan kirjoittajat löysivät tietoturva-aukon Windows XP:stä seuraavasti: Mika Katara: Ohjelmistojen testaus, 2011 465 Koska Windows Exploreria voi käyttää moneen samaan tarkoitukseen kuin Internet Exploreria, luetaan MS Exchange Serverin Outlook Web Access rajapintaa käyttäen ensin sähköpostit IE:llä siten, että käynnistetään IE WE:n kautta Session jälkeen suljetaan sekä WE- että IE-ikkunat Seuraavaksi otetaan yhteyttä WE:llä sähköpostipalvelimeen ja kas kummaa, päästään sisään ilman salasanan kyselyä! Kun yritetään lukea yksittäisiä posteja erillisestä ikkunasta, salasanaa kysytään, mutta käyttämällä Outlookin esikatselua salasanaa ei kysyä Opetus: tietoturva saatiin murrettua kun käytettiin vaihtoehtoista tapaa tehdä sama asia korvattiin Internet Exprorer Windows Explorerilla korvattiin Outlookin posti-ikkuna esikatselulla Huom! Tämä vika on sittemmin korjattu Mika Katara: Ohjelmistojen testaus, 2011 466

Tietoturvatestauksen ongelmia Testauksen täytyy löytää kaikki ohjelmistossa olevat tietoturvaaukot, vastustajalle riittää yksi Tietoturvaan liittyvät häiriöt ovat yleensä paljon huomaamattomampia kuin esim. toiminnallisuus- tai suorituskykyhäiriöt Mika Katara: Ohjelmistojen testaus, 2011 467 11. Staattisen testauksen tekniikat Laadunvarmistajan ja testaajan työkalupakkiin kuuluu toisiaan täydentäviä tekniikoita. Seuraavassa tutustutaan hyväksi havaittuihin ryhmätyötekniikoihin sekä hieman myös automaattiseen koodin analysointiin. Mika Katara: Ohjelmistojen testaus, 2011 468

11.1 Tarkastus Koostettu mukaillen lähteestä: Ahtee, Haikala, Märijärvi: Tarkastukset (koulutusmateriaali) Inspection IEEE 610.12-1990 (Standard Glossary of Software Engineering Terminology): A static analysis technique that relies on visual examination of development products to detect errors, violations of development standards, and other problems. Types include code inspection; design inspection. Projektin sisäinen, 3-6 osallistujaa Hyvin muodollinen verrattuna muihin ryhmätyötekniikoihin Aikataulutus joustavaa, useita tarkastuksia projektin vaiheen aikana Tarkastetaan kerralla pieniä kokonaisuuksia Mika Katara: Ohjelmistojen testaus, 2011 469 Tekniikan kehitti Fagan IBM:llä 1970-luvulla Tarkastuksia pidetään tehokkaimpana tunnettuna laadunvarmistuskeinona Tukee prosessia ja projektia mm. Pyrkimällä poistamaan virheet mahdollisimman varhaisessa vaiheessa Tekemällä projektin etenemisen näkyväksi hyväksytty tarkastus vastaa yhden etapin saavuttamista Jakamalla tietoa useammalle henkilölle Mika Katara: Ohjelmistojen testaus, 2011 470

Tarkastustilaisuus kestää n. 2 tuntia, jonka aikana voidaan tarkastaa enintään 50 sivua dokumenttia tai 500 riviä koodia Löydetään noin 50-80 % virheistä Tarkastukset kuluttavat noin 5-15 % työajasta Erittäin kustannustehokasta! Vaikka menettely ei lisääkään työmäärää kovin paljon, johdon sitoutuminen tarvitaan Mika Katara: Ohjelmistojen testaus, 2011 471 Tarkastukset ohjelmistoprosessissa Kerrasta oikein Spesifikaatio Tee Luonnos tarkasta OK Vaihetuote n (Vaihetuote n-1) Työstä Mika Katara: Ohjelmistojen testaus, 2011 472

Tarkastaa voidaan mm. Tarjous, sopimus Määrittelydokumentti Projektisuunnitelma Suunnitteludokumentti Testaussuunnitelma Koodi Käyttäjälle menevä dokumentaatio Koulutusmateriaali Mika Katara: Ohjelmistojen testaus, 2011 473 Tarkastustilaisuuden roolijako Puheenjohtaja Tarkastettavan vaihetuotteen tekijä Sihteeri = usein tekijä Tarkastaja = kaikki Esittelijä voi olla tekijä vain kooditarkastuksissa Sovellusalueen tms. asiantuntija, kieliasun tarkastaja, käyttäjänäkökulman edustaja, testausasiantuntija jne. joku voi keskittyä muistinhallinnan tarkastamiseen, toinen silmukoihin, kolmas algoritmeihin, neljäs rajapintoihin jne. Mika Katara: Ohjelmistojen testaus, 2011 474

Nyrkkisääntöjä Mikäli ei voida tarkastaa kaikkea, keskitytään tärkeimpiin osiin Huolellinen valmistautuminen on erittäin tärkeää tarkastettava materiaali jakoon vähintään 3 vrk etukäteen tarkastustilaisuus kannattaa peruuttaa, jos sen onnistumiselle ei ole riittäviä edellytyksiä esim. liian keskeneräinen vaihetuote Arvioidaan aina tuotetta, ei tekijää Tavoitteena ongelmien löytäminen eikä niiden ratkaiseminen Korjaukset kosmeettisiin virheisiin voi toimittaa sihteerille jälkikäteen Mika Katara: Ohjelmistojen testaus, 2011 475 Kannattaa pohtia etukäteen sääntöjä, jotka helpottavat kohteen tarkastamista Esim. ottaako vaatimus huomioon asiakkaan todellisen tarpeen Säännöt kannattaa valita huolella kohteen, organisaation, prosessin, riskien yms. mukaan Jo muutamalla säännöllä päästään hyviin tuloksiin (Marko Komssi, EuroSTAR 2004) Sääntöjen tarkkuutta voidaan kasvattaa prosessin edetessä Tarkastuksista on kehitetty IBM:llä myös sellainen versio, joka ei edellytä etukäteisvalmistelua: E. Farchi, S. Ur: Selective Homeworkless Reviews, Proceedings of the 2008 International Conference on Software Testing, Verification, and Validation IEEE Computer Society Washington, DC, USA Mika Katara: Ohjelmistojen testaus, 2011 476

Tarkastusten kypsyystasot Tarkastuksia pidetään Tarkastuksista on jotakin hyötyä Tarkastukset ovat tehokkaita Tarkastuksista kerätään tilastotietoja Virheanalyysejä ja tarkastuslistoja tehdään kokemusten perusteella Kerättyjä tietoja käytetään tarkastus- ja ohjelmistoprosessin parantamiseen hyödyllinen projektille hyödyllinen organisaatiolle Mika Katara: Ohjelmistojen testaus, 2011 477 11.2 Katselmointi Review, technical review IEEE 610.12-1990: A process or meeting during which a work product, or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Types include code review, design review, formal qualification review, requirements review, test readiness review. Käytetään vaiheen päättymisen toteamiseen Esim. määrittely- ja suunnitteluvaihe Katsotaan formaalisti, että kaikki vaiheen lopetusehdon vaatimukset on täytetty Tavoitteena tehdä projektin eteneminen näkyväksi Halutaan saavuttaa konsensus, ei niinkään löytää virheitä Mika Katara: Ohjelmistojen testaus, 2011 478

Projektin katselmukset ja tarkastukset [Haikala&Märijärvi 06]: esitutkimus& sopimus määrittely suunnittelu tarkastus katselmointi, toimittajan katselmointi, asiakas mukana ohjelmointi ja moduulitestaus integrointi järjestelmätestaus aika Mika Katara: Ohjelmistojen testaus, 2011 479 Huom! Jotta asia ei olisi liian yksinkertainen, puhutaan monissa organisaatioissa (esim. koodin) katselmoinnista vaikka tosiasiassa käytetäänkin tarkastusmenettelyä tai jotain sen kevennettyä muunnelmaa Koska kyse on kuitenkin tavoitteiltaan erilaisista tekniikoista, on syytä selvittää etukäteen, onko tarkoitus todella katselmoida vai tarkastaa Mika Katara: Ohjelmistojen testaus, 2011 480

11.3 Läpikäynti Walkthrough IEEE 610.12-1990: A static analysis technique in which a designer or programmer leads members of the development team and other interested parties through a segment of documentation or code, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems. Tehdään yleensä vain koodille, tavoitteena virheiden löytäminen Tekijä selittää mitä ohjelma hänen mielestään tekee Mika Katara: Ohjelmistojen testaus, 2011 481 Tarkastukseen verrattuna läpikäynti Korostaa tekijän roolia tilaisuudessa On epämuodollisempi Vaatii vähemmän koulutusta Löytää vähemmän virheitä Ei yleensä ole yhtä kustannustehokas Mika Katara: Ohjelmistojen testaus, 2011 482

11.4 Ohjelman staattinen analyysi Idea: analysoidaan lähdekoodia automaattisesti ilman sen suorittamista Tarkoituksena Löytää koodista virheitä Huomata poikkeamia sovituista koodauskäytännöistä (tyylioppaat) Generoida koodista dokumentaatiota Laskea arvoja ohjelman pituutta, monimutkaisuutta yms. kuvaaville mittareille Mika Katara: Ohjelmistojen testaus, 2011 483 Hyödynnettävät tekniikat perustuvat yleensä tieto- ja kontrollivuoanalyysiin, rajoitusten ratkaisemiseen (constraint solving) yms. Ensimmäinen suuren yleisön käyttöön tarkoitettu staattinen koodianalysaattori oli Unixin mukana levinnyt Lint Lintin tarkoituksena oli löytää tiettyjä C-kielelle tyypillisiä virheitä, joita senaikaiset kääntäjän eivät havainneet Mika Katara: Ohjelmistojen testaus, 2011 484

Minkä tyyppisiä virheitä voidaan löytää? Esim. Syntaksivirheet Samaa koodia useammassa kuin yhdessä paikassa, kuollut koodi (ei suoriteta ikinä) Koodin ylläpidettävyys ja siirrettävyysongelmia Alustamattomat muuttujat Käyttämättömät paluuarvot Virheellinen osoitinten käyttö Puskurin ylivuodot yms. tietoturvaongelmat Mika Katara: Ohjelmistojen testaus, 2011 485 Tunnettuja staattisia analysaattoreita: PC-Lint, Coverity, PolySpace, KlocWork Ominaista korkea hinta, lukuun ottamatta ensimmäistä Skaalautuvuus voi osoittautua ongelmaksi Väärien hälytysten määrä voi nousta suureksi Potentiaalisesti maksavat itsensä takaisin hyvinkin nopeasti löytämällä arvokkaita virheitä turvallisuuskriittisestä koodista Mika Katara: Ohjelmistojen testaus, 2011 486

Mitä apua dokumentointiin? Esim: Javadoc-tyyppinen API-dokumentaatio Doxygen-tyyppinen graafinen malli (UML) ohjelmistosta www.doxygen.org Kutsuhierarkia bar1() foo() bar2() Mika Katara: Ohjelmistojen testaus, 2011 487