Boundary Value Analysis
Boundary value analysis is a software testing design technique in which tests are designed to include representatives of boundary values.
Experience has shown that the boundaries of input and output ranges of a software component are common locations for errors that result in software faults. Boundary value analysis assists with the design of test cases that will exercise these boundaries in an attempt to uncover faults in the software during the testing process.
The expected input and output values should be extracted from the component specification. The input and output values to the software component are then grouped into sets with identifiable boundaries. Each set, or partition, contains values that are expected to be processed by the component in the same way. Partitioning of test data ranges is explained in the equivalence partitioning test case design technique. It is important to consider both valid and invalid partitions when designing test cases.
For an example where the input values were months of the year expressed as integers, the input parameter ‘month’ might have the following partitions:
… -2 -1 0 1 ………….. 12 13 14 15 …..
—————|—————–|———————
invalid partition 1 valid partition invalid partition 2
The boundaries are the values on and around the beginning and end of a partition. If possible test cases should be created to generate inputs or outputs that will fall on and to either side of each boundary. This would result in three cases per boundary. The test cases on each side of a boundary should be in the smallest increment possible for the component under test. In the example above there are boundary values at 0,1,2 and 11,12,13. If the input values were defined as decimal datatype with 2 decimal places then the smallest increment would be the 0.01.
Where a boundary value falls within the invalid partition the test case is designed to ensure the software component handles the value in a controlled manner.Boundary value analysis can be used throughout the testing cycle and is equally applicable at all testing phases.
After determining the necessary test cases with equivalence partitioning and subsequent boundary value analysis, it is necessary to define the combinations of the test cases when there are multiple inputs to a software component.
The purpose of boundary value analysis is to concentrate the testing effort on error prone areas by accurately pinpointing the boundaries of conditions, (e.g., a programmer may specify >, when the requirement states > or =).
Defining the Tests
To determine the tests for this method, first identify valid and invalid input and output conditions for a given function.
Then, identify the tests for situations at each boundary. For example, one test each for >, =, <, using the first value in the > range, the value that is equal to the boundary, and the first value in the < range.
Boundary conditions do not need to focus only on values or ranges, but can be identified for many other boundary situations as well, such as end of page, (i.e., identify tests for production of output that is one line less than the end of page, exactly to the end of page, and one line over the end of page). The tester needs to identify as many situations as possible, the list of Common Extreme Test Conditions may help with this process:
COMMON EXTREME TEST CONDITIONS
EXAMPLE OF BOUNDARY VALUE ANALYSIS
Function to be Tested
For a function called billing, the following specifications are defined:
· Generate a bill for accounts with a balance owed > 0.
· Generate a statement for accounts with a balance owed < 0 (credit).
· For accounts with a balance owed > 0:
· place amounts for which the run date is < 30 days from the date of service in the current total,
· place amounts for which the run date is = or > 30 days, but < or = 60 days, from the date of service, in the 30 to 60 day total,
· place amounts for which the run date is > 60 days, but < or = 90 days, from the date of service, in the 61 to 90 day total,
· place amounts for which the run date is > 90 days, from the date of service, in the 91 days and over total.
· For accounts with a balance owed > or = $10.00, for which the run date is = or > 30 days from the date of service, calculate a $3.00 or 1% late fee, whichever is greater.
Input and Output Conditions
Identify the input, (i.e., information is supplied to the function) and output, (i.e., information is produced by the function) conditions for the function.
The input conditions are identified as:
· balance owed,
· balance owed for late fee.
The output conditions are identified as:
· age of amounts,
· age of amounts for late fee,
· calculation for late fee.
Defining Tests
Define tests for the boundary situations for each of the input and output conditions. For example:
Balance Owed
1. > 0,
2. = 0,
3. < 0.
Age of Amounts
balance owed > 0 and
4. run date – date of service = 0,
5. run date – date of service = 29,
6. run date – date of service = 30,
7. run date – date of service = 31,
8. run date – date of service = 59,
9. run date – date of service = 60,
10. run date – date of service = 61,
11. run date – date of service = 89,
12. run date – date of service = 90,
13. run date – date of service = 91.
Balance Owed for Late Fee
run date – date of service > 30 and
14. balance owed = $9.99,
15. balance owed = $10.00,
16. balance owed = $10.01.
Age of Amount for Late Fee
balance owed > $10.00 and
17. run date – date of service = 29,
18. run date – date of service = 30,
19. run date – date of service = 31,
Calculation for Late Fee
balance owed > $10.00, run date – date of service > 30 and
20. 1% late fee < $3.00,
21. 1% late fee = $3.00,
22. 1% late fee > $3.00.
Boundary value analysis is a software testing design technique in which tests are designed to include representatives of boundary values.
Experience has shown that the boundaries of input and output ranges of a software component are common locations for errors that result in software faults. Boundary value analysis assists with the design of test cases that will exercise these boundaries in an attempt to uncover faults in the software during the testing process.
The expected input and output values should be extracted from the component specification. The input and output values to the software component are then grouped into sets with identifiable boundaries. Each set, or partition, contains values that are expected to be processed by the component in the same way. Partitioning of test data ranges is explained in the equivalence partitioning test case design technique. It is important to consider both valid and invalid partitions when designing test cases.
For an example where the input values were months of the year expressed as integers, the input parameter ‘month’ might have the following partitions:
… -2 -1 0 1 ………….. 12 13 14 15 …..
—————|—————–|———————
invalid partition 1 valid partition invalid partition 2
The boundaries are the values on and around the beginning and end of a partition. If possible test cases should be created to generate inputs or outputs that will fall on and to either side of each boundary. This would result in three cases per boundary. The test cases on each side of a boundary should be in the smallest increment possible for the component under test. In the example above there are boundary values at 0,1,2 and 11,12,13. If the input values were defined as decimal datatype with 2 decimal places then the smallest increment would be the 0.01.
Where a boundary value falls within the invalid partition the test case is designed to ensure the software component handles the value in a controlled manner.Boundary value analysis can be used throughout the testing cycle and is equally applicable at all testing phases.
After determining the necessary test cases with equivalence partitioning and subsequent boundary value analysis, it is necessary to define the combinations of the test cases when there are multiple inputs to a software component.
The purpose of boundary value analysis is to concentrate the testing effort on error prone areas by accurately pinpointing the boundaries of conditions, (e.g., a programmer may specify >, when the requirement states > or =).
Defining the Tests
To determine the tests for this method, first identify valid and invalid input and output conditions for a given function.
Then, identify the tests for situations at each boundary. For example, one test each for >, =, <, using the first value in the > range, the value that is equal to the boundary, and the first value in the < range.
Boundary conditions do not need to focus only on values or ranges, but can be identified for many other boundary situations as well, such as end of page, (i.e., identify tests for production of output that is one line less than the end of page, exactly to the end of page, and one line over the end of page). The tester needs to identify as many situations as possible, the list of Common Extreme Test Conditions may help with this process:
COMMON EXTREME TEST CONDITIONS
- zero or negative values,
- zero or one transaction,
- empty files,
- missing files (file name not resolved or access denied),
- multiple updates of one file,
- full, empty, or missing tables,
- widow headings (i.e., headings printed on pages with no details or totals),
- table entries missing,
- subscripts out of bounds,
- sequencing errors,
- missing or incorrect parameters or message formats,
- concurrent access of a file,
- file space overflow.
EXAMPLE OF BOUNDARY VALUE ANALYSIS
Function to be Tested
For a function called billing, the following specifications are defined:
· Generate a bill for accounts with a balance owed > 0.
· Generate a statement for accounts with a balance owed < 0 (credit).
· For accounts with a balance owed > 0:
· place amounts for which the run date is < 30 days from the date of service in the current total,
· place amounts for which the run date is = or > 30 days, but < or = 60 days, from the date of service, in the 30 to 60 day total,
· place amounts for which the run date is > 60 days, but < or = 90 days, from the date of service, in the 61 to 90 day total,
· place amounts for which the run date is > 90 days, from the date of service, in the 91 days and over total.
· For accounts with a balance owed > or = $10.00, for which the run date is = or > 30 days from the date of service, calculate a $3.00 or 1% late fee, whichever is greater.
Input and Output Conditions
Identify the input, (i.e., information is supplied to the function) and output, (i.e., information is produced by the function) conditions for the function.
The input conditions are identified as:
· balance owed,
· balance owed for late fee.
The output conditions are identified as:
· age of amounts,
· age of amounts for late fee,
· calculation for late fee.
Defining Tests
Define tests for the boundary situations for each of the input and output conditions. For example:
Balance Owed
1. > 0,
2. = 0,
3. < 0.
Age of Amounts
balance owed > 0 and
4. run date – date of service = 0,
5. run date – date of service = 29,
6. run date – date of service = 30,
7. run date – date of service = 31,
8. run date – date of service = 59,
9. run date – date of service = 60,
10. run date – date of service = 61,
11. run date – date of service = 89,
12. run date – date of service = 90,
13. run date – date of service = 91.
Balance Owed for Late Fee
run date – date of service > 30 and
14. balance owed = $9.99,
15. balance owed = $10.00,
16. balance owed = $10.01.
Age of Amount for Late Fee
balance owed > $10.00 and
17. run date – date of service = 29,
18. run date – date of service = 30,
19. run date – date of service = 31,
Calculation for Late Fee
balance owed > $10.00, run date – date of service > 30 and
20. 1% late fee < $3.00,
21. 1% late fee = $3.00,
22. 1% late fee > $3.00.
No comments:
Post a Comment