28|解决问题:如何保证自动化测试的可信性?
柳胜
你好,我是柳胜。
咱们今天讨论一个十分影响自动化测试 ROI 的具体问题,就是自动化测试的可信性。你可能听过健壮性,稳定性,但什么是自动化测试可信性呢?
我说一个场景你就明白了,当你的 UI automation 测试报告显示 Login 案例运行失败了,查了 Log 之后,发现是测试机上出了一个弹窗,转移了浏览器的焦点导致失败。这种情况下,就是自动化测试的失败 != 产品的 Bug,你白忙活了一通。
同样的,另外一个场景,你的 API automation 测试报告一直显示成功,直到有一天,生产环境发生了 Bug,你检查 API test 的执行日志,才发现 API 的 Response 早就出了问题。一个字段的 Default value 从 True 变成了 0,但是 Automation 没有检查这个字段,漏掉了 Bug。这种情况下,自动化测试的成功 != 产品没有问题, Bug 泄漏了。
通过这两个例子,你能够看出来,可信性指的是自动化测试报告是否直接反映产品真实的质量状态。如果它经常误导报告的使用者,那么自动化测试快速可靠的价值就会大打折扣。你也没有信心把自动化测试当做一个服务,提供给开发人员和运维人员去使用。
如果你的自动化测试项目有可信性不足的问题,那怎么办呢?学完今天的内容,你就知道怎么用度量驱动来解决这个问题了。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了自动化测试可信性的重要性,并提出了解决问题的思路。文章从自动化测试结果与产品质量状态的关系出发,探讨了假阳和假阴的影响,并提出了基于Bug的度量方式。作者强调了度量数据的来源应该是未经人加工的,并呼吁寻找更合适的度量办法。通过分析自动化测试结果的成功和失败,结合产品功能的正确与错误,文章提出了度量假阳和假阴的思路,并强调了数据驱动的解决思路。此外,文章还介绍了基于Assert语句的度量方法,以及建立完整度量驱动周期的重要性。最后,文章提出了思考题,鼓励读者分享自己的度量方法和经验。整体而言,本文为关注自动化测试的读者提供了深入的技术探讨和解决问题的思路,具有一定的参考价值。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《自动化测试高手课》,新⼈⾸单¥59
《自动化测试高手课》,新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(4)
- 最新
- 精选
- 亭子Assert 检查点的失败,是产品错误,其它的失败都属于自动化测试代码健壮性的问题。 个人习惯一般在用例结尾处才去编写Assert断言,那用例执行中出现的如页面加载不出,系统异常等问题,也可能是系统bug,那是不是要每操作一步就写一条断言,那这样会不会造成代码行数太多可读性变差呢
作者回复: 理解你说的问题。在实践中,我们可以丰富Automation Failure的分类,不局限于非黑即白“Assert”和“非Assert”的思路, 并对它们进行优先级和重要程度排序,形成自动化测试的评级制度。 以Java代码为例,不管Assert还是Timeout,还是其它错误,都是exception的形式,可以被框架捕捉到的。你可以得到一个列表来驱动不同角度的改进。 1. Failure1 ---->这需要改进么,谁来改进? 2. Failure2 ----> 这要改进么,谁来改进? 3. Failure3 ----> 这需要改进么,谁来改进?
2022-05-254 - 羊羊总结自己在自动化实践中的经验: 有些 assert fail 也是假阳导致的,对于这种情况,就是记录假阳的原因,改进自动化脚本和框架。老师提到的变异测试是个很好的思路。 遇到过的最极端的情况,自动化脚本啥操作没做,结果为pass。导致我们把脚本的默认结果设置为fail,需要检测点去更新最终的测试结果。 非检查的错误都会抛出异常,在异常模块定义了各种级别的异常,而且在定义了异常的处理方法,然后在数据库里面关联了每种异常和处理函数。异常发生后会通过反射机制去调用异常处理函数。 但是当时没有把这些数据统计出来,导致领导都不知道我们小组天天都在忙啥。
作者回复: 期待你加入自动化测试高手微信群。在那里有很多分享!
2022-08-05归属地:日本1 - ifelse微信群怎么加?2024-03-03归属地:浙江
- ifelse学习打卡2024-03-03归属地:浙江
收起评论