Regression Testing UML Designs

1
Regression Testing UML Designs

• Source IEEE International Conference on Software
  Maintenance
• (ICSM2006)
• Author Orest Pilskalns?Gunay Uyan and Anneliese
  Andrews
• Presented by Chen Hung-Hsiang

2
Outline

• Introduction
• Background
• A UML Regression Testing Approach
• Conclusion

3
Introduction

• As Model Driven Architectures (MDAs) gain in
  popularity several techniques that test the UML
  models have been proposed.
• Somebody proposed an approach to test the UML
  design models to check for inconsistencies.
• They create an aggregate model which merges
  information from Class Diagrams, Sequence Diagram
  and OCL statements, then generate test cases to
  identify inconsistencies.

4
Introduction cont.

• Contribute
• Author provide a set of rules about how to reuse
  part of the existing test cases, and generate new
  ones to ensure all effected parts of the system
  are tested adequately.
• The approach is a safe and efficient selective
  retest strategy.

5
Background

• Regression testing concept

6
Background cont.

• Regression Testing
• Regression testing strategies
• To find where changes occur in a system, with the
  intent that identification will allow for testing
  of the modified section of code.
• To decide which tests are more likely to reveal
  faults introduced by the modifications.
• To determining where additional tests may be
  needed.

7
Background cont.

• Regression testing of UML designs need to address
  issues
• Can we identify and classify changes made to
  different versions of a UML design?
• Assuming we identify the changes, can we use
  these changes to safely and efficiently select
  test cases for regression testing?
• Can we determine where new tests are needed in
  order to generate new tests?

8
Background cont.

• Safe and Efficient
• If a selective retest strategy reveals the same
  fault as a retest-all strategy, then the
  selective retest strategy is determined to be
  safe.
• If the selective retest strategy has a runtime
  less than a retest-all it is deemed to be
  efficient.

9
Background cont.

• Test case classify
• Reusable test cases
• Those cases are cover code that has not been
  modified.
• Retestable test cases
• Those cases are cover code that has been
  modified.
• Obsolete test cases
• Those cases are no longer valid.

10
Background cont.

• The UML testing approach
• UML testing relies upon building an integrated
  model from Class Diagram, Sequence Diagrams and
  OCL, the model consist of three steps
• Step1 maps Class Diagrams into tuples, called
  Class Tuples (CT).
• Step2 maps Sequence Diagrams into an Object
  Method Directed Acyclic Graph (OMDAG).
• Step3 combines each OMDAG with the CT information.

11
A UML Regression Testing Approach
modify
D
D
Test by
T
12
A UML Regression Testing Approach
13
A UML Regression Testing Approach cont.
14
A UML Regression Testing Approach cont.
v0 v1
T1 x0 T2 x1 T3 x2 T4 x4
v0 v2
15
A UML Regression Testing Approach cont.

• Following high-level algorithm specifies this
  approach
• Perform a topological sort of OMDAG C.
• For all vertices in C, classify type of design
  change (DC)
• Vertex change
• Edge change
• Classify DC as a path affecting change (PDC) or a
  non-path affecting change (NDC).
• Classify the test cases TC of OMDAG C find nodes
  affected by a design change.
• Rerun retestable test cases.
• Identify nodes and edges in the new OMDAG C that
  need to be covered.
• Apply non-binary domain analysis to the paths and
  nodes using the technique.
• Execute the new test cases.

16
Identify and Classify changes

• Author are interested in creating rules that
  specify how a UML-design change impacts test.
• Briand et al 11 use code test cases.
• Weakness complex because they must crate a large
  set of rules s for classifying changes to deal
  with the complexities of code.
• Author used UML test cases.

17
Identify and Classify changes

• Classify change according to they create, modify,
  or delete element in a design
• NEWSET
• All create changes are members of the NEWSET
• MODSET
• All modify changes are members of the MODSET
• DELSET
• All delete changes are members of the DELSET

18
Identify and Classify changes cont.

• Using Corollary 3.2 to classify all changes into
  two categories
• PDCSET
• All path design changes are part of the PDCSET.
• NDCSET
• All non- path design changes are part of the
  NDCSET.

19
Identify and Classify changes cont.
20
Identify and Classify changes cont.
21
Mapping Design Changes to OMDAG Vertices
22
Classifying Test Cases
23
Classifying Test Cases cont.

• Obsolete Test Cases

24
Classifying Test Cases cont.

• Retestable Test Cases

25
Classifying Test Cases cont.
26
Generating New Test Cases
27
Safety and Efficiency

• Safety
• Authors approach selection process is based on
  classify the changes in a directed graph, the
  path defines how the changes impact testing. In
  this property of the graph that allows us to
  safely select a regression test suite.
• A control flow graph, which is a more complex
  model has been shown to be safe by Rothermel.
• Efficiency
• The performance of algorithm 3 relies on the
  number of test cases, x, and the number of design
  changes y. The runtime can be described by
  O(xy).
• If we were to run all of the tests again, the
  runtime would be O(nlog(n)).

If xgty , it is efficient
28
Case study

• Batick is used for desplaying and manipulating
  scalable vector graphics (SVG) in java
  applications. This case study focuses on the
  Trascoder, a key component inside the core module
  of batik.
• The trascoder UML design component consists of 32
  classes contained in Class and Sequence Diagrams.
  In they built and integrated model and generated
  52 test cases.

29
Case study cont.
Only 4 existing test cases were retestable and
generate 14 new test cases.
30
Conclusion

• Author have adapted a safe and effective
  retesting technique for UML design evaluation.
• Their approach relies on categorizing changes to
  UML designs and creating rules to classify test
  cases based and those categories.