自动化工具 自动化接口测试,怎样判断 Bug 是否存在

stone9159 · November 16, 2020 · Last by 陈恒捷 replied at November 19, 2020 · 1443 hits

如图,接口测试完成后,代码会根据测试结果在jira上创建bug,bug数据来源如下:

bug创建成功后显示如下

每次测试用例不通过,首先查看是否已有相关Bug,
因为存在一下两种情况:
a)两次错误相同
b)两次错误不相同
问题:怎样判断bug是否已存在
补充问题:
1)bug的summery 现在还不确定该怎么写,因为如果error_info太长,创建问题可能会失败,也希望提供关于summery写法的意见
2)bug的优先级应该怎样给值也没想到最好的办法,因为用例的优先级不能完全代替bug的优先级

共收到 9 条回复 时间 点赞

不要用代码自动创建bug单,要手工创建。

能获取到message,将message加到列表中,每次新插入一条message就比较一下列表中有没有这条message,不就完成了这个业务逻辑吗?

Thirty-Thirty 回复

为什么,会存在什么问题吗?因为接口测试这种,就算你手动创建,能够填写的内容还是那些,人工唯一就是可以判断这个pr出现没

stone9159 回复

使用代码自动创建bug单,首先很难判断要创建的bug是否已经存在,其次你补充的问题也很难解决,再者完整的bug单还有别的项都是自动化难以解决的。解决这些问题远没有手工创建更准确、更简便、也更划算。

因为存在一下两种情况:
a)两次错误相同
b)两次错误不相同
问题:怎样判断bug是否已存在

我觉得你需要先想想,怎么可以认为2个错误是重复的。是根据 e.getMessage 内容就行,还是加上堆栈,还是还得加上前后n行的日志?
确定了这个,问题也就解决了。

PS: b)两次错误不相同,这种我觉得怎么判定应该也不会认为是重复的吧?

补充问题:
1)bug的summery 现在还不确定该怎么写,因为如果error_info太长,创建问题可能会失败,也希望提供关于summery写法的意见
2)bug的优先级应该怎样给值也没想到最好的办法,因为用例的优先级不能完全代替bug的优先级

1、summary 建议接口名称+失败message+执行时间,确保不重复且开发看起来比较清晰
2、如果说用例优先级不能代替bug优先级,那就按bug严重程度咯。我目前想到的:http code=4xx/5xx优先级最高,业务code!=成功次之,业务 code 成功但返回字段不符合要求优先级最低。不过建议用用例优先级最佳,毕竟功能重要,功能失败对应的 bug 也应该很重要。

总结

其实个人比较赞成一楼的观点,不要自动化测试错误就直接报缺陷,毕竟环境类问题(如配置不对、数据是脏数据、性能慢一点导致用例超时)当做缺陷,开发一般也不会太认可,而且数量一不小心就会太爆炸(比如测试环境网络问题挂了,立马100多个bug,谁都受不了。。。)。我们一般是执行2次用例都是同样错误,才会开始人工去确认,确认后再报bug。

上海开票 回复

你是中毒了?末尾这一串链接是啥。

陈恒捷 回复

1.关于自动化创建bug这个,确实遗漏了非程序方面导致的bug,所以改为先保存在在excel文档
2.保存在excel文档后,也想通过代码去删选是否bug已存在
3.summary:如果message太长,summary可能超长,关于为什么要加时间的目的不清楚,

stone9159 回复

加时间是为了方便区分,要不看到一样的summary有3个已解决1个待解决会有点怪。不过如果可接受也可以不加时间。

message 太长的可以做个简单的截取算法哈,只截取最多多少个字符,并且从后往前截取(针对层层叠加的最外层很可能都是长一个样)。不过一般message都不会太长,除非是少数层层叠加的。

保存在excel文档后,也想通过代码去删选是否bug已存在

没明白代码删选具体是想怎么做,是无人工介入代码直接判断么?个人觉得你的方向可以朝着怎么降低自动化发现bug上报到缺陷管理里面的成本(比如搞个简单的 web 界面,人工做一次简单复核,人工复核确认是要上报的一键上报),但代码直接判断会比较复杂(要综合当时的其他数据判定,有一套严谨的规则,甚至考虑引入机器学习自迭代),有这个资源还不如投入到怎么自动生成自动化用例里面。

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up