模板
教程
环境
性能
功能
管理
软件性能测试的一点总结
性能测试的最终目的是要满足用户的性能体验。无论终端环境如何，对用户来说，对性能的体验就是操作响应时间的大小。因此性能指标的最终表现形式是用户的响应时间。而其它指标比如系统资源占用或网络传输时间等，只是组成用户响应时间的一部分，或者说是影响用户响应时间的一个因素。
用户的响应时间，需求简单明确，始终如一。所以响应时间指标的明确不是问题，这与用户繁复的业务相比来说，有天壤之别。不过在应用场景上与业务测试也有异曲同工之妙。性能测试同样是需要建立在合理的测试场景之上，优先满足用户典型应用场景的响应时间。所以，对性能测试来说，首当其冲的是合理的测试场景设计，其次才是测试方法和调优。
这里的测试场景，需要关注的因素较业务测试场景要复杂一些。业务测试场景可能主要关注用户怎么使用软件，而性能测试场景除了关注用户的操作，还要明确用户使用软件的客观环境如何，比如用户终端的硬件配置(CPU，内存)、网络环境、用户数据量、以及同时在线的用户数量和并发用户数量等。因为这些客观环境，会直接或间接的影响最终的用户响应时间。总结上述因素，结合前期GEPS性能测试经验，总结出来性能测试场景模板格式如下：
|
场景编号 |
|
|||
|
场景名称 |
|
|||
|
场景重要程度 |
|
|||
|
场景设计人 |
|
|||
|
场景基础环境 |
||||
|
|
||||
|
客户端环境（CPU/内存/网络环境/操作系统） |
||||
|
|
||||
|
测试库基础数据量 |
||||
|
总项目数，每个项目数据量【具体每个业务口多少数据量，每个模块多少单据，每个单据细表多少记录数，可以另写一个单独的文档，附加上来】 |
||||
|
场景详情 |
||||
|
同时在线用户数 |
|
|||
|
同时在线客户端数 |
|
|||
|
并发用户数 |
|
|||
|
业务操作场景 |
|
|||
|
执行测试准入条件 |
||||
|
|
||||
|
测试结果有效性衡量标准 |
||||
|
|
||||
|
性能基线 |
||||
|
|
||||
|
测试方法 |
||||
|
测试工具及其作用 |
|
|||
|
测试脚本 |
|
|||
|
测试脚本负责人 |
|
|||
|
测试人 |
|
测试时间 |
|
|
|
测试结果 |
||||
|
|
||||
|
测试结论 |
||||
