您的第一步是将应用程序托管在尽可能靠近生产环境的地方，以消除负载/性能测试中的“噪音”。在测试服务器的情况下，您希望保留所有其他内容，将任何数据库托管在单独的系统上（如果这是您可能的生产配置），然后开始探索负载下的应用程序行为。

需要考虑的一些事项：

• 您实际上无法估计需要多少台服务器。您可以做的是估计给定主机配置每小时可以处理多少并发用户和用户。如果估计值低于您对流量的预期，那么您需要查看负载平衡的服务器。
• 如果您可以测试失败，那就去做（您可能会发现系统的其他元素使这成为不可能。我知道有人通过负载测试关闭了公司内部网 - 但他正在测试的应用程序没有闪烁）。
• 请注意应用程序生态系统中的任何其他限制：例如，与 COM 对象的通信在排队请求中受到硬限制，并且某些类型的交互不能是多线程的（我使用与大型机通信的 Web 应用程序- 主机通信是单线程的，先进先出）。如果您的应用程序中有任何这些，请确保明确测试它们的限制，因为它们可能是瓶颈的候选者。
• 如果您在公司网络中工作，请将测试安排在 Intranet 负载不重的时间。您不希望公司网络成为您的测试瓶颈（理想情况下，您应该从公司网络外部访问服务器并使用基于云的加载工具进行测试 - 这并不总是可能的）
• 确保您涵盖并发用户（每个人同时点击相同的东西）和可能适合您的应用的用户访问配置文件。我不记得并发用户的扩展经验法则（就像 10 分钟测试中的 10 个并发 = 每 10 分钟 100 个），但您可能会期望会有一些特殊事件让您获得大量并发或接近-并发用户。您想知道您的应用程序处理不同场景的能力如何。

这里要记住的关键（作为面试问题）是负载和性能测试的目的不是确定应用程序需要什么样的设备。它是尽可能多地定位和消除瓶颈。你永远不应该害怕告诉面试官这一点：如果一个组织为此目的使用负载和性能测试，他们就会面临资源过度或不足的高风险。