发布前遗留的 Bug 个数不是衡量标准，遗留问题定级是重点；我们发布版本之前都会针对遗留的缺陷跟团队进行定级，体验性问题以及严重程度不高的，发布前团队确定不改的，单独列举出来，在测试报告中标注暂时不做修复的原因；这样就避免了发布后，测试背锅的问题；你们跟客户合作的话，发布前测试报告可以邀请客户一起过一下，遗留问题客户认为必须要改的还是要改掉；体验性问题，测试没做记录，发布后被客户吐槽发现了，他们肯定会认为是 Bug，如果提前有个记录，就可以把锅甩出去

你这里就用了开发的思维了，认为功能没问题就没有 bug。但实际上测试这边更多需要站在使用者的角度上去验证问题，功能测试的流程里是有【可用性测试】的类别，包括界面设计、导航流畅性、反馈机制等方面的测试。还有客户的吐槽也是可以了解用户的需求和期望，并根据反馈进行改进的。 这些吐槽都可以提成【建议】级别的 bug 单，推给开发和产品，也可以让上面的人知道，这种不是功能性 bug

你说得这些没明确边界，没衡量标准，很难推动开发修改，另外，客户的使用感受也是非常主观的

那你这需求是给开发服务还是给客户服务？ 如果是重要客户，你这边不跟进吗？ 客户的使用体验就是主观的，你不能用客观去思考。。。。该提的单子还是得提，让产品去拿主意，反正测试这边是很注重用户体验的，如果提了产品同意了，开发不改，那就是开发背锅

就举个最简单的例子。产品设计稿设计是：未领取的券显示【立即领取】，已领取完的显示【已领取】，券只能给开通了 plus 会员的用户领取。那实际用户体验中就发现，显示领取的券点击后提示没资格领取，发起投诉。 就这个问题，从客观上讲，开发的提示交互做了，需求也是按照产品的来，测试这边针对这个投诉需要提单吗？ 那肯定是要的，测试这边不要做决定人，把问题抛给产品嘛，他还是觉得投诉的人不值得关注，那就把 bug 关了

所以，大家方向是不是搞错了，，我比较核心的问题是，，，项目出 bug，，应该是正常的吧，，不过，每次发版总出 bug，客户会失去信心，这种情况，大家是如何应对的。

to b 的？客户抱怨太多，那就加个客户验收或者灰度测试的流程，不过估计客户估计又会说没时间，这种基本无解；如果是 UI 操作层面的也能对付过去，更多的还是看产品和客户沟通是否充分。