1 摘要
内核和硬件等低级系统已被证明极难进行有效测试，因此，许多内核测试都是以手动为主方式进行的。现有的大多数测试框架都是为测试与底层平台隔离的高级软件而设计的，而底层平台被假定是稳定可靠的。测试底层平台本身需要一套全新的假设，这些假设必须从根本上反映在框架的设计中。设计必须将被测机器作为系统的重要组成部分，并且必须预测内核和硬件中任何级别的故障。此外，系统必须能够扩展到数百台甚至数千台被测机器，从而能够在各种硬件平台上同时测试多种不同的开发内核。因此，系统必须便于开发人员有效共享机器资源，并能自动维护机群。最后，系统必须实现端到端的自动化，使开发人员能够以最小的工作量，在不了解框架内部结构的情况下，简单地执行基本测试，并加入自己的测试。与此同时，它还必须在统一调度、执行和报告框架内适应复杂的集群级测试和不同的专业测试环境。
Autotest是一个开源项目，它克服了这些挑战，实现了底层系统的大规模全自动测试，并能检测到罕见的错误和微妙的性能退步。在谷歌使用Autotest，内核开发人员可以在数百台机器上进行检查测试，硬件测试工程师可以在短时间内鉴定数千台新机器。本文将讨论上述挑战，并介绍Autotest成功采用的一些解决方案。本文将重点介绍分层系统架构，以及该架构如何实现不仅测试执行环境而且整个测试控制系统的分布，如何利用Python提供简单但可无限扩展的作业控制和测试harness，以及自动系统健康监控和机器维修，从而将用户与测试平台的管理隔离开来。
2 Autotest简介
Autotest是一个对底层系统（包括内核和硬件）进行全自动测试的框架。它旨在针对运行中的内核或硬件提供端到端的自动化功能和性能测试，并尽可能减少手动设置。这种自动化可减少测试工作的浪费，提高测试频率和一致性。它还能轻松地将测试推送给上游的不同开发人员，将测试提前到开发周期中。
使用Autotest，内核和硬件工程师可以获得比此类组件通常获得的测试覆盖率大得多的测试覆盖率。这种典型的缺乏有效低级系统测试的情况是有充分理由的：此类系统的自动测试是一项艰巨的任务，并面临着许多有别于用户空间软件测试的挑战。本文将介绍Autotest所要满足的要求，以及这些要求所带来的一些独特挑战，包括面对系统不稳定性时的稳健测试、扩展到数千台测试机器，以及最大限度地降低测试执行和测试开发的复杂性。本文将讨论 Autotest为应对上述挑战而采用的解决方案，以实现有效的全自动底层系统测试。
3 背景
高质量的自动化测试是任何大型、长期软件项目保持稳定的必要条件。同时允许快速开发。对于Linux内核和其他系统软件来说，这一点与用户空间软件相同。不过，迄今为止，自动测试的优势在用户空间应用程序中实现得最为成功。
现有的大多数测试自动化框架都是针对运行在硬件和操作系统提供的平台之上的软件，几乎所有软件都是在这个平台上运行的。通过利用应用程序在平台提供的可靠标准化环境中运行这一假设，框架可以抽象并简化大部分底层系统。当试图为内核（和硬件）测试提供同样的服务时，这种假设就不再合理了，因为底层系统是测试内容不可分割的组成部分。这正是开发Autotest及其前身IBM Autobench最初版本的部分动机。
Autotest最初的目标是测试底层平台本身，而这一目标产生了一系列独特的要求。首先，由于Autotest所运行的平台本身也在接受测试，因此Autotest必须从一开始就假设系统不稳定。这就要求对内核panic、硬件锁定、网络故障和其他意外故障进行优雅的处理。此外，内核安装和硬件配置等任务在Autotest中必须是简单而常见的活动。
其次，由于被测平台不容易虚拟化，因此每次运行测试都需要一台物理机。硬件虚拟化可用于基本的内核测试，但由于它无法产生准确的性能结果，而且会掩盖特定平台的功能问题，因此只能用于最基本的内核功能验证。因此，Autotest的建立是为了在物理机上运行每个测试，包括内核和硬件测试。这使得多台机器之间的协调成为Autotest的核心需求，并进一步意味着扩展需要在数百甚至数千台机器之间分配测试。这就需要在用户之间建立一个高效的测试机共享系统，以最大限度地利用如此庞大的测试机群。
最后，Autotest必须满足任何测试框架的通用要求。特别是，自动测试必须最大限度地减少测试开发人员的开销。在同一基本框架内，既要能方便地整合现有测试，又要能轻松编写简单的新测试，还要能编写复杂的多进程或多机器测试。此外，开发测试应该是一个简单、熟悉的过程，只需要与一小部分可用的基础设施进行交互。因此，测试必须易于手工执行，同时又能插入大规模调度系统。
这些抽象层次被划分为不同的模块，本文将对此进行详细讨论。
如图1所示，系统的最底层是Autotest客户端，这是一个在单个机器上运行的简单测试框架。下一层是Autoserv，设计用于在集中式测试服务器上运行，自动安装和执行客户端，并协调多机测试。最外层由单个前端和作业调度器组成，允许多个用户共享单个测试机群和结果库。设计模块化，并允许用户在多个层面上与系统交互。在大范围内，用户可以在网络界面上按下按钮，在大型计算机集群上启动完整的测试套件；在小范围内，用户可以通过执行 shell 命令在本地工作站上运行单个测试。
3.1 相关工作
Linux测试项目(LTP: Linux Test Project)的目标是向开源社区提供测试套件，以验证Linux的可靠性、健壮性和稳定性"。它集合了Linux内核和相关功能的功能测试和压力测试，以及用于执行测试的客户端基础架构。客户端基础架构简化了许多测试的执行（包含3,000多个测试），支持并行运行测试，可在测试执行期间产生背景压力，并在运行结束时生成测试结果报告。不过，LTP并不打算成为一个通用的全自动内核测试框架。它本质上是一个测试集合，因此适合作为测试纳入Autotest。
为测试Xen虚拟化项目，开发了Xentest自动化框架。David Barrera等人指出，“测试Xen下的Linux与测试Linux本身非常相似”，他们通过"在Xen上运行 Linux下的标准测试套件"来执行部分测试。由于测试Xen与测试底层硬件本身非常相似，因此从内核测试和硬件测试的角度来看，Autotest的目标与Xentest的目标有很多共同之处。Xentest是一个脚本集合，支持构建和启动Xen、在Xen下运行测试以及收集结果日志。它不支持对测试结果进行任何自动分析，以确定通过/失败条件。测试运行可通过使用Python ConfigParser模块的控制文件进行配置。这提供了简单的配置，但在控制文件中缺乏任何编程功能。最后，Xentest紧紧围绕Xen构建，并不打算成为内核或硬件测试的通用框架。另一方面，Autotest可用于执行Xen测试，就像Xentest所做的那样，而且过去已经在这方面做了一些工作。
Crackerjack是另一种测试自动化系统，专门用于回归测试。它侧重于发现内核版本之间不兼容的API变化。这是很有价值的测试，但与Autotest相比，其关注点较窄。
PyReT和ANTS是解决分布式内核测试问题的两个框架。前者的所有通信都依赖于共享文件系统，而后者则使用串行控制台。对于仅依靠SSH连接进行通信的Autotest来说，测试机器上的这两项要求都过于苛刻。ANTS对测试机故障的处理能力相当强，因为它可以使用网络启动从头配置所有测试机，并能使用远程电源控制来重置和恢复无响应的测试机。此外，该系统还包括机器预留工具，这样开发人员和自动化系统就可以共享机器，而不会发生冲突。这些都是 Autotest的重要功能。不过，该系统严格针对夜间测试而构建，不支持用户自定义作业的通用队列。它包括非常有限的结果分析，即在夜间测试完成后以电子邮件报告的形式提供。它可以运行一些开源测试（包括LTP），但不支持更复杂的多机测试。最后，该系统是专有的，因此对社区的直接实用性不高。
Alexander Ufimtsev和Tim Chen提出了分布式内核性能测试系统。在这两个系统中，测试机都是自主运行的，运行一个客户端工具包，该工具包监控内核资源库，在新版本出现时进行构建和测试。从这个意义上说，这两个系统都是围绕每个版本测试的特定目的而构建的，尽管后一个系统还支持在任何内核上测试任意补丁。两个系统的客户端都会将结果传送到一个中央存储库，前者是一个远程服务器，后者是一个共享数据库。前者包括一些自动分析功能，可根据与先前平均值的差异进行回归检测，Autotest尚未实现这项任务。后一种系统包括一个网络前端，显示每个基准随内核版本变化的图表，并支持显示剖析器信息、重新运行测试或分段查找导致回归的补丁。Autotest 包含对这些功能的部分支持，但如果能在这一领域加以改进，将大有裨益。
4 Autotest 客户端
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服务器
5.1 跨机器分发测试运行
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 调度器和前端
6.1 共享机器池
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需要更好地分类和组织测试输出，并更有效地引导用户找到最有可能发现故障细节的地方。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
