CSC7302: Overview
Module Director: Jean-Luc Raffy
Joint Teaching:
•Paul Gibson
•Jean-Luc Raffy
Web Site:
http://www-public.int-evry.fr/~gibson/Teaching/CSC7302/
Evaluation: single examination 3 hours (1st December)
November 2011
CSC7302: Testing & Metrics
1
CSC5021: calendar
My Sessions (all PBL-driven)
•Session 1: Tuesday 8th November – Introduction and Hangman PBL
•Session 2: Thursday 10th November – Refactoring and Auto-restructuring (OO metrics)
•Session 3: Tuesday 15th November – Integration Testing & Regression Testing (OO)
•Session 4: Wednesday 16th November – Advanced Testing Techniques (Auto test generation)
These will be interdependent
PBL will help us identify holes in
your knowledge
Jean-Luc
•Metrics and Software Quality
•How good are your tests (coverage etc…?)
•Limits to Testing
•Black box versus White box
•Tests and Documentation
•Tests and Maintenance
•…?
November 2011
CSC7302: Testing & Metrics
Wed 9th Nov(pm), Mon 14th (pm),
Mon 21st (pm),
Tue 22nd(pm) – to be decided,
Thur 1st Dec (am) – exam
2
Some Previous Work You (May) Need To Revisit
1.
2.
3.
4.
5.
Life Cycle: Chaos versus Organised versus Agile
Test Driven Development
UML & Tests
JUnit
Metrics Examples
This module will examine all of these things in more detail
November 2011
CSC7302: Testing & Metrics
3
November 2011
CSC7302: Testing & Metrics
4
November 2011
CSC7302: Testing & Metrics
5
November 2011
CSC7302: Testing & Metrics
6
Move To Agile?
November 2011
CSC7302: Testing & Metrics
7
All of the most popular Agile methods place importance on testing,
and are closely related to test-driven development (TDD):
•Scrum
•Lean Development
•Extreme programming (XP)
•Adaptive Software Development (ASD)
•Agile Modeling
• Crystal Methods
• Dynamic System Development Methodology (DSDM)
•Feature Driven Development
The (implicit) design places importance on refactoring, often
in order to improve the software metrics
November 2011
CSC7302: Testing & Metrics
8
Test Driven Development
November 2011
CSC7302: Testing & Metrics
9
Testing Consistency
Tests are the main way of maintaining consistency in the
documentation/models:
•Natural Language Text (English/French)
•(UML) models
•(Java) Code
•Comments in (Java) Code
If you do not develop tests in parallel with code you risk having widespread
inconsistency that is difficult to fix (particularly in large projects with lots of
team members working on different phases of the development).
NOTE: testing after all the code is developed is usually a bad idea; but it is better
than no testing at all!
November 2011
CSC7302: Testing & Metrics
10
UML & Tests
A key principle with testing is that the tests should be derived from (and be
consistent with) the requirements specification.
The UML diagrams should help us because:
•if our tests are consistent with the UML then – provided the UML is validated
against the informally expressed needs of the client – we have a good chance of
properly testing the system against what is really required by the
client/customer
•the structure of the UML should correspond to the structure of the developed
code – it is a bridge between what is required and how it is to be implemented
– so we can re-use this design structure to structure our tests.
November 2011
CSC7302: Testing & Metrics
11
UML – the diagrams
–
Use Case Diagrams
–
Class Diagrams & Sequence/Communication Diagrams
•
•
•
–
–
ValidationTests
test associations/aggregations
– multiplicity
– creation, destruction
sequencing
– Flow control / threads
exceptions
Class diagrams (detailed)
State Machine Diagrams
November 2011
CSC7302: Testing & Metrics
Integration Tests
Unit Tests
12
Validation
Use Case Diagrams – for each use case examine possible scenarios, and choose a
subset for testing. For example:
Use case1
A1
Use case2
Use case3
A2
Use case4
A3
November 2011
CSC7302: Testing & Metrics
13
Integration: the most difficult
Big Bang – system validation – « if the system works then it must be properly
integrated? »
Test at the system interface
MAIN PROBLEMS:
•Testing produces errors, but what caused them?
•Testing misses bugs
•Testing starts after all components are coded
November 2011
CSC7302: Testing & Metrics
14
Integration
Top Down– test all interactions between components (from root to leaves).
Possible integration test
sequence
1
2
5
3
4
7
8
6
NOTES:
•In reality, one will execute many different tests for each branch of the tree.
•Top Down integration is usually performed breadth first or depth first.
November 2011
CSC7302: Testing & Metrics
15
Integration
Top Down– the need for stubs
In top down testing, we may start the tests before all components are coded. In
such a case, we may have to write stubs – pieces of dummy code that simulate
behaviour that is not yet coded. In OO, stubs simulate called methods.
NOTE: When code for other lower level components is completed, the relevant
stubs are no longer needed.
To execute an integration test on branch1 we may
have to simulate method calls between C and lower
level components that are not yet implemented.
S
1
C
2
For example, if SC2 is not yet coded we create a stub
(dummy code) which simulates the method call
between C and SC2
8
stub
SC1
SC22
November 2011
SC3
CSC7302: Testing & Metrics
16
Integration
Bottom-Up– test all interactions between components (from leaves to root).
Possible integration test
sequence
8
7
1
3
6
4
5
2
NOTES:
•In reality, one will execute many different tests for each branch of the tree.
•Bottom Up integration is usually performed breadth first or depth first.
November 2011
CSC7302: Testing & Metrics
17
Integration
Bottom-Up– the need for drivers
In bottom up testing, we may start the tests before all components are
coded. In such a case, we may have to write drivers– pieces of dummy code
that simulate behaviour that is not yet coded. In OO, drivers simulate
calling methods
NOTE; When code for other higher level components is completed, the
relevant drivers are replaced.
C
For example, to execute an integration test on
branches 7 and 4 we may have to simulate method
calls from C (which is not yet coded) to SC1 and SC2.
5
driver
SC1
November 2011
SC2
SC3
So, we create a driver (dummy code) which simulates
the sequence of method calls from C to SC1 and SC2.
CSC7302: Testing & Metrics
18
Unit Tests
November 2011
CSC7302: Testing & Metrics
19
Unit Test Tool Support
Always check if there unit test tool support for
your favourite languages/IDEs, eg: Java/Eclipse
November 2011
CSC7302: Testing & Metrics
20
Metrics Tool Support
Always check if there is a metrics tool support for your favourite
languages/IDEs, eg: Java/Eclipse
November 2011
CSC7302: Testing & Metrics
21
PBL Session – Hangman (See next set of slides)
November 2011
CSC7302: Testing & Metrics
22