河北省住房建设厅官方网站,如何在电网网站做备案,vs 2008 手机网站开发,大数据 做网站流量统计如果有人手动运行测试#xff0c;那么他们会暂停并了解更多信息。但是#xff0c;当自动测试失败时#xff0c;其余部分可能会继续运行。在套件完成之前#xff0c;你是没有办法看到测试报告的#xff0c;并且自动化程序不会在故障时执行任何额外的操作尝试找出问题。当剩…如果有人手动运行测试那么他们会暂停并了解更多信息。但是当自动测试失败时其余部分可能会继续运行。在套件完成之前你是没有办法看到测试报告的并且自动化程序不会在故障时执行任何额外的操作尝试找出问题。当剩下的用例全部执行以后测试人员可能会重新点击一下执行按钮看看第二遍失败的用例会不会执行成功。
那么自动测试重试好还是坏这实际上是一个相当争议的话题。 如果你想学习自动化测试我这边给你推荐一套视频这个视频可以说是B站播放全网第一的自动化测试教程同时在线人数到达1000人并且还有笔记可以领取及各路大神技术交流798478386 【已更新】B站讲的最详细的Python接口自动化测试实战教程全集实战最新版_哔哩哔哩_bilibili【已更新】B站讲的最详细的Python接口自动化测试实战教程全集实战最新版共计200条视频包括1、接口自动化之为什么要做接口自动化、2、接口自动化之request全局观、3、接口自动化之接口实战等UP主更多精彩视频请关注UP账号。https://www.bilibili.com/video/BV17p4y1B77x/?spm_id_from333.337.search-card.all.click 什么是重试机制
为避免任何混淆我们理清“自动测试重试”的意思。
假设我有 100 个自动测试用例。当我运行这些测试用例时框架将单独执行每个测试并产生测试的通过或失败结果。在套件结束时框架将所有结果聚集在一起。在最佳情况下所有测试通过100/100。
但是假设其中一个测试失败了。在发生故障时测试框架将捕获任何异常执行任何清理例程记录故障并安全地移动到下一个测试用例上。在套件结束时该报告将显示 99/100 通过一个测试失败的测试。
默认情况下大多数测试框架将一次运行每个测试。但是某些测试框架具有用于自动重新运行的测试用例故障的功能。框架甚至可以使测试人员能够指定要重试的次数。因此假设我们为我们的 100 个测试套件配置了 2 次重试。当一个测试失败时框架将为这个用例再执行 2 遍再转移到下一个用例。 重试可能被滥用
假设你现在是自动化团队的每晚为 Web 应用程序提供 300 个自动测试如大家所知Web 测试经常不太稳定每天晚上大约十几个不同的测试失败每天早上都花了很多时间调试问题。但是当你重新运行这些失败用例时他们几乎总是通过。所以你现在每天晚上都会会自己的自动化测试程序设置重运行。
这种策略是好的吗很难说因为这实际上是在隐藏问题而不是暴露问题。测试人员应该关注爆红而不是绿色的通过信息 通过重运行机制原来产生红色警示的 10 几个用例都无一例外的通过了 你还会花精力去分析晚上这 10 几个用例失败可能出现的原因吗
万一当时确实是在异常的条件下真的触发了这些用例爆红 后面因为条件回复正常才执行成功呢
如果这种异常条件总是间歇性的出现呢在这种情况下用例重运行隐藏了可能出现的 bug。
实际上失败重运行在手工测试也很普遍不是自动化独有的。测试人员喜欢找到一致可重复的失败因为这些失败很容易解释。一旦一个测试问题只是间歇性的出现我们就没法向开发和团队其他人员解释了。这些问题可能是环境因素导致的可能是达到的条件比较苛刻因此难以复现。
通常情况下如果不能轻松复现这个测试问题我们会选择沉默不再和开发继续争吵。而自动化的重运行机制也是这样当一个用例失败时我们可以选择复现如果第二次没再出现我们就默认了这里没问题因为问题没有复现 那么失败重运行的正确打开方式是怎样的
首先一定要记录所有失败的日志信息和失败原因如果有必要不管重运行后有没有成功只要用例有一次爆红都应该引起测试人员的警觉这里是很有可能出问题的。
其次在项目迭代过程中我们不一定有时间去解决这些间歇性发生的问题。要复现问题都比较困难更不要说要分析和开发人员沟通的过程了。
最终的答案还是优先级。一致性的失败是我们重点要提交的问题他们总是报红不管你是不是做了重运行。当解决了这些一致性失败时再考虑黄色问题重运行、警告。
不管如何重运行机制是一种非常好的工具和手段它能让我们知道哪些问题是一致性的哪些是间歇性的重点在于作为测试人员应该警戒所有的红色和黄色而不是想法设法把红色变成绿色。
