是否有关于应用程序应多久进行一次压力或负载测试的规则？我通常在将新版本投入生产之前、硬件发生变化或已知预期用户数量发生变化时这样做。
但今天有人问我，即使没有引入任何更改，这是否应该成为生产中应用程序的标准做法。如果有，多久一次？
【问题讨论】：
标签： testing load-testing stress-testing
这实际上取决于您希望如何满足公司的需求。就个人而言，我们每天加载测试我们的集成（测试）构建 - 就像构建出来一样。在构建运行在大约 1a 之后，我们也将其编写脚本以进行负载测试。我们的目标是专门寻找性能上的构建变化。即使我们不对代码进行更改，对代码进行负载测试的服务器仍会收到更新/补丁/热修复/服务包/等。在最坏的情况下，一旦自动化，它会提供额外的历史数据。
我们正在走这条路（构建相对论），因为在生产环境中尝试复制我们的硬件环境成本高昂。如果我们看到关键性能监视器发生突然变化（或逐渐变化），我们可以查看当时引入了哪些变更集，并隔离可能对性能产生不利影响的代码变更。
听上去，您是在一个复制生产的实验室进行测试？那是一种与我们不同的方法，因为我们假设我们的大部分瓶颈都是由代码引起的，而不是直接依赖于硬件。我们使用虚拟机来近似而非复制我们的生产环境。
【讨论】：
即使代码不变，也会影响系统性能的一件事是数据。
一个例子可能是数据库查询的性能。随着数据被添加到表中，维护索引的成本会上升。索引中的页面拆分会降低性能。随着索引的增长，索引中的“级别”数量将经常需要增加。当这种情况发生时，您会发现性能突然出现明显无法解释的变化。
在生产环境中运行压力测试并不总是可行的 - 它会影响您的日常业务。更常见的是，系统被检测为提供有关性能的持续反馈。也许使用像ganglia 这样的东西。这些数据用于检测问题和进行容量规划。
【讨论】：
我认为，无论何时您更改应用程序中的某些内容（代码、数据文件、用例），包括但不限于预期的用户数量，您都应该对其进行测试。
【讨论】：
我的两分钱：有时您不会更改任何内容，您的网站性能可能会受到影响。它可能来自处理过多数据的应用程序（即：缓存溢出）。可能是由于网站上的第三方广告变慢了。哎呀，这可能是因为内存故障！
主要的是，虽然通常建议您在任何 已知 更改后进行测试，但偶尔进行性能测试以检查可能的 未知 也不是一个坏主意可能影响性能的更改。
我的公司 BrowserMob 提供了一个 free website monitoring service，它每 X 分钟对您的站点运行一次真正的 Selenium 脚本。虽然它不是负载测试，但它绝对可以帮助您识别生产站点中的趋势和瓶颈。
【讨论】：
这取决于您的系统对任务的关键程度......如果它只是一个可以不用的小工具，一旦您投入生产。如果您的生活依赖于它，那么在每次构建之后。
就我而言，就是这样。
【讨论】：
取决于测试需要多少努力。如果它足够容易，更多的测试永远不会受到伤害。但是，我认为没有理由测试是否没有预期的变化。如果这会导致软件长时间未测试，那么不时运行测试可能是合适的，以防出现意外更改。
不用说，这还取决于您的软件是在运行核反应堆还是公告板。
【讨论】：
如果您的产品中没有引入任何更改，并且负载测试只是在一段时间内一遍又一遍地重复相同的过程，我看不到重新运行的好处。
【讨论】：
我曾经将压力测试作为我的 ant 文件的一部分，因此如果需要，我可以每晚运行这些测试，并且我会在进行任何更改或测试可能的新更改时运行它们，这将以某种方式影响我正在测试的内容，看看是否有任何改进。
我认为多久取决于您的环境。
如果您无法在开发中进行真正的压力测试，那么您可能必须等到进行 QA，在您投入生产之前进行测试。
我认为你越早做越好，因为你可以更快地发现问题并修复它们，因为你知道它在两个晚上前工作，昨晚它没有通过测试，所以白天发生了一些变化导致它.
我在许多压力测试中都使用了 junitperf。
【讨论】：
我认为我们不想对记事本进行压力测试。这是个笑话。没关系 =)。
压力测试并非适用于所有应用程序。 :-)
【讨论】：
如果您的软件可以杀死某人，我认为您应该这样做。
想象一下有人因为系统超时导致血液没有到达而死亡。
“Timeout.exception：你的心不再来了。稍后再试”
【讨论】：