谷歌Linux内核自动测试平台架构介绍-用自动测试测试难以测试的问题

Autotest要满足的最基本要求是提供一个在机器上运行测试的环境，并满足以下标准：

• 最低的裸机访问权限。
• 测试结果以标准的机器可读方式提供。
• 框架外开发的标准测试可在框架内轻松运行。

在编写针对内核和硬件本身的测试时，第一条标准（底层系统访问）似乎是不言而喻的。要测试系统的特定组件，必须使用能访问该组件标准应用程序接口的工具来编写测试。由于 C 语言是系统领域的通用语言，因此C API通常是可用的，但即便如此，情况也并非总是如此。在测试过程中创建文件系统时，mkfs将是最简单、最容易使用的机制；因此，除了能够轻松集成自定义C语言外，框架还必须能够轻松与外部工具配合使用。

用C语言编写框架本身可以满足最初的要求，但这最终会与Autotest期望满足的其他要求相冲突。首先，这最终会增加调用外部应用程序的难度；虽然fork、exec、popen和system等函数提供了启动外部进程并从中收集结果所需的所有基本机制，但与Python之类高级脚本语言相比，在C语言中使用这些函数需要大量的模板。如果需要以任何方式对执行进程的输出进行操作和/或解析，情况就会更加如此。第二个要求是以标准方式记录测试结果，这几乎保证了测试需要进行字符串操作，而使用脚本语言又简化了这项工作。

为了满足这些相互矛盾的要求，自动测试框架本身是用Python编写的，并提供了一些实用程序来简化C代码的编译和执行。测试本身是通过创建Python模块来实现的，该模块定义了一个测试子类，满足标准化的预定义接口。单个测试被打包在一个目录中，并可与所需的其他资源（如数据文件、需要编译和执行的 C 代码，甚至是预编译的二进制文件）一起打包。

这也满足了三项要求中的第三项，即运行独立于Autotest编写的标准测试的能力。只需将测试所需的组件与一个简单的Python封装器捆绑在一起即可。封装器负责设置必要的环境，执行底层测试，并将测试产生的结果转换为Autotest标准日志调用。封装器通常非常简单；在当前的Autotest发行版中，测试封装器的中位数仅为38行。

使用Python实现测试还为捆绑测试套件或定制特定测试的执行提供了一种简单的机制。测试本身是通过编写"控制文件"来执行的，而"控制文件"只是一个在预定义环境中运行的Python 脚本。它可以是一行"执行此测试"，也可以是执行整个测试序列的更复杂脚本，甚至可以是根据机器上运行的硬件和内核有条件地执行测试的脚本。Autotest提供的环境还包含其他实用程序，允许控制文件，使机器进入执行测试所需的任何状态，即使这需要安装内核和重启机器。有了Python的全部功能，测试运行人员无需学习自定义作业控制语言，就能执行无限的自定义操作。

不过，这种强大的功能也有一个很大的缺点。由于Python的动态特性和控制文件的强大功能，不可能静态地确定作业的许多信息。例如，我们不可能事先知道作业将运行哪些测试，事实上，运行的测试集可能是非确定的。这种限制还没有严重到超过这种方法的好处。

4.1 安装问题

随着该系统在谷歌投入使用，将Autotest安装到测试机器上很快就成为一个严重的性能问题。允许测试开发人员将数据、源代码甚至二进制文件与他们的测试捆绑在一起，虽然方便了测试的编写，但却使安装量急剧增加。这种情况可以通过尽量减少安装频率来缓解，但实际上，这只有在测试框架可以预先安装到系统上的情况下才会有所帮助。

解决这个问题的方法相当标准：与其将Autotest及其测试套件视为一个单一的软件包，不如将其拆分成一系列软件包：

包含框架本身的核心软件包
用于各种实用程序和依赖项（如剖析器、编译器和任何需要安装的非标准系统实用程序）的软件包
用于单个测试的软件包
每个软件包都可以将其他软件包声明为依赖项。核心软件包可以随处安装，而且相当轻量级，只包含一组Python源文件，不包含某些测试所需的重量级数据和二进制文件。在执行任务时，框架可以动态下载并安装执行特定测试所需的任何软件包。

5 Autotest服务器

Autotest 客户端为运行底层测试提供了足够的基础架构，但它只能在单台机器上执行测试并收集结果。要在多种硬件配置上测试内核，测试人员需要在多台机器上安装测试客户端，在每台机器上手动运行作业，并检查分散在这些系统上的结果。

这一缺陷导致了Autoserv（自动测试服务器）的开发，它是围绕客户端设计的一个独立层。它允许用户通过在测试机以外的机器上执行服务器进程来运行测试。

服务器进程将通过SSH连接到远程测试机，安装Autotest客户端，在客户端上运行一项作业，然后从测试机上提取结果。将这些服务器运行本地化到单台机器上，允许用户在任意机器集上运行测试作业，同时将所有结果收集到一个中心位置进行分析。

5.2 恢复失败的测试系统

一旦用户开始在更多机器上运行测试，处理系统崩溃的情况就会变得更加常见。随着测试机器数量的增加，坏内核（和随机机会）将导致更多的系统故障。在单台机器上进行测试时，人工干预是处理故障的最简单方法，但这种方法无法扩展到成百上千台机器。因此，自动化就变得非常必要，它有两个主要要求：

自动检测和报告测试机故障
提供修复损坏系统的机制
完全在测试机上运行的客户端内处理这些要求是不切实际的；当崩溃导致测试机上的测试进程被杀死时，检测和报告内核崩溃或硬件故障甚至都是不可能的。同样，修复可能需要重新映像机器，这将导致客户端本身瘫痪。

有了远程机器控制的任务执行，处理这些要求就变得可行了。Autoserv支持监控串行控制台输出、网络控制台输出和/var/log中的一般系统日志输出。它还能与收集崩溃转储的外部服务交互，甚至在有能力的情况下对机器进行电源循环。在最糟糕的情况下，服务器进程至少可以清楚地记录作业（以及正在运行的任何测试）的失败，以及失败测试机的最后已知状态。还可以执行自动修复。这在Autoserv中是以升级方式实现的，首先是多次尝试将机器恢复到已知的良好状态，然后是选择性地调用任何本地基础设施对机器进行完全重新安装，最后在必要时将修复过程升级到人工操作。当系统被错误的内核（或错误的测试）破坏时，在大量机器上进行测试就变得更加实用了只需最少的人工干预，就能使被错误内核（或错误测试）破坏的系统恢复工作状态。

5.3 多机测试

远程控制测试的执行也为跨多机运行单个测试提供了机会。虽然可以通过在主测试系统上运行Autotest客户端，并由其驱动其他从测试系统来实现，但这需要将服务器上的大部分"远程控制"基础设施直接复制到客户端。从安全的角度来看，这也可能会造成问题，因为测试机之间的相互访问将更加自由，而不是通过单个服务器进行控制。

既然Autotest已经确定了对独立服务器机制的需求，那么自然要对其进行扩展，以支持"服务器端"测试。Autoserv不只提供一组固定的服务器操作（安装客户端并运行作业、修复等），还允许测试人员提供Python控制文件，以便在服务器上执行，就像在客户端上一样。例如，可以用它来执行网络测试，流程如下：

在两台机器上安装 Autotest 客户端
在一台机器上启动 "网络服务器 "作业
在一台机器上启动 "网络客户端 "作业
等待两个作业完成并收集结果
任何单机网络测试都无法重复相同的结果，尤其是在试图量化网络性能而不仅仅是测试网络堆栈的稳定性时。这也允许执行更大规模的集群测试。虽然这已开始超出系统测试的范围，但它仍具有重要价值，因为它不是测试集群应用程序的一种方法，而是测试内核和硬件变化对大型应用程序影响的一种方法。较小规模的集群测试可采用与网络测试类似的工作流程。

这也允许执行更大规模的集群测试。虽然这已开始超出系统测试的范围，但它仍然具有重要价值，因为它不是测试集群应用程序的一种方法，而是测试内核和硬件变化对大规模应用程序影响的一种方法。较小规模的集群测试可采用与网络测试类似的工作流程。另外，服务器作业也可利用现有的集群设置和管理工具，只需驱动外部服务并在事后收集结果。

5.4 减少网络不稳定性

Autoserv的主要目标之一是提高可靠性，但它也带来了新的不稳定性。主要问题是它引入了一个新的故障点，即服务器与客户机之间的连接。在直接使用客户端的情况下，用户可以在一台机器上启动一项作业，并在预期完成后返回，任何短暂的网络问题都不会影响测试结果。如果作业是由远程服务器控制的，而服务器会持续监控测试机器，情况就不一样了。通过定期轮询远程机器而不是持续监控远程机器，可以在一定程度上缓解这一问题，但这最终只会降低问题的易发性。

通过OpenSSH实现更可靠的通信最终证明过于困难，主要原因是缺乏对网络故障模式的控制和可见性。曾考虑过的一个替代方案是使用完全独立的通信机制，但由于不切实际而被否决。使用SSH可为Autotest提供强大、安全的通信和远程执行机制，而无需投入大量时间和人力去发明一个需要在每台测试机上安装的定制协议。

因此，解决方案是添加一个使用Python软件包（paramiko）的SSH替代实施方案http://www.lag.net/paramiko/ 而不是启动外部OpenSSH进程。通过使用进程内库，Autoserv与SSH实现之间的集成和通信更加紧密，允许使用长时间SSH连接，并能从网络故障中自动恢复。同时，对Autotest客户端进行了修改，使其可以作为可分离的守护进程运行，这样自动连接恢复就可以重新连接到客户端，而不会影响本地测试。

添加paramiko支持的另一个好处是，通过在进程中执行SSH操作，减少了从Autoserv执行SSH 操作的开销，并简化了多通道SSH会话的使用，避免了不断创建和终止新会话的成本。在Autoserv中，基于paramiko的实现可以直接替代基于OpenSSH的实现，测试人员可以根据自己的需要选择使用。OpenSSH在大多数Linux配置中"开箱即用"的效果更好，而paramiko则需要更多的设置和配置，但最终可以实现更可靠、更轻量级的连接。

6 调度器和前端

Autoserv为个人用户测试少量平台提供了便捷可靠的方式。然而，作为一个独立的应用程序，它无法满足扩展到数千台机器的要求，也无法实现共享机器池的高效利用。为了满足这些需求，Autotest服务架构在Autoserv的基础上提供了一个层，使Autotest能够作为共享服务而非独立应用程序运行。用户无需直接执行Autotest客户端或服务器，而是通过基于Web 或命令行的界面与中央服务实例交互。该服务维护一个共享机器池和用户请求测试作业的全局队列。

有三个主要组件使这种使用模式成为可能。Autotest前端是用户安排和监控测试作业以及管理机器池的界面。自动测试调度程序负责执行和监控Autoserv，根据用户请求在池中的机器上运行测试。最后，本文未讨论的结果分析界面提供了一个用于查看、汇总和分析测试结果的通用界面。

自动测试前端（AutotestFrontend）是一个网络应用程序，用于调度测试、监控正在进行的测试和管理测试机器。它在一个数据库中运行，该数据库包含可用的测试、共享测试平台中的机器以及用户已调度测试作业的全局队列。调度程序通过该数据库与前端交互，执行已调度的测试作业，并根据执行进度更新作业和机器的状态。

前台支持多种功能，帮助用户组织机器池。首先，系统支持访问控制列表，以限制可以在某些机器上运行测试的用户。有些机器可以开放供一般测试使用，但有些用户，特别是硬件测试人员，会拥有不能被他人使用的专用机器。其次，系统支持用任意标签标记机器。该功能最常见的用途是标记机器的平台，这通常对作业调度和结果分析都很重要。此外，标签还可用于声明机器的功能（如远程电源控制），或将大量机器组合在一起以方便调度。

调度程序是运行在服务器上的守护进程，其主要目的是执行和监控Autoserv进程。调度程序会不断将预定的测试任务与可用的机器进行匹配，启动Autoserv进程来执行这些任务，并监控这些进程直至完成。在整个执行过程中，它都会更新数据库中每个作业的状态，以便用户跟踪作业进度。任务完成后，调度程序会执行一个解析器，将Autoserv的结构化结果日志读入测试结果数据库。然后，用户可通过专门的结果分析界面对这些结果进行强大的分析。

调度程序的一个重要特点是无状态。虽然它能保持大量内存状态，但所有重要状态都能从数据库中重建。这正是调度程序启动时会发生的情况，从而确保在调度程序需要重新启动时，所有测试将继续不间断地运行，不会浪费机器时间。这对于在部署新Autotest版本或调度程序崩溃后最大限度地减少对用户的影响至关重要。

此外，当测试机群扩展到数千台机器时，自动化的机群健康管理变得至关重要。为此，调度程序利用了Autoserv的机器诊断和修复功能。调度程序会启动特殊的Autoserv进程，在每次任务前验证机器的健康状况，并在必要时执行维修。无法修复的机器会在数据库中标记，机器健康仪表盘可从中读取并汇总机器健康数据。此外，调度程序还会对已知的死机进行定期重检，以捕捉可能发生的人工修复。

6.2 分布式执行实现可扩展性

当所有Autoserv进程都在单台服务器上运行时，大约有1000台机器同时接受测试，性能就会严重下降。调度程序支持对正在运行的进程进行全局节流，以避免系统瘫痪，但这仍然会对硬件本身的可扩展性造成限制。为了缓解这一问题并进一步扩展，调度程序支持在服务器池中分配Autoserv进程。单个调度程序协调多个服务器之间的执行，执行完成后，所有结果集中到单个归档服务器上。每台服务器可支持大约 1,000台被测机器，迄今为止，还没有任何 Autotest安装达到系统可使用服务器数量的上限。

除了增强可扩展性，分布式执行还能提高系统可靠性。由于执行服务器之间完全独立，因此每个服务器都可以完全失效，而不会导致整个服务停止。通过这种分布式执行模式，谷歌的 Autotest服务已扩展到约5,000台机器同时进行测试。

6.3 自动生成控制文件

要运行单个测试，Autoserv用户可以运行为每个测试编写的一个现有控制文件。但是，为了在一次执行中运行多个测试，用户必须编写自定义控制文件。虽然控制文件已尽可能保持简单，但编写自定义控制文件仍然是新用户的一大障碍。为此，自动测试前端支持自动生成控制文件，从而简化了运行多个测试的过程。

通过前台创建作业包括选择若干测试、若干机器和各种作业选项。用户可以从列表中选择测试，列表中包括每个测试的说明，前台将自动生成控制文件以运行所选测试。用户还可以指定要安装的内核，并选择要在测试期间启用的剖析器，生成的控制文件将包含所有这些选项。这样，用户就可以通过Autotest轻松运行中等复杂程度的工作，而无需任何控制文件知识。同样，也可以根据主机名或平台（或任何其他机器标签）从列表中逐一或批量选择机器。此外，用户还可以要求在特定平台的任何一台机器上运行作业，并允许调度程序在运行时选择其中一台。这一功能有助于提高共享测试机器的利用率，并使自动作业的运行特别容易，而无需固定的专用机器集。

6.4 支持高级自动化

网络前端的大部分工作在网络服务器上完成，该服务器主要作为RPC服务器运行。网络服务器使用Python和Django网络框架编写，并与MySQL数据库通信。网络界面是一个在浏览器中运行的成熟应用程序，使用谷歌网络工具包（Google Web Toolkit）实现。它仅通过RPC接口与服务器通信。此外，还有一个用Python实现的命令行界面，通过相同的 RPC 接口与服务器进行通信。

这得益于轻量级JSON5数据交换格式的使用，该格式可以用两种语言轻松实现。此外，还可以编写直接访问RPC接口的自定义脚本，通过一个简单的接口提供网络前端的全部功能。这支持强大而简便的高级自动化，允许用户在前端基础上使用外部脚本扩展 Autotest 的功能。

7 未来发展方向

Autotest在自动化执行内核和硬件测试方面取得了长足进步。但测试的执行通常是在鉴定过程中进行的，而完整的鉴定过程仍然是繁琐而机械的折磨。对新内核进行鉴定通常需要在代表各种硬件平台的大量机器上运行一系列功能和性能测试。测试项目的选择可能取决于先前测试的结果。然后，必须将测试结果与已知稳定内核的测试结果进行比较，以发现统计意义上的重大偏差。此外，持续测试系统希望以全自动方式执行整个过程，并在每次更改时报告偏差。对一系列新机器进行鉴定涉及类似但不完全相同的过程。特别是，必须通过更新系统软件或操作硬件组件，对单台机器进行测试、分流和修复的循环跟踪。与此同时，这种个性化的跟踪必须扩展到成百上千台机器，而且这一过程必须最终报告与已知稳定平台的重大偏差。

虽然Autotest可以抽象出这些流程中涉及的许多低级问题，但却无法实现这些高级流程的自动化。成功实现这些流程的自动化是Autotest项目尚未解决的主要问题之一。幸运的是，前端提供的高级自动化支持可以为这些问题提供原型解决方案。这些解决方案可以建立在Autotest体系结构之上，而无需修改Autotest本身，事实上，已经建立了许多这样的解决方案，以满足特定Autotest用户的需求。这些原型为将此类自动化纳入Autotest系统提供了有用的途径。

此外，改进报告仍然是Autotest大有可为的领域。Autotest当前的报告界面可以生成各种报告，有可能跨越多个作业，但仍需要大量人工才能得出有用的高层次结论，而且故障分流仍是一项艰巨的任务。为了帮助完成前一项任务，Autotest需要支持更好的自动折叠功能，将大量数据折叠成更小、更简洁的报告，突出重要的质量偏差，隐藏其他数据。为了更方便地分流故障，Autotest需要更好地分类和组织测试输出，并更有效地引导用户找到最有可能发现故障细节的地方。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！