性能测试计划

接到性能测试的任务时，每个人制定的测试计划不经相同。以下是个人的一些理解：

 

首先区分产品属于研发阶段，还是已到运营阶段

 

研发阶段：

一般在研发阶段有性能测试需求的团队是挺重视测试这个环节的。

之前测试过一个C/S架构的产品，做RoomServer和GameServer压力测试时，是由项目组提供机器人，来模拟多用户在房间中同时进行多局游戏。

QA需要做的是，设计机器人运行的场景

 

而做Web性能测试时，通常由需求方提出性能指标（当然，不一定合理），例如支持500用户并发访问(响应时间小于5秒），每秒注册请求50笔，等

可以尝试做些计划：

1.当无任何数据可参考时，可以尝试用1/3的需求量，先试水跑一次，观察事务的失败率以及响应时间曲线变化。

2.设计场景，虚拟用户数递增，运行时间 30分钟->5小时, 需要多次不同场景数据。

3.通过观察响应时间随着用户数递增产生的变化，寻找最佳并发用户数和最大并发用户数。

4.最佳并发用户数跑5小时，测试稳定性。同样最大并发用户数跑5小时，测试压力。

5.反馈数据，同需求比对。

 

运营阶段：

同研发阶段不同，到了运营阶段，做性能测试的需求，一般是在新上一个新页面/系统，或是活动时。

同样可以尝试做些计划：

1.和研发、运营、产品沟通，确定活动预期人数。

2.通过运营数据，例如PV量，确定一个参考并发数数据。

3.选择测试工具。

4.录制编写脚本、设计场景、运行脚本。

5.多次运行结果比对 （吐吞率、响应时间、系统资源利用率、事务通过率）。

6.多站在用户视角评判一个系统的性能，在用户看来，响应时间永远是第一位的。2秒内，速度很快；2-5秒，一般；5-10秒，很慢了；超过10秒，基本都直接关页面或重新发出请求了。

 

以上都是些非学术性的想法，但操作有效性高就可以了，不是吗？