© Conformiq Software Ltd. | www.conformiq.com The Future of Software Testing Oliosuuntautunut testaus.

Esitys aiheesta: "© Conformiq Software Ltd. | www.conformiq.com The Future of Software Testing Oliosuuntautunut testaus."— Esityksen transkriptio:

1 © Conformiq Software Ltd. | www.conformiq.com The Future of Software Testing Oliosuuntautunut testaus

2 © Conformiq Software Ltd. | www.conformiq.com Nykyiset näkemykset olio- suuntautuneesta testauksesta Optimistinen: oliosuuntautuneen maailman teknologia- ja ohjelmistoprosessit vähentävät testauksen tarvetta huomattavasti Minimalistinen: testaus pysyy elintärkeänä oliosuuntautuneissa toteutuksissa, mutta se tulee olemaan helpompaa ja halvempaa Laajeneva: oliosuuntautuneiden järjestelmien ominaisuudet vaativat uusia lähestymistapoja, jotta saavutetaan riittävä testauksen taso

3 © Conformiq Software Ltd. | www.conformiq.com Kaikki kolme näkemystä ovat oikeassa Oliosuuntautunut suunnittelu ja komponenttien uudelleenkäyttö voivat vähentää uudelleen kirjoitetun koodin määrää. Tämä vuorostaan vähentää testejä (optimistinen näkemys). Oliosuuntautuneen suunnittelun käyttö ei muuta mitään testauksen perusperiaatteita. Se mikä muuttuu, on testattavien yksikköjen osista koostuva rakenne (minimalistinen näkemys). Kapselointi, perintä, monimuotoisuus (polymorphism), viestinvälitys, poikkeukset jne. vaativat uusia lähestymistapoja testaukselta (laajeneva näkemys).

4 © Conformiq Software Ltd. | www.conformiq.com Eroavaisuudet perinteisestä testauksesta Virhehypoteesit Testitapaussuunnittelu Testauksen automatisointi Testausprosessi [Binder 1996]

5 © Conformiq Software Ltd. | www.conformiq.com Virhehypoteesi Ovatko jotkut oliosuuntautuneen ohjelmiston puolet toisia todennäköisemmin virheellisiä? Minkä tyyppiset virheet ovat todennäköisiä? Kuinka voidaan rakentaa paljastavia testitapauksia? Mitä vaikutusta testin laajuudella on virheen paljastamisen todennäköisyyteen? Missä määrin virhemallit ovat sovellus-, ohjelmointikieli- ja kehitysympäristökohtaisia? [Binder 1996]

6 © Conformiq Software Ltd. | www.conformiq.com Ehdokkaita virhehypoteesille (1/3) Perintävirheet: Perintä on loistava virheiden lähde: Se heikentää kapselointia; Syntyy virheitä, jotka ovat samanlaisia kuin ne, jotka liittyvät globaaliin dataan perinteisissä tuotteissa; Sitä voidaan käyttää epätavallisen voimakkaana ohjelmoijan mukavuuden korvaajana; Suuret perintähierarkiat voivat olla vaikeita ymmärtää, joka johtaa virheisiin ja testattavuuden huononemiseen; Semanttisia epäyhteensopivuuksia syntyy helposti kun aliluokkien metodeilla on erilaiset semantiikat ja ne vaativat erilaisia testejä; Moniperintä sallii yliluokan ominaisuudet samoilla nimillä, mahdollistaen nimeämisvirheet; Muutokset yliluokkiin voivat laukaista virheitä perityissä aliluokissa. [Binder 1996]

7 © Conformiq Software Ltd. | www.conformiq.com Ehdokkaita virhehypoteesille (2/3) Kapselointivirheet Oikein käytettynä kapselointi on turvallinen oliosuuntautunut ominaisuus. Itse asiassa suurimmat virheet tapahtuvat kun kapselointi ajetaan yli: Suora pääsy olion attribuutteihin aiheuttaa paljon riippuvuuksia olioiden välillä; Oliorajapintojen puutteellinen käyttö voi johtaa tilanteisiin, joissa minkä tahansa olion metodin muuttaminen rikkoo koodia viestinvälitysoliossa. Olion kapselointi tekee joskus testitapausten luomisen vaikeaksi piilottamalla liikaa [Binder 1996]

8 © Conformiq Software Ltd. | www.conformiq.com Ehdokkaita virhehypoteesille (3/3) Monimuotoisuusvirheet: Monimuotoisuus korvaa eksplisiittisen käännön- aikaisen sitomisen ja staattisen tyypin- tarkastuksen implisiittisellä ajonaikaisella sitomisella ja tyypintarkastuksella. Se on monien virheiden lähde: Mitä syvempi hierarkiapuu ja mitä laajempi testattava sovellus, sitä korkeampi on todennäköisyys, että dynaamisesti sidottu metodia käytetään väärin; Monimuotoisuuden ja metodien perinnän yhdistelmä tekee aliluokkien ja niiden toiminnan käyttäytymisen ymmärtämisestä hyvin vaikeaa; Monimuotoisuus ja myöhäinen sitominen voi helposti johtaa viestien lähettämiseen väärälle oliolle, koska voi olla vaikeaa tunnistaa ja käyttää kaikkia sidoksia; Kun sitominen on tehty ajon aikana, tyyppitarkastuksen vastuu on palvelimella (kääntäjän sijaan) ja viestin, rajapinnan tai metodin väärinkäyttö käy äärimmäisen yksinkertaiseksi; Monimutkaiset monimuotoiset suhteet voivat sekoittaa testaajia ja kehittäjiä, esimerkiksi peittämällä virheen alkupisteen; Hienovaraisia nimeämisvirheitä on helppo tehdä ja vaikea löytää. [Binder 1996]

9 © Conformiq Software Ltd. | www.conformiq.com Testitapaussuunnittelu Mitä tekniikoita voidaan käyttää testitapausten rakentamiseen malleista, määrittelyistä ja toteutuksista? Kuinka paljon testausta on riittävästi metodeille, luokille, luokkaryhmille, sovellusjärjestelmille ja uudelleenkäyttökirjastojen komponenteille? Millä laajuudella perittyjä ominaisuuksia pitäisi uudelleentestata? Kuinka abstrakteja ja yleisiä luokkia pitäisi testata? Mitkä yhteistyökaavioiden ymmärtämisen mallit ovat hyödyllisiä testaukselle? Kuinka testattavan olion, luokan tai järjestelmän abstraktien ja konkreettisten tilojen malleja voidaan käyttää? Kuinka kokoelma- ja säilytysluokkia voidaan testata? Kuinka tilariippuvainen käytös voidaan todentaa kun tilanhallinta on usein jakautunut koko sovelluksen laajuisesti? Kuinka dynaamisesti sidottujen asiakkaat ja palvelimet voidaan testata? Kuinka uusintatestit voidaan muodostaa ja ajaa, jotta varmistetaan luokkien yhtenäisyys? Kuinka esitysten ja toteutusten sisältämää tietoa voidaan käyttää testitapauksen odotettujen tulosten kehittämiseen tai automaattiseen luomiseen? [Binder 1996]

10 © Conformiq Software Ltd. | www.conformiq.com Testauksen automatisointiin liittyviä kysymyksiä Kuinka testitapaukset pitäisi esittää? Kuinka testitapauksia pitäisi soveltaa? Mikä on tynkien ja ajureiden oikea rooli? Kuinka testien tulokset pitäisi esittää ja arvioida? Koska raportteihin testaamattoman olion tilasta voidaan luottaa? Mikä on tehokas integrointitestauksen strategia? Mikä rooli sisäänrakennetuilla testeillä voi olla? Pitäisikö sisäänrakennetut testit olla tarjolla sovelluskomponenteissa, ohjelmointikielissä ja/tai kehitystyökaluissa? [Binder 1996]

11 © Conformiq Software Ltd. | www.conformiq.com Testausprosessiin liittyviä kysymyksiä Milloin testauksen pitäisi alkaa? Kenen pitäisi tehdä testausta? Kuinka testaustekniikat voivat auttaa virheiden estämisessä? Kuinka testausaktiviteetit on integroitu ohjelmistokehityksen prosessimalliin? Kuinka testaus voi edesauttaa uudelleenkäyttöä? Missä laajuudessa uudelleenkäytettäviä testijaksoja tulisi pitää välttämättömänä osana uudelleenkäytettävää komponenttikirjastoa? Mikä on tehokas testaus- ja integrointistrategia, jos iteratiivista lähestymistapaa pidetään parempana kuin oliosuuntautunutta kehitystä? [Binder 1996]

12 © Conformiq Software Ltd. | www.conformiq.com Lähteet R. Binder, Testing Object-Oriented Software: a Survey. Software Testing, Verification and Reliability. Vol. 6, pp 125-252 (1996)