在我们公司，我们有单元测试。 我们正在考虑编写一些自动化性能测试，这些测试也将成为测试套件的一部分，因此开发人员和自动构建都将运行它们。测试会做一些事情，如果超过一些预先估计的时间则会失败。
问题是，不同的计算机具有不同的CPU速度，并且在后台运行的进程也会降低执行速度。那么我们应该如何进行这些测试呢？
答案 0 :(得分：2)
一种策略是为代码运行的最佳机器设计性能指标;只要它在较差的机器上运行得足够快，就可以保证在生产中具有更好的性能。基本上，包括一个软糖因素，知道它必须在较慢的机器上运行，大概是在测试/开发过程中。
另一种策略是在测试设置期间进行一些基准测试，并将该时间量用作“单位时间”而不是秒。例如，使用dog-slow递归算法计算第20个Fibonacci数，然后说所有测试必须在10“20-fibs”内运行，所以虽然在慢速机器上挂钟时间会慢一些，你有一个独立于机器的指标来衡量它的运行情况。
在后台运行的进程更难。显然你通常不希望其他事情干扰你的测试，因此一种策略是尽可能地尝试消除它 - 常规开发人员可能会杀死某些进程并在出现故障时再次运行，并且你的持续集成框应该是保持相对清晰。
如果这不起作用，或者不够好，你可以尝试相反的方法：在测试的同时运行一堆CPU / IO密集型进程来模拟一个过载的系统，如果测试通过该环境，在正常系统中性能应该没问题
答案 1 :(得分：1)
根据程序的限制资源（I / O，CPU，内存），通过测量使用的CPU时间并将其与系统速度进行比较，可以获得良好的结果。例如，我当前程序的性能测试使用time获得花费的CPU时间，并从/proc/cpuinfo获取CPU速度以测量计算所花费的周期数。
这种方法有两个注意事项：第一，它不测量实现的并行性，其次，它不测量外部性能因素，如I / O使用。
答案 2 :(得分：1)
如果想要了解代码更改如何影响性能并确保性能大于或等于以前的构建，那么您需要每次都在已知的硬件配置文件上运行测试。最准确的方法是设置每次执行测试时用于测试的机器。如果许多开发人员需要同时执行此操作，可能同时创建一个可以旋转并指向测试执行的VM映像是值得的。
你不应该在开发者盒子上运行这些，因为你提到各种因素都会影响这些盒子上的测试结果。
在测试系统外部（低磁盘空间，网络带宽，内存，CPU等）的负载/应变下，应避免尝试测量性能，除非这些条件是作为测试用例的一部分专门设置的。例如，您可以进行3次不同的测试运行，一次是机器空载，另一次是中等负载（模拟后台运行的其他程序），另一次是高负载。
您还可以在各种硬件配置文件上运行测试，作为其他压力/性能测试的一部分，但您可能无法从针对每个构建运行它们中获得太多价值。但是，如果您希望您可以针对不同的硬件配置文件执行一些不同的测试运行，则需要更多设置，因为您需要设置其他计算机和/或VM映像以及基础设施来启动针对这些计算机的测试，收集结果并报告。
答案 3 :(得分：1)
+1对Sam的回应。我过去已经多次这样做了，关键是要锁定你的性能测试环境并确保你最小化任何潜在的通量。
在开发者系统上运行测试对于各个开发人员来说可能是一个有用的标志，但是拥有一个运行测试的中央系统是至关重要的。关于在VM中执行此操作的一个警告：确保您了解VM 主机系统上的负载，因为那里的负载可能会影响托管VM中的性能。
当我在夜间烟雾检查构建期间运行这些套房时，我获得了最好，最一致和最有用的结果。
答案 4 :(得分：0)
这也是一个关于公差（或可接受的容量范围）的问题，它将使您的测试有效。理想情况下，如上所述，您需要一个可预测，稳定和一致的设置，以进行任何有用的比较。如果您了解SUT的基本操作范围（可用的CPU，可用的内存等），那么早期的开发人员测试可以在已知资源容差范围内的系统和条件的混合和匹配上完成。