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

我们的产品在性能上名声不好。嗯，这是一个大的企业应用程序，已经有13年的历史了，需要一次提神，特别是性能的提升

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

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

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

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

你觉得这样的想法怎么样？ 有没有人有建立这样一个环境的经验？

---

你能分享你的经验吗？

这听起来是个好主意，但老实说，如果你的组织不能为为此目的而雇佣的昂贵的负载测试团队构建一个平台，那么它将永远无法让你的想法发挥作用

先吃低垂的水果。在过程的早期阶段，让性能测试团队可以使用夜间构建

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

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

---

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

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

---

然而，我们这么做是因为我们的身体比工具多。有一些大型压力测试工具可以满足您的所有需求。他们的成本，但这将少于花在手摇的时间。我们遇到的另一个问题是让我们的开发人员编写Ruby/Watir测试，最终由一个人完成，因此测试工作几乎成了瓶颈。

夜间构建非常出色，实验室环境非常出色，但我认为您有可能将性能测试与直接的bug测试混为一谈

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

---

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

生产力的最大提升之一是一个通宵运行的自动构建系统（这称为持续集成）。昨天犯的错误会在今天清晨被发现，那时我还很新鲜，可能还记得昨天做了什么（而不是几个星期/几个月后）

所以我建议让这件事先发生，因为这是其他一切的基础。如果您不能可靠地构建产品，您将发现很难稳定开发过程

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

不过有一条建议：不要试图一下子完成所有事情。一步一个脚印，解决一个又一个问题。如果有人提出“我们也必须这样做”，您必须像处理任何其他功能请求一样进行分类：这有多重要？有多危险？实施需要多长时间？我们能得到多少

---

将困难但重要的任务推迟到基本问题解决之后。

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

• 随时间变化的每个度量的图表。这将是他