Model-Based System Testing of Software Product Families

Reuys, Andreas; Kamsties, Erik; Pohl, Klaus; Reis, Sacha

doi:10.1007/11431855_36

Cited by 69 publications

(68 citation statements)

References 10 publications

(15 reference statements)

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…The frequently used test model is based on the model-based testing approach of Weissleder et al [16]. However, all model-based approaches for SPLs like ScenTED [17] and CADeT [18] can be used for test case derivation because our approach results in complete products which need to be tested. Further model-based testing approaches are summarized in [19] The scope of this contribution is marked with a dashed line: We aim to generate a minimal set of products covering all pairs of feature combinations.…”

Section: Our Approach -Moso-politementioning

confidence: 99%

Automated Incremental Pairwise Testing of Software Product Lines

Oster

Markert

Ritter

2010

Software Product Lines: Going Beyond

112

View full text Add to dashboard Cite

Abstract. Testing Software Product Lines is very challenging due to a high degree of variability leading to an enormous number of possible products. The vast majority of today's testing approaches for Software Product Lines validate products individually using different kinds of reuse techniques for testing. Due to the enormous number of possible products, individual product testing becomes more and more unfeasible. Combinatorial testing offers one possibility to test a subset of all possible products. In this contribution we provide a detailed description of a methodology to apply combinatorial testing to a feature model of a Software Product Line. We combine graph transformation, combinatorial testing, and forward checking for that purpose. Additionally, our approach considers predefined sets of products.

show abstract

Section: Our Approach -Moso-politementioning

confidence: 99%

Automated Incremental Pairwise Testing of Software Product Lines

Oster

Markert

Ritter

2010

Software Product Lines: Going Beyond

112

View full text Add to dashboard Cite

show abstract

“…Such ADs already exist as a result from requirements engineering, or they can be specifically created for testing purposes. In this respect we follow other authors who have successfully employed ADs for modelbased system testing (see [ 8,9]) and build on our own positive experience in applying ADs as test models (see [ 18,19]). …”

Section: Test Model Used For Ritedapmentioning

confidence: 99%

An automated technique for risk-based test case generation and prioritization

Stallbaum

Metzger

Pohl

2008

Proceedings of the 3rd International Workshop on Automation of Software Test

Self Cite

View full text Add to dashboard Cite

In practice, available testing budgets limit the number of test cases that can be executed. Thus, a representative subset of all possible test cases must be chosen to guarantee adequate coverage of a test object. In risk-based testing, the probability of a fault and the damage that this fault can cause when leading to a failure is considered for test case prioritization. Existing approaches for riskbased testing provide guidelines for deriving test cases. However, those guidelines lack the level of detail and precision needed for automation. In this contribution, we introduce the risk-based testing technique RiteDAP, which automatically generates system test cases from activity diagrams and prioritizes those test cases based on risk. The results of applying the technique to a practical example are presented and the ability of different prioritization strategies to uncover faults is evaluated.

show abstract

“…In the literature, several approaches for SPL testing have been proposed (e.g., [4][10] [15][17] [20] [24]). However, these approaches cover unit and system testing only.…”

Section: The Variability Of An Spl Is Modeled Explicitly By Variationmentioning

confidence: 99%

“…These approaches focus on unit and system testing only. In our previous work, we have developed the ScenTED technique for system testing [24][15] and performance testing [23]. McGregor focused on unit [18] and system testing [17], but furthermore he pointed out that all common artifacts can already be tested in domain engineering by integration tests.…”

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Integration Testing in Software Product Line Engineering: A Model-Based Technique

Reis

Metzger

Pohl

Lecture Notes in Computer Science

Self Cite

View full text Add to dashboard Cite

Abstract. The development process in software product line engineering is divided into domain engineering and application engineering. As a consequence of this division, tests should be performed in both processes. However, existing testing techniques for single systems cannot be applied during domain engineering, because of the variability in the domain artifacts. Existing software product line test techniques only cover unit and system tests. Our contribution is a model-based, automated integration test technique that can be applied during domain engineering. For generating integration test case scenarios, the technique abstracts from variability and assumes that placeholders are created for variability. The generated scenarios cover all interactions between the integrated components, which are specified in a test model. Additionally, the technique reduces the effort for creating placeholders by minimizing the number of placeholders needed to execute the integration test case scenarios. We have experimentally measured the performance of the technique and the potential reduction of placeholders. MotivationSoftware product line engineering (SPLE) is a proven approach for deriving a set of similar applications at low costs and at short time to market [8] [21]. SPLE is based on the planned, systematic, and pro-active reuse of development artifacts (including requirements, components, and test cases). There are two key differences between SPLE and the development of single systems [21]:1. The development process of a software product line (SPL) is divided into two sub processes: domain engineering and application engineering. In domain engineering, the commonalities and the variability of the SPL are defined and reusable artifacts, which comprise the SPL platform, are created. In application engineering, customer-specific applications are realized by binding the variability and reusing the domain artifacts. Because of the division of the development process into domain and application engineering, there are two major kinds of development artifacts that have to be tested. In domain engineering, the SPL platform has to be tested, in application engineering the derived applications have to be tested.The SPL platform contains variability. This variability prevents the use of existing testing techniques for single systems, because the domain artifacts do not define a single application but a set of applications. With existing techniques from single system testing, each of these applications would have to be individually tested in domain engineering, resulting in an enormous test effort.In the literature, several approaches for SPL testing have been proposed (e.g.,). However, these approaches cover unit and system testing only.This paper presents a model-based, automated technique for integration testing in domain engineering. Our technique generates integration test case scenarios (ITCSs), which support the test of the interactions between the components of an integrated sub-system. An ITCS describes the order and the t...

show abstract

Model-Based System Testing of Software Product Families

Cited by 69 publications

References 10 publications

Automated Incremental Pairwise Testing of Software Product Lines

Automated Incremental Pairwise Testing of Software Product Lines

An automated technique for risk-based test case generation and prioritization

Integration Testing in Software Product Line Engineering: A Model-Based Technique

Contact Info

Product

Resources

About