不符合需求的绝对是 Bug，但是用户体验不佳这个要如果定义呢，你自己觉得不好用，别人不一定觉得不好用，这个是不能算作 bug，只能是使用体验不好，需要相应负责人来讨论要怎么该

上面同学说的对，从测试角度说，一切与需求不符的就应该当做 bug 处理；不过有些东西也要视情况而最终定论，比如说一个功能开发人员开过程中进行了流程或是体验的优化，结果是与需求不太一致的，但最终结果能够说服大家是比起初的需求好的，这种情况就应该另当别论了。

这取决于团队对 bug 定义的共识。而不是一个人说了算。
有些内部的东西，全是 bug，那又怎样？
有些 2C 的，一个标点符号错了，他都是严重 BUG。

需求中有，做了做错了就是 bug;需求中没有，就是需求。

1 楼的同学说的不错，再加俩句:1.对于模糊的问题要从多方向考虑，切忌从自己的角色直接下结论，可以适当请教老司机，leader 一类的。2.测试本身也需要勤思考场景使用的细节，如人员属性，应用环境中，如果本身这块没定义，可以尝试总结并在会议上提出风险。彰显我测试的隐形价值。

一般遇到这种模棱两可的问题，建议把问题抛出来让团队决策。

我觉得处理顺序是：
1、首先可以直接找产品明确一下需求。
2、如果产品同学觉得这一块内容不需要明确，而你认为当前的处理方式会影响用户体验，可以再将问题抛出来由大家进行讨论决策。
3、实在无法决策，可以联系下使用者，运营同学既然是最终的使用者，他们对系统使用体验的要求就是最终要求哈哈哈。

我司是运营兼产品 哈哈哈

努力让自己成为标准啊哈哈

为什么需求评审没有定这块逻辑？为啥测试用例没有涉及这块？为啥测试用例评审没有指明这块？
有多个点可以控制这个问题！不管现在怎么处理，只有需求明确了，你才可以定义它是不是 bug

https://testerhome.com/articles/16966
@frzyq

可看看 这个 缺陷类型 的分类 要清楚 有什么样的缺陷。 这样做缺陷统计分析 缺陷分布柱状图 就可以兑当前系统 软件 或 服务 质量做出评估。

角度 维度不同 分类也不同 我文中有分析。

主要是 技术实现类缺陷 业务需求类缺陷。 这是一个维度
可以再上边两个维度上 往里塞。

技术实现类的 可以按 三层结构 前端 服务 数据库 来分别界定各自层级结构下的缺陷。 如上 缺陷分类好了 柱状分布图 更能真实反映 软件质量。

比如 前端 下的 子缺陷问题类型 问题多了 说明当前 前端开发人员 实现质量不高。
服务 接口 类的问题多说明 服务接口开发人员 逻辑问题多 接口问题多 实现质量不高。
数据类的 多了 说明 服务 问题多 质量不高。
你可以 在三层下 细分问题类型 这样越做越细 你对 缺陷定义的越准确 说明你对 缺陷的理解越深 对当前系统技术实现的细节 理解的越深 脑子里有层次感 有系统感
就像一个 机械表 它内部的运行机理 组成构成 都 透明的 如庖丁解牛， 十分清晰.

哦 另一个 层面 就是 你要对 缺陷问题 赋予 重要程度 是什么程度的缺陷 阻碍 致命 重要 次要 轻微。
比如 致命 的 数据 尤其是 落地数据类的 错误 比如 订单 钱包 里的某个字段 错了 那肯定是致命的。

你说的那个 应该是 次要 有解决处理办法 属于 运营人员配置错误 导致的前端 用户问题。 这个应该加强 对运营后台的培训 或 逻辑限制 防止他们用错。