Software Product Line (SPL) engineering is based on the idea that products of the same family may be built by systematically reusing assets, some of them being common to all members whereas others are only shared by a subset of the family. Such variability is commonly captured by the notion of feature, i.e., an unit of difference between products. A product member of the SPL is a valid combination of features. Individual features can be specified using languages such as UML, while their inter-relationships are organized in a Feature Diagram (FD). An FD thus (abstractly) describes all valid combinations of features (called configurations of the FD), that is all the products of the SPL.
In this project, we are interested in SPL testing. As opposed to to classical testing approaches, where the testing process only considers one software product, SPL testing is concerned about how to minimize the test effort related to a given the SPL (i.e., all the valid products of the SPL). The size of this set is roughly equal to 2^N, where N represents the number of features of the SPL. This number may vary from about 10 (2^10 possible products) in small SPLs to thousands of features (2^1000 possible products) in complex systems such as the Linux kernel. Automated Model-Based Testing and shared execution, where tests can be reused amongst products, are candidates to reduce such effort.
Still, testing all products of the SPL is only possible for small SPLs, given their exponential growth with the number of features. Hence, one of the main questions arising in such a situation is: How to extract and prioritize relevant products? Existing approaches consider sampling products by using a coverage criterion on the FD (such as all valid 2-tuples of features: pairwise) and rank products with respect with respect to coverage satisfaction (e.g. the number of tuples covered). An alternative is to label each feature with weights and prioritize configurations accordingly. These methods actually help testers to scope more finely and flexibly relevant products to test than using a covering criteria alone. Yet, these approaches only sample products based on the FD which does not account for product behavior: they are just configurations of the FD. Furthermore, assigning meaningful weights on thousands of features can be tricky if no other information is available.
