我们的产品在性能方面赢得了不好的声誉。嗯，这是一个 13 岁的大型企业应用程序，需要提神醒脑，特别是提高其性能。
我们决定在这个版本中战略性地解决性能问题。我们正在评估一些关于如何做到这一点的选项。
我们确实有经验丰富的负载测试工程师，他们配备了市场上最好的工具，但通常他们会在版本开发生命周期的后期获得稳定版本，因此在上一个版本中，开发人员没有足够的时间来修复他们的所有发现。（是的，我知道我们需要提供更早的稳定版本，我们也在处理这个过程，但它不在我的范围内）
我正在推动的方向之一是设置一个安装了每晚构建的实验室环境，以便开发人员可以测试其代码的性能影响。我希望模拟真实用户体验的脚本不断加载这个环境。在这个加载的环境中，每个开发人员都必须编写一个特定的脚本来测试他的代码（即真实世界环境中的单一用户体验）。我想生成一份报告，显示每次迭代对现有功能的影响，以及新功能的性能。
我有点担心我的目标太高了，结果会变得太复杂。
您如何看待这样的想法？有没有人有设置这样一个环境的经验？你能分享你的经验吗？
这听起来是个好主意，但老实说，如果您的组织无法为其专门为此目的而雇用的昂贵的负载测试团队进行构建，那么您的想法将永远无法实现。
首先去寻找低垂的果实。在流程的早期为性能测试团队获取可用的夜间构建。
事实上，如果这个版本是关于性能的，为什么不让团队只使用这个版本来解决上一个版本迭代后期出现的所有性能问题。
编辑：“开发人员对性能测试代码没有责任”是评论。是的，没错。我个人希望每个开发人员都拥有 YourKit java profiler 的副本（它既便宜又有效）并且知道如何使用它。然而，不幸的是，性能调优是一项非常非常有趣的技术活动，当您可以更好地开发功能时，可能会花费大量时间来做这件事。
如果您的开发团队反复开发明显缓慢的代码，那么对性能或更好的程序员的教育是唯一的答案，而不是更昂贵的过程。
生产力的最大提升之一是可以在一夜之间运行的自动化构建系统（这称为持续集成）。昨天犯的错误今天一大早就被发现，那时我还很新鲜，当我可能还记得我昨天所做的事情时（而不是几周/几个月后）。
所以我建议首先实现这一点，因为它是其他任何事情的基础。如果你不能可靠地构建你的产品，你会发现很难稳定开发过程。
完成此操作后，您将拥有创建性能测试所需的所有知识。
但有一条建议：不要试图一次完成所有事情。一步一步工作，一个接一个地解决问题。如果有人提出“我们也必须这样做”，您必须像处理任何其他功能请求一样进行分类：这有多重要？有多危险？实施需要多长时间？我们将获得多少？
推迟艰巨但重要的任务，直到您理清了基础知识。
每晚构建是性能测试的正确方法。我建议您需要每晚自动运行的脚本。然后将结果记录在数据库中并提供定期报告。你真的需要两种报告：
其他一些建议：
我们构建了一个小型测试平台，用于进行完整性测试 - 即当按下按钮时，应用程序是否启动并按预期工作，验证是否工作等。我们的应用程序是一个网络应用程序，我们使用Watir一个基于 ruby 的工具包来驱动浏览器。这些运行的输出被创建为 Xml 文档，我们的 CI 工具（巡航控制）可以将结果、错误和性能作为每个构建日志的一部分输出。整个事情运行良好，并且可以扩展到多台 PC 以进行适当的负载测试。
然而，我们之所以这样做，是因为我们拥有的身体多于工具。有一些大型压力测试工具可以满足您的所有需求。它们的成本，但这将少于手动滚动所花费的时间。我们遇到的另一个问题是让我们的开发人员编写 Ruby/Watir 测试，最终落到了一个人身上，因此测试工作几乎成了瓶颈。
夜间构建非常好，实验室环境非常好，但我认为你有可能将性能测试与直接错误测试混淆。
确保您的实验室条件是独立且稳定的（即您一次只改变一个因素，无论是您的应用程序还是 Windows 更新），并且硬件能够反映您的目标。请记住，您的基准比较仅在实验室内部是防弹的。
由编写代码的开发人员编写的测试脚本往往是有害的。它并不能帮助您消除实施中的误解（因为同样的误解也会出现在测试脚本中），而且实际发现问题的动力有限。更好的是采用 TDD 方法并首先作为一个组（或一个单独的组）编写测试，但如果失败，您仍然可以通过协作编写脚本来改进该过程。希望您在设计阶段有一些用户故事，并且可以重放日志以获得真实世界的体验（应用程序不同）。