This document discusses model-driven testing using the UML 2.0 Testing Profile (U2TP). It introduces the U2TP and how it can be applied to a UML system design model to generate a test design model. A methodology is presented where the test architecture and behavior are specified by transforming system design diagrams using U2TP concepts. This allows testing to be integrated early in the design process.

1. Model-Driven
Testing with UML
2.0 Presenter :
Ishara Amarasekera
Zhen Ru Dai

2. Contribution
Introduce a methodology of how to apply UML 2.0 Testing Profile
(U2TP) concepts to an existing UML system design model effectively
in order to retrieve a test design model.

3. “
Due to increasing complexity of today’s
software systems, the early integration of
testing into the development process
becomes more and more important. By
doing so, design mistakes and
implementation faults can be detected in
an early stage of the design process.
This allows reduction of time and costs.

4. Model
Driven
Testing

5. Model Driven
Architecture
⊙ Test design models might be transformed from system design
models directly. This enables the early integration of test
development into the overall development process.
⊙ The model-driven architecture approach defines system
functionality using a platform-independent model (PIM) using an
appropriate domain-specific language (DSL).
⊙ Then, given a platform model corresponding to CORBA, .NET,
the Web, etc.
⊙ PIM is translated to one or more platform-specific models (PSMs)
that computers can run.
⊙ In another transformation step, system code may also be derived
from the PSM.

6. Approaches to
Model-Driven
Testing

7. Approaches to
Model-Driven
Testing
⊙ The same abstraction in terms of platform independent, platform
specific modeling and system code generation can be applied to
test design models
⊙ Once the system design model is defined at PIM level, a platform
independent test design model (PIT) can be derived.
⊙ This model can be transformed either directly to test code or to a
platform specific test design model (PST)
⊙ The same transformation technology can be used for deriving PSTs
from the PSM.
⊙ After each transformation step, the test design model can be refined
and enriched with test specific properties.

8. UML 2.0
Testing
Profile

9. Use of UML 2.0
Testing Profile
⊙ UML is a visual language that supports design and development
of complex object-oriented systems.
⊙ As the system complexity grows, the need for solid testing
increases.
⊙ UML itself, even the newest version 2.0 provides no means to
describe a test model.
⊙ Thus, a UML 2.0 profile for the testing, called the UML 2.0
Testing Profile (U2TP), has been defined
⊙ U2TP bridges the gap between designers and testers by
providing a means for using UML for both system modeling and
test specification. This allows a re-use of UML design documents
for testing and enables test development in an early system
development phase.

10. ⊙ The UML 2.0 Testing Profile provides concepts to develop test
specifications and test models for black-box testing.
⊙ The profile introduces four logical concept groups covering the
followings.
1. Test Architecture
2. Test Behavior
3. Test Data
4. Time
⊙ Together, these concepts define a modeling language for
visualizing, specifying, analyzing, constructing and documenting a
test system.
UML 2.0
Testing Profile

11. Test
Architecture
⊙ Test architecture concepts needed to specify the structural aspects
of a test system including the following items
⊙ Test context which allows users to group test cases, to describe a
corresponding test configuration and to define the test control
⊙ The System Under Test (SUT), where one or more objects within a
test specification can be identified as the SUT.
⊙ Test components, which are defined as objects within the test
system that can communicate with the SUT or other components to
realize the test behavior.
⊙ The scheduler, which controls test execution and test component.

12. Test Behavior
⊙ The test behavior specifies the actions and evaluations that are
necessary to evaluate the test objective.
⊙ The test objective describes the aim of a test.
⊙ UML interaction diagrams, state machines, and activity diagrams
can be used to define test stimuli, observations from the SUT, test
control/invocations, coordination and actions.

13. Test Data
⊙ UML 2.0 Testing Profile supports wildcards, data pools, data partitions,
data selectors, and coding rules.
⊙ Wildcards are very useful for the handling of unexpected events, or
events containing many different values.
⊙ Therefore, the UML 2.0 Testing Profile introduces wildcards allowing
the specification of:
(1) Any value, denoting any value out of a set of possible values,
and
(2) Any or omitted values, denoting any value or the lack of a value (in
the case where multiplicities range from 0 upwards).
⊙ Data pools, data partitions, and data selectors support the repeated
execution of test cases with different data values to stimulate the SUT
in various ways.

14. ⊙ Timing concepts are provided to complete the concepts needed for
precise and complete test modeling.
⊙ Two new timing concepts added are in UML 2.0; Timers and Time
zones.
⊙ Timers, to manipulate and control test behavior as well as to
ensure the termination of test cases
⊙ Time zones, to group components within a distributed system,
thereby allowing the comparison of time events within the same
time zone.
Time

15. UML 2.0
Testing Profile

16. Model
Driven
Testing With
UML 2.0

17. Model Driven
Test
Development
Methodology
⊙ Step 1: Define a new UML package as the test package of the
system.
⊙ Step 2 : Import the classes and interfaces from the system design
package in order to get access to messages and data types in the
test specification.
⊙ Step 3: Start with the specification of the test architecture and
continue with test behavior specifications.
⊙ Test data and time are mostly already comprised in either the test
architecture (e.g. time zone or data pool) or test behavior (e.g. timer
or data partitioning) specifications.

18. Mandatories
and Optional
Test
Architecture
Mandatory:
⊙ Assign the classes (in a Class Diagram) or objects (in an Object
Diagram) you would like to test to SUT class/object.
⊙ Specify a test context class listing the test attributes and test
cases, also possible test control and test configuration.

19. Optional :
⊙ Define test components depend on their functionalities. Group the
classes/objects (except the SUT) to test component classes/objects.
⊙ Specify the test control In order to define the order of test case
execution.
E.g.: Each Activity illustrates one test case.
Activity Flow describes the test flow.
Use Case – Each Use case depicts a test case
⊙ Retrieve test configuration easily by means of existing Interaction
Diagrams.
If there is no Interaction Diagram provided, connect the test components
and SUT to an appropriate test configuration so that the configuration is
relevant for all test cases included in the test suite.
⊙ Assign time zones to the components if the test system is a distributed
system.
⊙ Provide coding rule information.
Mandatories
and Optional
Test
Architecture

20. Mandatory:
⊙ Specification of test cases
For Interaction Diagrams, change (i.e. rename or group) the
instances and assign them with stereotypes according to
their roles (i.e. test component or SUT).
For Use Case Diagrams or Activity Diagrams provided in the
system design model, the use cases and activities are
specified in additional Interaction Diagrams. Thus, for each
use case or activity, a test case should be specified.
⊙ Assigning verdicts at the end of each test case specification.
Usually, the verdict in a test case is set to “pass”.
Mandatories
and Optional
Test Behavior

21. Optional :
⊙ Define test objectives for each test case that is to be specified.
⊙ Obtain system behavior which are not used for the tests from the
default specifications.
Interaction Diagrams like Sequence Diagrams, State Machines or Activity
Diagrams should be used here.
Use wildcards to catch unexpected behavior
⊙ Derive Timers from time constraint specifications within a Sequence
Diagram or State Machine.
Mandatories
and Optional
Test Behavior

22. Test Design
Model
Transformation
⊙ Now the Test UML package is ready next, need a grouping
mechanism, which should be provided by the Test Directives Meta-
Model.
⊙ Test Derivative Model - The relationship between the objects
which should be grouped to test component is specified
⊙ The output test model consists of the test component and the SUT
instance.

23. Test Design
Model
Transformation

24. Conclusion
Test architecture and behavior can be specified for the test design
model by performing appropriate transformation rules on the different
system design diagrams by applying U2TP concepts .

25. Thanks!
Any questions?
You can find me at
@username &
user@mail.me