Testing Component-Based Systems Using FSMs

Abstract

Summary.No matter which tools, techniques, and methodologies are used for software development, it remains an error-prone process. Nevertheless, changing such important constituents of the software process surely has an effect on the types of faults inherent in the developed software. For instance, some types of faults are typical for structured development, whereas others are typical for object-oriented development.This chapter explores the question of whether component-based software requires new testing techniques, and proposes an integrated testing technique. This technique integrates various tasks during testing component-based software: whiteand black-box testing of the main component (i.e., the top level component controlling the other components), black-box testing of components, black-box testing of the middleware and integration testing of the main component with other components.Benefits of this technique are shown using a real-world example: the technique is automatable and applicable to existing component-based software.

Automated, contract-based user testing of commercial-off-the-shelf components

“…Note that BIT support is a vendor technique widely discussed (e.g., many chapters in [4] tailoring of the testing activity by the user, besides enabling autotesting. Figure 1 captures the framework to be used when reasoning on component vendor and user responsibilities to ease component testing in the context of a particular component deployment.…”

“…Similarly, for each selected Boolean variable value combination resulting in a false value of 3 For instance, assuming that the test case being constructed currently ends with method m k and constraint (m i , m j , p) has to be exercised, it might be less expensive to exercise (m k , #, true), that is the re-instantiation arc, followed by a path from # to m i (followed by m j ), than a path from m k to m i . 4 If three Boolean variables are involved in the predicate and values 0, 1, and 1 (for the three variables respectively) are selected according to the predicate criterion, the integer representation is 3 (0.2^2 + 1.2^1 + 1.2^0).…”

CBS testing requirements and test case process documentation revisited

“…White-box testing and black-box testing is used to test the main component. The main component has to be tested first using test cases generated on the basis of the source code, and then using test cases generated on the basis of its specifications [9]. When source code may not be available for some components then black-box testing of components is usually sufficient because at this level there is often no need for low-level testing techniques based on source code.…”

A component-based specification approach for embedded systems using FDTs

“…While in the last few years component-based software development gained much more attention from both researchers and practitioners, testing such software systems is still however to be more studied [11]. Because one believes that once a component is sufficiently tested, it is not needed to test it again when reused.…”

“…Because one believes that once a component is sufficiently tested, it is not needed to test it again when reused. But, this is generally not true, since components may satisfy a certain application domain and fails in a new environment [11].…”