为开发人员性能测试建立实验室

Posted 2023-03-23

【中文标题】为开发人员性能测试建立实验室

【英文标题】：Setting up a lab for developers performance testing

【发布时间】：2009-02-13 08:49:05

【问题描述】：

我们的产品在性能方面名声不佳。嗯，这是一个 13 年历史的大型企业应用程序，需要提神醒脑，特别是提高其性能。

我们决定在此版本中战略性地解决性能问题。我们正在评估一些关于如何做到这一点的选项。

我们确实有经验丰富的负载测试工程师，他们配备了市场上最好的工具，但通常他们会在版本开发生命周期的后期获得稳定版本，因此在上一个版本中，开发人员没有足够的时间来修复所有问题他们的发现。 （是的，我知道我们需要提供更早的稳定版本，我们也在处理这个过程，但它不在我的范围内）

我正在推动的一个方向是设置一个安装了夜间构建的实验室环境，以便开发人员可以测试其代码的性能影响。 我希望模拟真实用户体验的脚本不断加载这个环境。在这个加载的环境中，每个开发人员都必须编写一个特定的脚本来测试他的代码（即真实世界环境中的单用户体验）。我想生成一份报告，显示每次迭代对现有功能的影响，以及新功能的性能。

我有点担心我的目标太高了，结果会变得太复杂。

您如何看待这样的想法？ 有没有人有设置这样一个环境的经验？ 你能分享你的经验吗？

【参考方案1】：

这听起来是个好主意，但老实说，如果您的组织无法为其专门为此目的而雇用的昂贵的负载测试团队进行构建，那么您的想法将永远无法实现。

首先去寻找低垂的果实。在流程的早期为性能测试团队提供一个夜间构建版本。

事实上，如果这个版本是关于性能的，为什么不让团队只使用这个版本来解决上一个版本在迭代后期出现的所有性能问题。

编辑：“开发人员不负责性能测试代码”是一条评论。是的，没错。我个人希望每个开发人员都拥有 YourKit java profiler 的副本（它既便宜又有效）并且知道如何使用它。然而，不幸的是，性能调优是一项非常非常有趣的技术活动，当您可以更好地开发功能时，可能会花费大量时间。

如果您的开发团队反复开发明显缓慢的代码，那么教育性能或更好的程序员是唯一的答案，而不是更昂贵的过程。

【讨论】：

我同意，但开发人员对他们的代码进行性能测试是否有责任？就像他们在交付任何其他代码之前必须运行单元测试一样。

不幸的是，开发人员的观点可能存在偏见/偏差，并且与现实世界的使用情况相去甚远......

开发人员设置环境需要多长时间才能进行真实世界的性能测试？如果这需要几秒钟以上的时间，那么您将失去更多，而不是使用此策略获得的胜利。

【参考方案2】：

生产力的最大提升之一是可以在一夜之间运行的自动化构建系统（这称为持续集成）。昨天犯下的错误今天一大早就发现了，那时我还很新鲜，当我可能还记得我昨天所做的事情时（而不是几周/几个月后）。

所以我建议首先实现这一点，因为它是其他任何事情的基础。如果你不能可靠地构建你的产品，你会发现很难稳定开发过程。

完成此操作后，您将具备创建性能测试所需的所有知识。

但有一条建议：不要试图一次实现所有目标。一步一步工作，一个接一个地解决问题。如果有人提出“我们也必须这样做”，您必须像处理任何其他功能请求一样进行分类：这有多重要？有多危险？实施需要多长时间？我们将获得多少？

将艰巨但重要的任务推迟到你整理好基础知识为止。

【参考方案3】：

每夜构建是进行性能测试的正确方法。我建议您需要每晚自动运行的脚本。然后将结果记录在数据库中并提供定期报告。您确实需要两种报告：

每个指标随时间变化的图表。这将帮助您了解趋势 每个指标与基线的比较。您需要知道一天内什么时候出现急剧下降，或者什么时候超过了性能阈值。

其他一些建议：

确保您的机器与您的预期环境相似。池中有低端和高端机器。 一旦开始测量，切勿更换机器。你需要比较喜欢。您可以添加新机器，但不能修改任何现有机器。

【参考方案4】：

我们构建了一个小型测试平台，用于进行健全性测试 - 即当按下按钮时应用程序是否启动并按预期工作，验证是否工作等。我们是一个网络应用程序，我们使用了 Watir 一个红宝石基于工具包来驱动浏览器。这些运行的输出被创建为 Xml 文档，我们的 CI 工具（巡航控制）可以将结果、错误和性能作为每个构建日志的一部分输出。整个事情运行良好，并且可以扩展到多台 PC 上进行适当的负载测试。

但是，我们之所以这样做，是因为我们拥有的身体多于工具。有一些大型压力测试工具可以满足您的所有需求。它们的成本，但这将少于手动滚动所花费的时间。我们遇到的另一个问题是让我们的开发人员编写 Ruby/Watir 测试，最终落到了一个人身上，因此测试工作几乎成了瓶颈。

【参考方案5】：

夜间构建非常好，实验室环境也非常好，但我认为你有混淆性能测试和直接错误测试的危险。

确保您的实验室条件独立且稳定（即您一次只改变一个因素，无论是您的应用程序还是 Windows 更新），并且硬件能够反映您的目标。请记住，您的基准比较只能在实验室内部进行。

由编写代码的开发人员编写的测试脚本往往是有害的。它并不能帮助您消除实施过程中的误解（因为同样的误解也会出现在测试脚本中），并且实际发现问题的动机有限。更好的是采用 TDD 方法并首先作为一个组（或一个单独的组）编写测试，但如果失败，您仍然可以通过协作编写脚本来改进该过程。希望您在设计阶段有一些用户故事，并且可以重放日志以获得真实世界的体验（应用不同）。