基准测试（Benchmarks）不必消亡

重点摘要

• 基准测试帮助社区把他们对用户行为的理解编码
• 所有基准测试面对愚弄和作弊都会显得不堪一击
• 跟踪和性能分析可以替代测试中老旧过时的用户行为模型
• 没有可以在不同项目间共享跟踪数据的常用工具
• 测试能够作为性能退化测试的一部分永远存在下去

Chromium 项目近期宣布他们将要弃用一个传统的 JavaScript 基准测试，Octane，主张通过跟踪和性能分析收集真实场景下的性能测量数据来驱动性能提升。这种性能指标，是通过对用户的跟踪和分析收集而来的。

对于弃用 Octane，他们给出的理由是，使用传统的基准测试测出的 JavaScript 性能表现已经到了稳定期，而且最终，开发者总会找到愚弄这些基准测试的方法。

不过，尚在快速演进 JavaScript 社区之外的跟踪和是否就是性能工程的未来呢？是否一切基准测试都有保质期呢？

基准测试

所有优秀的基准测试都在模拟真实世界的工作负荷。它们内置有对诸如执行时间、延迟和吞吐量、以及每秒操作次数等指标的测量能力，这种测量能力能让开发者了解他们软件的表现。

本质上说，基准测试的目的是允许用户在不同软件版本和配置之间进行比较。以完全相同的工作负荷排除掉其他因素，从而能够单独比较代码上的区别。

拥有一个封装好的的工作负荷对于软件优化工作的编写和测试是无价之宝，因为它能让开发者感知到他们所做的改变对用户体验的影响。基准测试是仲裁者。开发者们判断自己所做的改变对性能表现的影响是好是坏，还有最终，对用户的影响是好是坏。基准测试结果上 15% 的提升，可能转化为网页加载时间上 25 毫秒的缩短。

很多备受欢迎的项目就是这样完成性能优化的：选择一个基准测试工具然后开始优化那些被历经的代码路径，直到性能得到显著提升。如果没有现有的基准测试工具可用，有些项目组甚至会自行编写基准测试工具。

用人工或综合的方式测试某个特定的部件的基准测试，被称为微基准测试（Micro-Benchmark）。微基准测试在一些方面非常有用，比如理解软件将来会如何规模化，或者了解某个部件的绝对最高性能表现，即使如今已经不可能让该部件达到最大负载。

当使用全面基准测试过于麻烦的时候，使用微基准测试对于指导软件优化是有帮助的。举一个例子，当你需要对一个没有开放 API，且需要被直接访问的缓存层进行性能提升的时候。又或者，当一个开发者想要重现一个很难触发的性能问题的时候。

微基准测试有一个难以编写正确的坏名声，然而也存在着很多他们被成功用来获得性能增益的例子。

基准测试不仅对提升性能有帮助，他们也可以被用做退化测试的基准，以保证即使代码发生变化，性能表现也可以保持稳定。考虑到性能表现不像正常 / 异常这种二元状态，不能明显的观测到是否出现倒退现象，因此系统化的性能退化跟踪对于成熟的项目成熟的项目非常重要。

也许最重要的一点是，发布精心设计的基准测试可以整合全社区对有趣的工作负载和用户行为的理解。基准测试可以指导所有开发者（特别是新来的那些）去提高那些最重要的代码，由于最佳的优化，就是找出那些普遍存在的情形，并为之做出调整。

然而，如同 Google Chromium 团队指出的那样，基准测试存在着很多的缺点。

如果一个基准测试不再能够代表项目相关的工作负荷，或者更糟，它从来不能，那么那些以基准测试有效为前提编写的代码，将不得不被重写。这些之前编写的代码很可能是对开发时间的巨大浪费。

有的时候，你最好的选择是从头重写一个全新的基准测试，而不是更新已有的那个。

但是即使你的基准测试可以准确重现目前的用户行为，它的配置信息也可能会复杂到让很多人无法正确使用。基准测试越复杂，出现这种情况风险越大。参数可以被无脑的复制黏贴，极少甚至完全不考虑这些配置参数对目前被测的软件是否有意义。

并不是所有人在运行基准测试时都怀着最好的出发点，有些人会有意的尝试利用每一个漏洞来获得好处。有些基准测试一直致力于通过限定允许标志的方式来阻止编译器过度的优化代码。深度优化会让编译器消除或简化生成的代码并违背了基准测试的本意。

当所做的一切都纯粹是为了更好的测试分数而非用户时，这中行为被称作愚弄测试（Gaming the benchmark）或者针对测试的优化，这种优化被称作 “基准测试专用优化”。Chrome V8 JavaScript 引擎包含着一个 SunSpider 测试的专用优化。

“V8 使用一个相对简单的技巧：既然每个 SunSpider 测试都在一个新的