【.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分钟的流量高峰，然后降低负载，观察系统是否能够正确响应或者暂时中止请求。当然，你也可以先尝试建立小峰，然后逐渐增加强度来研究系统的实际响应。需要强调的是，相关模拟应尽可能对应用户行为的分析结论，尤其是基于相关日志信息。总结性能测试计划的具体设计取决于您希望从中回答的实际问题，但共同点是我们需要尽量减少测试数量、优化测试成本并提高盈利能力。因此，迭代增量（用于负载、持久性和尖峰测试）和细粒度（用于压力测试）方法绝对值得尝试。原标题：如何制定性能测试计划原作者：FedericoToledo
