SEPA päiväkirja. BetaTeam. Kauko Huuskonen, 54396W, Hannu Kankaanpää, 58605L,
|
|
- Anne-Mari Sariola
- 7 vuotta sitten
- Katselukertoja:
Transkriptio
1 SEPA päiväkirja BetaTeam Kauko Huuskonen, 54396W, Hannu Kankaanpää, 58605L, Versio Pvm Tekijä Kuvaus Kauko Huuskonen Template Kauko Huuskonen Johdanto Hannu Kankaanpää Lähdeluettelo, henkilökohtaiset valintaperusteet, johdanto-kappaleen loppuosa, soveltamis-kappaleeseen lisää tekstiä Kauko Huuskonen Kappale Hannu Kankaanpää Täsmennyksiä kappaleeseen Kauko Huukonen Kokemuksia Hannu Kankaanpää Kokemuksia Hannu Kankaanpää Lisää kokemuksia
2 SEPA päiväkirja Automaattinen yksikkötestaus Sisältö: 1. Johdanto 1.1. Automaattinen yksikkötestaus 1.2. Henkilökohtaiset valintaperusteet 2. Käytäntöön soveltaminen 3. Kokemukset ja muutokset 3.1. Implementaatio Implementaatio Yhteenveto 4. Lähdeluettelo 1. Johdanto 1.1. Automaattinen yksikkötestaus Yksikkö(Unit) on pienin mahdollinen testattava ohjelmistokomponentti (Burnstein 2003). Yksikkö on perinteisesti funktio tai proseduuri, jos asiaa tarkastellaan imperatiivisen ohjelmointikielen kannalta. Oliopohjaisessa kielessä yksiköksi voidaan katsoa sekä metodi että luokka (class). Yksikkötestaamisella varmistetaan, että komponentti toimii määritysten mukaisesti. Menetelmänä se sijoittuu esimerkiksi V-mallissa testaamisen alimmalle tasolle. Testaaminen suoritetaan jokaiselle komponentille erikseen ennenkuin ne integroidaan osaksi suurempaan kokonaisuuteen. Yksikkötestaus voidaan suorittaa ad hoc -hengessä: kun kirjoitetaan lähdekoodiin muutoksia, ohjelma käännetään ja varmistetaan oikean toiminnallisuuden lisääminen. Yksikkötestaus voi olla myös huolellisesti valmisteltua, joka on suositeltavaa. Testitulokset raportoidaan tällöin osaksi yksikön historiaa. Testaamisessa suoritettavat toimet: Suunnitellaan yleinen lähestymistapa yksikkötesteille Suunnitellaan testitapaukset Määritetään relaatiot testeille Valmistellaan yksikkötesteissä käytettävä koodi
3 Yksikkötestaamisessa käytetyt testitapaukset tulisi suunnitella käyttäen sekä Black box että White box strategioita. Tavoitteena on löytää uhkia määrityksistä, algoritmeista, datasta, ohjauslogiikasta jne. Koska kaikkea ei voi testata, tulisi testata ensisijaisesti niitä ominaisuuksia joissa ongelmia on todennäköisimmin, tai joiden toimivuus on kriittisintä. Yksiköitä tulisi testata sekä tavallisilla syötteillä että virheellisillä, sekä syötteillä jotka tuottavat mahdollisesti epäintuitiivisia tuloksia. Testien tulisi olla mahdollisimman pitkälle automatisoituja, sillä näillä voidaan suorittaa vaivattomasti regressiotestausta bugien korjauksen, uuden toiminnallisuuden lisäämisen ja integroinnin yhteydessä. Nämä testit säilyttävät arvonsa tulevaisuutta ajatellen. Testaaminen yksikkötasolla on elintärkeää sillä tässä vaiheessa bugien jäljittäminen ja korjaaminen tulee halvaksi verrattuna myöhempiin vaiheesiin. Automaattisista yksikkötason testeistä on myös hyötyä yksiköiden toiminnallisuuden ja käyttötapojen kuvaamisessa. Hyvin kirjoitetut testit kertovat täsmällisesti ja luotettavasti miten yksiköt toimivat sekä tavallisissa että poikkeuksellisissa tapauksissa. Näistä voi olla suurta hyötyä korkeamman tason toiminnallisuutta toteutettaessa, erityisesti jos yksikköjen dokumentaatio on puutteellista tai virheellistä. Yksikkötestien suunnitteleminen myös helpottaa itse yksiköiden suunnittelemista modulaarisemmiksi. Jotta yhtä yksikköä voisi testata mahdollisimman eristettynä muusta järjestelmästä, yksikön tulee olla rakennettu irralliseksi komponentiksi. Ilman yksikkötestausta yksiköillä on mahdollisesti vain yksi käyttötarkoitus, minkä takia yksiköitä ei välttämättä suunnitella irroitettavaksi ympäristöstään. Mutta yksikkötesti lisää jokaiselle yksikölle yhden ylimääräisen käyttötarkoituksen, testauksen, joka pitää ottaa suunnittelu- ja kehitysvaiheessa huomioon. Äärimmilleen viety automaattinen yksikkötason testaus voi viedä huomattavasti aikaa. On tyyppillistä esimerkiksi rakentaa pelkästään testauskäyttöön tarkoitettu socket-luokka, joka simuloi verkossa tapahtuvia häiriöitä deterministisesti. Eräät kehittäjät ovat kertoneet projektiensa sisältävän enemmän yksikkötestaukseen liittyvää koodia kuin itse ohjelman toiminnallisuutta parantavaa koodia. Kuitenkin nämä testihullut vakuuttavat että lopputuloksena on luotettavampaa koodia, joka kaiken lisäksi valmistuu nopeammin. Projektissamme automaattinen yksikkötestaus on äärimmäisen tärkeää, sillä joudumme työskentelemään suurissa määrin vanhan koodikannan puitteissa, ja myös sitä muokaten. Yksikkötesteillä voimme varmistaa että vanha koodikanta toimii dokumentaation mukaisesti, ja ettemme muutoksillamme riko sen edelleen tuettua toiminnallisuutta. Ilman yksikkötestien antamaa tietoa vanhojen komponenttien toiminnasta, emme virheiden ilmaantuessa voisi välttämättä ollenkaan arvailla virheen syytä. Koska projektimme käsittelee kriittisiä alueita NAPA-ohjelmistosta, siis tietojen lukemista, kirjoittamista ja poistamista, meidän tulee varmentaa mahdollisimman hyvin ettei koodimme ole viallista. Lisäksi kattavien yksikkötestien avulla voimme myös vakuuttaa asiakkaamme koodimme luotettavuudesta. Aiheesta lukemamme artikkelit on lueteltu lähdeluettelossa.
4 1.2. Henkilökohtaiset valintaperusteet Hannu Olen kiinnostunut testivetoisesta kehityksestä (test driven development), mutta koska en omaa hirveästi aiempaa kokemusta edes tavallisesta yksikkötestaamisesta, ajattelin tämän SEPA-aiheen sopivan parhaiten ponnahduslaudaksi testauksen ihmeelliseen maailmaan. Tässä projektissa pääsee testaamaan mm. itse kirjoittamaansa Java-koodia, muiden ryhmäläisten kirjoittamaa koodia, vanhaa Fortan-koodia sekä tietokantaa. Testattavien alueiden kirjo on siis varsin laaja, ja uskoisin oppivani paljon. Luin tätä projektia varten erityisesti mock-olioista (mm. Lähteet [2], [3] ja [4]) sillä ajattelin niitä tarvittavan mm. tietokantayhteyksien testaamisessa. JUnit:n käyttö on myös uutta Kauko Olen koko syksyn ajan opiskellut ohjelmistotestaamisen periaatteita ja nähnyt monenlaisia raportointitapoja ja testitapauksia. Kiinnostukseni kohteena projektin alusta lähtien on ollut testaaminen, sen suunnittelu ja toteutus. Projektissamme tulee olemaan paljon testaamista ja laadun varmistamista, joten tulen saamaan arvokasta kokemusta ohjelmiston testaamisesta oikeassa kehitysprojektissa. 2. Käytäntöön soveltaminen Projektissamme yksikkötason testaus on suuressa roolissa, sillä funktionaalisuutta on hajoitettu todella paljon pieniin osiin. Lähdekoodi on kirjoitettu mm. Fortranilla, Javalla ja C:llä. Alkuperäisiä muistinhallinta-funktioita on lukuisia ja joudumme käyttämään näitä siirtäessämme dataa uuteen luomaamme tietokantaan ja hakiessamme tietoa sieltä. Käytämme testaamiseen Javan JUnit-kirjastoa. Projektimme sydän on Javassa, josta voimme kutsua C-funktioita, niiden kautta Fortran-funktioita (NAPA DLL), sekä tehdä kutsuja tietokantaan. Siksi on luonnollista keskittää kaikki testaaminen Javaan, hyödyntäen suosittua JUnit-kirjastoa. Yksikkötesteillä voimme varmistaa että se koodikanta, johon projektimme sisältyy, toimii tarvittavilta osin niin kuin oletamme. Vanhan koodin osalta yksikkö on pienin mahdollinen ulkoisesti testattava osa; Esimerkiksi funktiota, joka vain kirjoittaa muistiin, ei voi testata yksinään. Sen pariksi tarvitaan vielä lukufunktio, jolla testataan että muistista voidaan lukea sinne kirjoitetut tiedot oikein. Konseptuaalisesti tämä kuitenkin vastaa täysin Javan yksikkötestausta, jossa yksikkönä on luokka. Lisäksi varmennamme yksikkötesteillä tietysti oman koodimme toimivuuden, ja tarjoamme samalla asiakkalle esimerkkikoodia siitä kuinka kirjoittamiamme luokkia tulee käyttää. Jos asiakas tai ryhmämme löytää järjestelmästämme vikoja, pyrimme ensin kirjoittamaan testin joka demonstroi vikaa ja vasta sitten korjaamme vian. Näin voimme saada jonkinlaista varmuutta siitä, että onnistuimme korjaamaan vian.
5 Nimeämme kaikki yksikkötestausluokkamme Test-päätteisiksi. Esim. luokka DmTest testaa luokkaa Dm. Teemme lisäksi yhden testitapauksen, jonka ajamalla saa ajettua kaikki testit automaattisesti. Muokkaamme tarvittaessa koodia helpommin testattavaksi, esimerkiksi käyttämällä suunnittelumallia Kontrollin kääntäminen [6]. Kirjoitamme tarvittaessa mock-olioita simuloimaan testattavan yksikön ulkopuolisia järjestelmän osia deterministisesti. Testejä kirjoittavat Hannu Kankaanpää, joka on projektissa pääasiassa kehitysroolissa, sekä Kauko Huuskonen, jonka roolina on pääasiassa testaus. Testitapauksien kirjoittaminen sijoittuu I1-iteraatiossa sen loppupäähän, ja painottuu myös I2-iteraatiossa loppupuoliskolle. I2-iteraatiossa saatamme kirjoittaa joitain testitapauksia jopa ennen itse toiminnallisuuden kirjoittamista, ja raportoimme kokemuksista. Testien kirjoittamisen jälkeen niitä pyritään ajamaan usein: Kaikki testit ajetaan läpi vähintään viikottain, ja useammin jos ongelmia ilmenee. Testeissä ilmenevät viat raportoidaan välittömästi viallisen koodin kirjoittaneelle kehittäjälle, jonka ensimmäisen prioriteetin tulee olla testissä paljastuneen vian korjaaminen ellei hänellä ole pätevää syytä tehdä jotain muuta osa-aluetta ensin. IMPLEMENTAATIO I Viikolla 47: Yksikkötestaus alkaa. NAPA:n muistinkäsittelyfunktioiden ja tietokannan luku-ominaisuuden testaamista. Viikolla 48: Testit kirjoitus ja poisto-ominaisuuksille. IMPLEMENTAATIO II 3. Kokemukset ja muutokset 3.1. Implementaatio Kauko Projektin ensimmäisessä iteraatiossa aikataulu venyi kehittämisen osalta. Tämä johtui projektin luonteesta: tutkimme tarkkaan mitä kehitämme ja miten. Yksikkötason testitapauksia oli vaikea hahmottaa ja testaaminen viivästyi. Käytönnössä yksiköiden testaaminen vaatii vielä suunnittelua, joten suoritamme yksikkötestausta laajemmin vasta toisessa iteraatiossa. Saimme ensimmäisen iteraation lopussa toteutuksemme käännettävään kuntoon ja ajettua ensimmäiset testit. Automaattinen yksikkötestaus käsitteenä oli projektin alussa vielä hieman hämärän peitossa. Nyt olen tutustunut periaatteisiin tarkemmin teoreettisella tasolla ja odotan saavani käytännön kokemuksia toisen iteraation aikana Hannu
6 Tässä iteraatiossa testaus aloitettiin varsin myöhäisessä vaiheessa, koska implementaation työstäminen testattavaan vaiheeseen vei aikaa. Ajan puutteesta johtuen en ehtinyt toteuttamaan mock-olioita järjestelmälle, ja joistain automaattisista testeistä tuli siten varsin laaja-alaisia. Sain kuitenkin runsaasti ideioita siitä, miten toteutusta voisi muuttaa seuraavassa vaiheessa helpommin testattavaksi. Testaamista olisi pitänyt suunnitella jo ennen implementaation aloittamista, jotta implementaation olisi voinut kirjoittaa samantein oikein. Siis vaikka kirjottaisimmekin kakkositeraatiossa testit vasta loppupuolella, olisi hyvä huomioida testaamisen aiheuttamat vaatimukset jo suunnitteluvaiheessa. Otimme suunnitellusti käyttöön JUnit-kirjaston, ja toteutin jonkinlaiset testit käytännössä kaikille merkittäville Java-luokille (joista osa toimii kutsurajapintoina C- ja Fortrankoodille). TestAll-luokka ajaa kaikki testit yhdellä kertaa. Natiivin koodin testaaminen DLL:n avulla oli suoraviivaista, mutta vaati melkoisesti wrapper-koodia. Koska käytössämme oli vain yksi ympäristö, jolla DLL:n pystyi kääntämään (asiakkaan kannettava), ja DLL:n muuntamisvastuu oli toisella kehittäjällä, testaaminen hidastui kohtuuttomasti. Aina kun bugi löytyi natiivista päästä, piti odotella että toinen kehittäjä luo uuden DLL:n joka korjaa virheen, vaikka virhe olisi ollut hyvin yksinkertainenkin. Jos kukin kehittäjä kirjoittaisi alustavat yksikkötestit itse omalle koodilleen, suurin osa bugeista saataisiin nopeasti poistettua. Koodin kirjoittanut henkilö tietäisi parhaiten, missä viat ovat, ja osaisi korjata ne nopeasti. Toisaalta ulkopuolisten suorittama black box-testaus voi paljastaa bugeja, joita koodin kirjoittanut henkilö ei osaisi kuvitellakaan. Tässä ensimmäisessä iteraatiossa lähes kaikki testaus oli white box-testausta, mutta toivottavasti seuraavassa iteraatiossa on mahdollisuus harjoittaa myös black boxtestausta. Löysin testeillä pari selvää bugia kirjoittamastamme koodista, ja testien muodostama turvaverkko antoi varmuutta koodin muuttelemiselle. Aina ennen CVS commit:ia pystyi testit ajamalla varmistamaan että koodi on jokseenkin toimivassa kunnossa. Testien kirjoittaminen myös pisti miettimään, kuinka irrallisiksi yksiköt pitää saada jotta yksikkötestaus on yksikkötestausta. Voiko yksikössä käyttää Javan LinkedList-luokkaa, vai pitääkö mahdollistaa sen korvaaminen mock-oliolla testaamista varten? Eli sallitaanko yksiköissä staattisina ainoastaan primitiivit int, float jne.? Ja jos LinkedListluokan käyttö hyväksytään, miksei myös itse implementoidut säiliöt, jotka on testattu erillisillä testeillä? Tähän projektiin tämä kysymys liittyy oleellisesti, sillä Napan natiivi koodi nimenomaan tarjoaa eräänlaisen säiliörajapinnan. Sen käyttäminen testauksessa helpottaisi yksikkötestien kirjoittamista, sillä kyseiseen säiliöön tulee kirjoittaa tietoa myös ohjelman normaalissa ajossa, eikä tälle säiliölle siten tarvitsisi kirjoittaa mockoliota testaamista varten. Juuri näin testaus suoritettiin tässä iteraatiossa. Toisaalta testausympäristö ei ole ainut erilainen ympäristö mihin yksikkö voidaan sijoittaa, joten yksikön modulaarisuuteen olisi hyvä tähdätä joka tapauksessa. Jos esimerkiksi Napan natiivit osat muunnettaisiin tulevaisuudessa Javalle, olisi suotavaa että nykyistä tietokantakomponenttia voisi käyttää sellaisenaan. Testauksen toteuttaminen sai
7 pohtimaan erilaisia lähestymistapoja tämän saavuttamiseksi (esim. välikieli), mutta niiden implementoimiseen ei ollut aikaa tässä iteraatiossa Implementaatio Yhteenveto 4. Lähdeluettelo 1. JUnit Test Infected: Programmers Love Writing Tests < > 2. Approaches to Mocking < > 3. Kent Beckin wiki; Mock Object < 4. Unit testing with mock objects < > 5. A Dozen Ways to Get the Testing Bug in the New Year < > 6. Design Better Software with the Inversion of Control Pattern < > 7. Burnstein, Ilene, Practical Software Testing, Springer-Verlag, 2003
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ätiedotSEPA 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ätiedotOhjelmistojen 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ätiedotYksikkö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ätiedotTestausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testausdokumentti Kivireki Helsinki 17.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Anu Kontio Ilmari
LisätiedotSEPA päiväkirja. BetaTeam. Juho Mäkinen, 57796V, Jari Leppä, 42710V, Versio Pvm Tekijä Kuvaus
SEPA päiväkirja BetaTeam Juho Mäkinen, 57796V, jvmakine@cc.hut.fi Jari Leppä, 42710V, jleppa@cc.hut.fi Versio Pvm Tekijä Kuvaus 0.1 10.11.2005 Juho Mäkinen Johdanto 1. 0.2 11.11.2005 J.Mäkinen, Käytäntöön
LisätiedotSEPA 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ätiedot58160 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ätiedotJReleaser 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ätiedotLAATURAPORTTI 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ätiedotTarjolla tänää: Ohjelmiston toteutuksesta. Kuinka tulla hyväksi ohjelmoijaksi? CRC-kortit. Testilähtöinen kehittäminen JOT2007. Uudelleenrakentaminen
Tarjolla tänää: Ohjelmiston toteutuksesta JOT2007 CRC-kortit Testilähtöinen kehittäminen Uudelleenrakentaminen Voisiko ohjelmointi olla sittenkin suunnittelua? Kuinka tulla hyväksi ohjelmoijaksi? CRC-kortit
LisätiedotTIE 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ätiedotdokumentin 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ätiedotUCOT-Sovellusprojekti. Testausraportti
UCOT-Sovellusprojekti Testausraportti Ilari Liukko Tuomo Pieniluoma Vesa Pikki Panu Suominen Versio: 0.02 Julkinen 11. lokakuuta 2006 Jyväskylän yliopisto Tietotekniikan laitos Jyväskylä Hyväksyjä Päivämäärä
LisätiedotOhjelmiston testaus ja laatu. Testaustasot
Ohjelmiston testaus ja laatu Testaustasot Testauksen vaihejako Tarpeet / sopimus Järjestelmätestaus Hyväksymiskoe Määrittely testauksen suunnittelu ja tulosten verifiointi Arkkitehtuurisuunnittelu Moduulisuunnittelu
LisätiedotTIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4. Antti Jääskeläinen Matti Vuori
TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4 Antti Jääskeläinen Matti Vuori Vaiheet 3 & 4: Järjestelmätestaus 27.10.2014 2 Päämäärä jedit-ohjelmointieditorin järjestelmätestaus
LisätiedotL models. Testisuunnitelma. Ryhmä Rajoitteiset
Teknillinen korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Testisuunnitelma Ryhmä Rajoitteiset Versio Päivämäärä Tekijä Muutokset
LisätiedotTestaussuunnitelma. 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ätiedotSEPA päiväkirja. Aihe: Staattiset menetelmät Tekijät: Mikko Halttunen 58198B, Mikko Närjänen 58122B Ryhmä: Neptune T Ohjelmistoprojekti I
SEPA päiväkirja Aihe: Staattiset menetelmät Tekijät: Mikko Halttunen 58198B, Mikko Närjänen 58122B Ryhmä: Neptune T-76.4110 Ohjelmistoprojekti I Sisällysluettelo Sisällysluettelo...2 1. Johdanto...3 2.
LisätiedotKäyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä
www.niksula.cs.hut.fi/~jjkankaa// Testauksen loppuraportti v. 1.0 Päivitetty 23.4.2001 klo 19:05 Mikko Viljainen 2 (14) Dokumentin versiohistoria Versio Päivämäärä Tekijä / muutoksen tekijä Selite 1.0
LisätiedotConvergence 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ätiedotJohdanto 1. Projektille esiteltävä versio. Kokemukset ja muutokset 3. Projektille esiteltävä versio. Iteraatio 2., suunnitelma
SEPA päiväkirja BetaTeam Juho Mäkinen, 57796V, jvmakine@cc.hut.fi Jari Leppä, 42710V, jleppa@cc.hut.fi Versio Pvm Tekijä Kuvaus 0.1 10.11.2005 Juho Mäkinen Johdanto 1. 0.2 11.11.2005 J.Mäkinen, Käytäntöön
LisätiedotTestaussuunnitelma. Ohjelmistotuotantoprojekti Nero. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma Ohjelmistotuotantoprojekti Nero Helsinki 5.11.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti ( ov) Projektiryhmä
LisätiedotTestausraportti. Oppimistavoitteiden hallintajärjestelmä harri
Testausraportti Oppimistavoitteiden hallintajärjestelmä harri Helsinki 13.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti
LisätiedotTIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4. Antti Jääskeläinen Matti Vuori
TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4 Antti Jääskeläinen Matti Vuori Vaiheet 3 & 4: Järjestelmätestaus 28.10.2013 2 Päämäärä jedit-ohjelmointieditorin järjestelmätestaus
LisätiedotAutomaattinen 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ätiedotTest-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ätiedotOhjelmistotuotantoprojekti
Ohjelmistotuotantoprojekti Ryhmä Muppett TESTAUSDOKUMENTTI Helsinki 5.8.2008 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Ohjelmistotuotantoprojekti, kesä 2008 Projekti: Muutos- ja korjauspyyntöjen
LisätiedotT Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe T1. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T1
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tästä dokumentista ilmenee T1-vaiheessa suoritettu testaus, sen tulokset ja poikkeamat testisuunnitelmasta. Päivämäärä 1.12.2002 Projektiryhmä Keimo keimo-dev@list.hut.fi
LisätiedotTestauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori
Testauksen tuki nopealle tuotekehitykselle Antti Jääskeläinen Matti Vuori Mitä on nopeus? 11.11.2014 2 Jatkuva nopeus Läpäisyaste, throughput Saadaan valmiiksi tasaiseen, nopeaan tahtiin uusia tuotteita
LisätiedotOhjelmien 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ätiedotCOTOOL dokumentaatio Testausdokumentit
Table of Contents Testausraportti.............................................................................. 1 1 Tiivistelmä...............................................................................
LisätiedotOhjelmiston testaus ja laatu. Testausmenetelmiä
Ohjelmiston testaus ja laatu Testausmenetelmiä Testausmenetelmiä - 1 Testauksen menetelmien päälähestymistapoina ovat black-box testi testaaja ei voi tutkia lähdekoodia testaus perustuu sovellukselle suunnitteluvaiheessa
LisätiedotSEPA 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ätiedotELM GROUP 04. Teemu Laakso Henrik Talarmo
ELM GROUP 04 Teemu Laakso Henrik Talarmo 23. marraskuuta 2017 Sisältö 1 Johdanto 1 2 Ominaisuuksia 2 2.1 Muuttujat ja tietorakenteet...................... 2 2.2 Funktiot................................
LisätiedotCT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015
CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015 NOPEA KERTAUS TESTAUS HYVIN LYHYESTI Miten normaali testaajan arki ohjelmistoprojektissa sitten rullaa? Käytännössä
LisätiedotCT60A4150 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ätiedotTestilä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ätiedotTyökalut ohjelmistokehityksen tukena
1 Työkalut ohjelmistokehityksen tukena Johdanto 2 Työkaluja eli ohjelmistotyötä tukevia ohjelmistoja käytetään ohjelmistoalan yrityksissä nykypäivänä paljon. Työkalut auttavat ohjelmistoalan ihmisiä suunnittelemaan
LisätiedotTestaussuunnitelma. PUSU-ryhmä. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma PUSU-ryhmä Helsinki 13.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9 op) Projektiryhmä Jussi Hynninen
LisätiedotTestaussuunnitelma 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ätiedotTest-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ätiedotHirviö 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ätiedotTIE 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ätiedotTik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti
Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu TESTIRAPORTTI LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 1.1 Tila: hyväksytty Päivämäärä: 13.2.2001 Tekijä:
LisätiedotT-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ätiedotTestaussuunnitelma. Asdf. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma Asdf Helsinki 22.2.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Kuisma Sami Louhio
Lisätiedot4.12.2005. SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T
SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T SEPA: REFAKTOROINTI 2 (9) SEPA: REFAKTOROINTI 3 (9) VERSIOHISTORIA Version Date Author Description 0.1 2.12.2005 Erik Hakala Ensimmäinen
LisätiedotMää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ätiedotOhjelmiston toteutussuunnitelma
Ohjelmiston toteutussuunnitelma Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1 1 Johdanto Tämä luku antaa yleiskuvan koko suunnitteludokumentista,
LisätiedotKuopio 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ätiedotOhjelmistotekniikan 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ätiedotKontrollipolkujen 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ätiedotHirviö 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ätiedotGood Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä
Good Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä Versiohistoria: Versio: Pvm: Laatijat: Muutokset: 0.1 2006 12 09 Jani Eränen Alustava DOKUMENTIN TILA: Alustava Valmis Tarkastettu
LisätiedotRekursiolause. Laskennan teorian opintopiiri. Sebastian Björkqvist. 23. helmikuuta Tiivistelmä
Rekursiolause Laskennan teorian opintopiiri Sebastian Björkqvist 23. helmikuuta 2014 Tiivistelmä Työssä käydään läpi itsereplikoituvien ohjelmien toimintaa sekä esitetään ja todistetaan rekursiolause,
LisätiedotOhjelmistojen virheistä
Ohjelmistojen virheistä Muutama sana ohjelmistojen virheistä mistä niitä syntyy? Matti Vuori, www.mattivuori.net 2013-09-02 1(8) Sisällysluettelo Ohjelmistojen virheitä: varautumattomuus ongelmiin 3 Ohjelmistojen
LisätiedotTestausraportti. Orava. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testausraportti Orava Helsinki 5.5.2005 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Juhani Bergström Peter
LisätiedotCOTOOL dokumentaatio SEPA: Refaktorointi
Table of Contents Refaktorointi................................................................................ 1 1 Tehtävänanto.............................................................................
LisätiedotOhjelmistotuotteen hallinnasta
Ohjelmistotuotteen hallinnasta Luennon tavoitteista Luennon sisällöstä Motivointia Lähteinä: Haikala ja Märijärvi, Ohjelmistotuotanto Royce, Software Project Management, A Unified Framework 1 Tavoitteista
LisätiedotGood Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi
Good Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi Versiohistoria: Versio: Pvm: Laatijat: Muutokset: 0.1 2006-11-25 Janne Mäkelä Alustava 1.0 2006-12-10 Janne Mäkelä Valmis 1.
LisätiedotLaadunvarmistusdokumentti
Laadunvarmistusdokumentti Dokumentin historia Versio Päiväys Muokkaaja Kuvaus Hyväksytty 1.10 07.11.2005 Rönkkö Kirsi Erotettu omaksi dokumentikseen Sisällysluettelo 1. Koko projektissa...2 1.1. Tavoitteet...2
LisätiedotMihin 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ätiedotMenetelmäraportti - Konfiguraationhallinta
Menetelmäraportti - Konfiguraationhallinta Päiväys Tekijä 22.03.02 Ville Vaittinen Sisällysluettelo 1. Johdanto... 3 1.1 Tärkeimmät lyhenteet... 3 2. Konfiguraationhallinnan tärkeimmät välineet... 4 2.1
LisätiedotTestaustyö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ätiedotT Testiraportti - integraatiotestaus
T-76.115 Testiraportti - integraatiotestaus 16. huhtikuuta 2002 Confuse 1 Tila Versio: 1.1 Tila: Päivitetty Jakelu: Julkinen Luotu: 19.03.2002 Jani Myyry Muutettu viimeksi: 16.04.2002 Jani Myyry Versiohistoria
LisätiedotLaaturaportti [iteraatio 2] Ryhmä 14
Laaturaportti [iteraatio 2] Ryhmä 14 Versio Pvm Tekijä Kuvaus 1.0 2.3.2008 Luukkonen Ensimmäinen versio Sisältö 1. Käytetyt laatumenetelmät... 1 1.1 Automaattiset yksikkötestit, tutkiva testaus ja jatkuva
LisätiedotTT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD)
TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD) Ohjelmointikäytännöt 21/3/11 Mikko Vuorinen Metropolia Ammattikorkeakoulu 1 Sisältö 1) Mitä on hyvä koodi? 2) Ohjelmointikäytäntöjen merkitys? 3) Koodin asettelu
LisätiedotLuku 8 Rakennusvaihe. Detailed Design. Programming. Moduulisuunnittelu. Ohjelmointi
Luku 8 Rakennusvaihe Moduulisuunnittelu Detailed Design Programming Ohjelmointi Teknisen Complete suunnittelun Technical viimeistely Design Suunnittelukatselmuksen Design Perform suorittaminen Review Yhteisen
LisätiedotOhjelmistotuotanto s
Laadunvarmistustekniikoita Ohjelmistotuotanto 1 testaus (testing) ohjelman suorittamista tarkoituksena löytää virheitä tarkastukset (inspections, reviews) asiantuntijoiden suorittamia dokumentin (voi olla
LisätiedotOnnistunut 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ätiedotT Projektikatselmus
T-76.115 Projektikatselmus Projektityöryhmä GenCode I3-iteraatio 17.3.2004 Agenda Tavoitteiden toteutuminen (5 min) Resurssien käyttö (5 min) Iteraation tulokset (10 min) Riskit (5min) +Kokemuksia työskentelymenetelmistä
LisätiedotToteutusvaihe T2 Edistymisraportti
Toteutusvaihe T2 Edistymisraportti Sisällysluettelo 1. Projektin tila...3 1.1. Suoritetut tehtävät...4 1.2. Käytetyt menetelmät...5 1.3. Ongelmat...6 1.4. Jatkosuunnitelmat...6 Versio- ja muutoshistoria
LisätiedotBlueJ ohjelman pitäisi löytyä Development valikon alta mikroluokkien koneista. Muissa koneissa BlueJ voi löytyä esim. omana ikonina työpöydältä
Pekka Ryhänen & Erkki Pesonen 2002 BlueJ:n käyttö Nämä ohjeet on tarkoitettu tkt-laitoksen mikroluokan koneilla tapahtuvaa käyttöä varten. Samat asiat pätevät myös muissa luokissa ja kotikäytössä, joskin
LisätiedotT SEPA - STAATTISET MENETELMÄT Tuomas Tolvanen, 55382U Timo Töyry, 58578B
T-76.5158 SEPA - STAATTISET MENETELMÄT Tuomas Tolvanen, 55382U Timo Töyry, 58578B T-76.5158 SEPA - Pariohjelmointi 2 (7) VERSION HALLINTA Versio Päivä Tekijä Kuvaus 0.1 5.12.2006 Tuomas Tolvanen Ensimmäinen
Lisätiedotohjelman arkkitehtuurista.
1 Legacy-järjestelmällä tarkoitetaan (mahdollisesti) vanhaa, olemassa olevaa ja käyttökelpoista ohjelmistoa, joka on toteutettu käyttäen vanhoja menetelmiä ja/tai ohjelmointikieliä, joiden tuntemus yrityksessä
LisätiedotIT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA LUONNOS
20.4.2015 IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA 1 1.1 SOVELTAMINEN Näitä erityisehtoja sovelletaan ohjelmistojen tai niiden osien toimituksiin ketterien
LisätiedotSEPA diary. Dokumentti: SEPA_diary_PK_RI.doc Päiväys: Projekti : AgileElephant Versio: V0.2
AgilElephant SEPA Diary Pasi Kallioniemi 49477B Rauli Ikonen 51051V Tekijä: Kallioniemi&Ikonen Omistaja: ElectricSeven Aihe: RI & PK Sivu 1 of 7 Dokumenttihistoria Muutoshistoria Revision päiväys: 1.11.2004
LisätiedotOhjelmistojen testaus ja hallinta. Gradle
Ohjelmistojen testaus ja hallinta Gradle Perinteiset koontityökalut Ant Maven 2 Maven XML-pohjaiset koontitiedostot (pom.xml) Pohjautuu käytäntöihin (vain poikkeukset käytännöistä kirjoitetaan koontitiedostoon)
LisätiedotProjektisuunnitelma Viulu
Projektisuunnitelma Viulu Kuusela Johannes Sjöblom Teemu Suominen Osma Ohjelmistotuotantoprojekti Helsinki 23.9.2004 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Versiohistoria Päivämäärä Versio
LisätiedotTDD Käytännössä Todellinen työkalu vai lehmipoikien laukkaa? Harri Kulmala Solita Oy
www.solita.fi solita@solita.fi TDD Käytännössä Todellinen työkalu vai lehmipoikien laukkaa? Harri Kulmala Solita Oy 1 TDD Käytännössä Test Driven Development yleisesti Lupaukset Esimerkki Projektin ja
LisätiedotOhjelmistotestaus -09
Ohjelmistotestaus Testaustyökalut- ja automaatio Testaustyökalut ja -automaatio Testaustyökaluilla tuetaan testaustyötä sen eri vaiheissa Oikea työkalu oikeaan tarkoitukseen Testausautomaatio perustuu
LisätiedotTapahtuipa Testaajalle...
Tapahtuipa Testaajalle... - eli testaus tosielämässä 09.10.2007 Juhani Snellman Qentinel Oy 2007 Agenda Minä ja mistä tulen Testauksen konteksti Tapauksia tosielämästä ja työkaluja 2 Minä Juhani Snellman
LisätiedotLohtu-projekti. Testaussuunnitelma
Lohtu-projekti Testaussuunnitelma Versiohistoria: 1.0 19.2.2003 1. versio Mari 1.1 20.2.2003 Muutoksia Mari 1.2 25.2.2003 Katselmoinnissa esiin tulleet Mari muutokset 1.3 17.3.2003 2. syklissä tehtävät
LisätiedotTestivetoinen ohjelmistokehitys
Testivetoinen ohjelmistokehitys Ohjelman luominen pienin askelin 1. Kirjoita testi, joka testaa ohjelmalle myöhemmin lisättävää toiminnallisuutta. 2. Suorita testi. Testin ei tule mennä läpi. Mikäli testi
LisätiedotLiite 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ätiedot4. Luokan testaus ja käyttö olion kautta 4.1
4. Luokan testaus ja käyttö olion kautta 4.1 Olion luominen luokasta Java-kielessä olio määritellään joko luokan edustajaksi tai taulukoksi. Olio on joukko keskusmuistissa olevia tietoja. Oliota käsitellään
LisätiedotLaadunvarmistustekniikat
Laadunvarmistustekniikat Ohjelmistojen laadunvarmistustekniikoita: testaus (testing) ohjelman suorittamista tarkoituksena löytää virheitä tarkastukset (inspections, reviews) asiantuntijoiden suorittamia
LisätiedotYksikkö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ätiedotT Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe LU. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T3
T-76.115 Tietojenkäsittelyopin ohjelmatyö Testiraportti, vaihe LU Sisältö Tästä dokumentista ilmenee LU-vaiheessa suoritettu testaus, sen tulokset ja poikkeamat testisuunnitelmasta. Päivämäärä 14.4.2003
LisätiedotHarjoituksen aiheena on tietokantapalvelimen asentaminen ja testaaminen. Asennetaan MySQL-tietokanta. Hieman linkkejä:
Linux-harjoitus 6 Harjoituksen aiheena on tietokantapalvelimen asentaminen ja testaaminen. Asennetaan MySQL-tietokanta. Hieman linkkejä: http://www.mysql.com/, MySQL-tietokantaohjelman kotisivu. http://www.mysql.com/doc/en/index.html,
LisätiedotOhjelmistojen mallintaminen, mallintaminen ja UML
582104 Ohjelmistojen mallintaminen, mallintaminen ja UML 1 Mallintaminen ja UML Ohjelmistojen mallintamisesta ja kuvaamisesta Oliomallinnus ja UML Käyttötapauskaaviot Luokkakaaviot Sekvenssikaaviot 2 Yleisesti
LisätiedotTestaaminen ohjelmiston kehitysprosessin aikana
Testaaminen ohjelmiston kehitysprosessin aikana 04.02.2004 http://cs.joensuu.fi/tsoft/ Sisällys 1. Johdanto 2. Yksikkö- ja integrointitestaus 3. Järjestelmätestaus 4. Hyväksymistestaus http://cs.joensuu.fi/tsoft/
LisätiedotVERSIONHALLINTA. PARIOHJELMOINTI Lari Ahti, 62634M Antti Kauppinen, 58390D
VERSIONHALLINTA PARIOHJELMOINTI Lari Ahti, 62634M Antti Kauppinen, 58390D Versio Päivä Tekijä Kuvaus 0.1 26.10.2005 Kaarlo Lahtela Ensimmäinen versio 0.2 10.12.2006 Lauri Kiiski Suomennettu 3 (8 ) SISÄLLYS
LisätiedotTestiautomaatio 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ätiedotVersio 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ätiedotSoveltuvuustutkimus Lifebelt-ohjelman ideologian käytettävyydestä olioorientoituneeseen
Soveltuvuustutkimus Lifebelt-ohjelman ideologian käytettävyydestä olioorientoituneeseen ohjelmointiin Jukka Talvitie Valvoja: Professori Jorma Jormakka Paikka: TietoEnator oyj Ongelma Ideologia Lifebelt
LisätiedotYlläpitodokumentti. Boa Open Access. Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Ylläpitodokumentti Boa Open Access Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Ilmari
LisätiedotTurvakriittisen projektin menetelmät ja työkalut
Turvakriittisen projektin menetelmät ja työkalut 1. Vaatimushallinta Vaatimushallintaan kohdistuu turvaluokitelluissa projekteissa paljon odotuksia. Etenkin jäljitettävyys vaatimuksiin, testaukseen ja
Lisätiedot