在树的工具

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

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

在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

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

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

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

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

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

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

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

我曾经做过Linux内核编译，并对Android (Android 6.0 (Marshmallow)和Android 7.0 (Nougat))做过一些修改，其中我使用的是Linux版本3。我在Linux系统上交叉编译它，手动调试错误，然后在Android上运行它的引导映像文件，检查它是否进入了一个漏洞。如果它运行完美，则意味着它根据系统需求进行了完美的编译。

用于MotoG内核编译

注意:Linux内核将根据依赖于系统硬件的需求进行更改

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

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

LTP和memtest通常是首选工具。

除了其他答案外，本文更强调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.