Ohjelmiston testaus Osa materiaalista on Arto Stenbergin aineistosta Hannu Asmala Hannu Asmala 1 Testauksen määritelmä Testaus on 1) järjestelmän tai sen osan toiminnallisuuden ja muiden laatuattribuuttien mittaamista 2) suunnitellulla tavalla 3) luontevana osana järjestelmäkehitystä. 1) Täyttääkö järjestelmä sille asetetut toiminnalliset ja ei-toiminnalliset vaatimukset? Testaus mittaa ja paljastaa tietoa järjestelmästä Testausta voidaan suorittaa järjestelmän eri arkkitehtuuritasoilla 2) Mitä järjestelmän osia ja ominaisuuksia testataan enemmän, mitä vähemmän Miten testauksesta saadaan paras mahdollinen hyöty 3) Laadunvarmistus on koko järjestelmän elinkaaren ajan jatkuva prosessi Mitä myöhemmin virheet löytyvät, sitä suuremmat ovat niiden korjauskustannukset Testaus mielletään joskus projektin lopussa olevana, järjestelmän julkaisua viivyttävänä tulppana Testaus ja laadunvarmistus on ajan kuluessa kehittynyt virheiden paikantamisesta virheiden löytämiseen ja niiden syntymisen ehkäisemiseen Hannu Asmala 2 1
Testauksen perustotuuksia Järjestelmässä olevien vikojen lopullista määrää on käytännössä mahdotonta saada selville. Testaus voi osoittaa virheiden olemassaolon, mutta ei niiden poissaoloa. Jos jostain osasta järjestelmää löytyy virheitä, niin yleensä niitä on siellä vielä enemmänkin (80/20-sääntö). Kehittäjän on yleensä vaikeaa testata omaa tuotostaan. Hannu Asmala 3 Testaus ja debuggaus Testaus on systemaattista toimintaa, jolla yritetään estää virheiden syntymistä ja löytää järjestelmästä mahdollisimman paljon vikoja. Debuggaus tapahtuu vasta vian löytämisen jälkeen. Debuggaus paikallistaa vian alkuperän koodista yleensä työkalun (debuggeri) avulla, jonka jälkeen voidaan tehdä varsinainen vian korjaus. Hannu Asmala 4 2
Termejä Virhe (error): ihmisen tekemä virhe esim. kommunikaatiossa - dokumentissa - koodissa aiheuttaa ohjelmistossa väärän tuloksen, eli vian Vika (fault): ohjelmiston tila ohjelmistossa on virhe, joka aiheuttaa vian voi aiheuttaa häiriön satunnaisesti tai säännöllisesti Häiriö (failure): tapahtuma järjestelmän käyttäytyminen eroaa odotetusta käytöksestä käyttäjä huomaa tämän tapahtumana Hannu Asmala 5 Täydellinen testaaminen Täydellinen testaaminen ei ole käytännössä järkevää ja se on muutenkin miltei mahdotonta. Esimerkkinä funktio, joka lukee kolme kokonaislukuarvoa ja tekee annetuilla luvuilla jonkun operaation: Int funktio (int a, int b, int c); 16 bittiset kokonaisluvut, eli mahdollisten yhdistelmien määrä on 65536 * 65536 * 65536 jos yhden sekunnin aikana testataan 100000 yhdistelmää, niin kuinka kauan kestää kaikkien sallittujen yhdistelmien testaaminen? Hannu Asmala 6 3
Positiivinen testaus Pyritään todistamaan, että: järjestelmä tekee sitä, mitä sen pitääkin tehdä ei tee sitä, mitä sen ei pitäisikään tehdä Päämäärä: osoitetaan, että järjestelmä toimii Saavutetaan helpommilla testitapauksilla. Yleensä normaali tapa toimia, kun testaat omaa tuotostasi. Testataan normaaleja tapahtumia sallituilla syötteillä. Hannu Asmala 7 Negatiivinen testaus Pyritään todistamaan, että: järjestelmä tekee sitä, mitä sen ei pitäisi tehdä ei tee sitä, mitä sen pitäisi tehdä Päämäärä: löydetään mahdollisimman paljon virheitä Saavutetaan vaikeammilla testitapauksilla. Varsinaisten testaajien pitäisi toimia pääasiallisesti tällä tavalla. Positiivisten ja negatiivisten testitapausten suhde vaihtelee, mutta suhteen pitäisi olla 1/1 1/5. Hannu Asmala 8 4
Testitapausten suunnittelu Esiehdot: missä tilassa testauksen kohde pitää olla ennen varsinaisen testitapauksen alkamista miten sinne päästään: mahdolliset suoritusvaiheet mahdolliset edeltävät testitapaukset Testiympäristö: missä ympäristössä tämä testitapaus voidaan suorittaa laitteet, yhteydet muihin järjestelmiin, testaustyökalut, käyttöjärjestelmä, data, muu ohjelmisto jne. Syötteiden määrittely: mitkä ovat testitapauksen syötteet missä järjestyksessä niitä annetaan Hannu Asmala 9 Testitapausten suunnittelu Testauksen suoritus: miten testitapaus pitäisi suorittaa vaiheistus, mitä tehdään ja milloin Odotettu tulos: mitä testitapauksen suorituksen aikana pitäisi tapahtua minkä asioiden pitäisi muuttua mitkä asiat eivät saa muuttua minkä pitäisi olla testitapauksen lopputulos Hannu Asmala 10 5
Testausprosessi Hannu Asmala 11 V-malli ja testaustasot Kuvaa testausprosessin suhdetta ohjelmistoprosessiin Hannu Asmala 12 6
V-malli V-mallissa testaukset jaetaan eri tasoihin, joissa testataan niihin kuuluvia asioita. Kun tason testaustavoitteet on saavutettu, niin ei ole tarpeellista toistaa samoja asioita seuraavilla tasoilla. Edellisen tason testaus tulee olla suoritettuna, ennen seuraavalle siirtymistä. Testausten suunnittelu ja testitapaukset tulee tehdä jokaisen tason määrittelyn tai suunnittelun kanssa samanaikaisesti. Tällä tavalla karsitaan virheitä ennen siirtymistä alemmalle tasolle ja samalla syntyvä dokumentaatio tukee paremmin toteutusta ja testausta. Mallin vasemmassa haarassa keskitytään dokumenttien tutkimiseen, katselmointiin ja tarkistuksiin (voidaan saavuttaa moninkertainen hyöty verrattuna pelkkiin testauksiin) ja oikeassa testauksiin. Hannu Asmala 13 V-malli Moduulitestaus Pienin testattava yksikkö Tekee yleisesti koodin ohjelmoitsija Testataan rajapinnat, koodi, vikatilanteet Integrointitestaus Ohjelmiston osia yhdessä Testataan osien välinen kommunikaatio ja yhteistoiminta Järjestelmätestaus Koko järjestelmä (HW+SW) koossa Toiminnallista testausta käyttäjän näkökulmasta Myös ei-toiminnallinen testaus Usein testaajana ei ole koodin tehnyt ohjelmoitsija Hyväksymistestaus Voi olla osana järjestelmätestausta Asiakas mukana Testataan täyttääkö järjestelmä sopimuksen ehdot ja vaatimukset Hannu Asmala 14 7
Verifiointi ja validointi Verifiointi: todentaminen, joka kohdistuu erilaisiin vaihetuotteisiin, eli yleensä dokumentteihin onko vaihetuote tehty prosessien ja ohjeiden mukaisesti hyviä työtapoja noudattaen kysymys: Tehdäänkö järjestelmää oikein? Validointi: todistaminen oikeaksi (käyttäjän näkökulma) verrataan vaihetuotetta vaatimuksiin ja käyttäjältä saatavaan informaatioon kysymys: Tehdäänkö oikeaa järjestelmää? Hannu Asmala 15 Mikä on riittävä määrä testausta? Hyvin vaikea määritellä, joten ensin kannattaa määritellä järjestelmän laatuvaatimukset ja testauksen määrä sekä kattavuus. Lisäksi pitää miettiä testauksen hyötyjä ja kustannuksia. Riittävä määrä vaihtelee eri järjestelmien ja projektien välillä, mutta se riippuu ensisijaisesti järjestelmään kohdistuvista riskeistä. Testitapauksia pystyy suunnittelemaan enemmän kuin on aikaa niiden toteuttamiseen. On hyvä muistaa, että testaukseen käytettävät resurssit (esim. aika, henkilöt, kustannukset) ovat aina rajattuja. Hannu Asmala 16 8
Testauksen kohteet ja kattavuus Hannu Asmala 17 Testauksen kohteet ja kattavuus Eri lähestymistapoja tarvitaan, koska: ei koskaan tiedä varmasti, missä on vikoja tarvitaan testausta eri näkökulmista, jotta saadaan erilaista testauksen kattavuutta Käyttö: yleisin testausnäkökulma miten loppukäyttäjä todellisuudessa käyttää järjestelmää ja sen eri toiminnallisuuksia erilaisten vaatimusten, laatukriteerien ja käyttötapauksien testaaminen käytössä aito data ja yhteydet toisiin järjestelmiin yleensä ei saavuteta korkeaa rakenteellista kattavuutta Hannu Asmala 18 9
Testauksen kohteet ja kattavuus Toiminnallisuus: miten testataan järjestelmän tai sen osan tarjoamat yksittäiset toiminnallisuudet ylätason toiminnallisuus koostuu useasta alatason toiminnallisuudesta mitä kannattaa testata eri V-mallin testaustasoilla Rakenne: mikä on järjestelmän arkkitehtuuri ja sen rakenne esim. erilaiset laitteistot, rajapinnat, komponentit, koodi rakenteellinen kattavuus: koodi, komponentit Hannu Asmala 19 Testausmalli Hannu Asmala 20 10
Testausmalli Testauksen kohde: jokaisesta järjestelmästä löytyy useita testauksen kohteita eri tasoilta (käyttö-toiminnallisuus-rakenne) jotkut kohteet löytyvät kokemuksen avulla voidaan tunnistaa myös ilman dokumentaatiota Testitapaus: testauksen kohteesta voidaan tehdä useita testitapauksia esim. erilaisten testaustekniikoiden avulla testitapaukset suoritetaan joko manuaalisesti tai työkalun avulla automaattisesti Hannu Asmala 21 Testausmalli Suorituksen tulos: mitä järjestelmässä tapahtuu testitapauksen suorituksen aikana mitkä ovat suorituksen tulokset mikä on järjestelmän tila testitapauksen suorituksen jälkeen Lähdemateriaali: järjestelmän dokumentaatio (esim. vaatimusmäärittely, käyttötapaus, rajapintamäärittely, UML-malli, käyttöohje) dokumentaatiota käytetään hyväksi testitapausten suunnitteluun pitää muistaa, että lähdemateriaalissa voi olla virheitä Hannu Asmala 22 11
Testausmalli Odotettu tulos: mitä järjestelmässä pitäisi tapahtua testitapauksen aikana minkä pitäisi olla testitapauksen tulos missä tilassa järjestelmän pitäisi olla testitapauksen suorituksen jälkeen jos lähdemateriaalia ei ole saatavilla, testaajan pitää muodostaa oma käsityksensä siitä, mitä testitapauksessa pitäisi tapahtua ja mikä on odotettu tulos Testitapauksen tulos: vertailu suorituksen ja odotetun tuloksen välillä menikö testi läpi, löytyikö virhe vai tapahtuiko jotain muuta mielenkiintoista Hannu Asmala 23 Eri testaustekniikoiden jakoja Staattiset dynaamiset: kohdistuuko testaus vaihetuotteisiin, vai onko suoritettavaa koodia White box black box: mitataanko testauksen koodikattavuutta vaiko ei Systemaattiset ei-systemaattiset: johdetaanko testitapaukset järjestelmällisesti kehityksen aikana luoduista dokumenteista vai joutuuko/saako testaaja käyttää luovuuttaan Toiminnalliset ei-toiminnalliset: testataanko pelkästään järjestelmän toiminnallisuutta vai myös muita järjestelmän laatuominaisuuksia Hannu Asmala 24 12
Staattiset testaustekniikat Katselmukset ja tarkastukset: kohdistuvat vaihetuotteisiin, eli kaikenlaiseen ohjelmistokehityksessä syntyneeseen dokumentaatioon löytävät virheitä tehokkaammin oikein suoritettuna kuin dynaaminen testaus parannetaan vaihetuotteiden laatua, jolloin lopullisen tuotteen laatu paranee ehkäisevät uusien virheiden syntymistä ja kertautumista projektin yleinen tuottavuus nousee ja projekti nopeutuu, koska aikaa pitäisi säästyä testausvaiheessa turha työ vähenee Hannu Asmala 25 Tarkastuksen ja katselmuksen erot Suomessa termien käyttö ja sisältö saattaa vaihdella Tarkastuksella tarkoitetaan yleensä yhteen vaihetuotteeseen (dokumenttiin) kohdistuvaa laadun tarkastelua Katselmuksella tarkoitetaan yleensä projektin jonkun vaiheen päättymisen toteaminen, jolloin tarkastetaan onko kaikki siinä vaiheessa suunnitellut työn tehty Termien merkitys voi vaihdella yrityksestä toiseen Kansainvälisesti määriteltynä tarkastukset ovat formaaleja tapahtumia, katselmukset ovat vapaampia, mutta molemmat kohdistuvat yhteen dokumenttiin. Hannu Asmala 26 13
Automaatio-ohjelmistojen testaus Testausympäristöjen vaihtoehdot Reality control system 1 system 3 2 Simulation control system 4 system 1. Perinteinen tapa testata vasta, kun kaikki on valmista. Todellinen ohjausjärjestelmä ja prosessi. 2. Prosessin emulointi eli reaalimaailma simuloidaan. 3. Simuloitu ohjausjärjestelmä, mutta todellinen prosessi. 4. Koko ympäristö on simuloitu. being controlled being controlled Voi olla myös edellisten yhdistelmiä esim. 1 ja 2 tai 3 ja 4. Hannu Asmala 27 Automaatio-ohjelmistojen testaus Testaus tehdään tyypillisesti todellisilla laitteistolla tai simuloidulla prosessilla. Lähes poikkeuksetta testauksen tekee ohjelmistosuunnittelija omalla tavallaan. Tällöin korostuvat suunnittelijan ammattitaito ja kokemus. Erityisesti aloittelevan suunnittelijan ohjelmia suositellaan tarkastettavan ja katselmoitavan. Moduulien testausta pyritään tekemään simuloidun toimintaympäristön avulla, mutta laiteläheisen ohjelman testaus ilman fyysistä laitetta on vaikeaa tai mahdotonta. Ohjausjärjestelmä rakennetaan toimivaksi kokonaisuudeksi tehdastestejä (FAT) varten. Koko järjestelmän ei tarvitse sijaita yhdessä paikassa, vaan hajautus voidaan toteuttaa esim. tietoverkon avulla. Erityistä huomiota kiinnitetään rajapintojen testaukseen. Hannu Asmala 28 14
Automaatio-ohjelmistojen testaus Mekaniikkaa saatetaan soveltuvin osin koota toimittajan tiloihin testausta varten. Tällöin voidaan varmistaa osien yhteistoimivuus ja, että koko järjestelmän suorituskyky ja kapasiteetti vastaavat asiakkaan kanssa sovittuja tavoitteita. Ennen varsinaista tuotannon aloitusta suoritetaan täydellinen toiminnallinen testaus mukaan lukien sellaiset osa-alueet, jotka on aikaisemmin testattu simuloimalla. Hannu Asmala 29 Testauksen esimerkki 1 Sekä ohjaus että laite simuloidussa ympäristössä Siemens PLCSim ohjauslogiikan alustana MS Excel testaustyökaluna Kohteena 2-suuntaisen, 1-nopeuksisen moottorin ohjaus Perustui Black box tekniikkaan Exceliin oli toteutettu testitapaukset, jotka voitiin toteuttaa kehitetyllä skriptauksella Tulokset: Testitapauksia oli 57 Odotetun tuloksen antoi 47 tapausta Osittain tai kokonaan virheellinen tulos 10 tapausta Hannu Asmala 30 15
Simulointiavusteinen testaus Testauksen kohteena on laitteita ja koneita ohjaava ohjelmisto. Simuloinnilla pyritään mallintamaan tuotantolaitteet niin todelliseksi, että ohjausohjelmisto kuvittelee ohjaavansa todellisia laitteita (mallin validointi ja verifiointi). Pääasiallisena tavoitteena on lyhentää automaatiojärjestelmän käyttöönottoon kuluvaa aikaa. Voidaan hyödyntää myös analysoinnissa ja koulutuksessa. Simuloinnilla voidaan testata sellaisia asioita, jotka ovat mahdottomia todellisella laitteistolla. Testattavaa ohjelmistoa voidaan ajaa todellisessa tai emuloidussa ympäristössä. Tyypillisesti ohjausjärjestelmän kello käy reaaliaikaa, jolloin simuloinnin on myös edettävä reaaliajassa. Hannu Asmala 31 Tetausympäristö Useilla 3D-simulointiohjelmistojen valmistajilla on rajapinta (esim. OPC ) ulkoisen ohjauksen liittämiseksi. Liityntä ulkoiseen ohjaukseen luo perustan, mutta ei ole riittävä tehokkaalle testaukselle. Tarvitaan myös työkaluja helpottamaan testausprosessia testien määrittely testiajojen suoritus: manuaalinen, automaattinen, uudelleentestaus ohjelmiston saattaminen testausta edellyttävään tilaan jäljittäminen dokumentointia Ohjelmiston toiminnan selvittäminen voidaan toteuttaa: visuaalisella tarkastelulla ohjelmallisesti analysoimalla kerättyä dataa Hannu Asmala 32 16
Testauksen esimerkki 2 Mallinnettavana on vanerin liimauslinja, jota ohjaa Siemens S7-400 logiikka Computer 3DCreate Komponenttien rakenne ja käyttäytyminen Testiskriptit PLC Siemens S7-400 Component OPC Component Component OPC tagien ja simulointisignaalien kytkeminen OPC Server tagien nimeäminen Step7 symboleilla OPC Component OPC Add-on (OPC Client) OPC Server Fieldbus (Profibus) Mallin rakentamisen rinnalla kehitettiin OPC rajapinnan toteuttava liityntäohjelmisto omaksi tuotteeksi. OPC Add-on kehitys Card: SST 5135-PBMS Profibus Multislave 70 slaves and 1600 I/Os Liityntäkortti: SST 5135-PBMS Hannu Asmala 33 Vanerin liimauslinja Liimauslinjasta on mallinnettu harmaalla esitetty osuus Lukuarvoja mallista Yli 330 I/O kanavaa 5 nostopöytää 14 taajuusmuuttajaa 6 kuljetinta 7 puhallinta Malli vasteaika ka. 100ms, ohjelman kiertoaika 7ms, kenttäväylän kiertoaika 22 ms Hannu Asmala 34 17
Simulointimalli Hannu Asmala 35 Loki Lokia voidaan hyödyntää mallin ja ohjausjärjestelmän ohjelmiston validoinnissa Lokin avulla löydetty virhe Moottorin 706M1 ohjaus muuttuu hetkellisesti virheelliseksi. Ongelman aiheuttaa ohjelmistoarkkitehtuuri. Hannu Asmala 36 18
Kokemuksia pilotista PLC:n ohjelma ei vaatinut muutoksia, laitteistomäärittelyssä pieniä muutoksia: kolmen väylän asemat yhteen väylään, keskusyksikön yhteydessä oleva I/O siirrettiin väylään lisättyyn asemaan. Mallinnettiin toimiva tuotantolinja, ohjelmat ja laitteet ovat olemassa. Ohjausohjelmiston kehitysympäristön ja simulointiohjelmiston mahdollisuus datan tuontiin ja vientiin nopeuttavat testausympäristön toteuttamista. Mallin rakentaminen on työlästä, jos ei ole riittävästi tietoa fyysisistä laitteista esim. antureiden tarkat sijainnit. Jos simulointiohjelmiston liityntä hoidetaan OPC:lla, on tärkeää vertailla eri valmistajien ratkaisuja. Erityistä huomiota on kiinnitettävä OPC serverin konfigurointiin ja tagien uudelleennimeämiseen. Hannu Asmala 37 Kokemuksia pilotista Linjan operointi tuli tutuksi. Vaikuttaa toimivalta myös koulutuksessa. Hyödyn määrä jäi epäselväksi, jos malli olisi toteutettu ennen todellista linjaa ja ohjausta. Skriptien käyttö helpottaa testausta. Loki osoittautui toimivaksi sekä mallin että ohjelmiston validoinnissa. Komponentti tai layoutin osa voidaan konfiguroida valmiiksi esim. nostopöytä ja ladata rakenteilla olevaan linjaan. Komponentit on toteutettava niin, että ohjausjärjestelmään liitetyt signaalit saavat oikean arvon simulointia käynnistettäessä. Kommunikointi simulointimallin ja ohjausjärjestelmän välillä osoittautui luotettavaksi. Hannu Asmala 38 19
SST Profibus Multi Slave 5136-PBMS Siemens Step7 laitteistomäärittely Hannu Asmala 39 OPC tagien nimeäminen Renamed Statistics: DP Slaves: 70 Inputs: 927 Outputs: 759 Kehitettiin Excel-pohjainen työkalu, joka muokkasi tagien nimet Step7 symbolien mukaisiksi. Original names: Input13, input14, etc. Hannu Asmala 40 20
OPC tagien ja signaalien kytkentä Connection can be done manually or automatically (tag name contains component + signal names e.g. Tag = PBMS-PCI-0000.OS61Run Component = OS61, Signal = Run) Hannu Asmala 41 OPC Add-on OPC Add-on käyttöliittymä omalla sivulla Hannu Asmala 42 21
Esimerkki 0-1-start kytkin Kytkimen käyttöliittymä 3DCreate versiolle 3.1. Versiolla 2007 käyttäjä voi kääntää kytkintä interaktiivisessa tilassa hiiren oikealla ja vasemmalla painikkeella. Kytkimen asentojen visualisointi 0 1 Signaalien julkaisu OPC rajapintaan: Run and Start signals start Hannu Asmala 43 Skriptit User interface of the script component System scripts are preprogrammed functions Selected component s name and signals. Script component, MrWhite Hannu Asmala 44 22