自动化测试 – 如何处理预期在开发过程中失败的单元/回归测试?

在软件开发过程中,代码库中可能存在已知问题的错误.如果测试编写得很好,这些错误将导致回归/单元测试失败.

我们的团队一直在争论如何管理失败的测试:

>使用REVISIT或TODO评论评论失败的测试用例.

>优势:我们将始终知道何时引入了新缺陷,而不是我们已经知道的缺陷.
>缺点:可能忘记重新评估已注释掉的测试用例,这意味着缺陷可能会漏掉.

>让测试用例失败.

>优势:不会忘记修复缺陷,因为脚本失败会不断提醒您存在缺陷.
>缺点:由于故障噪声,很难检测到何时引入新缺陷.

我想探讨一下这方面的最佳实践.就个人而言,我认为三态解决方案最适合确定脚本是否通过.例如,当您运行脚本时,您可以看到以下内容:

>百分比通过率:75%
>百分比失败(预期):20%
>百分比失败(意外):5%

您基本上会使用某些元数据标记您希望失败的测试用例(由于某些缺陷).这可以确保您在测试结束时仍然可以看到失败结果,但是立即知道是否存在您不期望的新故障.这似乎采取了上述两个提案中最好的部分.

有没有人有任何最佳实践来管理这个?

我会留下您的测试用例.根据我的经验,用类似的东西评论代码

// TODO:  fix test case

类似于做:

// HAHA: you'll never revisit me

严肃地说,随着您越来越接近运输,在代码中重新访问TODO的愿望往往会消失,特别是对于单元测试这样的事情,因为您专注于修复代码的其他部分.

将测试留在您的“三态”解决方案中.但是,我强烈建议尽快修复这些案件.我不断提醒的问题是,在人们看到它们之后,他们倾向于掩饰它们并说“哦,是的,我们总是得到那些错误……”

举个例子 – 在我们的一些代码中,我们引入了“可跳过的断言”的概念 – 断言可以让你知道存在问题,但允许我们的测试人员将它们移到其他部分.码.我们已经发现QA开始说“哦,是的,我们一直得到断言,我们被告知它可以跳过”,并且没有报告错误.

我想我的建议是,还有另一种选择,即修复测试用例立即发现的错误.可能有不这样做的实际原因,但从长远来看,现在养成这种习惯可能更有益.

相关文章
相关标签/搜索