Test Design:
Functional Testing
Daniel Sundmark
Outline
●
Functional Testing Basics
●
Systematic Functional Test Design
●
Input-Space Based Techniques
●
Equivalence Partitioning
●
Boundary Value Analysis
●
Combinatorial Testing
●
Random Testing
●
Model-Based Testing
Functional Testing Basics
●
Basic idea
: Test cases are derived based on the
functional specifications of the software under test
●
What does the specifications say that the software is
supposed to do?
●
What does the specifications say that the software is
not
supposed to do (if this is explicitly stated)?
●
Implementation of the software under test is not
considered in test case design
●
Hence, functional testing is also historically known as
Functional Testing Basics
●
Basic idea
: Test cases are derived based on the
functional specifications of the software under test
●
What does the specifications say that the software is
supposed to do?
●
What does the specifications say that the software is
not
supposed to do (if this is explicitly stated)?
●
Implementation of the software under test is not
considered in test case design
●
Hence, functional testing is also historically known as
Black-Box Testing
4
This term has been critizised
by several testing scholars,
since is claimed to represent
an old-fashioned view of
testing.
Nevertheless, the term is still
widely used.
A Systematic Approach to
Functional Test Design
Adapted from “Software Testing and Analysis”, (Pezzè and Young), and Saarland University course on Software Testing (Fraser and Zeller)
Functional specifications Independently testable aspects Representative values Model Test specifications Test cases IDENTIFY CREATE DERIVE DERIVE DERIVE IDENTIFY
This is a general approach that can be utilized at all levels of testing, but still needs to be adapted to the situation at hand and the software under test
A Systematic Approach to
Functional Test Design
Adapted from “Software Testing and Analysis”, (Pezzè and Young), and Saarland University course on Software Testing (Fraser and Zeller)
6 Functional specifications Independently testable aspects Representative values Model Test specifications Test cases IDENTIFY CREATE DERIVE DERIVE DERIVE IDENTIFY
As previously stated, the functional specifications is the starting point for functional test design
A Systematic Approach to
Functional Test Design
Adapted from “Software Testing and Analysis”, (Pezzè and Young), and Saarland University course on Software Testing (Fraser and Zeller)
Functional specifications Independently testable aspects Representative values Model Test specifications Test cases IDENTIFY CREATE DERIVE DERIVE DERIVE IDENTIFY
Based on the functional specification, independently testable aspects (ITAs)
are identified. An ITA is a part of the functionality of the software that can be tested separately from other functionalities. An important aspect of an ITA is its inputs.
A Systematic Approach to
Functional Test Design
Adapted from “Software Testing and Analysis”, (Pezzè and Young), and Saarland University course on Software Testing (Fraser and Zeller)
8 Functional specifications Independently testable aspects Representative values Model Test specifications Test cases IDENTIFY CREATE DERIVE DERIVE DERIVE IDENTIFY
Based on the functional specification, independently testable aspects (ITAs)
are identified. An ITA is a part of the functionality of the software that can be tested separately from other functionalities. An important aspect of an ITA is its inputs.
Also called
independently testable
features or functions.
A Systematic Approach to
Functional Test Design
Adapted from “Software Testing and Analysis”, (Pezzè and Young), and Saarland University course on Software Testing (Fraser and Zeller)
Functional specifications Independently testable aspects Representative values Model Test specifications Test cases IDENTIFY CREATE DERIVE DERIVE DERIVE IDENTIFY
The concept of an ITA is not terribly well-defined. Java methods or isolated C
functions are often given as examples, but ITAs exist on all levels of integration. For example, the withdrawal function of an ATM could be an ITA.
A Systematic Approach to
Functional Test Design
Adapted from “Software Testing and Analysis”, (Pezzè and Young), and Saarland University course on Software Testing (Fraser and Zeller)
10 Functional specifications Independently testable aspects Representative values Model Test specifications Test cases IDENTIFY CREATE DERIVE DERIVE DERIVE IDENTIFY
Based on the nature of the ITA, we may either proceed with identifying
representative values for input using different techniques, e.g.,
• Equivalence partitioning of the input space
• Boundary value analysis
A Systematic Approach to
Functional Test Design
Adapted from “Software Testing and Analysis”, (Pezzè and Young), and Saarland University course on Software Testing (Fraser and Zeller)
Functional specifications Independently testable aspects Representative values Model Test specifications Test cases IDENTIFY CREATE DERIVE DERIVE DERIVE IDENTIFY
Based on the nature of the ITA, we may either proceed with identifying
representative values for input using different techniques, e.g.,
• Equivalence partitioning of the input space
• Boundary value analysis
A Systematic Approach to
Functional Test Design
Adapted from “Software Testing and Analysis”, (Pezzè and Young), and Saarland University course on Software Testing (Fraser and Zeller)
12 Functional specifications Independently testable aspects Representative values Model Test specifications Test cases IDENTIFY CREATE DERIVE DERIVE DERIVE IDENTIFY
Based on the nature of the ITA, we may either proceed with identifying
representative values for input using different techniques, e.g.,
• Equivalence partitioning of the input space
• Boundary value analysis
• Different types of random selection
A Systematic Approach to
Functional Test Design
Adapted from “Software Testing and Analysis”, (Pezzè and Young), and Saarland University course on Software Testing (Fraser and Zeller)
Functional specifications Independently testable aspects Representative values Model Test specifications Test cases IDENTIFY CREATE DERIVE DERIVE DERIVE IDENTIFY
…we may even derive a test Model that describes (parts of ) the specification in a more formal way, and that helps us derive test cases
A Systematic Approach to
Functional Test Design
Adapted from “Software Testing and Analysis”, (Pezzè and Young), and Saarland University course on Software Testing (Fraser and Zeller)
14 Functional specifications Independently testable aspects Representative values Model Test specifications Test cases IDENTIFY CREATE DERIVE DERIVE DERIVE IDENTIFY
…we may even derive a test Model that describes (parts of ) the specification in a more formal way, and that helps us derive test cases
A Systematic Approach to
Functional Test Design
Adapted from “Software Testing and Analysis”, (Pezzè and Young), and Saarland University course on Software Testing (Fraser and Zeller)
Functional specifications Independently testable aspects Representative values Model Test specifications Test cases IDENTIFY CREATE DERIVE DERIVE DERIVE IDENTIFY
Based on the representative values, or/and the test model, test specifications are derived. Test specifications are abstract test requirements that must be met during testing.
A Systematic Approach to
Functional Test Design
Adapted from “Software Testing and Analysis”, (Pezzè and Young), and Saarland University course on Software Testing (Fraser and Zeller)
16 Functional specifications Independently testable aspects Representative values Model Test specifications Test cases IDENTIFY CREATE DERIVE DERIVE DERIVE IDENTIFY
As a last step in the test design process, we create test cases that meet the test specifications
A Systematic Approach to
Functional Test Design
Adapted from “Software Testing and Analysis”, (Pezzè and Young), and Saarland University course on Software Testing (Fraser and Zeller)
Functional specifications Independently testable aspects Representative values Model Test specifications Test cases IDENTIFY GENERATE DERIVE DERIVE DERIVE IDENTIFY
As a last step in the test design process, we generate test cases that meet the test specifications
Again, note here that a
test case not only
requires an
input
, but
also an
expected
output
in order to be
able to provide a verdict.
The expected output is
typically derived based
on the specifications
Let’s go back to the more technical parts…
Techniques based on partitioning of the input space
Identifying representative
values
Functional specifications Independently testable aspects Representative values Model Test case specifications Test cases IDENTIFY GENERATE DERIVE DERIVE DERIVE IDENTIFYInput Space
●
Each ITA has an input space, which
is made up of all possible input
combinations
● Simple example: a function fun(int x, int y)
has a two-dimensional input space made up of all possible values of input
parameters x and y
● Each test case input is a (x,y) pair, which
essentially corresponds to a unique point in the input space
20
x y
Equivalence Partitioning
Divide and conquer
x y
●
For
each
input parameter,
● Divide the input space of that parameter
into partition blocks based on some characteristic
● Within each block, the software under test
should behave ”equivalent” with respect to that parameter
● Then test inputs are chosen to cover all
blocks rather than the full input space
●
Fundamental rules for a partition p:
● All partition blocks within p must be disjoint
● The union of all partition blocks in p must
make up the complete input space
Basic idea:
Divide input space into blocks
within which the software should behave
similarly. Then just cover all possible blocks
Equivalence Partitioning
Divide and conquer
22
x y
●
For
each
input parameter,
● Divide the input space of that parameter
into partition blocks based on some characteristic
● Within each block, the software under test
should behave ”equivalent” with respect to that parameter
● Then test inputs are chosen to cover all
blocks rather than the full input space
●
Fundamental rules for a partition p:
● All partition blocks within p must be disjoint
● The union of all partition blocks in p must
x y
Equivalence Partitioning
Divide and conquer
●
For
each
input parameter,
● Divide the input space of that parameter
into partition blocks based on some characteristic
● Within each block, the software under test
should behave ”equivalent” with respect to that parameter
● Then test inputs are chosen to cover all
blocks rather than the full input space
●
Fundamental rules for a partition p:
● All partition blocks within p must be disjoint
● The union of all partition blocks in p must
24
x y
Equivalence Partitioning
Divide and conquer
●
For
each
input parameter,
● Divide the input space of that parameter
into partition blocks based on some characteristic
● Within each block, the software under test
should behave ”equivalent” with respect to that parameter
● Then test inputs are chosen to cover all
blocks rather than the full input space
●
Fundamental rules for a partition p:
● All partition blocks within p must be disjoint
● The union of all partition blocks in p must
Equivalence Partitioning
General Process
1.
For each ITA, identify all parameters that affect its
behavior. These make up the input space.
2.
Partition the input space based on a set of
characteristics. Strategies:
●
Individual partitioning of each input parameter
●
Functional (or even output-based) modeling of the
input space
3.
Combine the partitions into an input domain model.
●
In this step, identify and remove invalid
combinations
4.
Identify representative values
5.
Derive test cases by complementing with expected
Equivalence Partitioning
Example (Ammann and Offutt)
26
1.
For each ITA, identify all parameters
that affect its behavior. These make up
the input space.
2.
Partition the input space based on a set
of characteristics. Strategies:
– Individual partitioning of each input parameter – Functional (or even output-based) modeling of the
input space
3.
Combine the partitions into an input
domain model.
– In this step, identify and remove invalid combinations
4.
Identify representative values
5.
Derive test cases by complementing
with expected output
Let’s look at how this can be applied to the
Triangle categorization problem
Equivalence Partitioning
Example (Ammann and Offutt)
1.
For each ITA, identify all parameters
that affect its behavior. These make up
the input space.
2.
Partition the input space based on a set
of characteristics. Strategies:
– Individual partitioning of each input parameter – Functional (or even output-based) modeling of the
input space
3.
Combine the partitions into an input
domain model.
– In this step, identify and remove invalid combinations
4.
Identify representative values
5.
Derive test cases by complementing
with expected output
For the triangle
categorization problem,
these are the three input
integers representing its
sides. Let’s call them
x
,
y
Equivalence Partitioning
Example (Ammann and Offutt)
28
1.
For each ITA, identify all parameters
that affect its behavior. These make up
the input space.
2.
Partition the input space based on a set
of characteristics. Strategies:
– Individual partitioning of each input parameter – Functional (or even output-based) modeling of the
input space
3.
Combine the partitions into an input
domain model.
– In this step, identify and remove invalid combinations
4.
Identify representative values
5.
Derive test cases by complementing
with expected output
Partition b1 b2 b3
x Greater than 0 Equal to 0 Less than 0
y Greater than 0 Equal to 0 Less than 0
Equivalence Partitioning
Example (Ammann and Offutt)
1.
For each ITA, identify all parameters
that affect its behavior. These make up
the input space.
2.
Partition the input space based on a set
of characteristics. Strategies:
– Individual partitioning of each input parameter – Functional (or even output-based) modeling of the
input space
3.
Combine the partitions into an input
domain model.
– In this step, identify and remove invalid combinations
4.
Identify representative values
5.
Derive test cases by complementing
with expected output
Partition b1 b2 b3 b4
Geometric classification
Equivalence Partitioning
Example (Ammann and Offutt)
30
1.
For each ITA, identify all parameters
that affect its behavior. These make up
the input space.
2.
Partition the input space based on a set
of characteristics. Strategies:
– Individual partitioning of each input parameter – Functional (or even output-based) modeling of the
input space
3.
Combine the partitions into an input
domain model.
– In this step, identify and remove invalid combinations
4.
Identify representative values
5.
Derive test cases by complementing
with expected output
Partition b1 b2 b3 b4
Geometric classification
Equivalence Partitioning
Example (Ammann and Offutt)
1.
For each ITA, identify all parameters
that affect its behavior. These make up
the input space.
2.
Partition the input space based on a set
of characteristics. Strategies:
– Individual partitioning of each input parameter – Functional (or even output-based) modeling of the
input space
3.
Combine the partitions into an input
domain model.
– In this step, identify and remove invalid combinations
4.
Identify representative values
5.
Derive test cases by complementing
with expected output
Partition b1 b2 b3 b4
Geometric classification
Scalene Isosceles, not equilateral
Equivalence Partitioning
Example (Ammann and Offutt)
32
1.
For each ITA, identify all parameters
that affect its behavior. These make up
the input space.
2.
Partition the input space based on a set
of characteristics. Strategies:
– Individual partitioning of each input parameter – Functional (or even output-based) modeling of the
input space
3.
Combine the partitions into an input
domain model.
– In this step, identify and remove invalid combinations
4.
Identify representative values
5.
Derive test cases by complementing
Equivalence Partitioning
Example (Ammann and Offutt)
Partition
Geometric classification
Scalene Isosceles, not equilateral Equilateral Invalid
x Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0
y Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0
z Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0 Greater than 0
Equivalence Partitioning
Example (Ammann and Offutt)
Partition
Geometric classification
Scalene Isosceles, not equilateral Equilateral Invalid
x Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0
y Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0
z Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0
Equivalence Partitioning
Example (Ammann and Offutt)
Partition
Geometric classification
Scalene Isosceles, not equilateral Equilateral Invalid
x Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0
y Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0
z Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0 Greater than 0
Equal to 0 Less than 0
If we feel like testing inputs from all partition
combinations, we still have 30 different test cases
to worry about…
…hence, after the upcoming lab, we will look at
more feasible ways of combining input from
Equivalence Partitioning
Example (Ammann and Offutt)
36
1.
For each ITA, identify all parameters
that affect its behavior. These make up
the input space.
2.
Partition the input space based on a set
of characteristics. Strategies:
– Individual partitioning of each input parameter – Functional (or even output-based) modeling of the
input space
3.
Combine the partitions into an input
domain model.
– In this step, identify and remove invalid combinations
4.
Identify representative values
5.
Derive test cases by complementing
with expected output
We leave these for you to
think about…
Equivalence Partitioning
- Follow-Up Exercise
●
Consider a function
parArea(int x, int y, int z)
that,
given two sides
x
and
y
, and an angle
z,
of a
parallelogram, calculates its area.
●
Equivalence partitioning of inputs:
●
x:
●
Invalid: x<0, Valid: x>0
●
y:
●
Invalid: y<0, Valid: y>0
●
z:
●
Invalid1: z<0, Valid: 0<z<180, Invalid2: z>180
x
y
Equivalence Partitioning
- Follow-Up Exercise
38x
y
z
Question:
How to
handle boundary values?
●
Consider a function
parArea(int x, int y, int z)
that,
given two sides
x
and
y
, and an angle
z,
of a
parallelogram, calculates its area.
●
Equivalence partitioning of inputs:
●
x:
●
Invalid: x<0, Valid: x>0
●
y:
●
Invalid: y<0, Valid: y>0
●
z:
Boundary Value Analysis
●
Experience has shown that there is a higher chance of
finding defects at, or close to,
partition boundaries
●
Boundary value analysis strives to identify partition
boundaries and suitable test case input on, or just
outside or inside boundaries
Equivalence Partitioning
- additional (more difficult)
example should go here
(No integers)
Lab
EP lab
Example Partitions
●
Perfect game:
●
{Score=300} {Score!=300}
●
Strike
:
●
{game with strike}{game with no strike}
EP lab
Example Partitions
●
Perfect game:
●
{Score=300} {Score!=300}
●
Strike
:
EP lab
Example Partitions
●
Perfect game:
●
{Score=300} {Score!=300}
●
Strike
:
●
{game with strike}{not a game with strike}
EP lab
Some 2-minute sketch partitions
●
Perfect game:
●
{Score=300} {Score!=300}
●
Strike
:
●
{game with strike}{not a game with strike}
●
Null pointer:
●
{null}{not null}
●
Number of frames
:
●
{less than 10}{10}{11}{more than 11}
●
Spare
:
●
{game with spare}{game with no spare}
●
Syntax
:
Equivalence Partitioning
- System-level perspective
should go here
●
Many things can be partitioned
●
Configuration parameters
●
Devices
●
Time
Combining Input from
Partitions into Test Cases
●
Ideally, we want to test all
combinations.
●
In many cases, this is however not
feasible.
x y
Combining Input from
Partitions into Test Cases
Strategies
•
All combinations (already
covered in previous slide)
•
Each choice
•
Pair-wise (and T-wise)
•
Base choice
48
x y
Combining Input from
Partitions into Test Cases
Strategies
•
All combinations (already covered
in previous slide)
•
Each choice
•
Pair-wise (and T-wise)
•
Base choice
x y
Combining Input from
Partitions into Test Cases
Strategies
•
All combinations (already covered
in previous slide)
•
Each choice
•
Pair-wise (and T-wise)
•
Base choice
50
x y
Equivalence Partitioning
- Follow-Up Exercise
●
Consider a function
parArea(int x, int y, int z)
that,
given two sides
x
and
y
, and an angle
z,
of a
parallelogram, calculates its area.
●
Equivalence partitioning of inputs:
●
x:
●
Invalid: x<=0, Valid: x>0
●
y:
●
Invalid: y<=0, Valid: y>0
●
z:
●
Invalid1: z<=0, Valid: 0<z<180, Invalid2: z>=180
x
y
Combining Input from
Partitions into Test Cases
Strategies
•
All combinations (already covered
in previous slide)
•
Each choice
•
Pair-wise (and T-wise)
•
Base choice
52
x y
Input value selection
●
A Note:
It has been recommended that input values are given
as variables that can be randomly assigned within the
partition boundaries, rather than being hard-coded.
●
This however makes it a lot harder to determine the
Random Testing
●
There are some proponents of randomly generating
input data, at least as a final stage of testing
●
Considering the fact that a large percentage of defects
are due to missing requirements, that might not be a
bad idea
●
However, defects are not evenly distributed
●
80% of defects in 20% of software
●
Adaptive Random Testing
●
Other problems with random testing?
Model-Based Testing
Functional specifications Independently testable aspects Representative values Model Test specifications Test cases IDENTIFY GENERATE DERIVE DERIVE DERIVE IDENTIFYNot all ITAs are suitable for equivalence partitioning. Specifically, equivalence partitioning is poorly suited to cover sequences of input, for example use case scenarios.
Model-Based Testing
●
Basic idea:
●
The intended behaviour of the software under test is
modeled (more or less) formally
●
Typically, finite state machine models are used, but
many other types of models are possible
●
Test specifications (or test cases) derived or
automatically generated from the model
Model-Based Testing
Example
●
AEBS:
Advance Emergency Braking System
Disabled (Ignition Off)
Enabled Disabled by Driver Fully Operational (Normal Mode) Not Fully Operational AEBS MODES No Action Driver Override
AEBS NORMAL MODE OPERATION
Brake Assist Collision
Warning Full Brake Warning
Model-Based Testing
Example
●
AEBS:
Advance Emergency Braking System
58
Disabled (Ignition Off)
Enabled Disabled by Driver Fully Operational (Normal Mode) Not Fully Operational AEBS MODES No Action Driver Override
AEBS NORMAL MODE OPERATION
Brake Assist Collision
Warning Full Brake Warning
Brake
Test cases derived from graph-based specification models are often based on the rationale that all transitions between the states, or some specific scenarios (paths) should be exercised
during testing.
However, more complex criteria can naturally be applied…
Example- test specification generation
Prime path coverage of the AEBS normal mode operation graph
1. BRAKE ASSIST, DRIVER OVERRIDE, NO ACTION, COLLISION WARNING, BRAKE ASSIST,
2. BRAKE ASSIST, DRIVER OVERRIDE, NO ACTION, COLLISION WARNING, WARNING BRAKE, BRAKE ASSIST,
3. BRAKE ASSIST, DRIVER OVERRIDE, NO ACTION, COLLISION WARNING, WARNING BRAKE, FULL BRAKE,
4. COLLISION WARNING, BRAKE ASSIST, DRIVER OVERRIDE, NO ACTION, COLLISION WARNING,
5. COLLISION WARNING, DRIVER OVERRIDE, NO ACTION, COLLISION WARNING,
6. COLLISION WARNING, NO ACTION, COLLISION WARNING,
7. COLLISION WARNING, NO ACTION, DRIVER OVERRIDE,
8. COLLISION WARNING, WARNING BRAKE, BRAKE ASSIST, DRIVER OVERRIDE, NO ACTION, COLLISION WARNING,
9. COLLISION WARNING, WARNING BRAKE, DRIVER OVERRIDE, NO ACTION, COLLISION WARNING,
10. COLLISION WARNING, WARNING BRAKE, FULL BRAKE, DRIVER OVERRIDE, NO ACTION, COLLISION WARNING,
11. COLLISION WARNING, WARNING BRAKE, FULL BRAKE, NO ACTION, COLLISION WARNING,
12. COLLISION WARNING, WARNING BRAKE, FULL BRAKE, NO ACTION, DRIVER OVERRIDE,
13. COLLISION WARNING, WARNING BRAKE, NO ACTION, COLLISION WARNING,
14. COLLISION WARNING, WARNING BRAKE, NO ACTION, DRIVER OVERRIDE,
15. DRIVER OVERRIDE, NO ACTION, COLLISION WARNING, BRAKE ASSIST, DRIVER OVERRIDE,
16. DRIVER OVERRIDE, NO ACTION, COLLISION WARNING, WARNING BRAKE, BRAKE ASSIST, DRIVER OVERRIDE,
20. FULL BRAKE, DRIVER OVERRIDE, NO ACTION, COLLISION WARNING, BRAKE ASSIST,
21. FULL BRAKE, DRIVER OVERRIDE, NO ACTION, COLLISION WARNING, WARNING BRAKE, BRAKE ASSIST,
22. FULL BRAKE, DRIVER OVERRIDE, NO ACTION, COLLISION WARNING, WARNING BRAKE, FULL BRAKE,
23. FULL BRAKE, NO ACTION, COLLISION WARNING, BRAKE ASSIST, DRIVER OVERRIDE,
24. FULL BRAKE, NO ACTION, COLLISION WARNING, DRIVER OVERRIDE,
25. FULL BRAKE, NO ACTION, COLLISION WARNING, WARNING BRAKE, BRAKE ASSIST, DRIVER OVERRIDE,
26. FULL BRAKE, NO ACTION, COLLISION WARNING, WARNING BRAKE, DRIVER OVERRIDE,
27. FULL BRAKE, NO ACTION, COLLISION WARNING, WARNING BRAKE, FULL BRAKE,
28. NO ACTION, COLLISION WARNING, BRAKE ASSIST, DRIVER OVERRIDE, NO ACTION,
29. NO ACTION, COLLISION WARNING, DRIVER OVERRIDE, NO ACTION,
30. NO ACTION, COLLISION WARNING, NO ACTION,
31. NO ACTION, COLLISION WARNING, WARNING BRAKE, BRAKE ASSIST, DRIVER OVERRIDE, NO ACTION,
32. NO ACTION, COLLISION WARNING, WARNING BRAKE, DRIVER OVERRIDE, NO ACTION,
33. NO ACTION, COLLISION WARNING, WARNING BRAKE, FULL BRAKE, DRIVER OVERRIDE, NO ACTION,
34. NO ACTION, COLLISION WARNING, WARNING BRAKE, FULL BRAKE, NO ACTION,
35. NO ACTION, COLLISION WARNING, WARNING BRAKE, NO ACTION,
COLLISION WARNING, BRAKE ASSIST,
39. WARNING BRAKE, DRIVER OVERRIDE, NO ACTION, COLLISION WARNING, WARNING BRAKE,
40. WARNING BRAKE, FULL BRAKE, DRIVER OVERRIDE, NO ACTION, COLLISION WARNING, BRAKE ASSIST,
41. WARNING BRAKE, FULL BRAKE, DRIVER OVERRIDE, NO ACTION, COLLISION WARNING, WARNING BRAKE,
42. WARNING BRAKE, FULL BRAKE, NO ACTION, COLLISION WARNING, BRAKE ASSIST, DRIVER OVERRIDE,
43. WARNING BRAKE, FULL BRAKE, NO ACTION, COLLISION WARNING, DRIVER OVERRIDE,
44. WARNING BRAKE, FULL BRAKE, NO ACTION, COLLISION WARNING, WARNING BRAKE,
45. WARNING BRAKE, NO ACTION, COLLISION WARNING, BRAKE ASSIST, DRIVER OVERRIDE,
46. WARNING BRAKE, NO ACTION, COLLISION WARNING, DRIVER OVERRIDE,
47. WARNING BRAKE, NO ACTION, COLLISION WARNING, WARNING BRAKE,
No Action
AEBS NORMAL MODE OPERATION
Brake Assist Collision
Warning Full Brake Warning
(c) 2007
Ch 14, slide 60
Model-Based Testing Exercise
Taken from “Software Testing and Analysis”, (Pezzè and Young)
Task: Derive a test model from the following informal requirements document
Maintenance: The Maintenance function records the history of items undergoing maintenance.
If the product is covered by warranty or maintenance contract, maintenance can be requested either by calling the maintenance toll free number, or through the web site, or by bringing the item to a designated maintenance station.
If the maintenance is requested by phone or web site and the customer is a US or EU resident, the item is picked up at the customer site, otherwise, the customer shall ship the item with an express courier.
If the maintenance contract number provided by the customer is not valid, the item follows the procedure for items not covered by warranty.
If the product is not covered by warranty or maintenance contract, maintenance can be requested only by bringing the item to a maintenance station. The maintenance station informs the customer of the estimated costs for repair. Maintenance starts only when the customer accepts the estimate.
If the customer does not accept the estimate, the product is returned to the customer.
Small problems can be repaired directly at the maintenance station. If the maintenance station cannot solve the problem, the product is sent to the maintenance regional headquarters (if in US or EU) or to the
maintenance main headquarters (otherwise).
If the maintenance regional headquarters cannot solve the problem, the product is sent to the maintenance main headquarters.
Maintenance is suspended if some components are not available. Once repaired, the product is returned to the customer.
(c) 2007 Mauro Pezzè & Michal
Young
