Monday 17 October 2011

Testausheuristiikat 6/7

FDSFSCURA
Tekniikkoihin ja lähestymistapoihin pureutuva FDSFSCURA tarjoaa on omiaan kertomaan MITEN ja MITÄ kannattaa testata. Tekniikoita ovat siis: F = Function Testing, D = Domain Testing, S = Stress Testing, F = Flow Testing, S = Scenario Testing, C = Claims Testing, U = User Testing, R = Risk Testing, A = Automatic Testing. Tällä pyritään valottamaan sitä, että on useampiakin tapoja tehdä testausta kyseiseen tuotteeseen.

Toiminnallinen testaus on käytännössä sitä, että testataan "mitä voi tehdä". Tunnistetaan funktioiden ja toiminnallisuuksien tarkoamat ominaisuudet ja testataan niihin liittyviä asioita. Hyvä mittaamaan kykyä luotettavuuden sijaan. Toiminnallinen testaus on yleensä mukana muissakin heuristiikoissa tavalla tai toisella, mutta tässä tarkoitetaan nimenomaan toiminnallisuuden tarkastamista, että "se toimii oikein".

Toimialakohtainen testaus liittyy yleensä dataan. Kattamalla erilaisia datakombinaatioilla voidaan löytää asioita, joita puhtaasti toiminnallinen testaus ei löydä. Esimerkiksi vakuutusalalla on useita testaustekniikoita, testi-ideoita ja variaatioita, jotka koskevat vain ko. alaa. Myös logistiikka-ala, pankkiala, jne. sisältävät oman toimialan erikoistapauksia.

Stressitestauksella pyritään kyykyttämään järjestelmää parhaalla mahdollisella tavalla. Näin saadaan esiin muistivuotoja, validointivirheitä ym. jotka nousevat esiin vain paineen alla. Tietokantatasolla saadaan massatestauksella aikaan mahdolliset lukkotilanteet sekä datan ylikirjautuminen tai kirjautumatta jääminen.

Ketjuttamisella voidaan testata toimintoja toisen perään. Voidaan myös testata prosessia niin, että jätetään pakollisia toimintoja välistä tai tullaan prosessiin keskeltä mukaan. Näin löydetään ongelmia, jotka eivät ole riippuvaisia yhden toiminnallisuuden asioista. Mallipohjaisessa testauksessa testausautomaatiolla voidaan toteuttaa helpostikin pitkiäkin ketjuja sekä niiden variaatioita.

Skenaariotestauksella testataan asioita tuotteen ympäriltä sekä liittymistä. Skenaario on eräänlainen käyttötapaus, mutta joka on lähemmin yhteydessä todelliseen käyttöön ja ympäröiviin asioihin. Käyttötapauksia hyväksikäyttäen voidaan luoda sellaisia skenaarioita, missä on muuttujina esimerkiksi alusta, käyttäjän taito, aika, data ja/tai muut muuttujat.

Väitetestauksella tarkoitetaan siis määrityksiä, lupauksia, vaateita. Niitä testataan sekä tuotetta vasten ja tuotetta testataan niitä vasten. Tarkoitus on sekä tarkentaa "väitettä" ja tuotetta. Väitteet voidaan myös poimia asiakkaan tai tuotteen omistajan puheesta ja testata, josko "luvataan liikoja".

Käyttäjätestaus liittyy usein käyttäjän kykyihin käyttää järjestelmää. Miten punavihersokea pystyy aistimaan dashboradin elementit? Miten ummikko pystyy käyttämään kompleksista toiminnanohjausjärjestelmää? Entä käyttäjät, jotka käyttävät suoraan ohjeesta? Entä käyttäjät, jotka kokeilevat ja testailevat tuotetta?

Riskitestauksella pyritään tunnistamaan riskejä ja yrittämään toteuttaa ne. Voiko riskin toteuttaa järjestelmällä? Voiko siitä seurata ongelmia? Tässä kannattaa käyttää hyväksi asiantuntemusta myös liiketoiminnasta ja kehittäjiltä, jotta voidaan löytää ne suurimmat rsikit omaavat osa-alueet. Riskitestauksella voidaan myös mitigoida riskejä tai nostaa esiin uusia riskejä.

Automaatiotestaus tarkoittaa käytännössä testi ajamista tuhanisa kertoja tai automatisoimalla testin muuttumaan hieman. Näin voidaan nopeasti kehittää suuri määrä testejä joilla voidaan löytää ongelmia, joita manuaalinen testaus ei löydä. Esimerkiksi Brute force -tietoturvatestaus löytää helpommin aukkoja tietoturvasta kuin manuaalisesta samojen testien ajaminen. Lisäksi tietoturvatestausta harvemmin kannattaa toteuttaa manuaalisesti, sillä usein tietoturva-aukkoja etsitään koneitse.

5 comments:

  1. Moi Pekka,

    Hyvä kirjoitus! Tekisi enemmänkin mieli pätkiä blogausta osiin ja tarkastella eri kohtia. Viimeinen kappale tosin nosti harjakseni pystyyn, joten aloitan siitä.

    Tarkoitat ilmeisesti automaatiotestauksella automoitua funktionaalista mustalaatikkotestausta. Se on pieni pintaraapaisu automaatiotestauksesta, jota mielestäni kannattaa käyttää vain muutamassa erityistapauksessa. Usein onkin tärkeämpää näyttää, että automaatio ei löydä ongelmia kuin toisinpäin.

    "Brute force" -tietoturvatestaus löytää aukkoja vain niissä tapauksissa, kun ne on tehty jo design-vaiheessa, tai koodia ei ole kunnolla katselmoitu. Molemmissa tapauksissa testaus on aika kelvotonta, jos ongelmat löytyvät vasta automaatiolla.

    Tietoturvatestaus on pääosin manuaalista. Potentiaalisia aukkoja voidaan etsiä mm. skannereilla, mutta suurin osa itse tietoturvatestauksesta on manuaalista. Toki tässä on mukana myös koodianalysaattorit, kääntäjät, skannerit ja niin edelleen, mutta nehän yleensä toimivat ainoastaan syötteiden käsittelijöinä ja esim. muistivuotojen tarkistajina. Itse testaaminen silti jää ihmisen työksi.

    Vastauksen motivaattorina muuten toimi tämä kirjoituksesi: http://mitenmatestaan.blogspot.com/2011/08/miten-saada-lisaa-aanta-suomen.html

    Mukavaa loppusyksyä!


    Terveisin,
    Jari

    ReplyDelete
  2. Kiitos Jari!

    Hienoa, että tartut noihin asioihin! En tietenkään voi sanoa olevani kovan alan ammattilainen turvallisuustestauksesas, mutta hyviä pointtereita.

    Tässä tapauksessa automaatio oli ainoastaan heuristiikka, jolla voidaan luoda jokin heräte toiminnalle. Sanotaan, että "miten automaatiota voisi käyttää hyväksi tässä kontekstissa" ja ideoita alkaa tulemaan. Tietoturvatestaukseen pätee varmasti joitakin muitakin heuristiikkoja, jotka on mainittu yllä, mutta ei välttämättä -> Heuristiikka ei aina päde, koska se on heuristiikka.

    Ja hienoa, että ääntä saadaan kuuluville. Ja pätki ihmeessä! :) Kaikki kommentointi ja parjaaminen tuottavat todennäköisesti uusia näkökulmia.

    ReplyDelete
  3. Kiitos vastauksesta, Pekka!

    Ymmärsin jostain syystä hieman väärin tuon vikan kappaleen. Taisin halata niitä puita enkä nähnyt siltä Puolen Hehtaarin metsää.

    Automaatiotestaus voitaisiin siis kuvata:
    Automaatiolla pyritään kattamaan tilanteita, joissa kone on ihmistä parempi, kuten suuren data-/testimäärän suorittaminen. Etsi sellaisia kohteita ohjelmistosta, joissa automaatiosta voisi olla hyötyä. Tällaisia tilanteita on mm. datan jatkuva lisääminen, muokkaaminen ja poistaminen tietokannasta, sekä outputtien varmentaminen satunnaisten input-kombinaatioiden pohjalta.

    FDSFSCURA -listaus on hyvä ja mielenkiintoinen. Varmasti ainakin herättää keskustelua, kunhan saan purettua sitä lisää mielessäni. Mihin noista yhdeksästä kohdasta mielestäsi parhaiten sopii "tehdäänkö oikeaa tuotetta"? Soveltuuko näiden testitekniikoiden käyttö parhaiten eri sessioissa vai teetkö mieluiten tarkistuksia monta erilaista kysymystä mielessäsi?

    Ihan mahtava päästä lähemmäs toisten (suomalaiseten) tapoja testata!


    Terveisin,
    Jari

    ReplyDelete
  4. Hyvin muotoilit tuon stressitestauksen. Oma määritelmäni on kovin samanlainen eli tähtään stressitestuaksella aina siihen, että löytyy kohta jossa järjestelmä hajoaa. Kun järjestelmän hajoamispiste on tiedossa, niin totean stressitestin tuloksen olevan valmis.

    Järjestelmän hajoamispiste tulee olla aina selvillä, niin silloin tilanteisiin voi varautua etukäteen.

    Esimerkki: järjestelmän tulee kestää 10 000 yhtäaikaista käyttäjään. Rakennan testipenkin joka kuormittaa järjestelmää 100 000 käyttäjän edestä. Jos systeemi ei mene rikki, niin lisään kuormaa niin kauan kunnes systeemi hajoaa. Tämän jälkeen tilanteesta syntynyt data analysoidaan.

    Nyt tiedämme, että mitä systeemi oikeasti tulee kestämään ja mikä parasta, niin kaikki ymmärtävät sen, että systeemi todellakin hajoaa jos se joutuu äärimmäiseen stressiin. Tämä on kokemukseni mukaan eräänlainen ahaa-elämys vähemmän testauksen kanssa tekemisissä oleville. Voisin melkein sanoa, että stressitestauksen paras anti on juurikin se, että tiedämme jo aikaisessa vaiheessa mitä systeemi kestää ja mitä se ei kestä ja silloin asialle voi tehdä paljonkin.

    ReplyDelete
  5. Terve Peksi,

    En itsekään ole mikään tietoturvaekspertti, mutta Jari on täsmälleen oikeassa siinä, että tietoturvatestaus on pääosin manuaalista. Ja miksi? Siksi, että usein tietoturvatestaaja etenee tutkivan testauksen ihanteiden mukaisesti eli seuraava testi riippuu edellisen testin tuloksista. Ei tarvitse paljoa selittää, miksi automaatio ei tällaiseen kuvioon pysty.

    Olen ollut parissa seminaarissa, joissa on penetraatiotestattu käyttöliittymiä. Näissä nuoret kaverit rummuttivat kaikenlaisia inputteja hakien virheilmoituksia ja etenkin heikkouksia niissä, toki kaivaen sorsaa, manipuloiden URL:eja, muuttaen käyttöliittymien ulkoasua skripteillä, yms. kaikenlaista hienoa, jota tuijotin monttu auki. Virheilmoitukset antoivat tietoa, jonka perusteella kaverit pääsivät pidemmälle ja kappas, kun olivat yhtäkkiä kiinni suoraan tietokannoissa ja sovelluspalvelimissa. Tästä alkoikin sitten mystisen tekninen osuus ja lähdin tauolle syömään pullaa... :)

    Näin tutustuin ensimmäisen kerran tutkivaan testaukseen ja ihastuin välittömästi!

    Sami

    ReplyDelete