测试失败时会发生什么?如果有人手动运行测试,那么他们会暂停并了解更多信息。但是,当自动测试失败时,其余部分可能会继续运行。在套件完成之前,你是没有办法看到测试报告的,并且自动化程序不会在故障时执行任何额外的操作尝试找出问题。当剩下的用例全部执行以后,测试人员可能会重新点击一下执行按钮,看看第二遍失败的用例会不会执行成功。
那么,是自动测试重试好还是坏?这实际上是一个相当争议的话题。
什么是重试机制?
为避免任何混淆,我们理清“自动测试重试”的意思。
假设我有 100 个自动测试用例。当我运行这些测试用例时,框架将单独执行每个测试,并产生测试的通过或失败结果。在套件结束时,框架将所有结果聚集在一起。在最佳情况下,所有测试通过:100/100。
但是,假设其中一个测试失败了。在发生故障时,测试框架将捕获任何异常,执行任何清理例程,记录故障,并安全地移动到下一个测试用例上。在套件结束时,该报告将显示 99/100 通过一个测试失败的测试。
默认情况下,大多数测试框架将一次运行每个测试。但是,某些测试框架具有用于自动重新运行的测试用例故障的功能。框架甚至可以使测试人员能够指定要重试的次数。因此,假设我们为我们的 100 个测试套件配置了 2 次重试。当一个测试失败时,框架将为这个用例再执行 2 遍,再转移到下一个用例。
重试可能被滥用
假设你现在是自动化团队的,每晚为 Web 应用程序提供 300 个自动测试,如大家所知,Web 测试经常不太稳定,每天晚上大约十几个不同的测试失败,每天早上都花了很多时间调试问题。但是当你重新运行这些失败用例时,他们几乎总是通过。所以你现在每天晚上都会会自己的自动化测试程序设置重运行。
这种策略是好的吗?很难说! 因为这实际上是在隐藏问题,而不是暴露问题。测试人员应该关注爆红,而不是绿色的通过信息, 通过重运行机制,原来产生红色警示的 10 几个用例都无一例外的通过了, 你还会花精力去分析晚上这 10 几个用例失败可能出现的原因吗?
万一当时确实是在异常的条件下,真的触发了这些用例爆红, 后面因为条件回复正常,才执行成功呢?
如果这种异常条件总是间歇性的出现呢?在这种情况下,用例重运行隐藏了可能出现的 bug。
实际上失败重运行在手工测试也很普遍,不是自动化独有的。测试人员喜欢找到一致,可重复的失败,因为这些失败很容易解释。一旦一个测试问题只是间歇性的出现,我们就没法向开发和团队其他人员解释了。 这些问题可能是环境因素导致的,可能是达到的条件比较苛刻,因此难以复现。
通常情况下,如果不能轻松复现这个测试问题,我们会选择沉默,不再和开发继续争吵。而自动化的重运行机制也是这样,当一个用例失败时,我们可以选择复现,如果第二次没再出现,我们就默认了,这里没问题,因为问题没有复现!!
那么,失败重运行的正确打开方式是怎样的?
首先,一定要记录所有失败的日志信息和失败原因,如果有必要,不管重运行后有没有成功,只要用例有一次爆红,都应该引起测试人员的警觉: 这里是很有可能出问题的。
其次,在项目迭代过程中,我们不一定有时间去解决这些间歇性发生的问题。要复现问题都比较困难,更不要说要分析,和开发人员沟通的过程了。
最终的答案,还是优先级。一致性的失败是我们重点要提交的问题,他们总是报红,不管你是不是做了重运行。 当解决了这些一致性失败时,再考虑黄色问题(重运行、警告)。
不管如何,重运行机制是一种非常好的工具和手段,它能让我们知道哪些问题是一致性的,哪些是间歇性的,重点在于,作为测试人员应该警戒所有的红色和黄色,而不是想法设法把红色变成绿色。
喜欢对你有帮助的话记得加个关注不迷路哦
个人主页有领取方式,可以领取到一些个人收集的软件测试工具、面试题、资料包,无偿的,需要的私信小编“资料或许对你有帮助!
点击链接领取
软件测试全套基础/进阶/转行资料
感谢各位大大的阅读