抽3分钟检验一下,自动化测试重运行,我会了么?

测试失败时会发生什么?

如果有人手动运行测试,那么他们会暂停并了解更多信息。但是,当自动测试失败时,其余部分可能会继续运行。在套件完成之前,你是没有办法看到测试报告的,并且自动化程序不会在故障时执行任何额外的操作尝试找出问题。当剩下的用例全部执行以后,测试人员可能会重新点击一下执行按钮,看看第二遍失败的用例会不会执行成功。

那么,自动测试重试好还是坏?这实际上是一个相当争议的话题。

抽3分钟检验一下,自动化测试重运行,我会了么?_第1张图片

如果你想学习自动化测试,我这边给你推荐一套视频,这个视频可以说是B站播放全网第一的自动化测试教程,同时在线人数到达1000人,并且还有笔记可以领取及各路大神技术交流:798478386    

【已更新】B站讲的最详细的Python接口自动化测试实战教程全集(实战最新版)_哔哩哔哩_bilibili【已更新】B站讲的最详细的Python接口自动化测试实战教程全集(实战最新版)共计200条视频,包括:1、接口自动化之为什么要做接口自动化、2、接口自动化之request全局观、3、接口自动化之接口实战等,UP主更多精彩视频,请关注UP账号。icon-default.png?t=N7T8https://www.bilibili.com/video/BV17p4y1B77x/?spm_id_from=333.337什么是重试机制?

为避免任何混淆,我们理清“自动测试重试”的意思。

假设我有 100 个自动测试用例。当我运行这些测试用例时,框架将单独执行每个测试,并产生测试的通过或失败结果。在套件结束时,框架将所有结果聚集在一起。在最佳情况下,所有测试通过:100/100。

但是,假设其中一个测试失败了。在发生故障时,测试框架将捕获任何异常,执行任何清理例程,记录故障,并安全地移动到下一个测试用例上。在套件结束时,该报告将显示 99/100 通过一个测试失败的测试。

默认情况下,大多数测试框架将一次运行每个测试。但是,某些测试框架具有用于自动重新运行的测试用例故障的功能。框架甚至可以使测试人员能够指定要重试的次数。因此,假设我们为我们的 100 个测试套件配置了 2 次重试。当一个测试失败时,框架将为这个用例再执行 2 遍,再转移到下一个用例。

抽3分钟检验一下,自动化测试重运行,我会了么?_第2张图片

重试可能被滥用

假设你现在是自动化团队的,每晚为 Web 应用程序提供 300 个自动测试,如大家所知,Web 测试经常不太稳定,每天晚上大约十几个不同的测试失败,每天早上都花了很多时间调试问题。但是当你重新运行这些失败用例时,他们几乎总是通过。所以你现在每天晚上都会会自己的自动化测试程序设置重运行。

这种策略是好的吗?很难说!因为这实际上是在隐藏问题,而不是暴露问题。测试人员应该关注爆红,而不是绿色的通过信息, 通过重运行机制,原来产生红色警示的 10 几个用例都无一例外的通过了, 你还会花精力去分析晚上这 10 几个用例失败可能出现的原因吗?

万一当时确实是在异常的条件下,真的触发了这些用例爆红, 后面因为条件回复正常,才执行成功呢?

如果这种异常条件总是间歇性的出现呢?在这种情况下,用例重运行隐藏了可能出现的 bug。

实际上失败重运行在手工测试也很普遍,不是自动化独有的。测试人员喜欢找到一致,可重复的失败,因为这些失败很容易解释。一旦一个测试问题只是间歇性的出现,我们就没法向开发和团队其他人员解释了。这些问题可能是环境因素导致的,可能是达到的条件比较苛刻,因此难以复现。

通常情况下,如果不能轻松复现这个测试问题,我们会选择沉默,不再和开发继续争吵。而自动化的重运行机制也是这样,当一个用例失败时,我们可以选择复现,如果第二次没再出现,我们就默认了,这里没问题,因为问题没有复现!!

抽3分钟检验一下,自动化测试重运行,我会了么?_第3张图片

那么,失败重运行的正确打开方式是怎样的?

首先,一定要记录所有失败的日志信息和失败原因,如果有必要,不管重运行后有没有成功,只要用例有一次爆红,都应该引起测试人员的警觉:这里是很有可能出问题的。

其次,在项目迭代过程中,我们不一定有时间去解决这些间歇性发生的问题。要复现问题都比较困难,更不要说要分析,和开发人员沟通的过程了。

最终的答案,还是优先级。一致性的失败是我们重点要提交的问题,他们总是报红,不管你是不是做了重运行。当解决了这些一致性失败时,再考虑黄色问题(重运行、警告)。

不管如何,重运行机制是一种非常好的工具和手段,它能让我们知道哪些问题是一致性的,哪些是间歇性的,重点在于,作为测试人员应该警戒所有的红色和黄色,而不是想法设法把红色变成绿色。

你可能感兴趣的:(职场和发展,jenkins,fiddler,测试工具,面试)