Testing
Reda Bendraou
reda.bendraou{{@}}Lip6.fr
http://pagesperso-systeme.lip6.fr/Reda.Bendraou/
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 1/57
Some slides were adapted from L. Osterweil, B. Meyer, and P.
Müller material
© Reda Bendraou
Hi Level
Code
Code must
implement
design
Low
level
consistent
views
Design
Focus on “How do you
know”
Requirements Spec.
Characteristics of
System to be
built must
match required
characteristics
Hi level design must
show HOW requirements
can be met
Test Results must
match required behavior
Test plan
exercises
this code
Test Plan
Safety
Test
implements
describes
Testing
Outputs
Accuracy
Robustness
Requirements
Functional
Performance
Inputs
Expected
Result
compare
Setup
Test input/output
behavior must
match functional
requirements
Testplan
Result
Program
Knockdown
equals
Cours 5: Les Tests 4/57
Test succeeds
LI386-S1 Génie Logiciel – UPMC
Test fails
different
Specification
Timing
Timing limit
must meet
performance
requirement
© Reda Bendraou
© Reda Bendraou
Testing issues
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 5/57
Testing : Validation
Vérification/proof
testing
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 6/57
does the product meet the spec?
E.W. Dijkstra, 1970, Structured Programming and a few other places
“Testing can only show the presence of errors never their absence!”
validation
© Reda Bendraou
Testing : problem
• We can’t afford to test everything and at anytime
– We have to make choices about what to test and with which input
values
Cours 5: Les Tests 7/57
• Proving that a program is bug free is an undecidable
(indeterminate) problem
– Need to define some realistic heuristics
• To test a software is to try to make it fail
LI386-S1 Génie Logiciel – UPMC
– Software fails => Test successful!
© Reda Bendraou
Testing : costs
Implem.
Test
Testing cost in development processes
Design
Analysis
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 8/57
+ maintenance = 80 % of global development cost!!!
© Reda Bendraou
Why
© Reda Bendraou
Testing : costs
Cost
Effort
Trust
LI386-S1 Génie Logiciel – UPMC
Testing
Cours 5: Les Tests 9/57
• 30% students first job/experience is about testing
Cours 5: Les Tests 10/57
• 50% of start-ups collapse because they deliver software with
a lot of bugs
LI386-S1 Génie Logiciel – UPMC
– Bad test campaign
– No “no regression” testing
– Bad maintenance
© Reda Bendraou
Failure?
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 11/57
From P. Müller
• A failure=>any event of system’s execution that violates a stated
quality objective
• Quality is the absence of “deficiencies “ (bugs)
© Reda Bendraou
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 12/57
When and how Quality can be achieved
At any time
© Reda Bendraou
Maintenance
Cours 5: Les Tests 13/57
When and how Quality can be achieved
Intergation tests
?
Code
LI386-S1 Génie Logiciel – UPMC
System
Integration
Delivery tests
(with client)
system
Tests
Integration
Tests
Unitary
Tests
V cycle
Cours 5: Les Tests 14/57
Modules
System’s test plan (functional)
Software delivery to the C.
Test hierarchy
LI386-S1 Génie Logiciel – UPMC
• How (for a posteriori)
© Reda Bendraou
Problem statement
Requirements
Design
Advanced Design
© Reda Bendraou
Test hierarchy
Unit/Module
Comparing a code unit or module with design specifications.
planned during coding: done after coding
Integration
Systematic combination of software components and modules
planned during design: done after unit/module V&V
Software System
Comparing entire software system with requirements
planned during requirements: done after integration
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 15/57
System
Comparing integrated hardware/software system to requirements
planned during informal requirements: after SW System
© Reda Bendraou
Testing: basic concepts
Implementation Under Test (IUT)
The software (& possibly hardware) elements to be tested
Cours 5: Les Tests 16/57
Test case
Precise specification of one execution intended to uncover a
possible fault:
• Required state & environment of IUT before execution
• Inputs
Test run
One execution of a test case
LI386-S1 Génie Logiciel – UPMC
Test suite
A collection of test cases
© Reda Bendraou
Testing: basic concepts
Returned values
Exceptions
Resulting state of program & environment
Non-functional characteristics (time, memory…)
Messages
Expected results (for a test case)
Precise specification of what the test is expected to yield in the absence of a
fault
fault:
•
•
•
•
•
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 17/57
Test oracle
A mechanism to determine whether a test run satisfies the expected results
Output is generally just “pass” or “fail”.
© Reda Bendraou
Testing: basic concepts
Test driver
A program, or program element (e.g. class), used to apply test cases to
an IUT
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 18/57
Stub
A temporary implementation of a software element, replacing its actual
implementation during testing of other elements relying on it.
Generally doesn’t satisfy the element’s full specification.
May serve as placeholder for:
• A software element that has not yet been written
• External software that cannot be run for the test (e.g.
• because it requires access to hardware or a live database)
• A software element that takes too much time or memory to
• run, and whose results can be simulated for testing purposes
© Reda Bendraou
Test Classification
By intent
Maintenance
Cours 5: Les Tests 19/57
Fault-directed testing
Goal: reveal faults through failures
Unit and integration testing
Conformance-directed testing
Goal: assess conformance to required capabilities
System testing
Acceptance testing
Goal: enable customer to decide whether to accept a
product
Regression testing
Goal: Retest previously tested element after changes, to
assess whether they have re-introduced faults or
uncovered new ones.
Mutation testing
Goal: Introduce faults to assess test case quality
LI386-S1 Génie Logiciel – UPMC
System Tests
Integration Tests
Unitary Tests
By Goal
• Functional test
• Performance test
• Stress (or “load”) test
By scope
Structural
Testing
Functional Testing
© Reda Bendraou
Intergation tests
?
Code
LI386-S1 Génie Logiciel – UPMC
System
Integration
Delivery tests
(with client)
system
Tests
Integration
Tests
Unitary
Tests
V cycle
Cours 5: Les Tests 20/57
Modules
System’s test plan (functional)
Software delivery to the C.
Test Classification : by process
Problem statement
Requirements
Design
Advanced Design
© Reda Bendraou
Cours 5: Les Tests 21/57
Test Classification : Black Vs white box
White-Box
- Source code (IUT) is used to define test
cases
LI386-S1 Génie Logiciel – UPMC
Black-box
- Properties of IUT available only through
specification , interfaces, etc.
- Typical use : integration
© Reda Bendraou
Testing: Process
• Identify parts of the software to be tested
• Identify interesting input values (next slide)
• Identify expected results (functional) and execution
characteristics (non-functional)
• Run the software on the input values
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 22/57
• Compare results & execution characteristics to expectations
© Reda Bendraou
How to identify interesting inputs?
• Need for realistic inputs, would not be feasible to test all values !!
• Partition testing: select elements from a partition of the input set, i.e. a set of
subsets that is
• Complete: union of subsets covers entire domain
• Pairwise disjoint: no two subsets intersect
• Purpose (or hope!):
• For any input value that produces a failure, some other in the same
subset produces a similar failure
Cours 5: Les Tests 23/57
• Common abuse of language: “a partition” for “one of the subsets in the partition” • Better called “equivalence class (ec)”
LI386-S1 Génie Logiciel – UPMC
• Each ec should at least be used by one test case
© Reda Bendraou
How to identify interesting inputs?
Ideas for equivalence classes:
• Set of values so that if any is processed correctly (incorrectly) then
any other will be processed correctly (incorrectly)
• Values at the center of a range, e.g. 0, 1, -1 for integers
• Boundary values, e.g. MAXINT
• Values known to be particularly relevant
Cours 5: Les Tests 24/57
• Values that must trigger an error message (“invalid”)
LI386-S1 Génie Logiciel – UPMC
• Intervals dividing up range, e.g. for integers
© Reda Bendraou
Test Quality: notion of Coverage?
Goal: to assess the effectiveness of a test suite,
=>Measure how many instructions in your program are reached
(executed) by your test.
How it works:
• Choose a kind of program element, e.g. instructions (instruction
coverage) or paths (path coverage)
• Count how many are executed at least once
• Report as percentage
Cours 5: Les Tests 25/57
100% coverage achieved by a test suite => every instruction in the
element tested has been executed at least by one test
LI386-S1 Génie Logiciel – UPMC
Known tools: Emma, Jcoverage, Ncover..etc
© Reda Bendraou
Coverage criteria
Instruction (or: statement) coverage:
Measure instructions executed
Disadvantage: insensitive to some control structures
Branch coverage:
Measure conditionals whose paths are both executed
Condition coverage:
Count how many atomic boolean expressions evaluates to both
true and false
Path coverage:
Count how many of the possible paths are taken
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 26/57
(Path: sequence of branches from routine entry to exit)
© Reda Bendraou
Test Quality: Mutation testing
Creation of tests still poses the question whether the tests are
correct and sufficiently cover the requirements that have originated
the implementation.
• "Quis custodiet ipsos custodes?" ["Who will guard the guards?"].)
• In our case, who tests the tester?
Mutation testing !
Cours 5: Les Tests 27/57
Idea: make small changes to the program source code (so that the modified
versions still compile) and see if your test cases fail for the modified versions
LI386-S1 Génie Logiciel – UPMC
Purpose: estimate the quality of your test suite
© Reda Bendraou
What it is Mutation testing?
if a mutant is introduced without the behavior (generally output) of the
program being affected this indicates:
- The code that had been mutated was never executed (dead code)
- The test suite was unable to locate the faults represented by the mutant.
Mutants are based on well-defined mutation operators
- mimic typical programming errors (ex. using the wrong operator or variable
name)
- force the creation of valuable tests (ex. dividing each expression by zero).
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 28/57
Disadvantage
- A large number of mutants usually are introduced into a large program,
- Requires the compilation and execution of an extremely large number of
copies of the program.
© Reda Bendraou
© Reda Bendraou
Cours 5: Les Tests 29/57
Mutants: example
LI386-S1 Génie Logiciel – UPMC
Mutation: some concepts
A mutant is the result of an application of a mutation operator
Faulty versions of the program = mutants
A mutant is Killed if at least one test case detects the fault injected into the
mutant, Alive otherwise
Mutation operator: a rule that specifies a syntactic variation of the program text so
that the modified program still compiles
The quality of the mutation operators determines the quality of the mutation testing
process.
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 30/57
Mutation operator coverage (MOC): For each mutation operator, create a mutant
using that mutation operator.
© Reda Bendraou
Cours 5: Les Tests 31/57
Mutation Operators: Examples
• Replace arithmetic operator by another
• Replace relational operator by another
• Replace logical operator by another
• Replace a variable by another
• Replace a variable (in use position) by a constant
• Replace a constant by another
• Replace “while… do…” by “repeat… until…”
• Replace condition of test by negation
LI386-S1 Génie Logiciel – UPMC
• Replace call to a routine by call to another
© Reda Bendraou
Testing: How to proceed?
 Defining the process
 Test plan (next slides)
 Input and output documents
 Who is testing?
 Developers / special testing teams / customer
Cours 5: Les Tests 32/57
 What test levels do we need?
 Unit, integration, system, acceptance, regression
 Order of tests
 Top-down, bottom-up, combination
LI386-S1 Génie Logiciel – UPMC
 Running the tests
 Manually
 Use of tools
 Automatically
© Reda Bendraou
Test Plans and Test Planning
• Goal: Determine if the product satisfies the requirements that
spawned its development
• Testing is done after the product is built
• Test planning commences during requirements
Testing can require elaborate harnesses
Testing difficulties can shape product requirements
Testing effort can be saved by static analysis
Make sure your requirements are Testable !!
• Best to plan it out
– Testing can be an elaborate process
–
–
–
–
Design of a Test Plan
• Structure
– Possibly a tree-like hierarchy of Test plan Element Specifications
(TES)
– One TES for each function, or functional aspect to be tested
• Function identification
• Testing goals
• Summary of Resources required
– Time
– People
– Equipment
– Other software systems
• Available or to-be-built
• Evaluation approach: Is this worth the cost?
Example Structure of a
Testplan Element Specification
Some Kinds of Test Element Goals
• Goals/Requirements for this test case
• Requirements element (e.g. function) or aspect (e.g. security) being tested
• Needed resources (e.g. databases, users, computers, software)
• Setup procedure
• Input data, which may be
– fixed, randomly selected, selected from a list
• Output results required
– Speed required
– Definition of what is “correct” output
• fixed number, range, formula
• Response to failure(s)
• Cleanup/knockdown
• Evaluation: turning this data into information, maybe into knowledge.
•
•
•
•
Is the functionality correct?
Does the software execute fast enough?
Is the software easy enough to use to satisfy a particular class of
stakeholders?
Does the software “fail safe” under certain specific
circumstances?
Some test plan elements can potentially test more than one of these
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 37/57
What kind of properties to test?
• Functional
• Security/Safety
• Usability
• Consistency
• Performance
• Robustness
© Reda Bendraou
Who Tests?
Any significant project should have a separate Quality Analysis team
Cours 5: Les Tests 38/57
Unit tests: the developers
Suggestion: pair each developer with another who serves as
“personal tester”
Integration test: developer or QA team
System test: QA team
LI386-S1 Génie Logiciel – UPMC
Acceptance test: customer & QA team
© Reda Bendraou
© Reda Bendraou
From B. Meyer and P. Muller
Cours 5: Les Tests 39/57
Error life cycle: example
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 40/57
What about Standards?
IEEE 829
IEEE Standard for Software Test Documentation, 1998
Can be found at: http://tinyurl.com/35pcp6
(shortcut for: http://www.ruleworks.co.uk/testguide/documents/
IEEE%20Standard%20for%20Software%20Test%20Documentation..pdf)
Specifies a set of test documents and their form
LI386-S1 Génie Logiciel – UPMC
For an overview, see the Wikipedia entry
© Reda Bendraou
IEEE-829: Test elements
Test plan:
“Prescribes scope, approach, resources, & schedule of testing. Identifies items & features to test, tasks to perform, personnel responsible for each
task, and risks associated with plan”
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 41/57
Test specification documents:
• Test design specification: identifies features to be covered by tests,
constraints on test process
• Test case specification: describes the test suite
• Test procedure specification: defines testing steps
Test reporting documents:
• Test item transmittal report
• Test log
• Test incident report
• Test summary report
© Reda Bendraou
Cours 5: Les Tests 42/57
IEEE 829: Test plan structure
LI386-S1 Génie Logiciel – UPMC
a) Test plan identifier
b) Introduction
c) Test items
d) Features to be tested
e) Features not to be tested
f) Approach
g) Item pass/fail criteria
h) Suspension criteria and resumption
requirements
i) Test deliverables
j) Testing tasks
k) Environmental needs
l) Responsibilities
m) Staffing and training needs
n) Schedule
o) Risks and contingencies
p) Approvals
© Reda Bendraou
LI386-S1 Génie Logiciel – UPMC
Maintenance
Cours 5: Les Tests 43/57
Let’s zoom in the different kinds of tests
© Reda Bendraou
Intergation tests
?
Code
LI386-S1 Génie Logiciel – UPMC
System
Integration
Delivery tests
(with client)
system
Tests
Integration
Tests
Unitary
Tests
V cycle
Cours 5: Les Tests 44/57
Modules
System’s test plan (functional)
Software delivery to the C.
Test Classification : Reminder
Problem statement
Requirements
Design
Advanced Design
© Reda Bendraou
V2
Cours 5: Les Tests 45/57
Validation
Req. Spec
Or the « spiral » life cycle
Early design
Advanced Design
V1
Integration
LI386-S1 Génie Logiciel – UPMC
Implementation
© Reda Bendraou
Unit Testing
• To validate a module independently of the others
Cours 5: Les Tests 46/57
• To validates the different functions/operations intensively
• Are the functions /operations ok?
LI386-S1 Génie Logiciel – UPMC
• Is the code readable? maintainable ?
© Reda Bendraou
- item: String
- next
0..1
Node
Unit Testing
0..1
- previous
Cours 5: Les Tests 47/57
+ Node()
+ isFirst()
+ isLast()
LI386-S1 Génie Logiciel – UPMC
• In OO programming
– Unit= class
© Reda Bendraou
Integration Testing
Cours 5: Les Tests 48/57
• Continuously testing the behavior of the system every time a
new module is integrated
LI386-S1 Génie Logiciel – UPMC
• Issue: choosing the right integration order!
© Reda Bendraou
NATIVE_C
DEFERRED_FUNCTION
DEFERRED_PROCEDURE
NATIVE_SMALL_EIFFEL
NATIVE_JVM
ONCE_PROCEDURE
ONCE_FUNCTION
Cours 5: Les Tests 49/57
Integration Testing
- Simple case: no cycles in modules
dependencies
LI386-S1 Génie Logiciel – UPMC
- Dependencies form a Tree and the
integration is done in a bottom-up way
© Reda Bendraou
CALL
E_DEBUG
FEATURE_NAME
+ is_frozen : Boolean
+base_class
WRITABLE_ATTRIBUTE
CST_ATT
+names
CREATION_CLAUSE
FEATURE_NAME_LIST
+procedure_list
+list
SIMPLE_FEATURE_NAME
FROZEN_FEATURE_NAME
INFIX_NAME
PREFIX_NAME
+base_class
+creation_clause_list
+base_class +base_class
NAME
BASE_CLASS
+ path
: String
+ is_manifest_string
: Boolean
+ is_deferred : Boolean
+ is_result : Boolean
+ is_expanded : Boolean
+ is_void : Boolean
/+ is_generic : Boolean
+ is_any : Boolean = initval
+ is_general : Boolean
+origin_base_class
(from InheritanceClause)
(from InheritanceClause)
EXPORT_ITEM
RENAME_PAIR
FEATURE_NAME_LIST
FORMAL_GENERIC_ARG
+ +constraint
constrained : boolean
+ rank : Integer
+current_type
TYPE
/ path : String
+generic_list
(from InheritanceClause)
+export_list
+rename_list
+undefine_list
+parent_list
PARENT_LIST
PARENT
(from InheritanceClause)
+formal_generic_list
+list
FORMAL_GENERIC_LIST
(from TYPE)(from TYPE)(from TYPE)
+formal_generic_list
TYPE_GENERIC
TYPE_FORMAL_GENERIC
TYPE_CLASS
TYPE_CHARACTER
TYPE_ANY
TYPE_NONE
TYPE_POINTER
Cours 5: Les Tests 50/57
+redefine_list
+select_list
CREATION_CLAUSE_LIST
FEATURE_NAME
EXPRESSION
+base_class_dictionary
+base_class
+list
SMALLEIFFELFEATURE_CLAUSE
: Integer
LOCAL_NAME
ARGUMENT_NAME + magic_count +list
TYPE+ is_ready : Boolean
+result_type
+ load_class()
+ get_started()
+clientsTYPE
+name_list+to_runnable
+ falling_down()
+clients
+result_type
+ afd_check()
CLIENT_LIST
+name
FEATURE_CLAUSE_LIST
LOCAL_ARGUMENT
CLASS_NAME
+list
CLASS_NAME
+feature_clause_list
+result_type
EXPRESSION
CALL_PROC_CALL
GLOBALS
1
+writable
1
DECLARATION_GROUP
DECLARATION_1
+target
0..*
+arguments
E_INSPECT
WHEN_LIST
E_WHEN
WHEN_ITEM
LOCAL_VAR_LIST
ATTRIBUTE
ROUTINE
REVERSE_ASSIGNMENT
EXPRESSION
WHEN_ITEM_1
CREATION_CALL
PROC_CALL
ASSIGNMENT
+call
+type
E_FEATURE
DECLARATION
+ is_deferred : Boolean = initval
TYPE
FORMAL_ARG_LIST
+ count : Integer DECLARATION_LIST
E_LOOP
EFFECTIVE_ROUTINE
DEFERRED_ROUTINE
EXTERNAL_ROUTINE
+nativeNATIVE
+then_compound
ONCE_ROUTINE
PROCEDURE
FUNCTION EXTERNAL_FUNCTION
EXTERNAL_PROCEDURE
COMPOUND
IFTHENELSE
IFTHEN
INSTRUCTION
E_CHECK
E_RETRY
Integration Testing
- Worst case: presence of cycles between
modules dependencies
- Often the case in OO design
LI386-S1 Génie Logiciel – UPMC
- Need to define heuristics to find the best
integration order
© Reda Bendraou
System Testing
• To validate the global behavior of the system
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 51/57
– Check the that functionalities meet the requirements spec.
– Check in the interfacing with other systems
– Check the GUI
© Reda Bendraou
No-regression testing
• The purpose of non-regression testing is to verify whether,
after introducing or updating a given software application,
the change has had the intended effect
– What worked before, still works fine!
• Usually in maintenance phase
Cours 5: Les Tests 52/57
– After refactoring, adding/deleting a functionality
LI386-S1 Génie Logiciel – UPMC
• After the correction of an error/bug
© Reda Bendraou
© Reda Bendraou
Unit Testing
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 53/57
Unit Testing in OO
• Testing a unit independently of the others
A unit=> Class
• It’s a Client’s point of view code
– Test Plans call methods to be tested from the outside (external client)
– Only public methods can be tested (or use reflection)
• Hints for testing private methods:
http://www.artima.com/suiterunner/privateP.html
– Testing a class, is done by an external class
• At least one test by public method
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 54/57
• Need to define a test order!!
– What are the dependencies between the methods?
© Reda Bendraou
• Test case= a method
• Body of the method
– Initial configuration
– Test data
Unit test case
• Parameters used to test the method
– An oracle
Cours 5: Les Tests 55/57
•Test adding an element to
an empty list
•Test deleting an element
from a list
•Test deleting the last
element of a list
•Etc….
• Specify the expected result
• Or check some properties on the expected result
LI386-S1 Génie Logiciel – UPMC
• One test class for each class to be tested
– Regroup all test cases for the class
© Reda Bendraou
0..1
- next
Example
Node
- item: String
+ Node()
+ isFirst(): boolean
+ isLast(): boolean
- previous
0..1
Cours 5: Les Tests 56/57
How to write these tests?
How to execute them?
Are they good?
Is it enough tested?
...
LI386-S1 Génie Logiciel – UPMC
- FirstNode
0..1
0..1
- CurrentNode
0..1
- LastNode
How to test StringList?
StringList
StringList()
add(it: String)
insert(it: String)
item(): String
next()
previous()
remove()
replace(it: String)
size(): int
- count: int
+
+
+
+
+
+
+
+
+
© Reda Bendraou
- FirstNode
0..1
0..1
- CurrentNode
0..1
- LastNode
+ Node()
+ isFirst(): boolean
+ isLast(): boolean
- item: String
Node
0..1
- previous
0..1
- next
Example : testing the StringList class
StringList
StringList()
add(it: String)
insert(it: String)
item(): String
next()
previous()
remove()
replace(it: String)
size(): int
- count: int
+
+
+
+
+
+
+
+
+
Cours 5: Les Tests 57/57
- Create a test class to manipulate StringList class’s instances LI386-S1 Génie Logiciel – UPMC
- One test case by each public method
© Reda Bendraou
Tests: abstraction levels
– Abstract test cases: you can use UML Sequence diagrams
• Goal: to start reasoning about tests in earlier development phases
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 58/57
– Executable test cases : use of x-unit framework to concretely
execute tests
© Reda Bendraou
© Reda Bendraou
© Reda Bendraou
Cours 5: Les Tests 59/57
Abstract Test Cases
LI386-S1 Génie Logiciel – UPMC
Application & Test
Test cases
Abstract
Executable
Spec
Application
Application
Test Cases
Cours 5: Les Tests 60/57
Code
LI386-S1 Génie Logiciel – UPMC
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 61/57
Cours 5: Les Tests 62/57
Executable test cases
LI386-S1 Génie Logiciel – UPMC
Abtract Test Case: Example
test of StringList- the insert() method
© Reda Bendraou
© Reda Bendraou
• Origin
JUnit
Cours 5: Les Tests 63/57
– Xtreme programming (test-first development)
– Java framework by E. Gamma et K. Beck
– open source: www.junit.org
• Goals
LI386-S1 Génie Logiciel – UPMC
– Testing Java applications
– Non-Regression testing
© Reda Bendraou
StringList
StringList()
add()
insert()
item()
next()
previous()
remove()
replace()
size()
- count: int
+
+
+
+
+
+
+
+
+
Test case
specification
- LastNode
0..1
- CurrentNode
0..1
0..1
- FirstNode
Node
- item: String
+ Node()
+ isFirst()
+ isLast()
- previous
0..1
- next
0..1
Executable test case
Testing StringList- the insert() method
Intention
initialisation
Cours 5: Les Tests 64/57
//first test for insert: call insert and see if
//current element is the one that's been inserted
public void testInsert1(){
StringList list = new StringList();
list.add("first");
list.add("second");
list.insert("third");
assertTrue(list.size()==3);
assertTrue(list.item()=="third");
LI386-S1 Génie
} Logiciel – UPMC
oracle
Call with a data
© Reda Bendraou
Conclusion
• Its a domain by its own! Very important field of research
• Very important in the development life cycle
• Each phase has its own tests
–
–
Cours 5: Les Tests 65/57
• Unit testing
– Unfortunately doesn’t cover all the possibilities
– Increase customer’s trust in the application
– Even if you cover 99% , the 1% left can be source a damageable bug!!!
LI386-S1 Génie Logiciel – UPMC
Software Engineering,
© Reda Bendraou
•
The Mythical Man-Month
Lectures
•
Cours de Software Engineering du Prof. Bertrand Meyer à cette @:
–
http://public.enst-bretagne.fr/~beugnard/
http://se.ethz.ch/teaching/ss2007/252-0204-00/lecture.html
Frederick P. Brooks JR., Addison-Wesley, 1995
Ian Sommerville, Addison Wesley; 8 edition (15 Jun 2006), ISBN-10: 0321313798
•
Cours d’Antoine Beugnard à cette @:
–
•
Martin Fowler, Addison-Wesley Object Technology Series, 2003, ISBN-10: 0321193687
UML2 pour les développeurs, cours avec exercices et corrigés
–
----------------------• UML Distilled 3rd édition, a brief guide to the standard object modeling language
•
UML 2 par la pratique, études de cas et exercices corrigés,
–
–
http://www.irisa.fr/prive/jezequel/enseignement/PolyUML/poly.pdf
Pascal Roques, 6ème édition, Edition Eyrolles, 2008
Xavier Blanc, Isabelle Mounier et Cédric Besse, Edition Eyrolles, 2006, ISBN-2-212-12029-X
•
Cours très intéressant du Prof. Jean-Marc Jézéquel à cette @:
–
•
Richard Helm (Auteur), Ralph Johnson (Auteur), John Vlissides (Auteur), Eric Gamma (Auteur), Vuibert
informatique (5 juillet 1999), ISBN-10: 2711786447
LI386-S1 Génie Logiciel – UPMC
Cours 5: Les Tests 66/57
Cours sur les tests est basé sur les Cours très complets et bien faits de Yves le Traon et Benoit Baudry
–
• La page de l’OMG dédiée à UML: http://www.uml.org/
-----------------------• Design patterns. Catalogue des modèles de conception réutilisables
•
© Reda Bendraou