partitioning and boundary value analysis are described in [BS7925-2], including

complex business rules, which is useful for developers as well as for testers.
Decision tables can be used in test design whether or not they are used in
specifications, as they help testers explore the effects of combinations of differ-
ent inputs and other software states that must correctly implement business
rules. Helping the developers do a better job can also lead to better relationships
with them.
Testing combinations can be a challenge, as the number of combinations can
often be huge. Testing all combinations may be impractical if not impossible. We
have to be satisfied with testing just a small subset of combinations but making the
choice of which combinations to test and which to leave out is not trivial. If you do
not have a systematic way of selecting combinations, an arbitrary subset will be
used and this may well result in an ineffective test effort.
Decision tables aid the systematic selection of effective test cases and can have
the beneficial side-effect of finding problems and ambiguities in the specification.
It is a technique that works well in conjunction with equivalence partitioning.
The combination of conditions explored may be combinations of equivalence
partitions.
In addition to decision tables, there are other techniques that deal with testing
combinations of things: pairwise testing and orthogonal arrays. These are described
in [Copeland 2003]. Other sources of techniques are [Pol et al. 2001, Black 2007].
Decision tables and cause-effect graphing are described in [BS7925-2], including
designing tests and measuring coverage.
Using decision tables for test design
The first task is to identify a suitable function or subsystem that has a behaviour
which reacts according to a combination of inputs or events. The behaviour of
interest must not be too extensive (i.e. should not contain too many inputs) other-
wise the number of combinations will become cumbersome and difficult to manage.
It is better to deal with large numbers of conditions by dividing them into subsets
and dealing with the subsets one at a time.
Once you have identified the aspects that need to be combined, then you put
them into a table listing all the combinations of True and False for each of the
aspects. Take an example of a loan application, where you can enter the amount of
the monthly repayment or the number of years you want to take to pay it back (the
term of the loan). If you enter both, the system will make a compromise between the
two if they conflict. The two conditions are the loan amount and the term, so we put
them in a table (see Table 4.2).
T A B L E 4 . 2
Empty decision table
Conditions
Rule 1
Rule 2
Rule 3
Rule 4
Repayment amount has
been entered
Term of loan has been
entered
90
Chapter 4 Test design techniques

Next we will identify all of the combinations of True and False (see Table 4.3).
With two conditions, each of which can be True or False, we will have four
combinations (two to the power of the number of things to be combined). Note that
if we have three things to combine, we will have eight combinations, with four
things, there are 16, etc. This is why it is good to tackle small sets of combinations at
a time. In order to keep track of which combinations we have, we will alternate True
and False on the bottom row, put two Trues and then two Falses on the row above
the bottom row, etc., so the top row will have all Trues and then all Falses (and this
principle applies to all such tables).
The next step (at least for this example) is to identify the correct outcome for each
combination (see Table 4.4). In this example, we can enter one or both of the two
fields. Each combination is sometimes referred to as a rule.
At this point, we may realize that we hadn
’t thought about what happens if the
customer doesn
’t enter anything in either of the two fields. The table has highlighted
a combination that was not mentioned in the specification for this example. We
could assume that this combination should result in an error message, so we need to
add another action (see Table 4.5). This highlights the strength of this technique to
discover omissions and ambiguities in specifications. It is not unusual for some
combinations to be omitted from specifications; therefore this is also a valuable
technique to use when reviewing the test basis.
T A B L E 4 . 3
Decision table with input combinations
Conditions
Rule 1
Rule 2
Rule 3
Rule 4
Repayment amount has
been entered
T
T
F
F
Term of loan has been
entered
T
F
T
F
T A B L E 4 . 4
Decision table with combinations and outcomes
Conditions
Rule 1
Rule 2
Rule 3
Rule 4
Repayment amount has
been entered
T
T
F
F
Term of loan has been
entered
T
F
T
F
Actions/Outcomes
Process loan amount
Y
Y
Process term
Y
Y
Section 3 Specification-Based or Black-Box Techniques 91

Suppose we change our example slightly, so that the customer is not allowed to
enter both repayment and term. Now our table will change, because there should
also be an error message if both are entered, so it will look like Table 4.6.
You might notice now that there is only one
‘Yes’ in each column, i.e. our
actions are mutually exclusive
– only one action occurs for each combination of
conditions. We could represent this in a different way by listing the actions in the
cell of one row, as shown in Table 4.7. Note that if more than one action results
from any of the combinations, then it would be better to show them as separate rows
rather than combining them into one row.
The final step of this technique is to write test cases to exercise each of the four
rules in our table.
T A B L E 4 . 5
Decision table with additional outcomes
Conditions
Rule 1
Rule 2
Rule 3
Rule 4
Repayment amount has
been entered
T
T
F
F
Term of loan has been
entered
T
F
T
F
Actions/Outcomes
Process loan amount
Y
Y
Process term
Y
Y
Error message
Y
T A B L E 4 . 6
Decision table with changed outcomes
Conditions
Rule 1
Rule 2
Rule 3
Rule 4
Repayment amount has
been entered
T
T
F
F
Term of loan has been
entered
T
F
T
F
Actions/Outcomes
Process loan amount
Y
Process term
Y
Error message
Y
Y
92
Chapter 4 Test design techniques

In this example we started by identifying the input conditions and then identifying
the outcomes. However in practice it might work the other way around
– we can see
that there are a number of different outcomes, and have to work back to understand
what combination of input conditions actually drive those outcomes. The technique
works just as well doing it in this way, and may well be an iterative approach as you
discover more about the rules that drive the system.
Credit card worked example
Let
’s look at another example. If you are a new customer opening a credit card
account, you will get a 15% discount on all your purchases today. If you are an
existing customer and you hold a loyalty card, you get a 10% discount. If you
have a coupon, you can get 20% off today (but it can
’t be used with the ‘new
customer
’ discount). Discount amounts are added, if applicable. This is shown
in Table 4.8.
T A B L E 4 . 7
Decision table with outcomes in one row
Conditions
Rule 1
Rule 2
Rule 3
Rule 4
Repayment amount
has been entered
T
T
F
F
Term of loan has
been entered
T
F
T
F
Actions/Outcomes
Result
Error
message
Process loan
amount
Process term
Error
message
Y
Y
Y
T A B L E 4 . 8
Decision table for credit card example
Conditions
Rule 1
Rule 2
Rule 3
Rule 4
Rule 5
Rule 6
Rule 7
Rule 8
New customer (15%)
T
T
T
T
F
F
F
F
Loyalty card (10%)
T
T
F
F
T
T
F
F
Coupon (20%)
T
F
T
F
T
F
T
F
Actions
Discount (%)
X
X
20
15
30
10
20
0
Section 3 Specification-Based or Black-Box Techniques 93

In Table 4.8, the conditions and actions are listed in the left hand column. All the
other columns in the decision table each represent a separate rule, one for each
combination of conditions. We may choose to test each rule/combination and if
there are only a few this will usually be the case. However, if the number of rules/
combinations is large we are more likely to sample them by selecting a rich subset
for testing.
Note that we have put X for the discount for two of the columns (Rules 1 and 2)
–
this means that this combination should not occur. You cannot be both a new customer
and already hold a loyalty card! There should be an error message stating this, but even
if we don
’t know what that message should be, it will still make a good test.
We have made an assumption in Rule 3. Since the coupon has a greater discount
than the new customer discount, we assume that the customer will choose 20%
rather than 15%. We cannot add them, since the coupon cannot be used with the
‘new customer’ discount. The 20% action is an assumption on our part, and we
should check that this assumption (and any other assumptions that we make) is
correct, by asking the person who wrote the specification or the users.
For Rule 5, however, we can add the discounts, since both the coupon and the
loyalty card discount should apply (at least that
’s our assumption).
Rules 4, 6 and 7 have only one type of discount and Rule 8 has no discount, so 0%.
If we are applying this technique thoroughly, we would have one test for each
column or rule of our decision table. The advantage of doing this is that we may test
a combination of things that otherwise we might not have tested and that could find
a defect.
However, if we have a lot of combinations, it may not be possible or sensible to
test every combination. If we are time-constrained, we may not have time to test all
combinations. Don
’t just assume that all combinations need to be tested; it is better
to prioritize and test the most important combinations. Having the full table enables
us to see which combinations we decided to test and which not to test this time.
There may also be many different actions as a result of the combinations of
conditions. In the example above we just had one: the discount to be applied. The
decision table shows which actions apply to each combination of conditions.
In the example above all the conditions are binary, i.e. they have only two
possible values: True or False (or, if you prefer Yes or No). Often it is the case
that conditions are more complex, having potentially many possible values. Where
this is the case the number of combinations is likely to be very large, so the
combinations may only be sampled rather than exercising all of them.
4.3.3 State transition testing
State transition testing is used where some aspect of the system can be described in
what is called a
‘finite state machine’. This simply means that the system can be in a
(finite) number of different states, and the transitions from one state to another are
determined by the rules of the
‘machine’. This is the model on which the system and
the tests are based. Any system where you get a different output for the same input,
depending on what has happened before, is a finite state system. A finite state
system is often shown as a state diagram (see Figure 4.2).
For example, if you request to withdraw $100 from a bank ATM, you may be
given cash. Later you may make exactly the same request but be refused the money
(because your balance is insufficient). This later refusal is because the state of your
bank account has changed from having sufficient funds to cover the withdrawal to
State transition
testing A black box test
design technique in
which test cases are
designed to execute valid
and invalid state
transitions.
State diagram A
diagram that depicts the
states that a component
or system can assume,
and shows the events or
circumstances that cause
and/or result from a
change from one state to
another.
94
Chapter 4 Test design techniques

having insufficient funds. The transaction that caused your account to change its
state was probably the earlier withdrawal. A state diagram can represent a model
from the point of view of the system, the account or the customer.
Another example is a word processor. If a document is open, you are able to
close it. If no document is open, then
‘Close’ is not available. After you choose
‘Close’ once, you cannot choose it again for the same document unless you open
that document. A document thus has two states: open and closed.
A state transition model has four basic parts:
l
the states that the software may occupy (open/closed or funded/insufficient funds);
l
the transitions from one state to another (not all transitions are allowed);
l
the events that cause a transition (closing a file or withdrawing money);
l
the actions that result from a transition (an error message or being given your cash).
Note that in any given state, one event can cause only one action, but that the
same event
– from a different state – may cause a different action and a different
end state.
We will look first at test cases that execute valid state transitions.
Figure 4.2 shows an example of entering a Personal Identity Number (PIN) to a
bank account. The states are shown as circles, the transitions as lines with arrows
and the events as the text near the transitions. (We have not shown the actions
explicitly on this diagram, but they would be a message to the customer saying
things such as
‘Please enter your PIN’.)
The state diagram shows seven states but only four possible events (Card
inserted, Enter PIN, PIN OK and PIN not OK). We have not specified all of the
possible transitions here
– there would also be a time-out from ‘wait for PIN’ and
from the three tries which would go back to the start state after the time had elapsed
and would probably eject the card. There would also be a transition from the
‘eat
card
’ state back to the start state. We have not specified all the possible events
either
– there would be a ‘cancel’ option from ‘wait for PIN’ and from the three
tries, which would also go back to the start state and eject the card. The
‘access
account
’ state would be the beginning of another state diagram showing the valid
transactions that could now be performed on the account.
start
eat card
wait for
PIN
1st try
2nd try
3rd try
access
to
account
card inserted
enter PIN
PIN OK
PIN OK
PIN OK
PIN not OK
PIN not OK
PIN not OK
F I G U R E 4 . 2
State diagram for PIN entry
Section 3 Specification-Based or Black-Box Techniques 95

However this state diagram, even though it is incomplete, still gives us informa-
tion on which to design some useful tests and to explain the state transition
technique.
In deriving test cases, we may start with a typical scenario. A sensible first test
case here would be the normal situation, where the correct PIN is entered the first
time. To be more thorough, we may want to make sure that we cover every state (i.e.
at least one test goes through each state) or we may want to cover every transition.
A second test (to visit every state) would be to enter an incorrect PIN each time, so
that the system eats the card. We still haven
’t tested every transition yet. In order
to do that, we would want a test where the PIN was incorrect the first time but OK
the second time, and another test where the PIN was correct on the third try. These
tests are probably less important than the first two.
Note that a transition does not need to change to a different state (although all of
the transitions shown above do go to a different state). So there could be a transition
from
‘access account’ which just goes back to ‘access account’ for an action such as
‘request balance’.
Test conditions can be derived from the state graph in various ways. Each state
can be noted as a test condition, as can each transition. In the Syllabus, we need to
be able to identify the coverage of a set of tests in terms of transitions.
Going beyond the level expected in the Syllabus, we can also consider transition
pairs and triples and so on. Coverage of all individual transitions is also known as
0-switch coverage, coverage of transition pairs is 1-switch coverage, coverage of
transition triples is 2-switch coverage, etc. Deriving test cases from the state transi-
tion model is a black-box approach. Measuring how much you have tested (covered)
is getting close to a white-box perspective. However, state transition testing is
regarded as a black-box technique.
One of the advantages of the state transition technique is that the model can
be as detailed or as abstract as you need it to be. Where a part of the system is
more important (that is, requires more testing) a greater depth of detail can be
modelled. Where the system is less important (requires less testing), the model
can use a single state to signify what would otherwise be a series of different
states.
Testing for invalid transitions
Deriving tests only from a state graph (also known as a state chart) is very good
for seeing the valid transitions, but we may not easily see the negative tests,
where we try to generate invalid transitions. In order to see the total number of
combinations of states and transitions, both valid and invalid, a state table is
useful.
The state table lists all the states down one side of the table and all the events that
cause transitions along the top (or vice versa). Each cell then represents a state
–
event pair. The content of each cell indicates which state the system will move to,
when the corresponding event occurs while in the associated state. This will include
possible erroneous events
– events that are not expected to happen in certain states.
These are negative test conditions.
Table 4.9 lists the states in the first column and the possible inputs across the
top row. So, for example, if the system is in State 1, inserting a card will take it to
State 2. If we are in State 2, and a valid PIN is entered, we go to State 6 to access
the account. In State 2 if we enter an invalid PIN, we go to State 3. We have put a
State table A grid
showing the resulting
transitions for each state
combined with each
possible event, showing
both valid and invalid
transitions.
96
Chapter 4 Test design techniques

dash in the cells that should be impossible, i.e. they represent invalid transitions
from that state.
We have put a question mark for two cells, where we enter either a valid or invalid
PIN when we are accessing the account. Perhaps the system will take our PIN number
as the amount of cash to withdraw? It might be a good test! Most of the other invalid
cells would be physically impossible in this example. Invalid (negative) tests will
attempt to generate invalid transitions, transitions that shouldn
’t be possible (but often
make good tests when it turns out they are possible).
A more extensive description of state machines is found in [Marick 1994]. State
transition testing is also described in [Craig 2002], [Copeland 2003], [Beizer 1990],
[Broekman 2003], and [Black 2007]. State transition testing is described in
[BS7925-2], including designing tests and coverage measures.
4.3.4 Use case testing
Use case testing is a technique that helps us identify test cases that exercise the
whole system on a transaction by transaction basis from start to finish. They are
described by Ivar Jacobson in his book Object-Oriented Software Engineering:
A Use Case Driven Approach [Jacobson 1992].
A use case is a description of a particular use of the system by an actor (a user
of the system). Each use case describes the interactions the actor has with the
system in order to achieve a specific task (or, at least, produce something of
value to the user). Actors are generally people but they may also be other systems.
Use cases are a sequence of steps that describe the interactions between the actor
and the system.
Use cases are defined in terms of the actor, not the system, describing what the
actor does and what the actor sees rather than what inputs the system expects and
what the system outputs. They often use the language and terms of the business
rather than technical terms, especially when the actor is a business user. They serve
as the foundation for developing test cases mostly at the system and acceptance
testing levels.
T A B L E 4 . 9
State table for the PIN example
Insert card
Valid PIN
Invalid PIN
S1) Start state
S2
–
–
S2) Wait for PIN
–
S6
S3
S3) 1st try invalid
–
S6
S4
S4) 2nd try invalid
–
S6
S5
S5) 3rd try invalid
–
–
S7
S6) Access account
–
?
?
S7) Eat card
S1 (for new card)
–
–
Use case testing A
black box test design
technique in which test
cases are designed to
execute scenarios of use
cases.
Section 3 Specification-Based or Black-Box Techniques 97

Use cases can uncover integration defects, that is, defects caused by the
incorrect interaction between different components. Used in this way, the actor
may be something that the system interfaces to such as a communication link or
sub-system.
Use cases describe the process flows through a system based on its most likely
use. This makes the test cases derived from use cases particularly good for finding
defects in the real-world use of the system (i.e. the defects that the users are most
likely to come across when first using the system). Each use case usually has a
mainstream (or most likely) scenario and sometimes additional alternative
branches (covering, for example, special cases or exceptional conditions). Each
use case must specify any preconditions that need to be met for the use case to
work. Use cases must also specify postconditions that are observable results and a
description of the final state of the system after the use case has been executed
successfully.
The PIN example that we used for state transition testing could also be defined in
terms of use cases, as shown in Figure 4.3. We show a success scenario and the
extensions (which represent the ways in which the scenario could fail to be a
success).
For use case testing, we would have a test of the success scenario and one test for
each extension. In this example, we may give extension 4b a higher priority than 4a
from a security point of view.
System requirements can also be specified as a set of use cases. This approach
can make it easier to involve the users in the requirements gathering and definition
process.

tải về 6.34 Mb.

Chia sẻ với bạn bè của bạn: