N this chapter, we will introduce you to the fundamentals of testing: why testing is

them equivalently), hence
‘equivalence partitioning’. Equivalence partitions are
also known as equivalence classes
– the two terms mean exactly the same thing.
The equivalence-partitioning technique then requires that we need test only one
condition from each partition. This is because we are assuming that all the condi-
tions in one partition will be treated in the same way by the software. If one
condition in a partition works, we assume all of the conditions in that partition will
work, and so there is little point in testing any of these others. Conversely, if one of
the conditions in a partition does not work, then we assume that none of the
conditions in that partition will work so again there is little point in testing any
more in that partition. Of course these are simplifying assumptions that may not
always be right but if we write them down, at least it gives other people the chance
to challenge the assumptions we have made and hopefully help to identify better
partitions. If you have time, you may want to try more than one value from a
partition, especially if you want to confirm a selection of typical user inputs.
For example, a savings account in a bank earns a different rate of interest
depending on the balance in the account. In order to test the software that calculates
the interest due, we can identify the ranges of balance values that earn the different
rates of interest. For example, if a balance in the range $0 up to $100 has a 3%
interest rate, a balance over $100 and up to $1000 has a 5% interest rate, and
balances of $1000 and over have a 7% interest rate, we would initially identify three
valid equivalence partitions and one invalid partition as shown below.
Invalid partition
Valid (for 3% interest)
Valid (for 5%)
Valid (for 7%)
–$0.01 $0.00
$100.00 $100.01
$999.99 $1000.00
Notice that we have identified four partitions here, even though the specification
only mentions three. This illustrates a very important task of the tester
– not only do
we test what is in our specification, but we also think about things that haven
’t been
specified. In this case we have thought of the situation where the balance is less than
zero. We haven
’t (yet) identified an invalid partition on the right, but this would also
be a good thing to consider. In order to identify where the 7% partition ends, we
would need to know what the maximum balance is for this account (which may not
be easy to find out). In our example we have left this open for the time being. Note
that non-numeric input is also an invalid partition (e.g. the letter
‘a’) but we discuss
only the numeric partitions for now.
We have made an assumption here about what the smallest difference is between
two values. We have assumed two decimal places, i.e. $100.00, but we could have
assumed zero decimal places (i.e. $100) or more than two decimal places (e.g.
$100.0000) In any case it is a good idea to state your assumptions
– then other
people can see them and let you know if they are correct or not.
We have also made an assumption about exactly which amount starts the new
interest rate: a penny over to go into the 5% interest rate, but exactly on the
$1000.00 to go into the 5% rate. By making our assumptions explicit, by document-
ing them in this technique, we may highlight any differences in understanding what
the specification means.
When designing the test cases for this software we would ensure that the three
valid equivalence partitions are each covered once, and we would also test the invalid

tải về 6.34 Mb.

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