使用 Jenkins 重新执行测试用例并合并 Robot Framework 报告

随机性很重要，但有时它会变得混乱，尤其是在代码调试或报告分析方面。当整体结果仅因几次您无法控制的随机故障而受到影响时（或者可能由于您机器上的一些繁琐原因和优先级因素而不想终止或修复它们），这时，“第二次机会”可以修复您报告和整体测试结果的很大一部分。

遵循这个思路，在本文中，我将讨论如何在您的机器或环境中由于任何随机故障而导致测试用例失败时，如何 RE-RUN 这些测试用例（当然，这种随机故障或操作不应来自您的测试应用程序或您的自动化工具集，因为如果您的测试被中断或任何测试用例因您自己的应用程序行为而失败，那么这是关键的，您应该通过自动化来处理它）。我们还将看到如何在执行重新运行时，通过作业的批量命令来监督如何合并结果（通过率、报告等）。最后，作为奖励部分，我们还将讨论在批量命令中包含“non-critical”标签的用途。

一点历史

3.0.4 是 Robot Framework 的当前版本（我没有发布它，我只是从 Robot Framework 官方文档中读取的），但几年来，测试人员和工程师确实需要在其库中增加一个功能来重新执行测试用例，然后相应地合并报告。因此，为此原因，`--rerunfailed`（用于重新执行失败的测试）已添加到 Robot Framework 2.8 中，该版本大约在 2013 年中期发布，然后在很短的时间内，随着 Robot Framework 2.8.4 的发布，另一个命令选项（`-merge`）（用于合并输出结果）也被添加到其词汇表中。这两个命令选项在组合使用时非常有用，可以带来非常好的整体结果，并为您节省大量手动麻烦。

这些简单的选项是如何实现神奇效果的

`Rerun failed` 选项（`--rerunfailed`）在实际测试执行完成后重新执行失败的测试用例。它使用测试用例的状态获取失败的测试用例实例，然后重新执行所有测试用例（如果测试用例是间歇性失败的，则给它第二次通过的机会）。

在上图中，您可以清楚地注意到这个测试用例在第一次运行时失败了，而在第二次执行时通过了。因为它的状态、旧状态和旧消息都解释了这一点。您可能已经注意到旧消息的文本，它在第一次运行时解释了失败的原因“Control doesn’t exist”（控件不存在），这很少发生，当发生一些意想不到的事情时。因此，在下一次执行中，找到了控件，我们的测试用例就通过了。

ipy -m robot.run --output output-i.xml --include "BuildNumber" 
--exclude "InValid" "RIDE Scripts" & ipy -m robot.run --rerunfailed output-i.xml 
--output-ii.xml --include "BuildNumber" --"InValid" "RIDE Scripts"  

上面的批量命令是不言自明的，但仍然最好将其分解解释。第一个 ipy 块向 robot framework 发出命令，以执行包含特定构建号作为标签的脚本，并排除任何带有“InValid”标签的测试脚本。此命令将简单地执行名为“RIDE SCRIPT”的文件夹中放置的所有测试脚本，然后输出将存储在 output-i.xml 输出文件中，以便稍后生成进一步的报告文件（Log.html 和 Report.html）。

 

有趣的信息：最好知道，通过 robot framework 执行测试脚本后首先生成的主要文件是 output.xml，它进一步生成两个 HTML 文件，称为 log.html 和 report.html，它们都表示得很好并且易于阅读，可用于分析目的。
Execution of test scripts via robot framework is output.xml, which further generates two HTML
files called log.html and report.html, which are finely represented and readable to be used
for analysis purpose.

Command - rebot output.xml

此外，第二个 ipy 块中的命令包括 tag 选项，即 –rerunfailed，它需要第一次执行生成的 XML 输出，然后我们命名将要在此失败的测试用例执行后生成的另一个输出（此处为 output-ii.xml）。请注意，rerunfailed 命令可以接受 include 和 exclude 标签，因此您可以限制您不想重新运行的意外失败，以及其他类似的目的，根据您的测试需求。

在此步骤之后，您将有两个不同的 XML 输出文件，但它们对您来说都不真正有用，直到您将这两个 XML 文件合并为一个，然后从该合并的输出文件中获取 log 和 report 文件。

ipyrebot --rerunmerge --output output.xml --noncritical "non-critical" -l log.html 
-r report.html output-i.xml output-ii.xml 

同样，这看起来很简单。在这里，我们将两个 XML 文件合并，并生成一个最终的 output.xml、log.html 和 report.html 文件。从中您可以查看最终结果并进行分析，在此报告中，由于您再次重新运行了失败的测试用例，并且所有因意外行为或操作而失败的测试用例都不会失败，因此失败率会好得多。

开头，我提到了 non-critical 标签，我将描述我们使用此标签的目的以及如何使用。先看看下面的命令。

ipy -m robot.run --output output-i.xml  --noncritical "non-critical" 
--include "BuildNumber" --exclude "InValid"  "RIDE Scripts"   

在这里，在提供第一个输出 XML 文件名之后的批量命令中，我提到了一个标签，即 –noncritical，并且在此之后，我用引号括起来了该特定标签名称“non-critical”，这只是一个添加到脚本中的普通标签，就像您的其他标签一样。它的作用是，它将这些测试用例视为非关键的，并且由于带有此标签的测试用例失败，其影响不会反映在整个套件中。此外，Jenkins 项目中的整体趋势和测试摘要将更加清晰。

您可以清楚地看到这两个图像之间的差异，以及最终摘要如何描述关键和非关键测试用例的数量。我首先运行了没有在命令中包含 non-critical 选项的 Jenkins 构建，然后在下一个构建中，我在批量命令中添加了 non-critical 选项。

只有当您尝试这些命令并看到它们在实际操作中帮助您的 UI 测试时，您才会感受到其中的快乐。迄今为止，我们已经经历了多个步骤和方法，可以如何改进您的 robot framework 测试结果，尤其是在存在间歇性问题并试图搞乱您的测试时。