测试验证¶
当一个变更集添加新的测试或修改现有的测试时，测试验证 (TV) 测试套件会执行额外的测试，以帮助尽快找到修改后的测试中的间歇性故障。TV 使用其他测试工具多次运行测试，有时还会在各种配置中运行。例如，当修改 mochitest 时，TV 会在验证模式下在修改后的 mochitest 上运行 mochitest 工具。该测试将运行 10 次，然后相同的测试将再运行 5 次，每次都在一个新的浏览器实例中。完成后，整个序列将在测试混乱模式 (设置 MOZ_CHAOSMODE) 下重复。如果任何测试运行失败，则会正常报告失败，测试结束，并且测试套件会报告失败。
最初，存在一些限制
TV 仅适用于 mochitests（所有类型和子套件）、reftests（包括 crashtests 和 js-reftests）和 xpcshell 测试；一个单独的作业 TVw 处理 web-platform 测试。
仅启用了部分测试混乱模式功能
使用 mach 运行测试验证¶
支持的测试工具接受 –verify 选项
mach web-platform-test <test> --verify
mach mochitest <test> --verify
mach reftest <test> --verify
mach xpcshell-test <test> --verify
可以一次验证多个测试，甚至清单或目录，但这通常不建议这样做。一次验证一个测试更容易理解！
验证步骤¶
每个测试工具都以一个或多个“步骤”实现 –verify 行为。每个步骤都使用不同的策略来查找间歇性故障。例如，mochitest 验证的第一步是使用 –repeat=20 运行测试；第二步是在单独的浏览器会话中只运行一次测试，关闭浏览器，然后重复该序列多次。如果在一个步骤中发现故障，则跳过后面的步骤。
验证摘要¶
测试验证可能会产生大量输出，其中大部分是重复的。为了帮助传达已发现的验证内容，每个测试工具都会为每个已验证的文件打印一个摘要。在每个验证步骤中，都会有一个通过或失败状态以及一个整体验证状态，例如
:::
::: Test verification summary for:
:::
::: dom/base/test/test_data_uri.html
:::
::: 1. Run each test 20 times in one browser. : FAIL
::: 2. Run each test 10 times in a new browser each time. : not run / incomplete
:::
::: Test verification FAILED!
:::
长时间运行的测试和验证持续时间¶
测试验证旨在快速完成：尽快确定此测试是否间歇性失败，以便快速传达通过或失败的结果，并且不会浪费测试资源。
测试的运行时间范围很广，从几毫秒到几分钟不等。当然，一个运行需要 5 分钟的测试，可能需要很长时间才能验证。也可能存在一次验证许多测试的情况。例如，在自动化中，一个变更集可能会对数百个测试进行微不足道的更改，或者合并可能会导致类似的情况。即使每个测试的验证速度都相当快，验证所有这些文件所需的时间也可能相当可观。
每个支持 –verify 选项的测试工具也支持 –max-verify-time 选项
mach mochitest <test> --verify --max-verify-time=7200
默认的 max-verify-time 为 3600 秒（1 小时）。如果验证步骤超过 max-verify-time，则不运行后面的步骤。
在自动化中，TV 任务使用 –max-verify-time 尝试将验证限制在大约 1 小时内，无论要验证多少个测试或每个测试运行多长时间。如果验证不完整，则任务不会失败。它报告成功并在 treeherder 中显示为绿色，此外，treeherder 的“作业状态”窗格也将报告“验证时间过长！并非所有测试都已验证”。
自动化中的测试验证¶
在自动化中，每当变更集包含对 .js、.html、.xhtml 或 .xul 文件的修改时，TV 和 TVw 任务就会运行。TV/TVw 任务本身会检查测试清单以确定任何修改的文件是否是测试文件；如果任何文件是测试文件，TV/TVw 将会验证这些测试。
Treeherder 状态为
绿色：支持的套件中所有修改的测试都已验证，并且没有测试失败，或者测试验证没有足够的时间来验证一个或多个测试。
橙色：此变更集修改的一个或多个测试验证失败。应考虑回退（但不是强制性的），以避免这些测试将来出现间歇性故障。
存在一些限制
预先存在的条件：测试可能正在失败，然后在推送中以积极的方式更新，但继续间歇性失败。如果作者知道剩余的问题，最好不要回退。
由于测试验证条件导致的失败：在某些情况下，测试可能会失败，因为测试验证会使用 –repeat 运行测试，或者因为测试验证使用混乱模式，但这些故障可能不会在测试的“正常”运行中出现。理想情况下，所有测试都应该能够在测试验证中成功运行，但可能存在例外情况。
Try 上的测试验证¶
要在 Try 上使用测试验证，请使用类似以下内容：
mach try -b do -p linux64 -u test-verify-e10s --artifact
推送中修改的测试将被验证。
对于 TVw，请使用类似以下内容：
mach try -b do -p linux64 -u test-verify-wpt-e10s --artifact
推送中修改的 Web 平台测试将被验证。
您还可以使用类似以下内容在不修改测试的情况下对测试运行测试验证：
mach try fuzzy <path-to-test>
跳过验证¶
在绝大多数情况下，测试验证失败表明测试存在弱点，应予以解决。
在一些不常见的情况下，如果测试验证失败没有提供价值，则可以在测试中“跳过”测试验证：在随后修改测试的推送中，测试验证作业将不会尝试验证跳过的测试。
对于 mochitests、xpcshell 测试以及其他使用 .ini 清单格式的测试，请使用类似以下内容：
[sometest.html]
skip-if = verify
对于 reftests（包括 crashtests 和 jsreftests），请使用类似以下内容：
skip-if(verify) == sometest.html ...
目前，尚不支持在验证模式下跳过 web-platform 测试。
常见问题¶
为什么我的测试会出现“峰值”的测试验证失败？为什么它停止了？
测试验证失败的 Bug 报告通常会在某一天显示“峰值”的失败。这是因为 TV 仅在修改特定测试时才会针对该测试运行。特定的推送修改了测试，TV 运行并且测试失败，然后 TV 在随后的推送中不会再次运行该测试（直到/除非测试文件再次被修改）。当然，当该推送合并到其他树中时，TV 会再次触发，因此通常会在多个树中连续注意到相同的故障：例如，mozilla-inbound 上的一个修订版本，然后当该修订版本合并到 mozilla-central 以及 autoland 上时再次出现。
当 TV 失败时，是否值得重新触发？
不 - 通常不值得。TV 会一遍又一遍地运行特定测试 - 有时在单次运行中会运行 50 次。在 treeherder 上重新触发通常没有必要，并且很可能会产生与原始运行相同的通过/失败结果。从这个意义上说，TV 失败几乎总是“永久失败”。
联系方式¶
测试验证由 :gbrown 和 :jmaher 维护。Bug 应在 Testing :: General 中提交。您可能想参考 Bug 1357513。