N this chapter, we will introduce you to the fundamentals of testing: why testing is
partition in its own right and should be tested, but it doesn
tải về 6.34 Mb. Chế độ xem pdf
|
partition in its own right and should be tested, but it doesn ’t make sense to talk about boundaries for this type of partition, which is a collection of valid things. The invalid partition would be an attempt to type in any other type of flight class (e.g. ‘Staff’). If this field is implemented using a drop-down list, then it should not be possible to type anything else in, but it is still a good test to try at least once in some drop-down field. When you are analyzing the test basis (e.g. a requirements specifica- tion), equivalence partitioning can help to identify where a drop-down list would be appropriate. When trying to identify a defect, you might try several values in a partition. If this results in different behaviour where you expected it to be the same, then there may be two (or more) partitions where you initially thought there was only one. We can apply equivalence partitioning and boundary value analysis to all levels of testing. The examples here were at a fairly detailed level probably most appro- priate in component testing or in the detailed testing of a single screen. At a system level, for example, we may have three basic configurations which our users can choose from when setting up their systems, with a number of options for each configuration. The basic configurations could be system administrator, manager and customer liaison. These represent three equivalence partitions that could be tested. We could have serious problems if we forget to test the configura- tion for the system administrator, for example. We can also apply equivalence partitioning and boundary value analysis more than once to the same specification item. For example, if an internal telephone system for a company with 200 telephones has 3-digit extension numbers from 100 to 699, we can identify the following partitions and boundaries: Section 3 Specification-Based or Black-Box Techniques 85 l digits (characters 0 to 9) with the invalid partition containing non-digits; l number of digits, 3 (so invalid boundary values of 2 digits and 4 digits); l range of extension numbers, 100 to 699 (so invalid boundary values of 099 and 700); l extensions that are in use and those that are not (two valid partitions, no boundaries); l the lowest and highest extension numbers that are in use could also be used as boundary values. One test case could test more than one of these partitions/boundaries. For example, Extension 409 which is in use would test four valid partitions: digits, the number of digits, the valid range, and the ‘in use’ partition. It also tests the boundary values for digits, 0 and 9. How many test cases would we need to test all of these partitions and boundaries, both valid and invalid? We would need a non-digit, a 2-digit and 4-digit number, the values of 99, 100, 699 and 700, one extension that is not in use, and possibly the lowest and highest extensions in use. This is 10 or 11 test cases – the exact number would depend on what we could combine in one test case. Using equivalence partitioning and boundary value analysis helps us to identify tests that are most likely to find defects, and to use fewer test cases to find them. This is because the contents of a partition are representative of all of the possible values. Rather than test all 10 individual digits, we test one in the middle (e.g. 4) and the two edges (0 and 9). Instead of testing every possible non-digit character, one can represent all of them. As we mentioned earlier, we can also apply these techniques to output partitions. Consider the following extension to our bank interest rate example. Suppose that a customer with more than one account can have an extra 1% interest on this account if they have at least $1000 in it. Now we have two possible output values (7% interest and 8% interest) for the same account balance, so we have identified another test condition (8% interest rate). (We may also have identified that same output condition by looking at customers with more than one account, which is a partition of types of customer.) Equivalence partitioning can be applied to different types of input as well. Our examples have concentrated on inputs that would be typed in by a (human) user when using the system. However, systems receive input data from other sources as well, such as from other systems via some interface – this is also a good place to look for partitions (and boundaries). For example, the value of an interface parameter may fall into valid and invalid equivalence partitions. This type of defect is often difficult to find in testing once the interfaces have been joined together, so is particularly useful to apply in integration testing (either component integration or system integration). Boundary value analysis can be applied to the whole of a string of characters (e.g. a name or address). The number of characters in the string is a partition, e.g. between 1 and 30 characters is the valid partition with valid boundaries of 1 and 30. The invalid boundaries would be 0 characters (null, just hit the Return key) and 31 characters. Both of these should produce an error message. Partitions can also be identified when setting up test data. If there are different types of record, your testing will be more representative if you include a data record of each type. The size of a record is also a partition with boundaries, so we could include maximum and minimum size records in the test database. 86 Chapter 4 Test design techniques If you have some inside knowledge about how the data is physically organized, you may be able to identify some hidden boundaries. For example, if an overflow storage block is used when more than 255 characters are entered into a field, the boundary value tests would include 255 and 256 characters in that field. This may be verging on white-box testing, since we have some knowledge of how the data is structured, but it doesn ’t matter how we classify things as long as our testing is effective at finding defects. Don ’t get hung up on a fine distinction – just do whatever testing makes sense, based on what you know. An old Chinese proverb says, ‘It doesn’t matter whether the cat is white or black; all that matters is that the cat catches mice ’. With boundary value analysis, we think of the boundary as a dividing line between two things. Hence we have a value on each side of the boundary (but the boundary itself is not a value). Invalid Valid Invalid 0 1 99 100 Looking at the values for our printer example, 0 is in an invalid partition, 1 and 99 are in the valid partition and 100 is in the other invalid partition. So the boundary is between the values of 0 and 1, and between the values of 99 and 100. There is a school of thought that regards an actual value as a boundary value. By tradition, these are the values in the valid partition (i.e. the values specified). This approach then requires three values for every boundary, so you would have 0, 1 and 2 for the left boundary, and 98, 99 and 100 for the right boundary in this example. The boundary values are said to be ‘on and either side of the boundary’ and the value that is ‘on’ the boundary is generally taken to be in the valid partition. Note that Beizer talks about domain testing, a generalization of equivalence tải về 6.34 Mb. Chia sẻ với bạn bè của bạn:
|