Testaus elinkaaressa. Testaustasot ja vaiheet

Koko: px
Aloita esitys sivulta:

Download "Testaus elinkaaressa. Testaustasot ja vaiheet"

Transkriptio

1 Testaus elinkaaressa Testaus kehittämisen tukena Yksikkötestaus Integrointitestaus Testaustasot ja vaiheet Testaustaso = tietyn testauksen kohteen ja tavoitteen mukainen testaus joka jatkuu koko ajan tai toistuu usein projektissa esimerkiksi integrointitestaus aina kehitys-baselinen yhteydessä Testausvaihe = projektissa tehtävä kertaluonteinen projektin etenemiseen liittyvä testausaktiviteetti voi olla yhtä tai useaa testaustasoa esim. beta-testaus, hyväksyntätestaus, käytettävyystestaus.. Testaustaso ja vaihe usein mielletään samaksi, ero kuitenkin merkittävä 1

2 Testauksen kytkeytyminen ohjelmistokehitykseen ns. testauksen V-malli on syntynyt nivomalla eri tasoiset testauksen vaiheet vastaaviin kehitysvaiheisiin perinteisessä vesiputous-elinkaarimallissa V-mallissa oleellista Eri työvaiheiden vastaavuudet Testauksen suunnittelu alkaa heti projektin alussa Erottelee testaustasoja Kritiikkiä Yksinkertaisena ja jäykkänä mallina ei vastaa modernia ohjelmistokehitystä Ei kykene mukautumaan muutokseen Johtaa tehottomiin ruohnjuuritason testauskäytäntöihin Testauksen V-malli Black-box Testaajat Staattinen Dynaaminen White-box Kehittäjät 2

3 V-malli käytännössä V-malli ei ole kehityksen elinkaarimalli, vaan käsitteellinen malli Iteratiivisessa kehityksessä V-mallia sovelletaan jokaisen iteraation sisällä Tasoja voi olla useita, eivätkä moduulitestaus ja integrointitestaus ole aina helposti eroteltavissa Oleellista on ymmärtää mikä on kulloinkin SUT Joka tasolla laaditaan testaussuunnitelma Suunnitelman tekoa kannattaa joskus viivyttää mahdollisten muutosten vuoksi Suunnitelma ei tarkoita dokumentin tuottamista! Testaus toteutetaan niin aikaisin kuin mahdollista Eri tasojen spesifikaatioita voidaan validoida staattisella testauksella ja rakentuvan järjestelmän asiakastestaukella V-malli käytännössä Testaustekniikat riippuvat siitä millä tasolla ollaan Yleinen periaate: Matalilla testauksen tasoilla testauksen tehokas kohdistaminen (kattavuus, tehokas virheiden löytyminen) vaatii ohjelmiston rakenteen hyödyntämistä white-box tekniikat Matalilla tasoilla testaaminen vaatii usein järjestelmän modulien teknistä tuntemusta, lisäksi tarve saada löytyvät virheet saman tien korjattua kehittäjät/ohjelmoijat testaavat Korkeammilla tasoilla järjestelmän tai osajärjestelmän testauksessa testataan toimintoja ja asiakasvaatimuksia black-box tekniikat Asiakasnäkökulma, ei-toiminnalliset ominaisuudet, testauksen kohdentaminen riskiperustaisesti erilliset testaajat Käytännössä mm. rakennettava ohjelmisto, kehitysprosessi ja yrityksen organisaatio vaikuttavat oleellisesti tekniikoiden valintaan 3

4 YKSIKKÖTESTAUS (unit testing) Itse ohjelmointityössä tapahtuvien virheiden välittömäksi poistamiseksi tehtävä tekninen testaus Yksikkö joka testataan voi olla... Komponentti, moduuli Luokka Luokan metodi Toiminnallisuus jonka kehittäjä on toimeksiantona totetuttanut Koko ja periaate jolla yksikkö määritetään vaihtelee siis suuresti Usein käytännössä kaksi yksikkötestauksen tasoa Yksittäisten koodaustehtävien testaus sitä mukaan kun ne tehdään Moduli/komponenttitestaus jollekin ohjelmiston osalle ennen integrointia YKSIKKÖTESTAUS Testattava moduli Testitulokset Testitapaukset Varmistaa että moduuli toimii irrallisena kokonaisuutena Modernissa ohjelmistokehityksessä yksikkötason testaus nähdään suoraan osana toteutuksen tekoa, kehittäjän vastuulla 4

5 Yksikkötestausympäristö Ajuri Moduli Tynkä Tynkä rajapinta lokaalit tietorakenteet rajatapaukset suorituspolut virheelliset syötteet Testitapaukset Testin tulos Yksikkötestausympäristö Modulit on suunniteltu toimimaan osana järjestelmää Jos ympäröiviä moduleja ei tehty, testauksessa apukoodia Ajuri (test driver) Syöttää testitapausten datan SUT:lle Kerää SUT:n tulokset (analysointi yleensä erillinen) Käyttää SUT:ia kuten aikanaan valmistuva ohjelmisto Voidaan usein testata modulia monipuolisemmin kuin integroituna ohjelmistoon Tynkämoduli (mock up, stub) Korvaa modulin jota SUT kutsuu ja tarvitsee Toteuttaa vaadittavat rajapinnat Kerää tiedon siitä että sitä on kutsuttu (sekä kutsun parametrit) Palauttaa kontrollin testattavaan yksikköön Tynkä usein hyödyllinen korvaaman vaikeasti generoitavaa todellista dataa (esim. jokin mittausinstrumentti) 5

6 Yksikkötestauksen kohdentaminen Modulin rajapintojen testaus Funktioiden parametrit ja paluuarvot tiedonvälittäjinä Kääntäjä huomaa suurimman osan virheistä Staattisen testauksen tekniikat käyttökelpoisia Lokaalit tietorakenteet Virheiden estäminen: käytä valmiita luotettavia tietorakenteita (kielen kirjastot, esim. C++:n STL) Valmiiden tietorakenteiden käyttäminen testattava Monimutkaisten tietorakenteiden kattava dynaaminen testaus erittäin vaikeaa koodin staattinen testaus Yleensäkin virhealttiita Yksikkötestauksen kohdentaminen Suortuspolku, silmukat Mahdollisia suorituspolkuja (koodissa) käytetään testien kohdentamiseen ja kattavuuden arvointiin Valitse testitapaukset siten että kaikki oleelliset suorituspolut tulevat testatuksi Jo muutama silmukka tekee riittävän kattavuuden saavuttamisen mahdottomaksi (ainakin manuaalisella testauksella) staattinen testaus, black-box testaus täydentämään Ääriarvot Ohjelmointivirheet liittyvät usein sallittujen arvojen rajoihin Parametrit, paluuarvot Silmukoiden pyörimiskerrat (0, 1, n, max kertaa) Tietorakenteet, esim. dynaamisesti kasvavan rakenteen täyttyminen (ja taas pieneminen) 6

7 Yksikkötestauksen kohdentaminen Virhetilanteiden testaus Hallitusti hoidetut virhetilanteet ovat osa ojelman toimintaa Nostetut poikkeukset (ja muut virheilmoitukset) ovat osa modulin rajapintaa Virhekäyttäytyminen yleensä huonosti huomioitu ja määritelty, siksi virhealtis alue ja toisaalta vaikea testata Matalalla tasolla poikkeuksia sekä palautettuja virhekoodeja, korkealla tasolla käyttäjälle näkyviä virheilmoituksia ja toipumismenettelyjä Testattavaa: Syntyykö virheilmoitus oikein? Sisältääkö virheilmoitus riittävän tiedon sen ymmärtämiseksi? Kykeneekö käyttäjä paikallistamaan virheen syyn ja toipumaan tilanteesta? Ovatko virhekäytännöt yhtenevät? INTEGEROINTITESTAUS Virheiden estäminen Integrointitestaus Integrointitestauksen strategioita Sopimuspohjainen ohjelmointi Integrointitestauksen toteutus 7

8 Virheiden estäminen Virheen estäminen on aina fiksumpaa kuin sen löytäminen testauksella, näin myös integrointivaiheessa Moduulien tehtävä oltava selkeä, korkea koheesio (tekee vain yhtä asiaa) Rajapinnat Pieniä Eksplisiittisiä (ei piilotettuja tai vaikeasti havaittavia mekanismeja) Ymmärrettäviä ja selkeitä, hyvin dokumentoituja Modulien väliset kytkennät löyhiä Asiakaskoodin riippuvuus rajapinnasta, ei toteutuksesta Luotettavien hyvin testattujen moduulien käyttö Valmiit kirjastot ja komponentit Uudellenkäytön usein unohdettu hyöty! Integrointitestaus Integrointitestauksesta on kyse aina kun kaksi erillään suunniteltua ja toteutettua yksikköä yhdistetään Voi olla sama ohjelmoija, toteutukset ajallisesti erillään Testaus kohdennetaan yksiköiden yhteistoimintaan eli rajapintojen oikeellisuuteen ja niiden oikeaan käyttöön Oletus: yksikkötestaus suoritettu, koodi laadukasta Integrointia ja siten myös integrointitestausta tehdään monella eri tasolla Yhden pienen lisäominaisuuden integrointi, ns. jatkuvan integroinnin periaate (esim. ketterät toimintatavat) Jokapäiväinen rutiini kehittämisessä Suurehkojen erillään kehitettyjen modulien (osajärjestelmien) integrointi Vaatii erilliset testaajat ja mahdollisesti monimutkaisia testijärjestelyjä Modulin integrointi johonkin ohjelmistoalustaan tai valmiiseen ohjelmistokomponenttiin 8

9 Integrointitestaus Tekniikat yleensä white-box painottuneita Testausvastuu vaihtelee kehittäjien ja erillisten testaajien välillä Jatkuvassa integroinnissa testausvastuu kehittäjillä Osajärjestelmien integroinnissa vastuu erillisillä testaajilla Testauksen kohdentaminen Modulien väliset liittymät Toimiiko tiedonvälitys rajapinnoissa Toimiiko kytkentä (esim. ajoitukset realiaikajärjestelmissä, jaetut laiteresurssit) Kokonaisuus - toimivatko syntyvät toiminnot oikein? Onko väärinymmärryksiä tai vääriä tulkintoja? Esim. Nasan luotain menetettiin cm - in tulkintaeron vuoksi Integrointitestauksen strategiat Big Bang Big Bang integrointi: yksikkötestataan (jollain tasolla) kaikki yksiköt erikseen ja integroidaan ne kertarysäyksellä yhteen Ei ole yleensä hyvä idea vähänkään suuremmissa ohjelmissa! Ongelmia Virheiden paikantaminen hankalaa, ei tiedetä onko vika tietyn kahden modulin välisessä toiminnassa vai aiheutuuko se sivuvaikutuksena kauempaa vian ilmenemiskohdasta Virheitä tulee paljon kerralla, virheet peittävät toisiaan, oleellisia virheitä eit saada helposti esille Virheiden korjaus voi aiheuttaa sivuvaikutuksia muihin moduuleihin, joudutaan tekemään useita testaa-korjaa syklejä Yksikkötestaus on työläs sillä valmiita moduuleja ei päästä käyttämään hyväksi vaan kaikille on kirjoitettava apukoodit (tynkämoduulit, ajurit) Vesiputousmallin mukaisen ohjelmistokehityksen ja myös puritanistisen V-mallin tulkinnan mukainen tilanne 9

10 Integrointitestaksen strategiat Inkrementaalinen integrointi: Top-Down SUT 1) 2) A Ylin moduli testataan tynkien avulla 3) B F G 4) Tynkämodulit korvataan oikeilla yksi kerrallaan C D E Lisättäessä uusia moduleita, Aikaisemmat testit ajetaan uudelleen (ainakin osa) Integrointitestaksen strategiat Inkrementaalinen integrointi: Bottom-Up A SUT B F G C Testiajurit korvataan testatuilla klustereilla Yksi kerrallaan Moduleista kootaan klustereita D E Klusteri Bottom-up on eri asia kuin big bang, matalan tason moduuleja ei integroida kerralla vaan klustereittain 10

11 Integrointitestaksen strategiat Virheen paikantaminen Testi näyttää virhettä, mutta mistä se johtuu? Jos paikallistetaan virhe kahden modulin yhteistoimintaan, kummassa virhe on? Onko virhe rajapinnan toteutuksessa, onko se väärin ymmärretty rajapinnan spesifikaatioista, onko se moduulin toteutuksen virhe jota ei löydetty yksikkötestauksessa? Onko virhe peräisin jostain aivan muualta, sivuvaikutus? Uuden modulin integrointi voi rikkoa jo testattuja osia Lokalisointia helpottaa oleellisesti pienet inkrementit integroinnissa Rajapintavirheen korjaus vaatii usein koko järjestelmän uudelleen testauksen Integrointitestaksen strategiat Sopimuspohjainen ohjelmointi Sopimuspohjainen ohjelmointi Miinoitetaan koodia integraatiotesteillä, valvotaan ajonaikaisesti esi- ja jälkiehtojen toteutumista Jos esiehto ei voimassa, virhe kutsujassa Jos jälkiehto ei voimassa, virhe palvelun toteuttajassa Hyötyjä Rajapinnan integrointitestaus (tai ainakin osa siitä) on aina automaattisesti käytettävissä, riippumatta siitä mihin moduuli integroidaan Vähentää virheiden syntymistä koska rajapinnat paremmin määriteltyjä Ei poista erillisen integrointitestauksen tarvetta, täydentää sitä 11

12 Integrointitestaksen strategiat Sopimiuspohjainen ohjelmointi /** Palauttaa x:n neliöjuuren. x >= 0 Math.abs(RESULT * RESULT - x) * < 1.0e-10.0 & RESULT >= 0.0 */ public static double neliöjuuri(double x) //-- Alkuehto assert x >= 0.0 : "Alkuehtorikkomus"; //-- Totetus double tulos; // Lasketaan neliöjuuren arvo muuttujaan tulos... //-- Loppuehto assert tulos >= 0.0 : "Loppuehtorikkomus"; assert Math.abs(tulos * tulos - x) < 1.0e-10.0 : "Loppuehtorikkomus"; //-- Paluuarvo return tulos; } Integrointitestaksen strategiat Vertailua Arkkitehtuurin testaus ja arkkitehtuuritason virheet Top-down löytää todennäköisemmin virheitä arkkitehtuurista aikaisessa vaiheessa Bottom-up testing ei vaadi arkkitehtuurin kiinnittämistä ketterä ohjelmistoprosessi mahdollinen Järjestelmän toiminta Top-down antaa toimivan järjestelmän heti alussa demonstraatio, protoilu, motivaattori, varhainen järjestelmätestaus Bottom-up antaa myös toimivia kokonaisuuksia nopeasti mikäli toteutus suunnitellaan tämän tavoitteen mukaisesti toiminnalliset klusterit 12

13 Integrointitestaksen strategiat Vertailua Testien toteuttaminen Top-down vaatii tynkämodulien toteuttamisen, mikä on usein työlästä Bottom-up vaatii ajurien toteutuksen, usein helpompaa Tulosten kerääminen Top-down rakentamisessa yleensä ylimmät (kontrolli-) tasot eivät tuota mitään näkyvää tulostetta pitää toteuttaa tynkiin ylimääräisiä toimintoja raportoimaan mitä järjestelmässä tapahtuu Varhaisessa järjestelmätestauksessa usein tavoitteena ongelman ja ohjelman parempi ymmärrys asiakaspalautteen kautta Bottom-up vaatii usein ajureihin testattavien modulien toimintaa tarkkailevia ja tuloksia kerääviä osia. Käytännössä käytetään melkein aina yhdistelmää molemmista strategioista Bottom-up painottuu olio- ja komponenttipohjaisissa järjestelmissä Integrointitestaksen strategiat Realistinen, yhdistelmä Käytännössä molempia integrointisuuntia sovelletaan tilanteen mukaan Ohjelman rakentamisessa on etupäässä muista kuin testauksesta johtuvia syitä joiden perusteella integrointistrategia laaditaan Asiakkaan palautteen varhainen saanti Kriittisten tai erityisen vaikeiden osien varhainen toteutus teknisten riskien minimoimiseksi Monitiimisen kehityksen hallinta ja kustannuslogiikka Testauksen usein mukauduttava Pidettävä mielessä testauksen tavoitteet Oleellisten virheiden varhainen löytyminen Kehittämisen aikaisen laatuinformaation tuottaminen Testauksen kustannusten optimointi (ei minimointi joka tapahtuisi siten ettei testata :-) V-mallin testaustasojen väliset synergiat 13

14 Integrointitestauksen toteuttaminen Testauksen tavoitteisiin pyrittäessä ei ole olemassa mitään ehdottomia sääntöjä Tilanteenmukainen ja luova toiminta Kehittämisen aikainen kehittämistä tukeva arkkitehtuuri Järjestelmän arkkitehtuurissa on usein hierarkinen moduulirakenne Perusteluna mm. rinnakkainen kehittäminen, komponettiperustaisuus Integrointistrategia laaditaan tämän koostumiseen perustuvan arkkitehtuurin perusteella Testauksen kannalta kuitenkin moduulien riippuvuudet ovat paljon tärkeämpiä Riippuvuudet SUT:sta määrittävät onko kyseessä top-down vai bottom-up tilanne Yksikkötestien hyödynnettävyys integraatiotestauksessa Top-down integroinnissa suoraan hyödynnettävissä, joskaan eivät riittävät Bottom-up integroinnissa eivät testaa integroinnin SUT:ia, silti jätetään osaksi testikantaa mahdollisia tulevia muutoksia ja tulevia tynkien korvauksia varten Modernisoitu V-malli Testauksen synergiat 14

15 Yksikkötestien käyttö integrointitestauksessa SUT SUT Yksikkötestien käyttö integrointitestauksessa SUT 15

16 Tynkämoduleista Tynkämodulien käytölle on monia muitakin syitä kuin se että vastaava moduli on vielä toteuttamatta Ei haluta testata moduulia todellista moduulia vastaan Käyttö raskasta tai monimutkaista (esim. konfigurointi) Testiympäristön luonti työlästä tai mahdotonta Kontrollointi vaikeata Laitteistoja emuloidaan tynkämoduleilla yleisesti Laite ei saatavilla ohjelmistonkehitysympäristössä Laite ei stabiili Useita laiteympäristöjä, emuloinnilla testauksen automatisointi Testataan äärikäyttäytymistä, todellinen laite ei generoi ääriarvoja Testataan vikasietoisuutta eikä haluta oikeasti rikkoa laitetta Tynkämodulit ovat olennainen tekniikka käytännön testauksesa Esimerkki - Varhainen virheiden löytäminen SUT SUT hajautunut eri arkkitehtuurin yksiköihin Testausjärjestely C:n ja A:n varhaiseen integrointitestaukseen 16

17 Esimerkki - Testauksen kapselointi kehityksen aikana SUT Esimerkki - Testauksen kapselointi kehityksen aikana PalkanlaskuTest on samanaikaisesti sekä ajuri että tynkätietokanta Ajaa testitapauksia Kaappaa tietokantakutsut ja antaa niille tynkätoteutuksen Erittäin suuri kontrolli testaukseen Voidaan esimerkiksi tehdä testitapaus jonka pitäisi generoida virhe tietokantahaussa, palauttaa tuo virhe tynkätietokannasta ja testata miten SUT sen käsittelee Testitapausten suunnittelu yhdenmukaistuu, toteutus yhteen paikkaan Jotta yksikkötason (SUT = Palkanlasku) testitapaukset olisivat uudelleenkäytettävissä seuraavan vaiheen testauksessa (SUT = Palkanlasku + Tietokanta), on PalkanlaskuTest toteutettava niin että ajurin ja tyngän roolit on erotettavissa toisistaan Tynkä korvataan Tietokannan toteutuksella, ajuri ja testitapaukset uudelleenkäytettävissä 17

18 Esimerkki - Testauksen kapselointi kehityksen aikana Koko testaus on kapseloitu PalkanlaskuTest moduliin siten että järjestemä ei ole siitä lainkaan tietoinen 18

Ohjelmistojen mallintaminen. Luento 11, 7.12.

Ohjelmistojen mallintaminen. Luento 11, 7.12. Ohjelmistojen mallintaminen Luento 11, 7.12. Viime viikolla... Oliosuunnittelun yleiset periaatteet Single responsibility eli luokilla vain yksi vastuu Program to an interface, not to concrete implementation,

Lisätiedot

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää

Lisätiedot

Testaussuunnitelma PULSU. Syksy 2008 Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testaussuunnitelma PULSU. Syksy 2008 Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Testaussuunnitelma PULSU Syksy 2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9 op) Projektiryhmä Heikki Manninen Noora Joensuu

Lisätiedot

Laadunvarmistustekniikat

Laadunvarmistustekniikat Laadunvarmistustekniikat Ohjelmistojen laadunvarmistustekniikoita: testaus (testing) ohjelman suorittamista tarkoituksena löytää virheitä tarkastukset (inspections, reviews) asiantuntijoiden suorittamia

Lisätiedot

Kontrollipolkujen määrä

Kontrollipolkujen määrä Testaus Yleistä Testaus on suunnitelmallista virheiden etsimistä Tuotantoprosessissa ohjelmaan jää aina virheitä, käytettävistä menetelmistä huolimatta Hyvät menetelmät, kuten katselmoinnit pienentävät

Lisätiedot

Testaussuunnitelma. Koskelo. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testaussuunnitelma. Koskelo. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Testaussuunnitelma Koskelo Helsinki 16.12.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Tom Bertell Johan

Lisätiedot

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3 AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 7 Dokumenttihistoria Revisiohistoria Revision päiväys: 29.11.2004 Seuraavan

Lisätiedot

Verifioinnin ja validoinnin ero. 7. Verifiointi ja validointi. Verifiointi- ja validointitekniikat. Verifiointi- ja validointitekniikat II

Verifioinnin ja validoinnin ero. 7. Verifiointi ja validointi. Verifiointi- ja validointitekniikat. Verifiointi- ja validointitekniikat II 7. Verifiointi ja validointi Verifiointi ja validointi (V&V) on ohjelmistotuotannon työvaihe, missä varmistetaan, että ohjelmisto täyttää sille asetetut implisiittiset ja eksplisiittiset vaatimukset ja

Lisätiedot

Harjoitustyön testaus. Juha Taina

Harjoitustyön testaus. Juha Taina Harjoitustyön testaus Juha Taina 1. Johdanto Ohjelman teko on muutakin kuin koodausta. Oleellinen osa on selvittää, että ohjelma toimii oikein. Tätä sanotaan ohjelman validoinniksi. Eräs keino validoida

Lisätiedot

T Testiraportti - järjestelmätestaus

T Testiraportti - järjestelmätestaus T-76.115 Testiraportti - järjestelmätestaus 18. huhtikuuta 2002 Confuse 1 Tila Versio: 1.0 Tila: Päivitetty Jakelu: Julkinen Luotu: 18.04.2002 Jani Myyry Muutettu viimeksi: 18.04.2002 Jani Myyry Versiohistoria

Lisätiedot

Ohjelmistotekniikan menetelmät, toteutuksesta ja testauksesta

Ohjelmistotekniikan menetelmät, toteutuksesta ja testauksesta 582101 - Ohjelmistotekniikan menetelmät, toteutuksesta ja testauksesta 1 Toteutuksesta ja testauksesta Suunnitteluprosessista Tarkan tason luokkasuunnittelu Siirtyminen UML-kaavioista Java-toteutukseen

Lisätiedot

Testaussuunnitelma Labra

Testaussuunnitelma Labra Testaussuunnitelma Labra Helsinki 25.8.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos 1 Kurssi 581260 Ohjelmistotuotantoprojekti (9+1op) Projektiryhmä Anssi Kapanen,

Lisätiedot

3. Testaus osana ohjelmistoprosessia

3. Testaus osana ohjelmistoprosessia 3. Testaus osana ohjelmistoprosessia Ohjelmistotuotanto on paljon muutakin kuin testaamista. Mutta miten testaus liitetään ohjelmistoprosessiin? Tässä kohdassa esitellään ns. testauksen V-malli ja siihen

Lisätiedot

Yksikkötestaus. Kattava testaus. Moduulitestaus. Ohjelman testaus. yksikkotestaus/ Seija Lahtinen

Yksikkötestaus. Kattava testaus. Moduulitestaus. Ohjelman testaus. yksikkotestaus/ Seija Lahtinen Yksikkötestaus Kattava testaus Moduulitestaus Ohjelman testaus 1 Kattava testaus Testauksen perimmäinen tarkoitus on LÖYTÄÄ VIRHEITÄ Testaus pitäisi olla täydellinen: - Jokainen pyydetty arvo pitäisi testata

Lisätiedot

Testaustyökalut. Luento 11 Antti-Pekka Tuovinen. Faculty of Science Department of Computer Science

Testaustyökalut. Luento 11 Antti-Pekka Tuovinen. Faculty of Science Department of Computer Science Testaustyökalut Luento 11 Antti-Pekka Tuovinen 25 April 2013 1 Tavoitteet Työkalutyyppejä Testauksen hallinta Testien määrittely Staattinen analyysi Dynaaminen testaus 25 April 2013 2 1 Työkalut ja testaus

Lisätiedot

Convergence of messaging

Convergence of messaging Convergence of messaging Testaussuunnitelma The Converge Group: Mikko Hiipakka Anssi Johansson Joni Karppinen Olli Pettay Timo Ranta-Ojala Tea Silander Helsinki 20. joulukuuta 2002 HELSINGIN YLIOPISTO

Lisätiedot

Dynaaminen analyysi I

Dynaaminen analyysi I Dynaaminen analyysi I Luento 6 Antti-Pekka Tuovinen 4 April 2013 1 Tavoitteet Testitapausten suunnittelun ja suorituksen perusteet Black-Box testitapausten suunnittelu Ekvivalenssiluokat Raja-arvo (reuna-arvo)

Lisätiedot

Mihin kaikkeen voit törmätä testauspäällikön saappaissa?

Mihin kaikkeen voit törmätä testauspäällikön saappaissa? Mihin kaikkeen voit törmätä testauspäällikön saappaissa? Arto Stenberg Copyright Kuntien Tiera Oy Kuntien Tiera Copyright Kuntien Tiera Oy Tiera on vuonna 2010 perustettu yli 200:n kuntatoimijan omistama

Lisätiedot

Testaus käsite. Sekalaista testausasiaa. Testauksen käsitteestä. Kattavuusmitat. Jos ajatellaan, että testaus = V&V, voidaan erottaa:

Testaus käsite. Sekalaista testausasiaa. Testauksen käsitteestä. Kattavuusmitat. Jos ajatellaan, että testaus = V&V, voidaan erottaa: Testaus käsite Sekalaista asiaa Sami Kollanus 15.11.2006 Jos ajatellaan, että = V&V, voidaan erottaa: Staattinen Dynaaminen Toisaalta voidaan määritellä Myersin (1979) mukaan: Testaus on ohjelman suoritusta,

Lisätiedot

Automaattinen yksikkötestaus

Automaattinen yksikkötestaus Teknillinen Korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Automaattinen yksikkötestaus Ryhmä Rajoitteiset Versio Päivämäärä Tekijä

Lisätiedot

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 7 Dokumenttihistoria Revisiohistoria Revision Numero Revision Päiväys

Lisätiedot

Test-Driven Development

Test-Driven Development Test-Driven Development Ohjelmistotuotanto syksy 2006 Jyväskylän yliopisto Test-Driven Development Testilähtöinen ohjelmistojen kehitystapa. Tehdään ensin testi, sitten vasta koodi. Tarkoituksena ei ole

Lisätiedot

Testaus osana ohjelmistojen elinkaarta I

Testaus osana ohjelmistojen elinkaarta I Testaus osana ohjelmistojen elinkaarta I Luento 3 Antti-Pekka Tuovinen www.cs.helsinki.fi 19 March 2013 1 Oppimistavoitteet Ohjelmistokehityksen V-malli Testauksen tasot Komponenttitestaus Integrointitestaus

Lisätiedot

Mihin kaikkeen voit törmätä testauspäällikön saappaissa?

Mihin kaikkeen voit törmätä testauspäällikön saappaissa? Mihin kaikkeen voit törmätä testauspäällikön saappaissa? Arto Stenberg Copyright Kuntien Tiera Oy Kuntien Tiera Copyright Kuntien Tiera Oy Tieran toiminta perustuu osaamisverkoston rakentamiseen, mikä

Lisätiedot

Yksikkötestaus. import org.junit.test; public class LaskinTest public void testlaskimenluonti() { Laskin laskin = new Laskin(); } }

Yksikkötestaus. import org.junit.test; public class LaskinTest public void testlaskimenluonti() { Laskin laskin = new Laskin(); } } Yksikkötestauksella tarkoitetaan lähdekoodiin kuuluvien yksittäisten osien testaamista. Termi yksikkö viittaa ohjelman pienimpiin mahdollisiin testattaviin toiminnallisuuksiin, kuten olion tarjoamiin metodeihin.

Lisätiedot

Test-Driven Development

Test-Driven Development Test-Driven Development Syksy 2006 Jyväskylän yliopisto Test-Driven Development Testilähtöinen ohjelmistojen kehitystapa. Tehdään ensin testi, sitten vasta koodi. Tarkoituksena ei ole keksiä kaikkia mahdollisia

Lisätiedot

Suunnitteluvaihe prosessissa

Suunnitteluvaihe prosessissa Suunnittelu Suunnitteluvaihe prosessissa Silta analyysin ja toteutuksen välillä (raja usein hämärä kumpaankin suuntaan) Asteittain tarkentuva Analyysi -Korkea abstraktiotaso -Sovellusläheiset käsitteet

Lisätiedot

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016 CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016 VIIME KERRALLA MENETELMIÄ Musta laatikko Valkea laatikko Harmaa laatikko Regressio Automaatio Rasitus (kuormitus)

Lisätiedot

Hirviö Laadunvarmistussuunnitelma

Hirviö Laadunvarmistussuunnitelma Hirviö Laadunvarmistussuunnitelma Jani Heikkinen Anssi Kalliolahti Jukka Larja Kim Nylund Liia Sarjakoski Samuli Sorvakko Timo Toivanen 30. marraskuuta 2004 1 Sisältö 1 Johdanto 3 1.1 Testauksen tavoitteet

Lisätiedot

dokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant

dokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant AgilElephant Testausraportti I1 Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: Testausraportti Sivu 1 / 5 Dokumentti Historia Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision

Lisätiedot

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Liite 1: skenaariot ja PoC tulokset 1. Palvelun kehittäjän näkökulma Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Palvelun uusi versio on Palveluiden kehittäminen voitava asentaa tuotantoon vaikeutuu

Lisätiedot

Oleelliset vaikeudet OT:ssa 1/2

Oleelliset vaikeudet OT:ssa 1/2 Oleelliset vaikeudet OT:ssa 1/2 Monimutkaisuus: Mahdoton ymmärtää kaikki ohjelman tilat Uusien toimintojen lisääminen voi olla vaikeaa Ohjelmista helposti vaikeakäyttöisiä Projektiryhmän sisäiset kommunikointivaikeudet

Lisätiedot

Versio Päiväys Tekijä Kuvaus Tikkanen varsinainen versio

Versio Päiväys Tekijä Kuvaus Tikkanen varsinainen versio Testiraportti 26.2.2006 1/5 - Noheva II Testiraportti Versio Päiväys Tekijä Kuvaus 1.0 26.2.2006 Tikkanen varsinainen versio 1 Yleistä Toteutusvaiheen 2 virallinen testaus on muodostunut automaattisista

Lisätiedot

812341A Olio-ohjelmointi, IX Olioiden välisistä yhteyksistä

812341A Olio-ohjelmointi, IX Olioiden välisistä yhteyksistä 2016 IX Olioiden välisistä yhteyksistä Sisältö 1. Johdanto 2. Kytkentä 3. Koheesio 4. Näkyvyydestä 2 Johdanto n Ohjelmassa syntyy kytkentöjä olioiden välille Toivottuja ja epätoivottuja n Näkyvyys vaikuttaa

Lisätiedot

Tenttikysymykset. + UML-kaavioiden mallintamistehtävät

Tenttikysymykset. + UML-kaavioiden mallintamistehtävät Tenttikysymykset 1. Selitä mitä asioita kuuluu tietojärjestelmän käsitteeseen. 2. Selitä kapseloinnin ja tiedon suojauksen periaatteet oliolähestymistavassa ja mitä hyötyä näistä periaatteista on. 3. Selitä

Lisätiedot

TESTIRAPORTTI - VYM JA KANTA Virtuaaliyhteisöjen muodostaminen Versio 1.0

TESTIRAPORTTI - VYM JA KANTA Virtuaaliyhteisöjen muodostaminen Versio 1.0 TESTIRAPORTTI - VYM JA KANTA Versio 1.0 i Sisällysluettelo 1. YLEISTÄ 2 1.1. Dokumentin tarkoitus ja yleisiä toimintaohjeita 2 1.2. Viittaukset muihin dokumentteihin 2 2. SUORITETTAVA TESTI 3 2.1. Testauksen

Lisätiedot

Kuopio Testausraportti Asiakkaat-osakokonaisuus

Kuopio Testausraportti Asiakkaat-osakokonaisuus Kuopio Testausraportti Asiakkaat-osakokonaisuus Kuopio, testausraportti, 25.3.2002 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 11.2.2002 Matti Peltomäki Ensimmäinen versio 0.9 11.2.2002 Matti Peltomäki

Lisätiedot

Testilähtöinen ohjelmistokehitys. Testilähtöinen ohjelmistokehitys. TDD Testilähtöinen ohjelmistokehitys. Testi! Testi

Testilähtöinen ohjelmistokehitys. Testilähtöinen ohjelmistokehitys. TDD Testilähtöinen ohjelmistokehitys. Testi! Testi Testilähtöinen ohjelmistokehitys Kevät 2008 Jonne Itkonen Jyväskylän yliopisto Testilähtöinen ohjelmistokehitys Test-Driven Development, TDD Tehdään ensin testi, sitten vasta koodi. TDD Testilähtöinen

Lisätiedot

Tarkastusten rakenne. 10. Tarkastukset. Tuotoksen tekijän rooli. Tarkastustiimi. Tarkastusprosessin vaiheet. Tarkastusprosessi

Tarkastusten rakenne. 10. Tarkastukset. Tuotoksen tekijän rooli. Tarkastustiimi. Tarkastusprosessin vaiheet. Tarkastusprosessi 10. Tarkastukset Tarkastus (inspection) on tehokas analyysitekniikka, jota voidaan käyttää minkä tahansa projektin tuotoksen läpikäyntiin. Tarkastus on systemaattinen ja yksityiskohtainen katselmointi

Lisätiedot

58160 Ohjelmoinnin harjoitustyö

58160 Ohjelmoinnin harjoitustyö 58160 Ohjelmoinnin harjoitustyö Testaus 30.3.2009 Tuntiop. Sami Nikander sami.nikander@helsinki.fi 58160 Ohjelmoinnin harjoitustyö, Sami Nikander 30.3.2009 1 Testaus Ohjelman systemaattista tutkimista

Lisätiedot

T Testiraportti - integraatiotestaus

T Testiraportti - integraatiotestaus T-76.115 Testiraportti - integraatiotestaus 22. maaliskuuta 2002 Confuse 1 Tila Versio: 1.0 Tila: Päivitetty Jakelu: Julkinen Luotu: 19.03.2002 Jani Myyry Muutettu viimeksi: 22.03.2002 Jani Myyry Versiohistoria

Lisätiedot

Määrittelydokumentti NJC2. Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Määrittelydokumentti NJC2. Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Määrittelydokumentti NJC2 Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti ( ov) Projektiryhmä Eero Anttila Olli

Lisätiedot

Testaussuunnitelma. Ohjelmistotuotantoprojektin tietojärjestelmä OhtuTie

Testaussuunnitelma. Ohjelmistotuotantoprojektin tietojärjestelmä OhtuTie Testaussuunnitelma Ohjelmistotuotantoprojektin tietojärjestelmä OhtuTie Helsinki 14.7.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti

Lisätiedot

Esityksen sisältö Määrittelyjen mukaisuudesta varmistuminen - PlugIT-leima

Esityksen sisältö Määrittelyjen mukaisuudesta varmistuminen - PlugIT-leima Esityksen sisältö Johdanto Yleistä leimausmenettelystä ja leimasta Leimausmenettelyn vaiheet Kuinka määrittelyjen mukaisuus testataan: esimerkkejä testitapauksista Olennaisimmat kysymykset leimausmenettelyn

Lisätiedot

Olio-ohjelmien testaamisesta

Olio-ohjelmien testaamisesta Olio-ohjelmien testaamisesta Mika Katara et. al. Ohjelmistotekniikan laitos Tampereen teknillinen yliopisto 13.8.2013 Ohjelmistojen testaus, 2013 1(32) Sisällysluettelo 1/2 Olio-ohjelmien testaamisesta

Lisätiedot

2. Ohjelmistotuotantoprosessi

2. Ohjelmistotuotantoprosessi 2. Ohjelmistotuotantoprosessi Peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa

Lisätiedot

TESTIRAPORTTI - XMLREADER-LUOKKA Virtuaaliyhteisöjen muodostaminen Versio 1.0 (luonnos 2)

TESTIRAPORTTI - XMLREADER-LUOKKA Virtuaaliyhteisöjen muodostaminen Versio 1.0 (luonnos 2) TESTIRAPORTTI - XMLREADER-LUOKKA Versio 1.0 (luonnos 2) Copyright Comptel Oyj i Sisällysluettelo 1. YLEISTÄ 2 1.1. Dokumentin tarkoitus ja yleisiä toimintaohjeita 2 1.2. Viittaukset muihin dokumentteihin

Lisätiedot

Hirviö Laadunvarmistussuunnitelma

Hirviö Laadunvarmistussuunnitelma Hirviö Laadunvarmistussuunnitelma Jani Heikkinen Anssi Kalliolahti Jukka Larja Kim Nylund Liia Sarjakoski Samuli Sorvakko Timo Toivanen 8. helmikuuta 2005 1 Sisältö 1 Johdanto 3 1.1 Testauksen tavoitteet

Lisätiedot

Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa k

Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa k 1 Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa ko. toiminnallisuuden hyödyntämisen Web-palveluna.

Lisätiedot

WCLIQUE. Ohjelmistoprojekti. Testaussuunnitelma

WCLIQUE. Ohjelmistoprojekti. Testaussuunnitelma TKK/DISKO/Tik-76.115 WCLIQUE Projektiryhmä Clique http://www.hut.fi/jekahkon/wclique/testplan.html WCLIQUE Ohjelmistoprojekti Projektiryhmä Clique: Janne Dufva, 75008T, email: janne.dufva@nokia.com, 75014C,

Lisätiedot

Sopisiko testiautomaatio yritykseesi juuri nyt? Testiautomaation soveltuvuuden arviointiopas

Sopisiko testiautomaatio yritykseesi juuri nyt? Testiautomaation soveltuvuuden arviointiopas Sopisiko testiautomaatio yritykseesi juuri nyt? Testiautomaation soveltuvuuden arviointiopas www.valagroup.fi TESTITAUTOMAATIO SINUN YRITYKSEESI? Testauksen automatisointi ei sovellu kaikkiin tilanteisiin;

Lisätiedot

11/20: Konepelti auki

11/20: Konepelti auki Ohjelmointi 1 / syksy 2007 11/20: Konepelti auki Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy 2007 p.1/11 Tämän luennon

Lisätiedot

T-76.5158 SEPA päiväkirja

T-76.5158 SEPA päiväkirja T-76.5158 SEPA päiväkirja Ryhmä 14 Automatisoitu yksikkötestaus Mikko Luukkonen, 60549T Lauri Helkkula, 62820H Matti Eerola, 60686A Versiohistoria Versio Pvm Tekijä(t) Kuvaus 0.3 25.11.2007 Luukkonen,

Lisätiedot

Kuopio Testausraportti Kalenterimoduulin integraatio

Kuopio Testausraportti Kalenterimoduulin integraatio Kuopio Testausraportti Kalenterimoduulin integraatio Kuopio, testausraportti, 22.4.2002 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 22.4.2002 Matti Peltomäki Ensimmäinen versio 0.9 22.4.2002 Matti

Lisätiedot

JReleaser Yksikkötestaus ja JUnit. Mikko Mäkelä 6.11.2002

JReleaser Yksikkötestaus ja JUnit. Mikko Mäkelä 6.11.2002 JReleaser Yksikkötestaus ja JUnit Mikko Mäkelä 6.11.2002 Sisältö Johdanto yksikkötestaukseen JUnit yleisesti JUnit Framework API (TestCase, TestSuite) Testien suorittaminen eri työkaluilla Teknisiä käytäntöjä

Lisätiedot

Ylläpito. Ylläpito. Ylläpidon lajeja Ohjelmistotuotanto, syksy 1998 Ylläpito

Ylläpito. Ylläpito. Ylläpidon lajeja Ohjelmistotuotanto, syksy 1998 Ylläpito Kaikki ohjelmistoon sen julkistamisen jälkeen kohdistuvat muutostoimenpiteet jopa 70-80% ohjelmiston elinkaarenaikaisista kehityskustannuksista Ylläpidon lajeja korjaava ylläpito (corrective) testausvaiheessa

Lisätiedot

7. Verifiointi ja validointi

7. Verifiointi ja validointi 7. Verifiointi ja validointi Verifiointi ja validointi (V&V) on ohjelmistotuotannon työvaihe, missä varmistetaan, että ohjelmisto täyttää sille asetetut implisiittiset ja eksplisiittiset vaatimukset ja

Lisätiedot

TIE Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori

TIE Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori TIE-21204 Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2 Antti Jääskeläinen Matti Vuori Työn yleiset järjestelyt 14.9.2015 2 Valmistautuminen Ilmoittaudu kurssille Lue harjoitustyön nettisivut

Lisätiedot

Ohjelmoinnin perusteet Y Python

Ohjelmoinnin perusteet Y Python Ohjelmoinnin perusteet Y Python T-106.1208 2.3.2009 T-106.1208 Ohjelmoinnin perusteet Y 2.3.2009 1 / 28 Puhelinluettelo, koodi def lue_puhelinnumerot(): print "Anna lisattavat nimet ja numerot." print

Lisätiedot

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14 Arkkitehtuurikuvaus Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Ryhmä 14 Muutoshistoria Versio Pvm Päivittäjä Muutos 1.0 19.10.2007 Suanto 0.3 18.10.2007 Matti Eerola 0.2 17.10.2007

Lisätiedot

Kuntokirjuri. Testausraportti. Miika Alonen Jarkko Laine Jesse Honkanen Veli Matti Huovinen Jani Jäntti. Versio 1.1 16.5.2008

Kuntokirjuri. Testausraportti. Miika Alonen Jarkko Laine Jesse Honkanen Veli Matti Huovinen Jani Jäntti. Versio 1.1 16.5.2008 Kuntokirjuri Testausraportti Miika Alonen Jarkko Laine Jesse Honkanen Veli Matti Huovinen Jani Jäntti Versio 1.1 16.5.2008 Jakelu: Asiakas Jukka Rantala Ohjaaja Erkki Pesonen Opponoiva ryhmä 1 Kuopion

Lisätiedot

Automaattinen regressiotestaus ilman testitapauksia. Pekka Aho, VTT Matias Suarez, F-Secure

Automaattinen regressiotestaus ilman testitapauksia. Pekka Aho, VTT Matias Suarez, F-Secure Automaattinen regressiotestaus ilman testitapauksia Pekka Aho, VTT Matias Suarez, F-Secure 2 Mitä on regressiotestaus ja miksi sitä tehdään? Kun ohjelmistoon tehdään muutoksia kehityksen tai ylläpidon

Lisätiedot

812341A Olio-ohjelmointi Peruskäsitteet jatkoa

812341A Olio-ohjelmointi Peruskäsitteet jatkoa 812341A Olio-ohjelmointi 2106 Peruskäsitteet jatkoa Luokkakohtaiset piirteet n Yhteisiä kaikille saman luokan olioille n Liittyvät luokkaan, eivät yksittäiseen olioon n Kaikki ko. luokan oliot voivat käyttää

Lisätiedot

Laadunvarmistustekniikoita. Ohjelmistotuotanto. Testaus termejä. Testaus periaatteita. Testaus havaintoja. Testaus havaintoja

Laadunvarmistustekniikoita. Ohjelmistotuotanto. Testaus termejä. Testaus periaatteita. Testaus havaintoja. Testaus havaintoja Laadunvarmistustekniikoita Ohjelmistotuotanto Ohjelmistojen testaus 1 Testaus (testing) ohjelman suorittamista tarkoituksena löytää virheitä Tarkastukset, katselmukset (inspections, reviews) asiantuntijoiden

Lisätiedot

Harjoitustyö 3 - Reittioptimisaatio

Harjoitustyö 3 - Reittioptimisaatio Harjoitustyö 3 - Reittioptimisaatio Tampereen kaupunki tarjoaa avoin data -sivuilla kaupungin avoimena julkaistun tietoaineston osana Tampereen joukkoliikenteen aikataulut, reitit sekä rajapinnan joukkoliikenteen

Lisätiedot

Standardin IEC testaustekniikoista. V-malli vai ketterämpi prosessi?

Standardin IEC testaustekniikoista. V-malli vai ketterämpi prosessi? Standardin IEC 61508-3 testaustekniikoista V-malli vai ketterämpi prosessi? Mika Katara mika.katara@tut.fi Tampereen teknillinen yliopisto Ohjelmistotekniikan laitos 2 Sisältö Termien käännökset Johdanto

Lisätiedot

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia Ohjelmistojen mallintaminen, kurssikoe 15.12. esimerkkivastauksia Tehtävä 1 a: Ohjelmistotuotantoprosessi sisältää yleensä aina seuraavat vaiheet: määrittely, suunnittelu, toteutus, testaus ja ylläpito.

Lisätiedot

tsoft Tarkastusmenettelyt ja katselmukset Johdanto Vesa Tenhunen 4.2.2004

tsoft Tarkastusmenettelyt ja katselmukset Johdanto Vesa Tenhunen 4.2.2004 Tarkastusmenettelyt ja katselmukset tsoft Vesa Tenhunen 4.2.2004 http://cs.joensuu.fi/tsoft/ Johdanto Yksi tärkeimmistä tekijöistä laadukkaiden ohjelmistojen tuottamisessa on puutteiden aikainen havaitseminen

Lisätiedot

Dynaaminen analyysi III

Dynaaminen analyysi III Dynaaminen analyysi III Luento 8 Antti-Pekka Tuovinen 16 April 2013 1 Tavoitteet White box testitapausten suunnittelutekniikat Lausekattavuus Haarautumakattavuus Ehto- ja polkukattavuus Huomioita white

Lisätiedot

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 8 Dokumenttihistoria Revisiohistoria Revision Numero Revision Päiväys

Lisätiedot

Opintojakso TT00AA11 Ohjelmoinnin jatko (Java): 3 op Rajapinnat ja sisäluokat

Opintojakso TT00AA11 Ohjelmoinnin jatko (Java): 3 op Rajapinnat ja sisäluokat Opintojakso TT00AA11 Ohjelmoinnin jatko (Java): 3 op Rajapinnat ja sisäluokat Rajapinnat Java-kieli ei tue luokkien moniperintää. Jokaisella luokalla voi olla vain yksi välitön yliluokka. Toisinaan olisi

Lisätiedot

Onnistunut SAP-projekti laadunvarmistuksen keinoin

Onnistunut SAP-projekti laadunvarmistuksen keinoin Onnistunut SAP-projekti laadunvarmistuksen keinoin 07.10.2010 Patrick Qvick Sisällys 1. Qentinel 2. Laadukas ohjelmisto täyttää sille asetetut tarpeet 3. SAP -projektin kriittisiä menestystekijöitä 4.

Lisätiedot

LAATURAPORTTI Iteraatio 1

LAATURAPORTTI Iteraatio 1 LAATURAPORTTI Iteraatio 1 LAATURAPORTTI 2 (7) VERSION HALLINTA Versio Päivä Tekijä Kuvaus 0.1 9.12.2006 Kaarlo Lahtela Ensimmäinen versio 0.2 Kaarlo Lahtela Korjauksia 1.0 Lauri Kiiski Katselmointi ja

Lisätiedot

Ohjelmiston testaus ja laatu. Testaus yleistä

Ohjelmiston testaus ja laatu. Testaus yleistä Ohjelmiston testaus ja laatu Testaus yleistä Määritelmä Testaus on systemaattinen lähestymistapa ohjelmistoissa esiintyvien virheiden löytämiseksi ohjelmaa suorittamalla. Testattaessa pyritään luomaan

Lisätiedot

Vakuutusyhtiöiden testausinfo

Vakuutusyhtiöiden testausinfo Vakuutusyhtiöiden testausinfo ATJ:n ulkoisten liittymien testaaminen Jonna Hannukainen ja Markku Noukka 12. ja 17.5.2006 (Päivitetty 18.5.2006) ATJ:n integraatiotestaus vakuutusyhtiöiden kanssa Testauksen

Lisätiedot

1 Tehtävän kuvaus ja analysointi

1 Tehtävän kuvaus ja analysointi Olio-ohjelmoinnin harjoitustyön dokumentti Jyri Lehtonen (72039) Taneli Tuovinen (67160) 1 Tehtävän kuvaus ja analysointi 1.1 Tehtävänanto Tee luokka, jolla mallinnetaan sarjaan kytkettyjä kondensaattoreita.

Lisätiedot

statbeatmobile PROJECT REVIEW iteration 1

statbeatmobile PROJECT REVIEW iteration 1 statbeatmobile PROJECT REVIEW iteration 1 agenda Projekti Status Käytännöt Tulokset Katsaus eteenpäin PROJEKTI / mikä on statbeat? Sosiaalinen joukkueurheilupalvelu Keskustelu, fanit, kavereiden joukkueet,

Lisätiedot

Harjoitustyö 3 - Millosemeni

Harjoitustyö 3 - Millosemeni Harjoitustyö 3 - Millosemeni Tampereen kaupunki tarjoaa avoin data -sivuillaan Tampereen joukkoliikenteen aikataulut, reitit sekä rajapinnan joukkoliikenteen reaaliaikaiseen seurantaan. Näinpä erilaisille

Lisätiedot

Yhteenvetoa, pieniä laajennuksia, tulevaisuuden haasteita

Yhteenvetoa, pieniä laajennuksia, tulevaisuuden haasteita Yhteenvetoa, pieniä laajennuksia, tulevaisuuden haasteita 581259 Ohjelmistotuotanto 378 Lemström, 2006-2011 581259 Ohjelmistotuotanto Kiitos Tuomolle kuvasta 379 Ohjelmistotuotannon perustehtävät projektinhallinta:

Lisätiedot

Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio

Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio Analyysi Tarkentaa ja jäsentää vaatimusmäärittelyä, vastaa kysymykseen MITÄ järjestelmän tulisi tehdä. Suoritetaan seuraavia tehtäviä:

Lisätiedot

Testausoppeja toimialavaihdoksesta

Testausoppeja toimialavaihdoksesta Testausoppeja toimialavaihdoksesta Maaret Pyhäjärvi Email: Gsm: 040-8233777 Erkki Pöyhönen & Maaret Pyhäjärvi Nimeä Attribution (Finland) http://creativecommons.org/licenses/by/1.0/fi/

Lisätiedot

TIE Ohjelmistojen testaus 2016 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori

TIE Ohjelmistojen testaus 2016 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori TIE-21201 Ohjelmistojen testaus 2016 Harjoitustyö Vaiheet 1 ja 2 Antti Jääskeläinen Matti Vuori Työn yleiset järjestelyt 20.9.2016 2 Valmistautuminen Ilmoittaudu kurssille Lue harjoitustyön nettisivut

Lisätiedot

Testiautomaatio tietovarastossa. Automaattisen regressiotestauksen periaate ja hyödyt

Testiautomaatio tietovarastossa. Automaattisen regressiotestauksen periaate ja hyödyt Testiautomaatio tietovarastossa Automaattisen regressiotestauksen periaate ja hyödyt Sisältö 2 Testaus kiinteänä osana DW-toteutusta Regressiotestauksen merkitys Robot Framework Automatisoitu DW:n regressiotestaus:

Lisätiedot

Rajapinnat ja olioiden välittäminen

Rajapinnat ja olioiden välittäminen Rajapinnat ja olioiden välittäminen Moduulit/oliot kutsuvat toisiaan kapseloitujen rajapintojen läpi Kutsuissa välitetään usein olioita paikasta toiseen Jos olion omistus (= tuhoamisvastuu) säilyy koko

Lisätiedot

Testaus ja säästöt: Ajatuksia testauksen selviämisestä lama-aikana

Testaus ja säästöt: Ajatuksia testauksen selviämisestä lama-aikana Testaus ja säästöt: Ajatuksia testauksen selviämisestä lama-aikana Muutamia ajatuksia siitä, miten testaus pärjää lama-ajan säästötalkoissa. Laman patologioita ja mahdollisuuksia. Säästämisen strategioita.

Lisätiedot

815338A Ohjelmointikielten periaatteet

815338A Ohjelmointikielten periaatteet 815338A Ohjelmointikielten periaatteet 2015-2016 VIII Poikkeusten ja tapahtumien käsittely Sisältö 1. Poikkeusten käsittelyn käsitteitä ja suunnittelukriteerejä 2. Poikkeusten käsittely C++:ssa 3. Poikkeusten

Lisätiedot

Olion elinikä. Olion luominen. Olion tuhoutuminen. Olion tuhoutuminen. Kissa rontti = null; rontti = new Kissa();

Olion elinikä. Olion luominen. Olion tuhoutuminen. Olion tuhoutuminen. Kissa rontti = null; rontti = new Kissa(); Sisällys 7. Oliot ja viitteet Olio Java-kielessä. Olion luominen, elinikä ja tuhoutuminen. Viitteiden käsittelyä: sijoitus, vertailu ja varautuminen null-arvoon. Viite metodin paluuarvona.. 7.1 7.2 Olio

Lisätiedot

Oliosuunnitteluesimerkki: Yrityksen palkanlaskentajärjestelmä

Oliosuunnitteluesimerkki: Yrityksen palkanlaskentajärjestelmä Oliosuunnitteluesimerkki: Yrityksen palkanlaskentajärjestelmä Matti Luukkainen 10.12.2009 Tässä esitetty esimerkki on mukaelma ja lyhennelmä Robert Martinin kirjasta Agile and Iterative Development löytyvästä

Lisätiedot

Ohjelmien testaustyökalut

Ohjelmien testaustyökalut Ohjelmien testaustyökalut Antti Hämäläinen Helsinki 13.11.2000 Ohjelmistotuotantovälineet seminaari HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Ohjelmien testaustyökalut Antti Hämäläinen Ohjelmistotuotantovälineet

Lisätiedot

AUTOMATISOITU REGRESSIOTESTAUS SULAUTETUN JÄRJESTELMÄN KEHITYSTYÖSSÄ

AUTOMATISOITU REGRESSIOTESTAUS SULAUTETUN JÄRJESTELMÄN KEHITYSTYÖSSÄ Jukka Määttälä AUTOMATISOITU REGRESSIOTESTAUS SULAUTETUN JÄRJESTELMÄN KEHITYSTYÖSSÄ Tietotekniikan pro gradu -tutkielma Ohjelmistotekniikan linja 27.6.2005 Jyväskylän yliopisto Tietotekniikan laitos Tekijä:

Lisätiedot

Ohjelmoinnin peruskurssien laaja oppimäärä, kevät

Ohjelmoinnin peruskurssien laaja oppimäärä, kevät Ohjelmoinnin peruskurssien laaja oppimäärä, kevät Luento 1: Testaus, ohjelman suunnittelutapoja Riku Saikkonen (osa kalvoista on suoraan ei-laajan kurssin luennoista) 14. 1. 2013 Sisältö 1 Ohjelmien testaustapoja

Lisätiedot

815338A Ohjelmointikielten periaatteet Harjoitus 3 vastaukset

815338A Ohjelmointikielten periaatteet Harjoitus 3 vastaukset 815338A Ohjelmointikielten periaatteet 2015-2016. Harjoitus 3 vastaukset Harjoituksen aiheena ovat imperatiivisten kielten muuttujiin liittyvät kysymykset. Tehtävä 1. Määritä muuttujien max_num, lista,

Lisätiedot

Testaussuunnitelma. Oppimistavoitteiden hallintajärjestelmä harri

Testaussuunnitelma. Oppimistavoitteiden hallintajärjestelmä harri Testaussuunnitelma Oppimistavoitteiden hallintajärjestelmä harri Helsinki 15.11.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti

Lisätiedot

Ohjelmiston testaussuunnitelma

Ohjelmiston testaussuunnitelma Ohjelmiston testaussuunnitelma Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1 1 Johdanto Tämä lukaa antaa yleiskuvan koko testausdokumentista.

Lisätiedot

Javan perusteita. Janne Käki

Javan perusteita. Janne Käki Javan perusteita Janne Käki 20.9.2006 Muutama perusasia Tietokone tekee juuri (ja vain) sen, mitä käsketään. Tietokone ymmärtää vain syntaksia (sanojen kirjoitusasua), ei semantiikkaa (sanojen merkitystä).

Lisätiedot

Käyttötapausanalyysi ja testaus tsoft

Käyttötapausanalyysi ja testaus tsoft Käyttötapausanalyysi ja testaus tsoft 15.09.2004 http://cs.joensuu.fi/tsoft/ Johdanto Use Case analyysi (käyttötapausanalyysi) on yleisesti käytetty järjestelmälle asetettujen toiminnallisten vaatimusten

Lisätiedot

Harjoitustyö: virtuaalikone

Harjoitustyö: virtuaalikone Harjoitustyö: virtuaalikone Toteuta alla kuvattu virtuaalikone yksinkertaiselle olio-orientoituneelle skriptauskielelle. Paketissa on testaamista varten mukana kaksi lyhyttä ohjelmaa. Ohjeita Noudata ohjelman

Lisätiedot

Dynaaminen analyysi II

Dynaaminen analyysi II Dynaaminen analyysi II Luento 7 Antti-Pekka Tuovinen 9 April 2013 1 Tavoitteet Black-box testitapausten suunnittelutekniikat II Tilamallien käyttö Syys-seurausverkot ja päätöstaulut Käyttötapaukset Yhteenveto

Lisätiedot

Power Steering for ATV

Power Steering for ATV AS-0.3200 Automaatio- ja systeemitekniikan projektityöt Power Steering for ATV 27.1.2014 Juuso Meriläinen Antti Alakiikonen Aleksi Vulli Meriläinen, Vulli, Alakiikonen 1/6 Projektin tavoite Projektityössä

Lisätiedot

TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM!

TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM! TARJOUSPYYNTÖ / LIITE 1 1 (5) TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM! Tällä liitteellä yksilöidään hankinnan kohteen ominaisuuksia ja toiminnallisuuksia, jotka

Lisätiedot