Triaging new crashes

ClusterFuzz的建立是为了尽可能地减轻fuzz中的人工工作。特别是bug分类，一直是一个困难和需要手动处理的过程。

Filtering testcases

ClusterFuzz对每个测试案例进行分析。比如，ClusterFuzz可以通过crash类型来确定一个crash是否有影响。

测试案例页面提供对测试案例的过滤和搜索功能。

你可以通过以下几种方式过滤：

默认情况下，只有享有特权的用户才可以看到具有安全影响的问题。可以在不泄露敏感信息的情况下向一些用户授予访问权。参见访问控制，给予更细化的访问。

虽然只适用于稳定复现crashes,但是回归测试范围往往是最有用的分类信息。它显示了该问题被引入的提交范围。

构建版本的频率越高，范围就越窄。如果你归档了你构建的每一个版本，ClusterFuzz就可以准确指出引入错误的commit。

当使用sanitizers时，bug和崩溃栈信息有关，可以帮助你确定崩溃的原因。这更像是一门艺术，而不是一门精确的科学，没有一个过程可以遵循，利用这些信息找到一个罪魁祸首的变化列表。

也就是说，在回归范围内寻找更改崩溃栈信息中所看到的相同文件的变化（如果有的话），往往是有帮助的。否则，”git blame “或类似的工具可能有助于找到一个更熟悉相关代码的开发者。这个开发者可能是一个很好的第一联络点。

ClusterFuzz还提供了关于问题发生频率和条件的统计。例如，ClusterFuzz会跟踪问题在哪些平台上重现以及哪些模糊器发现了这些问题。

这些有时会对其他方法失败的bugs提供有用的信息。例如，如果不能直接修改崩溃栈中的一个文件，但你发现它只在一个特定的平台上重现，那么该平台上的一个大的行为变化可能是造成crash的原因。对于一个无法重现的crash，知道它在3天前开始发生，与一个危险的变化同时发生，可能会很有用。