如表13-1所示为IT部门对业务部门承诺的关键功能（登录系统）的性能指标。如何将宽泛的IT承诺指标转换测试人员可以使用的性能测试指标，这里有一定的技巧。
1.如何确定性能测试的并发虚拟用户数
测试环境平均并发数=（高峰段用户数×10%）/n
n是生产环境和测试环境服务器配置折算比，例如n=公倍数（（生产Web服务器数/测试Web服务器数），（生产APP服务器/测试APP服务器数））×（生产服务器内存/测试服务器内存），一般算下来n=4。请注意n=4仅仅是一个经验值，并不一定适用于测试人员所在的测试组织。
10%的含义是我们假定所有用户中，只有10%的用户在同一时刻做同一件事情，例如登录系统。请注意10%仅仅是一个经验值，并不一定适用于测试人员所在的测试组织。
2.如何确定性能测试的持续时长
IT部门对业务部门承诺的系统可用时间段为：8:00~21:00，那么用户的登录操作是否平均分布在8：00~21：00这13个小时以内呢？答案当然是否定的。调研生产用户习惯后，发现登录操作集中发生在8：50~9:20这半个小时以内。因此我们可能将性能测试的持续时长，确定为半个小时。
3.如何确定性能测试的存量数据
准备性能测试的存量数据是一件复杂而具有挑战性的工作。这项工作并没有通用的模型可供参考，只能凭借测试人员的经验，它需要测试人员对系统架构非常熟悉才行。本例中的存量数据就是23000个测试账号，即数据库用户表中应该有23000条以上的记录，而测试人员并不需要保证这23000条记录每一条都能真实完成系统登录。
4.如何确定测试人员重点观察的性能指标
从IT部门对业务部门承诺的关键功能（登录系统）的性能指标中，我们可以找到两个具体要求：
（1）平均响应时长<4s
（2）可接受最长响应时长≤7s.
现在要做的就是将这两个指标与JMeter监听器的统计口径关联起来。
（1）平均响应时长←→平均响应时长（JMeter聚合报告）
（2）可接受最长响应时长←→90%阈值（JMeter聚合报告）
除了平均响应时长和90%阈值这两项统计值之外，我们还需要关注哪几项统计值呢？答案是吞吐率（每秒完成请求数）和错误率。在图形结果中吞吐率应该是先逐渐攀升最后趋于平稳的一条曲线，而错误率则应该基本为0。
于是我们得出结论，本例中测试人员应该重点关注4项JMeter监听器的统计指标：
（1）平均响应时长（JMeter聚合报告）<4s
（2）90%阈值（JMeter聚合报告）≤7s
（3）吞吐率，应该是先逐渐攀升最后趋于平稳的一条曲线。
（4）错误率，趋近于0，如果不为0，应该认真分析。
