System Testing of Product Lines: From Requirements to Test Cases

Abstract

Product line processes still lack support for testing end-product functions by taking advantage of the specific features of a product line (commonality and variabilities). Indeed, classical testing approaches cannot be directly applied on each product since, due to the potentially huge number of products, the testing task would be far too long and expensive. There is thus a need for testing methods, adapted to the product line context, that allow reducing the testing cost. The approach we present is based on the automation of the generation of application system tests, for any chosen product, from the system requirements of a product line. These PL requirements are modeled using enhanced UML use cases which are the basis for the test generation. Product-specific test objectives, test scenarios, and test cases are successively tional variation points at requirement level to automatically generate the behaviors specific to any chosen product. With such a strategy, the designer may apply any method to produce the domain models of the product line and then instantiate a given product: the test cases check that the expected functionalities have been correctly implemented. The approach is adaptive and provides automated test generation for a new product as well as guided test generation support to validate the evolution of a given product.features. We here focus on system and functional testing. One of the specific issues related to PL testing concerns the way a testing technique deals with the creation of new dom used for driving the functional testing task. However, the end product is expected to assets to obtain a product, and system testing ensures that the end product has the required requirements is known as crucial task for the elaborated design, product requirements are sel-ods being one among them [2,14,19,20,22,23,26]. While the elicitation of product line products and the evolution of existing products. In this chapter, we present the automation as a relevant way for dealing with these issues.Testing a PL is all the more tedious since the common and the shared variant requirements have to be tested for each instantiated product. Indeed, the same piece of functional test code, derived from a requirement, cannot be reused exactly: for instance, in an objectoriented product line, the objects addressed to realize a given functionality may be different from one product to another, due to the crossing of different variation points. For example, the initialization sequence leading to the testing of a particular point may be totally specific test cases may have to be written for each specific product. As a result, manually writing the tests cases for all the products is not conceivable, since it is far too expensive. Automating the test generation appears as a possible way to deal with these cost and timeto-market issues.Many approaches already exist to automatically generate tests from the requirements of variability expressed in product line requirements. To benefit from the product line appautomatically the test ...

Automated and Scalable T-wise Test Case Generation Strategies for Software Product Lines

“…Nebut et al [28] proposed a model-based approach to derive test objectives for the whole system. In [29], Scheidemann defined a method minimizing the set of configurations to verify the whole software product line.…”

Applying product line Use case modeling in an industrial automotive embedded system: Lessons learned and a refined approach

“…Biddle et al [21] provide support for customizing use cases through parametrization. Nebut et al [7] enhance a use case template with parameters and contracts for product line system testing. These two approaches using parameters do not allow analysts to explicitly document variants and variation points.…”

“…In many development environments, such additional modeling and traceability is often perceived as an unnecessary overhead. Some other works [6] [7] [8] propose use case template extensions for textual representation of variability. As Halmans and Pohl [2] stated, textual representation has shortcomings: variation points are not explicit, variability constraints (e.g., number of variants that can be selected for a variation point) cannot be easily represented, and variants are hard to identify.…”

Model-Driven Engineering for Software Product Lines

“…Variability management is thus seen as the key feature that distinguishes SPL engineering from other software development approaches [10]. Variability management is thus growingly seen as the cornerstone of SPL development, covering the entire development life cycle, from requirements elicitation [11] to product derivation [12] to product testing [13,14].…”

“…For example, the early approach presented in [14,118] is based on the automation of the generation of application system tests, for any chosen product, from the system requirements of a Product Line [119]. These PL requirements are modeled using enhanced UML use cases which are the basis for the test generation.…”