4

在我们公司，我们有单元测试。我们正在考虑编写一些自动化性能测试，它们也将成为测试套件的一部分，以便开发人员和自动化构建都可以运行它们。如果花费的时间超过了一些预先估计的时间，测试会做一些事情然后失败。

问题是，不同的计算机具有不同的 CPU 速度，并且在后台运行的进程也会减慢执行速度。那么我们应该如何进行这些测试呢？

4

5 回答 5

2

一种策略是为将运行代码的最佳机器设计性能指标；只要它在较差的机器上运行得足够快，就可以保证在生产中具有更好的性能。基本上，包括一个软糖因素，知道它必须在较慢的机器上运行，大概是在测试/开发期间。

另一种策略是在您的测试设置期间进行一些基准测试，并将该时间量用作您的“单位时间”而不是使用秒。例如，使用 dog-slow 递归算法计算第 20 个斐波那契数，然后说所有测试都必须在 10 个“20-fibs”内运行，因此虽然挂钟时间在慢速机器上会变慢，你有一个独立于机器的指标来衡量它的运行情况。

在后台运行的进程更难。显然，您通常不希望其他事情干扰您的测试，因此一种策略是尝试尽可能多地消除它 - 常规开发人员可能会在出现故障时终止某些进程并再次运行，并且您的持续集成框应该是保持相对清晰。

如果这不起作用，或者不够好，你可以尝试相反的方法：在测试的同时运行一堆 CPU/IO 密集型进程来模拟过载的系统，如果测试通过了环境，正常系统下性能应该没问题

于 2011-11-29T16:07:22.150 回答
1

+1 for Sam's response. I've done this a number of times in the past and it's critical to lock down your performance test environment and ensure you're minimizing any potential flux.

Running the tests on devs' systems may be a useful flag for individual devs, but having a central system to run the tests on is critical. One caveat about doing this in VMs: ensure you understand the load on the VM host system because load there can impact performance in the hosted VMs.

I've had the best, most consistent and useful results when I ran these sorts of suites during a nightly smoke check build.

于 2011-11-30T18:42:41.270 回答
1

根据程序的限制资源（I/O、CPU、内存），您可以通过测量使用的 CPU 时间并将其与系统速度进行比较来获得良好的结果。例如，我当前程序的性能测试会获取 CPU 时间，time并从中获取 CPU 速度，/proc/cpuinfo以测量计算所花费的周期数。

这种方法有两个注意事项：首先，它不衡量实现的并行性，其次，它不衡量外部性能因素，如 I/O 使用率。

于 2011-11-29T16:14:39.100 回答
1

如果想法是了解代码更改如何影响性能并确保性能大于或等于以前的版本，那么您需要每次都在已知的硬件配置文件上运行测试。执行此操作的最准确方法是在每次执行测试时设置用于测试的机器。如果许多开发人员需要这样做，有时是同时进行，也许创建一个他们可以启动并指向以执行测试的 VM 映像是值得的。

您不应该在开发人员的盒子上运行这些，因为正如您提到的那样，各种因素都可能影响这些盒子上的测试结果。

您应该避免在来自被测系统外部（低磁盘空间、网络带宽、内存、cpu 等）的负载/压力下尝试测量性能，除非这些条件是作为测试用例的一部分专门设置的。例如，您可以进行 3 次不同的测试运行，一次在机器空载时运行，另一次在中等负载下（模拟在后台运行的其他程序），另一次在高负载下运行。

作为其他压力/性能测试的一部分，您还可以在各种硬件配置文件上运行测试，但您可能不会从针对每个构建运行它们中获得太多价值。但是，同样，如果您希望您可以针对不同的硬件配置文件进行一些不同的测试运行，但这需要更多设置，因为您需要设置额外的机器和/或 VM 映像以及基础设施来启动针对这些机器的测试，收集结果并报告它们。

于 2011-11-29T22:40:32.423 回答
0

这也是一个关于使您的测试有效的容差（或可接受的容量范围）的问题。理想情况下，如前所述，您需要一个可预测、稳定和一致的设置来进行任何有用的比较。也就是说，如果您了解 SUT 的基本操作范围（可用 CPU、可用内存等），那么早期的开发人员测试可以在已知资源容差范围内的系统和条件的混合和匹配上进行。

于 2013-03-29T15:59:05.620 回答