感觉你们聊的不是一个维度。。。

bug 指代的是结果。程序运行输出结果不符合预期称为 bug
而你前面列的 1-4 和开发说的 “外部原因” 都是在说原因，是指出现这个结果背后的原因。

bug 可以是外部原因造成的，两者不冲突。你想说的冲突，是不是测试认为这些属于开发人为操作失误导致，开发需要改进；而开发说是外部原因，即认为开发不需要改进？

1.从测试角度来看，不论是少提文件还是少改配置，执行的最终结果与预期不符，出现一些错误，我们都可以判定为缺陷（Bug）；
2.针对这些 Bug 我们再来分析排查原因，是代码逻辑本身有问题？还是测试环境有问题？上述四点都是引起 Bug 的具体原因；
3.如果你们开发身上有缺陷指标相关的 KPI，那就可以理解为什么会标记为 “外部原因” 了...

最后要说的是，不论出于什么原因，要及时修复，避免日后出现同样的问题就行。如果一再因为开发自身原因导致 Bug 量居高不下，那就要把这类问题单独拿出来说道说道了。

bug 有外因和内因，但是无论是什么原因，bug 就是 bug。

你想表达的是你们认为是他们的原因，但是他们说是外部原因，有甩锅的嫌疑吧。

不过少提文件和少 sql 都能提测，感觉几乎没有自测就提测了，建议加入测试准入标准~~~

该说的楼上大佬们都说了，我补充一句：给你们部门老大提 bug，让他去改下流程

不论出于什么原因，要及时修复，避免日后出现同样的问题就行_------------是的，我的目的也是希望尽量避免这种问题。开发考核的是代码错误类型的 bug，其他配置/环境什么的，不计入考核。

我也是一直在提 测试准入原则，这些都是最基本的。并且开发环境时间太久了，数据比较乱，搞不起自测联调。

已经推给领导去沟通了。目前感觉他们在纠结类型归属，是属于代码错误还是 标准规范。就是禅道那个 bug 类型。

少提文件或 sql，测试时当然会报错，会提一个 bug 给开发。开发定位是因为少提文件或 sql 后，选择解决方案为外部原因。我们测试是不认同的。

我个人是认为 sql 和文件都属于代码，外加为了让他们重视，就应该提到代码错误类型里。然后他们是不太认同。认为代码错误是功能性的错误才算。

纠结缺陷类型，其实是考核制度的锅。。。没有合理引导，大家关注点都不在提高质量上，都怕影响自身去了，这种风气长此以往会导致项目组内部矛盾重重，毫无团队气氛。。。。

只要是 bug，就应该重视和解决，有甩锅那时间，还不如多总结问题。对项目来说，外因和内因并没有什么区别。

列一下你们已有的解决方案有哪些，以及这些解决方案后面会用于什么？

我理解只要能体现是属于开发方面的原因，他们需要优化，就行了。说实话，都属于比较低级的人为操作错误。

是的，百度都没有这种问题 。 目前就是希望大家统一一下，不想纠结这个了。谢谢大佬回复。

bug 定性，就是缺陷类型。
分的维度：
1 业务维度
业务维度带来的缺陷类型可能有，业务功能，业务流程，
2 技术实现维度
可能有 前端问题 接口问题，服务问题，数据库问题 这是大类 可以把各个大类 比如前端问题再细化。比如前端 界面样式问题，前端脚本问题等等等等

自己根据实际统计缺陷的需求 或公司实际项目情况酌情增减， 多了没好处，少了统计不细。

我有一个思路，这功能拿出去给客户用，客户觉得不行，你给他说是 “外部原因”，绝对不是 bug，你看客户能不能接受。

我咋感觉 是 环境问题，部署问题