性能测试的最终目的是要满足用户的性能体验。无论终端环境如何，对用户来说，对性能的体验就是操作响应时间的大小。因此性能指标的最终表现形式是用户的响应时间。而其它指标比如系统资源占用或网络传输时间等，只是组成用户响应时间的一部分，或者说是影响用户响应时间的一个因素。
用户的响应时间，需求简单明确，始终如一。所以响应时间指标的明确不是问题，这与用户繁复的业务相比来说，有天壤之别。不过在应用场景上与业务测试也有异曲同工之妙。性能测试同样是需要建立在合理的测试场景之上，优先满足用户典型应用场景的响应时间。所以，对性能测试来说，首当其冲的是合理的测试场景设计，其次才是测试方法和调优。
这里的测试场景，需要关注的因素较业务测试场景要复杂一些。业务测试场景可能主要关注用户怎么使用软件，而性能测试场景除了关注用户的操作，还要明确用户使用软件的客观环境如何，比如用户终端的硬件配置（CPU，内存）、网络环境、用户数据量、以及同时在线的用户数量和并发用户数量等。因为这些客观环境，会直接或间接的影响最终的用户响应时间。总结上述因素，结合前期GEPS性能测试经验，总结出来性能测试场景模板格式如下：
|
场景编号 |
|
|
场景名称 |
|
|
场景重要程度 |
|
|
场景设计人 |
|
|
场景基础环境 |
|
服务器环境（CPU/内存/网络环境/操作系统/数据库配置/软件版本） |
|
|
|
客户端环境（CPU/内存/网络环境/操作系统） |
|
|
|
测试库基础数据量 |
|
总项目数，每个项目数据量【具体每个业务口多少数据量，每个模块多少单据，每个单据细表多少记录数，可以另写一个单独的文档，附加上来】 |
|
场景详情 |
|
同时在线用户数 |
|
|
同时在线客户端数 |
|
|
并发用户数 |
|
|
业务操作场景 |
|
|
执行测试准入条件 |
|
|
|
测试结果有效性衡量标准 |
|
|
|
性能基线 |
|
|
|
测试方法 |
|
测试工具及其作用 |
|
|
测试脚本 |
|
|
测试脚本负责人 |
|
|
测试人 |
|
测试时间 |
|
|
测试结果 |
|
|
|
测试结论 |
测试场景编写举例如下：
标准版性能测试
|
场景编号 |
标准版－压力－001 |
|
场景名称 |
压力测试 |
|
场景重要程度 |
高，关注是否能够支撑500个用户同时使用产品 |
|
场景设计人 |
*** |
|
场景基础环境 |
|
服务器环境（CPU/内存/网络环境/操作系统/数据库配置/软件版本） |
|
数据库服务器：
服务器型号：HP DL380
CPU：Intel
Xeon E5540，4路6核
内存：16G
网络环境：局域网
操作系统：winserver2003
ent X64，SP2
数据库配置：MSSQL
2005
min
memory per query (KB)：3192
min
server memory (MB)：3192
max
server memory (MB)：12288
max
degree of parallelism：8
network
packet size (B)：6144
应用服务器：
服务器型号：
CPU：Intel
Xeon E5430，2路4核
内存：8G
网络环境：局域网
操作系统：win
server 2003 ent，SP2
GEPS软件版本：5.1.0.1427 |
|
客户端环境（CPU/内存/网络环境） |
|
CPU：>1GB
内存：>1GB
网络环境：局域网 |
|
测试库基础数据量 |
|
50个项目数据库。
具体数据量参考数据量分析文档 |
|
场景详情 |
|
同时在线用户数 |
50个GTF，相当于250-500个实际用户 |
|
同时在线客户端数 |
50 |
|
并发用户数 |
需后续研究 |
|
业务操作场景 |
50个用户分别在物资、设备、收入生产和安全考核业务口走业务流 |
|
执行测试准入条件 |
|
1、 数据库服务器和应用服务器处于刚开机状态
2、 客户端机器资源占用低：CPU使用不超过10％，可使用内存应该大于1GB，可用网络带宽不低于2MB |
|
测试结果有效性衡量标准 |
|
1、 实际操作数与期望操作数误差在-5％～5％之间
2、 测试过程中操作失败频率较低（分析各个业务口脚本失败情况，如果失败步骤较多，或者阻塞测试，则视为测试结果无效） |
|
性能基线 |
|
响应时间指标：
单据类<3秒；查询类<10秒； |
| 
