Failover and Recovery Testing
[Failover and Recovery Testing ensures that the target-of-test can successfully failover and recover from a variety of hardware, software or network malfunctions with undue loss of data or data integrity.
Failover testing ensures that, for those systems that must be kept running, when a failover condition occurs, the alternate or backup systems properly “take over” for the failed system without loss of data or transactions.
Recovery testing is an antagonistic test process in which the application or system is exposed to extreme conditions, or simulated conditions, to cause a failure, such as device Input/Output (I/O) failures or invalid database pointers and keys. Recovery processes are invoked and the application or system is monitored and inspected to verify proper application, or system, and data recovery has been achieved.]
| Test Objective: | [Verify that recovery processes (manual or automated) properly restore the database, applications, and system to a desired, known, state. The following types of conditions are to be included in the testing: · power interruption to the client · power interruption to the server · communication interruption via network servers · interruption, communication, or power loss to DASD and or DASD controllers · incomplete cycles (data filter processes interrupted, data synchronization processes interrupted). · invalid database pointer or keys · invalid or corrupted data element in database] |
| Technique: | [Tests created for Function and Business Cycle testing should be used to create a series of transactions. Once the desired starting test point is reached, the following actions should be performed, or simulated, individually: · Power interruption to the client: power the PC down. · Power interruption to the server: simulate or initiate power down procedures for the server. · Interruption via network servers: simulate or initiate communication loss with the network (physically disconnect communication wires or power down network servers or routers. · Interruption, communication, or power loss to DASD and DASD controllers: simulate or physically eliminate communication with one or more DASD controllers or devices. Once the above conditions or simulated conditions are achieved, additional transactions should be executed and upon reaching this second test point state, recovery procedures should be invoked. Testing for incomplete cycles utilizes the same technique as described above except that the database processes themselves should be aborted or prematurely terminated. Testing for the following conditions requires that a known database state be achieved. Several database fields, pointers, and keys should be corrupted manually and directly within the database (via database tools). Additional transactions should be executed using the tests from Application Function and Business Cycle Testing and full cycles executed.] |
| Completion Criteria: | [In all cases above, the application, database, and system should, upon completion of recovery procedures, return to a known, desirable state. This state includes data corruption limited to the known corrupted fields, pointers or keys, and reports indicating the processes or transactions that were not completed due to interruptions.] |
| Special Considerations: | · [Recovery testing is highly intrusive. Procedures to disconnect cabling (simulating power or communication loss) may not be desirable or feasible. Alternative methods, such as diagnostic software tools may be required. · Resources from the Systems (or Computer Operations), Database, and Networking groups are required. · These tests should be run after hours or on an isolated machine.] |
Дата добавления: 2015-12-17; просмотров: 14; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!