Ohjelmistotekniikka - Luento 4 Luku 19: Oliosuuntautuneiden sovellusten testaus - oliotestauksen testaustasot - oliotestauksen ominaispiirteitä ja testausmenetelmiä - luokkatason testausmenetelmät Luku 20: Web sovellusten testaus - Web sovelluksen testausprosessi - Web sovelluksen testaustapoja - sisällön, navigoinnin ja konfiguraation testaus Luku 21: Formaali mallintaminen ja verifiointi - matemaattisen notaation soveltaminen formaaliin spesifiointiin - OCL kieli - puhdastilamenetelmä
OOT testaustasot Luokkatestaus vastaa yksikkötestausta luokan operaatiot testataan luokan tilakäyttäytyminen testataan Integrointitestauksessa kolme strategiaa säieperustainen testaus - integroidaan luokat, joita tarvitaan käsittelemään jonkin syöte tai tapahtuma käyttöpohjainen testaus - integroidaan luokat, joita tarvitaan jokin käyttötapauksen mukaiseen toimintaan ryväspohjainen testaus - integroidaan luokat, joita tarvitaan toteuttamaan haluttu yhteistyö Järjestelmätestaus ja validointitestaus kuten perinteisessä testauksessa!2
Olioperustainen testaus Aloitetaan arvioimalla (tarkastamalla) OOA ja OOD mallien oikeellisuutta (syntaksi & semantiikka) ja yhdenmukaisuutta tutkimalla CRC korteilla kuvatut luokkien vastuut ja yhteistyö muiden luokkien kanssa Muutokset testausstrategiassa yksikkö-käsite laajenee kapseloinnin tuloksena integrointi kohdistuu luokkiin ja niiden suoritukseen säikeessä, käyttöskenaarion tai yhteistyön (ryväs) rajaamana validointi käyttää perinteisiä mustalaatikko-menetelmiä!3
Oliotestauksen ominaispiirteet Luokkatestaus ja luokkahierarkia Testataan luokan jokainen metodi (ja konstruktori) Testataan metodien vaikutukset luokan tilaan (attribuutteihin) tarvitaan omia (built-in) metodeja, joilla saadaan tila näkyville Periytyminen ei tee tarpeettomaksi kaikkien johdettujen luokkien läpikotaista testausta. luokan muuttuessa joudutaan testaamaan kaikki ko. luokkaa käyttävät sovellukset sekä luokasta perityt aliluokat aliluokkaan tehty muutos aiheuttaa perittyjen operaatioiden testaustarpeen.!4
Olioperustaiset testausmenetelmät Vikapohjainen testaus Perustuu olettamuksiin todennäköisistä vioista (faults) tutkiva (exploratory) testaus Analyysi- ja suunnittelutason kuvaukset antavat vihjeitä todennäköisistä vioista Skenaarioperustainen testien suunnittelu Skenaarioperustainen testaus keskittyy käyttäjän tekemiseen. Tämä tarkoittaa käyttötapauksista poimittujen tehtävien käyttämistä testien perustana.!5
Luokkatason testausmenetelmät Satunnainen testaus tunnistetaan luokalle sopivat operaatiot määritellään rajoitukset niiden käytölle (esim. järjestys) tunnistetaan pienin riittävä testisekvenssi (_) operaatiot, jotka määrittelevät luokan minimin elinhistorian generoi vaihteleva joukko satunnaisia (käypiä) testisekvenssejä laajennetaan luokan elinhistoriaa Account luokka: open(), setup(), deposit(), withdraw(), balance(), summarize(), creditlimit(), close()!6
Luokkatason testausmenetelmät Ositus(partitio)testaus vähentää testitapausten määrää aivan kuten ekvivalenssiositus perinteisessä testauksessa tilaperustainen ositus (tilaa muuttavat/ei-muuttavat) valitaan testioperaatioita, jotka muuttavat luokan tilaa, esim. Account luokka: deposit(), withdraw() attribuuttiperustainen ositus (attribuuttia käyttävät/ muuttavat) valitaan testioperaatioita, jotka käyttävät attribuutteja, esim. Account luokka: attribuutit balance, creditlimit kategoriaperustainen ositus valitaan testioperaatioita, jotka suorittavat toimintoja, esim. Account luokka: initialization (open(), setup()), computational (deposit(), withdraw()), termination (close()) operaatiot!7
20. Web-sovellusten testaus Käyttöliittymän suunnittelu Web-sovelluksen suunnitteluaktiviteetit Graafinen suunnittelu Sisällön suunnittelu Navigoinnin suunnittelu Arkkitehtuurisuunnittelu Komponenttisuunnittelu!8
Web-sovelluksen ympäristön vaikutus virheiden etsimiseen Nguyen 2000 Koska Web-sovelluksen testauksessa löydetään ensin virheitä asiakaspuolelta, kehittäjä/testaaja näkee virheen oireet - ei itse virhettä. Koska Web-sovellus on toteutettu eri konfiguraatioina eri ympäristöissä, voi olla vaikeaa tuottaa uudelleen tilanne, jossa virhe havaittiin. Vaikka jotkut virheet johtuvat virheellisestä suunnittelusta tai ohjelmoinnista, monet virheet voidaan jäljittää konfiguraatioon. Koska Web-sovellukset rakennetaan asiakas/palvelin arkkitehtuurille, virheen paikallistaminen voi olla vaikeaa (asiakas/palvelin/verkko). Jotkut virheet johtuvat staattisesta toimintaympäristöstä (konfiguraatio, jossa testataan), toiset dynaamisesta (suoritusaikaiset resurssit).!9
Sisällön testaus (syntaksi, semantiikka, tietokanta) Käyttäjä Käyttöliittymän suunnittelu Käyttöliittymän Sisällön testaus testaus (käytettävyys) Navigoinnin testaus Web-sovelluksen testausprosessi Integrointitestaus Graafinen suunnittelu Sisällön suunnittelu Navigoinnin suunnittelu Komponenttitason testaus (toimintojen testaus, esim. polkutestaus) Arkkitehtuurisuunnittelu Konfiguraation testaus (asiakas/palvelin) Komponenttisuunnittelu Suorituskykytestaus Turvallisuustestaus Teknologia
Sisällön testaus Kolme tärkeää tavoitetta syntaksivirheiden paljastaminen tekstidokumenteista, ja kaavioista (kirjoitusvirheet, sääntöjen rikkomiset) semanttisten virheiden paljastaminen (puutteet tiedon tarkkuudessa ja täydellisyydessä, tarjotaanko mahdollisuuksia väärinkäyttäjille) virheiden paljastaminen loppukäyttäjälle esitettävän sisällön rakenteesta ja organisoinnista (kuvat, kuvaukset) Katselmointi tärkeässä roolissa Myös dynaamisten sivujen testaus yhteys tietokantaan (tasoarkkitehtuuri) käyttäjän pyynnöt SQL lauseiksi!11
Web-sovelluksen testaustapoja / Di Lucca, Fasolino 2006 Suorituskykytestaus (performance testing) Varmistetaan tietyt järjestelmän ominaisuudet, kuten vasteaika, palveluaste (kriittisiä Web sovelluksissa) Kuormitustestaus (load testing) Piikkitestaus (stress testing) Yhteensopivuustestaus (compatibility testing) Järjestelmää testataan (vaatimusten mukaan) ennalta määritellyllä kuormalla. Mitataan kykyä selviytyä kuormasta minimikokoonpanolla. Testaan kykyä selviytyä yli sovittujen rajojen menevästä kuormasta (myös elpyä romahduksesta). Testataan sovelluksen toimivuutta erilaisilla palvelinalustoilla tai selaimilla!12
Web-sovelluksen testaustapoja / Di Lucca, Fasolino 2006 Käytettävyystestaus (usability testing) Varmistutaan sovelluksen helppokäyttöisyydestä, oikean muotoisesta sisällön esittämisestä, viestien, kehoitteiden ja komentojen selvyydestä. Käytettävyys on kriittinen tekijä Web-sovelluksissa. (Navigoinnista seuraavalla sivulla) Saavutettavuuden testaus (accessibility testing) Käytettävyystestauksen alalaji, varmistutaan että sisältö saadaan näkyviin, vaikka selain ei tukisi grafiikkaa tai skriptejä. Turvallisuustestaus (security testing) Varmistaudutaan, että luvattomat käyttäjät eivät pääse käyttämään sovellusta. Websovellukset ovat haavoittuvampia kuin perinteiset (johtuu käyttäjämääristä, toteutuksen monista vaihtoehdoista)!13
Navigoinnin testaus / Splaine & Jaskiel 2001 Seuraavat navigointimekanismit tulisi testata Linkit sisäiset ja ulkoiset (toisiin sovelluksiin) Uudelleenohjaukset kun sivu on poistettu tai nimeä muutettu Kirjanmerkit (bookmarks) varmistetaan järkevä nimiehdotus Kehykset (frames) ja kehysjoukot kehysjoukot voivat muodostaa sisäkkäisiä rakenteita, näiden testauksessa tulisi keskittyä esim. navigoinnin, layoutin ja latauksen keston testaukseen!14
Navigoinnin testaus / Splaine & Jaskiel 2001 Seuraavat navigointimekanismit tulisi testata... Sivun uudelleenorganisointi myös web sivut rapistuvat ajan myötä, kannattaa vertailla kilpailijoiden sivuihin Sivukartat kaikki (ja vain ne) tärkeät sivut löytyvät ja esitetään sopivassa järjestyksessä Sisäiset hakukoneet hakukoneiden avulla käyttäjä paikallistaa halutun tiedon laajoissa web sovelluksissa testataan hakukoneen nopeutta, tulosten lajittelua ja selviämistä vääränmuotoisista syötteistä!15
Konfiguraation testaus Ei tavoitella kaikkien mahdollisten konfiguraatioiden testausta, mutta testataan joukko mahdollisista Palvelinpuolen testausta (esim.) onko Web-sovellus yhteensopiva (?!) palvelimen käyttöjärjestelmän kanssa toimiiko tiedostojen ja hakemistojen päivitys virheettömästi sallivatko tietoturvamekanismit Web-sovelluksen tehokkaan käytön onko Web-sovellusta testattu myös hajautetussa konfiguraatiossa, jos sellaista käytetään Asiakaspuolen testausta testattavat konfiguraatiot kerätään sovittamalla yhteen komponentteja laitteisto: CPU, keskusmuisti, talletusmedia,... käyttöjärjestelmä: Linux, OS X, Windows,... selain: IE, Firefox, Chrome, Safari, myös mobiililaitteiden selaimet ja upotetut selainratkaisut käyttöliittymäkomponentit: JavaScript, CSS, [Java applets], laajennukset: QuickTime, RealPlayer,... yhteydet: kaapeli, ADSL/DSL modeemi,!16
Luku 21: Formaali mallintaminen ja verifiointi Mitä ongelmia on perinteisissä spesifikaatioissa? ristiriitaisuudet (contradictions) epäselvyydet (ambiguities) epämääräisyys (vagueness) epätäydellisyys (incompleteness) abstraktiotasojen sekavuus (mixed levels of abstraction) Formaaleilla spesifikaatioilla pyritään eroon luonnollisen kielen ja graafisen esitystavan aiheuttamista epätäsmällisyyksistä. Siirrytään joukko-opin ja logiikka-notaation käyttöön sekä matemaattiseen todistukseen.!17
Formaalit spesifiointikielet Formaali spesifiointikieli koostuu yleensä kolmesta osasta syntaksista, joka määrittelee kuvaustavan (notaation) spesifikaation esittämiselle semantiikasta, joka määrittelee käytettävät oliot (universe of objects) järjestelmän kuvaamiselle joukosta yhteyksiä, jotka määrittelevät olioiden käytön säännöt halutun spesifikaation muodostamiselle Formaalin spesifiointikielen syntaksi perustuu joukkoteoriaan ja predikaattikalkyyliin. Spesifiointikielen semantiikalla kuvataan järjestelmän vaatimukset.!18
Object Constraint Language (OCL) Formaali kuvaustapa, jonka avulla käyttäjät voivat tarkentaa UML kuvauksia (luokka, tila ja aktiviteettikaavioita). Kielellä on logiikan ja diskreetin matematiikan kuvausvoima. OCL kielen suunnittelijat päättivät, että OCL lauseissa käytetään vain ASCII merkkejä (eikä perinteistä matemaattista notaatiota) OCL kielen lausekkeissa (rajoituksissa) operaattorit toimivat olioiden kanssa. OCL mahdollistaa kyselyjen kirjoittamisen, samankaltaisesti kuten SQL-kielellä.!19
BlockHandler using UML Pressman 2005!20
BlockHandler määrittelyt OCL kielellä Invarianttien käyttö (predikaatti, joka on voimassa kiinnitetyn luokan (BlockHandler) kaikissa esiintymissä) Jokainen lohko merkitään käytetyksi tai käyttämättömäksi. context BlockHandler inv: (self.used->intersection(self.free)) ->isempty() Kaikki jonossa olevat lohkot ovat nyt käytössä olevia lohkoja. context BlockHandler inv: blockqueue->forall(ablockset used->includesall(ablockset )) Käytettyjen ja käyttämättömien lohkojen kokoelmat muodostavat kaikkien lohkojen kokoelman. context BlockHandler inv: allblocks = used->union(free) Käyttämättämien lohkojen kokoelmassa ei ole samoja lohkonumeroja. context BlockHandler inv: free->isunique(ablock ablock.number) Käytettyjen lohkojen kokoelmassa ei ole samoja lohkonumeroja. context BlockHandler inv: used->isunique(ablock ablock.number) free allblocks used-lohkot eivät löydy free-lohkoista kaikki jonossa olevat lohkot (ablockset) löytyvät used-lohkoista Block elements used blockqueue BlockHandler BlockSet Pressman 2005!21
Cleanroom menetelmä Cleanroom menetelmän periaatteet määriteltiin 1970/80 lukujen vaihteessa Nimi Cleanroom (puhdastila) on lainattu puolijohdeteollisuudesta Vaikka ihminen on erehtyväinen, ohjelmistovirheet voidaan välttää (Mills 1991) Harlan Mills sovitti matematiikka ja tilastotiedettä ohjelmistotekniikkaan toiminnallinen todentaminen (functional verification) testimateriaalin tarkka suunnittelu (tilastomatematiikan käyttö)!22
Esimerkkiprojekteja 1987 IBM Flight Control: Helicopter Avionics System Component 33 KLOC (Jovial) Häiriöaste 2.3 virhettä/kloc, valmistui etuajassa 1989 NASA Satellite Control Project I 40 KLOC (Fortran) Häiriöaste 4.5 virhettä/kloc, 80% parannus tuottavuudessa 1989 NASA Satellite Control Projects II & III 170 KLOC (Fortran) Häiriöaste 4.2 virhettä/kloc 1993 IBM LAN software first increment 4.8 KLOC (C) Häiriöaste 0.8 virhettä/kloc Tyypillinen tulos on alle 6 virhettä 1000 koodiriviä kohden ensimmäisessä testausvaiheessa (menetelmässä ei tehdä yksikkötestausta)!23
Cleanroom - ongelmia tai pikemminkin seurauksia. Vaatii paljon koulutusta IBM kertoo menetelmän käytöstä noin 450 henkilön laboratoriossa 150 osallistui 10-11 päivän koulutukseen 300 osallistui lyhyempään koulutukseen kokonaisuudessaan laboratorio investoi koulutukseen 7-8 henkilötyövuotta spesifikaatioiden kirjoitus vei myös suunniteltua enemmän aikaa (6 viikkoa -> 12 viikkoa)!24
Asiakas Vaatimusanalyysi Toiminnallinen spesifikaatio Käyttöspesifikaatio Spesifikaatioiden evaluointi Toteutusvaiheiden suunnittelu Suunnittelu, toteutus, todentaminen Käytön mallinnus ja testien suunnittelu Tuoteversioiden evaluointi Tilastollinen testaus ja laadunvarmistus = ohjelmistokehitysryhmän työtä = laadunvarmistusryhmän työtä = yhteiset tehtävät
Cleanroom tekniikat Asteittainen kehittäminen Funktioperustainen määrittely, suunnittelu ja todentaminen mustalaatikko (black box) syöte + syötehistoria -> palaute (S, SH) -> (R) tilalaatikko (state box) syöte + vanha tilatieto = palaute + uusi tilatieto (S, OS) -> (R, NS) lasilaatikko (clear box) clear box -> black boxes (S, OS) -> (R, NS) by procedures P!26
Cleanroom tekniikat... Oikeellisuuden varmentaminen jokainen laatikko varmennetaan kukin ohjelmoija todentaa (verifioi) oman koodinsa julkaisun oikeellisuus todennetaan myös katselmoinneissa Tilastollinen testaus käyttömalli (usage model) kuvaa ohjelmiston käyttäytymisen testitapaukset laaditaan käyttömallin avulla määritellään MTTF (Mean Time To Failure) tavoitearvot!27