在树的工具

在内核中找到测试工具的一个好方法是:

做出帮助并阅读所有目标 在工具/测试下面找找

在4.0版本中，这导致我:

在工具/测试/自我测试下进行自我测试。运行make selftest。必须运行已构建的内核。请参见:Documentation/kselftest.txt, https://kselftest.wiki.kernel.org/ 工具/测试/ Ktest下的Ktest。参见:http://elinux.org/Ktest, http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest make help的静态分析器部分，其中包含如下目标: linux源代码中的checkstack.pl做什么? 双球菌检查(askb提及)

内核CI

https://kernelci.org/是一个旨在使内核测试更加自动化和可见的项目。

它似乎只做构建和引导测试(TODO如何自动测试引导工作，源代码应在https://github.com/kernelci/)。

Linaro似乎是这个项目的主要维护者，有许多大公司的贡献:https://kernelci.org/sponsors/

Linaro洗

http://www.linaro.org/initiatives/lava/看起来像一个CI系统，专注于开发板和Linux内核。

可怜的丽莎

https://github.com/ARM-software/lisa

不知道它具体做了什么，但它是由ARM和Apache授权的，所以可能值得一看。

演示:https://www.youtube.com/watch?v=yXZzzUEngiU

一步调试器

不是真正的单元测试，但在测试开始失败时可能会有所帮助:

QEMU + GDB: https://stackoverflow.com/a/42316607/895245 KGDB: https://stackoverflow.com/a/44226360/895245

我自己的QEMU + Buildroot + Python设置

我还开始了一个专注于易于开发的设置，但我最终也添加了一些简单的测试功能:https://github.com/cirosantilli/linux-kernel-module-cheat/tree/8217e5508782827320209644dcbaf9a6b3141724#test-this-repo

我没有非常详细地分析所有其他设置，它们可能比我的设置做得更多，但是我相信我的设置非常容易快速开始，因为它有很多文档和自动化。

还有:

MMTests是用来分析结果的基准测试和脚本的集合。

它是Linux系统调用模糊测试器。

此外，SourceForge的LTP页面已经相当过时，项目已经转移到GitHub。

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

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

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

内核测试过程。

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

自动化内核测试并不容易。大多数Linux开发人员自己进行测试，就像adobriyan提到的那样。

然而，有一些事情可以帮助调试Linux内核:

kexec: A system call that allows you to put another kernel into memory and reboot without going back to the BIOS, and if it fails, reboot back. dmesg: Definitely the place to look for information about what happened during the kernel boot and whether it works/doesn't work. Kernel Instrumentation: In addition to printk's (and an option called 'CONFIG_PRINTK_TIME' which allows you to see (to microsecond accuracy) when the kernel output what), the kernel configuration allows you to turn on a lot of tracers that enable them to debug what is happening.

然后，开发人员通常会让其他人检查他们的补丁。一旦补丁在本地被检查，并且没有干扰其他任何东西，并且补丁被测试与来自Linus的最新内核一起工作而没有破坏任何东西，补丁就会被推送到上游。

这里有一个很好的视频，详细介绍了一个补丁在集成到内核之前所经历的过程。

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

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

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

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

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

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

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

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