Unit Testing part two

When a module performs external I/O, following additional interface test must be conducted.

1. File attributes correct?
2. Open/Close statements correct?
3. Format specification matches I/O statements?
4. Buffer size matches record size?
5. Files opened before use?
6. End-of-File conditions handled?
7. I/O errors handled
8. 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

1. Improper or inconsistent typing
2. erroneous initialization are default values
3. incorrect variable names
4. inconsistent data types
5. 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 :

1. misunderstood or incorrect arithmetic precedence
2. mixed mode operation
3. incorrect initialization
4. precision Inaccuracy
5. incorrect symbolic representation of an expression.

Comparison and control flows are closely coupled to one another.

Test cases should uncover errors like:

1. Comparison of different data types
2. Incorrect logical operators are precedence
3. Expectation of equality when precision error makes equality unlikely
4. Incorrect comparison or variables
5. Improper or non-existent loop termination.
6. Failure to exit when divergent iteration is encountered
7. 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:

1. Error description is unintelligible
2. Error noted does not correspond to error encountered
3. Error condition causes system intervention prior to error handling
4. Exception-condition processing is incorrect
5. 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 n^th element of an n-dimensional array

is processed; when the i^th 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 TESTING

QUALITY ASSURANCE

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