每项性能测试都应附带英文说明，描述测试所衡量的内容（通常用一句话说明）。
例如，“使用 Zircon 通道测量进程之间 IPC 往返所用的时间”。
一种例外情况是小测试（主要是一行代码），其中代码不需要汇总。对于非常相似的测试系列，只需要一条说明。
说明测试的预期用例可能也很有用。请参阅性能测试的潜在用例列表。
理由
对性能测试比对正确性测试（通过或失败测试）更重要，因为对性能测试的解释比对通过或失败结果更精细。
例如，如果您的 CL 破坏正确性测试，使测试始终失败，则明确您必须找到一种方法让测试通过，或移除测试。相比之下，如果 CL 使测试速度减慢 10%，就不清楚这一点是否重要。如果某项更改会导致测试速度减慢 1% 的 50%，那么就更不清楚是否应将其视为重要了。
此外，代码库中的内容可能比正确性测试的通过或失败结果更多，这会影响性能测试的结果。更确切地说，您可以通过多种方式更改代码库，这些方式不会影响正确性，但会影响性能。
这往往意味着，对于给定测试的通过或失败结果，需要解读性能结果的人更多。例如，如果对组件 A 的更改导致组件 B 的性能测试回归，那么这些性能测试的含义可能需要由组件 A 的维护者和组件 B 的维护者来解读，以及对提交后性能回归问题进行分类的其他人员来解读。
因此，记录性能测试的标准应高于正确性测试的记录标准。
有关测试衡量内容的描述通常比测试代码短得多，因此提供描述可能有助于开发者避免花费大量时间阅读代码，以了解测试要衡量的内容。
位置信息
性能测试的说明可以放在测试代码的注释中，也可以放在附近的 Markdown 文件中。
我们目前还没有性能测试及其说明的可浏览列表，也没有从代码中提取测试说明的方法，但将来可能会添加其中之一。
示例
Fuchsia 微基准的示例：
“使用 Zircon 通道测试 IPC 往返（客户端和服务器均使用 Zircon 端口等待）。”
（来源：适用于 IPC 往返时间的 Microbenchmark，src/tests/microbenchmarks/round_trips.cc）
“测量在单个线程上加入队列，然后将消息从 Zircon 通道出列所需的时间。但这不涉及任何跨线程唤醒。”
（来源：适用于渠道的 Microbenchmark、src/tests/microbenchmarks/channels.cc）
存储性能测试的示例：
“测量无任何显式同步或刷新的情况下，使用系统文件系统将大小为 8KiB 的块写入新创建的文件所用的时间。生成的指标是每个块的写入返回所用的时间。”
（来源：旧版 garnet/bin/odu/README.md；当前说明更长）