Languages
DE
Putting the customer at the center of business activities – product variants are an expression of this strategy. Tool-supported testing of variant-rich embedded systems adapts the quality assurance of this development and helps to ensure the functional safety of the product, even in demanding competitive situations.
In order to manage the development of variant-rich products efficiently and cost-effectively, product lines are used in software development. Product lines are comparable to development platforms in vehicle construction and comprise several individual versions of a software product, each of which meets different requirements. Targeted and organized reuse of common product artifacts as the basis for different variants of the product line can save resources and development costs. The main purpose of developing product lines is to be able to adapt the software to different needs. The conceptual development of a product line must take two essential aspects into account:
1. The description of the variability of a product line
2. The division into domain and application engineering
The variability of a product line describes the entirety of a software product’s functions that can be adapted to different customer requirements through selection.
Domain engineering is a concept for the systematic reuse of software artifacts in development. Domain analysis identifies similarities and differences in the developed systems. Based on this, the constant and variable components of a product line can be defined at the domain design level. In application engineering, the individual end products are now developed using the developed software artifacts. This results in product variants with common and different properties. These properties are also called features. A distinction is made between the basic features and the variant-specific features of a product line.
Feature models are used to represent all variants of a product line. The model and its features can be represented using a tree structure, for example. Figure 1 shows an excerpt from a simplified feature model. It shows feature variants for vehicle access control.
The elements in a feature model can be differentiated according to different types, relationships, and characteristics. Feature types distinguish individual features based on specific characteristics. This includes, for example, the distinction between mandatory features that must be included in every product variant and optional features. Feature relations describe the type of relationship a feature has to its branches. For example, the selection of one feature may require (requires) or exclude (excludes) another. The selection of features can also be restricted.
In this way, for example, limits can be defined for the number of features that can be selected from a group. For example, in the feature model shown, only one country or door configuration is allowed per product variant. Feature characteristics are attributes that contain information about a feature, such as names and value ranges.
Variation points are particularly important in the software development process. They mark the branching paths that graphically describe the creation of new product variants. Semantically, feature combinations can be described using propositional logic formulas.
A feature model not only allows the various functions of the system to be developed to be represented, but also offers a way to optimize the test design of embedded systems with many variants.
Since product variants significantly increase the testing effort, it is important to have a way to manage and execute the resulting test cases. ITPower Solutions has developed such a concept for testing variants of embedded software. With the help of feature models, a way to select test cases for different product variants was created. The selection of test cases for different product variants is done by linking test cases and features of a product line. The link is made at the variation points. Here, a corresponding test element can be specified for each child node of a parent node in the feature tree.
The goal was to define a test procedure that tests all possible features, links them to the variation points, and automatically selects the appropriate test cases after the test strategy criteria have been entered. The respective product variant is represented here by a propositional logic formula that describes each feature with a Boolean value. The semantics of the propositional logic model therefore correspond to the set of all feature configurations permitted by the feature model. When implementing the solution, care must of course be taken not to allow the user to select contradictory features.
To define a variant, the user selects, for example, features A1, A2, …, An. These would then imply features B1, B2, …, Bm and exclude features C1, C2, …, Ck, according to the feature types, relations, and characteristics. The following formula represents the logical conclusion and the selected configuration:
(A1 ˄ A2 ˄ … ˄ An) ˄ (B1 ˄ B2 ˄ … ˄ Bm) ˄ ̚ (C1 ˅ C2 ˅ … ˅ Ck)
In this case, the graphical representation of the feature models for specifying the variants as software implementation is done using TreeView elements (see Figure 2). The TreeView structure offers good clarity, e.g., by expanding and collapsing elements and groupings, and enables good scalability. Information about the hierarchical relationships between the features is displayed in the TreeView view using special symbols and characters. Additional information about a feature, e.g., feature relations and attributes, can also be entered and displayed in the windows provided for this purpose.
For variant management in the test process, it is now possible to link test cases to features. In this case, this is done via an additional menu that allows any point in the test sequence to be defined as a variation point and the alternative test elements to be subsequently linked to the corresponding features in the feature model. To perform the test, the tester selects a variant from the product line. Elements that do not belong to the selected configuration must be deactivated and marked accordingly.
Various strategies are available for selecting tests and variants. This is important for the automated creation of test suites. To control the test coverage of the features, alternative criteria can be defined for how often a single feature is tested. A variant selection can be used to define the number of variants to be used in the test. The third strategy option takes into account the distribution of the test effort between different variants in order to balance the test intensity between them and to be able to skip features that have already been sufficiently tested.
Solutions for testing systems with many variants are particularly suitable for integration into existing testing tools. They build on existing functionalities and expand them.
The concept developed and its implementation in the ContinoProva testing tool supports semi-automated test design for embedded systems with many variants. This greatly simplifies test design, facilitates adjustments, and enables the creation of test suites for testing entire product lines.
This makes complex test scenarios manageable. Product development can focus entirely on market requirements without being slowed down by quality assurance issues.
I am your sales representative and will be happy to advise you on all questions relating to our services and products! Get in touch or simply make an appointment for a free consultation call.
Sebastian Stritz
E-Mail: sebastian.stritz@itpower.de
Phone: +49 (0)30 6098501-17