DEBUGGING AND TESTING

Performance Testing

Performance testing is designed to test run-time performance testing occurs throughout all steps in the testing process. Even at the unit level, the performance of an individual module may be assessed as white- box tests are conducted. However, it is until not all system elements are fully integrated that the true performance of a system can be ascertained.

Performance tests are often coupled with stress testing and often require both hardware and software instrumentation. That is, it is often necessary to measure resource utilization in an exacting fashion. External instrumentation can monitor execution intervals, log events as they occur, and sample machine states on a regular basis. By incrementing a system, the tester can uncover situation that lead to degradation and possible system failure.

Debugging

Software testing is a process that can be systematically planned and specified. Test case design can be conducted, a strategy can be defined, and results can be evaluated against prescribed expectations.

Debugging occurs as a consequence of successful testing. That is, when a test case uncovers an error, debugging is the process that results in the removal of the error. Debugging is not testing, but it always occurs as consequence of testing

The Debugging Process

The debugging process begins with the execution of a test case. The debugging process begins with the execution of a test case. Results are assessed and a lack of correspondence between expected and actual is encountered. In many cases, the non-corresponding data is a symptom of an underlying cause as yet hidden. The debugging process attempts to match symptom with cause, thereby leading to error correction.

The debugging process attempts to match symptom with cause, there by leading to error correction.

The debugging process will always have two outcomes:

1. The cause will be found, corrected, and removed

2. The cause will not be found.

In the latter case, the person performing debugging may suspect a cause, design a test case to help validate his/her suspicion, and work toward error correction in iterative fashion.

Why debugging is so difficult?

Some characteristics of bugs provide some clues:

1. The symptom and the cause may be geographically remote. That is, the symptom may appear in one part of a program, while the cause may actually be located at a site that is far removed. Highly coupled program structures exacerbate this situation.

2. The symptom may disappear(temporarily) when another error is corrected.

3. The symptom may actually be caused by no errors (e.g. round-off inaccuracies).

4. The symptom may be caused by human error that is not easily traced.

5. The symptom may be a result of timing problems, rather than processing problems.

6. It may be difficult to accurately reproduce input conditions(e.g. a real-time application in which input ordering is indeterminate).

7. The symptom may be due to causes that are distributed across a number of tasks running on different processors.

Debugging approach

In general, three categories for debugging approaches may be proposed.

¨ Brute force

¨ Back tracking

¨ Cause elimination

The brute force category of debugging is probably the most common and efficient method for isolating the cause of a software error. Brute force debugging methods are

applied when all methods of debugging fail. Using a philosophy, memory dumps are taken, run time traces are invoked and the program is loaded with WRITE statement. When this is done, one finds a clue by the information produced which leads to cause of an error.

Backtracking is a common debugging approach that can be used successfully in small programs. Beginning at the site where a symptom has been uncovered, the source code is traced backward (manually) until the site of the cause is found. This process has a limitation when the source lines are more.

Cause Elimination is manifested by induction or deduction and introduces the concept of binary partitioning. Data related to the error occurrence are organized to isolate potential causes.

Alternatively, a list of all possible causes is developed and tests are conducted to eliminate each.

If initial tests indicate that a particular cause hypothesis shows promise the data are refined in an attempt to isolate the bug.

related post

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