从Linux2.4到2.6内核开发中的改进 （2）

在实际应用中测试

过 去，Linux 内核测试方法围绕开放源代码开发模型进行。由于代码一经发布后就公开给其他开发者进行审查，因此从来没有出现过一个与其他形式的软件开发类似的正式的验证周期。这种方法背后的理论依据是“The Cathedral and the Bazaar”中所谓的“Linus 法则” （请查阅 参考资料 以获得相关的参考），这一法则的内容为“众人的眼光是雪亮的”。换句话说，高力度的审查可以找出大部分真正的大问题。

然而实际上，内核有很 多复杂的相互联系。即使进行了足够力度的审查，还是会漏过很多严重的缺陷。此外，最新的内核一经发布，终端用户可以（也经常是） 下载并使用。2.4.0 发布时，社区中很多人都提议进行更有组织的测试，以保证特定测试和代码审查的强度。有组织的测试包括运用测试计划、测试过程中的可重复性等等。使用所有的三种方法比最初只使用两种方法会带来更高的代码质量。

Linux 测试项目

最早对 Linux 开始进行有组织测试的贡献者是 Linux 测试项目 (Linux Test Project，LTP)。这个项目的目的是通过更有组织的测试方法提高 Linux 的质量。这个测试项目的一部分是自动测试套件的开发。LTP 开发的主要测试套件也叫做 Linux 测试项目。2.4.0 内核发布时，LTP 测试套件只有大约 100 个测试。随着 2.4 和 2.5 版本 Linux 的发展与成熟，LTP 测试套件也正在发展和成熟。当前，Linux 测试项目包括超过 2000 个测试，而且这个数字还在增长!

代码覆盖分析

现在所使用的新工具为内核提供了代码覆盖分析的功能。覆 盖分析告诉我们，在一个给定的测试运行时，内核中哪些行代码被执行。更重要的是，覆盖分析提示了内核的哪些部分还根本没有被测试到。这个数据是重要的，因为它指出了需要再编写哪些新测试来测试内核的那些部分，以使内核可以得到更完备的测试。

持续多日的内核回归测试

在 2.5 的开发周期中，Linux 测试项目所采用的另一个项目是，用 LTP 测试套件对 Linux 内核执行持续多日的回归测试。人们用 BitKeeper 创建了一个实时的、集中的档案库，以随时可以获得 Linux 内核的快照。在没有使用 BitKeeper 和快照时，测试人员不得不等到内核发布后才可以开始测试。现在，内核只要发生了改变，测试人员就可以进行测试。

使用自动化工具来执行持续多日的回归测试的另一个优点是，和上一次测试相比变化较小。如果发现了一个新的回归缺陷，通常会容易地检测出这个缺陷可能是哪个改变导致的。

同 样，由于是最新的改变，因此它在开发者的脑海中印象还比较深 —— 希望这能让他们更容易地记起并修订相应的代码。或许 Linus 法则应该有这样一个结论，有一些缺陷比其他缺陷更容易被发现，因为那些正是持续多日的内核回归测试所发现并处理的那些。在开发周期中和实际发布之前能够每 天进行这些测试，这就使那些只关注完整发行版本的测试者可以将精力集中于更严重和耗时的缺陷。

可扩展测试平台

另外一个名为开放源 代码开发实验室 (Open Source Development Labs, OSDL) 的团队也为 Linux 测试做出了重要的贡献。2.4 内核发布后不久，OSDL 创建了一个叫做可扩展测试平台 (Scalable Test Platform，STP) 的系统。STP 是一个自动化的测试平台，让开发者和测试者可以运行 OSDL 硬件之上的系统所提供的测试。开发者甚至可以使用这个系统来测试他们自己的针对内核的补丁。可扩展测试平台简化了测试的步骤，因为 STP 可以构建内核、设置测试、运行测试，并收集结果。然后得到结果以进行深入地比较。很多人无法接触大型系统，比如具有 8 个处理器的 SMP 机器，而通过 STP，任何人都可以在像这样的大型系统上运行测试，这个系统 (STP) 的另一个好处就在于此。