页面停留时间
即请求之间的间隔（思考）时间，如在编辑页面上停留多久才会点提交按钮。如果无此数据，性能测试脚本只有运行时长是有数据（活跃时间）支撑的，脚本中的各请求之间的思考时间，只能通过常规判断和猜测，由性能测试人员自己掌控。收集到此数据后，性能测试脚本会更加符合真实用户的操作习惯，更加接近真实用户。
热点模块（页面）
分析系统各模块或页面的访问频率，可以用来检查性能测试是否设计了足够的覆盖、是否遗漏的用户频繁使用的功能，并据此对用户模型进行完善。
此外，此数据可用来分析各模块或功能所涉及到的工作量，如每天平均完成多少次提交操作、多少次统计操作。这对于确定系统的使用压力有很大的作用。
场景数据
最后，综合所有数据，为特定测试场景制订出成如下表格：
|
总体 | ||
|
|
场景名称 |
100用户负载场景 |
|
|
场景描述 |
模拟系统使用高峰期时，在2小时左右有100用户的访问 |
|
|
场景时长 |
2h |
|
|
场景加载策略 |
每4.5分钟加载5个虚拟用户。因为要在2小时内完成100用户的访问，而每个用户的运行时间在30分钟左右，那么在1小时30分钟时就最后一批用户就要开始访问系统，即90分钟内加载100个用户。 |
|
|
虚拟用户数 |
100 |
|
|
用户模型 |
见XX用户模型 |
|
|
虚拟用户运行时间 |
30min |
|
|
平均思考时间 |
30~60s |
|
|
场景并发度 |
25。 虚拟用户数*(虚拟用户运行时间/场景时长) |
|
操作说明 | ||
|
登录 |
Think Time |
平均8s，最小5s，最大20s |
|
Pass/Fail 条件 |
如果失败，重试一次，依然失败就中止。 | |
|
数据 |
每虚拟用户使用不同的账号 | |
|
... |
|
|
可以说，用户模型表达的是，系统运行中的压力是如何分布的。
而场景数据表达的是，要给系统施加多大的压力。
只有结合用户模型和场景数据两部分，才能构造出一个确定的负载场景。
如果到这里都已经做好，并且经过了技术负责人和业务负责人的确认，那么接下来要做的就是按照设计来实现测试脚本了。
