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