Generating Test Cases from UML Model _Part 2_
Shared by: panniuniu
-
Stats
- views:
- 1
- posted:
- 12/1/2011
- language:
- English
- pages:
- 35
Document Sample


Model-Driven Framework for
Context-Dependent Testing of Components
Abu Zafer Javed
Advisors:
Paul Anthony Strooper
Geoffrey Norman Watson
School of Information Technology & Electrical Engineering
The University of Queensland, Australia
September 3, 2007
1
Outline
Problem and Context
Aims / Goals
Work Done
Plan and Contributions
2
Component-based Software Development
Problem and
Context
Component
Unit of composition with contractually specified interfaces
Interface
Component-based software
Advantages
Faster development of software application
Lower development cost
Reusability
3
Context-Dependent Component Testing
Problem and
Context
Component Testing (CT)
Uniform across a range of component’s uses
May fail when use of a components is:
Novel
Intensive for a particular functionality
Context-Dependent Component CDCT
Testing (CDCT)
User benefits from context
Intensive for a particular context
Tendency to discover context-related defects
4
Context-Dependent Component Testing
Problem and
Context
Significance of context
ARIANE 5 Rocket
Examples of different contexts
Different system
CDCT
Different platform
5
Problems In Component Reuse
Problem and
Context
Unexpected behaviour of component
Novel context
Lack of access to internal working of components
Observability
Testability
Test adequacy criteria for component reuse
How much testing component users should perform
6
Outline
Problem and Context
Aims / Goals
Work Done
Plan and Contributions
7
Aims / Goals
Aims / Goals
Devising a Model-driven Framework for Context-
dependent Component Testing
To test component behaviour for new context (CDCT)
To evaluate and extend adequacy of CDCT
Providing a tool support for the framework
Evaluating the framework and its tool support
8
Outline
Problem and Context
Aims / Goals
Work Done
Plan and Contributions
9
Model-Driven Architecture (MDA)
Work Done
Model-centric development
Computation Independent Model (CIM)
Platform Independent model (PIM)
Platform Specific model (PSM)
MDA technology uses model transformation
Models and meta-models
Transformation rules
Model transformation tools
Advantages
Automation of software development
Automation of software testing
Reverse-engineering of software applications
10
Model-Driven Process
Work Done
Horizontal Transformation
Vertical Transformation
Horizontal Transformations
UML Model (UML to xUnit)
xUnit Model
Platform Independent Model OR
Vertical Transformation Vertical Transformation
(xUnit to JUnit) (xUnit to SUnit)
JUnit Test Case SUnit Test Case
Platform Specific Model
11
An Example Sequence Diagram
Work Done
Session ATM Transaction Withdrawl Simulation CardReader CustomerConsole
readCard( )
readCard( )
card
card
readPIN( promptMessage )
readPIN( promptMessage )
pin
pin
makeTransaction
( atm, session, card, pin)
readMenuChoice( )
readMenuChoice( )
choice
choice
. . .
12
Model-Driven Test Case Generator (MTCG)
Work Done
Sequence of
Method Calls
(SMC)
JUnit Code
MTCG Test Case
( with test data )
Test Data
Test Data
Test Data
Compare actual and expected return values of methods
Capture execution traces using Daikon tracing tool
13
Test Case Generation
UML Model to xUnit Model
xUnit Model to Test Case Work Done
Step 1 Step 2
5
6
Model to Model
Transformation Model to Text
Specifications Transformation
Specifications
horizontal vertical
2 3
SMC transformation rules xUnit transformation rules 9
m
Meta- - odel Meta- model
- Test Data
Test Data
Test Data
source metamodel target metamodel source metamodel data
7 8
Tefkat MOFScript 10
Instance of Model to Model Instance of Model to Text Code Header
Transformation Transformation
Tool Tool
source model target model source model test case
1
4 JUnit Code 11
SMC Model
xUnit Model Test Case
( with test data)
A. Javed, P. Strooper, and G. Watson, "Automated Generation of Test Cases Using Model-Driven Architecture, "
14
Proceedings of the 2nd International Workshop on Automation of Software Test, Minneapolis, USA, 2007
User Inputs to MTCG
Work Done
SMC Model <SequenceDiagram name="withdrawal">
readCard
<Message name="Simulation::readCard">
readPIN <ExpectedValue name="card" value="">
<SimpleAttribute name="number" value="1"/>
Test Data </ExpectedValue>
</Message>
XML format <Message name="Simulation::readPIN">
<Parameter name="prompt" value="Please enter PIN."/>
Parameters and <ExpectedValue name="pin" value="42"/>
</Message>
expected value
....
</SequenceDiagram>
15
MTCG Output - JUnit Test Case
Work Done
16
Inputs to the Methodology
Platform Independent Input Work Done
Platform Dependent Input
Test Specific Input
5
6
Model to Model
Model to Text
Transformation
Transformation
Specifications
Specifications
horizontal vertical Test Data 9
SMC 2 transformation rules xUnit
3 transformation rules Test Data
Test Data
Meta-model Meta-model
source metamodel target metamodel source metamodel data
7 8
Instance of Tefkat Instance of MOFScript
Model to Model Model to Text Code Header 10
Transformation Transformation
Tool Tool
1 source model target model source model test case
SMC Model 4 JUnit Code 11
xUnit Model Test data)
(with testCase
17
Limitations of MTCG
Work Done
Simple meta-model for SMC
SMC model is created manually
Traces are compared manually
18
Outline
Problem and Context
Aims / Goals
Work Done
Plan and Contributions
19
The Model-Driven Framework for Context-
Dependent Testing of Components
Plan and
Contributions
Modelling component usage scenarios and
devising test cases
using use case charts
Evaluating and extending test adequacy of
the generated test cases
using component certification metadata
Executing the test cases
Adapting MTCG for components
20
Use Case Charts
Plan and
Specify precise use cases Contributions
Extension of activity diagram
Advantages
Automation of software
development activities
Modeling and Testing of
component-based software
Generating execution
orders of scenarios
J. Whittle, "Specifying precise use cases with use case chart,” Lecture Notes in Computer Science, vol. 3844, 2005
21
Component Certification
Plan and
Contributions
Third-party certification1
Conducted by neutral organization
Context independent
Costly
Developer certification2
Test cases are attached to component as metadata
Context independent
1. W. Councill, "Third-Party Testing and the Quality of Software Components," IEEE Softw., vol. 16, 1999, pp. 55-57.
2. J. Morris, G. Lee, K. Parker, G. Bundell, and C. Lam, "Software Component Certification," Computer, vol. 34, 2001, pp. 30-36.
22
Evaluating Test Adequacy
Plan and
Contributions
Potential Adequacy of CDCT
CT – CDCT = ø Context-Dependent
Component Testing Component Testing
CT – CDCT ≠ ø CDCT CT
Adequacy of CT
CDCT – CT = ø
CDCT – CT ≠ ø CDCT - CT CT– CDCT
CDCT ∩ CT
Weakness in CT Potential weakness
in CDCT
Component acceptability
for the context
23
Extending Test Adequacy
Plan and
Contributions
Using CT - CDCT
Context-Dependent
Using CDCT - CT Component Testing
CDCT
Component Testing
CT
CDCT - CT CT– CDCT
CDCT ∩ CT
Weakness in CT Potential weakness
in CDCT
Component acceptability
for the context
24
Criteria for Comparing Test Cases
and Test Suites
Plan and
Contributions
Comparing Test Cases
Same sequence of method calls
Same parameter values
Same equivalence class of parameter values
Comparing Test Suites
Simple comparison
Using state machines
25
Adapting MTCG for Components
Plan and
Contributions
Object 1 Object 2 Component Object 3 Object 4
Interface Method
Interface Method
Interface Method
26
Contributions
Plan and
Contributions
Model-driven framework for context-dependent testing of
components
Algorithm to derive test requirements from use case charts
Method for evaluating and extending test adequacy
Algorithms for comparing test cases and test suites
Prototype tool support for the framework
Evaluation of the framework and the tool support
27
Tasks
Plan and
Development of the framework and tool support
Contributions
1. Defining a case study
2. Devising an algorithm to determine test requirements from use case charts
3. Proposing and evaluating criteria for comparing test cases and test suites
4. Providing prototype tool support for the proposed framework
5. Applying the framework and tool support to the case study
Evaluation of the framework and tool support
6. Defining a case study for evaluation of the framework
7. Evaluating the framework and the tool support on a case study
8. Analysis of the data collected during evaluation
Thesis Writing
9. Parts of the thesis will be written up as the work progresses
28
Timeline
Plan and
Contributions
29
Thank You
Questions
30
Genericity of the Approach
xUnit-based Approach
MOFScript Rules
(Vertical Transformation-Artifact 6)
xUnit - SUnit xUnit - JUnit
Total Rules 9 9
Rules with Same Structure 7
Total Lines of Code 323 330
Common Lines of Code 282
% Reuse 85
31
SMC Meta-model
Named Element
Interaction
Interaction
Message Literal String
ordered
Class *
Message * owner Class
Parameter
Expected Value *
* Parameter DataValue
Constructor Parameter 1
*
ExpectedValue
Complex Value
*
*
* Scalar Value
32
xUnit Meta-model
Named Element
Test Suite
Test Suite
Test Case
*
Test Case
Assertion
*
Complex Value Assertion
type: String
* ExpectedValue DataValue
Scalar Value * *
Method * Parameter Complex Value
*
OwnerClass *
* Scalar Value
33
SMC Model
Methods
readCard( )
readPIN( )
makeTransaction( )
performTransaction( )
ejectCard ( )
34
xUnit Model
Assertions
readCard
readPIN
makeTransaction
performTransaction
ejectCard
35
Get documents about "