A classic system testing problem is “finger pointing”. This occurs when an error is uncovered, and each system element developer blames the other for the problem. Rather than indulging in such nonsense, the software engineer should anticipate potential interfacing problems and
1) design error-handling paths that test all information coming from other elements of the system;
2) conduct a series of tests that simulate bad data or other potential errors at the software interface;
3) record the results of tests to use as “evidence” if finger pointing does occur; and
4) participate in planning and design of system tests to ensure that software is adequately tested.
Recovery Testing
Many computer-based systems must recover from faults and resume processing within a pre-specified time. In some cases, a system must be fault tolerant; that is, processing faults must not cause overall system function to cease. In other cases, a
system; failure must be corrected within a specified period of time or severe economic damage will occur.
Recovery testing is a system test that forces the software to fail in a variety of ways and verifies that recovery is properly performed. If recovery is automatic (performed by the system itself), re-initialization, check pointing, mechanism, data recovery, and restart are each evaluated for correctness. If recovery requires human intervention, the mean time to repair is evaluated to determine whether it is within acceptable limits.
Security Testing
Security testing attempts to verify that protection mechanisms built into a system will in fact protect it from improper penetration.
During security testing, the tester plays the role(s) of the individual who desires to penetrate the system. Anything goes! The tester may attempt to acquire passwords through external clerical means, may attack the system with custom software designed to break down any defenses that have been constructed; may overwhelm the system, thereby denying service to others; may purposely cause system errors, hoping to penetrate during recovery; may browse through insecure data, hoping to find the key to system entry; and so on.
Given enough time and resources, good security testing will ultimately penetrate a system. The role of the system designer is to make penetration cost greater than the value of the information that will be obtained.
Stress test is designed to confront programs with abnormal situations. In essence, the tester who performs stress testing asks:"How high can we crank this up before it fails"?
Stress testing executes a system in a manner that demands resources in abnormal quantity, frequency, or volume.
For example
1. Special test may be designed that generate 10 interrupts per second when 1 or 2 is the average rate.
2. Input data rates may be increased by an order of magnitude to determine how input function will respond.
3. Test cases that require maximum memory or other resources may be executed
4. Test cases that may cause trashing in a virtual operating system may be designed.
5. Test cases that may cause excessive hunting for disk resident data may be created.
Essentially the tester attempts to break the program.
A variation of stress testing is a technique called sensitivity testing. In some situation, a very small range of data contained within the bounds of valid data for a program may cause extreme and even erroneous processing or profound performance degradation. This situation analogous to a singularity in a mathematical function.
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
No comments:
Post a Comment