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

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

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

使用代码自动创建 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 可能超长，关于为什么要加时间的目的不清楚，

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

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

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

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