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

这听起来是个好主意,但老实说,如果您的组织无法为其为此目的雇佣的昂贵的负载测试团队构建,那么它将永远无法让您的想法发挥作用。

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

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

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

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

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

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

将困难但重要的任务推迟,直到你解决了基本问题。

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

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

• 确保您的机器与预期环境的变化类似。池中有低端和高端机器。

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

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

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

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