据我所知，英特尔有一个自动性能回归检查工具(名为lkp/0 day)运行/资助。它将测试发送到邮件列表的每个有效补丁，并检查从不同的微基准测试(如hackbench, fio, unixbench, netperf等)更改的分数。

一旦出现性能下降/改进，相应的报告将直接发送给补丁作者和Cc相关的维护者。

除了其他答案外，本文更强调Linux内核的功能测试、硬件认证测试和性能测试。

大量的测试实际上是通过脚本、静态代码分析工具、代码审查等进行的，这对于捕获错误非常有效，否则会破坏应用程序中的某些东西。

稀疏-一个开源工具，旨在发现Linux内核中的错误。

Coccinelle是另一个程序进行匹配和转换引擎，它提供了语言SmPL(语义补丁语言)，用于在C代码中指定所需的匹配和转换。

checkpatch.pl and other scripts - coding style issues can be found in the file Documentation/CodingStyle in the kernel source tree. The important thing to remember when reading it is not that this style is somehow better than any other style, just that it is consistent. This helps developers easily find and fix coding style issues. The script scripts/checkpatch.pl in the kernel source tree has been developed for it. This script can point out problems easily, and should always be run by a developer on their changes, instead of having a reviewer waste their time by pointing out problems later on.

Linux内核非常重视社区测试。

通常，任何开发人员都会在提交代码之前测试他们自己的代码，而且他们经常会使用Linus的内核开发版本，或者其他与他们工作相关的项目的不稳定/开发树之一。这意味着他们经常测试自己的更改和其他人的更改。

通常没有太多正式的测试计划，但是在将特性合并到上游树之前可能会要求进行额外的测试。

正如Dean所指出的，还有一些自动化测试:Linux测试项目和内核Autotest(很好的概述)。

开发人员通常还会编写针对测试他们的更改的自动化测试，但我不确定是否有一种(经常使用的)机制来集中收集这些临时测试。

当然，这在很大程度上取决于内核的哪个部分正在被更改——您为一个新的网络驱动程序所做的测试与替换核心调度算法时所做的测试是完全不同的。

adobriyan提到了Ingo的随机配置构建测试循环。现在，零日测试机器人(又名kbuild测试机器人)几乎涵盖了这一点。这里有一篇关于基础结构的不错的文章:内核构建/引导测试

这种设置背后的想法是尽快通知开发人员，以便他们能够尽快纠正错误(在某些情况下，在补丁进入Linus的树之前，因为kbuild基础设施也会针对维护人员的子系统树进行测试)。

一旦贡献者提交了他们的补丁文件并发出了合并请求，Linux看门人就会通过集成和审查补丁来检查补丁。一旦成功，他们将把补丁合并到相关的分支中，并发布一个新版本。

Linux测试项目是提供在应用补丁后针对内核运行的测试场景(测试用例)的主要来源。这可能需要大约2 ~ 4个小时，这取决于情况。

请注意所选内核将要测试的文件系统。 例如:ext4生成的结果与ext3不同，依此类推。

内核测试过程。

从存储库(Linux内核档案或GitHub)获取最新的内核源代码 应用补丁文件(使用diff工具) 构建新内核。 针对LTP (Linux测试项目)中的测试过程进行测试

我可以想象他们使用虚拟化来进行快速测试。它可以是QEMU、VirtualBox或Xen之类的东西，以及一些执行配置和自动化测试的脚本。

自动化测试可能是通过尝试许多随机配置或少数特定配置(如果他们处理特定问题)来完成的。Linux有很多低级工具(比如dmesg)来监视和记录来自内核的调试数据，所以我认为也会使用它。