自动化测试¶

您刚刚编写了一个功能，并且（希望如此！）想要对其进行测试。或者您已经决定现有功能的测试不足，并希望贡献一些测试。但是您从哪里开始呢？您四处查看并找到了对“xpcshell”或“web-platform-tests”或“talos”等内容的引用。它们都测试哪些代码、功能或平台？它们的特性集在哪里重叠？简而言之，您的新测试应该放在哪里？本文档是希望开始了解 Mozilla 自动化测试工具和流程的人员的起点。在下面，您将找到我们使用的每个框架的简要总结，以及一些问题来帮助您为自己的目的选择所需的框架。

如果您仍有疑问，请在 Matrix 或相关 Bug 上提问。

Firefox 生产¶

这些测试与产品代码一起在 mozilla-central 代码树中找到。

当更改集推送到 mozilla-central、autoland 或 try 时，它们将运行，结果显示在 Treeherder 上。并非所有测试都会在每个更改集上运行；会实施算法来运行最有可能失败的测试，并定期运行所有测试。

它们也可以在本地构建上运行。注意：大多数移动测试在模拟器上运行，但一些测试（特别是性能测试）在硬件设备上运行。我们尽量避免不必要地在硬件设备上运行移动测试。在 Treeherder 中，名称以“hw-”开头的测试在硬件上运行。

代码风格检查¶

代码风格检查测试通过使用代码风格检查工具分析代码来帮助确保更高的质量和更少的错误代码。

代码风格检查工具¶
Treeherder 符号	名称	平台	测试内容
`ES`	ESLint	所有	分析 JavaScript 代码的正确性。
`ES-build`	eslint-build	所有	使用构建工件的扩展 JavaScript 分析。
`mocha(EPM)`	ESLint-plugin-mozilla	桌面	ESLint 插件规则。
`f8`	flake8	所有	分析 Python 代码的样式和正确性。
`stylelint`	Stylelint	所有	分析 CSS 代码的正确性。
`W`	wpt lint	桌面	分析 web-platform-tests 的样式和清单的正确性
`WR(tidy)`	WebRender servo-tidy	桌面	gfx/wr 中的代码将通过 servo-tidy 运行。
`A`	Spotless	Android	分析 Java 代码的样式和正确性。

功能测试¶

自动化测试套件¶
Treeherder 符号	名称	平台	进程	环境		权限	测试内容
				Shell	浏览器配置文件
`R(J)`	JS Reftest	桌面	N/A	JSShell	N/A	N/A	JavaScript 引擎对 JavaScript 语言的实现。
`R(C)`	Crashtest	所有	子进程	内容	是	低	页面加载不会崩溃、断言或泄漏。
`R(R)`	Reftest	所有	子进程	内容	是	低	页面渲染（以及布局）是否正确。
`GTest`	GTest	所有	N/A	终端	N/A	N/A	未公开给 JavaScript 的代码。
`X`	xpcshell	所有	父进程，允许	XPCShell	允许	高	公开给 JavaScript 的底层代码，例如 XPCOM 组件。
`M(a11y)`	无障碍 (mochitest-a11y)	桌面	子进程	内容	是	?	无障碍接口。
`M(1), M(2), M(...)`	普通 Mochitest	所有	子进程	内容	是	低，允许	公开给 Web 内容中 JavaScript 的功能，如 DOM 和其他 Web API，其中 API 不需要提升的权限来进行测试。
`M(c1/c2/c3)`	Chrome Mochitest	所有	子进程，允许	内容	是	高	需要 UI 或 JavaScript 与特权对象交互的代码。
`M(bc)`	浏览器 Chrome Mochitest	所有	父进程，允许	浏览器	是	高	浏览器 UI 如何与自身以及内容交互。
`M(remote)`	远程协议 Mochitest	所有	父进程，允许	浏览器	是	高	Firefox 远程协议（实现了 Chrome 开发者工具协议的部分内容）。基于浏览器 Chrome Mochitest。
`SM(...), SM(pkg)`	SpiderMonkey 自动化	桌面	N/A	JSShell	N/A	低	SpiderMonkey 引擎 Shell 测试和 JSAPI 测试。
`W`	web-platform-tests	桌面	子进程	内容	是	低	公开给 ECMAScript 中 Web 内容的标准化功能；测试与其他供应商共享。
`Wr`	web-platform-tests	所有	子进程	内容	是	低	标准化功能的布局和图形正确性；测试与其他供应商共享。
`Mn`	Marionette	桌面	?	内容，浏览器	?	高	大型进程外功能集成测试以及与多个远程 Gecko 进程进行通信的测试。
`Fxfn`	Firefox UI 测试	桌面	?	内容，浏览器	是	高	集成测试，重点关注用户界面和本地化。
`tt(c)`	telemetry-tests-client	桌面	N/A	内容，浏览器	是	高	Firefox Telemetry 客户端的集成测试。
`TV`	测试验证 (test-verify)	所有	依赖于测试框架	?	?	?	使用其他测试框架 - mochitest、reftest、xpcshell - 对新/修改的测试进行额外测试。
`TVw`	wpt 的测试验证 (test-verify-wpt)	桌面	子进程	?	?	?	使用 wpt 测试框架对新/修改的 web-platform 测试进行额外测试。
`WR(wrench)`	WebRender 独立测试	所有	N/A	终端	N/A	N/A	WebRender Rust 代码（作为独立模块，与 Gecko 集成）。

注意：以前的测试套件存在基于首选项的变体。例如，Treeherder 上的 mochitests 可以有 gli、swr、spi、nofis、a11y-checks、spi-nw-1proc 等等。另一个例子是 GTest，它可以使用 GTest-1proc。要了解有关这些变体的更多信息，您可以将鼠标悬停在这些项目上以阅读这些缩写的描述。

表格键¶

符号

Treeherder 使用的测试套件的缩写。第一个字母通常表示用于执行测试的测试框架。括号中的字母标识实际的测试套件。

名称

引用测试套件时使用的常用名称。

文件类型

添加新测试时，您通常会在源代码树中创建此类型的文件，然后在清单或 Makefile 中声明它。

平台

大多数测试套件仅在可用平台和操作系统的一部分上受支持。除非另有说明

**桌面**测试在 Windows、Mac OS X 和 Linux 上运行。
**移动**测试在 Android 模拟器上或远程在 Android 设备上运行。

进程

当指示 **父进程** 时，即使浏览器以 Electrolysis (e10s) 模式运行，测试文件也将始终在父进程中运行。
当指示 **子进程** 时，当浏览器以 Electrolysis (e10s) 模式运行时，测试文件将在子进程中运行。
**允许**标签表示测试可以访问在其他进程中运行代码的机制。

环境

**JSShell** 和 **XPCShell** 环境是有限的 JavaScript 执行环境，没有窗口或用户界面（但请注意，Android 上的 XPCShell 测试在浏览器窗口中运行）。
**内容**指示表示测试在浏览器窗口加载的内容页面内运行。
**浏览器**指示表示测试在浏览器 XUL 窗口的 JavaScript 上下文中加载。
**浏览器配置文件**列指示测试开始时是否加载了浏览器配置文件。**允许**标签表示测试可以使用特殊命令选择性地加载配置文件。

权限

指示测试通常以低（内容）或高（chrome）JavaScript 权限运行。**允许**标签表示测试可以使用特殊命令选择性地在特权环境中运行代码。

性能测试¶

有许多测试框架用于测试性能。有关各种性能框架的更多信息，请查看性能文档。

我应该使用哪个？¶

通常，您应该选择尽可能低级别的框架。如果您正在测试 JavaScript 但不需要窗口，请使用 XPCShell 甚至 JSShell。如果您正在测试页面布局，请尝试使用 web-platform-test reftest。低级别测试的优势在于，您不会引入许多可能存在自身问题的其他组件，因此您可以快速定位您正在具体测试的任何 Bug。

以下是一系列问题，在您想要编写一些测试时，可以针对您的工作提出这些问题。

它是底层代码吗？¶

如果功能公开给 JavaScript，并且您不需要窗口，请考虑使用 XPCShell。如果不是，您可能需要使用 GTest，它几乎可以测试任何内容。一般来说，这应该是您为新测试选择的最后一个选项，除非您必须测试未公开给 JavaScript 的内容。

它会导致崩溃吗？¶

如果您发现导致 Firefox 崩溃的页面，请添加 crashtest 以确保未来的版本不会再次遇到此崩溃（断言或泄漏）。请注意，一旦找到核心问题，这可能会导致更多测试。

它是布局/图形功能吗？¶

Reftest 是您的最佳选择，如果可能的话。

您需要验证性能吗？¶

使用此列表中的适当性能测试套件.

您正在测试 UI 功能吗？¶

尝试 mochitest 的某种类型，或者如果应用程序还需要重新启动或使用本地化版本进行测试，则尝试 Marionette。

您正在测试移动/Android 吗？¶

如果您正在测试 GeckoView，则需要使用 JUnit 集成测试。

Mochitest 或 Reftest 可以涵盖一些特定功能。浏览器 Chrome 测试在 Android 上不运行。如果您想测试性能，Raptor 将是一个不错的选择。

您以上都没有做？¶

要使您的测试在持续集成中运行，请尝试使用 web-platform-tests 或 Mochitest，或者如果需要更高的权限，请尝试使用 Mochitest 浏览器 Chrome 测试。
对于桌面 Firefox，或者如果您只想了解 Gecko 测试的未来，请关注正在进行的 Marionette 项目。

需要从测试中获取更多数据吗？¶

大多数测试作业现在都公开了一个名为 $MOZ_UPLOAD_DIR 的环境变量。如果在自动化测试运行期间设置了此变量，则可以将其他文件放到此目录中，并在测试完成后将其上传到 Web 服务器。检索文件的 URL 将输出在测试日志中。

在 Linux 平台上运行某些测试（例如 mochitests）时，传递 $MOZ_RECORD_TEST=1 作为环境变量将触发使用 GNOME Screencast 对桌面的录制。

需要为测试套件设置首选项吗？¶

首先问问自己，是否需要为所有测试启用这些首选项，或者只为一部分测试启用（例如，启用某个功能）。

设置仅适用于某些测试的首选项¶

如果答案是后者，请尝试尽可能将首选项设置为仅适用于需要它的测试。以下是一些选项：

如果测试在 chrome 范围内运行（例如 mochitest chrome 或 browser-chrome），则可以使用 Services.prefs 在测试的设置函数中设置首选项。请务必在拆卸期间将首选项重置回其原始值！
Mochitest 普通测试可以使用 SpecialPowers 设置首选项。
所有版本的 mochitest 都可以在其清单文件中设置首选项。例如，要在清单文件中为所有测试设置首选项：
```
[DEFAULT]
prefs =
  my.awesome.pref=foo,
  my.other.awesome.pref=bar,
[test_foo.js]
[test_bar.js]
```
所有版本的 reftest 也都可以在其清单文件中设置首选项。
所有版本的 web-platform-tests 也都可以在其清单文件中设置首选项。

设置适用于整个套件的首选项¶

大多数测试套件都在位于 testing/profiles 下的 user.js 文件中定义首选项。每个目录都是一个配置文件，其中包含一个 user.js 文件，其中定义了许多首选项。然后，测试套件将在运行时将其中的一个或多个基本配置文件合并到其自己的配置文件中。要查看哪些配置文件适用于哪些测试套件，您可以检查 testing/profiles/profiles.json。列表开头的配置文件会被列表末尾的配置文件覆盖。

由于此系统难以全面了解为任何给定测试套件设置了哪些配置文件，因此创建了一个方便的 profile 实用程序。

$ cd testing/profiles
$ ./profile -- --help
usage: profile [-h] {diff,sort,show,rm} ...
$ ./profile show mochitest          # prints all prefs that will be set in mochitest
$ ./profile diff mochitest reftest  # prints differences between the mochitest and reftest suites

注意：JS 引擎测试尚未使用 testing/profiles，而是在此处设置首选项。

向跳过条件添加新上下文¶

通常，在建立新的测试配置时，需要添加可在 skip-if 注释中使用的新的键。