【51CTO.com快译】所谓制定性能测试规划，并不单纯只是整理出一篇指导文档，而应深入考量以确保能够通过最少的执行步骤回答关于系统性能的种种问题。
首先，我们有必要了解测试结果需要用于回答哪些问题。以下是部分常见示例：
- 压力测试：系统能够承受且提供可接受用户体验的***并发用户数量是多少？拐点在哪里？
- 负载测试：在当前系统负载场景下，应用程序表现如何？是否能够实现进一步改善？
- 持久性测试：在运行一段时间后，系统工作效果如何？（有时我们需要每晚重启服务器，直到找出解决性能逐步下降的根本原因。）
- 峰值测试：如果正常运行的系统被突如其来的峰值压垮，我们需要多长时间才能完成系统恢复？
另外，在性能测试规划当中，我们还应当对自身能力进行考量：
团队是否准备好应对此类突发状况？或者还需要进行额外培训？
我们能够以怎样的速度找到性能问题的解决办法？
我们已经具备哪些物理资源？不具备的部分存在怎样的获取难度？
带着这些问题，我们即可有针对性地对系统进行审查，并思考如何加以改进。
为了控制篇幅，今天我们只专注于其中一项议题：在明确了预期负载后，我们该如何运行准确的对应负载场景？
性能测试规划：并发用户数量
这里需要再次强调：我们无法在测试起步时即模拟全部并发用户。在这种情况下，一定会同时出现多种问题，而我们很难弄清其真正根源。因此大家应当以迭代方式不断提升负载强度，并在过程中观察所出现的问题。
- 示例：负载测试
现在，我们假定需要测试当前系统能否支持1000名并发用户。
1.首测：1用户，无并发。我们将此作为基准，当然大家也可以选择5用户或者10用户，但请确保具体数字远低于预期水平。
2.二测：200并发用户（或者预期负载的20%）。现在我们将能够得到大量信息，其将最终决定测试过程是否顺利。
在初始测试时，我们首先解决重要问题与默认配置（连接池数或者Java堆大小等），借此了解如何将响应时间与基准水平进行比较。在分析与故障排查完成后，我们再次重复这一测试，直到得出可接受的时间。
根据实际结果，我们考虑在第三次测试中使用40%负载强度（以20%作为基础增量）还是50%（接下来为75%和100%）进行实验。无论如何选择，我们都能在过程中了解到系统的响应时间变化，并掌握其随负载提升所产生的变化。
在本示例中，我们将20%作为增量。另外，我们会重复测试直到在各种负载强度下达到符合预期的SLA，之后再进行新一轮增量。
- 示例：压力测试
在第二项示例中，我们希望利用压力测试找到系统的性能拐点。这意味着我们要增加用户数量并分析其是否会同步带来通量增加。一旦并发量增加但通量不变，则意味着我们到达了拐点，这时系统已经达到饱和状态。
这里我们***采取所谓探索性能测试，即假设拐点一定存在于1000并发用户以内的区间。
目前各类负载模拟工具皆可随时间推移进行负载量提升，例如在开始测试时为0并发用户，到1小时时则为1000并发用户。如此一来，我们即可观察系统通量何时发生下降。假设拐点出现在约650并发用户，则我们可以进一步细化以确定准确的拐点位置。
- 示例：持久性测试
在持久性测试中，我们在可接受条件下运行一项恒定负载，例如在***容量的50%到70%之间。当然，具体情况视您的实际系统场景而定。
一般来讲，此类测试应在压力或负载测试之后进行，用以发现其它类型的问题（例如内存泄漏与挂起连接等）。如果有时间，大家可以延长测试周期以发现更多问题。
- 示例：峰值测试
正如之前提到，峰值测试的意义在于了解系统能够以怎样的速度实现恢复。在这里，我们可以尝试设置1分钟的流量峰值，而后降低负载，观察系统能否正确响应或者将请求暂时挂起。
当然，大家也可以先尝试建立小型峰值，而后再逐步加大强度以研究系统的实际反应。需要强调的是，相关模拟请尽可能与用户行为的分析结论相对应，特别是基于相关日志信息。
总结
性能测试规划的具体设计取决于您希望从中回答的实际问题，但其共同点在于，我们需要尽可能减少测试次数、优化测试成本并提升收益。因此，迭代式增量（用于负载、持久性与峰值测试）以及细粒度（用于压力测试）方法无疑值得大家加以尝试。
原文标题：How to Make a Performance Test Plan
原文作者：Federico Toledo
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
