开源开发实验室 (OSDL) 是一家致力于增强 Linux 可扩展性和电信功能的非营利公司。OSDL 赞助商 (www.osdlab.org/sponsors) 资助了一个全面的测试和开发实验室，配备了 TB 级的存储空间和一系列 CPU 数量从 2 个到 16 个不等的 SMP 服务器。在实验室中，我们为开发人员提供通过远程登录完全访问企业级机器的权限。

我们一直与开发人员合作进行测试的创建和执行。在此过程中，我们注意到许多对于通过实验室的每个测试都必须重复完成的事情。我们列出了运行平均测试序列的任务，并发现该过程的很大一部分涉及到可以自动进行的人工交互。“可扩展测试平台”(STP) 是我们尝试自动化从请求到报告的测试过程的结果。

基准测试本身存在固有的概念问题，这些问题既不在本文的范围之内，也不在可扩展测试平台工作的范围之内。然而，当前的测试实践中存在一些可解决的问题，而这正是 STP 试图解决的问题。请记住，我们关注的基准测试与用于获得可销售基准数字的方法完全不同。

测试环境的配置很少像应有的那样有完善的文档记录。关于测试中使用系统的设置文档通常仅限于测试人员认为与其特定研究目标相关的部分。这种细节的缺乏会在以后分析师检查报告时引起问题。分析师不得不重复整个测试序列以获得回答稍后出现的问题所需的数据，这并非罕见。测试设置也通常只是部分自动化，在未记录的时刻产生的人工交互也会影响结果的可重复性。

性能测试可能需要大量的资源，包括时间和硬件。有多少开源开发人员可以访问千兆网络上的 50 台双路客户端服务器，以便测试由多台 8 核 CPU 服务器和一台 16 核 CPU 服务器组成的服务器群？很少有公司会慷慨地提供对这类硬件的访问权限，而且即使提供，也需要配备完整的管理人员，并需要潜在的收入回报来证明支出的合理性。一个没有访问此类硬件的开发人员提出的好主意很可能仍然未被探索。

目前，对于性能、稳定性和标准合规性测试，没有集中的、有完善文档记录的结果存档。研究人员被迫运行自己的测试，或者从平庸的结果中挑选，以得出不太准确的猜测。系统管理员没有一个中心位置可以查找关于内核、发行版和硬件的组合在类似于他们预期的工作负载下往往表现良好的入门信息。这种可用研究的缺乏导致了关于众多 Linux 选择的性能和可靠性的困惑。

Linux 内核开发人员无法花费时间和精力在其补丁上运行长时间的性能和稳定性测试。即使开发人员愿意花费时间测试补丁，测试软件通常也需要大量的知识和专门的硬件才能安装和配置。有时，这种情况会导致问题被引入到稳定和开发内核树中。这也可能导致先前解决的问题在未来的开发中再次出现，但由于缺乏回归测试而未被注意到。

许多开发人员在 Linux 内核邮件列表中发声，要求为新补丁制定标准测试程序。许多用户和开发人员都认为，一个简单的程序，包括性能、稳定性、标准合规性和回归测试，将有益于 Linux 内核开发。

虽然你无法测试出所有错误，但你可以检查常见类型的问题。在发现并修复错误后，通常很容易将回归测试用例添加到你的测试套件中。问题不在于创建这些测试。大多数开发人员都意识到，拥有一些可用的综合测试是个好主意，并且经常这样做。问题在于，大多数开发人员不能或不愿意花时间配置全方位的验证测试。虽然编码可能很有趣，但测试通常相当枯燥。如果开发人员可以轻松地请求对其代码进行全面测试，然后在别人做脏活累活时继续工作，我们认为他们会更倾向于尝试对其补丁进行验证运行。

STP 是用于自动化测试的硬件和软件配置。为了运行测试的后端控制和脚本，我们开发了 Brimstone，一个组合的批处理控制系统和自动化测试框架。请求使用 Eidetic（一个用户友好的 Web 前端）或 brim-gate（电子邮件网关）提交。使用这些前端，可以在不到两分钟的时间内请求整个测试序列。

STP 的工作原理始于开发人员将补丁签入我们的内核 CVS 树，并使用他们的补丁请求测试序列。测试完成后，详细结果将通过电子邮件返回给开发人员，并存档在我们的网站上。为了进一步简化流程，开发人员可以编写一个简短的 shell 脚本，该脚本在不到五行代码中，可以将他们的补丁签入 CVS，并通过电子邮件提交预格式化的测试请求。然后，检查其补丁有效性所需的只是一条命令。完整规模测试运行中涉及的一切都将得到处理，而无需考虑其他事情。

OSDL 为 STP 提供的硬件包括 1.8TB 的网络连接存储设置，通过多条光纤通道连接连接到每台服务器（四核 CPU 及以上）。服务器包括各两台 2 核 CPU、4 核 CPU 和 8 核 CPU 的机器，以及一台 16 核 CPU IBM NUMA-Q 服务器。第二台包含 Itanium CPU 的 16 核 NEC AzusA 服务器正在订购中。我们还有 50 多台客户端负载机器，只需按一下键即可将其移入 STP。我们还在研究是否可以加入一些单核 CPU 机器，以确保内核修改不会对当前绝大多数安装产生不利影响。

Eidetic、Brimstone 和电子邮件网关都在 GPL 许可下，因此有兴趣的各方可以在建立自己的专业测试实验室时使用它们。

第一步是通过免费注册成为 OSDL 实验室助理，网址为 www.osdlab.org。接下来，通过网页输入测试请求，这将涉及到以下内容：选择要运行的内核标签（例如 2.4.8），选择要使用的发行版，选择要运行的测试，列出 CPU 详细信息，列出各种硬件限制（可选），并输入可选的 LILO 命令行（允许限制使用的 RAM）。提交基本项后，您需要花一些时间填写您选择的测试的设置页面，然后提交最终请求。

就这么简单。根据完成所请求类型的测试所需的时间长短，您可以在不到 25 分钟内收到回复。完整的环境文档和结果数据集将存档在网站上供您使用。简短的测试至少需要 15 分钟，因为在每个测试序列之前都会安装一个全新的操作系统副本。

由于整个过程是自动化的，因此测试不会在我们办公室关门时停止。这意味着，对于位于世界任何地方的开发人员来说，快速响应在任何时候都是可能的。

由于 STP 目前处于初步推广阶段，因此脚本化测试的数量仍然很少。在撰写本文时，以下是可能的负载示例列表：Juan Quitela 的“memtest”VM 滥用测试套件、dbench (Samba) 文件系统惩罚、一直很流行的脚本化内核编译、模拟真实世界的 CVS 惩罚和 lmbench。

目前正在评估一份潜在测试的长列表，其中包括涉及多台服务器和应用程序（如 Apache 和 MySQL）的场景。当然，作为一个开源项目，我们欢迎在这些测试的自动化方面提供帮助。为 STP 准备全方位的测试将是一项重大任务，但我们相信这对 Linux 的好处将是值得的。对我个人而言，这就是我希望为 Linux 社区做出一些积极影响的地方。

我们还与来自 SGI 和 IBM 的开发人员在 Linux 测试项目 (LTP) 中积极合作。当前的目标之一是扩大 LTP 的覆盖范围，以包括有针对性的和通用的工作负载模拟测试。LTP 内核功能测试几乎已准备好自动化，这将为我们提供一个大型回归测试套件，以及稳定性研究的坚实基础。LTP 的未来计划包括开发许多独立的测试，这些测试将成为 STP 的绝佳测试目标。