search query: @keyword ohjelmistotestaus / total: 49
results-list
reference: 19 / 49
« previous | next »
Author:Eerola, Matti
Title:Ohjelmistotuotelinjan automaattinen yksikkötestaus
Automatic unit testing of product line architecture
Publication type:Master's thesis
Publication year:2009
Pages:76      Language:   fin
Department/School:Informaatio- ja luonnontieteiden tiedekunta
Degree programme:Tietotekniikan tutkinto-ohjelma
Main subject:Ohjelmistotekniikka   (T-106)
Supervisor:Malmi, Lauri
Instructor:Lampi, Mikko
OEVS:
Electronic archive copy is available via Aalto Thesis Database.
Instructions
close

Reading digital theses in the closed network of the Aalto University Harald Herlin Learning Centre

In the closed network of Learning Centre you can read digital and digitized theses not available in the open network.

The Learning Centre contact details and opening hours: https://learningcentre.aalto.fi/en/harald-herlin-learning-centre/

You can read theses on the Learning Centre customer computers, which are available on all floors.

Logging on to the customer computers

  • Aalto University staff members log on to the customer computer using the Aalto username and password.
  • Other customers log on using a shared username and password.

Opening a thesis

  • On the desktop of the customer computers, you will find an icon titled:

    Aalto Thesis Database

  • Click on the icon to search for and open the thesis you are looking for from Aaltodoc database. You can find the thesis file by clicking the link on the OEV or OEVS field.

Reading the thesis

  • You can either print the thesis or read it on the customer computer screen.
  • You cannot save the thesis file on a flash drive or email it.
  • You cannot copy text or images from the file.
  • You cannot edit the file.

Printing the thesis

  • You can print the thesis for your personal study or research use.
  • Aalto University students and staff members may print black-and-white prints on the PrintingPoint devices when using the computer with personal Aalto username and password. Color printing is possible using the printer u90203-psc3, which is located near the customer service. Color printing is subject to a charge to Aalto University students and staff members.
  • Other customers can use the printer u90203-psc3. All printing is subject to a charge to non-University members.
Location:P1 Ark Aalto     | Archive
Keywords:software testing
automatic unit testing
product line architecture
ohjelmistotestaus
automaattinen yksikkötestaus
tuotelinja-arkkitehtuuri
Abstract (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.
Abstract (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.
ED:2010-01-11
INSSI record number: 38701
+ add basket
« previous | next »
INSSI