性能测试Report 模板

XXXXNew Archive Release Compare Test Report

XXXX-PEG

XXXX/

 

 

Test Objective

This test is aimed at compare the new deployed archive release with the non-archive release of XXXXboth on UAT environment using new updated data base Oracle 10g with updated store procedures.

Test Background

 

Project Version	1.9.2
Infrastructure	Application Server: AIX53, 8 CPUs, 15G Memory Database: Oracle 10g: SunOS 5.1, 8 CPUs 2400M Hz, 32G Memory
Architecture	Application Server: Websphere 6.1 Database: Oracle 10g
Testing Time	The test last from 08/24 to 08/25.
Testing Environment	The test is performed at UAT environment.

 

 

Test Strategy

For this compare test we pick 5 scenarios. Each test we ramp up 20 users and run the test for 30 minutes.

Test Setting

The test is built for each scenario as this way:

Total Planning Duration (including Ramp Up/Down):      30 Minutes

Startup Virtual Users:   0

Maximum Running Virtual users: 20

Ramp Up Enabled:        True

Ramp Down Enabled:    False

Sleep Time between Requests:  30 seconds

Think Time between Actions:  0 seconds

Start 0 users at the beginning and add 2 virtual users every minute. Let the 20 users concurrently run for 20 minutes.

Test Result

Following lists the test results for each scenario:

Scenario Name

Request and Action time before release

 

Request and Action time after release

 

 

CPU Utility and I/O before release

 

CPU Utility and I/O after release

 

 

 

Scenario name

Request and Action time before release

 

Request and Action time after release

 

 

CPU Utility and I/O before release

 

CPU Utility and I/O after release

 

 

Conclusion

The data shows that: for ‘xxxxxxscenario the response time of after release and before release is close; for “xxxx statistics” and “xxxxstatisticsxxxx” scenarios, response time decrease a lot (nearly 80 times) after the archive release; and for “xxx” and “xx” scenarios, response time increase nearly 86% after the release.

And the CPU utility and I/O for every scenario are all low which is normal. But the performance degrade of monthly reports should be taken care of, which takes more than 300 seconds to finish one request. It is unacceptable.

 

Terminology

Term	Definition
Virtual User	Virtual users are used as a replacement for human users. When you run a scenario, Virtual Users emulate the actions of human users working with your application. A scenario can contain tens, hundreds, or even thousands of Virtual Users running concurrently on a single workstation.
Load Test	Tests a system's ability to handle a heavy workload. A load test simulates multiple transactions or users interacting with the computer at the same time and provides reports on response times and system behavior.
Run Time	Run Time allow you to customize the way a Virtual Users is executed. You configure the run time settings before running a scenario. Run Time Editor of GrinderBox allows you to set the time that the scenario will start running, the duration time of the scenario or of the Virtual users within the scenario, and to gradually run and stop the Virtual users within the scenario. It also allows you to set the load behavior of Virtual Users in a scenario.
Scenario	A scenario defines the events that occur during each testing session. For example, a scenario defines and controls the number of users to emulate, the actions that they perform, and the machines on which they run their emulations.
	Scenario includes branches of sessions; at least, one session is required. There are tree types of sessions. They are general type session, start type session and end type session. For start type and end type, there should be 0 or 1 session in a single scenario; and for the general type, at least 1 session is required.
Session	Session is a sequence of actions; it should include at least one action indeed. Those actions in this session maybe context sensitive.
Action	An Action includes at least one request. Possibly, it represents a page in web applications. You can take the action as a flexible granularity; it can be a single request, a single page or a group of pages. You can even take similar requests as different actions with slight difference in requests, such as the parameter, etc.
Request	A request is atomic granularity of load test in GrinderBox. It should be some communication between client and server and should be responded immediately. In web applications, request could be some http get, http post, http put, etc.