When a module performs external I/O, following additional interface test must be conducted.
- File attributes correct?
- Open/Close statements correct?
- Format specification matches I/O statements?
- 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 are default values
- incorrect variable names
- inconsistent data types
- underflow, overflow, and addressing exception
In addition to local data structures, the impact of global data on a module should be ascertained during unit testing.
Selective testing of execution paths is an essential task during the unit test. Test cases should be designed to uncover errors to erroneous computations; incorrect comparisons are improper control flow. Basis path and loop testing are effective techniques for uncovering a broad array of path errors.
Among the more common errors in computation are :
- misunderstood or incorrect arithmetic precedence
- mixed mode operation
- incorrect initialization
- precision Inaccuracy
- incorrect symbolic representation of an expression.
Comparison and control flows are closely coupled to one another.
Test cases should uncover errors like:
- Comparison of different data types
- Incorrect logical operators are precedence
- Expectation of equality when precision error makes equality unlikely
- Incorrect comparison or variables
- Improper or non-existent loop termination.
- Failure to exit when divergent iteration is encountered
- Improperly modified loop variables.
Good design dictates that error conditions be anticipated and error handling paths set up to reroute or cleanly terminate processing when an error does occur.
Among the potential errors that should be tested when error handling is evaluated are:
- Error description is unintelligible
- Error noted does not correspond to error encountered
- Error condition causes system intervention prior to error handling
- Exception-condition processing is incorrect
- Error description does not provide enough information to assist in the location of the cause of the error.
Boundary testing is the last task of the unit tests step. software often files at its boundaries. That is, errors often occur when the nth element of an n-dimensional array
is processed; when the ith repetition of a loop with i passes is invoke; or when the maximum or minimum allowable value is encountered. Test cases that exercise data structure, control flow and data values just below, at just above maxima and minima are Very likely to uncover errors.
INTEGRATION TESTING PART ONE
INTEGRATION TESTING PART TWO
INTEGRATION TESTING PART THREE
INTEGRATION TESTING PART FOUR
INTEGRATION TESTING PART FIVE
INTEGRATION TEST STANDARDS
INTEGRATION TEST STANDARDS PART TWO
QUALITY ASSURANCE PART TWO
QUALITY ASSURANCE SQA
QUALITY OF DESIGN OF TEST CASE
QUALITY MANAGEMENT IN SOFTWARE TESTING
TOOLS FOR QUALITY MANAGEMENT
STATICAL QUALITY ASSURANCE
ISO APPROACH TO QUALITY TESTING