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.
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 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.
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 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