haku: @keyword ohjelmistotestaus / yhteensä: 49
viite: 19 / 49
| Tekijä: | Eerola, Matti |
| Työn nimi: | Ohjelmistotuotelinjan automaattinen yksikkötestaus |
| Automatic unit testing of product line architecture | |
| Julkaisutyyppi: | Diplomityö |
| Julkaisuvuosi: | 2009 |
| Sivut: | 76 Kieli: fin |
| Koulu/Laitos/Osasto: | Informaatio- ja luonnontieteiden tiedekunta |
| Koulutusohjelma: | Tietotekniikan tutkinto-ohjelma |
| Oppiaine: | Ohjelmistotekniikka (T-106) |
| Valvoja: | Malmi, Lauri |
| Ohjaaja: | Lampi, Mikko |
| OEVS: | Sähköinen arkistokappale on luettavissa Aalto Thesis Databasen kautta.
Ohje Digitaalisten opinnäytteiden lukeminen Aalto-yliopiston Harald Herlin -oppimiskeskuksen suljetussa verkossaOppimiskeskuksen suljetussa verkossa voi lukea sellaisia digitaalisia ja digitoituja opinnäytteitä, joille ei ole saatu julkaisulupaa avoimessa verkossa. Oppimiskeskuksen yhteystiedot ja aukioloajat: https://learningcentre.aalto.fi/fi/harald-herlin-oppimiskeskus/ Opinnäytteitä voi lukea Oppimiskeskuksen asiakaskoneilla, joita löytyy kaikista kerroksista.
Kirjautuminen asiakaskoneille
Opinnäytteen avaaminen
Opinnäytteen lukeminen
Opinnäytteen tulostus
|
| Sijainti: | P1 Ark Aalto | Arkisto |
| Avainsanat: | software testing automatic unit testing product line architecture ohjelmistotestaus automaattinen yksikkötestaus tuotelinja-arkkitehtuuri |
| Tiivistelmä (fin): | Tässä työssä perehdytään erään järjestelmän automaattisen yksikkötestauksen toteuttamiseen. Kohdejärjestelmä on Internet-pohjainen sovellus, joka noudattaa ohjelmistotuotelinja-arkkitehtuuria. Arkkitehtuurin avulla ohjelmiston komponenttien uudelleenkäyttöä voidaan parantaa. Lisäksi toimintaa voidaan muokata erilaiseksi eri asiakkaille ja tuotteille. Työn tarkoitus on kartoittaa kohdejärjestelmän testauksessa olevat haasteet ja selvittää, mitkä niistä voidaan ratkaista automaattisella yksikkötestauksella. Lopullisena tavoitteena on, että tämän työn tuloksena automaattinen yksikkötestaus saadaan osaksi sovelluskehitysprosessia. Tavoitteen saavuttamiseksi työssä toteutettiin kirjallisuuskatsaus, jossa kartoitettiin olemassa olevia testausmenetelmiä, automaattisen yksikkötestauksen ominaisuuksia ja tuotelinja-arkkitehtuurin vaikutuksia testaukseen. Testauksessa olevia haasteita kartoitettiin pienimuotoisella avoimella haastattelulla. Havaittujen haasteiden perusteella suunniteltiin ja toteutettiin automaattisessa yksikkötestauksessa käytettävä testausjärjestelmä Kun testausjärjestelmä oli toteutettu, toteutettiin automaattisia yksikkötestejä ja mitattiin testeissä havaittujen virheiden määrää ja saavutettua kattavuutta. Mittausten avulla muodostettiin käsitys siitä, miten toteutettu yksikkötestausjärjestelmä ja automaattiset yksikkötestit vaikuttavat ohjelmiston testaukseen ja laatuun. Lisäksi automaattisten yksikkötestien toteutuksen yhteydessä saatiin parempi kuva valittujen työkalujen soveltuvuudesta automaattisen yksikkötestauksen toteuttamiseen. Kirjallisuuden perusteella tehokkain tapa toteuttaa yksikkötestausta tuotelinja-arkkitehtuurissa on tuotelinjan sovelluskehitysprosessin yksikkötestausvaiheessa. Tuotelinjan sovelluskehitys- prosessissa tapahtuvan testauksen todettiin kuitenkin olevan vaikeaa, koska varioitavuutta ei ole vielä siinä vaiheessa sidottu. Kirjallisuuden mukaan varioitavuuden sitomiseksi tarvittiin varioitavuuden huomioon ottavia työkaluja ja suunniteltuun yksikkötestausjärjestelmään lisättiinkin yksikkötestauskehys, joka laajennettiin käsittelemään tuotelinjan varioitavuutta. Testien toteutuksen yhteydessä kerättyjen tulosten perusteella testausjärjestelmä mahdollisti automaattisen yksikkötestauksen tuotelinjan sovelluskehitysprosessissa. Automaattisten testien toteutuksen yhteydessä törmättiin kuitenkin siihen, että testien toteutus vaatii melko paljon aikaa, mikä on kirjallisuuden mukaan yleisesti testauksen automatisoinnin ongelmana. Mittaustulosten perusteella ei pystytty selkeästi osoittamaan käytetyn järjestelmän vaikutusta ohjelmiston laatuun. Kirjallisuudessa esitetyissä tutkimuksissa testien automatisoinnin on kuitenkin todettu parantavan ohjelmiston laatua. Yksikkötestauksessa havaittujen virheiden analysointi osoitti, että suurin osa yksikkötesteissä havaituista virheistä olisi havaittu vasta yksittäisten tuotteiden testauksen yhteydessä. Yksittäisten tuotteiden testaus taas tapahtuu vasta tuotelinjan testauksen jälkeen, joten automaattisella yksikkötestauksella saavutettiin jonkin verran säästöjä, koska virheet havaittiin aikaisemmin. |
| Tiivistelmä (eng): | This work studies automatic unit testing of specific software that is web-based and uses product line architecture. Product line architecture enables greater reuse of software components. It also allows customizations for individual customers and products. The objective of this work is to examine what are the problems of testing the specific software and which problems can be solved with automatic unit testing. One objective is also to introduce automatic unit testing as one of the activities in the software engineering process that is used to develop the specific software. The work included literature survey, small open interview, planning and implementation of the automatic unit testing system and empirical study. The objective of literature survey was to research which techniques exist for automatic unit testing and what are the characteristics of automatic unit testing. The literature survey also viewed the effects of product line architecture to software testing. The open interview surveyed the problems involved in testing the software. Empirical study was performed after the implementation of the automatic unit testing system. Code coverage and number of errors found in unit testing were measured during the empirical study. Measurements were used to get insight of how the implemented unit testing system and the automated unit tests affected software testing and quality. The results also helped to assess suitability of the selected tools to testing. In product line architecture unit testing is more efficient during domain engineering than application engineering according to literature. The problem in testing during domain engineering is that variability is not yet bound. Customized testing tools are needed to enable testing when variability is not yet bound so unit testing framework was added to the planned testing system. It was modified to cope with unbound variability iii the product line. Based on the results from the empirical study the implemented solution allowed testing during domain engineering. It was also observed, as in literature, that the costs for creating automatic unit tests were high. There was no clear evidence of improved quality based on the results from this study. Previous researches however have shown that software quality can he improved by automatic testing. Analysis of errors found during automatic unit testing indicated that the majority of errors would not have been found until application testing. The testing of single applications takes place after domain testing so it can be said that some savings were achieved by automatic unit testing, because errors were found earlier. |
| ED: | 2010-01-11 |
INSSI tietueen numero: 38701
+ lisää koriin
INSSI