背景
本页面介绍了人们在进行自动化性能测试时可能会遇到的各种使用场景。
描述这些用例的一个原因是记录 Fuchsia 工具为其提供服务的程度。其中一些用例比其他工具更适合使用 Fuchsia 当前工具。
描述这些用例的更广泛原因是为了帮助我们介绍测试。一个人想要用于测试的用例可能不同于另一个人想要的用例。
如果某人在编写测试时脑海中想到了一些用例，那么在将测试发送给审核人员以供代码审核或寻求帮助时，明确声明这些用例可能会很有帮助。
测试的用例与我们如何处理其结果中的回归问题有关，而这又受我们测量性能的方式的限制以及用于检测回归和改进的统计测试的限制的影响。
例如，大量可用于比较用例的测试（见下文）可能会因统计信息中存在多比较问题而产生较高的错误回归警告。因此，这组测试对于检测回归可能不是很有用。我们可能会发现，只有较大的回归才是可行的，而小的回归警告通常是虚假的，可以忽略。
此处介绍的一些用例重叠 - 它们并不是互斥的。
用例
检测回归问题（提交后或提交前）：我们通常使用 Chromeperf 和罪魁祸首工具检测提交后问题。预提交检测只能通过 perfcompare 选择启用，默认情况下不会应用。
- 检测由于许多更改的累积影响而产生的逐渐回归（爬行）。我们目前没有任何自动化工具可以执行此操作。Chromeperf 的检测算法仅查找由单个修订版本或单个时间点引入的回归问题。
测试潜在的改进：即测试旨在提高性能的更改的效果。这可以使用 perfcompare 来实现。
比较案例：即比较相关测试用例的相对性能。
这可用于查找相对于其他用例出乎意料的情况，因为我们可能需要修复这些情况。例如，针对 FIDL 编码和解码的性能测试就将其用作了一个用例。
此 API 也可用于衡量操作或子系统的费用，而无需使用性能剖析。例如，IPC 往返微基准可以测量使用各种不同内核和用户空间 IPC 操作的线程或进程之间的往返时间。通过使用和不使用 FIDL 进行测试，我们可以估算 FIDL 和其他 userland 库在内核 IPC 基元的基础上增加的开销。同样，通过在进程之间和进程中的线程之间测试 IPC，我们可以估算在地址空间之间切换的上下文切换的成本。
提供关于其他回归的线索：指标 A 中的回归可能不是我们关注的方面，但它可能很有用，有助于揭示指标 B 中回归问题的线索。此使用场景与性能剖析类似，但更通用。
例如，如果每秒帧数指标下降，我们可以通过帧构建时间指标来了解该指标是否也有所变化。
性能剖析：即分析测试中时间或内存用量的明细。
虽然 Linux 具有用于对 CPU 时间使用情况进行统计分析的 perf 和 OProfile 等工具，但 Fuchsia 目前没有等效工具。
无论是自动测试还是手动测试，通常使用 Fuchsia 的跟踪系统来检查时间使用情况的明细。（因此，与手动测试相比，自动化测试的优势在于可重现性更高、运行工作量更少。）不过，Fuchsia 的跟踪系统与 Perf 和 OProfile 等统计性能剖析工具有两处差异：
- 跟踪功能仅会记录带有注释以便生成跟踪事件的代码的时间使用情况。
- 跟踪记录的典型用途是手动检查它们或从中提取一组固定指标（例如“每秒帧数”和“帧构建时间”）。对于通常由性能剖析工具生成的此类统计信息，我们还没有相应的工具用于生成此类统计信息。
请注意，
fuchsiaperf文件周围的基础架构并不适合记录分析数据。它不适合记录大量描述时间或内存使用情况的指标。为设计决策提供依据：子系统的性能特征决定了我们如何使用子系统。如果子系统运行缓慢，我们或许可以避免使用该子系统，在该子系统上构建一个层（例如缓存），或以其他方式解决该问题。
“每个程序员应该知道的延迟时间数字”表就是此用例的一个示例。请参阅表的这个近期版本。
这个表格的早期版本出现在 Jeff Dean 的演讲（斯坦福 CS295 课堂讲座，2007 年春季）中，他在该讲座中提倡编写微基准，以建立效果估算基础，从而建立效果估算基础。此表格存在多个更新版本；请参阅此 Stack Exchange 问题，了解更多讨论内容。