3. Testaus osana ohjelmistoprosessia
|
|
- Kaarlo Auvinen
- 7 vuotta sitten
- Katselukertoja:
Transkriptio
1 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 liittyen käydään läpi neljä tärkeää työvaihetta: yksikkö-, integrointi-, järjestelmä- ja hyväksymistestaus. Kuten perinteisessä ohjelmistotuotannossa yleensä, suurin osa testaukseen liittyvästä työstä on usein sen dokumentointia, mitä pitäisi tehdä ja mitä on tullut tehdyksi. Mika Katara: Ohjelmistojen testaus, Kuten edellä on jo todettu, testaus on oleellinen osa ohjelmistojen tuottamista Testausta ei yleensä voi eikä kannata eristää muusta ohjelmistoprosessista Nyrkkisäännön mukaan 20% koodista sisältää 80% virheistä, eli testauksen suunnitteluun ja resurssien kohdentamiseen kannattaa satsata Virheiden kasautuminen ei ole satunnaista, vaan yleensä ne piileskelevät uudessa ja muuttuneessa koodissa sekä kaikista monimutkaisemmissa komponenteissa Jokainen itseään kunnioittava ohjelmistotuotantoprosessi ottaa kantaa siihen, missä vaiheessa ja mitä testataan Mika Katara: Ohjelmistojen testaus,
2 Koska jopa yli puolet ohjelmistoprojektin resursseista voi kulua testaukseen, virheiden paikallistamiseen ja korjaukseen, voidaan prosessia parantamalla saavuttaa suuria säästöjä Kuten myös parantamalla testauksessa käytettäviä menetelmiä, työkaluja yms. Motto: mitä aikaisemmin virheet korjataan, sen parempi Testata kannattaa heti, kun on jotain testattavaa, esim. kirjoittamalla hyväksymistestaussuunnitelma heti, kun vaatimukset on valmiina Näin vaatimusmäärittelydokumentti tulee testattua Yksityiskohdat kannattaa kiinnittää vasta sitten, kun ne tiedetään riittävän varmasti, näin vältytään turhalta työltä Mika Katara: Ohjelmistojen testaus, Testaamalla aikaisin saadaan myös parempi käsitys siitä, mihin suuntaan projekti on menossa Ensiarvoisen tärkeää tietoa projektin johdolle Toisaalta, jos testitapaukset suunnitellaan aikaisin, kasvaa sen riski, että ne joudutaan suunnittelemaan vielä uudestaan ennen kuin niitä päästään ajamaan Jos maali liikkuu, joudutaan tähtäämään uudestaan Vielä parempi olisi tietenkin jättää virheet tekemättä Parannetaan ohjelmistoprosessia vähentämään virheitä Kaikkein tunnetuin testausprosessi liittyy ns. testauksen V- malliin Mika Katara: Ohjelmistojen testaus,
3 3.1 Testauksen V-malli Toiminnallinen määrittely Vaatimusmäärittely Hyväksymistestaus Järjestelmätestaus Arkkitehtuurisuunnittelu Integrointitestaus Moduulisuunnittelu Yksikkötestaus Toteutus testauksen suunnittelu tulosten verifiointi Mika Katara: Ohjelmistojen testaus, Perinteiseen, vesiputousmallia noudattavaan ohjelmistoprosessiin testaus liitetään V-mallin mukaisesti V-mallin vasen sivu kuvaa vesiputousmallia, jossa edetään ylhäältä alas ensin vaatimusmäärittelystä toiminnalliseen määrittelyyn ja siitä arkkitehtuurisuunnitteluun ja lopulta moduulisuunnitteluun ja toteutukseen Jokaisessa vaiheessa laaditaan testaussuunnitelmat vastaaville testausvaiheille (oikea sivu) Kun testattavissa olevaa toteutusta alkaa olla olemassa, aletaan sitä testata Edetään V-mallin oikeaa sivua alhaalta ylös toimien em. testaussuunnitelmien mukaan Testaus verifioi kullakin tasolla, vastaako toteutus määrittelyä/suunnittelua Mika Katara: Ohjelmistojen testaus,
4 Käytettävät tekniikat vaihtelevat riippuen siitä, missä vaiheessa ollaan menossa Esim. testaus on alemmilla tasoilla yleensä enemmän lasi- kuin mustalaatikkotyyppistä ja ylemmillä tasoilla taas toisin päin Jäljitettävyys eri vaiheiden välillä helpottaa virheiden alkuperän selvittämistä Kun virhe on paikallistettu, voidaan testausprosessia yrittää parantaa siten, että ko. tyypin virheet havaitaan aikaisemmin Mika Katara: Ohjelmistojen testaus, V-malli on monesti turhan jäykkä nykyaikaiseen ohjelmistotuotantoon Idea on kuitenkin helppo sisäistää Voidaan myös olettaa, että kaikki testaajat tuntevat V-mallin Lisäksi uudemmat prosessimallit voidaan usein tajuta helposti vertaamalla niitä V-malliin Mika Katara: Ohjelmistojen testaus,
5 Testauksen tasot vs. vaiheet Esimerkkinä sulautettujen järjestelmien kehitykseen soveltuva Multiple V malli [Broekman&Notenboom 02]: jt jt it jt it yt it yt Testauksen yt tasot Simulaatiomalli Prototyyppi Esituotanto Testauksen vaiheet Mika Katara: Ohjelmistojen testaus, Verifiointi ja validointi V-mallin avulla [Pezzè&Young 07] Actual Needs and Constraints Review User Acceptance (alpha, beta test) Delivered Package Validation Verification System Specification Subsystem Design/Specs Analysis/ Review Analysis/ Review System Test Integration Test Subsystem System Integration Unit/ Component Specs Module Test Units/ Components User review of external behavior as it is determined or becomes visible Mika Katara: Ohjelmistojen testaus,
6 3.2 Yksikkötestaus Unit testing, module testing Testataan jokainen ohjelman yksikkö erikseen Yksikkö voi olla moduuli, luokka, prosessi tms. Yksikkötestaus on yleensä osa yksikön toteutusvaihetta Yksikön koodaaja tarkistaa oman toteutuksensa yleensä tieto virheistä jää vain toteuttajalle koska virheillä on tapana kasautua, voitaisiin tämän tiedon avulla kohdistaa testausta paremmin toisaalta ohjelmoijat voivat osoittaa testaajille järjestelmän vaikeat kohdat muutenkin Mitä pikemmin yksikön toteutus testataan, sen parempi Mika Katara: Ohjelmistojen testaus, Yksikkötestaus on yleensä lasilaatikko-testausta, mutta myös jotkin mustalaatikko-testauksen tekniikoista ovat käyttökelpoisia Yksikkötestauksen osa-alueet: Rajapinnat Yksikön käyttämät tietorakenteet Suorituspolut ja silmukat Virhetilanteiden käsittely Raja-arvot Mika Katara: Ohjelmistojen testaus,
7 Rajapintojen testaaminen Rajapinta koostuu yleensä funktioista, joiden parametreja ja paluuarvoja käytetään tiedonvälitykseen Rajapintojen toimivuus on yleensä syytä testata ensimmäiseksi Jos rajapinnat eivät toimi, voi muiden testien suorittaminen olla hankalaa ellei jopa mahdotonta Näihin liittyviä ongelmia: Parametrien määrä ja järjestys Parametrien ja paluuarvojen tyypit Muutetaanko sellaisen parametrin arvoa, jonka arvoa ei saisi muuttaa? Onko globaali data määritelty yhtenevästi kaikkialla ohjelmassa? Mika Katara: Ohjelmistojen testaus, Käytettävästä ohjelmointikielestä riippuen hyvä kääntäjä huomaa suurimman osan em. virheistä Valitettavasti nykyään niin suositut dynaamiset skriptikielet ovat tässä suhteessa huonossa asemassa Kääntäjä ei sen sijaan yleensä pysty huomaamaan sitä, tulkitseeko sekä kutsuja että kutsuttava parametrin/paluuarvon samalla tavalla Esim. toinen luulee arvon tarkoittavan senttejä ja toinen tuumia (tämän kaltaisen virheen takia NASA on menettänyt yhden avaruusluotaimen) NASA lost a $125 million Mars orbiter because a Lockheed Martin engineering team used English units of measurement while the agency's team used the more conventional metric system for a key spacecraft operation, according to a review finding released Thursday. Metric mishap caused loss of NASA orbiter, CNN, September 30, 1999 Mika Katara: Ohjelmistojen testaus,
8 Tietorakenteiden testaaminen Yksikön toteuttamat (lokaalit) tietorakenteet ovat virheherkkiä Myös yksikön käyttämien, jossain muualla toteutettujen tietorakenteiden vaikutukset, tulisi testata yksikön testauksen yhteydessä Tyyppivirheet Oletusarvojen alustukset Muuttujien nimien oikeinkirjoitus Tietotyyppejä käytetään yhtenevästi Yli- ja alivuodot, poikkeukset Hyvä kääntäjä huomaa jälleen ainakin osan näistä virheistä Tietorakenteisiin kannattaa kiinnittää huomiota myös koodin tarkastuksissa Mika Katara: Ohjelmistojen testaus, Aina kun on mahdollista, kannattaa käyttää valmiita, hyvin testattuja tietorakenteita Esim. C++:n Standard Template Library (STL) Mika Katara: Ohjelmistojen testaus,
9 Suorituspolku- ja silmukkatestaus Koodin haarautumiskohdat ovat virheherkkiä Ehtolauseet, silmukat, hypyt Testitapauksia kannattaa valita sen mukaan, että mahdollisimman monta kriittistä suorituspolkua yksikön läpi tulee testattua Testattavien suorituspolkujen joukkoon kannattaa valita erityisesti niitä, joissa voisi todennäköisesti syntyä virhetilanne (esim. syötteen arvosta riippuen) Silmukoita testattaessa kannattaa erottaa toisistaan yksinkertaiset, sisäkkäiset ja peräkkäiset silmukat Myöhemmin tutustutaan tekniikoihin, joilla yksinkertaisia silmukoita voidaan testata Esim. testitapaukset keskittyvät silmukkamuuttujan raja-arvoihin Mika Katara: Ohjelmistojen testaus, Nämä tekniikat yleistyvät myös sisäkkäisiin silmukoihin Ongelma on tarvittavien testitapausten määrän nopea kasvu sisäkkäisyyden kasvaessa Sisäkkäisten silmukoiden testaukseen on kehitetty strategioita, joilla pyritään pitämään testitapausten määrä kohtuullisena esim. testataan sisäkkäisin silmukka ensin täydellisesti pitäen ulompien silmukoiden silmukkamuuttujat minimiarvoissaan, sitten toiseksi sisäkkäisin jne. Peräkkäiset silmukat voivat olla joko riippumattomia tai riippuvaisia toisistaan Riippuvuus syntyy esim. tilanteesta, jossa jälkimmäisen silmukkamuuttujan arvo alustetaan käyttäen ensimmäisen silmukkamuuttujan arvoa Mika Katara: Ohjelmistojen testaus,
10 Toisistaan riippuvien silmukoiden testaamiseen voidaan käyttää soveltaen sisäkkäisten silmukoiden testaukseen kehitettyjä heuristiikkoja Riippumattomien silmukoiden testaus palautuu yksinkertaisten silmukoiden testaamiseen Mika Katara: Ohjelmistojen testaus, Virhetilanteiden testaaminen Virhetilanteiden käsittely jää usein vähälle huomiolle ohjelman suunnittelussa Valitettavasti myös virhetilanteiden testaaminen on silloin yleensä lapsipuolen asemassa Vaikka ohjelma muuten olisikin suunniteltu testausystävälliseksi, virheidenkäsittely ei välttämättä ole sitä Tämän seurauksena ohjelman antamat virheilmoitukset voivat olla käyttäjän kannalta täysin hyödyttömiä tai jopa harhaanjohtavia Mitä myöhemmin virhe löytyy, sen enemmän sen korjaaminen maksaa tämä periaate pätee erityisen hyvin virhetilanteiden tapauksessa Huonosti tehty virheenkäsittely voi vaarantaa myös tietoturvan (tähän palataan myöhemmin) Mika Katara: Ohjelmistojen testaus,
11 Virhetilanteiden testauksen muistilista: Onko virheilmoitus ymmärrettävä? Vastaako virheilmoitus tapahtunutta virhettä? Auttaako virheilmoitus käyttäjää paikallistamaan virheen syyn ja pääsemään eteenpäin? Ovatko virheilmoitukset yhtenevät kaikissa yksiköissä? Onko virheenkäsittely tehty siten, että käsittelyyn ylipäänsä päästään vai kaatuuko ohjelma jo ennen sitä? Onko virheenkäsittely ylipäänsä tehty oikein? Onko virheestä toipuminen mahdollista? jos ei, kaadetaanko ohjelma käyttäjäystävällisesti? Mika Katara: Ohjelmistojen testaus, Raja-arvojen testaaminen Viimeinen vaihe yksikkötestauksessa Muistilista: Parametrien ja paluuarvojen raja-arvot Silmukoiden pyörimiskertojen raja-arvot Tietorakenteisiin liittyvät raja-arvot esim. kasvaako ja pieneneekö dynaaminen tietorakenne oikein silloin kun muistia todella varataan tai vapautetaan Mika Katara: Ohjelmistojen testaus,
12 Yksikkötestauksen toteuttaminen Design by Contract: metodien esi- ja jälkiehdot Jos kutsuja täyttää metodin esiehdon, kutsuttava täyttää sen jälkiehdon Koodin miinoittaminen assertioilla järkevästi Jos suorituksen halutaan jatkuvan virhetilanteen jälkeen, if-lause on parempi vaihtoehto Testikehyksen määrittelemät älykkäät assertiot double square_root(long x) { assert(x >= 0); // esiehto double result = sqrt(x); assert((result * result) == x); // jälkiehto, toimiiko tämä aina? return result; } Mika Katara: Ohjelmistojen testaus, Koska yksiköt eivät yleensä voi toimia itsenäisesti, vaatii niiden testaaminen apukoodin kirjoittamista, jota käytetään vain testauksessa Testikoodi on koodia siinä missä testattavakin koodi Se on tehtävä ja dokumentoitava vähintään yhtä huolellisesti Myös testikoodia on testattava ja ylläpidettävä Englanninkielinen termi scaffolding eli rakennusteline kuvaa hyvin testikoodin suhdetta testattavaan koodiin Mika Katara: Ohjelmistojen testaus,
13 Tärkeitä yksikkötestauksen toteuttamiseen liittyviä käsitteitä ovat ajuri ja tynkä (testikehyksen ohella) Ajuri (driver, test bed) on ohjelma, joka ottaa syötteenään testitapaukseen liittyvää dataa ja syöttää datan testattavalle yksikölle Ajuri myös huolehtii yksikön tuottamien tulosten keräämisestä ja niiden välittämisestä edelleen analysoitavaksi Ajuri kannattaa suunnitella siten, että sitä voidaan käyttää usean eri yksikön testaamiseen Ajuri kannattaa suunnitella rinnan testattavan yksikön kanssa Ongelmat ajurin suunnittelussa voivat paljastaa virheitä testattavan yksikön suunnittelussa Mika Katara: Ohjelmistojen testaus, Tynkä (stub) korvaa testattavan yksikön kutsuman toisen yksikön Jokaista kutsuttavaa yksikköä varten tarvitaan oma tynkänsä Tyngän tehtävät: Toteuttaa tarvittavat rajapinnat Tulostaa tiedon lokiin siitä, että sitä on kutsuttu Palauttaa kontrollin testattavaan yksikköön Käsittelee mahdollisimman vähän saamiaan syötteitä Mika Katara: Ohjelmistojen testaus,
14 Tynkä tulisi suunnitella siten, että se olisi mahdollisimman helppo toteuttaa Tynkien merkitys korostuu erityisesti virhetilanteita testattaessa Virhetilanteiden generoiminen on työlästä Niiden systemaattinen etsiminen on erittäin vaikeaa Tarkoitusta varten suunnitellun tyngän avulla haluttu virhetilanne saadaan aikaan helposti Mika Katara: Ohjelmistojen testaus, xunit-testauskehykset Junit: Erich Gamman ja Kent Beckin kehittämä testikehys Java-ohjelmien yksikkötestaukseen Avointa lähdekoodia Valmiita toimintoja testitapausten ajamiseen ja niiden tuloksista raportointiin Määrämuotoiset testitapaukset helpottavat testien ylläpitoa Lähtökohta: jos jotakin ohjelman ominaisuutta varten ei ole automatisoituja testejä, oletettavasti ko. ominaisuus ei toimi Useita suunnittelumalleja (design patterns) hyödyntämällä tehty testikehys, jossa testejä kuvataan olioilla Testitapausten strukturointi ja työkalut niiden ajamiseen Mika Katara: Ohjelmistojen testaus,
15 Käyttää reflektiota tms., mikä tuo joustavuutta kehyksen käyttöön Abstrakti kantaluokka TestCase, joka määrittelee mm. testitapauksen nimen ja run-metodin: public void run() { setup(); // alustaa testitapauksen luomalla ns. fixtuurin runtest(); // ajaa testitapauksen ja tarkastaa tulokset teardown(); // purkaa fixtuurin } Fixture eli vakiokalusto, useille eri testitapauksille yhteiset järjestelmän alustukset Testijoukkoja mallintava TestSuite-luokka tallettaa joukon TestCase- ja TestSuite-luokan olioita Mika Katara: Ohjelmistojen testaus, JUnitin arkkitehtuuri: «interface» Test run(testresult) TestResult name TestCase run(testresult) runtest() setup() teardown() TestSuite run(testresult) addtest(test) Mika Katara: Ohjelmistojen testaus,
16 Voidaan käyttää myös integrointitestauksen apuna Käytännössä auttaa lähinnä ajurien rakentamisessa, ei niinkään tynkien Useita laajennuksia: J2EE, testikattavuuden mittaus jne. xunit perheeseen kuuluu useita hieman erilaisia kehyksiä eri ohjelmointikielille jne. Lisätietoja: junit.org Mika Katara: Ohjelmistojen testaus, Integrointitestaus Yksikkötestauksen jälkeen yksiköt integroidaan isommiksi kokonaisuuksiksi Integrointitestauksessa testataan yksiköiden rajapintoja ja niiden yhteistoimintaa Kannattaa hyödyntää mahdollisuuksien mukaan testiautomaatiota kuten automatisoituja savutestejä (esitellään myöhemmin) Mika Katara: Ohjelmistojen testaus,
17 Integrointitestaus voidaan ajatellaan implisiittiseksi osaksi yksikkötestausta, varsinkin, jos ohjelmisto on kooltaan pienehkö, ja yksiköt integroidaan inkrementaalisesti Lisätään yksi yksikkö kerrallaan testattavaan kokonaisuuteen Yleensä kehittäjät vastaavat tällöin yksikkötestauksen lisäksi suurelta osin myös integrointitestauksesta Integrointitestit suoritetaan yksikkötestien tapaan yleensä kehitysympäristössä Nykyään hyvin suorittu jatkuva integrointi pitää sisällään myös keskitetyn integroinnin, joka tapahtuu palvelimella, mutta tämän voidaan katsoa kuuluvan kehitysympäristöön Mika Katara: Ohjelmistojen testaus, Hyvässä ohjelmistoarkkitehtuurissa jokainen yksikkö hoitaa oman rajatun tehtävänsä mahdollisimman itsenäisesti Ylimääräiset riippuvuudet yksiköiden välillä hankaloittavat ylläpitoa yms. Mahdollisia riippuvuuksia yksiköiden välillä: Yksikkö välittää dataa toiselle parametrien välityksellä parametrin tyyppi saattaa olla tietorakenne, josta kutsuttava yksikkö hyödyntää vain pientä osaa kontrolliparametri voi välittää tiedon siitä, mikä mahdollisista suorituspoluista on valittava Yksiköt eivät tiedä toisistaan, mutta kolmas yksikkö käyttää niitä molempia esim. toinen yksikkö kirjoittaa tiedostoon ja toinen lukee sieltä Mika Katara: Ohjelmistojen testaus,
18 Yksiköt käyttävät yhteisiä globaaleja muuttujia tiedonkätkentä ei aina käytännössä toteudu Spagettikoodissa yksiköt voivat päästä kurkkimaan rajapintojen ohi tai kontrolli voi muuttua yksiköstä toiseen kesken kaiken nykyaikainen versio: C++:n friend-mekanismi ystävät kannattaa valita huolella Mika Katara: Ohjelmistojen testaus, Kertarysäysintegrointi Big bang: Alussa ei ollut mitään ja sitten kaikki räjähti Idea: Ensin yksikkötestataan kaikki yksiköt erikseen ja sitten integroidaan ne kerralla toimivaksi kokonaisuudeksi Yleistä pienissä ohjelmissa Ongelma 1: yksikkötestausvaiheessa on kaikille yksiköille kirjoitettava tarvittavat ajurit ja tyngät Ongelma 2: kun vika ilmenee integroitua järjestelmää testattaessa, on sen aiheuttaneen virheen etsiminen hankalaa isosta joukosta yksiköitä Ongelma 3: virheen korjaamisen jälkeen täytyy monia testejä ajaa uudelleen, sen varmistamiseksi, ettei korjaus ole rikkonut mitään muuta Mika Katara: Ohjelmistojen testaus,
19 integrointitestattava kokonaisuus yksikkötestattu yksikkö riippuvuus Mika Katara: Ohjelmistojen testaus, Inkrementaalinen integrointi Aloitetaan testaaminen yhdestä yksiköstä Lisätään toinen yksikkö, sitten kolmas jne. Etu 1: säästytään ajurin/tyngän tekemiseltä, jos sen sijasta voidaan käyttää yksikkötestattua yksikköä Etu 2: vika helpompi löytää pienestä määrästä yksiköitä Etu 3: virheen korjaamisen jälkeen ei kaikkia siihen asti ajettuja testejä välttämättä tarvitse ajaa uudestaan Mika Katara: Ohjelmistojen testaus,
20 Jäsentävä inkrementaalinen integrointi Top-down Idea: yksikkötestataan ensin ylimmän tason kontrolliyksikkö, joka sitten integroidaan niiden yksiköiden kanssa, joita se kutsuu Kutsuttavat yksiköt testataan seuraavaksi niiden kutsumat yksiköt korvataan jälleen tyngillä ylimmän tason yksikkö poistaa ajureiden tarpeen Kun integrointi on saatu testattua, korvataan jälleen tyngät niitä vastaavilla yksiköillä, jne. Näin edetään, kunnes kaikki yksiköt on integroitu yhdeksi kokonaisuudeksi Mika Katara: Ohjelmistojen testaus, testattava yksikkö integrointitestattava kokonaisuus testattu yksikkö riippuvuus tynkä Mika Katara: Ohjelmistojen testaus,
21 Etuna se, että käytettävissä on koko ajan ajettava ohjelma Haittana tarvittavat tyngät, joiden toteuttaminen voi olla työlästä Mika Katara: Ohjelmistojen testaus, Kokoava inkrementaalinen integrointi Bottom-up Toinen inkrementaalinen lähestymistapa Edetään päinvastoin kuin jäsentävässä integroinnissa Aloitetaan yksikkötestaus alimman tason yksiköistä, joille kirjoitetaan tarvittavat ajurit Seuraavassa vaiheessa korvataan nämä ajurit vastaavilla yksiköillä Testataan seuraavaksi nämä yksiköt Kirjoitetaan jälleen tarvittavat ajurit Alimman tason yksiköt poistavat tynkien tarpeen Mika Katara: Ohjelmistojen testaus,
22 Näin syntyy vähitellen klustereita, joista periaatteessa jokainen huolehtii jostain hyvin määritellystä toiminnallisesta kokonaisuudesta Kun kaikki klustereiden yksiköt on testattu, ajurit korvataan jälleen seuraavan tason yksiköillä Tuloksena syntyy hieman isompia klustereita Tätä jatketaan, kunnes kaikki klusterit on integroitu yhdeksi kokonaiseksi ohjelmaksi Mika Katara: Ohjelmistojen testaus, testattava yksikkö integrointitestattava kokonaisuus testattu yksikkö riippuvuus ajuri Mika Katara: Ohjelmistojen testaus,
23 Kokoava lähestymistapa korostaa toiminnallisuuden testausta ohjelman logiikan testauksen kustannuksella Ohjelman logiikassa olevat virheet voivat paljastua vasta integrointitestauksen viime metreillä Toisin kuin jäsentävässä integroinnissa, järjestelmän prototyyppi ei ole käytettävissä ennen kuin vasta aivan integrointitestauksen lopussa Mika Katara: Ohjelmistojen testaus, Ehdottomasti paras puoli kokoavassa lähestymistavassa on se, että tynkiä ei tarvita laisinkaan Tynkien tekeminen on yleensä työläämpää kuin ajurien Lisää etuja: Kokoavassa integroinnissa voidaan klustereiden testausta jakaa helposti useammalle tiimille Matalan tason yksiköiden suunnittelussa ja toteutuksessa tehdyt virheet voidaan löytää nopeasti esim. niissä piilevät suorituskykyongelmat voidaan havaita tehokkaasti Mika Katara: Ohjelmistojen testaus,
24 Muita tapoja integrointitestata Edellä oletettiin, että inkrementaalinen integrointitestaus on implisiittinen osa yksikkötestausta, ja että samoja tynkiä ja ajureita voidaan hyödyntää molemmissa vaiheissa Vaiheita ei välttämättä kannata erottaa toisistaan Käyttäen inkrementaalista integrointistrategiaa voidaan välttyä (lähes) kokonaan joko tynkien tai ajureiden kirjoittamiselta Integrointitestauksessa tarvittavat tyngät ja ajurit voivat kuitenkin erota merkittävästi yksikkötestauksessa tarvituista Esim. virhekäsittelyn testaus ilman tätä tarkoitusta varten suunniteltuja tynkiä voi osoittautua hankalaksi Mika Katara: Ohjelmistojen testaus, Jossain tilanteissa vaiheet saattaa kannattaa erottaa toisistaan, eli yksikkötestauksen voi ajatella integrointitestauksesta riippumattomaksi vaiheeksi yksikkötestauksessa kaikille yksiköille kirjoitetaan tarvittavat tyngät ja ajurit integrointitestauksessa ajurit ja tyngät kirjoitetaan tarpeen mukaan erikseen Testaajat eivät välttämättä pääse vaikuttamaan siihen, missä järjestyksessä integrointia testataan Testausjärjestys voi riippua siitä, missä järjestyksessä yksiköitä integroidaan toisiinsa Tämä on luonnollista eritoten silloin, kun integrointia testaavat kehittäjät Mika Katara: Ohjelmistojen testaus,
25 Joskus kannattaa integroida ensin ne yksiköt, joihin liittyy suurin riski tai jotka muuten vaan sattuvat olemaan kriittisellä polulla Mitä suurempi riski, sen aikaisemmassa vaiheessa pitää testata Kriittinen polku saattaa liittyä esim. ominaisuuteen, joka halutaan saada toimimaan mahdollisimman nopeasti tai tekniikkaan, jonka käyttökelpoisuus halutaan selvittää mahdollisimman nopeasti Jatkuvan integroinnin prosessi esitellään myöhemmin Mika Katara: Ohjelmistojen testaus, Integrointitestauksen nyrkkisääntöjä Tarvittavan apukoodin määrä tulisi minimoida Kerralla kannattaa integroida vain pieni määrä yksiköitä Vain yksi kerrallaan, jos kyseessä on kriittinen tai virheherkkä yksikkö Toisaalta yksinkertaisia, toisistaan riippuvia yksiköitä ei välttämättä kannata testata erillisinä yksiköinä vältytään turhien ajurien/tynkien kirjoittamiselta Mika Katara: Ohjelmistojen testaus,
26 Järjestelmäintegrointitestaus Isojen tietojärjestelmäprojektien yhteydessä suureksi kysymykseksi nousee yleensä yhteensopivuus muiden järjestelmien kanssa Koska kokonaisjärjestelmän osat tulevat yleensä eri toimittajilta, on syytä kiinnittää erityistä huomiota siihen, että osajärjestelmät juttelevat toistensa kanssa saumattomasti Järjestelmäintegrointitestaus on luonteeltaan teknistä, toiminnallisuus ja suorituskyky jne. varmistetaan vasta kun homma toimii pellin alla Kannattaa aloittaa mahdollisimman aikaisin, myöhäinen aloitus johtaa ongelmiin projektin lopussa Ajureita ja tynkiä joudutaan käyttämään korvattaessa keskeneräisiä ja puuttuvia osajärjestelmiä Mika Katara: Ohjelmistojen testaus, Järjestelmätestaus Testataan kokonaisjärjestelmän toimintaa Voi olla erillisen testaustiimin tehtävä Löydettyjen virheiden korjaus kallista Ajallisesti yleensä pitkäkestoisin kaikista testausvaiheista Kaikkien testitapausten ajaminen voi kuluttaa hyvinkin paljon resursseja Luontevaa aloittaa jälleen savutestillä Jos järjestelmätestaus aloitetaan vasta projektin lopussa, ajaudutaan helposti ongelmiin Ketterässä prosessissa pyritään testaamaan koko ajan myös järjestelmätasolla Mika Katara: Ohjelmistojen testaus,
27 Järjestelmätestausvaiheessa käytettävissä on koko järjestelmä, mikä tekee mielekkääksi mm. seuraavien asioiden testaamisen: Asiakkaan vaatimukset Suunnittelun ominaispiirteet Järjestelmän tilat Kapasiteetti Rinnakkaisuus Ohjelmiston ja laitteiston konfiguraatiot Rajapinnat ja toiminta muiden järjestelmien kanssa (vrt. järjestelmäintegrointitestaus) Installointi Lokalisointi Mika Katara: Ohjelmistojen testaus, Suorituskyky Toipuminen virhetilanteista Luotettavuus Resurssien käyttö Skaalautuvuus Järjestelmätestaus vaatii huomattavasti enemmän luovuutta kuin alemman tason testaus Yleispäteviä toimintamalleja mahdotonta määritellä tarkasti Mika Katara: Ohjelmistojen testaus,
28 Järjestelmätestauksen vaiheet (mukailtu Kit: Software Testing in the Real World, 1995): Vaatimusten analysointi ja paloittelu hallittaviin osiin Jokaiselle osalle yksityiskohtaisten vaatimusten listaus Jokaista merkityksellistä vaatimusta vastaavien syötteiden ja tulosten määrittely Vaatimuskattavuusmatriisin määrittely Testitapausten ajaminen ja vaatimuskattavuuden mittaaminen Uusien testitapausten määrittely ja ajaminen tavoitellun vaatimuskattavuuden saavuttamiseksi Mika Katara: Ohjelmistojen testaus, to be determined, ei vielä ajettu Vaatimuskattavuusmatriisi Taulukko, jossa kerrotaan yhteydet (eri tyyppisten) testitapausten ja vaatimusten välillä Mikäli mahdollista, yhdellä (laillisella) testitapauksella kannattaa testata montaa vaatimusta Matriisista näkee helposti sen, mitä ei (vielä) testata vaatimus testitapaus TT1 V1 V2 V3 V4 TBD TT2 OK OK TT3 FAIL TT4 OK OK Mika Katara: Ohjelmistojen testaus,
29 Järjestelmätestausvaiheessa pitäisi huolehtia siitä, että kehittäjät saavat vikaraportit nopeasti Ei niin itsestään selvää kuin alemmissa vaiheissa mahdolliset organisaatiorajat hidastavat Projektin johdon kautta kierrättäminen ei välttämättä ole hyvä idea Nopea raportointi voi estää virheen leviämisen muihin paikkoihin Mika Katara: Ohjelmistojen testaus, Muutosten hallinnasta Koska järjestelmätestien suorittajat eivät yleensä itse korjaa löydettyjä virheitä, on erittäin tärkeää huolehtia muutosten hallinnasta Mikäli jokainen virhe korjataan heti siten, että testattava versio vaihtuu jatkuvasti, ei järjestelmätestaus pääse etenemään Toisaalta joidenkin virheiden pikainen korjaaminen voi olla ensisijaista toisten virheiden nopealle löytymiselle Yleensä virheiden korjaamisen priorisoinnista ja aikatauluista päättää erillinen taho (Change/Configuration Control Board) Tähän voi kuulua testaajien ja kehittäjien lisäksi myös tuotteenhallintapäällikkö, projektipäällikkö, laatupäällikkö, tietokantojen ylläpitäjä, asiakkaita/loppukäyttäjiä, asiakastukihenkilöitä ja markkinointi-ihmisiä Mika Katara: Ohjelmistojen testaus,
30 Pahimmassa tapauksessa kehittäjät määräävät mitä versiota testataan ja testaajat keskittyvät vain muutosten hallintaan testiympäristössä Esim. testiautomaatio voi tarvita säätöä aina testiympäristön muuttuessa Esim. virheidenkorjausstrategiasta [Craig&Jaskiel 02]: Järjestelmätestauksen ensimmäisen kahden viikon aikana kaikki muutosehdotukset toteutetaan ja raportoidut virheet korjataan päivittäisissä buildeissä, jotka alkavat klo Mika Katara: Ohjelmistojen testaus, Seuraavan kahden viikon aikana testaus- ja kehitystiimien johtajat, käyttäjien edustaja ja tuotteenhallinnasta vastaava henkilö tapaavat klo joka tiistai ja torstai priorisoimaan kaikki muutosehdotukset ja raportoitujen virheiden korjaukset samalla päätetään siitä, mitkä muutoksista päivitetään testiympäristöön Viimeisen kahden viikon aikana ainoastaan fataalien virheiden korjaukset päivitetään testiympäristöön Mika Katara: Ohjelmistojen testaus,
Ohjelmistojen testaus
Ohjelmistojen testaus Mika Katara, Matti Vuori ja Antti Jääskeläinen Tampereen teknillinen yliopisto, Tietotekniikan laitos 25.8.2014 Ohjelmistojen testaus, 2014 1(507) Mitä testaus on? Erilaisia näkökulmia
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ätiedotOhjelmiston 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ä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ä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ätiedotOhjelmistotuotantoprojekti
Ohjelmistotuotantoprojekti Ryhmä Muppett TESTAUSDOKUMENTTI Helsinki 5.8.2008 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Ohjelmistotuotantoprojekti, kesä 2008 Projekti: Muutos- ja korjauspyyntöjen
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ä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ä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ätiedotTestaus 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ä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ä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ätiedotVerifioinnin 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ä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ä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ätiedotTestaus elinkaaressa. Testaustasot ja vaiheet
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
LisätiedotOhjelmistotuotanto s
Laadunvarmistustekniikoita Ohjelmistotuotanto 1 testaus (testing) ohjelman suorittamista tarkoituksena löytää virheitä tarkastukset (inspections, reviews) asiantuntijoiden suorittamia dokumentin (voi olla
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ätiedotLaadunvarmistustekniikat
Laadunvarmistustekniikat Ohjelmistojen laadunvarmistustekniikoita: testaus (testing) ohjelman suorittamista tarkoituksena löytää virheitä tarkastukset (inspections, reviews) asiantuntijoiden suorittamia
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ä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ä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ätiedotAutomaattinen 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ä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ätiedot2. Ohjelmistotuotantoprosessi
2. Ohjelmistotuotantoprosessi Peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa
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ä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ä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ä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ätiedotTestaussuunnitelma Labra
Testaussuunnitelma Labra Helsinki 25.8.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos 1 Kurssi 581260 Ohjelmistotuotantoprojekti (9+1op) Projektiryhmä Anssi Kapanen,
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ä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ätiedot7. 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ä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ä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ätiedotOhjelmistojen suunnittelu
Ohjelmistojen suunnittelu 581259 Ohjelmistotuotanto 154 Ohjelmistojen suunnittelu Software design is a creative activity in which you identify software components and their relationships, based on a customer
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ätiedotTestausprosessin vaatimukset. 2. Testausprosessi (Artikkelit) Vesiputousmallin ongelmia. V-mallin neljä osavaihetta. Testausprosessimalli V-malli
2. ausprosessi (Artikkelit) Nykyisin useimpien prosessimallien lähtökohta on, että testaus on oleellinen osa ohjelmistotuotantoprosessia. Itse asiassa huolellinen testaus vie helposti 50% tai enemmän käytettävistä
Lisätiedot10. Tarkastukset. Tarkastusten rakenne
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ätiedotTarkastusten 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ätiedotProsessimalli. 2. Ohjelmistotuotantoprosessi. Prosessimallin vaihejako. Prosessimallien perustehtävät. Ohjelmiston suunnittelu. Vaatimusmäärittely
2. Ohjelmistotuotantoprosessi Peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa
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ä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ätiedotHarjoitustyö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ätiedotCopyright by Haikala. Ohjelmistotuotannon osa-alueet
Copyright by Haikala Ohjelmistotuotannon osa-alueet Ohjelmiston elinkaari 1. Esitutkimus, tarvekartoitus, kokonaissuunnittelu, järjestelmäsuunnittelu (feasibility study, requirement study, preliminary
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ä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ä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ä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 Tiera on vuonna 2010 perustettu yli 200:n kuntatoimijan omistama
LisätiedotDynaaminen 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ä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ätiedotT 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ä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ä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ätiedotSisältö. Integrointitestaus. Yleinen teoreettinen pohja. Integrointitestaus prosessina. Skooppi, focus ja locus
Sisältö Integrointitestaus Antti Tevanlinna, tutkija, Helsingin yliopisto, Tietojenkäsittelytieteen laitos Yleinen teoreettinen pohja Mitä on integrointitestaus Integrointitestauksen tarve Integrointitestauksen
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ätiedotOhjelmistotuotanto, verifiointi ja validointi Syksy Verifioinnin ja validoinnin ero. 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ä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ätiedotOhjelmistotekniikka - Luento 2
Ohjelmistotekniikka - Luento 2 Luku 2: Prosessimallit - miten spiraalimalliin päädyttiin - spiraalimallista (R)UP malliin - oman ammattitaidon kehittäminen; PSP ja TSP mallit 1 Luento 2: Prosessimallit
LisätiedotTestaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille
1(23) Testaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille Matti Vuori, Tampereen teknillinen yliopisto 30.10.2012 Sisällysluettelo 1/2 Esityksen tarkoitus 4 Laatu on tärkeää, ei
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ätiedotOhjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus
Yhteenveto Ohjelmistotuotanto vs. muut insinööritieteet Monimutkaisuus Näkymättömyys (Usein näennäinen) luotettavuus ja edullisuus Muunnettavuus Epäjatkuvuus virhetilanteissa Skaalautumattomuus Copyright
LisätiedotOhjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA
Ohjelmointitekniikka lyhyesti Survival Kit. Vesiputousmalli ELINKAARIMALLEISTA. Ohjelmiston elinkaari Ohjelmiston elinkaarella (life cycle) tarkoitetaan aikaa, joka kuluu ohjelmiston kehittämisen aloittamisesta
LisätiedotProject-TOP QUALITY GATE
Project-TOP QUALITY GATE FOR SUCCESSFUL COMPANIES TYÖKALU ERP- JÄRJESTELMIEN TESTAUKSEEN PROJECT-TOP QUALITY GATE Quality Gate on työkalu ERP-järjestelmien testaukseen Huonosti testattu ERP- järjestelmä
LisätiedotTestaussuunnitelma. Karstula. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma Karstula Helsinki 20.4.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Juha-Pekka Juutilainen
LisätiedotTestaus 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ätiedotSisällys. JAVA-OHJELMOINTI Osa 7: Abstrakti luokka ja rajapinta. Abstraktin luokan idea. Abstrakti luokka ja metodi. Esimerkki
Sisällys JAVA-OHJELMOINTI Osa 7: Abstrakti luokka ja rajapinta Abstrakti luokka ja metodi Rajapintamäärittely (interface) Eero Hyvönen Tietojenkäsittelytieteen laitos Helsingin yliopisto 13.10.2000 E.
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ätiedotOhjelmistotekniikka - Luento 2 Jouni Lappalainen
Ohjelmistotekniikka - Luento 2 Jouni Lappalainen Luku 2: Prosessimallit - miten spiraalimalliin päädyttiin - spiraalimallista (R)UP malliin - oman ammattitaidon kehittäminen; PSP ja TSP mallit 1 Luento
LisätiedotSuunnitteluvaihe 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ä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ä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ätiedotTestaussuunnitelma. Pizzeria - Pitseria HAAGA-HELIA ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma. WebPizza
Testaussuunnitelma Pizzeria - Pitseria HAAGA-HELIA ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma Versio 1.0 Ehdotus Laatija Raine Kauppinen VERSIOHISTORIA Versionotyyppi Versio- Päiväys Tekijä
LisätiedotOhjelmoinnin 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ätiedotOhjelmiston 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ätiedotOlio-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ä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ä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ätiedotOhjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1
3. Komponentit ja rajapinnat 3.1 Komponenttien idea: ohjelmistotuotannon rationalisointi 3.2 Mikä on ohjelmistokomponentti? 3.3 Komponentit ohjelmistoyksikköinä 3.4 Rajapinnat 3.6 Komponenttien räätälöinti
LisätiedotYhteenvetoa, 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ä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ätiedotToisessa viikkoharjoituksessa on tavoitteena tutustua JUnit:lla testaukseen Eclipse-ympäristössä.
Toisessa viikkoharjoituksessa on tavoitteena tutustua JUnit:lla testaukseen Eclipse-ympäristössä. JUnit-ympäristö 1. Luo tests -pakkaukseen uusi luokka. Nimeä VHTestit. 2. Laita VHTestit periytymään TestCase:sta
LisätiedotLaadunvarmistustekniikoita. 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ätiedotTestauksen hallinta Testaustyökalut Luento 7 Antti-Pekka Tuovinen
Testauksen hallinta Testaustyökalut Luento 7 Antti-Pekka Tuovinen 23 April 2018 1 Tavoitteet Yleiskuva seuraavista aiheista Testauksen organisointi Testaussuunnittelma Testauksen kustannukset Testausstrategia
LisätiedotTestaussuunnitelma. Opeapuri. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma Opeapuri Helsinki 2.4.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Krister Eklund
LisätiedotKONEAUTOMAATION LAATU JA TURVALLISUUS. 4.6.2015 Marko Varpunen
KONEAUTOMAATION LAATU JA TURVALLISUUS 4.6.2015 Marko Varpunen TLJ ja automaatio Rautatie, metro, teollisuus-laitokset, kaivoskoneet, vesi, n. 90 henkeä Mikkeli Turvallisuusjohtaminen konsultointi riskienarviointi
Lisätiedot812341A 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ätiedotOsoitin ja viittaus C++:ssa
Osoitin ja viittaus C++:ssa Osoitin yksinkertaiseen tietotyyppiin Osoitin on muuttuja, joka sisältää jonkin toisen samantyyppisen muuttujan osoitteen. Ohessa on esimerkkiohjelma, jossa määritellään kokonaislukumuuttuja
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ä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ätiedotJUnit ja EasyMock (TilaustenKäsittely)
OHJELMISTOJEN TESTAUS JA HALLINTA Syksy 2015 / Auvo Häkkinen JUnit ja EasyMock (TilaustenKäsittely) Tehtävässä tarvittava koodi löytyy osoitteella http://users.metropolia.fi/~hakka/oth/mockesimerkki.zip
LisätiedotOhjelmistojen testaus
Ohjelmistojen testaus Juha Taina 1. Perusteet (P&Y:1-4) Kurinalainen insinöörityö sisältää suunnittelun ja rakentamisen lisäksi välttämättä tehtäviä, joiden tarkoitus on tunnistaa ja poistaa keskeneräisestä
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ätiedot11/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ätiedotOhjelmistotuotanto, prosessit Syksy Ohjelmistotuotantoprosessi. Prosessimalli. Prosessimallien perustehtävät. Prosessimallin vaihejako
2. Ohjelmistotuotantoprosessi peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa
LisätiedotUudelleenkäytön jako kahteen
Uudelleenkäyttö Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta
LisätiedotHyväksymistestauksen tarkistuslista järjestelmän hankkijalle
Hyväksymistestauksen tarkistuslista järjestelmän hankkijalle Tarkistuslista on suunniteltu käytettäväksi hyväksymistestauksen suunnittelussa, valmiuksien arvioinnissa ja katselmoinnissa.tämä tarkistuslista
Lisätiedot6. Suunnittelu. Suunnitteluprosessi
6. Suunnittelu Vaatimusanalyysin jälkeen seuraava työvaihe on suunnittelu. Siinä vaatimusanalyysin korkean abstraktiotason malleja käyttämällä luodaan alempien abstraktiotasojen malleja. Tavoitteena on
LisätiedotDynaaminen 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