- Is the number of input parameters equal to number of arguments?
- Do parameter and argument attributes match?- Do parameter and argument units system match?
- Is the number of arguments transmitted to called modules equal to number of parameters?
- Are the attributes of arguments transmitted to called modules equal to attributes of parameters?
- Is the units system of arguments transmitted to called modules equal to units system of parameters?
- Are the number of attributes and the order of arguments to built-in functions correct?
- Are any references to parameters not associated with current point of entry?
- Have input only arguments altered?
- Are global variable definitions consistent across modules?- Are constraints passed as arguments?
When a module performs external I/O, additional interface tests must be conducted:
- File attributes correct?
- OPEN/CLOSE statements correct?- Format specification matches I/O statement?- Buffer size matches record size?
- Files opened before use?- End-of-file conditions handled?
- I/O errors handled?- Any textual errors in output information?
The local data structure for a module is a common source of errors.
Test cases should be designed to uncover errors in the following categories:
- improper or inconsistent typing- erroneous initialization or default values
- incorrect (misspelled or truncated) variable names- inconsistent data types
- underflow, overflow and addressing exceptions
From a strategic point of view, the following questions should be addressed:
- Has the component interface been fully tested?
- Have local data structured been exercised at their boundaries?
- Has the cyclomatic complexity of the module been determined?
- Have all independent basis paths been tested?
- Have all loops been tested appropriately?
- Have data flow paths been tested? Have all error handling paths been tested?
- Do parameter and argument attributes match?- Do parameter and argument units system match?
- Is the number of arguments transmitted to called modules equal to number of parameters?
- Are the attributes of arguments transmitted to called modules equal to attributes of parameters?
- Is the units system of arguments transmitted to called modules equal to units system of parameters?
- Are the number of attributes and the order of arguments to built-in functions correct?
- Are any references to parameters not associated with current point of entry?
- Have input only arguments altered?
- Are global variable definitions consistent across modules?- Are constraints passed as arguments?
When a module performs external I/O, additional interface tests must be conducted:
- File attributes correct?
- OPEN/CLOSE statements correct?- Format specification matches I/O statement?- Buffer size matches record size?
- Files opened before use?- End-of-file conditions handled?
- I/O errors handled?- Any textual errors in output information?
The local data structure for a module is a common source of errors.
Test cases should be designed to uncover errors in the following categories:
- improper or inconsistent typing- erroneous initialization or default values
- incorrect (misspelled or truncated) variable names- inconsistent data types
- underflow, overflow and addressing exceptions
From a strategic point of view, the following questions should be addressed:
- Has the component interface been fully tested?
- Have local data structured been exercised at their boundaries?
- Has the cyclomatic complexity of the module been determined?
- Have all independent basis paths been tested?
- Have all loops been tested appropriately?
- Have data flow paths been tested? Have all error handling paths been tested?
Comments