Scheduling Capacity Testing
Performance Test and Stress/Load Test occur during System Test or when  enough of the application has been delivered. The earlier capacity  testing can be applied, the earlier defects can be detected and  mediated. It is critical to detect capacity related defects early  because these types of defects often require architectural changes to  the system. Because these tests usually depend on functional interfaces,  it may be wise to delay until function testing has demonstrated some  predefined level of reliability. A balance must be struck between  testing early and testing when appropriate. 
 Designing Capacity Tests
Lack of capacity testing requirements and goals is one of the most  common errors made during any capacity testing exercise. Test  organizations will often go through the process of capacity testing only  to discover the testing results do not present the project with any  useful information. The solution is to treat Performance and Stress/Load  testing the same as any other testing effort. The test organization  needs to perform: Test Planning, Partitioning / Functional  Decomposition, Requirements Definition / Verification, Test Case Design,  Traceability (Traceability Matrix), Test Case Execution, Defect  Management, and Coverage Analysis (for more on this see "Requirements  based Function Test"). 
 Implementing Capacity Tests
Both Performance and Stress/Load testing require a toolset that can put  the system under a known load and measure the performance of the  application while under load. Several shops have developed their own  in-shop solutions for capacity testing and there are several capacity  testing freeware, shareware, and commercial products available to meet  this need. It is easy to fall into the .over-engineering. trap when  implementing a capacity testing toolset - to avoid this trap ensure the  solution meets the test organizations goals and that the toolset does  not become a "goal" in itself. 
 

No comments:
Post a Comment