Ohjelmistotekniikka - Luento 10 Jouni Lappalainen

Transkriptio

1 Ohjelmistotekniikka - Luento 10 Jouni Lappalainen 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ä

2 Pohdiskelun aiheita Di Lucca ja Fasolino esittelevät paperin luvussa 7.2 Websovelluksen testaustapoja, joilla pyritään varmistamaan, että sovellus vastaa sekä ei-toiminnallisia että toiminnallisia vaatimuksia. Millaiset testaustavat sopivat ei-toiminnallisille vaatimuksille ja miten Web-sovellusten erityispiirteet näkyvät näissä testaustavoissa. Miten Web-sovellusten toiminnallisuuden testaus eroaa perinteisten ohjelmistojen testauksesta? Di Lucca G., Fasolino A., Web Application Testing, Engineering_Mendes_C07WebTest.pdf

3 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 3

4 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ä 4

5 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. 5

6 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. 6

7 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() 7

8 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 8

9 20. Web-sovellusten testaus Web-sovelluksen suunnitteluaktiviteetit Käyttöliittymän suunnittelu Graafinen suunnittelu Sisällön suunnittelu Navigoinnin suunnittelu Arkkitehtuurisuunnittelu Komponenttisuunnittelu 9

10 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). 10

11 Sisällön testaus (syntaksi, semantiikka, tietokanta) Käyttäjä Käyttöliittymän suunnittelu Graafinen suunnittelu Sisällön suunnittelu Navigoinnin suunnittelu Käyttöliittymän Sisällön testaus (käytettävyys) testaus Navigoinnin testaus Komponenttitason testaus (toimintojen testaus, esim. polkutestaus) Web-sovelluksen testausprosessi Integrointitestaus Arkkitehtuurisuunnittelu Konfiguraation testaus (asiakas/palvelin) Komponenttisuunnittelu Suorituskykytestaus Turvallisuustestaus Teknologia 11

12 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 12

13 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

14 Web-sovelluksen testaustapoja /Di Lucca, Fasolino 2006 Käytettävyystestaus (usability testing) Käyttöön saamisen testaus (accessibility testing) Turvallisuustestaus (security 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) Käytettävyystestauksen alalaji, varmistutaan että sisältö saadaan näkyviin, vaikka selain ei tukisi grafiikkaa tai skriptejä. Varmistaudutaan, että luvattomat käyttäjät eivät pääse käyttämään sovellusta. Web-sovellukset ovat haavoittuvampia kuin perinteiset (johtuu käyttäjämääristä, toteutuksen monista vaihtoehdoista)

15 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

16 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ä

17 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, Safari,... käyttöliittymäkomponentit: Active X, Java applets,... laajennukset: QuickTime, RealPlayer,... yhteydet: kaapeli, ADSL/DSL modeemi,...

18 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. 18

19 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. 19

20 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ä. 20

21 BlockHandler using UML Block * elements 1 BlockSet * number * * blockqueue free * used {ordered} allblocks {subset} {subset} BlockHandler addblock() removeblock() Pressman

22 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 used-lohkot eivät löydy free-lohkoista kaikki jonossa olevat lohkot (ablockset) löytyvät used-lohkoista Block allblocks used elements BlockHandler BlockSet blockqueue Pressman

23 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ö)

24 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)

25 Cleanroom - ongelmia Vaatii paljon koulutusta IBM kertoo menetelmän käytöstä noin 450 henkilön laboratoriossa 150 osallistui 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)

26 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

27 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

28 CB BB SB CB BB 1.1 BB CB BB 1 BB 1.2 BB BB 1.3 BB 1.n Pressman

29 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

30 [set w to minimum of z and absolute value of x] [set w to minimum of z and absolute value of x] DO = [set y to absolute = value of x] [set w to minimum of z and y] END [set w to minimum of z and absolute value of x] DO [set y to absolute value of x] IF x < 0 THEN y := -x ELSE y := x END [set w to minimum of z and y] IF y < z THEN w := y ELSE w := z END Asteittainen tarkentaminen ja todentaminen clear box esityksessä

31 SAFEHOME off away stay alarm check fire away stay instant bypass not ready armed power max test bypass instant code chime ready * 0 # panic ohjauspaneli ilmaisee toimijalle järjestelmän tilan: - not ready ilmoitus tarkoittaa, että huoneiston jokin ovi tai ikkuna on auki toimija käyttää näppäimistöä antaakseen nelinumeroisen salasanan - jos salasana on väärä, järjestelmä ilmoittaa piippaamalla, jos oikea, odottaa jatkotoimia toimija asettaa järjestelmän käyttöön stay (talon ulkopuolen tunnistimet) tai away (kaikki tunnistimet) näppäimillä

32 Käyttäjän tekemä valinta A (arm/disalarm) Z (zone set) Q (query) T (test) P (panic alarm) Käytön todennäköinen hajonta 50 % 15 % 15 % 15 % 5 % Hajontaasteikko Testi Satunnaisluvut Testitapaukset A A A Z A T Z P A Q T Q T A Z A A A A A P T A Q Testitapausten tilastollinen valinta

33 Syötteet Syöte Kuvaus viite vaatimukseen nro S Set Laitteen aktivointi 2 T Trip Signaali tunnistimelta 1 B BadDigit Väärä merkki osana 7 koodia C Clear Koodin nollaus 7 G GoodDigit Oikea merkki osana 5,6 koodia Palautteet Palaute Kuvaus viite vaatimukseen nro Light on Set näppäimeen valo 3 Light off Set näppäimen valo pois 6 Alarm on Hälytysääni aktivoituu 4 Alarm off Hälytysääni katkeaa 5 33

34 Software not invoked Alarm G C Alarm and 1_OK G C Alarm and 2_OK S T C B B B Ready Alarm and Entry Error G G B C T T T Entry Error B 1_OK G 2_OK G Software terminated C C Turvahälyttimen käyttömalli

35 Pohdiskelun aiheita Di Lucca ja Fasolino esittelevät paperin luvussa 7.2 Websovelluksen testaustapoja, joilla pyritään varmistamaan, että sovellus vastaa sekä ei-toiminnallisia että toiminnallisia vaatimuksia. Millaiset testaustavat sopivat ei-toiminnallisille vaatimuksille ja miten Web-sovellusten erityispiirteet näkyvät näissä testaustavoissa. Miten Web-sovellusten toiminnallisuuden testaus eroaa perinteisten ohjelmistojen testauksesta? Di Lucca G., Fasolino A., Web Application Testing, Engineering_Mendes_C07WebTest.pdf

36 Harjoitustehtävät: viikko 7 1. Tarkastele funktiota laske_joulukuun_palkka Työntekijöiden kuukausipalkat vaihtelevat välillä euroa. Oletetaan myös, että työntekijä on voinut olla yrityksen palveluksessa 0 50 vuotta. Joulukuun palkkaan lisätään joulubonus, joka määritellään seuraavasti: Työntekijä saa 50% bonuksen (50% kuukausipalkasta), jos on ollut yrityksessä kolme vuotta tai enemmän. Jos on ollut yrityksessä yli viisi vuotta, bonus on 75% ja yli kahdeksan vuotta yritystä palvelleille bonus on 100%. Funktio määritellään kahden parametrin avulla seuraavasti: double laske_ joulukuun _palkka ( double kk_palkka, // henkilön kuukausipalkka int palvelusaika, // henkilön palvelusaika yrityksessä) a. Tee funktion parametreille testiaineisto käyttäen luennoilla esiteltyä ekvivalenssiositusta, jossa määritellään ekvivalenssiluokat sekä käyville että ei-käyville syöttöarvoille. Tee myös taulukkoesitys, josta näkee parametrien arvot ja lopputuloksen eri testiarvoilla. 36

37 Harjoitustehtävät: viikko 7 1. b. Toteuta laske_ joulukuun _palkka funktio Java (tai C) ohjelmana. Piirrä myös lohkokaavio ja määrittele syklomaattinen kompleksisuus ja tarvittavien testitapausten lkm. Määrittele polut, joiden avulla saadaan polkukattavuus 100%:ksi ja laadi näille testitapaukset. 2. Olet kehittämässä Web-pohjaista apteekkiohjelmistoa NurkkaApteekki.com, joka on tarkoitettu ikäihmisten käyttöön. Käyttäjän täytyy tunnistautua verkkopankin tunnuksilla. Sen jälkeen käyttäjä näkee, millaisia reseptejä, milloin ja kenen toimesta hänelle on määrätty. Ohjelmistolla on yhteys tietokantaan ja uusien lääkemääräyksien ja vanhojen määräyksien yhteisvaikutus arvioidaan. Jos huomataan vaarallinen yhteisvaikutus, tästä ilmoitetaan käyttäjälle. Millaisia testejä tällaiselle ohjelmistolle tulisi suunnitella. Riittää että kerrot sanallisesti testeistä, ei tarvitse suunnitella testiaineistoa. 37